はじめに
本記事では、既存の DNS サーバーから AWS Route 53 へ DNS 環境を移行する手順について解説します。具体例として、ConoHa で管理しているドメインを Route 53 へ移行する際の設定手順に加え、実務の切り替え作業において発生しやすい「セカンダリ DNS（ゾーン転送）に起因するトラブル事例」とその防止策を紹介します。
- 既存環境（ConoHa 等）から Route 53 へ移行するための事前準備と手順
- セカンダリ DNS の削除漏れによるスプリットブレインの発生メカニズムと対策
- ダウンタイムを防ぐための DNS 伝播の確認手法
AWS Route53 とは
AWS Route 53 は、AWS が提供するクラウドベースの DNS ウェブサービスです。ドメイン名（例: example.com）を IP アドレスに変換し、ユーザーを Web サイトなどのリソースへ誘導する役割を担います。
「Route 53」という名前は、インターネットの伝送路（Route）と、DNS サーバーで使用される標準ポート番号（53番）に由来しています。
Route53 のメリット
他の DNS サービスと比較して、主に以下の強みがあります。
世界中に分散されたAWSのデータセンター（エッジロケーション）を使用して名前解決を行うため、低遅延でのアクセスが可能です。SLA（稼働率保証）100%という極めて高い可用性を持ちます。
ユーザーの地理的条件に応じた誘導（位置情報ルーティング）や、サーバー障害時に自動で予備系へ切り替える機能（フェイルオーバー）など、柔軟なトラフィック制御が可能です。
他の AWS サービスと統合して管理できるほか、DNSSEC に対応しており、DNS スプーフィングなどの攻撃からドメインを保護します。
移行の前提条件と準備
移行作業を開始する前に、以下の環境準備と情報のバックアップを行います。
AWS アカウントの準備
Route 53 を利用するための AWS アカウントを作成します。Route 53 には無料枠がなく、ホストゾーン数やクエリ数に応じた従量課金制となりますが、一般的な規模のサイトであれば月額数ドル程度で運用可能です。
現在の DNS 設定のバックアップ
移行時の設定漏れを防ぐため、現在の DNS 管理画面（今回の例では ConoHa）を開き、登録されているレコード情報をすべてメモ（または画面キャプチャ・CSV エクスポート）して記録します。
- Aレコード：Web サーバーなどの IP アドレス
- CNAME レコード：
wwwなどの別名設定 - MX レコード：メールの送受信設定
- TXT レコード：SPF / DKIM などのドメイン認証情報
特に、MX レコードや TXT レコードの移行漏れは、「Web サイトは見れるが、メールが届かない・送信できない」といった重大な障害に直結するため注意が必要です。各 DNS レコードの役割や詳細については、以下の記事も併せてご参照ください。
AWS Route 53 への移行手順
ホストゾーンの作成（AWS 側）
AWS Management Console にログインし、Route 53 ダッシュボードを開きます。
- 「ホストゾーンの作成」 をクリックします。
- ドメイン名（移行するドメイン）を入力します。
- タイプは 「パブリックホストゾーン」 を選択し、作成します。
DNS レコードの登録（AWS 側）
まだネームサーバーは切り替えません。 先に Route 53 側にレコードを準備します。
ConoHa でバックアップしたレコード（A, CNAME, MX, TXT 等）を、Route 53 のホストゾーンに「レコードを作成」から手動で登録していきます。 「移行元（ConoHa）と全く同じ状態」 を Route 53 上に再現してください。
ネームサーバー情報の確認
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ネームサーバーの変更（ConoHa 側）
ここから実際の切り替え作業です。
- ConoHa コントロールパネルにログインし、「ドメイン」管理画面を開きます。
- 「ネームサーバー設定」の項目を開きます。
- 現在の ConoHa のネームサーバーを削除し、STEP 3 でメモした Route 53 の 4 つのネームサーバー に書き換えます。
- 「保存」をクリックします。
ネームサーバーの変更が世界中に反映されるまで、数時間〜最大72時間かかる場合があります（DNS 伝播）
- 実施タイミング: アクセスの少ない 夜間や休日 に作業することをおすすめします。
- 一時的な不安定: 切り替え中は「古いサーバー」と「新しいサーバー」のどちらに繋がるか不安定になる可能性があります。
- 事後確認: 変更後は Web サイトの表示だけでなく、メールの送受信 が正常に行えるか必ず確認してください。
実際のトラブル事例 | 旧環境のセカンダリ DNS によるスプリットブレイン
DNS 移行において、旧環境で「セカンダリ DNS（ゾーン転送）」を利用していた場合、切り替え後に新旧の DNS 情報が混在して応答される「スプリットブレイン状態」に陥るリスクがあります。
事象のメカニズムと原因
過去の事例として、旧環境（オンプレミス等の BIND サーバー）から、プロバイダ（OCN など）が提供する無料セカンダリ DNS に対してゾーン転送を許可していたケースがあります。
この設定が残っていると、ドメイン管理側でネームサーバーを Route 53 へ切り替えても、以下の事象が発生します。
プロバイダ側のセカンダリ DNS が、旧オンプレ DNS から古いレコード情報を定期的にコピー（ゾーン転送）し続ける。
プロバイダ側の DNS が権威サーバーとして、世界中からの問い合わせに対して古い情報を代理で応答し続ける。
結果として、DNS クライアントは「Route 53 の新しい情報」と「プロバイダ DNS の古い情報」の両方をランダムに取得してしまい、Web アクセスやメール配送が不安定になります。
必須となる対策
プロバイダ等に限らず、DNS サーバーを移行する際は、切り替え作業前（または同時）に必ず「旧環境のセカンダリDNS 設定（ゾーン転送の許可）を削除し、古い情報を代理で応答しないように無効化する」ことが必須です。
切り替え時の注意事項と伝播の確認方法
ネームサーバーの変更作業が完了しても、その情報が世界中の DNS サーバーに反映（DNS 伝播）されるまでには、数時間から最大で72時間程度かかる場合があります。
実施タイミングと一時的な不安定さの考慮
伝播期間中は、アクセスするユーザーの環境によって「Route 53 の新しい情報」と「旧環境の古い情報」のどちらを参照するかが不安定になります。そのため、切り替え作業はアクセスや業務への影響が少ない夜間や休日に実施することを推奨します。
また、Web サイトの表示確認だけでなく、旧環境へのメールの取りこぼしがないか、送受信テストも併せて実施してください。
nslookup / dig コマンドでの確認手法
手元の PC（ターミナルやコマンドプロンプト）から以下のコマンドを実行し、Route 53 のネームサーバーが正しく応答するか確認します。
ネームサーバー（NS レコード）の確認
$ nslookup -type=ns example.comWeb サーバー（A レコード）の確認
$ nslookup example.com実行結果の nameserver の部分に、STEP3 で確認した Route 53 のサーバー名（例：awsdns-xx.com）が表示されていれば、切り替えが正常に始まっています。
世界的な伝播状況の確認（DNS チェックツール）
自環境のコマンドだけでなく、外部のネットワークから正しく名前解決ができているかを確認したい場合は、Web ブラウザ上で手軽に実行できる DNS チェックツールの利用が便利です。
当ブログでも専用の確認ツールを公開しています。以下のページにアクセスして対象のドメインを入力し、Route 53 で設定した新しい IP アドレスが正常に返ってくるかを確認してください。
まとめ
本記事では、既存環境から AWS Route 53 への DNS 移行手順と、実務で陥りやすいトラブル対策について解説しました。
- 移行作業は、必ず既存の DNS レコード（特に MX/TXT）をバックアップしてから開始する。
- Route 53 側にすべてのレコードを登録した後に、ネームサーバーの切り替えを実施する。
- スプリットブレインを防ぐため、旧環境のセカンダリ DNS（ゾーン転送）設定は必ず削除する。
- 切り替え後はコマンドやツールを用いて伝播状況を確認し、Webとメールの動作検証を行う。
以上、最後までお読みいただきありがとうございました。
