サブドメインの子ゾーン委譲が切り替わったかを dig で確認する

投稿日 2026/06/19

投稿者 rengotaku

11 分で読めます

サブドメインの子ゾーン委譲が切り替わったかを dig で確認する

サブドメインを親ゾーン内の単一レコードから独立した子ホステッドゾーンへ昇格させる作業をした。委譲が本当に切り替わったかを確認しようとして、最初に手が止まった。dig で引いても返ってくる IP が作業前と同じだったからだ。

これは当然で、移行の前後で A レコードの宛先(ALB)は変えていない。変わるのは「どのゾーンが権威を持って答えるか」であって、解決結果の IP ではない。だから検証も IP ではなく委譲チェーンを見る必要がある。同じ轍を踏まないよう、使ったコマンドと見るべき点を残しておく。

まとめ

子ゾーンへの委譲は、最終的に返る IP では判別できない。宛先を変えない移行なら IP は前後で同じになる
判定材料は3つ。親ゾーンが NS 委譲(referral)を返すか / 子ゾーンが aa フラグ付きで権威応答するか / dig +trace で委譲チェーンが成立しているか
@<server> でキャッシュを通さず特定の権威サーバへ直接問い合わせるのが基本
旧レコード削除後は、親への直接問い合わせが ANSWER: 0 + NS委譲のみになることで掃除完了を確認できる

前提となる構成

sub.example.com というサブドメインが、もともと親ゾーン example.com 内の A レコードとして存在していた。これを独立した子ホステッドゾーン sub.example.com に切り出し、親ゾーンには NS 委譲レコードだけを残す、という移行をしたとする。

親ゾーン: example.com
子ゾーン: sub.example.com(新規作成)
A レコードの宛先: 移行前後で同一(同じロードバランサ)

宛先が同じなので、エンドユーザから見た解決結果は変わらない。これはゼロダウンタイム移行としては狙いどおりだが、検証する側からすると「IP を見ても何も分からない」状況になる。

なぜ IP では判別できないのか

DNS の解決結果(A レコードの値)は「最終的にどのサーバが答えたか」とは独立している。親ゾーンの旧 A も、子ゾーンの新 A も、同じ宛先を指していれば同じ IP を返す。

確認すべきは値ではなく権威の所在だ。具体的には次の3点を見る。

親ゾーンが sub.example.com の問い合わせに対し NS 委譲(子ゾーンの NS を指す referral)を返すか
子ゾーンの権威サーバが aa(Authoritative Answer)フラグ付きで応答するか
root から辿った委譲チェーンが子ゾーンまで降りているか

1. 親ゾーンの権威 NS を調べる

まず親ゾーンを管理している権威サーバを特定する。以降はここに直接問い合わせる。

dig +short NS example.com
# → ns-xxx.awsdns-xx.com. などが返る

2. 親NSに委譲レコードがあるか

親の権威サーバに直接、サブドメインの NS を問い合わせる。

PNS=ns-xxx.awsdns-xx.com.
dig +noall +authority +answer NS sub.example.com @"$PNS"
# → sub.example.com. 300 IN NS ns-...(子ゾーンの NS) が返れば委譲成立

@"$PNS" を付けることで、ローカルのキャッシュ DNS を経由せず親の権威サーバへ直接問い合わせる。委譲を入れた直後でも、キャッシュの TTL を待たずに現在の状態を見られる。

3. 子ゾーンの正規 NS と委譲先を照合する

クラウド側(ホステッドゾーンの管理画面や CLI)で、子ゾーンに割り当てられた正規の NS を取得する。手順2で親が返した委譲先 NS と、この正規 NS が完全一致しているかを照合する。ここがずれていると、委譲先を間違えて NXDOMAIN になる。

4. 子ゾーンが権威応答するか(aa フラグ)

子ゾーンの NS の1つに直接 A を問い合わせ、ヘッダのフラグを見る。

CNS=ns-yyy.awsdns-yy.com   # 子ゾーンの NS
dig +noall +comments +answer A sub.example.com @"$CNS"

出力ヘッダの flags: に aa が立っていれば、そのサーバが権威として答えている証拠になる。

;; flags: qr aa rd; QUERY: 1, ANSWER: 2, ...

+comments を付けないとこのフラグ行が出ないので注意。+short だけだと値しか見えず、権威かどうかの判定ができない。

5. root 起点の end-to-end トレース

ここが一番分かりやすい。+trace は root サーバから順に委譲を辿るので、グローバルに見た現在の委譲状態をキャッシュ非依存で確認できる。

dig +trace +nodnssec sub.example.com A

出力を上から追うと、こう降りていく。

.                  → ルートサーバ
com.               → TLD サーバ
example.com.       → 親ゾーンの権威NS
sub.example.com. 300 IN NS ns-...   → 親が返す委譲(referral)
sub.example.com. 60  IN A   x.x.x.x → 子ゾーンが返す A

親ゾーンの段で NS 委譲が出て、その後に子ゾーンの NS に降りてから A が返っていれば、委譲経由で解決できている。+nodnssec は DNSSEC 関連レコードの出力ノイズを抑えるためのオプション。

6. 一般リゾルバでの実解決

最後にエンドユーザ視点で、パブリックリゾルバ経由でも解決が途切れていないかを確認する。

dig +short A sub.example.com @8.8.8.8
dig +short A sub.example.com @1.1.1.1

7. 旧レコード削除後の確認

委譲が効いていれば、親ゾーンに残った旧 A は参照されなくなる(DNS ではこれを occlude、委譲の影に隠れた状態と呼ぶ)。掃除としてこの旧レコードを削除したあと、親への直接問い合わせで消えたことを確認する。

PNS=ns-xxx.awsdns-xx.com.
dig +noall +comments +answer +authority A sub.example.com @"$PNS"

削除前は親が A を直接持っていた(ANSWER セクションに A が出る)が、削除後は ANSWER: 0 で AUTHORITY セクションに NS 委譲だけが残る。これで「親は直接レコードを持たず、委譲だけになった」=最終形に到達したことが分かる。

よく使ったオプション

オプション	役割
`@<server>`	指定サーバへ直接問い合わせ(キャッシュを通さず権威を見る)
`+trace`	root から委譲を辿る(グローバルな委譲状態の確認)
`+comments`	ヘッダ(`flags: ... aa` 等)を表示。権威判定に必須
`+noall +answer +authority`	出力を ANSWER / AUTHORITY セクションだけに絞る
`+short`	値だけ簡潔表示(実解決の確認向き)
`+nodnssec`	DNSSEC レコードを抑制してノイズ削減

委譲まわりは「値が返る/返らない」だけ見ていると、権威の所在を見落として誤判定する。@ で権威サーバを直接指名し、+trace で root から辿り、aa フラグで権威を確認する。自分はこの IP が同じ問題で一度手が止まったので、次からはこの順で見るようにしている。

networking, infrastructure

dns dig route53 ns-delegation troubleshooting