DNSSECを有効にしたゾーンでサーバー移転を行う場合、DNSサービスを変えずにAレコードのIPアドレスだけを書き換えるなら、DNSKEYやDSには触れる必要がなく、普段どおりTTLを下げてから切り替えれば済みます。注意が要るのは、移転先のホスティング会社のDNSへネームサーバーごと移す場合で、このときはDNSKEYが入れ替わるため、DSの扱いを先に決めないと名前解決が止まります。この記事では、移転のパターンを見分けたうえで、それぞれの手順と、切り替え前後の確認方法を説明します。
署名ゾーンでAレコードを運用する基本（DNSKEY・RRSIG・DSの役割、有効化の順序）は別の記事で扱っているため、ここではサーバー移転の場面に絞ります。
まず移転のパターンを見分ける
作業の前に、次の2点を確かめます。
# ネームサーバー（どのDNSサービスでゾーンを管理しているか）
dig example.com NS +short
# 親ゾーンにDSがあるか（DNSSECが有効か）
dig example.com DS +shortDSが返ってくれば、そのドメインはDNSSECで検証される状態です。そのうえで、移転後もネームサーバーが変わらないかどうかで、作業が分かれます。
- パターンA：DNSサービスはそのまま、AレコードのIPだけ変える: 外部のDNSサービス（Cloudflare、Route 53など）でゾーンを管理していて、Webサーバーだけ引っ越すケースです
- パターンB：DNSサービスごと移る: 旧ホスティング会社のDNSを使っていて、移転先のホスティング会社のネームサーバーに切り替えるケースです
パターンA：IPアドレスだけを変える
DNSKEYとDSは触らない
Aレコードの値を書き換えても、ゾーンの鍵（DNSKEY）や親ゾーンのDSは変わりません。DNSサービスが書き換えたAレコードに新しい署名（RRSIG）を付けるだけです。多くのマネージドDNSは保存と同時に署名し直し、BINDで dnssec-policy を使っている場合も、元のゾーンを編集して読み込み直せば自動で署名されます。手作業で dnssec-signzone を実行して署名している環境だけは、書き換えのたびに署名し直す必要があります。
1. TTLを下げて待つ
切り替えの前日など、現在のTTL以上の時間を空けて、Aレコード（IPv6も使っているならAAAAレコード）のTTLを300秒程度に下げます。RRSIGは署名したレコードと同じTTLでキャッシュされるため、TTLを下げればAレコードと署名がそろって短く入れ替わるようになります。
2. 署名の状態を確かめておく
切り替え前に、権威DNSが署名付きで応答していることと、検証が通っていることを確かめます。
dig @ns1.example-dns.net www.example.com A +dnssec +norecurse
dig @1.1.1.1 www.example.com A +dnssec1つ目でAレコードとRRSIGが返り、2つ目の flags: に ad が含まれていれば、検証が通っています。ここで既に失敗しているなら、移転とは別の問題なので、先に直してから進めます。
3. Aレコードを書き換える
管理画面またはゾーンファイルでIPアドレスを新しいサーバーのものに変えます。ゾーンファイルで管理している場合は、編集前にバックアップを取り、SOAのシリアル番号を上げてから読み込み直します。
named-checkzone example.com /var/named/example.com.zone
sudo rndc reload example.com4. 新しい値と署名を確かめる
権威DNSで新しいIPアドレスとRRSIGが返ること、検証するリゾルバーで ad が付くことを確かめます。権威DNSが複数ある場合は、すべてに問い合わせます。セカンダリDNSへの転送が遅れていると、サーバーによって新旧の値が混ざって返ります。
パターンB：DNSサービスごと移る
ネームサーバーを移転先に切り替えると、新しいDNSサービスは自分の鍵でゾーンに署名します。親ゾーンのDSが旧サービスの鍵のままだと、新しいネームサーバーの応答はどれも検証に失敗し、検証するリゾルバーを使う利用者からはサイトもメールも見えなくなります。
旧サービスと新サービスの間で鍵を引き継ぐ仕組み（互いの鍵を事前に公開しておく方式）を両社が用意していれば、DNSSECを保ったまま移ることもできますが、対応しているサービスは限られます（2026年10月現在）。多くの場合は、次の「一度DNSSECを外して移る」手順が現実的です。
- 移転先のDNSサービスにゾーンを作り、Aレコードを含むすべてのレコードを登録する（MX、TXT、CAAも忘れずに）
- レジストラの管理画面で、親ゾーンのDSを削除する
- DSのTTLが切れるまで待つ（
dig example.com DSで親側のTTLを事前に確かめておきます）。待つ間も旧ネームサーバーの署名は止めない - ネームサーバーを移転先に切り替える
- 旧ネームサーバーのTTLが切れ、新ネームサーバーで応答していることを確かめる
- 移転先でDNSSECを有効にし、全台で署名が返ることを確かめてから、新しいDSをレジストラに登録する
手順2と3を飛ばしてネームサーバーを先に変えると、DSと鍵が合わない状態がDSのTTL分続きます。また、移行の間はDNSSECによる保護が一時的に外れることになるため、作業日を決めて短期間で終えるようにします。
新しいホスト名を追加するときの注意
移転に合わせて new.example.com のような確認用の名前を追加することがあります。署名ゾーンでは、存在しない名前への答えが、NSECまたはNSEC3という「この範囲に名前は無い」ことを示す署名付きのレコードで返ります。
追加する前に誰かがその名前を問い合わせていると、「存在しない」という答えがキャッシュされ、追加した後もしばらく見えないことがあります。さらに、NSECを使うゾーンでは、検証するリゾルバーがキャッシュしたNSECを根拠に、同じ範囲にある別の名前も「存在しない」と判断する動き（RFC 8198）があります。この待ち時間は、SOAレコードの値（ネガティブキャッシュのTTL）で決まるため、確認用の名前は前もって追加しておくと、当日に待たされずに済みます。
切り替え後に起きやすい問題
名前解決ができないときは、検証を無効にする +cd 付きの問い合わせと比べます。
dig @1.1.1.1 www.example.com A
dig @1.1.1.1 www.example.com A +cd普通の問い合わせが SERVFAIL で、+cd なら新しいIPが返る場合は、DNSSECの検証で失敗しています。可能性の高い順に次を確かめます。
- ネームサーバーを変えたのに旧DSが残っている: パターンBの手順を飛ばした場合です。DSを削除するか、新しい鍵に対応するDSに入れ替えます
- 一部の権威DNSが署名していない、または古いゾーンを返す: 全台に
+dnssec +norecurseで問い合わせて比べます - 署名の期限切れ: 手動で署名している環境で、書き換え後に署名し直していない場合です
DNSSECの問題でなければ、残っているのは通常のキャッシュの問題です。旧サーバーは、元のTTLが切れるまで止めずに残しておくと、古い答えを持つ利用者も旧サイトを見られ、問題があったときの切り戻しも容易になります。
WordPressサイトでは、Aレコードが新しいサーバーを指してからでないと、移転先でSSL証明書を発行できない構成（HTTPで所有確認をする方式）が多くあります。CAAで発行元を制限している場合は、移転先が使う認証局が許可されているかも、切り替え前に確かめておきます。
まとめ
- DNSサービスを変えずにAレコードだけを書き換えるなら、DNSKEYとDSには触れない
- TTLを下げて待ち、署名と
adを確かめてから切り替える - ネームサーバーごと移るときは、DSを先に外し、DSのTTLが切れてから切り替える
- 新しいホスト名は前もって追加し、NSECによる「存在しない」のキャッシュを避ける
- 不具合時は
+cdと比べ、DSの残り、全台の署名、署名期限の順に確かめる