プライマリNS（ゾーンの原本を持つ権威DNSサーバー）を新しいサーバーや別のDNSサービスへ切り替えたあとは、「親ゾーンの委任」「各NSの応答内容」「セカンダリへの同期」「キャッシュの残り」の4点を順に確かめると、切り替えが終わったかどうかを判断できます。この記事では、dig を使ってそれぞれを確認する手順と、つまずきやすい箇所を説明します。旧サーバーを止めてよいタイミングも判断できるようになります。
「プライマリNS」が指すものを先に整理する
作業に入る前に、言葉の意味をそろえておきます。ここが曖昧なままだと、確認すべき場所を取り違えます。
- プライマリ（マスター）サーバー: ゾーンファイルの原本を持ち、編集を受け付ける権威サーバーです。SOAレコードの MNAME（最初の項目）には通常このサーバー名が入ります。
- セカンダリ（スレーブ）サーバー: プライマリからゾーン転送（AXFR/IXFR）でコピーを受け取る権威サーバーです。
- レジストラ画面の「プライマリ」「セカンダリ」欄: 多くのレジストラではネームサーバーの入力欄に番号や「プライマリ」と表示されますが、これは登録の並び順にすぎません。リゾルバは応答速度などを見てNSを選ぶため、1番目に書いたNSが優先して使われるわけではありません。
つまり「プライマリNSの切り替え」には、(1) 原本を持つサーバーを移す作業と、(2) レジストラに登録するNSそのものを入れ替える作業の2種類があります。DNSサービスを丸ごと乗り換える場合は両方が同時に起きます。以下の確認は両方に対応しています。
確認1: 親ゾーンの委任が新しいNSを指しているか
最初に、TLD（.com や .jp）の権威サーバーが、あなたのドメインのNSとして何を返しているかを確かめます。レジストラの画面で変更しても、レジストリへの反映が終わるまでは古いNSが返ります。
# .com の場合: TLDの権威サーバーを調べる
dig NS com. +short
# そのうち1台に、再帰なしで直接問い合わせる
dig NS example.com @a.gtld-servers.net +norec+norec を付けると、問い合わせ先のサーバーが持っている委任情報そのものが返ります。結果は ANSWER ではなく AUTHORITY セクションに出るのが普通です。ここに新しいNSが並んでいれば、レジストリ側の反映は済んでいます。
.jp の場合は dig NS jp. +short で得られるサーバーに同じように問い合わせます。dig +trace example.com を使うと、ルートからTLD、権威サーバーまでの委任をたどった結果をまとめて見られます。
WHOIS の Name Server 欄でも確認できますが、WHOISの表示はレジストラのデータを反映しているだけのこともあるため、最終的な判断はTLDサーバーへの問い合わせで行うほうが確かです。
NSがドメイン内の名前（ns1.example.com など）のとき
NSのホスト名が自分のドメイン配下にある場合、親ゾーンにはグルーレコード（NSホストのIPアドレス）の登録が必要です。上の +norec の結果で ADDITIONAL セクションに新しいIPアドレスが出ているかを確認してください。古いIPのまま残っていると、委任先は新しくても実際には旧サーバーへ問い合わせが行きます。グルーの変更はレジストラの「ホスト登録」などの機能で行うのが一般的ですが、名称はレジストラごとに異なります。
確認2: 新しいNSがすべて権威応答を返すか
次に、委任先として登録したNSの1台ずつに直接問い合わせます。
dig SOA example.com @ns1.new-dns.example +norec
dig SOA example.com @ns2.new-dns.example +norec見るべき点は3つです。
- ヘッダの flags に
aa（権威応答）が付いているか。付いていなければ、そのサーバーはゾーンを持っていません。 - status が
NOERRORか。REFUSEDはゾーン未登録やアクセス制限、SERVFAILはゾーンの読み込み失敗が疑われます。 - SOAの MNAME が新しいプライマリになっているか、シリアル番号が想定どおりか。
全NSのSOAをまとめて比べるには +nssearch が便利です。
dig +nssearch example.com各NSが返したSOAのシリアルが一覧で表示されます。シリアルがそろっていなければ、セカンダリへの同期が終わっていないか、旧サーバーがまだNSとして残っています。
親と子でNSの一覧が一致しているか
ゾーンの中にもNSレコードがあります。親（TLD）が返すNSと、新しい権威サーバー自身が返すNSが一致しているかも確かめてください。
dig NS example.com @ns1.new-dns.example +norec +shortゾーン内に旧NSが残っていると、一部のリゾルバがそちらを使い続ける原因になります。DNSサービスを乗り換えた場合、ゾーンをインポートしたときに旧NSのレコードがそのまま入っていることがよくあります。
確認3: セカンダリへのゾーン転送が動いているか
自前のプライマリとセカンダリを運用している場合は、プライマリを移したあとにセカンダリが新しいプライマリから転送を受けられているかを確認します。BIND を例にします。
# セカンダリ側で、ゾーンの状態を確認
sudo rndc zonestatus example.com
# 新プライマリからの再転送を試す
sudo rndc retransfer example.com
# ログで転送の成否を見る（サービス名は環境により named / bind9）
sudo journalctl -u named --since "30 min ago" | grep -i transferつまずきやすいのは次の箇所です。
- セカンダリの設定（BINDなら
primaries/mastersの指定）が旧プライマリのIPのままになっている。 - 新プライマリ側で、セカンダリのIPからのゾーン転送（
allow-transfer）や NOTIFY の送信先が設定されていない。 - ファイアウォールで TCP 53番が閉じている。ゾーン転送はTCPを使うため、UDPだけ開けていると失敗します。
ゾーン転送は許可したセカンダリだけに限定してください。誰からでも AXFR を受け付ける設定は、ゾーンの中身をすべて外部に渡すことになります。
確認4: キャッシュがいつ切れるか
委任と権威サーバーが正しくても、リゾルバには古いNS情報がキャッシュされています。主要な公開リゾルバで現状を見ておきます。
dig NS example.com @8.8.8.8
dig NS example.com @1.1.1.1ANSWER の各行にある数字が残りTTL（秒）です。古いNSが返ってくる場合でも、この値が0に向かって減っていれば時間の問題です。TLDが設定する委任NSのTTLは長めのことが多く（例えば .com では2日程度）、ゾーン内のNSレコードのTTLとも別に効くため、旧サーバーは少なくとも両方のTTLが過ぎるまで同じ内容で動かし続けてください。旧サーバーでレコードを先に消したり止めたりすると、キャッシュが残る利用者だけ名前解決に失敗します。
DNSSECを使っている場合の注意
DNSSECを有効にしたまま別のDNSサービスへ移ると、親ゾーンに登録したDSレコードと新サービスの鍵（DNSKEY）が一致せず、検証するリゾルバでは SERVFAIL になります。サイトが一部の利用者だけ表示されない、という形で現れるため気付きにくい障害です。
dig DS example.com +short
dig DNSKEY example.com @ns1.new-dns.example +short
delv example.comdelv で fully validated と出れば検証は通っています。移行の手順はDNSサービスごとに異なり、鍵の引き継ぎに対応するサービスとしないサービスがあります（2026年10月現在）。一般には「旧サービスでDSを外してDSのTTLが切れるのを待つ → NSを切り替える → 新サービスで署名を有効にしてDSを登録する」という順に進めると安全です。DSの扱いはDNSサービスとレジストラ両方のヘルプで確認してください。
切り替え完了と判断する目安
次の条件がそろえば、プライマリNSの切り替えは完了したと判断できます。
- TLDサーバーへの
+norec問い合わせで新しいNSだけが返り、グルーも新しいIPになっている。 - 新しいNSすべてが
aa付き・NOERRORで応答し、+nssearchのシリアルがそろっている。 - ゾーン内のNSレコードが親の委任と一致している。
- セカンダリへの転送ログに成功が記録されている（自前運用の場合）。
- 公開リゾルバから新しいNSが返る、または旧NSのTTLが切れている。
作業前にゾーンファイルや管理画面のレコード一覧をエクスポートしておくと、移行先で値が欠けたときに見比べられます。
まとめ
- 「プライマリNS」はゾーンの原本を持つサーバーのことで、レジストラ画面の入力順とは別物です。
- 確認は「親の委任 → 各NSの権威応答とSOA → ゾーン転送 → キャッシュ」の順に進めます。
dig +norecで委任そのものを、dig +nssearchで全NSのシリアルを比べられます。- 旧サーバーは委任とゾーン内NSのTTLが切れるまで同じ内容で動かし続けます。
- DNSSEC利用中はDSレコードの扱いを先に決めてから切り替えます。