ブラウザに URL を打ってから、IP に辿り着くまで何が起きているのか？
アドレスバーに example.com と打ってエンターを押すと、コンマ何秒かの間に画面が切り替わる。この一瞬の裏で、ブラウザは example.com がどの IP アドレスかを誰かに教えてもらっている。誰に、どうやって聞いているのか、説明できるだろうか。
- TCP 接続には IP アドレスが要るので、名前解決（ドメイン名を IP に変換する処理）を毎回どこかで行っている
- いきなり世界中に問い合わせるのではなく、ブラウザ・OS・再帰的リゾルバの 3 段のキャッシュを順に確認し、どこにも無いときだけルート → TLD → 権威 DNS サーバーへの委任の連鎖をたどる
- 「DNS の変更が世界に浸透するのに時間がかかる」という現象の正体は、単一の伝播処理ではなく各リゾルバがそれぞれ TTL の間だけ古い答えをキャッシュし続けているだけである
そもそも、なぜ名前を番号に変換する必要があるのか
TCP で接続を張るには宛先の IP アドレスが要る。ドメイン名はそのままでは通信に使えない、人間のための別名にすぎない。この「名前 → IP アドレス」の変換を 名前解決と呼び、それを担う分散データベースの仕組みが DNS（Domain Name System）だ。
DNS が単一の巨大な台帳ではなく分散システムになっているのは、世界中のドメイン名を 1 か所のサーバーに集約すると、そのサーバーが落ちた瞬間にインターネット全体の名前解決が止まるからだ。責任を階層的に分割し、それぞれの階層が「自分の担当範囲だけ」を管理することで、単一障害点を避けている。
実はブラウザは、ほとんどの場合どこにも聞きに行かない
example.com を打つたびに世界のどこかへ問い合わせが飛んでいるように思えるかもしれない。しかし実際には、名前解決は毎回ネットワークの外まで問い合わせに行くわけではない。ブラウザ自身が直近の結果を持つブラウザキャッシュを最初に確認し、無ければ OS のスタブリゾルバ（自分では答えを持たず、設定された先へ問い合わせを転送するだけの軽量な解決クライアント）に聞く。スタブリゾルバも自前のキャッシュを見て、それでも無ければ ISP や自社で運用する再帰的リゾルバ（キャッシュ DNS サーバーとも呼ばれる）に問い合わせる。ここまでの 3 段階のどこかにキャッシュが残っていれば、外部への問い合わせは一切発生しない。
Chrome は OS のスタブリゾルバ（getaddrinfo()）経由で名前解決すると、権威サーバーが指定した TTL とは無関係に一律 60 秒だけキャッシュする。getaddrinfo() の戻り値には TTL の情報が含まれないため、Chrome 側で機械的に 60 秒という固定値を採用しているからだ。DNS レコードの TTL を 30 秒に設定しても、ブラウザは最低 60 秒はその結果を使い続ける。
大きな図書館で目当ての本を探す場面を思い浮かべてほしい。総合案内（ルートサーバー）は本の内容までは知らないが、「その分野の棚はあちらです」と担当フロア（TLD サーバー）を教えてくれる。フロアに着くと今度は「この本の担当司書はこの人です」と個別の担当者（権威 DNS サーバー）を紹介される。各案内係は答えそのものを知っているのではなく、次に誰へ聞けばいいかだけを知っている。ルートから TLD、権威サーバーへと続く DNS の階層は、この「委任のたらい回し」がそのまま実体になったものだ。
キャッシュに無ければ、委任の連鎖をたどる
3 段のキャッシュのどこにも答えが無いとき、再帰的リゾルバは自分の代わりに問い合わせを組み立て直し、階層を上から順にたどる。まずルートサーバー（DNS 階層の頂点にあたる、13 個の名前（a〜m.root-servers.net）に割り当てられた特別なサーバー群）に example.com を聞くと、「.com の担当はこちら」という TLD サーバーの情報だけが返る。次に TLD サーバーに聞くと、「example.com の担当はこちら」という権威 DNS サーバー（そのドメインの実際の IP アドレスを管理し、最終的な答えを持つサーバー）の情報が返る。最後に権威 DNS サーバーへ問い合わせて、ようやく IP アドレスそのものを受け取る。
stub resolver (OS)
│ 再帰的に問い合わせ
▼
recursive resolver
(再帰的リゾルバ／cache)
│
├▶ root NS 「.comはあちら」
├▶ TLD NS 「権威はあちら」
└▶ 権威 NS → IP を返す
ルートサーバーは 13 個の名前（IP アドレス）しか持たないが、実体は 1 台ずつではない。anycast（同じ IP アドレスを複数拠点に配り、経路上もっとも近い拠点へ自動的に振り分ける技術）によって、世界各地に分散した約 1,700〜1,900 台規模の物理サーバー群が同じ 13 個の名前の裏側で稼働している。1 台に集中させず地理的に散らすことで、特定拠点の障害や攻撃が全体停止に直結しない構造になっている。
答えが返ってきた後も、しばらくは同じ答えを使い回す
権威 DNS サーバーからの応答には TTL（Time To Live。そのレコードをキャッシュしてよい秒数）が付く。再帰的リゾルバはこの秒数が経過するまで、同じドメインへの問い合わせが来ても権威サーバーへは聞きに行かず、手元のキャッシュだけで答える。TTL を短くするほど変更の反映は速くなるが、その分キャッシュが効かず権威サーバーへの問い合わせ頻度が増えるという、両立しない関係にある。
存在しないドメインへの問い合わせ結果も同様にキャッシュされる。これをネガティブキャッシュと呼び、RFC 2308 で標準化されている。ネガティブキャッシュの有効期間には権威ゾーンの SOA レコードにある minimum フィールドの値が使われ、この間は「存在しない」という結果自体がキャッシュされて権威サーバーへの問い合わせが省略される。DNS レコードを追加した直後に一部の環境だけ反映が遅れるのは、追加前の「存在しない」という答えがまだキャッシュに残っているケースがあるからだ。
CDN の切り替えや DB のフェイルオーバーで DNS レコードを変更したのに、一部のユーザーだけ旧サーバーに繋がり続ける現象はこの仕組みで説明できる。切り替え前のレコードの TTL がまだ残っている再帰的リゾルバや、Chrome の 60 秒キャッシュ、あるいは OS 自体のキャッシュのいずれかに古い答えが残っているだけで、「世界に伝播するのを待つ」ような単一の処理が進行しているわけではない。切り替えを急ぐ計画があるなら、事前に TTL を短く設定しておくことで、この待ち時間の上限を事前にコントロールできる。
dig +trace で、ルート → TLD → 権威という委任の連鎖を実際のクエリで観察する。キャッシュを経由せず、階層を 1 段ずつ自分でたどってくれるオプションだ。
dig +trace example.com
出力を上から見ると、まず .（ルート）への問い合わせに対して 13 個のルートサーバーの一覧が返り、次に com. の TLD サーバー一覧、最後に example.com の権威サーバーからの A レコード（実際の IP アドレス）という順で、記事中で説明した委任の連鎖がそのままログとして流れてくるのが分かるはずだ。
- DNS の変更が世界中に「浸透」するには決まった時間がかかる — 一元的に伝播していく処理は存在しない。実際には各リゾルバがそれぞれ独立に、古いレコードの TTL が切れるまで自分のキャッシュを使い続けているだけで、キャッシュが残っている環境ほど反映が遅く見える。
- ルートサーバーは世界に 13 台しかない — 13 はサーバーの「名前（IP アドレス）」の数であって、その裏では anycast によって約 1,700〜1,900 台規模の物理サーバーが世界中に分散して稼働している。
- ルートサーバーや TLD サーバーは、ドメインの IP アドレスを知っている — 実際に IP アドレスを持っているのは権威 DNS サーバーだけで、ルート・TLD の各サーバーは「次にどこへ聞けばいいか」という委任先の情報しか返さない。
- スタブリゾルバ
- OS に組み込まれた軽量な名前解決クライアント。自分ではキャッシュ以外の答えを持たず、再帰的リゾルバへ問い合わせを転送する。
- 再帰的リゾルバ
- クライアントの代わりにルート → TLD → 権威と問い合わせをたどり、最終的な答えをキャッシュして返すサーバー。キャッシュ DNS サーバーとも呼ぶ。
- ルートサーバー
- DNS 階層の頂点にある 13 個の名前に割り当てられたサーバー群。実体は anycast で分散した多数の物理サーバー。
- 権威 DNS サーバー
- 特定のドメインについて実際の IP アドレスなどのレコードを保持し、最終的な答えを返すサーバー。
- TTL
- DNS レコードをキャッシュしてよい秒数。権威サーバーが応答に付けて指定する。
- ネガティブキャッシュ
- 「存在しない」という否定的な問い合わせ結果自体をキャッシュする仕組み。RFC 2308 で標準化。
- What is DNS? | Cloudflare — 再帰的リゾルバ・ルート・TLD・権威の 4 種のサーバーがどう連携するかを図解している。
- DNS Root Server | Cloudflare — 13 個のルートサーバーの名前と、その裏にある anycast 構成の解説。
- RFC 2308: Negative Caching of DNS Queries — ネガティブキャッシュの TTL に SOA の minimum フィールドを使う仕様の一次情報。
- Chromium's DNS Cache — Chrome が
getaddrinfo()経由の解決結果を TTL 無視で 60 秒キャッシュする挙動の解説。