WEB制作のための情報サイト / unazuki Library

ドメインとサーバーの関係

サーバーとは

まずは、サーバーについて見ていきましょう。

サーバーとは、ユーザーからのリクエストを受け付け、必要な情報を返す役割を持つ場所です。英語の serve には「提供する」「仕える」といった意味があり、ユーザーのリクエストに応じて情報を提供する存在であることから、サーバー（server） と呼ばれています。

ユーザーがリンクをクリックするなどしてWebサイトへのアクセスをリクエストすると、そのリクエストは特定のサーバーに送られます。サーバーはそのリクエストを受け取り、必要なファイルを返すことで、Webサイトがブラウザ上に表示されます。

サーバーでは、受け付けたリクエストに応じてさまざまな処理を行うことができますが、まずは 「リクエストに応じたHTMLファイルをユーザーに返すもの」 と理解していただければ問題ありません。

そうやってサーバーからダウンロードしてきたファイルをWebサイトとして表示する役割はブラウザ（ChromeやEdgeなど）が担っています。

ブラウザとは

ブラウザとは、Chrome・Edge・Safari・Firefox など、皆さんが普段Webサイトを閲覧するために使用しているソフトウェアのことです。ブラウザは、HTMLやCSSを解析して（この処理をレンダリングといいます）、Webサイトを画面上に表示します。

そのため、Web制作者は、Webサイトを公開する際に、表示に必要なファイル一式をサーバーにアップロードする必要があります。

なお、ブラウザは最初からWebサイトに必要なすべてのファイルを一度にダウンロードするわけではありません。
まずHTMLファイルをダウンロードし、そのHTMLを解析（レンダリング）する過程で、CSSファイルやJavaScript、画像ファイルなどへのリンクが見つかれば、追加でサーバーにリクエストを送り、それらのファイルを順次取得していきます。

現在ではあまり意識することはありませんが、以前はブラウザごとにHTMLやCSSの解釈が異なることも多く、ブラウザ間の互換性を保つことが非常に大変でした（私がWeb制作を始めた2014年よりも、さらに前の時代の話です）。これは、ブラウザのシェア争いの中で、各ブラウザが独自機能を実装していたことが背景にあります。

こうした混乱を解消するため、Web技術の標準化を進める団体である World Wide Web Consortium（W3C） や、その後に設立された WHATWG が中心となり、Web技術の標準化が進められてきました。

サーバーの住所：IPアドレス

話をサーバーに戻します。サーバーの住所について考えてみましょう。

サーバーにアクセスするためには、現実世界の住所と同じように、どこにあるのかを示す情報が必要になります。
インターネットの世界では、このサーバーの住所が IPアドレス によって定められています。

IPアドレスは、たとえば 192.168.1.1 のように、数字をドットで区切った形式で表されます。ユーザーは、このIPアドレス、つまり インターネット上の住所 にアクセスすることで、サーバーに接続し、Webサイトを表示することができます。

しかし、ここで一つ疑問が生まれます。私たちは普段、Webサイトを閲覧する際に、このようなIPアドレスを直接入力したり、目にしたりすることはほとんどありません。では、実際にはどのようにしてIPアドレスを指定しているのでしょうか。その仕組みに関わってくるのが、ドメインです。次は、このドメインについて見ていきましょう。

ドメインとは

サーバーの住所はIPアドレスだと説明しましたが、IPアドレスは数字の羅列で、人間にとっては非常に分かりづらいものです。そこで、IPアドレスの代わりに、人間にとって分かりやすい文字列として用意されているのが「ドメイン」です。そして、このドメインは、裏側で特定のIPアドレスと紐付けられています。

具体例を見ながら、ドメインについて説明していきましょう。WebサイトのURLには、例えば次のようなものがあります。

https://example.com

このURLのうち、「example.com」 の部分がドメインです。
さらに、com の部分は トップレベルドメイン（TLD） と呼ばれます。トップレベルドメインには、.net、.org、.co.jp などさまざまな種類があり、それぞれ用途や取得条件が定められています。

