レッスン3：名前の話——URL から始まる名前解決

このレッスンで学ぶこと

URL がスキーム・ホスト・パスという要素に分解できることを理解する
ドメインの階層構造を、右から読む発想で整理できる
DNS による名前解決の 4 つのステップを説明できる
キャッシュと TTL の役割を理解する
名前解決が失敗したときに、画面がどう見えるかを見分けられる

前回のレッスンでは、IP アドレスという「番地」の読み方を学びました。ところが、私たちが普段ブラウザに打ち込むのは、「203.0.113.10」のような数字の並びではなく、「www.example.com」のような文字の並びです。数字の番地と、私たちが打ち込む名前は、どうつながっているのでしょうか。今回のレッスンでは、番地と名前をつなぐ仕組みをたどります。中核メッセージの 2 つ目、「番地と名前は別物」を、具体的に掘り下げる回です。

URL の分解——スキーム・ホスト・パス

ブラウザのアドレスバーに打ち込む文字列を、URL（Uniform Resource Locator）と呼びます。URL は、いくつかの要素が決まった順番で組み合わさってできています。

https://www.example.com/docs/page.html

この URL を、要素ごとに分解してみましょう。

要素	この例での値	役割
スキーム	https	どんな方法で通信するかを示す。Web ページなら https や http が一般的
ホスト	www.example.com	通信の相手を、名前で示す部分
パス	/docs/page.html	相手のサーバーの中の、どのファイルや情報を指すかを示す部分

スキームは、URL の先頭にあり、「://」の手前までの部分です。ホストは、「://」の直後から、次のスラッシュの手前までの部分で、これから話す DNS が主役になる部分です。パスは、ホストのあとに続く部分で、サーバーの中のどこにある情報を指すかを表します。

💡 ポイント レッスン 5 で扱う HTTPS は、この URL のスキームが「https」であることを指します。「http に暗号化の手順が 1 つ挟まる」仕組みですが、詳しい中身はレッスン 5 で扱います。今のレッスンでは、URL の中に「ホスト」という名前の部分があることだけを押さえてください。

URL のそのほかの要素

URL には、パスのあとに続く要素が、もう 2 つあります。1 つは、疑問符に続く「クエリ文字列」で、検索キーワードや表示条件など、サーバーに渡す追加の情報を表します。例えば「?page=2」であれば、「2 ページ目を表示してほしい」という指定を意味します。もう 1 つは、シャープ記号に続く「フラグメント識別子」で、同じページの中の特定の見出しへジャンプするための目印です。ページ内の目次から見出しへ移動すると、URL の末尾にシャープ記号付きの文字列が付くことがありますが、これがフラグメント識別子です。

いずれも、これから説明する名前解決には関わりません。名前解決が関わるのは、URL の中の「ホスト」の部分だけです。クエリ文字列やパスがどれだけ複雑でも、宛先のサーバーを特定する作業は、ホスト名だけを見て行われます。

ドメインの階層構造——右から読む

URL のホスト部分にあたる「www.example.com」を、ドメイン（domain）と呼びます。ドメインは、ピリオドで区切られた階層構造を持っています。この階層は、右から左に向かって、大きな単位から小さな単位へと読み進める構造になっています。

flowchart LR
  A["com<br/>トップレベルドメイン"] --> B["example<br/>セカンドレベルドメイン"]
  B --> C["www<br/>ホスト名／サブドメイン"]

一番右にある「com」は、トップレベルドメイン（TLD：Top Level Domain）と呼ばれ、ドメインの中でもっとも大きな区分です。「co.jp」「org」「net」なども、トップレベルドメインの仲間です。その左にある「example」は、多くの場合、企業や組織が取得する固有の部分で、セカンドレベルドメインと呼ばれます。さらにその左にある「www」は、組織の中でのサービスの区分を示すホスト名で、サブドメインと呼ばれることもあります。

住所の並びに例えると、この構造がわかりやすくなります。日本の住所は「東京都、渋谷区、〇〇一丁目」のように、大きな単位から小さな単位へと並びます。ドメインも同じで、右にある「com」が国や大きな区分、真ん中の「example」が組織の名前、左の「www」が組織の中の窓口、という関係になっています。

日本の企業でよく見かける「www.example.co.jp」のようなドメインは、もう少し階層が深くなります。一番右の「jp」が日本を表すトップレベルドメイン、その左の「co」が企業であることを示す区分、さらに左の「example」が組織の名前、一番左の「www」がホスト名です。階層が増えても、右から左へ大きな単位から小さな単位へと読む考え方は変わりません。

📝 補足 このコースでは、ドメインを取得する手続きや、料金の仕組みには触れません。あくまで、URL の中にあるドメインという文字列を、どう読み解くかに絞って説明します。

DNS とは何か——名前を番地に変換する仕組み

