ゾーン委任（Zone Delegation）

概要

ゾーン委任（Zone Delegation） は、DNS の名前空間を分割し、特定のサブドメインの管理権限を別の権威ネームサーバーに委譲する仕組みです。RFC 1034（1987年）で定義された DNS の分散管理モデルの根幹であり、インターネットの DNS がルートゾーンから各ドメインまで階層的に機能する基盤となっています。

DNS の名前空間は単一のサーバーで管理するには巨大すぎます。ゾーン委任によって、ルートゾーン（.）は .com や .jp などの TLD ネームサーバーに管理を委ね、TLD ネームサーバーは example.com の権威ネームサーバーに管理を委ね、という階層的な委譲が実現しています。組織内でも、api.example.com を別のチームやプロバイダーのネームサーバーで管理したい場合にゾーン委任を使います。

委任は親ゾーンに NS レコードを設定することで行います。必要に応じてグルーレコード（A/AAAA レコード）も親ゾーンに追加します。再帰リゾルバーはこの NS レコードを辿って委任先のネームサーバーに問い合わせ直すため、委任先が独立してレコードを管理できるようになります。

仕組み

ゾーン委任は親ゾーンの NS レコードで委任先を指示し、必要に応じてグルーレコードで循環参照を解消する二段構えの設計です。

委任の基本構造

ゾーン委任は、親ゾーンと子ゾーンの間に成立する関係です。親ゾーンのゾーンファイルに子ゾーンの NS レコードを記述することで、「このサブドメインについてはあちらのネームサーバーに聞いてください」と再帰リゾルバーに指示します。

; example.com ゾーンファイル内の委任設定
api.example.com.   IN  NS  ns1.api-provider.com.
api.example.com.   IN  NS  ns2.api-provider.com.

この設定により、example.com ゾーンの権威ネームサーバーは api.example.com やその配下（v2.api.example.com など）のレコードを持ちません。代わりに、問い合わせに対して委任応答（referral）を返します。

委任が成立すると、名前空間は次のように分割されます。

example.com ゾーン（ns1.example.com が管理）
├── example.com       (SOA, NS, A, MX, TXT)
├── www.example.com   (A)
├── mail.example.com  (A)
└── api.example.com   (NS) ← 委任ポイント
      │
      api.example.com ゾーン（ns1.api-provider.com が管理）
      ├── api.example.com       (SOA, NS, A)
      ├── v2.api.example.com    (A)
      └── docs.api.example.com  (CNAME)

親ゾーンが持つのは委任ポイントの NS レコードだけです。api.example.com の A レコードや、v2.api.example.com のレコードは子ゾーン側で管理します。

委任応答（Referral）の仕組み

再帰リゾルバーが v2.api.example.com の A レコードを解決する流れを追います。

1. 再帰リゾルバーが example.com の権威ネームサーバーに v2.api.example.com を問い合わせる
2. 権威ネームサーバーは api.example.com の NS レコードを AUTHORITY セクションに含めた委任応答を返す
3. 応答の flags に aa（Authoritative Answer）フラグが立たない。これは「自分はこのレコードの権威ではない」という意味
4. 再帰リゾルバーは NS レコードで示された ns1.api-provider.com に v2.api.example.com を問い合わせ直す
5. 委任先の権威ネームサーバーが A レコードを返す

委任応答を dig で確認すると、次のような出力になります。

dig A v2.api.example.com @ns1.example.com

;; flags: qr rd; QUERY: 1, ANSWER: 0
;; AUTHORITY SECTION:
api.example.com.  86400  IN  NS  ns1.api-provider.com.
api.example.com.  86400  IN  NS  ns2.api-provider.com.

ANSWER セクションが空で AUTHORITY セクションに NS レコードが返ること、aa フラグが立っていないことが委任応答の特徴です。

グルーレコード

委任先のネームサーバーのホスト名が、委任先ゾーン自身のサブドメインである場合、循環参照が発生します。

; example.com ゾーン内
sub.example.com.  IN  NS  ns1.sub.example.com.

この場合、ns1.sub.example.com の IP アドレスを知るためには sub.example.com ゾーンに問い合わせる必要がありますが、そのゾーンのネームサーバーが ns1.sub.example.com であるため、解決が循環します。

グルーレコード（Glue Record）はこの問題を解決します。親ゾーンに委任先ネームサーバーの A レコード（または AAAA レコード）を直接登録し、循環参照を断ち切ります。

