📅 2026年9月3日 ⏱️ 12分で読めます

権威DNSの移行手順｜NS切替・TTL・DNSSEC・ロールバックを安全に管理する方法

執筆ファネルAi編集部編集ファネルAi編集部監修ファネルAi監修チーム最終更新2026年9月3日

現行の権威DNSから新しい権威DNSへ安全に切り替え、応答を検証する移行イメージ

権威DNS事業者の移行は、レジストラでネームサーバー（NS）を書き換えるだけの作業ではありません。ゾーン内のレコード、親ゾーンの委任、DNSSECの信頼連鎖、Web・メール・外部SaaSの依存関係が別々のキャッシュ時間で動くため、順序を誤ると一部の利用者だけ名前解決できない状態が長く残ります。

安全に進めるには、現行ゾーンを凍結して新事業者へ複製し、新しい権威DNSを直接照会して内容を確かめ、DNSSECの移行方式を決めてから親ゾーンのNSを変更します。切替後は旧新の権威DNSと複数の再帰リゾルバーを並行して観測し、事前に決めた合格条件を満たすまで旧ゾーンを保持します。

権威DNSの移行では、レコードのTTL、親ゾーンにあるNS・DSのTTL、否定応答のキャッシュを分けて確認し、DNSSECを無効化して移すか、対応事業者間で信頼連鎖を維持するかを先に決めることが重要です。

本記事のポイント

移行前に全レコードと事業者固有機能を複製し、新権威NSの直接照会とTTL・親NS・DS・否定応答の待機時間を切り分けて確認します。
DNSSECは旧DSの失効後にNSを変える方式か、対応事業者間の多重署名方式かを先に決め、自己流で混在させません。
新旧の権威応答と複数リゾルバー、Web・メール・外部連携が基準を満たすまで旧ゾーンを保持します。

移行前にゾーン・権限・依存先を棚卸しする

最初に、対象ゾーンとサブゾーンを一覧化します。A、AAAA、CNAME、MX、TXT、CAA、SRV、NAPTR、TLSAなどのレコードだけでなく、ワイルドカード、委任用NS、DNSSECのDNSKEY・DS、動的更新、セカンダリDNS、Geo DNS、ヘルスチェック、ALIASやANAMEのような事業者固有機能も対象です。ゾーンファイルをエクスポートできても、事業者固有のルーティングやフェイルオーバー設定まで移るとは限りません。

Google Cloud DNSの移行手順でも、既存事業者から設定をエクスポートし、新しいマネージドゾーンへインポートしてからレジストラのNSを更新し、最後に移行を検証する順序が示されています。BIND形式を使う場合は、末尾のドットがない名前がゾーン相対名として解釈される点や、新事業者が自動生成するSOA・NSとインポート値が競合する点も確認します。

棚卸し対象	記録する内容	漏れた場合の影響
ゾーンとレコード	FQDN、種別、値、優先度、TTL、用途、所有部門	Webは開くがメールや外部連携だけ止まる
委任	レジストラ、親ゾーンのNS、glue、変更権限、現在のTTL	新NSへ正しく委任されない、戻せない
DNSSEC	DS、DNSKEY、署名アルゴリズム、鍵管理者、自動ローテーション	検証リゾルバーがSERVFAILを返す
事業者固有機能	Geo、重み付け、ヘルスチェック、flattening、動的更新	同じレコード名でも応答動作が変わる
業務依存	Web、メール、VPN、IdP、API、Webhook、SaaS検証、証明書	トップページの確認だけでは障害を見逃す
運用と証跡	承認者、作業者、連絡先、変更凍結、観測点、切り戻し条件	異常時に判断と復旧が遅れる