ドメインという名前が何を表すかがわかったところで、本題に入ります。ブラウザは、ドメインという名前を受け取っても、そのままでは通信できません。パケットの宛先には、レッスン 2 で学んだ IP アドレスという番地が必要だからです。

この「名前」から「番地」への変換を担う仕組みが、DNS（Domain Name System）です。DNS は、インターネット全体で共有される、巨大な電話帳のような仕組みだとイメージするとわかりやすくなります。電話帳が「名前を引くと電話番号がわかる」道具であるように、DNS は「ドメインを引くと IP アドレスがわかる」道具です。

この、名前から番地を調べる一連の手続きを、名前解決（name resolution）と呼びます。

名前解決の 4 ステップ

名前解決は、1 つの装置だけで完結するわけではありません。役割の異なる複数の登場人物が、バケツリレーのようにやり取りをしながら、最終的な番地にたどり着きます。

sequenceDiagram
    participant U as 利用者の端末
    participant R as リゾルバ
    participant Root as ルート DNS サーバー
    participant TLD as TLD DNS サーバー
    participant Auth as 権威 DNS サーバー
    U->>R: www.example.com の番地は？
    R->>Root: .com はどこにある？
    Root->>R: .com の TLD サーバーはここ
    R->>TLD: example.com はどこにある？
    TLD->>R: example.com の権威 DNS サーバーはここ
    R->>Auth: www.example.com の番地は？
    Auth->>R: 203.0.113.10 です
    R->>U: 203.0.113.10 です

登場人物を、1 つずつ確認しましょう。

リゾルバ（resolver）：利用者の端末から名前解決の依頼を受け取り、代理でほかの DNS サーバーに問い合わせる役割です。多くの場合、契約しているインターネットサービスプロバイダーや、会社の情報システム部門が用意したものが使われます
ルート DNS サーバー：階層構造の一番上にあるサーバーで、「.com はどのサーバーが担当しているか」という、トップレベルドメインの案内役を担います
TLD DNS サーバー：トップレベルドメインごとに存在するサーバーで、「example.com は、どのサーバーが詳しく知っているか」という、次の案内役を担います
権威 DNS サーバー（authoritative DNS server）：そのドメインについて、実際の IP アドレスを知っている、最終的な回答者です

リゾルバは、この 4 段階の道のりを順番にたどりながら、最終的に権威 DNS サーバーから正しい IP アドレスを受け取り、利用者の端末に返します。私たちが URL を打ち込んでから画面が表示されるまでのあいだに、こうしたやり取りが瞬時に行われています。

🔰 初学者の方へ 「リゾルバ」「権威 DNS サーバー」といった名前を丸暗記する必要はありません。大事なのは、「名前から番地を調べる作業は、1 つの箱の中で完結するのではなく、案内役のバケツリレーで進む」という全体像です。

誰が「代わりに調べてくれる」役なのか

先ほどの図をよく見ると、実際にルート DNS サーバー、TLD DNS サーバー、権威 DNS サーバーの 3 か所を順番に訪ね歩いているのは、リゾルバだけです。利用者の端末は、リゾルバに 1 回問い合わせるだけで、最終的な答えを受け取っています。このように、依頼を受けた側がすべての手続きを代行し、最終的な答えだけを返すやり取りを「再帰的な問い合わせ」と呼びます。一方、リゾルバがルート DNS サーバーや TLD DNS サーバーに対して行う問い合わせは、「知っているところを教えてほしい」という案内だけを求めるやり取りで、「反復的な問い合わせ」と呼ばれます。

権威 DNS サーバーは、多くの場合、そのドメインを取得した組織や、組織が契約するサービス事業者が用意します。企業が自社のドメインの権威 DNS サーバーの設定を誤ると、その企業のドメイン宛ての通信全体が届かなくなるため、権威 DNS サーバーの設定変更は、慎重に扱われる作業の 1 つです。

キャッシュと TTL——毎回たどらなくていい理由

先ほどの 4 ステップを、アクセスするたびに毎回繰り返していては、時間がかかってしまいます。実際には、一度調べた結果を一定期間覚えておく「キャッシュ（cache）」という仕組みが働いています。

一度名前解決をした結果は、リゾルバや利用者の端末に一時的に保存されます。次に同じドメインへアクセスするときは、保存された結果をそのまま使い、4 ステップの問い合わせを省略できます。これにより、2 回目以降のアクセスは、格段に速くなります。

このキャッシュを、いつまで覚えておくかを決めるのが TTL（Time To Live）です。TTL は、権威 DNS サーバーが「この情報は、何秒間キャッシュしてよい」と指定する値です。TTL が長く設定されていれば、キャッシュは長持ちしますが、サーバーの IP アドレスが変わったときに、古い情報がしばらく残ってしまう可能性があります。逆に TTL が短ければ、変更はすぐに反映されますが、問い合わせの頻度が増えます。

