プライベートNS（自分のドメイン配下の名前で運用するネームサーバー）を変更するときに注意する点は、グルーレコードの更新漏れ、新旧サーバーのゾーンの食い違い、親ゾーンのTTLによる切り替えの遅れ、DNSSECの鍵、そしてNSと同じサーバーに載っているWebやメールへの影響です。この記事では、VPSの移転などで自前のDNSサーバーのIPやホストが変わる場面を想定し、注意点ごとに「何が起きるか」「どう確かめるか」「どう防ぐか」を説明します。
ブランド名を付けた独自NS名そのものを付け替える手順は、別記事のVanity NSの変更手順で扱っています。この記事は、自前で運用するDNSサーバーの移転・IP変更に絞っています。
プライベートNSの前提
example.com のネームサーバーを ns1.example.com と ns2.example.com にしている場合、ns1.example.com のIPを知るには example.com のネームサーバーに聞く必要があり、そのままでは循環してしまいます。これを解くのが、親ゾーン（.comなど）に登録するグルーレコード（ホストのIP）です。グルーはドメインのレジストラの管理画面で「ネームサーバーのホスト名登録」などの名前で登録します。
つまり、プライベートNSのIPは「自分のゾーンファイル」と「レジストラ経由で登録した親ゾーンのグルー」の2か所にあります。変更時の失敗の多くは、この2か所の片方だけを変えることから起きます。
注意点1：グルーレコードの更新漏れ
何が起きるか: サーバーを移転してゾーン内のAレコードだけを新しいIPに変えると、親ゾーンのグルーは古いIPのままです。リゾルバーはグルーのIP（古いサーバー）に問い合わせるので、古いサーバーを止めた時点で名前解決ができなくなります。
確かめ方: 親ゾーンのサーバーに直接問い合わせて、グルーのIPを見ます。
dig @a.gtld-servers.net example.com NS +norec応答の追加情報（ADDITIONAL）に出るIPがグルーです。ゾーン内の値と比べます。
dig @新しいサーバーのIP ns1.example.com A +norec防ぎ方: レジストラでホストのIPを新しいものに更新し、上のコマンドで反映を確かめてから古いサーバーを止めます。.jpなど一部のTLDでは、ホストの登録や変更の手順がgTLDと異なることがあるため、レジストラの案内を確認してください。
注意点2：新旧サーバーのゾーンの食い違い
何が起きるか: 切り替えの間は、キャッシュの状態によって古いサーバーに聞くリゾルバーと新しいサーバーに聞くリゾルバーが混在します。片方だけにレコードを追加すると、利用者によって表示されるサイトや届くメールの経路が変わります。
確かめ方: 同じ問い合わせを新旧両方のサーバーに投げ、SOAのシリアル番号と主要なレコードを比べます。
dig @古いサーバーのIP example.com SOA +short
dig @新しいサーバーのIP example.com SOA +short防ぎ方: 移転の期間中はレコードの変更を止めるか、変えるときは両方に同じ変更を入れます。BINDで新サーバーをセカンダリにしてゾーン転送で同期し、切り替え後にプライマリへ昇格させる方法もあります。ゾーン転送は相手のIPを限って許可します。
注意点3：親ゾーンのTTLは短くできない
何が起きるか: ゾーン内のTTLは自分で短くできますが、親ゾーンに載るNSとグルーのTTLはレジストリが決めていて、多くのgTLDで2日程度です。グルーを更新しても、それより前に古い情報をキャッシュしたリゾルバーは、TTLが切れるまで古いIPに問い合わせます。
防ぎ方: 古いサーバーは、グルーを更新してから最低でも親ゾーンのTTL分、余裕を見て数日は同じゾーンを返すように動かしておきます。VPSの契約を切り替え日に解約すると、この猶予が取れません。
注意点4：NSが1台、または同じ場所に2台
何が起きるか: ns1 と ns2 が同じVPSの別IPだと、そのVPSが止まった瞬間に名前解決が全滅します。移転作業中は特に止まりやすい時期です。
防ぎ方: ネームサーバーは、別のサーバー・別のネットワークに最低2台置きます。自前で2台を用意できない場合は、DNSサービスのセカンダリ機能を使う方法があります。移転は1台ずつ行い、常にどちらかが応答する状態を保ちます。
注意点5：DNSSECの鍵とDSレコード
何が起きるか: DNSSECを有効にしているドメインで、新しいサーバーが別の鍵で署名すると、親ゾーンのDSレコードと一致せず、検証するリゾルバーでは名前解決に失敗します。単なるIP変更でも、鍵ファイルを新サーバーに移し忘れると同じことが起きます。
防ぎ方: 同じ鍵を使い続けるなら、鍵ファイルを安全な方法で新サーバーへ移し、署名の状態をDNSSECの検証ツールで確かめます。鍵を作り直すなら、DSの更新を含む鍵の切り替え手順を先に計画します。
注意点6：同じサーバーに載っている他のサービス
何が起きるか: 自前のDNSサーバーにWebサイトやメールも同居していることがあります。DNSだけ移したつもりでも、AレコードやMXレコードの指す先、メールの送信元IPに関係するSPF、逆引き（PTR）などが古いIPのまま残ると、サイトが表示されない、メールが迷惑メール扱いになる、といった別の問題が起きます。
防ぎ方: 移転前にゾーンの全レコードを書き出し、古いIPを含む行を洗い出します。
dig @古いサーバーのIP example.com AXFR > zone-backup.txt
grep "古いIPアドレス" zone-backup.txtAXFRはゾーン転送を許可しているサーバーからしか取れません。許可していない場合はゾーンファイルそのものをバックアップします。
切り替え当日の確認リスト
- 新サーバーで全ゾーンが応答し、新旧のSOAシリアルが揃っている
- レジストラでグルーのIPを更新し、親ゾーンへの反映を
dig +norecで確かめた dig +trace example.comで新しいサーバーまでたどれる- Web表示、メールの送受信、SSL証明書の自動更新（DNS認証を使う場合）を確かめた
- 古いサーバーを止める日を、親ゾーンのTTLを過ぎた後に設定した
作業は、ゾーンファイルと設定ファイルのバックアップを取ってから始めてください。ホスト登録の画面や手順はレジストラごとに異なり、変わることもあるため、各社の最新の案内で確認してください（2026年10月現在）。
まとめ
- プライベートNSのIPは、ゾーン内と親ゾーンのグルーの2か所にある。変更時は両方をそろえる
- 切り替え中は新旧サーバーが混在して参照されるため、ゾーンの内容を一致させておく
- 親ゾーンのTTLは自分で短くできない。古いサーバーは数日残す
- ネームサーバーは別の場所に最低2台。移転は1台ずつ
- DNSSECの鍵と、同居しているWeb・メールの設定も移転の対象に含める