【要約】【Cloudflare】Route 53 からネームサーバーを移行する [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
筆者がCloudflare Workersを利用しようとした際、DNSゾーンをCloudflareへ移行する必要が生じた。移行にあたっては、既存のAWS環境への影響を最小限に抑えつつ、正確にレコードを引き継ぐ必要がある。具体的には以下の課題が存在する。
- ・Cloudflareの自動スキャンは辞書ベースであり、特殊なサブドメインやACM検証用CNAMEを見落とす。
- ・Route 53のAliasレコードが、変動するIPアドレスを持つAレコードとして誤認される。
- ・全レコードが「Proxied」設定になり、既存のCloudFront配信と競合するリスクがある。
// Approach
筆者は、配信基盤（CloudFront）とレジストラ（Route 53 Domains）は維持したまま、DNSホスティングのみをCloudflareへ切り替える方針を採用した。安全性を担保するため、以下のステップで作業を行った。
- ・AWS CLIを用いて
aws route53 list-resource-record-setsを実行し、全レコードを正確に棚卸しする。 - ・Cloudflare側では、既存の配信構成を維持するため、全レコードを「DNS only」に設定する。
- ・切り替え前に
digコマンドを用いて、Cloudflareのネームサーバーが正しい応答を返すか検証する。 - ・万が一の事態に備え、Route 53のホストゾーンは即座に削除せず、ロールバック可能な状態を維持する。
// Result
筆者は、既存のプロフィールサイト、画像CDN、RSSリーダーのすべてにおいて、ダウンタイムなしで移行を完了した。作業は極めて短時間かつ安全に遂行された。
- ・作業時間は棚卸しから確認まで約40分で完了した。
- ・Route 53のホストゾーンを削除することで、月額0.50ドルのコスト削減を実現した。
- ・Cloudflare Workersを利用可能な環境を構築できた。
Senior Engineer Insight
> DNS移行における「自動スキャンの過信」は、本番環境では致命的な事故を招く。特にAliasレコードの挙動や、辞書にないサブドメインの欠落は、実務で頻発するリスクだ。本記事のように、CLIによる棚卸しと
dig による事前検証を徹底するプロセスは、極めて健全である。また、レジストラを動かさずNSのみを変更する手法は、リスクヘッジの観点からも理にかなっている。実戦投入の際は、移行元との完全な突合を絶対条件とすべきだ。