⚠️ 注意 サーバーの引っ越し（IP アドレスの変更）を行った直後に、「新しいサーバーにアクセスできる人と、できない人が混在する」という現象が起きることがあります。これは、TTL の設定にしたがって、キャッシュがまだ残っている端末があるためです。多くの場合、TTL で指定された時間が過ぎれば自然に解消します。

キャッシュは、1 か所だけに存在するわけではありません。ブラウザ自身が短期間だけ記憶している場合もあれば、パソコンやスマートフォンの OS が記憶している場合、契約しているインターネットサービスプロバイダーのリゾルバが記憶している場合など、複数の階層でそれぞれ独立してキャッシュが保持されています。ある階層のキャッシュが更新されても、ほかの階層に古い情報が残っていれば、見え方が食い違うことがあります。「自分のパソコンでは新しいサイトが見えるのに、隣の席の同僚のパソコンではまだ見えない」という状況は、こうしたキャッシュの階層構造が原因で起こります。

名前解決が失敗するとどう見えるか

名前解決の仕組みがわかると、うまくいかないときの見え方も理解しやすくなります。名前解決が失敗する典型的な原因には、次のようなものがあります。

ドメイン名を打ち間違えている
そのドメインが、実際には存在しない、または削除されている
利用しているリゾルバに一時的な不具合が起きている
端末やルーターのネットワーク設定に問題がある

これらのケースでは、多くのブラウザが「このサイトにアクセスできません」といった趣旨のエラー画面を表示し、名前解決に失敗した旨のメッセージが添えられます。この画面が出た場合、パケットが届かなかったのではなく、そもそも宛先の番地を調べる段階でつまずいている、と当たりをつけられます。この切り分けの発想は、レッスン 7 で本格的に扱います。

ここで大事なのは、名前解決の失敗と、通信そのものの失敗を混同しないことです。「サイトにアクセスできない」という結果だけを見ると、原因はすべて同じように見えてしまいます。しかし実際には、宛先の番地がそもそもわからない場合と、番地はわかったのに、そこから先のパケットのやり取りがうまくいかない場合とでは、疑うべき箇所がまったく異なります。前者は名前の層、後者は経路や機器の層の問題であり、レッスン 1 で学んだ階層の発想が、ここでも役立ちます。

📖 もっと詳しく 「このドメインは存在しません」という趣旨のエラーと、「このドメインは存在するが、応答がありません」という趣旨のエラーは、原因が異なります。前者は名前解決そのものの失敗、後者は名前解決には成功したものの、その先の通信で問題が起きているケースが多く、見分けるヒントになります。

講師の現場メモ：「ドメインは正しいのに、つながらない」の正体

私（樋口）がテクニカルサポート部門にいたころ、印象に残っている問い合わせがあります。ある企業のご担当者から、「先週から、取引先のサイトにアクセスできなくなった。ドメイン名は間違っていないはずだ」というお電話をいただきました。

確認すると、たしかにドメイン名の綴りは正しいものでした。ところが、話を聞いていくと、その会社では、ネットワーク全体を管理する情報システム部門が、社内で使うリゾルバを独自に用意していることがわかりました。そして、そのリゾルバの設定変更が、ちょうど問題が起き始めた時期と重なっていたのです。

原因は、リゾルバの設定変更にともなって、一部のドメインへの問い合わせがうまく処理されなくなっていたことでした。ドメイン名という「宛先の名前」は正しいのに、その名前を番地に変換する「案内役」のほうに不具合があった、というわけです。

このとき、私が担当者にお伝えしたのは、「ドメインが正しいことを確認できたら、次は名前解決そのものがうまくいっているかを疑ってください」という切り分けの順番でした。年間数百件の「つながらない」に向き合う中で、私が繰り返し実感したのは、多くの利用者が「サイトが落ちている」「回線が壊れている」と考えがちな一方で、実際にはその手前の「名前を番地に変換する段階」でつまずいているケースが少なくない、ということです。名前解決という、目に見えない裏方の工程を知っているかどうかで、当たりのつけ方は大きく変わります。

まとめ

このレッスンでは、以下のことを学びました。

URL は、スキーム・ホスト・パスという要素に分解できる
ドメインは、右から左へ、大きな単位から小さな単位へと読む階層構造を持つ
DNS は、ドメインという名前を IP アドレスという番地に変換する仕組み
名前解決は、リゾルバ・ルート DNS サーバー・TLD DNS サーバー・権威 DNS サーバーの 4 段階のやり取りで進む
キャッシュと TTL により、毎回すべての段階をたどらなくても、名前解決を高速化できる
名前解決が失敗すると、多くのブラウザは専用のエラー画面を表示する

次のレッスンでは、番地と名前がわかったあとに、実際にパケットがどんな機器を経由して届け先までたどり着くのか、届ける仕組みの側に進みます。

確認クイズ

このレッスンの理解度をチェックしましょう。