新しい権威DNSには、委任を変更する前に全レコードを登録します。各新NSを直接指定してSOA、NS、主要なA・AAAA・CNAME、MX、TXT、CAAを照会し、応答コード、AAフラグ、TTL、値、DNSSEC署名を現行側と照合します。新事業者の自動スキャンだけに依存せず、レコード件数と用途台帳を突き合わせます。Cloudflareも、自動スキャンですべての既存レコードを発見できる保証はないため、特に apex、サブドメイン、メール関連を確認するよう案内しています。

現行DNSの棚卸し、新権威DNSへの複製、DNSSEC判断、親ゾーンのNS・DS切替、旧新並行監視、完了判定へ進む移行フロー — DNS移行は、ゾーン複製、直接照会、DNSSECの方式決定、親ゾーン切替、複数経路での確認を別のゲートとして扱うと、障害箇所と戻す条件を判断しやすくなります。

レジストラや現行DNSの管理アカウントが個人に依存している場合は、移行前に組織管理へ直します。更新期限や決済、緊急連絡先まで含む管理は、企業ドメインの更新期限・権限管理と分けずに確認すると、DNS作業中のアカウントロックや期限切れを防ぎやすくなります。

TTLを下げる対象と戻す時期を分ける

「移行前にTTLを300秒へ下げる」という一律の方法は安全策になりません。ゾーン内のAやMXなどのTTL、ゾーン頂点のNS TTL、親ゾーンが持つ委任NSのTTL、DNSSECのDS TTL、存在しない名前に対する否定応答のキャッシュは別々です。自社が変更できるTTLと、レジストリやレジストラ側で決まるTTLを作業票で分けます。

新旧でレコード値を変える予定がある場合は、少なくとも現在のTTLが一度切れるより前に対象RRsetのTTLを下げます。移行直前に下げても、すでに再帰リゾルバーへ保存された長いTTLは短くなりません。反対に、移行中も旧新が同じ値を返すなら、すべてを極端に短くする必要はありません。短すぎるTTLは権威DNSへの問い合わせ量を増やすため、事業影響と問い合わせ負荷を見て決めます。

親ゾーンの委任NSは、レジストラで変更するときに表示されるTTLや、実際の親ゾーン応答を確認します。Google Cloud DNSも、レジストラのNSを更新した時刻とTTLを記録し、その時間が新NSの利用開始を待つ目安になると説明しています。DNSSECを一度無効化して移す場合は、旧DSを親ゾーンから削除した後、そのDS TTLが切れるまで待ってからNSを変更します。Cloudflareの公式手順は、旧DSがキャッシュに残ったままNSを変えると、新しいDNSKEYと一致せず検証リゾルバーがSERVFAILを返すと注意しています。

TTLを元へ戻すのは、親ゾーンのNSが期待値になっただけでは早すぎます。全新NSの権威応答、複数の再帰リゾルバー、Web・メール・APIなどの業務確認、監視アラートを一定期間見て、旧NSへ届く問い合わせが十分に減ってから段階的に戻します。否定応答のキャッシュが残る場合もあるため、移行前に作った新しい名前が一部環境でNXDOMAINになるときはSOAとnegative cachingも確認します。

NS・DS切替を9ステップで実行する

