DNS名前解決の全プロセス — ブラウザーからルートサーバーまで何ホップ？

1. 全8ステップの流れ

┌─────────────────────────────────────────────────────────────┐
│  ブラウザー（Chrome / Firefox）でgoogle.comと入力           │
└────────────────┬────────────────────────────────────────────┘
                 │ ① ブラウザーのDNSキャッシュ（Chromeは約60秒）
                 ↓ キャッシュミス
┌─────────────────────────────────────────────────────────────┐
│  OSのスタブリゾルバー + システムのDNSキャッシュ             │
└────────────────┬────────────────────────────────────────────┘
                 │ ② システムのキャッシュにない → ルーターへUDPで問い合わせ
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  家庭用ルーターのDNS転送 + ルーターのキャッシュ             │
└────────────────┬────────────────────────────────────────────┘
                 │ ③ ルーターのキャッシュにない → ISPの再帰リゾルバーへ転送
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ISP / パブリックDNSの再帰リゾルバー                        │
│  （1.1.1.1 / 8.8.8.8 / 223.5.5.5）                          │
│  キャッシュヒット：そのまま返答（全体で1〜5ms）             │
│  キャッシュミス：下の「完全な検索」の流れへ                 │
└────────────────┬────────────────────────────────────────────┘
                 │ ④ ルートNSに「google.comはどこ？」と問い合わせ
                 ↓
        13組のルートネームサーバー（a〜m.root-servers.net）
                 │ ⑤ 返答「知らない。.comのNS（a.gtld-servers.net）に聞いて」
                 ↓
        .com TLDの権威DNSサーバー（Verisign）
                 │ ⑥ 返答「こちらも全部は持っていない。google.comのNS（ns1.google.com）に聞いて」
                 ↓
        google.comの権威DNSサーバー（Google自身が運用）
                 │ ⑦ 返答「google.comのAレコード = 142.250.x.x」
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ⑧ 再帰リゾルバーが回答を（TTLに従って）キャッシュし、      │
│     クライアントに返す — 途中の各層も                       │
│     それぞれコピーをキャッシュする                          │
└─────────────────────────────────────────────────────────────┘

重要なポイント：実際の利用場面では、8ステップすべてを通ることはほとんどありません。主要サイトのIPアドレスはほぼ常に再帰リゾルバーのキャッシュにあるため、一般のユーザーはステップ④の時点で応答を受け取ります。完全な流れが発生するのは、マイナーなドメイン、長い間アクセスされていないサイト、TTLが切れた場合、新規登録されたドメインだけです。

2. DNSキャッシュの5つの層を解説

DNSが1983年に設計された時点で、すでにある事実が考慮されていました。それは問い合わせの回数は変更の10万倍にのぼるということです。そのため、キャッシュはあらゆる場所にあり、各層がTTL（Time To Live）の期間だけデータを保持します。

3. 再帰問い合わせと反復問い合わせ — 重要な概念

3.1 再帰問い合わせ（Recursive）

クライアント（ブラウザー / OSのスタブ）は、ISPの再帰リゾルバーにこう伝えます：「google.comのIPを調べてきて。途中のやり方は問わない」。再帰リゾルバーは検索全体を完了し、最終的な結果を返さなければなりません。

3.2 反復問い合わせ（Iterative）

再帰リゾルバーがルート、TLD、権威DNSサーバーとやり取りするときは反復です。ルートに尋ねるとルートは「.comに聞いて」と答え、.comに尋ねると.comは「googleに聞いて」と答え、そこでgoogleに尋ねます。各ステップは1段階ずつしか進まず、「ルートに尋ねれば、ルートがすべて代わりにやってくれる」というわけではありません。

4. 自分で試してみる — dig +trace

dig +traceを使うと、完全な反復検索を強制的に実行し、各ステップを表示できます：

$ dig +trace cleanip.io

; <<>> DiG 9.10.6 <<>> +trace cleanip.io
;; global options: +cmd

; ① 1ホップ目 — ルート（.）に問い合わせ
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
... （ルートのNSレコード13件）
;; Received 525 bytes from 127.0.0.53#53 in 5 ms

; ② 2ホップ目 — .io TLDに問い合わせ
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      b0.nic.io.
... （.ioのNS 4件）
;; Received 822 bytes from 198.41.0.4#53(a.root-servers.net) in 121 ms

; ③ 3ホップ目 — cleanip.ioの権威DNSサーバーに問い合わせ
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 109 bytes from 156.154.150.6#53(a0.nic.io) in 53 ms

