権威 DNS とゾーン転送・委任の仕組み

ゾーンと委任：木をどこで切るか

DNS の名前空間はルートを頂点とする木ですが、その木を実際に管理する単位はゾーンです。ゾーンとは「ある名前を起点に、子へ委任した境界の手前までの連続した範囲」を指します。example.com. ゾーンは example.com 自身と www.example.com などを含みますが、dev.example.com を別管理にしたければ、そこに**委任の切れ目（カット）**を入れて子ゾーンを作ります。木のどこに切れ目を入れるかが、そのまま「誰がどの範囲の権威か」を決めます。

委任の起点や名前解決の全体像は DNS の名前解決内部 で扱った反復問い合わせと対になります。本記事は「答えを持つ側」、すなわち権威サーバー・ゾーン・委任・転送の内部に踏み込みます。

委任はNSレコード、起動の鶏卵問題はグルーで断つ

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

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

この NS は「example.com の担当はこのサーバー群だ」という指し示しにすぎず、答えそのもの（A レコード等）は委任先の権威だけが持ちます。各段は次の行き先を返すだけ、という構造がルートから末端まで連鎖します。

ここで循環が生じます。委任先 NS の名前 ns1.example.com を解決するには example.com ゾーンに聞く必要があり、そのためには ns1.example.com の IP が要る——という無限後退です。これを断つのがグルーレコードで、親（com）は委任応答の Additional セクションに、委任先 NS の A/AAAA を例外的に同梱します。

SOAレコード：ゾーンの一次情報源

各ゾーンの頂点（apex）には必ず1つだけ SOA（Start of Authority）レコードが置かれます。これがゾーンのメタ情報の一次情報源です。

example.com.  SOA  ns1.example.com. admin.example.com. (
                   2026062101   ; serial   ← 版番号
                   7200         ; refresh  ← 同期確認の間隔
                   3600         ; retry    ← 失敗時の再試行間隔
                   1209600      ; expire   ← 同期断時のゾーン破棄期限
                   300 )        ; minimum  ← ネガティブキャッシュTTL

これらのタイマはすべてセカンダリの同期動作を制御します。serial はゾーン内容の版番号で、内容を変えるたびに増やす規約です（慣習として YYYYMMDDnn 形式が多用される）。否定応答の保持時間を決める minimum の役割は 名前解決内部 で詳述したとおりです。

プライマリとセカンダリの同期：シリアル比較が起点

権威サーバーは1台では冗長性がないため、**プライマリ（マスター）**が原本を持ち、**セカンダリ（スレーブ）**が複製を保持します。セカンダリは SOA の serial を比較してゾーンが更新されたかを検知し、必要なときだけ転送を行います。流れは次のとおりです。

secondary 同期ループ:
  refresh 秒ごとに:
    soa = query(primary, zone, SOA)        # SOAだけ軽く取得
    if soa.serial > 自分の serial:
      ゾーン転送を要求（AXFR または IXFR）  # 版が進んでいれば転送
    elif 取得失敗:
      retry 秒後に再試行
      最後の成功から expire 秒を超えたら → ゾーンを破棄し応答停止

肝は、シリアルが進んでいなければ転送は走らない点です。コンテンツを変えたのに serial を増やし忘れると、セカンダリは「変化なし」と判断し、いつまでも古いゾーンを返し続けます。これは現場で頻発する更新事故の典型です。

AXFRとIXFR：全件転送か差分転送か

ゾーン転送には2方式があります。

AXFR はゾーン全体を送るため必ず TCP を使います（512バイトを超える応答を確実に運ぶため）。IXFR はプライマリが保持する変更履歴から、セカンダリの現在シリアルと最新シリアルの差分だけを送り、転送量を抑えます。ただしプライマリが古い差分を保持していない、あるいは差分計算が破綻する場合は AXFR へ自動的にフォールバックします。

更新の即時反映には、プライマリが変更時にセカンダリへ通知を送る NOTIFY を併用します。NOTIFY は「SOA が変わったかもしれない」という合図にすぎず、受け取ったセカンダリは結局 SOA を問い合わせてシリアルを比較してから転送します。NOTIFY は refresh 間隔の待ちを縮める最適化であって、同期判断の本体はあくまでシリアル比較です。

ラメ委任：親子のNSがずれると壊れる

**ラメ委任（lame delegation）**とは、親が委任した先のサーバーが、そのゾーンの権威として正しく応答しない状態を指します。具体的には次のいずれかです。

• 委任先 NS が応答しない（停止・到達不能）。
• 委任先は応答するが、そのゾーンの権威として設定されていない（SERVFAIL や委任の再返しを返す）。
• 親に書かれた NS 集合と、子ゾーン自身が持つ NS 集合が食い違う。

特に最後が見落とされがちです。委任の NS は親子の二か所に存在し（親側＝委任、子側＝apex の権威データ）、リゾルバの実装によってどちらを信頼するかが分かれます。両者がずれていると、ある NS には正しく届くのに別の NS では失敗する、という断続的で再現しにくい障害になります。ラメ委任は応答するサーバーがある限りタイムアウト＋リトライで時々救済されるため、平均遅延の増大として表面化し、原因特定が遅れます。

一段で言うと

権威 DNS は「親の NS とグルーで委任を連鎖させ、答えは末端の権威だけが持つ」委任設計と、「SOA のシリアル比較で更新を検知し、AXFR/IXFR で複製する」同期機構の二本柱です。障害の多くは serial の増やし忘れ（同期されない）と親子 NS の不一致（ラメ委任）に集約されます。裏取りには dig +trace（委任を一段ずつ辿る）、dig SOA（各権威のシリアル一致を確認）、dig NS（親と子の NS 集合を突き合わせ）を組み合わせ、どの段で委任が切れ、どのサーバーが版遅れかを必ず特定してください。