DNS の名前解決内部とキャッシュ階層

名前空間は木構造、答えは1か所にしかない

DNS の名前空間は根（ルート）を頂点とする木です。www.example.com. は右から読み、ルート → com → example → www と階層を下ります。重要なのは、ある名前に対する権威ある答えを持つのは木の特定の枝を委任された権威サーバーだけで、ルートや TLD は答えそのものを持たないという点です。ルートは「com の担当はここ」、com は「example.com の担当はここ」と次の行き先（委任）を教えるだけです。

この分散構造ゆえに、1台で世界中の名前を抱える必要がなく、各組織が自分のゾーンだけを管理できます。代償として、未知の名前は複数段の問い合わせを要します。それを肩代わりするのが DNS の基本記事 で触れたフルサービスリゾルバ（キャッシュ DNS）です。

再帰問い合わせと反復問い合わせは別物

混同しやすい2語を厳密に分けます。

端末（スタブリゾルバ）は「答えだけ欲しい」とリゾルバに再帰を依頼します。依頼を受けたリゾルバは、ルートから権威まで反復で聞いて回り、まとめた答えを返します。権威サーバーは通常、再帰要求（RD=1）が来ても再帰せず、自分の知る範囲だけを返します。この役割分担を取り違えると、後述の dig +trace の各行の意味を読み違えます。

反復問い合わせの実際の道筋

www.example.com を未キャッシュ状態から解決する手順を擬似コードで示します。リゾルバは最も深く一致するキャッシュ済みネームサーバーから開始し、なければルートヒント（ルート13系統の住所を焼き込んだ初期データ）から始めます。

resolve(name = "www.example.com", type = A):
  ns_list = ルートサーバー群        # 既知の出発点
  loop:
    server = ns_list から1台選ぶ    # RTT等で選択
    resp   = query(server, name, A, RD=0)
    if resp に Answer(A) がある:
      return Answer                  # 権威が答えを返した→完了
    elif resp に Authority(NS) がある:
      ns_list = resp の NS が指すサーバー群   # 一段深い委任へ
      # 可能なら Additional 内のグルー(A/AAAA)を使う
      continue
    else:
      return 失敗（NXDOMAIN 等）

ルートに聞くと Answer は空で、Authority セクションに com の NS が並び、Additional セクションにそれらの IP（グルー）が入った委任応答（referral） が返ります。リゾルバはその NS へ進み、com サーバーが今度は example.com の NS を委任で返し、最後に example.com の権威が www の A レコードを Answer で返して終了します。各段で「答え」か「次の委任」かを見分けるのが解決ループの核心です。

委任とグルーレコード：鶏卵問題を断つ

委任は親ゾーンに置かれた NS レコードで表現されます。com ゾーンには次のような委任が記録されています。

example.com.   NS   ns1.example.com.
example.com.   NS   ns2.example.com.

ここで循環が生じます。example.com の権威サーバーの名前が ns1.example.com 自身であるため、その IP を知るには example.com を解決せねばならず、それには ns1.example.com の IP が要る——という無限後退です。これを断ち切るのがグルーレコードです。親（com）は委任応答の Additional セクションに、委任先 NS の A/AAAA をゾーン外なのに例外的に同梱します。

グルーはあくまで親が持つヒントで、権威データではありません。委任先ゾーンが自分で持つ NS/A（権威データ）と食い違うと「lame delegation（不整合委任）」となり、断続的な解決失敗の温床になります。

キャッシュと TTL：肯定も否定もキャッシュする

リゾルバは得た各レコードを、そのレコードに付いた TTL（秒） の間だけ保持します。ここで効くのは、解決の途中で得た委任（NS とグルー）も TTL の間キャッシュされる点です。だから2回目以降の example.com 配下の解決は、ルートや com を飛ばして example.com の権威から始められます。キャッシュは木の浅い部分ほど共有・再利用されやすく、ルートや TLD への実トラフィックは見かけの問い合わせ数より桁違いに少なくなります。これは CDN のエッジキャッシュ と同じ「上流ほど集約が効く」構造です。

否定応答（存在しない名前 = NXDOMAIN や、名前はあるが該当型が無い = NODATA）もネガティブキャッシュされます。鍵は権威が返す SOA レコードの MINIMUM フィールドです。

; 否定応答に同梱される SOA（抜粋）
example.com.  SOA  ns1.example.com. admin.example.com. (
                    2026062101   ; serial
                    7200         ; refresh
                    3600         ; retry
                    1209600      ; expire
                    300 )        ; minimum ← ネガティブキャッシュTTL

否定キャッシュの保持時間は、レスポンスの TTL と SOA MINIMUM の小さいほうになります（RFC 2308）。これにより、存在しない名前への連打が権威へ素通りせず、攻撃的なスペル誤りやループするクライアントから権威サーバーを守ります。逆に、消したばかりのレコードがしばらく「無い」と返り続けるのもこの仕組みのためです。

一段で言うと

DNS 解決は「各段は委任しか返さず、答えは権威だけが持つ」反復問い合わせと、「肯定は TTL、否定は SOA MINIMUM でキャッシュする」二層のキャッシュ、そして「循環をグルーで断つ」委任設計、この3点で成り立ちます。挙動の裏取りには dig +trace（ルートから委任を1段ずつ辿る）と dig +norecurse（権威に直接聞いて再帰を介さない）を使い分け、どの段で委任が返り、どの TTL でキャッシュされたかを必ず確認してください。詰まったときの層別の切り分けは ネットワークの切り分け の手順に乗せると、名前解決とその先の到達性を分離して追えます。