DNSの名前解決は、「端末のキャッシュ → フルサービスリゾルバー（キャッシュDNS） → ルート → TLD → 権威DNS」という順番で、手前から答えを探していく仕組みです。この記事では、ブラウザにURLを入力してからIPアドレスが返ってくるまでの流れを一段ずつ説明し、各段階を dig などのコマンドで自分の目で確かめる方法まで紹介します。サーバー移転後に「自分だけ古いサイトが見える」といった現象の理由も、この流れを知ると説明できるようになります。
なお、権威DNSとキャッシュDNSの役割の違いそのものに焦点を当てた解説は別記事にあります。この記事は「問い合わせが実際にどこを通るか」を順に追うことに重点を置いています。
名前解決に登場する4つの役者
最初に、登場する要素を整理します。
- スタブリゾルバー: OSに組み込まれた問い合わせ係です。アプリから頼まれた名前を、設定されたDNSサーバーに問い合わせるだけで、自分では答えを探し回りません。
- フルサービスリゾルバー（キャッシュDNS）: プロバイダーや社内、または 8.8.8.8 や 1.1.1.1 のようなパブリックDNSが提供するサーバーです。答えを知らなければ、ルートから順にたどって答えを探し、得た結果を一定時間キャッシュします。
- ルートサーバー・TLDサーバー: ルートは「.com はこのサーバーに聞いて」、TLDは「example.com はこのサーバーに聞いて」と、次の問い合わせ先を教えます（これを委任と呼びます）。
- 権威DNSサーバー: そのドメインのレコードを実際に持っているサーバーです。お名前.comやCloudflare、Route 53などのDNS管理画面で設定した内容は、ここから返されます。
名前解決の流れを順番に追う
www.example.com にアクセスする場合を例に、流れを追います。
ステップ1: 端末内で答えを探す
ブラウザは、まず自分の持つDNSキャッシュを確認します。次にOSのキャッシュと hosts ファイルが参照されます。hosts ファイルに書かれた名前はDNSに問い合わせずに解決されるため、移転作業中に書いたまま消し忘れると、いつまでも古いサーバーを見続ける原因になります。
ステップ2: フルサービスリゾルバーに問い合わせる
端末内に答えがなければ、スタブリゾルバーが設定されたDNSサーバーに問い合わせます。このとき「代わりに最後まで調べてください」という意味の再帰問い合わせ（RDフラグつき）を送ります。リゾルバーのキャッシュに答えがあれば、ここで即座に返されます。多くの問い合わせはこの段階で完結します。
ステップ3: ルートからTLD、権威DNSへとたどる
キャッシュに答えがない場合、リゾルバーは次のように順番に問い合わせます。
- ルートサーバーに
www.example.comを聞くと、「.com を担当するサーバーはこちら」という委任情報が返ります。 - .com のTLDサーバーに聞くと、「example.com の権威DNSはこちら」という NS レコードが返ります。
- example.com の権威DNSに聞くと、
www.example.comの A レコード（IPアドレス）が返ります。
リゾルバーが自分でたどるこの問い合わせを、反復問い合わせと呼びます。ルートサーバーの名前は a〜m の13個ですが、それぞれがエニーキャストで世界中に多数配置されており、実際のサーバー台数はそれよりずっと多くなっています。
ステップ4: 結果をキャッシュして端末に返す
リゾルバーは得た答えを、レコードに設定された TTL（秒数）のあいだキャッシュし、端末に返します。端末側のOSやブラウザも同様にキャッシュします。存在しない名前（NXDOMAIN）の結果もキャッシュされ、その保持時間はゾーンの SOA レコードの値をもとに決まります（ネガティブキャッシュ）。
各段階をコマンドで確かめる
端末が使っているDNSサーバーを確認する
# Linux（systemd-resolved を使っている場合）
resolvectl status
# Windows（PowerShell）
Get-DnsClientServerAddress
# macOS
scutil --dns | grep nameserversystemd-resolved が動いているLinuxでは、/etc/resolv.conf に 127.0.0.53 と書かれていることがあります。これはローカルのスタブリゾルバーで、実際の上流サーバーは resolvectl status で確認できます。
リゾルバー経由の答えとTTLを見る
dig www.example.com A
dig @8.8.8.8 www.example.com A出力の ANSWER SECTION の2列目の数字が TTL です。キャッシュから返された答えなら、時間をおいて実行するとこの数字が減っていきます。flags: 欄に ra（再帰可能）があれば、問い合わせ先がフルサービスリゾルバーであることが分かります。
権威DNSに直接聞く
dig example.com NS +short
dig @ns1.example-dns.net www.example.com A2行目の ns1.example-dns.net は、1行目で得たNSのホスト名に置き換えてください。権威DNSからの答えには flags: に aa（権威ある応答）が付きます。管理画面で変更した値がここで返っていれば、設定そのものは反映済みで、残りはキャッシュの問題だと判断できます。
ルートから順にたどる様子を見る
dig +trace www.example.com A+trace を付けると、dig 自身がルートから順に問い合わせ、各段階の応答を表示します。ルート、TLD、権威DNSの順に NS レコードが表示され、最後に A レコードが返れば、委任は正しく機能しています。途中で止まる場合は、その段階の NS 設定（レジストラ側のネームサーバー登録など）を疑います。
Windows では Resolve-DnsName www.example.com -Server 8.8.8.8 のように、問い合わせ先を指定して比較できます。
サーバー移転で「人によって見え方が違う」理由
名前解決の流れを踏まえると、移転直後に見え方が分かれる理由は次のように整理できます。
- リゾルバーのキャッシュ: 変更前の A レコードが、TTLが切れるまで各リゾルバーに残ります。使っているリゾルバーが違えば、切り替わるタイミングも違います。
- 端末やブラウザのキャッシュ: リゾルバーが新しい値を持っていても、端末側に古い値が残っていることがあります。
- hosts ファイル: 作業用に書いた行が残っていると、DNSの変更が一切反映されません。
- ネームサーバー自体の変更: レジストラでネームサーバーを変える場合は、TLD側の NS 情報が更新され、それがキャッシュから切れるまで時間がかかります。
対策の基本は、変更の前に TTL を短くしておくことです。現在の TTL の秒数以上前に短い値へ下げておけば、切り替え時に古い値が残る時間を短くできます。
ブラウザ独自のDNS（DoH）に注意する
最近のブラウザは、OSの設定とは別に DNS over HTTPS（DoH）で独自のリゾルバーを使う設定を持っており、主要ブラウザの多くが対応しています（2026年10月現在）。この場合、OSで dig した結果とブラウザの見え方が一致しないことがあります。調査中は、ブラウザの「セキュア DNS」関連の設定がどうなっているかも確認してください。設定項目の名前はブラウザやバージョンによって異なります。
まとめ
- 名前解決は、端末内のキャッシュ、フルサービスリゾルバー、ルート、TLD、権威DNSの順に答えを探す仕組みです。
- 多くの問い合わせはリゾルバーのキャッシュで完結し、その保持時間は TTL で決まります。存在しない名前の結果もキャッシュされます。
digのraとaaフラグ、@サーバー指定、+traceを使うと、どの段階で何が返っているかを切り分けられます。- 移転時の見え方の違いは、キャッシュ、hosts ファイル、ブラウザのDoHのいずれかが原因であることがほとんどです。