; example.com ゾーン内（グルーレコード付き委任）
sub.example.com.      IN  NS  ns1.sub.example.com.
sub.example.com.      IN  NS  ns2.sub.example.com.
ns1.sub.example.com.  IN  A   198.51.100.1
ns2.sub.example.com.  IN  A   198.51.100.2

グルーレコードは委任応答の ADDITIONAL セクションに含まれて返ります。再帰リゾルバーはこの IP アドレスを使って委任先ネームサーバーに直接接続できます。

グルーレコードが必要になるのは、委任先のネームサーバー名が委任先ゾーン内のホスト名である場合（in-bailiwick）のみです。委任先のネームサーバーが外部ドメイン（ns1.api-provider.com など）であれば、通常の名前解決でそのネームサーバーの IP アドレスを取得できるため、グルーレコードは不要です。

DNS の階層的な委任チェーン

インターネットの DNS 全体がゾーン委任の連鎖で構成されています。

. (ルートゾーン) ─── IANA が管理
├── com. ─── Verisign が管理（ルートゾーンからの委任）
│   ├── example.com. ─── レジストラ経由でユーザーが管理（com. からの委任）
│   │   └── api.example.com. ─── 別プロバイダーが管理（example.com. からの委任）
│   └── cloudflare.com. ─── Cloudflare が管理
├── jp. ─── JPRS が管理
│   └── example.jp. ─── ユーザーが管理
└── org. ─── PIR が管理

ルートゾーンには世界に 13 のルートネームサーバー群（a.root-servers.net 〜 m.root-servers.net）があり、Anycast 技術によって実際には数百のサーバーが稼働しています。RFC 2870（2000年）でルートサーバーの運用要件が規定されています。

ドメインの取得時にレジストラの管理画面でネームサーバーを設定する操作は、TLD ゾーンに NS レコード（と必要に応じてグルーレコード）を登録して委任を確立する手続きです。

委任の双方向性

委任が正しく機能するには、親ゾーン側と子ゾーン側の両方で整合性のある設定が必要です。

親ゾーン側で必要な設定は次の通りです。

• 子ゾーンの NS レコードを登録する
• 必要に応じてグルーレコードを登録する

子ゾーン側で必要な設定は次の通りです。

• SOA レコードを作成する
• NS レコードを登録する（親ゾーンに設定したものと一致させる）
• 管理対象のレコード（A、AAAA、MX、TXT など）を登録する

親ゾーンの NS レコードと子ゾーンの NS レコードが一致しない状態を「Lame Delegation」と呼びます。RFC 1912（1996年）でこの問題が記述されています。

設定例

親ゾーンと子ゾーンの両方に必要な設定を、外部プロバイダーへの委任とグルーレコード付き委任の 2 パターンで示します。

基本的なサブドメイン委任

example.com の管理者が api.example.com を別プロバイダーに委任する場合の設定です。

親ゾーン（example.com）側の設定です。

; example.com ゾーンファイル
api.example.com.  IN  NS  ns1.api-provider.com.
api.example.com.  IN  NS  ns2.api-provider.com.

子ゾーン（api.example.com）側の設定です。

; api.example.com ゾーンファイル
$ORIGIN api.example.com.
$TTL 3600

@   IN  SOA  ns1.api-provider.com. admin.api-provider.com. (
                2024010101  ; SERIAL
                10800       ; REFRESH
                3600        ; RETRY
                604800      ; EXPIRE
                300         ; MINIMUM
            )
    IN  NS   ns1.api-provider.com.
    IN  NS   ns2.api-provider.com.
    IN  A    203.0.113.10

v2  IN  A    203.0.113.11

グルーレコードが必要な委任

委任先ネームサーバーが自ゾーン内にある場合です。

; example.com ゾーンファイル
sub.example.com.      IN  NS  ns1.sub.example.com.
sub.example.com.      IN  NS  ns2.sub.example.com.
ns1.sub.example.com.  IN  A   198.51.100.1
ns2.sub.example.com.  IN  A   198.51.100.2

クラウド DNS での委任設定

AWS Route 53 で api.example.com のホストゾーンを作成した場合、Route 53 がネームサーバーを割り当てます。そのネームサーバーを親ゾーン側に NS レコードとして登録します。

; example.com ゾーンファイル（親ゾーン側）
api.example.com.  IN  NS  ns-1234.awsdns-56.org.
api.example.com.  IN  NS  ns-789.awsdns-01.co.uk.
api.example.com.  IN  NS  ns-456.awsdns-78.com.
api.example.com.  IN  NS  ns-012.awsdns-34.net.

