DNS の仕組みを図解：再帰的な名前解決、キャッシュ、TTL

A レコードを変更し、dig を実行すると、新しいアドレスが見えます。ところが別のオフィスの同僚には、1 時間たっても古いアドレスが返ってきます。新しいサブドメインは自分の環境では動くのに、顧客には NXDOMAIN が返ります。どれも偶然ではありません。DNS の名前解決とキャッシュの仕組みから生じることであり、問い合わせがたどる経路を描けるようになれば予測できます。

この記事では、1 回の問い合わせをブラウザーから権威サーバーまで往復で追い、図とともに説明します。続いて、TTL、ネガティブキャッシュ、委任、トランスポート、本番環境で出会う障害のパターンを扱います。

すべての問い合わせに登場する 4 つの役割

1 回の問い合わせは、最大 4 種類のサーバーを経由します。それぞれが答えの別の部分を知っています。

ルートは 1 台のマシンではありません。2026 年 11 月時点の root-servers.org によると、ルートサーバーの識別子は a から m.root-servers.net までの 13 個あり、12 の独立した組織が運用しています。そしてエニーキャストによって、世界中の 2,000 を超えるインスタンスに分散されています。

問い合わせを順に追う

ブラウザーが app.example.com を必要としていて、どこにも何もキャッシュされていないとします。

1. ブラウザーは自身のキャッシュを確認し、次に OS のスタブリゾルバーに問い合わせます。
2. スタブは、「recursion desired」フラグを付けた問い合わせを、設定されている再帰リゾルバーに送ります。app.example.com の A レコードは何か、という問い合わせです。
3. リゾルバーには何もキャッシュされていないので、ルートサーバーに問い合わせます。ルートは答えを知りませんが、com を誰が運用しているかは知っているので、委任応答（リフェラル）を返します。com の NS レコードとそのアドレス（グルー）です。
4. リゾルバーは com の TLD サーバーに問い合わせ、別の委任応答を受け取ります。example.com のネームサーバーです。
5. リゾルバーはそれらの権威サーバーの 1 つに問い合わせ、答えを受け取ります。app.example.com. 300 IN A 203.0.113.10 です。
6. リゾルバーは、知ったレコードをすべて TTL の間キャッシュし、答えをスタブに返します。スタブはそれをブラウザーに渡します。

スタブが行うのは再帰問い合わせで、最終的な答えを求めます。リゾルバーが行うのは反復問い合わせで、各サーバーは答えそのものか、答えにより近い相手への指示のどちらかを返します。ルートサーバーや TLD サーバーが、あなたの代わりに答えを探しに行くことはありません。

反復の部分は、リゾルバーのキャッシュを使わずにルートから始める dig +trace で観察できます（出力は一部省略しています）。

$ dig +trace app.example.com
.                  518400  IN  NS  a.root-servers.net.
com.               172800  IN  NS  a.gtld-servers.net.
example.com.       172800  IN  NS  ns1.example.net.
app.example.com.   300     IN  A   203.0.113.10

最近のリゾルバーは QNAME ミニマイゼーション（RFC 9156）も適用します。ルートには com についてだけ、TLD には example.com についてだけ問い合わせるので、上位のサーバーは問い合わせた完全な名前を知ることがありません。

キャッシュと TTL

すべてのレコードは、秒単位の有効期間（TTL）を持っています。app.example.com を TTL 300 でキャッシュしたリゾルバーは、カウントダウンしながら次の 5 分間はキャッシュから応答し、その後で初めて権威サーバーに再び問い合わせます。ブラウザーと OS も、その上にそれぞれ短いキャッシュを持っています。

これが、いわゆる浸透（プロパゲーション）の正体です。レコードを変更しても、どこにも何も送られません。古い値をキャッシュした各リゾルバーは、自分のコピーが期限切れになるまでそれを返し続けます。したがって最悪の場合にかかる時間は、新しい TTL ではなく、おおむね古い TTL です。リゾルバーは非常に長い TTL を切り詰めることもあります。たとえば Unbound は、既定でキャッシュするレコードの上限を 1 日にしています。

変更のための実践的なルールは次のとおりです。