; ④ ようやく回答を取得
cleanip.io.             300     IN      A       104.21.x.x
cleanip.io.             300     IN      A       172.67.x.x
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 154 bytes from 173.245.59.108#53(nolan.ns.cloudflare.com) in 12 ms

読み解くと：

• 全体で5 + 121 + 53 + 12 = 191msかかっており、初回のコールドな検索はやはり遅いことが分かります
• しかし、1秒後に同じドメインをもう一度問い合わせると1〜2msしかかかりません。ISPの再帰リゾルバーのキャッシュにすでに入っているためです（TTLは300秒）
• 104.21.x.x / 172.67.x.xはCloudflare CDNのアドレスで、当サイトの実際のオリジンIPはCDNの背後に隠されています

5. TTLを詳しく解説 — キャッシュは実際どれくらい続くのか

TTL（Time To Live）は、権威DNSサーバーがすべての再帰リゾルバーに「最大でこの時間までキャッシュしてよい」と伝えるフィールドで、単位は秒です。

注意：TTLは「最大キャッシュ時間」です。各リゾルバーは早めにキャッシュを削除できますが、延長することはできません。そのため、権威側のTTLが1時間でも、10分ほどで再度問い合わせるリゾルバーもあります。

落とし穴：IPを切り替える前に、まずTTLを短く（1〜5分）しておき、古いTTLが完全に切れるのを待ってから切り替えてください。そうしないと、一部のユーザーが1時間以上も古いIPにアクセスし続けることになります。

6. DNSレコードの種類早見表

7. DNSの最適化 — 名前解決を速くする方法

7.1 近くの再帰リゾルバーを選ぶ

中国本土：223.5.5.5（Alibaba）/ 119.29.29.29（DNSPod）が国内サイトの名前解決で最も高速です。それ以外の地域：1.1.1.1（Cloudflare、エニーキャストのカバー範囲が最も広い）/ 8.8.8.8（Google）。詳しくは次のページをご覧ください：パブリックDNSリゾルバー一覧.

7.2 DoH（DNS-over-HTTPS）を有効にする

DNSクエリをHTTPSで暗号化すると、ISPによる盗み見や改ざんを防げます（NXDOMAINハイジャックも防止）。Chrome、Firefox、Edgeはいずれも対応しており、設定で有効にするだけです。

7.3 事前にウォームアップする（DNS Prefetch）

サイトの<head>に<link rel="dns-prefetch" href="//api.example.com">を追加すると、ブラウザーがアイドル時に事前に名前解決しておくため、実際のリクエスト時にはキャッシュヒットになります。

7.4 CDN + エニーキャストNSを使う

権威NSをエニーキャスト（Cloudflare / Route 53）で運用すると、世界中のユーザーが最寄りのインスタンスに問い合わせるようになり、ステップ③の遅延を100msから10msまで短縮できます。

7.5 TTLを適切に設定する

めったに変更しないレコード（NS / MX）には長いTTL（1〜7日）を、切り替える可能性のあるAレコードには短いTTL（5〜60分）を設定します。

8. よくある質問

8.1 DNSを変更したのに反映されないのはなぜ？

まず、現在のTTLがどれくらいかを考えてみてください。DNSを変更しても、古いTTLが切れるまでは、すべての再帰リゾルバーが古いIPを返し続けます。「全世界への反映」には、一般にTTLの約2倍の時間がかかります（リゾルバー同士の同期のずれを考慮するため）。

• クライアント：ipconfig /flushdns（Windows）/ sudo killall -HUP mDNSResponder（macOS）
• パブリック再帰リゾルバーのキャッシュが切れるのを待つ：1.1.1.1 / 8.8.8.8にはそれぞれ専用の「purge」ツールがあり、手動でクリアすることもできます

8.2 アクセスできるユーザーとできないユーザーがいる — DNSポイズニング

中国本土から海外のサイトにアクセスするときによく起こります — GFWによる偽のDNS応答の注入や、ISPによる問い合わせのハイジャックが原因です。DoH（ブラウザーの暗号化DNS）に切り替えると、ほとんどのDNSポイズニングを回避できます。

8.3 ドメインを登録してから、どれくらいで使えるようになる？

登録後、TLDのレジストリがNSレコードを.com / .netなどのトップレベルの権威DNSサーバーに反映します。所要時間は通常15分〜24時間です。.cn / .com.cnのドメインは、中国本土で名前解決できるようになるまでにICP登録が必要な場合があります。