変更を凍結して基準値を保存する。
移行期間中のDNS変更窓口を一つにし、ゾーン全体、事業者固有設定、現行NS・DS応答、主要URLとメール試験の結果を時刻付きで保存します。緊急変更が入った場合は新旧両方へ反映し、差分台帳を更新します。
新しいゾーンを作り、レコードを複製する。
エクスポート・インポート後に、自動生成されたSOA・NSを除いて件数と値を比較します。相対名、末尾ドット、ワイルドカード、MXの優先度、TXTの分割、CAA、SRVのweight・portなど、形式変換で壊れやすい項目を重点確認します。
新しい全権威NSを直接照会する。
まだ親ゾーンを変えず、各新NSへA・AAAA・MX・TXT・CAA・DNSKEYなどを直接問い合わせます。新NSの一台だけが古い、AAフラグがない、TCP 53で応答しないといった片系差も切替前に解消します。
DNSSECの移行方式を確定する。
一般的な停止方式では、レジストラの旧DSを削除し、DS TTLが切れたことを複数の再帰リゾルバーで確認してからNSを変更し、新事業者側で署名を有効化して新DSを登録します。DNSSEC保護を切らずに移す方式は、新旧事業者が外部DNSKEYの取り込み、複数DS、鍵の自動ローテーション停止、同じアルゴリズムなどを支援する場合だけ選びます。
必要なゾーン内TTLを事前に下げる。
変更予定のRRsetと、障害時に戻す可能性がある値を対象にします。変更前TTLが一度失効するだけの準備時間を取り、実施時刻と元のTTLを記録します。親ゾーンのNS・DS TTLは別欄で管理します。
親ゾーンのNSと必要なglueを更新する。
レジストラまたは親ゾーン管理者へ新NSを登録します。NS名が委任対象ドメインの配下にある場合はglueの更新要否を確認し、親ゾーンが返すNSとglueが意図どおりかを直接照会します。一度に無関係なレコードやCDN設定まで変更しません。
旧新の権威応答を並行監視する。
委任が広がる間は、旧NSと新NSの両方が同じ主要RRsetを返す状態を保ちます。各NSを直接指定した応答と、複数地域・複数事業者の再帰リゾルバー経由の応答を分けて記録し、キャッシュ差と権威側の不整合を混同しません。
業務トランザクションを確認する。
DNS応答だけでなく、Web、ログイン、問い合わせフォーム、メール送受信、API、Webhook、VPN、IdP、証明書発行・更新、外部SaaSのドメイン検証を実行します。CAAやDNSSECに起因する証明書エラーは、CAAレコードと証明書発行制御の観点でも切り分けます。
新DS登録、TTL復元、旧ゾーン終了を順番に閉じる。
停止方式で移行した場合は新事業者側のDNSSECを有効化し、生成されたDSを親へ登録して検証成功を確認します。安定観測後にTTLを戻し、さらに旧NSへの問い合わせが合意した水準まで減ってから旧ゾーンを終了します。旧設定の削除とアカウント解約を同日に行わず、復旧証跡を保管します。

DNSSECを有効なまま移す場合は、単純なNS変更ではありません。Google Cloud DNSの公式資料は、新旧事業者とレジストラが連携し、新しい事業者の公開鍵を旧側でも署名し、親ゾーンへ複数DSを置くなどして、両事業者の応答を検証できる期間を作る方式を説明しています。対応条件を満たせなければ、保護を一時停止する方式へ戻し、未対応の多重署名を自己流で組まない方が安全です。

ゾーン転送を使って旧新の内容を同期する構成では、転送ジョブの成功だけでなくSOAシリアルと主要RRsetを全NSで照合します。移行後もセカンダリDNSを運用する場合は、セカンダリDNSのゾーン転送・SOA監視に沿って日常監視へ引き継ぎます。

ロールバック条件と完了判定を先に決める

ロールバックは「担当者が不安になったら戻す」ではなく、事前の閾値で判断します。主要な権威NSが応答しない、DNSSEC検証がSERVFAILになる、MXやIdPなど重要RRsetが新旧で不一致、Web・メール・認証の正常完了率が基準を下回る、原因と影響範囲を制限時間内に確定できない、といった条件を決めます。