• 計画的な変更の前に TTL を下げます。 TTL が 86400 のレコードなら、移行の少なくとも 1 日前に 300 に下げ、古い TTL が過ぎるのを待ってから変更し、その後で元に戻します。
• 短い TTL は、素早いフェイルオーバーが必要な場所だけに使います。 TTL 60 秒にすると、プロバイダーへの問い合わせが増え、ユーザーのキャッシュミスも増えます。キャッシュミスのたびに完全な名前解決のコストがかかります。
• ネームサーバーの変更はもっと時間がかかります。 親ゾーンにある example.com の NS レコードには独自の TTL があり、com では 172800 秒（2 日）で、これは短縮できません。

DNS ベースのフェイルオーバーは、これらの数字に左右されます。ヘルスチェック付きの DNS レコードがどこに位置し、その TTL がなぜ復旧時間の上限を決めるのかは、AWS マルチリージョンアーキテクチャ図とディザスタリカバリのアーキテクチャ図で示しています。

ネガティブキャッシュ：NXDOMAIN の落とし穴

リゾルバーは「存在しない」という応答もキャッシュします。名前が存在しない場合、権威サーバーはゾーンの SOA レコードとともに NXDOMAIN を返し、リゾルバーはその否定応答を、SOA レコードの TTL と MINIMUM フィールドの小さいほうの時間だけキャッシュします（RFC 2308）。

典型的な障害はこうです。レコードが作られる前に誰かが api.example.com を問い合わせ、リゾルバーが NXDOMAIN を 1 時間キャッシュします。その後レコードを作成しても、そのリゾルバーは 1 時間が過ぎるまで「存在しない」と答え続けます。新しいホスト名を公表する前に dig example.com SOA でネガティブ TTL を確認し、誰かが試す前にレコードを作成しておきましょう。

委任、グルー、レイムサーバー

ゾーンが DNS に存在するのは、親ゾーンがそのゾーンに委任しているからです。com ゾーンには、example.com についてどのサーバーが権威を持つかを示す NS レコードがあります。それらのネームサーバーが、ns1.example.com のように自分が担当するゾーンの中にある場合、親ゾーンはそのアドレスもグルーレコードとして保持します。そうしないと、リゾルバーはネームサーバーを見つけられないからです。

委任がよく壊れるパターンは 2 つあります。1 つはレイムデリゲーションで、親ゾーンが、もうそのゾーンを担当していないサーバーを指している状態です。プロバイダーの移行後によく起こり、一部のユーザーでタイムアウトや SERVFAIL を引き起こします。もう 1 つは、親ゾーンの NS レコードとゾーン内の NS レコードが食い違っている状態で、リゾルバーがたまたまどちらをキャッシュしたかによって挙動が変わります。

トランスポートとプライバシー

DNS トラフィックの大半は、ポート 53 の UDP です。収まりきらない応答には切り詰め（truncation）フラグが立ち、クライアントは TCP で再試行するため、TCP のポート 53 も開けておく必要があります。DNS Flag Day 2020 以降、主要な DNS ソフトウェアは IP フラグメンテーションを避けるため、既定で 1,232 バイトの EDNS バッファサイズを使っています。そのため、DNSSEC 署名付きレコードのような大きな応答では、TCP へのフォールバックがより一般的になっています。

従来の DNS は暗号化されていません。DNS over TLS（ポート 853）、DNS over HTTPS、DNS over QUIC は、スタブと再帰リゾルバーの間の区間を暗号化しますが、リゾルバーからルート、TLD、権威サーバーへの区間は、今もほとんどが平文です。

DNSSEC が解決するのは別の問題で、プライバシーではなく真正性です。各ゾーンは自分のレコードに署名し、親ゾーンが子ゾーンの鍵を保証します。これが、検証を行うリゾルバーが信頼するルートの鍵まで続きます。2026 年 10 月 11 日、ルートゾーンは新しい鍵署名鍵 KSK-2024 へのロールオーバーを完了しました。新しいトラストアンカーを取り込んでいない検証リゾルバーは、すべての問い合わせで SERVFAIL を返して失敗します。

問い合わせが失敗するとき

dig @ns1.example.net app.example.com で権威サーバーに直接問い合わせれば、何が真実かが分かります。リゾルバーに問い合わせれば、ユーザーが何を見ているかが分かります。

DNS の名前解決の図

図の読み方は次のとおりです。

