Route 53 への DNS 移行手順とゾーン転送が招くスプリットブレインの対処

はじめに

本記事では、既存の DNS サーバーから AWS Route 53 へ DNS 環境を移行する手順を解説します。具体例として、ConoHa で管理しているドメインを Route 53 へ移行する際の設定手順に加え、実務の切り替え作業で発生しやすい「セカンダリ DNS（ゾーン転送）に起因するスプリットブレイン」とその検知・対策を紹介します。

DNS 移行で最も注意したいのは、ネームサーバーの切り替えそのものよりも、切り替え前後の「古い情報の残存」です。旧環境にゾーン転送（セカンダリ DNS）設定が残っていると、新旧のレコードが混在して応答され、Web やメールが断続的に不安定になります。先に Route 53 側へ全レコードを登録し、TTL を事前に短縮したうえで切り替えることで、影響時間と切戻しリスクを抑えられます。

AWS Route 53 とは

AWS Route 53 は、AWS が提供するクラウドベースの DNS ウェブサービスです。ドメイン名（例: example.com）を IP アドレスに変換し、ユーザーを Web サイトなどのリソースへ誘導する役割を担います。

「Route 53」という名前は、インターネットの伝送路（Route）と、DNS で使用される標準ポート番号（53 番）に由来しています。

Route 53 の主なメリット

他の DNS サービスと比較して、主に以下の特徴があります。

高速かつ安定した名前解決

世界中に分散された 200 以上のエッジロケーション（anycast ネットワーク）で名前解決を行うため、低遅延でのアクセスが可能です。認証 DNS（ホストゾーン）については 100% の稼働率を定めた SLA を提供しており、可用性を重視する用途に向いています。

高度なトラフィック管理

ユーザーの地理的条件に応じた誘導（位置情報ルーティング）や、サーバー障害時に予備系へ自動で切り替える機能（フェイルオーバー）など、柔軟なトラフィック制御が可能です。

一元管理とセキュリティ

他の AWS サービスと統合して管理できるほか、DNSSEC に対応しており、DNS スプーフィングなどの攻撃からドメインを保護します。なお 2026 年 4 月には、リージョン障害時でも DNS レコードの変更を一定時間内に回復できる Accelerated Recovery 機能が追加され、運用継続性がさらに強化されました。

参考: Amazon Route 53 pricing（AWS 公式）
“A hosted zone includes up to 10,000 records.”
（1 つのホストゾーンには 10,000 件までのレコードを含められます）
https://aws.amazon.com/route53/pricing/

Route 53 を選ぶべきか ｜ 主要 DNS サービスの簡易比較

移行先として Route 53 が常に最適とは限りません。すでに AWS 上でインフラを運用しているなら統合性の面で Route 53 が有力ですが、コストを最小化したい場合や他クラウドを主に使う場合は、別の選択肢が向くこともあります。2026 年時点での主要サービスを簡単に整理します。

参考: DNS Infrastructure Compared（inventivehq）
“Cloudflare DNS is free at every scale.”
（Cloudflare の DNS は規模を問わず無料）
https://inventivehq.com/blog/cloudflare-dns-vs-route-53-vs-azure-dns-vs-google-cloud-dns-comparison

選定の目安としては、AWS 中心の構成なら統合性とエイリアスレコードの無料クエリが活きる Route 53、固定費を抑えたい個人サイトや小規模構成なら無料の Cloudflare、といった整理が分かりやすいです。

移行の前提条件と準備

移行作業を開始する前に、以下の環境準備と情報のバックアップを行います。

AWS アカウントの準備

Route 53 を利用するための AWS アカウントを作成します。Route 53 に無料枠はなく、ホストゾーン数とクエリ数に応じた従量課金制です。2026 年 6 月時点の料金は、公開ホストゾーンが最初の 25 個まで 1 個あたり 0.50 USD/月（26 個目以降は 0.10 USD/月）、標準クエリが 100 万件あたり 0.40 USD です（2026 年 2 月に値下げ）。たとえば 1 ドメインで月間クエリが 100 万件程度なら、月額はおおむね 1 USD 未満に収まります。CloudFront や ELB、S3 などの AWS リソースへ向けたエイリアスレコードのクエリは無料です。