日本の企業のWebサイトでは、.co.jp を目にすることが多いと思います。この .co.jp は、日本国内の法人向けドメインであり、日本国内で登記された法人でなければ取得することができません。

.co.jp の場合、

• .jp が トップレベルドメイン
• .co が セカンドレベルドメイン

という構造になっています。.jp は日本国内を示し、.co は法人格を示しています。

同様に、日本国内の政府機関であれば .go.jp（government）、大学や短期大学などの教育機関であれば .ac.jp（academic）が使用されます。

設立前の新規法人でも .co.jp は取得できるの？

.co.jp を正式に利用するには、法人の登記簿謄本を提出する必要があります。そのため、法人設立前の段階では、原則として正式取得はできません。ただし、6か月間の仮登録制度があり、その期間中は .co.jp ドメインを利用することが可能です。

仮登録期間内に法人登記を完了し、登記簿を提出することで、正規登録へ移行できます。この仕組みは、.ac.jp や .go.jp などでも同様に用意されています。

ここまでで、ドメインがURLの一部であることが分かりました。そして先述したとおり、このドメインはIPアドレスと紐付けられており、URLにドメインを指定することで、対応するサーバーへアクセスできる仕組みになっています。

例えば、example.com というドメインに対して、IPアドレス 192.168.1.1 が紐付けられているとします。この場合、ユーザーが https://example.com というURLにアクセスすると、そのドメインに対応する IPアドレス 192.168.1.1 のサーバー に接続されます。

では、この ドメインとIPアドレスの紐付けは、どのような仕組みで管理されているのでしょうか。
その役割を担っているのが、DNS です。

次は、このDNSについて見ていきましょう。

DNS（ドメイン・ネーム・システム）

では、そもそも ドメインとIPアドレスはどこで紐付けられているのか というと、その役割を担っているのが DNS（Domain Name System） です。

ユーザーがブラウザでURLリンクをクリックするなどして、特定のWebサイトにアクセスしたとき、どのような流れでWebサイトが表示されるのかを見ていきましょう。
例えば、https://example.com のリンクをクリックしたとします。

するとまず、ブラウザは DNSに対して「example.com に対応するIPアドレスは何か」 を問い合わせます。DNSはその問い合わせに対して、該当するIPアドレスの情報をブラウザに返します。

ブラウザは、返ってきたIPアドレスを使って、そのWebサイトのファイルが格納されている サーバーにアクセス します。そして、サーバー上にあるファイルをダウンロードし、最終的にブラウザ上でWebサイトが表示される、という流れになっています。

DNSサーバーは階層構造になっている

例として、example.com というドメインの場合に、どのような流れで最終的にWebサーバーのIPアドレスへたどり着くのかを見てみましょう。

DNSサーバーには、最上位に ルートDNSサーバー が存在します。まず、ブラウザはこのルートDNSサーバーに問い合わせを行います。ただし、ここでいきなり example.com のIPアドレスが返ってくるわけではありません。
ルートDNSサーバーは、「.com を管理しているDNSサーバーのIPアドレス」を教えてくれます。

次に、.com を管理しているDNSサーバーに問い合わせを行うと、今度は example.com を管理しているDNSサーバーのIPアドレス が返されます。
そして最終的に、そのDNSサーバーに問い合わせることで、example.com に対応する WebサーバーのIPアドレス を取得できます。ブラウザは、この取得したIPアドレスを使ってWebサーバーにアクセスし、Webサイトを表示します。

このように、ドメイン名から対応するサーバーのIPアドレスを特定することを「名前解決」と呼びます。重要な用語なので、覚えておきましょう。

なお、ここで説明した名前解決の流れはあくまで基本的な概念です。実際には、DNSキャッシュサーバーなどが利用されるため、常にこの一連の流れがすべて実行されるわけではありません。

Web制作の現場では、納品時やサーバー移転時などに DNS周りの設定作業が発生することも少なくありません。
そのため、細かい仕組みをすべて理解する必要はありませんが、DNSの役割と全体像は必ず押さえておくようにしましょう。

