2026年6月12日
AWS Route 53 のようなクラウド DNS から Google Cloud DNS へ移すときの難所は、標準のゾーンファイルに書けない独自機能のレコードです。Route 53 の ALIAS レコード、加重やフェイルオーバーといったルーティングポリシー、それに結び付いたヘルスチェックは、そのままでは Cloud DNS へ持っていけません。標準のレコードは書き出して変換し、一括でインポートする。独自機能のレコードは、置き換え方を先に一つずつ決める。この二つに分けて進めると、移行当日に慌てずに済みます。
この記事では Route 53 からの移行を例に、レコードの棚卸し、BIND 形式への変換、ALIAS とルーティングポリシーの置き換え、Cloud DNS での照合、ネームサーバーの切り替えと Route 53 の片付けまでを説明します。Cloudflare や Azure DNS など、ほかのクラウド DNS から移す場合も考え方は同じです。AWS CLI・gcloud・各サービスの仕様は更新されるため（2026年10月現在の情報です）、実行前に --help と公式ドキュメントで手元の環境の動作を確認してください。作業前には Route 53 のレコードを書き出したファイルをバックアップとして保管しておきます。
移行前に、レコードを3種類に分ける
Route 53 のホストゾーンにあるレコードは、移行の扱いで次の3種類に分かれます。
- 標準のレコード：A・AAAA・CNAME・MX・TXT・CAA・SRV、サブドメインを委任する NS など。値を変換すれば Cloud DNS にそのまま登録できます。
- ALIAS レコード：CloudFront・ロードバランサー・S3 などの AWS リソースや、同じゾーンの別レコードを指す Route 53 独自のレコードです。Cloud DNS には同じ仕組みがないため、置き換えが必要です。
- ルーティングポリシー付きのレコード：加重・フェイルオーバー・位置情報・レイテンシーなどで、同じ名前に複数のレコードがあり、識別子（SetIdentifier）が付いています。ヘルスチェックと組み合わせているものもあります。
まずホストゾーンの ID を調べ、全レコードを JSON で書き出してから、3種類に分けて一覧にします。
# ホストゾーンIDを調べる（example.com は自分のドメインに置き換え）
aws route53 list-hosted-zones-by-name --dns-name example.com \
--query "HostedZones[0].Id" --output text
# 全レコードを書き出す（AWS CLI は既定で全ページを取得する）
aws route53 list-resource-record-sets \
--hosted-zone-id Z0123456789EXAMPLE --output json > r53.json
# 種類ごとに一覧を出す
jq -r '.ResourceRecordSets[]
| [ .Name, .Type,
(if .AliasTarget then "ALIAS -> " + .AliasTarget.DNSName
elif .SetIdentifier then "ROUTING: " + .SetIdentifier
else "standard" end) ]
| @tsv' r53.jsonALIAS と ROUTING の行が、手順2で個別に方針を決める対象です。
手順1：標準のレコードを BIND 形式に変換する
標準のレコードだけを取り出し、Cloud DNS がインポートできる BIND 形式のゾーンファイルにします。ゾーン頂点の SOA と NS は Cloud DNS が自動で用意するため除外し、サブドメインを委任している NS は残します。
APEX="example.com."
jq -r --arg apex "$APEX" '
.ResourceRecordSets[]
| select(.ResourceRecords != null and .SetIdentifier == null)
| select(((.Name == $apex) and (.Type == "SOA" or .Type == "NS")) | not)
| . as $r
| .ResourceRecords[]
| (if ($r.Type | IN("CNAME","NS","MX","SRV","PTR")) and (.Value | endswith(".") | not)
then .Value + "." else .Value end) as $v
| "\($r.Name) \($r.TTL) IN \($r.Type) \($v)"
' r53.json | sed 's/\\052/*/g' > example.com.zoneこの変換で気を付けている点は三つです。
- 値の末尾のドット：Route 53 では CNAME や MX の値を末尾のドットなしで登録しても完全な名前として扱われますが、BIND 形式ではドットのない名前にゾーン名が付け足されます。そのため、ドットがない値に付け足しています。
- ワイルドカード：Route 53 は
*を\052という表記で返すため、sed で*に戻しています。ほかの記号を含む名前がある場合は、出力を目で確かめてください。 - TXT の引用符：Route 53 は TXT の値を引用符付きで返すので、そのままゾーンファイルに使えます。255 文字を超える DKIM の値は複数の引用符付き文字列に分かれていることがあり、その形も BIND 形式として有効です。
AWS Certificate Manager（ACM）の DNS 検証用の CNAME（_ で始まる名前から acm-validations.aws へ向くもの）も標準のレコードとして含まれます。移行後も CloudFront やロードバランサーで ACM の証明書を使い続ける場合、このレコードを消すと証明書の自動更新に失敗するため、Cloud DNS 側に残します。
手順2：ALIAS とルーティングポリシーの置き換え方を決める
ALIAS レコード
ALIAS の置き換え方は、指している先が移行後どうなるかで決まります。
- サイトも Google Cloud へ移す場合：新しいサーバーや外部ロードバランサーに予約した静的 IP を、A レコードで指定します。
- サブドメインの ALIAS（www など）で、先が AWS に残る場合：ALIAS の DNSName（CloudFront の配信ドメインやロードバランサーの DNS 名）を値にした CNAME に置き換えます。
- ゾーン頂点の ALIAS で、先が AWS に残る場合：頂点には CNAME を置けず、Cloud DNS には ALIAS に当たる仕組みがありません。ロードバランサーや CloudFront の IP は変わるため、その時点の IP を A レコードに書き写す方法はとらないでください。頂点の扱いが決まらない場合は、移行の範囲や時期を見直します。
ルーティングポリシーとヘルスチェック
Cloud DNS にも、加重ラウンドロビン・位置情報・フェイルオーバーといったルーティングポリシーがあります。ただし、ヘルスチェックを組み合わせられる対象や条件は Route 53 と同じではなく、Google Cloud のロードバランサーを前提とした機能もあります。移行先で同じ動作を作れるかを公式ドキュメントで確認し、作れない場合は「移行を機に単純な構成にする」か「振り分けをロードバランサー側に任せる」かを決めます。Route 53 のヘルスチェックそのものは移せないため、監視の役目を別の仕組みに持たせることも忘れないようにします。
決めた置き換えのレコードは、手順1のゾーンファイルに追記しておきます。
手順3：Cloud DNS にインポートして照合する
Cloud DNS に公開ゾーンを作り、ゾーンファイルをインポートします。頂点の NS は既定で取り込まれず、Cloud DNS が割り当てたネームサーバーが使われます。
gcloud dns managed-zones create example-com \
--dns-name="example.com." \
--description="migrated from route53" \
--visibility=public
gcloud dns record-sets import example.com.zone \
--zone=example-com --zone-file-format
# 割り当てられたネームサーバーを確認する
gcloud dns managed-zones describe example-com --format="value(nameServers)"ネームサーバーを変える前に、Route 53 と Cloud DNS の両方へ直接問い合わせて答えを比べます。Route 53 側のネームサーバー名は aws route53 get-hosted-zone --id Z0123456789EXAMPLE --query "DelegationSet.NameServers" で確認できます。
OLD="ns-123.awsdns-45.com" # Route 53 の名前に置き換え
NEW="ns-cloud-a1.googledomains.com" # describe で確認した名前に置き換え
for q in "example.com A" "www.example.com CNAME" "example.com MX" "example.com TXT"; do
echo "== $q"
echo "旧: $(dig +short @"$OLD" $q | sort | tr '\n' ' ')"
echo "新: $(dig +short @"$NEW" $q | sort | tr '\n' ' ')"
doneALIAS を CNAME や A に置き換えた名前は、答えの形が変わるので差分として出ます。Cloud DNS のネームサーバーは自分のゾーンの答えしか返さないため、CNAME に置き換えた名前では、返ってきた CNAME の値が手順の一覧にある ALIAS の DNSName と一致するかを確かめ、その DNSName を公開リゾルバーで引いて（例：dig +short @1.1.1.1 d111111abcdef8.cloudfront.net A）接続先が生きていることを確認します。
手順4：DNSSEC を確認してネームサーバーを切り替える
Route 53 で DNSSEC の署名を有効にし、レジストラに DS レコードを登録している場合は、先に DS を削除し、DS の TTL ぶん以上待ってから切り替えます。Route 53 側の署名は、DS の削除が行き渡るまで止めないでください。署名を先に止めると、DS が残っている間は検証するリゾルバーから名前が引けなくなります。Cloud DNS で DNSSEC を有効にするのは、切り替えが安定してからです。
ドメインを Route 53 Domains で登録している場合は、AWS CLI でネームサーバーを変更できます。Route 53 Domains の API はバージニア北部（us-east-1）リージョンで呼び出します。
aws route53domains update-domain-nameservers --region us-east-1 \
--domain-name example.com \
--nameservers Name=ns-cloud-a1.googledomains.com Name=ns-cloud-a2.googledomains.com \
Name=ns-cloud-a3.googledomains.com Name=ns-cloud-a4.googledomains.comほかのレジストラで登録している場合は、その管理画面でネームサーバーを Cloud DNS の4つの名前に変更します。
切り替え後と Route 53 の片付け
切り替え後は、dig example.com NS +trace で委任先が Cloud DNS に変わったことを確かめ、サイトの表示、WordPress の管理画面へのログイン、外部とのメールの送受信、証明書の更新に使うレコードを確認します。
Route 53 のホストゾーンは、上位の NS のキャッシュが切れて問い合わせが来なくなるまで残します。移行期間中にレコードを変えた場合は、Route 53 にも同じ変更を入れます。不要になったホストゾーンや、ALIAS の置き換えで使わなくなったヘルスチェックを削除するのは、問題がないことを数日以上確かめてからにしてください。削除の前に r53.json を保管しておけば、必要になったときに内容を確認できます。
まとめ
- クラウド DNS からの移行では、レコードを「標準」「ALIAS」「ルーティングポリシー付き」に分けて扱います。
- 標準のレコードは JSON から BIND 形式に変換し、末尾のドット・ワイルドカード表記・頂点の SOA と NS に注意してインポートします。ACM の検証用 CNAME は残します。
- ALIAS は指している先に応じて A か CNAME に置き換え、頂点の ALIAS が AWS に残る場合は移行の範囲から見直します。
- ルーティングポリシーとヘルスチェックは同じ動作を作れるかを確かめ、単純化するか別の仕組みに任せます。
- DNSSEC は DS を外して待ってから切り替え、Route 53 のゾーンとヘルスチェックはしばらく残してから片付けます。