現在の DNS 設定のバックアップ

移行時の設定漏れを防ぐため、現在の DNS 管理画面（今回の例では ConoHa）を開き、登録されているレコード情報をすべて記録します（メモ・画面キャプチャ・CSV エクスポート等）。

バックアップ対象の主なレコード

• A レコード: Web サーバーなどの IP アドレス
• CNAME レコード: www などの別名設定
• MX レコード: メールの送受信設定
• TXT レコード: SPF / DKIM などのドメイン認証情報
• CAA レコード: 証明書発行を許可する認証局の指定（設定済みの場合）

特に MX レコードや TXT レコードの移行漏れは、「Web サイトは見えるがメールが届かない・送信できない」という障害につながりやすいため注意が必要です。各レコードの役割や詳細は、『DNS レコードの種類と A・CNAME・MX・TXT の違いと使い分けのポイント』も参照してください。

切り替え前の TTL 短縮でダウンタイムを抑える

DNS 移行で見落とされやすいのが、切り替え前の TTL（Time To Live）の調整です。TTL は各レコードがリゾルバーにキャッシュされる秒数で、値が大きいほど古い情報が長く残ります。移行直前に TTL が長い（例: 3600〜86400 秒）ままだと、切り替え後も古い情報を参照し続けるリゾルバーが多く残り、切戻しが必要になった際の復旧にも時間がかかります。

そこで、切り替え作業の数日前に、移行対象レコードの TTL を短い値（例: 300 秒）へ下げておくことをおすすめします。これにより、リゾルバー側のキャッシュが短時間で更新され、切り替え時の影響時間と切戻しリスクを抑えられます。重要なのは、TTL を下げてから「下げる前の旧 TTL の秒数」が経過するのを待ってから切り替える点です。旧 TTL がまだキャッシュに残っている間に切り替えても、短縮の効果はすぐには現れません。

AWS 公式の「使用中ドメインの移行手順」でも、レコード登録の後に TTL を短縮し、旧 TTL の失効を待ってからネームサーバーを切り替える順序が案内されています。切り替え後に名前解決が安定したら、NS レコードの TTL は元の長い値へ戻します（AWS は NS レコードに 172800 秒を推奨）

参考: Making Route 53 the DNS service for a domain that’s in use（AWS 公式）
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/migrate-dns-domain-in-use.html

AWS Route 53 への移行手順

移行フロー

STEP

ホストゾーンの作成（AWS 側）

AWS Management Console にログインし、Route 53 ダッシュボードを開いて「ホストゾーンの作成」をクリックします。

移行するドメイン名を入力します。タイプは「パブリックホストゾーン」を選択して作成します。

STEP

DNS レコードの登録（AWS 側）

この段階ではまだネームサーバーを切り替えません。先に Route 53 側へレコードを準備します。ConoHa でバックアップしたレコード（A、CNAME、MX、TXT 等）を、Route 53 のホストゾーンに「レコードを作成」から登録し、移行元（ConoHa）と同じ状態を Route 53 上に再現します。この「先に登録、後で切替」の順序が、切り替え時のダウンタイムを避けるための基本です。

STEP

ネームサーバー情報の確認

Route 53 のホストゾーン詳細画面にある NS レコードを確認します。通常、以下のように 4 つのサーバー名が表示されるため、これを控えます。

ns-xxx.awsdns-xx.com
ns-xxx.awsdns-xx.net
ns-xxx.awsdns-xx.org
ns-xxx.awsdns-xx.co.uk

STEP

ネームサーバーの変更（ConoHa 側）

ここから実際の切り替え作業です。

1. ConoHa コントロールパネルにログインし、「ドメイン」管理画面を開きます。
2. 「ネームサーバー設定」の項目を開きます。
3. 現在の ConoHa のネームサーバーを削除し、STEP 3 で控えた Route 53 の 4 つのネームサーバーに書き換えます。
4. 「保存」をクリックします。

切り替え時の注意点

• ネームサーバーの変更が反映されるまで、TTL とレジストリ側の更新に依存して時間がかかります（後述）。
• 実施タイミングは、アクセスの少ない夜間や休日をおすすめします。
• 切り替え中は古い情報と新しい情報のどちらに繋がるかが不安定になる場合があります。
• 変更後は Web サイトの表示だけでなく、メールの送受信も確認することをおすすめします。