症状	最初に見る証拠	安全側の対応	ロールバック判断
一部利用者だけ古い応答	親NS、問い合わせ先リゾルバー、残TTL、旧新NSの応答	旧新のゾーンを同値で維持してキャッシュ差を観測	新NS自体が正しければ即時のNS往復を避ける
SERVFAILが増加	DS、DNSKEY、RRSIG、全権威NS、検証有無	親子の信頼連鎖を一貫した状態へ戻す	DSと鍵の不一致を解消できない場合は停止
メールだけ不達	MX、SPF、DKIM、DMARC、送受信ログ	不足レコードを新旧へ反映し実送受信を再確認	重要メールの不達が継続する場合は戻す
新NSの片系だけ不一致	各NSのSOA、主要RRset、応答コード、AAフラグ	委任拡大を止めて事業者へ修正依頼	合意時間内に全新NSが揃わなければ戻す
親ゾーンの委任誤り	親へ直接問い合わせたNSとglue	レジストラで正しい委任へ修正	修正不能または権限不明なら旧委任へ戻す
WebやAPIの失敗	DNS応答、TLS、HTTP、アプリログ、外部監視	DNSとアプリ層を分けて原因を特定	DNS起因で重要機能が基準未達なら戻す

NSを旧値へ戻しても、再帰リゾルバーには新しい委任がTTLの間残ります。そのため、旧ゾーンを保持し、新旧どちらへ問い合わせが届いても同じ正しい値を返す期間を作ることが最大のロールバック対策です。DNSSECでは、旧NSへ戻すだけでDSとDNSKEYの整合が回復するとは限りません。親ゾーンのDS、旧新のDNSKEY、キャッシュ残存を確認し、信頼連鎖全体を戻します。

権威DNS移行の完了は、レジストラのNSを変更した時ではなく、新旧の権威応答と複数の再帰リゾルバーを照合し、DNSSEC・Web・メール・外部連携が基準を満たした後に旧ゾーンを閉じられた時です。

完了記録には、親ゾーンの最終NS・DS、全新NSのSOAと主要RRset、DNSSEC検証結果、業務試験、TTL復元値、旧ゾーン終了時刻、例外と残課題を残します。Cloudflare固有のプロキシやSSL/TLSまで同時に導入する場合は、CloudflareへのDNS切替手順を併用し、権威DNS移行とCDN・WAF設定の変更を別の判定ゲートにします。

よくある質問

権威DNSの移行前に何を棚卸ししますか？

全ゾーン、全レコード、事業者固有機能、DNSSEC、親ゾーンの委任、管理権限、Web・メール・認証・外部SaaSの依存先を記録します。エクスポートだけで終えず、各レコードの用途と所有部門も紐付けます。

TTLはいつ下げ、いつ戻しますか？

変更予定のRRsetは、現在のTTLが一度失効するより前に下げます。親ゾーンのNS・DS TTLは別に確認します。切替後、全新NS、複数リゾルバー、業務試験が安定し、旧NSへの問い合わせが十分に減ってから元へ戻します。

NS・DSレコードをどの順番で切り替えますか？

DNSSECを一時停止する方式では、旧DSを親から削除し、そのTTL失効を確認してからNSを変更します。新NSの安定後に新DNSSECを有効化し、新DSを親へ登録します。複数DSを使う無停止移行は、新旧事業者とレジストラが必要機能を支援する場合だけ行います。

移行失敗時にどの条件でロールバックしますか？

DNSSECのSERVFAIL、重要RRsetの不一致、主要NSの応答停止、Web・メール・認証の基準未達、制限時間内に原因を確定できない場合を条件にします。親NSを戻すだけでなく、旧ゾーンとDNSSECの信頼連鎖を一貫した状態に戻します。

旧DNS事業者はいつ解約できますか？

親ゾーンのNS変更後すぐには解約しません。委任キャッシュが失効し、旧NSへの問い合わせが十分に減り、新事業者側でDNSSECと業務試験が安定し、ロールバック期間を終えてから解約します。

新しい権威DNSはどう検証しますか？

委任前に各新NSを直接指定し、SOA、NS、A・AAAA、MX、TXT、CAA、DNSKEYなどを現行側と比較します。委任後は親ゾーン、全権威NS、複数の再帰リゾルバーを分けて確認し、最後にWeb・メール・APIなどの実トランザクションを試します。

仕様確認に使った公式情報

DNS移行を含むWeb基盤の設計・切替・復旧手順を相談する

メディア一覧へ戻る