DNSの反映には時間がかかる

DNS周りの設定を変更した場合、反映までに24〜48時間程度かかることがあります。

例えば、ドメインはそのままでサーバーを変更するケースでは、DNSの設定を変更して、アクセス先のIPアドレスを新しいサーバーに向けます。しかし、この設定を変更した直後から、すべてのユーザーが新しいサーバーにアクセスできるようになるわけではありません。

その原因の一つが、DNSのキャッシュです。DNSには、一度取得した情報を一時的に保存しておく仕組みがあり、このキャッシュが更新されるまで、旧サーバーのWebサイトが表示され続けることがあります。また、インターネット上には非常に多くのDNSサーバーが存在し、ユーザーごとに参照しているDNSが異なるため、「ある人は表示が切り替わったが、別の人はまだ切り替わっていない」といった状況が発生します。

そのため、DNS設定を変更したあと、自分の環境ではすでに表示が切り替わっていても、クライアントの環境ではまだ反映されていない可能性があります。あらかじめ「反映までに時間がかかることがある」という点をクライアントに伝えておくと、トラブル防止につながり、安心してもらえるでしょう。

どこのDNSを使うのか

ここまでで、実務でWebサイトを本番公開するためには、ドメイン・サーバーに加えてDNSが関わっていることが分かりました。DNSサーバーは、特別に個別契約をしなくても、ドメインを取得した時点で自動的に用意されるのが一般的です。

ドメインを取得すると、初期設定ではそのドメインを契約したサービスのDNSが使われるようになっています。

例えば、Xサーバー でドメインを取得した場合、初期設定ではXサーバーのDNSが利用されます。また、お名前.com でドメインを取得した場合は、初期設定でお名前.comのDNSが使われます。これらは、それぞれのドメイン管理画面から確認することができます。

例えばXサーバーのドメイン管理画面で、契約済のドメインを選択してネームサーバー設定を見ると次のようになっています。

ns1.xserver.jpやns2.xserver.jpはXサーバーのDNSなので、つまりこのドメインはXサーバーのDNSで管理されていることがわかります。そしてXサーバーでサーバーを契約すると、サーバーコントロールパネルで、「ドメイン設定」という項目があり、そこで利用するドメインを設定することで、そのドメインとサーバーをXサーバーのDNSで紐づけることができます。

ここまでの流れを整理すると、次のようになります。

1. ドメインを取得する
2. どこのDNSを使うかを指定する（デフォルトはドメインを取得したところのDNS）
3. サーバーのコントロールパネルでドメイン設定をする

DNSを特に変更しないのであれば、ドメインを取得した後、「３」のステップに移動し、サーバー側でドメイン設定をします。

ドメインとサーバーを異なるサービスで契約する場合

ここは特に注意が必要なポイントです。
例えば、Xサーバー でドメインもサーバーも両方契約している場合は、基本的にDNSを意識する必要はありません。初期設定のままで問題なく動作します。

しかし、

• ドメインは Xサーバー で取得
• サーバーは さくらインターネット を利用

といったように、ドメインとサーバーを異なるサービスで契約する場合には、「どこのDNSを使うかを指定する」という手続きが必要になります。

なぜなら、Xサーバーでドメインを取得すると、初期設定ではXサーバーのDNSが使われるからです。この状態のまま、さくらインターネット側のサーバーでドメイン設定を行っても、その設定はさくらインターネットのDNSに対して行われるだけで、XサーバーのDNSには一切反映されません。

つまり、

• ドメインはXサーバーのDNSを参照している
• しかし設定はさくらインターネットのDNSに行っている

という状態になり、設定がまったく意味を持たないことになります。
ドメインが参照していないDNSにどれだけ設定を行っても、Webサイトが表示されることはありません。

使うDNSを変更する

このような構成の場合は、ドメイン側で使用するDNSを、実際に利用するサーバーのDNSに切り替える必要があります。先程のドメイン管理画面をもう一度見てみましょう。

