結論ファースト：ダウンタイムゼロ移行の3つの鉄則
DNSホスティング → レジストラの順で分離移行する
移行前にTTLを短縮し、変更の伝播を高速化する
新旧DNSサービスを並行運用し、完全確認後に切り替える
郵便局の転送届けで理解するDNS移行
DNS移行は「引っ越し時の郵便転送届け」とまったく同じ構造です。住所（ドメイン）宛の手紙（通信）が途切れないように、転送手続き（DNS設定変更）を正しい順番で行う必要があります。
図1：郵便システムとDNSの対応関係マッピング
| 郵便のたとえ | AWS / DNS用語 | 役割 |
|---|---|---|
| 自宅の住所 | ドメイン名（example.com） | あなたを一意に識別する名前 |
| 管轄の郵便局 | DNSホスティングサービス | 「この住所の人はここにいる」と教える場所 |
| 住所録の個別記載情報 | DNSレコード（A, CNAME, MX等） | 実際の配送先の詳細情報 |
| 住所の登記所 | レジストラ（ドメイン登録業者） | 「どの郵便局が担当か」を管理する公的機関 |
| 転送届け | ネームサーバー変更 | 「担当の郵便局が変わりました」と届け出ること |
| 転送有効期間 | TTL（Time to Live） | 古い情報をキャッシュしておく期間 |
補足：NS（Name Server）レコードとは？
NSレコードは「このドメインのDNS情報は、どのネームサーバーが管理しているか」を示す特別なレコードです。郵便のたとえなら、NSレコードは「この住所の管轄郵便局は○○局です」という登記情報にあたります。
世界中のDNSリゾルバは、以下の流れで名前解決を行います：
ns-123.awsdns-45.net のような4つのネームサーバーが割り当てられます。移行Step 4でレジストラのNSをこの4つに書き換えることで、「このドメインの問い合わせ先はRoute 53です」と世界中に通知されます。
DNSホスティング と ドメイン登録 の違い
多くの人がこの2つを混同しますが、まったく別のサービスです。引っ越しに例えると、「どの郵便局を使うか」と「住所の登記をどこで管理するか」は別の話。だから個別に移行できるのです。
DNSホスティング（DNS Service）
ドメインに対応するIPアドレスやメールサーバーの情報を保持し、問い合わせに応答するサービス。
たとえ：「この住所に届いた手紙を、実際にどこに届けるか」を管理する郵便局の業務。
ドメイン登録（Domain Registration）
ドメイン名の所有権を公的に管理し、「どのDNSサーバーが担当か」を記録するサービス。
たとえ：「この住所の管轄郵便局はどこか」を記録している登記所の業務。
それぞれの役割を詳しく見る
ドメイン名の登録と管理を担当する
ドメイン名とそのネームサーバー（NS）レコードを管理する
ドメインのDNSレコード（A、CNAME、MX、TXTなど）を保存・提供する
DNSクエリに応答し、ドメイン名をIPアドレスに解決する
なぜこの順番ならダウンタイムが発生しないのか？
「DNSホスティングを先に移行すれば安全」と言える理由を、各時点の状態を追って確認してみましょう。
❶レジストラ（登記所）が「このドメインの担当NSはここ」と正しく指し示していること
❷その指し示された先のDNSホスティングに、正しいレコードが存在すること
図：各フェーズでの状態追跡 — どの時点でも必ず「指す先」に「正しいレコード」が存在する
移行前（初期状態）
レジストラ → 旧NSを指す
旧DNS → レコードあり ✅
レコードコピー後（NS変更前）
レジストラ → まだ旧NSを指す
旧DNS → レコードあり ✅
Route 53 → レコード準備済（待機中）
NS変更後（伝播中 = 並行運用）
旧キャッシュ利用 → 旧DNS → レコードあり ✅
新NS参照 → Route 53 → レコードあり ✅
伝播完了（移行完了）
レジストラ → Route 53を指す
Route 53 → レコードあり ✅
逆の順番（レジストラを先に移行）だとなぜ危険か？
図：逆順移行の危険性 — 「指す側」を先に変えると不整合が発生し得る
レジストラを先に移管した場合のリスク
新レジストラ →（NSがまだ旧のまま、or 移管中の設定不備）→ 正しいDNSに到達できない ❌
「指し示す側」を先に変えてしまうと、「指す先」と「応答する側」のペアが崩れる瞬間が生まれるリスクがある
「応答できる側（DNSホスティング）を先に準備万端にしておき、最後に参照先（レジストラのNS）を切り替える」からこそ安全。
郵便のたとえなら「新しい郵便局に住所録を全部置いてから、登記所の管轄を変更する」ので、どこに問い合わせが行っても正しく配達できる。
全体フロー：5ステップ移行マップ
以下の5ステップを順番に実行することで、ユーザーに気づかれることなくDNSサービスをRoute 53へ移行できます。
図2：DNS移行5ステップの全体フロー（ホスティング移行 → レジストラ移行の順）
各ステップの詳細と郵便たとえ
移行元DNSでTTLを短縮する
現在のDNSプロバイダーで、すべてのレコードのTTL（Time to Live）を短い値（60〜300秒）に変更します。これにより、後のネームサーバー変更時に古いキャッシュが素早く消えます。
Route 53にホストゾーンを作成 & レコードをコピー
Route 53で新しいホストゾーンを作成し、現在のDNSプロバイダーにあるすべてのレコード（A, AAAA, CNAME, MX, TXT等）を正確にコピーします。SOAレコードとNSレコードはRoute 53が自動生成するため、コピー不要です。
Route 53のレコードが正しく応答するかテスト
dig コマンド等でRoute 53のネームサーバーに直接問い合わせ、各レコードが正しい値を返すことを確認します。ここでミスがあると切り替え後に障害が発生するため、全レコードを慎重にテストします。
レジストラでネームサーバーをRoute 53に変更
ドメインの現在のレジストラ管理画面で、ネームサーバーをRoute 53が発行した4つのNSレコード値に変更します。この変更が全世界に伝播するまで最大48時間かかります（Step 1でTTLを短縮済みなら大幅に短縮）。
（オプション）ドメイン登録もRoute 53に移管
DNSホスティングの移行が安定したら、ドメイン登録自体もRoute 53に移管できます。これにより、DNS管理とドメイン管理をAWSに一元化できます。移管にはロック解除と認証コードの取得が必要です。
TTL（Time to Live）の仕組みと調整戦略
TTLは「DNSレコードがキャッシュに保存される秒数」です。郵便のたとえで言えば「古い住所録をいつまで信用するか」の期限です。
通常時（高TTL）
= 24時間キャッシュ。変更が伝播するまで最長1日。DNSサーバーの負荷は低い。
移行前に短縮（低TTL）
= 1〜5分でキャッシュ更新。変更が数分で世界中に伝播。ただし問い合わせ頻度が増加。
図3：TTL調整のタイムライン（事前短縮 → 移行 → 事後復元）
並行運用フェーズ：新旧DNSの同時稼働
ダウンタイムゼロの鍵は「並行運用期間」です。ネームサーバー変更後も、一部のDNSリゾルバは旧ネームサーバーのキャッシュを保持しています。旧DNSサービスは伝播完了まで維持してください。
変更前
旧DNSのみ稼働。TTL短縮済み。Route 53にレコードコピー完了。
伝播中（並行運用）
新旧両方が応答可能。世界中のリゾルバが順次新NSに切替。旧DNSは削除しない！
伝播完了後
Route 53のみ応答。旧DNSサービスを安全に解約可能。TTLを元に戻す。
図4：並行運用期間中のDNSクエリ遷移（旧DNS → Route 53への段階的切替）
確認コマンド集
移行の各フェーズで使える確認コマンドです。Route 53のネームサーバー（ns-xxx.awsdns-xx.xxx）に直接問い合わせることで、切り替え前にレコードの正しさを検証できます。
図5：移行前後に使用するDNS確認コマンド
移行前チェックリスト
よくある質問（FAQ）
Q. TTLを1秒にすれば最速で伝播するのでは？
A. 技術的には可能ですが、DNSリゾルバへの問い合わせが爆発的に増え、応答速度の低下やDNSサーバーの負荷増大を招きます。実用的には60〜300秒が推奨値です。
Q. ネームサーバー変更後、どのくらいで伝播が完了しますか？
A. TTLを事前に短縮していれば、ほとんどのリゾルバは数分〜数時間で更新されます。ただし一部のISPや企業DNSは独自キャッシュを持つため、完全伝播には最大48〜72時間を見込んでおくと安全です。
Q. ドメイン登録の移管は必ず必要ですか？
A. いいえ。DNSホスティングだけRoute 53に移行し、ドメイン登録は元のレジストラに残すことも可能です。ただし管理の一元化を望む場合はRoute 53への移管がおすすめです。
Q. 移行中にWebサイトやメールが止まることはありますか？
A. 正しい手順（TTL短縮→レコードコピー→確認→NS変更→並行運用）を守れば、ダウンタイムは発生しません。最も多い失敗原因は「レコードのコピー漏れ」と「旧DNSの早期解約」です。