Route 53 のネームサーバーは外部ドメインであるため、グルーレコードは不要です。

確認方法

委任が正しく設定されているかを確認するには、親ゾーンの権威ネームサーバーに直接問い合わせます。

dig NS api.example.com @ns1.example.com

;; flags: qr rd; QUERY: 1, ANSWER: 0
;; AUTHORITY SECTION:
api.example.com.  86400  IN  NS  ns1.api-provider.com.
api.example.com.  86400  IN  NS  ns2.api-provider.com.

aa フラグが立たず、AUTHORITY セクションに NS レコードが返れば委任が設定されています。

委任先のネームサーバーが正しく応答するかも確認します。

dig A api.example.com @ns1.api-provider.com

;; flags: qr aa rd; QUERY: 1, ANSWER: 1
;; ANSWER SECTION:
api.example.com.  3600  IN  A  203.0.113.10

aa フラグが立ち、ANSWER セクションに A レコードが返れば、委任先が正しく機能しています。

ルートからの委任チェーンを全て追跡するには +trace オプションを使います。

dig A api.example.com +trace

各ステップでの委任応答が表示され、問題がどの階層にあるかを特定できます。

外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/dns?domain=api.example.com&type=NS,A"

{
  "success": true,
  "data": {
    "domain": "api.example.com",
    "records": {
      "NS": [
        "ns1.api-provider.com",
        "ns2.api-provider.com"
      ],
      "A": [
        { "address": "203.0.113.10", "ttl": 3600 }
      ]
    }
  },
  "error": null,
  "meta": { "responseTime": 55 }
}

records.NS に委任先ネームサーバーのホスト名が配列で返ります。末尾のドット（FQDN 表記）は除去された状態です。records.A には委任先が管理する A レコードの address と ttl が含まれます。NS が null の場合、そのサブドメインに委任が設定されていないか、委任先が応答していない可能性があります。

よくある問題

ゾーン委任のトラブルは、親ゾーンと子ゾーンの設定不整合（Lame Delegation）やグルーレコードの更新漏れが大半を占めます。

委任先にゾーンが作成されていない

親ゾーンに NS レコードを設定しても、委任先のネームサーバーにゾーンが作成されていなければ SERVFAIL が返ります。委任は双方向の設定であり、親ゾーンの NS レコード追加と、委任先でのゾーン作成（SOA レコード、NS レコード、その他のレコードの登録）の両方が必要です。dig で委任先に直接問い合わせて応答を確認します。

dig SOA api.example.com @ns1.api-provider.com

SOA レコードが返らない場合、委任先のゾーン設定が不完全です。

親ゾーンと子ゾーンの NS レコードが不一致（Lame Delegation）

親ゾーンの NS レコードが ns1.old-provider.com を指しているのに、実際のゾーンは ns1.new-provider.com で管理している状態です。再帰リゾルバーは親ゾーンの NS レコードに従って古いネームサーバーに問い合わせるため、名前解決に失敗するか古いデータが返ります。

DNS プロバイダーを移行した場合は、委任先のゾーンを新プロバイダーに作成した後、親ゾーンの NS レコードも更新する必要があります。

グルーレコードの IP アドレスが古い

ネームサーバーの IP アドレスを変更したのにグルーレコードを更新しなかった場合、再帰リゾルバーは古い IP アドレスに接続しようとして名前解決が失敗します。グルーレコードはレジストラの管理画面で更新します。TLD ネームサーバーへの反映には数時間かかることがあるため、IP アドレス変更時は新旧両方のアドレスでネームサーバーを一時的に稼働させます。

委任先ネームサーバーが 1 台しかない

委任先の NS レコードが 1 つだけの場合、そのサーバーに障害が発生するとサブドメイン全体の名前解決が停止します。RFC 2182 は最低 2 つの権威ネームサーバーを異なるネットワークに配置することを推奨しています。クラウド DNS サービスは通常 2〜4 台のネームサーバーを自動で割り当てます。

委任の TTL が長すぎて移行に時間がかかる

親ゾーンに設定した NS レコードの TTL が長い（86400 秒 = 24 時間など）場合、委任先の変更後も長時間にわたって旧ネームサーバーへの問い合わせが続きます。委任先の移行を予定している場合は、移行の 24〜48 時間前に NS レコードの TTL を 300〜600 秒に短縮しておきます。移行完了後、新しい委任が十分に伝搬した段階で TTL を元の値に戻します。