画像の右上にある「設定変更」ボタンから、そのドメインで使うDNSを変更することができます。ここからさくらインターネットのDNSに変更することで、そのドメインの情報をさくらインターネットのDNSで持つことができます。

レコードを変える

DNSは、そのドメインが どのIPアドレスと紐づくか を指定する役割を持っています。もう少し正確に言うと、DNSの中には 「レコード」 という概念があり、このレコードに ドメインとIPアドレスの対応関係 が記述されています。

これまでの例で、

• ドメインは Xサーバー
• サーバーは さくらインターネット

という構成の場合、「使うDNSをさくらインターネットに切り替える必要がある」と説明しました。
しかし実は、DNS自体はXサーバーのままにしておき、DNSレコードを書き換える という方法もあります。

つまり、

• ドメインはXサーバーのDNSを参照したまま
• そのDNSのレコード情報を変更し
• アクセス先のIPアドレスを、さくらインターネットのサーバーに向ける

という形です。

このように、「どこのDNSを使うか」 と 「DNSの中でどのIPアドレスを指定するか（レコード）」 は、分けて考える必要があります。

図にまとめると、次のようなイメージになります。

※ この辺は様々なパターンがあり後に説明するメールも関係してきます。ですので一概にどうするというよりは、状況に応じて適切な対応ができるように仕組みを理解しておくことが重要です。

次にDNSのレコードについて説明をします。

DNSのレコードとは何か

ここまでで、DNSがドメインとサーバーを紐づけている仕組みについては、十分に理解できたのではないかと思います。

ただし、実際のWeb制作の現場では、それだけでは不十分で先程登場した、「DNSレコード」 という考え方を理解しておく必要があります。これまで「DNSはドメインとサーバーを紐づける」と説明してきましたが、正確には、DNSの中にある「レコード」 に、その紐づけ情報が記述されています。

また、DNSは単純に「1つのドメインと1つのサーバーを紐づける情報」だけを持っているわけではありません。
DNSには、ドメインに関するさまざまな情報が保存されており、それぞれが用途別のレコードとして管理されています。つまり、DNSには複数のレコードが存在するということです。

DNSレコード

ここでは、DNSレコードの代表的なものを簡単に見ていきましょう。

• Aレコード
  ドメインとWebサーバーの IPアドレス（IPv4） を紐づけるレコードです。
  Webサイトを表示するために最も基本となるレコードです。
• MXレコード
  メールサーバー を指定するためのレコードです。
  お問い合わせフォームや業務用メールを使う場合に重要になります。
• TXTレコード
  テキスト情報を格納できるレコードで、メールの認証（SPF / DKIM など） や各種サービス連携で利用されます。
• CNAMEレコード
  あるホスト名を、別のホスト名へエイリアス（別名）として紐づけるためのレコードです。

例えば、◯◯◯.co.jp というドメインを、202.211.xxx.xx（サーバーのIPアドレス）と紐づけたい場合は、DNSの Aレコード に 202.211.xxx.xx を設定します。これにより、そのドメインへのアクセスは、指定したIPアドレスのサーバーに向けられます。

ただし、同じレンタルサーバーでドメインとサーバーを契約している場合は、Aレコードは自動的に設定されることがほとんどです。そのため、普段の制作ではレコード設定を意識する機会は少ないかもしれません。

一方、先ほどの例のように、

• ドメインは Xサーバー
• サーバーは さくらインターネット

という構成で、XサーバーのDNSを使い続けたい場合には、Xサーバー側のDNS設定画面で Aレコードを編集し、さくらインターネットのサーバーIPアドレスを指定します。こうすることで、Webサイトの表示時には、さくらインターネットのサーバーが参照されるようになります。

※ なお、メールの送受信もさくらインターネットで行う場合は、Webサイト用のAレコードとは別に、MXレコードの指定が必要になる点には注意してください。

サーバーのみ変更する場合のDNS対応パターンを整理

これまで見てきたとおり、サーバー変更時のDNS対応には、

