セカンダリNSの変更で名前解決が止まる原因の多くは、「ゾーン転送が新しいサーバーに届いていない」「ゾーン内のNSレコードと親ゾーンの委任が食い違っている」「古いサーバーを早く止めすぎた」の3つです。この記事では、セカンダリNSを追加・入れ替え・撤去するときに事前に確認すべき点を、確認コマンドとあわせて整理します。具体的な切り替えの手順は別記事「セカンダリNSの切り替え方法」で扱い、ここでは作業前に知っておくべき落とし穴に絞ります。
セカンダリNSの役割をおさらいする
セカンダリNSは、プライマリ（マスター）が持つゾーンの複製を受け取り、同じ内容を権威DNSとして答えるサーバーです。複製はゾーン転送（全体を送るAXFR、差分を送るIXFR）で行われ、プライマリからのNOTIFYか、SOAレコードのrefresh間隔ごとの問い合わせをきっかけに始まります。
ここで大事なのは、セカンダリは「プライマリと同じ答えを返すこと」が前提だという点です。リゾルバー（利用者側のキャッシュDNS）は、NSとして登録されたサーバーのどれに問い合わせるかを自分で選びます。1台でも古い内容や誤った内容を返すと、一部の利用者だけサイトが見えない、メールが届かないといった、再現しにくい障害になります。
注意点1：ゾーン転送の許可と通信経路
新しいセカンダリを用意したら、まずプライマリ側で転送を許可する必要があります。BINDなら allow-transfer、NOTIFYの送り先は also-notify などで指定します。PowerDNS、NSD、Knot DNSでも設定名は違いますが、考え方は同じです。
見落としやすいのは次の点です。
- ゾーン転送はTCPの53番ポートを使います。UDPの53番だけを開けているファイアウォールでは転送が失敗します
- セカンダリがマネージドDNSの場合、転送元として使われるIPアドレスが複数あることがあります。事業者が公開している一覧を確認して、すべて許可します
- TSIG鍵で転送を認証している場合、鍵名・アルゴリズム・鍵の値が両側で一致していないと拒否されます
- 転送の許可を
anyにするのは避けます。ゾーンの全レコードを第三者が取得できる状態になります
確認は、新しいセカンダリに対して直接問い合わせ、権威の答え（aa フラグ）が返るかを見ます。
dig +norec @ns-new.example.net example.com SOAstatus: REFUSED や SERVFAIL が返る場合は、まだゾーンを受け取れていません。
注意点2：SOAのシリアル番号
セカンダリは、SOAのシリアル番号が自分の持っている値より大きいときだけ転送を受けます。プライマリでレコードを変えたのにシリアルを上げ忘れると、セカンダリには変更が伝わりません。
シリアルを 2026102201 のような日付形式で運用している場合、誤って桁の多い値を入れてしまうと、元に戻すのが面倒になります（シリアルは比較規則上、単純に小さくできません）。変更前に全サーバーのシリアルをそろえて記録しておくと、後で差分を見つけやすくなります。
for ns in ns1.example.com ns2.example.com ns-new.example.net; do
echo -n "$ns: "; dig +short +norec @"$ns" example.com SOA | awk '{print $3}'
doneすべてのサーバーで同じシリアルが返ることが、変更作業に入る前提です。
注意点3：ゾーン内のNSレコードと親ゾーンの委任
NSの情報は2か所にあります。
- 親ゾーンの委任: レジストラの管理画面で設定する「ネームサーバー」。
.comなら.comのサーバーに登録されます - ゾーン内のNSレコード: 自分のゾーンの頂点（
example.com.）に書くNSレコード
この2つが食い違うと、リゾルバーによって使うサーバーが変わり、挙動が不安定になります。セカンダリを入れ替えるときは、両方を同じ内容にそろえることを意識します。
# 親ゾーンに登録されている委任
dig +norec @a.gtld-servers.net example.com NS
# ゾーン内のNSレコード
dig +norec @ns1.example.com example.com NSさらに、NSとして登録したサーバーのうち、実際にはそのゾーンを持っていないサーバー（いわゆるレイムデリゲーション）がないかも確認します。委任先に加えたのに転送が完了していない状態は、このレイムデリゲーションと同じ扱いになります。
注意点4：TTLと「古いサーバーを止める時期」
親ゾーンの委任には、親ゾーン側が決めたTTLが付きます。多くのgTLDでは1〜2日程度で、利用者が自分で短くすることはできません。ゾーン内のNSレコードのTTLは自分で決められますが、親の値を待つ必要がある点は変わりません。
そのため、旧セカンダリを外す作業は次の順序にします。
- 委任とゾーン内NSレコードから旧セカンダリを外す
- 親ゾーンとゾーン内NSのうち長いほうのTTL以上の時間を待つ
- その間も旧セカンダリには最新のゾーンを転送し続ける
- 待機後に旧セカンダリからゾーンを削除し、転送の許可を外す
逆に、旧セカンダリを先に止めて後から委任を外すと、キャッシュが残っている間は応答しないサーバーに問い合わせが向かい、名前解決が遅くなったり失敗したりします。
注意点5：SOAのexpireと「止め忘れ」
撤去時に見落としやすいのが、旧セカンダリを「止めずに放置する」ケースです。セカンダリはプライマリと通信できなくなっても、SOAのexpireの期間（数日〜数週間に設定されることが多い）が過ぎるまでは、手元の古いゾーンで答え続けます。
委任から外したつもりでも、どこかに古い設定が残っていれば古いIPが返ります。旧セカンダリが他社のサービスなら、そのサービス側でゾーンの登録を削除するところまでを作業に含めます。
注意点6：ネームサーバー名を自ドメインの配下にする場合
新しいセカンダリに ns3.example.com のように自分のドメインの配下の名前を付ける場合は、親ゾーンにIPアドレス（グルーレコード）を登録する必要があります。レジストラによって「ホスト登録」「ネームサーバーの登録」など呼び方が違います。グルーを登録せずに委任すると、その名前を引くためにそのゾーン自身を引くことになり、解決できなくなります。
注意点7：DNSSECを使っている場合
プライマリで署名したゾーンをそのまま転送する構成なら、セカンダリを替えてもDSレコードは変わりません。ただし、新しいセカンダリが受け取った署名済みゾーンをそのまま配信できるか（署名を付け直さないか）は、サービスごとに確認が必要です。セカンダリ側で独自に署名する構成は、複数の署名者を組み合わせる運用になり、手順が大きく変わります（2026年10月現在、対応状況は事業者により異なります）。
署名の検証が通っているかは、DNSSECの検証に対応したリゾルバーで ad フラグを見るか、DNSVizなどの診断ツールで確かめます。
作業前のチェックリスト
- 全NSのSOAシリアルが一致している
- 新セカンダリで転送が完了し、
aa付きで答えている - TCP 53番とTSIGの設定が両側で合っている
- 委任とゾーン内NSレコードを同じ内容に変える計画がある
- 旧セカンダリを残す期間（TTL以上）を決めている
- 変更前のNS・SOA・ゾーンファイルを保存している
まとめ
- セカンダリNSは「プライマリと同じ答えを返す」ことが前提。1台でも食い違うと一部の利用者だけが影響を受ける
- 転送はTCP 53番を使う。転送元IPの全許可とTSIGの一致を確認する
- 変更前に全サーバーのSOAシリアルがそろっていることを確かめる
- 親ゾーンの委任とゾーン内NSレコードを同じ内容にそろえる
- 旧セカンダリは委任から外した後もTTL以上残し、最後にゾーンを削除する