セカンダリNSの切り替えは、「新セカンダリにゾーンを転送して応答を確かめる」「NSレコードと委任に新セカンダリを加える」「TTLぶん待ってから旧セカンダリを外す」の順に進めると、名前解決を止めずに済みます。この記事では、プライマリをBINDで運用している場合を例に、設定の書き方と各段階の確認方法を手順として説明します。変更時の落とし穴の解説は別記事「セカンダリNSを変更するときの注意点」にまとめ、ここでは実際の作業の流れに絞ります。
全体の流れ
作業は次の6段階です。各段階で確認が取れてから次へ進みます。
- 現状を記録し、バックアップを取る
- 転送用のTSIG鍵を用意し、プライマリで新セカンダリへの転送を許可する
- 新セカンダリにゾーンを登録し、転送と応答を確認する
- ゾーン内のNSレコードと、レジストラの委任に新セカンダリを加える
- 旧セカンダリを外し、TTL以上待つ
- 旧セカンダリからゾーンを削除する
新旧を一時的に併用する期間を作るのがポイントです。いきなり置き換えるより作業は増えますが、問題が起きたときに戻せる状態を保てます。
1. 現状を記録する
作業前に、今の委任・NSレコード・SOA・ゾーンファイルを保存します。BINDの設定ファイル（named.conf と関連ファイル）とゾーンファイルは、日付を付けてコピーしておきます。
dig +norec @a.gtld-servers.net example.com NS > before_delegation.txt
dig +norec @ns1.example.com example.com NS > before_ns.txt
dig +norec @ns1.example.com example.com SOA > before_soa.txt.com 以外のドメインでは、親ゾーンのサーバー名が異なります。dig +short com NS のように親ゾーンのNSを引いて、その中の1台を指定します。
2. TSIG鍵の作成と転送の許可
ゾーン転送は、IPアドレスの制限に加えてTSIG鍵で認証するのが一般的です。BINDに付属する tsig-keygen で鍵を作れます。
tsig-keygen -a hmac-sha256 xfer-example > /etc/bind/xfer-example.key出力された key の定義を、プライマリと新セカンダリの両方で読み込みます。鍵の値は秘密情報なので、権限を絞ったファイルに置き、リポジトリなどに含めないようにします。
プライマリ側のゾーン定義は、たとえば次のようにします（ファイルの場所はディストリビューションにより異なります）。
include "/etc/bind/xfer-example.key";
zone "example.com" {
type primary;
file "/etc/bind/zones/example.com.zone";
notify yes;
also-notify { 198.51.100.20; }; // 新セカンダリ
allow-transfer {
key "xfer-example"; // 新セカンダリ（TSIG）
203.0.113.10; // 旧セカンダリ（既存の許可）
};
};古いBINDでは type master と書きます。新しいバージョンでも旧表記は使えますが、将来の変更に備えて手元のバージョンのドキュメントで確認してください（2026年10月現在）。
設定を変えたら構文を確かめてから再読み込みします。
named-checkconf
named-checkzone example.com /etc/bind/zones/example.com.zone
rndc reconfigファイアウォールでは、新セカンダリからのTCP 53番を許可します。ゾーン転送はTCPを使うため、UDPだけ開けている状態では失敗します。
3. 新セカンダリにゾーンを登録する
新セカンダリもBINDなら、次のように定義します。
include "/etc/bind/xfer-example.key";
zone "example.com" {
type secondary;
file "/var/cache/bind/example.com.zone";
primaries { 192.0.2.10 key "xfer-example"; };
};古いBINDでは type slave; と masters を使います。マネージドDNSを新セカンダリにする場合は、管理画面で「セカンダリゾーン」に当たる機能を選び、プライマリのIPとTSIG鍵を入力します。画面の名称や対応するアルゴリズムは事業者ごとに異なり、セカンダリの機能自体を上位プランに限っている事業者もあります。
登録したら、転送が終わったかを確認します。
# 新セカンダリが権威として答えるか（flagsに aa があるか）
dig +norec @198.51.100.20 example.com SOA
# プライマリとシリアルが一致するか
dig +short +norec @192.0.2.10 example.com SOA
dig +short +norec @198.51.100.20 example.com SOA転送が進まないときは、新セカンダリで rndc retransfer example.com を実行し、BINDのログ（journalctl -u named など、環境により名前が異なります）で拒否の理由を見ます。TSIG や REFUSED を含む行があれば、鍵の不一致か許可の漏れです。
あわせて、主要なレコード（Webサーバーの A、メールの MX、SPFなどの TXT）を新セカンダリに直接問い合わせ、プライマリと同じ値が返ることを確かめます。
4. NSレコードと委任に新セカンダリを加える
新セカンダリが正しく答えることを確認できたら、名前解決の対象に加えます。
まずプライマリのゾーンファイルで、頂点のNSレコードに新セカンダリを追加し、SOAのシリアルを上げます。
example.com. 3600 IN NS ns1.example.com.
example.com. 3600 IN NS ns2.example.net. ; 旧セカンダリ
example.com. 3600 IN NS ns-new.example.org. ; 新セカンダリrndc reload example.com で反映し、NOTIFYで両方のセカンダリに伝わったことをシリアルで確認します。
次に、レジストラの管理画面で委任（ネームサーバー）に新セカンダリを追加します。新セカンダリの名前が自分のドメインの配下（例: ns3.example.com）なら、先にホスト（グルー）の登録が必要です。反映後、親ゾーンを直接引いて委任が変わったことを確認します。
5. 旧セカンダリを外す
新セカンダリを加えた状態でしばらく様子を見て問題がなければ、旧セカンダリを外します。順序は追加のときと同じで、ゾーン内のNSレコードから削除してシリアルを上げ、レジストラの委任からも削除します。
ここで旧セカンダリを止めてはいけません。親ゾーンの委任のTTL（多くのgTLDで1〜2日程度）と、ゾーン内のNSレコードのTTLのうち長いほうの時間は、旧セカンダリを動かし続けます。その間もプライマリからの転送は続け、最新の内容を返せる状態にしておきます。
6. 旧セカンダリからゾーンを削除する
待機期間が過ぎたら、旧セカンダリのゾーン定義を削除し、プライマリの allow-transfer と also-notify から旧セカンダリを外します。旧セカンダリが他社のサービスなら、その管理画面でゾーンを削除します。放置すると、SOAのexpireの期間が過ぎるまで古い内容で答え続けるためです。
最後に、すべてのNSで同じシリアルが返ること、dig +trace example.com で親から順に正しくたどれることを確認して作業完了です。
うまくいかないときの戻し方
新セカンダリに問題が見つかった場合は、委任とNSレコードから新セカンダリを外せば元に戻ります。旧セカンダリを撤去するまでは、この戻し方が使えます。旧セカンダリの削除を最後にしているのは、このためです。
まとめ
- 新旧を併用する期間を作り、追加→確認→撤去の順に進める
- TSIG鍵で転送を認証し、TCP 53番の許可とシリアルの一致を確かめる
- 新セカンダリが
aa付きで正しく答えてから、NSレコードと委任に加える - 旧セカンダリは委任から外した後もTTL以上動かし、最後にゾーンを削除する
- BINDの
type・primariesなどの表記はバージョンで変わるため、手元のドキュメントを確認する