DNSSEC を設定済みの場合の注意点

旧環境で DNSSEC（DNS Security Extensions）を有効化し、レジストラ（親ゾーン）に DS（Delegation Signer）レコードを登録済みの場合は、ネームサーバーの切り替え手順に追加の注意が必要です。

DNSSEC は、署名に使う鍵と、親ゾーンに登録した DS レコードによる「信頼の連鎖」で検証が成り立ちます。旧環境の DNSSEC を有効にしたままネームサーバーを Route 53 へ切り替えると、親ゾーンの DS レコードが指す鍵と Route 53 側の署名が一致せず、DNSSEC 検証を行うリゾルバーが SERVFAIL を返し、対象ドメインの名前解決が広範囲で失敗するおそれがあります。

参考: Making Route 53 the DNS service for a domain that’s in use（AWS 公式）
“Route 53 does not currently support migrating the DNSSEC setting.”
（Route 53 は現時点で DNSSEC 設定の移行をサポートしていません）
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/migrate-dns-domain-in-use.html

そのため、AWS 公式手順では DNSSEC を構成済みのドメインについて、以下の順序が案内されています。

1. ネームサーバーの切り替え前に、レジストラ（親ゾーン）から DS レコードを削除し、DNSSEC 検証を一時的に無効化する。
2. 削除した DS レコードの TTL が失効するまで待つ（この間は検証が無効化される）
3. ネームサーバーを Route 53 へ切り替える。
4. 移行と動作確認が完了したのち、Route 53 側で DNSSEC 署名を有効化し、KMS のカスタマー管理キーをもとに KSK（Key Signing Key）を作成する。
5. Route 53 が生成した新しい DS レコードを、改めてレジストラ（親ゾーン）に登録して信頼の連鎖を再構築する。

DNSSEC を利用していない一般的なドメインでは、この手順は不要です。自ドメインで DNSSEC が有効かどうかは、次のコマンドで DS レコードの有無を確認できます。

$ dig DS example.com +short

応答に DS レコードが返る場合は DNSSEC が有効化されているため、上記の手順に沿って切り替えることをおすすめします。

実際のトラブル事例 ｜ 旧環境のセカンダリ DNS によるスプリットブレイン

DNS 移行において、旧環境で「セカンダリ DNS（ゾーン転送）」を利用していた場合、切り替え後に新旧の DNS 情報が混在して応答される「スプリットブレイン状態」に陥るリスクがあります。

事象のメカニズムと原因

過去の事例として、旧環境（オンプレミス等の BIND サーバー）から、プロバイダー（OCN など）が提供する無料セカンダリ DNS に対してゾーン転送を許可していたケースがあります。この設定が残っていると、ドメイン管理側でネームサーバーを Route 53 へ切り替えても、以下が発生します。

 古い情報の継続コピー（ゾーン転送）:
プロバイダー側のセカンダリ DNS が、旧オンプレ DNS から古いレコード情報を定期的にコピーし続ける。

 権威サーバーとしての代理応答:
プロバイダー側の DNS が権威サーバーとして、問い合わせに対して古い情報を代理で応答し続ける。

 新旧情報の混在（スプリットブレイン状態）:
結果として、DNS クライアントが「Route 53 の新しい情報」と「プロバイダー DNS の古い情報」の両方をランダムに取得し、Web アクセスやメール配送が不安定になる。

対策

プロバイダーに限らず、DNS サーバーを移行する際は、切り替え作業の前（または同時）に、旧環境のセカンダリ DNS 設定（ゾーン転送の許可）を削除し、古い情報を代理応答しないよう無効化しておくことを強く推奨します。

切り替え前後にゾーン転送設定の残存を確認する

スプリットブレインを防ぐには、対策を知っているだけでなく、切り替え前に旧環境のゾーン転送（セカンダリ DNS）設定が残っていないかを実際に確認することが効果的です。ここでは確認に使えるコマンドを紹介します。

まず、レジストラ（親ゾーン）が委任しているネームサーバーと、旧環境のゾーンが返すネームサーバーを比較し、意図しない（旧プロバイダーの）NS が残っていないかを確認します。