• DNS自体を変更するパターン
• DNSは変更せず、レコードのみを編集するパターン

の2通りがあります。ただし、これらを判断する際に**必ず考慮しなければならないのが「メールの扱い」**です。ここでは、実務でよくある「ドメインはそのまま、サーバーだけ変更してください」というケースを例に、メールの扱いについて考えてみましょう。

サーバーが変わるということは、当然ながら ドメインと紐づくサーバーも変わる ということです。そのため、Webサイトを新しいサーバーで表示させるには、DNSのAレコードを変更する必要があります。具体的には、新しく契約したサーバーの IPアドレス を確認し（サーバーのコントロールパネルに記載されています）、DNSの AレコードをそのIPアドレスに書き換えることで、Webサイトは新サーバーを参照するようになります。

注意点：メールが届かなくなる？

ただメールのことを忘れないように注意してください。Aレコードを変更したので、Webサイトを開くと新しいサーバーを参照するようになりますが、MXレコードを変更しなければ、メールは旧サーバーに届き続けます。

つまり、

• Webサイト：新サーバー
• メール：旧サーバー

という状態になります。

この状態で 旧サーバーを解約してしまうと、メールが届かなくなる ため注意が必要です。旧サーバーを残して、旧サーバーでメールを送受信するならAレコードだけを変える形で問題ありませんが、運用が分散してわかりづらくコストもかかるので、一般的には旧サーバーを解約して新サーバーでメールを送受信することになるでしょう。その場合、そもそもDNSのレコード変更ではなく、DNS自体を新サーバーのものに変えることを考えます。

メールも新サーバーに移行する

例えば、元々Xサーバーでドメインもサーバーも契約して、XサーバーのDNSを使っていたとしましょう。そしてサーバー変更でさくらインターネットにするとします。このとき、Webサイトだけでなく、メールの送受信もさくらインターネット側で行うなら、XサーバーのDNSからさくらインターネットのDNSに切り替える方法を考えます。

つまりこの例では、

• ドメイン：Xサーバー
• サーバー：Xサーバー
• DNS：Xサーバー

という構成から、

• ドメイン：Xサーバー
• サーバー：さくらインターネットに変更
• DNS：さくらインターネットに変更

となります。この場合下記のような作業が必要になります。

• DNSをエックスサーバー → さくらインターネットに変更
• さくらインターネット側でドメイン設定
• メールアドレスを新サーバーで作成
• メールソフト側の送受信設定を変更

という流れになります（上記は作業順ではありません）。

メールを送受信するサーバーがさくらインターネットになるので、さくらインターネット側でメールアドレスの作成が必要であることに加え、メールソフト側の送受信設定の変更が必要です。（メール送受信の仕組みがわからない方はこちらをご覧ください。：YouTubeが開きます）

これらはあくまでも一例ですが、仕組みを理解して状況に応じて考えるようにしましょう。

補足：外部メールサービスを使う場合

Google Workspaceなど外部サービスでメール管理することもあります。この場合は、Google Workspaceのガイドに従い、Google Workspace用のMXレコードやドメイン認証用のTXTレコードをDNSに追加する必要があります。

Google Workspaceに限らず外部のサービス関係で、レコードを色々書く必要が出てくる場合があります。ただ、この辺は各連携先のサービスのガイドラインを見て作業することになると思いますので、DNSやレコードについて理解しておくことが重要です。

おわりに

Web制作の現場では、さまざまなパターンが考えられます。もちろん、何も設定を変更せず、ファイルをアップロードするだけで完了するケースも少なくありません。しかし、サーバーを変更したいという要望は、一定の割合で必ず発生します。

そうした場面に慌てず対応できるようにするためにも、Webサイトがどのような仕組みで表示されているのかを理解しておくことが重要です。
ドメイン・サーバー・DNS、そしてDNSレコードまで含めて全体像を押さえておけば、状況に応じた適切な判断ができるようになります。

Web制作者として、「なんとなく動いている」ではなく、「仕組みを理解したうえで対応できる」状態を目指しましょう。