• ノート PC から始めます。 そのスタブリゾルバーはリゾルバーに再帰問い合わせを 1 回送り（ステップ 1）、応答を 1 回受け取ります（ステップ 8）。
• 階層をたどるのはリゾルバーです。 ステップ 2〜7 は反復問い合わせで、ルートと com のサーバーは委任応答を返し、example.com の権威サーバーがレコードを返します。
• TTL は応答に付いています。 A レコードは TTL 300 秒で返ってきます。これが、リゾルバーが再び問い合わせずにそれを使い回す時間です。
• フレームは、自分では運用しない階層をまとめています。 ただし権威サーバーだけは、自分か DNS プロバイダーのものです。
• Markdown ブロックには、キャッシュの層と、変更がユーザーに届く速さを決める TTL をまとめています。

本当の疑問に答える DNS の図を描くには

• ステップに番号を付けます。 DNS の疑問は順序に関するものです。誰が誰に問い合わせ、いつ代わりにキャッシュが答えるのか、です。
• 再帰のトラフィックと反復のトラフィックを分けます。 クライアントからは 1 回、リゾルバーからは複数回の問い合わせです。両者が同じに見えると、図は最も重要な考え方を隠してしまいます。
• 応答に TTL を書きます。 TTL は、段落で説明するよりうまくプロパゲーションを説明してくれます。
• 所有者を示します。 自分が管理しているサーバーに印を付けましょう。インシデントのとき、誰に連絡するかがそれで決まります。
• レコードの変更は別の図にします。 TTL を下げ、切り替え、TTL を戻すという移行のタイムラインのほうが、名前解決の図に注釈を付けるよりも分かりやすくなります。

メッセージの順序が要点なら、リゾルバーと各サーバーをライフラインにしたシーケンス図も使えます。リゾルバーがネットワークのどこにあるかという物理的な側面については、ネットワークトポロジ図のガイドを参照してください。

Archboard で作る

1. Google または GitHub でサインインし、図を作成します。
2. ノート PC 用にネットワークパックの デバイス ノードを、再帰リゾルバー用に DNS ノードを追加します。
3. DNS 階層を表す名前を付けた基本パックの フレーム を追加し、その中にさらに 3 つの DNS ノードを置きます。ルート、com の TLD、example.com の権威サーバーです。
4. 名前解決のあとにブラウザーが接続するホスト app.example.com 用に、ネットワークパックの サーバー ノードを追加します。
5. エッジを順に描き、ラベルに番号を付けます。クライアントの問い合わせと応答、続いてリゾルバーと各サーバーの間の問い合わせと応答です。最後の応答に TTL を書きます。
6. キャッシュの層と TTL のルールを書いた基本パックの Markdown ブロックを追加します。

この例で使うダイアグラムノードは 8 個で、Free プランの範囲に収まります。

よくある質問

DNS の浸透にはどれくらい時間がかかりますか？ 古いレコードをキャッシュした各リゾルバーで、最大で古いレコードの TTL の分だけかかります。何かが送られるのではなく、キャッシュが期限切れになるのです。ネームサーバーの変更はさらに時間がかかります。親ゾーンの NS レコードには独自の TTL があり、com では 2 日だからです。

再帰 DNS サーバーと権威 DNS サーバーの違いは何ですか？ 再帰リゾルバーは、クライアントに代わって答えを探し、キャッシュします。権威サーバーは、あるゾーンのレコードを保持し、そのゾーンについてだけ答えます。

レコードを変更したのに、古い IP アドレスが見えるのはなぜですか？ 自分と権威サーバーの間にあるキャッシュが、まだ古いレコードを保持しているからです。ブラウザー、OS、リゾルバーのいずれかです。権威サーバーに直接問い合わせて変更を確認し、TTL が切れるのを待ってください。

TTL が非常に短いと問題がありますか？ DNS プロバイダーへの問い合わせと、ユーザーの完全な名前解決が増え、キャッシュミス時のレイテンシーが増します。フェイルオーバーが必要になりうるレコードには短い TTL を、安定したレコードには長めの TTL を使ってください。

DNS のトラフィックは暗号化されていますか？ 既定では暗号化されていません。DNS over TLS、HTTPS、QUIC は、端末とリゾルバーの間の区間を暗号化します。DNSSEC はレコードが本物であることを証明する署名を加えますが、何も暗号化しません。

無料で始める — 1 シート、クレジットカード不要。