$ dig NS example.com +short

次に、旧環境のプライマリ DNS に対してゾーン転送（AXFR）が許可されたままになっていないかを確認します。許可が残っていると、ゾーン全体が応答として返ってきます。

$ dig AXFR example.com @<旧プライマリ DNS のホスト名または IP>

ゾーン全体のレコードが返る場合は、ゾーン転送が許可された状態です。旧環境のセカンダリ DNS がこの転送によって古い情報を保持し続けるため、切り替え前に旧プライマリ側でゾーン転送の許可を解除し、セカンダリ DNS 側の権威設定も無効化しておくことをおすすめします。

さらに、切り替え後に「旧環境のセカンダリ DNS がまだ古い情報を権威応答していないか」を確認するには、旧環境の各ネームサーバーへ直接問い合わせ、Route 53 以外のサーバーが応答を返さないかを確かめます。

$ dig example.com @<旧セカンダリ DNS のホスト名または IP>

旧サーバーが古い IP アドレスを返し続ける場合は、ゾーン転送の解除と権威設定の無効化が完了していない可能性があります。

切り替え後の伝播確認とダウンタイム対策

ネームサーバーの変更作業が完了しても、その情報が各 DNS リゾルバーに反映（DNS 伝播）されるまでには時間がかかります。反映に要する時間は各レコードに設定された TTL とレジストリ側の更新タイミングに依存し、実務では数分から数時間で反映されることが多い一方、キャッシュの状況によっては反映完了までに最大 48〜72 時間程度を見込んでおくと安全です。

実施タイミングと一時的な不安定さの考慮

伝播期間中は、アクセスするユーザーの環境によって「Route 53 の新しい情報」と「旧環境の古い情報」のどちらを参照するかが不安定になります。そのため、切り替え作業はアクセスや業務への影響が少ない夜間や休日に実施することをおすすめします。また、Web サイトの表示確認だけでなく、旧環境へのメールの取りこぼしがないか、送受信テストも併せて実施することをおすすめします。

nslookup / dig コマンドでの確認手法

手元の PC（ターミナルやコマンドプロンプト）から以下のコマンドを実行し、Route 53 のネームサーバーが正しく応答するかを確認します。

ネームサーバー（NS レコード）の確認:

$ dig NS example.com +short
（Windows の場合）> nslookup -type=ns example.com

応答結果に、STEP 3 で控えた Route 53 のサーバー名（例: awsdns-xx.com）が表示されていれば、切り替えが反映され始めています。

権威サーバーと SOA レコードの確認（どちらの DNS が応答しているかを判別）:

$ dig SOA example.com

委任経路の追跡（ルートから順にどの NS に委任されているかを確認）:

$ dig +trace example.com

Web サーバー（A レコード）の確認:

$ dig example.com +short
（Windows の場合）> nslookup example.com

世界的な伝播状況の確認（DNS チェックツール）

自環境のコマンドだけでなく、外部のネットワークから正しく名前解決ができているかも確認したい場合は、Web ブラウザ上で実行できる DNS チェックツールが便利です。当ブログでも確認ツールを公開しているため、対象ドメインを入力し、Route 53 で設定した新しい IP アドレスが返るかを確認してください。

まとめ

本記事では、既存環境から AWS Route 53 への DNS 移行手順と、実務で陥りやすいトラブル対策を解説しました。移行の成否を分けるのは切り替え操作そのものよりも、切り替え前後の古い情報の残存をどう抑えるかにあります。TTL の事前短縮、DNSSEC とゾーン転送の確認を押さえることで、ダウンタイムと切戻しリスクを抑えた移行につながります。

• 既存レコード（特に MX・TXT）の事前バックアップ
• Route 53 へ全レコードを登録してからネームサーバーを切替
• 切り替え数日前の TTL 短縮による影響時間の圧縮
• DNSSEC 利用時は DS レコード削除を先行し移行後に再有効化
• 旧環境のゾーン転送設定の解除によるスプリットブレイン防止
• dig や DNS チェックツールでの伝播と Web・メールの動作確認

以上、最後までお読みいただきありがとうございました。