ほかの DNS サービスから Google Cloud DNS へ移るときは、旧 DNS のレコードを BIND 形式のゾーンファイルにまとめ、gcloud dns record-sets import で一括登録し、Cloud DNS のネームサーバーへ直接問い合わせて照合してから、レジストラでネームサーバーを切り替えるのが基本の流れです。この記事では、gcloud コマンドを使った移行を、ゾーンファイルの整え方、インポート時の注意、照合の方法、DNSSEC の扱い、切り替え後の確認まで順に説明します。
ゾーンの作り方そのもの（公開ゾーンと限定公開ゾーンの違い、レコードの個別追加、サブドメインの委任）は、Cloud DNS のゾーン作成手順を扱った別記事で詳しく説明しています。ここでは「既存のドメインを止めずに移す」ことに絞ります。gcloud のフラグや Cloud DNS の機能は更新されることがあるため（2026年10月現在）、実行前に gcloud dns record-sets import --help などで手元のバージョンの説明を確認してください。
移行の前に決めておくこと
作業を始める前に、次の三つを決めます。
- Google Cloud のプロジェクト：DNS のゾーンはプロジェクトに属し、課金と権限もプロジェクト単位で管理されます。本番のドメインは、検証用とは別のプロジェクトに置くのが一般的です。
- 作業する人の権限：ゾーンとレコードの作成には DNS の管理者権限（
roles/dns.adminなど）が必要です。移行後の日常運用では、レコード変更だけを許す権限に絞ることも検討します。 - 切り替えの日時：メールの送受信が少ない時間帯を選び、担当者が数時間は様子を見られる日にします。
Cloud DNS の API が有効になっていない場合は、最初に有効にします。
gcloud config set project your-project-id
gcloud services enable dns.googleapis.com手順1：旧 DNS のレコードをゾーンファイルにする
旧 DNS の管理画面にゾーンファイルの書き出し機能があれば、それを使います。機能がない場合は、レコード一覧を見ながら BIND 形式のファイルを作ります。外部からのゾーン転送（AXFR）は多くのサービスで許可されていないため、dig でゾーン全体を取り出すことはできないと考えてください。
$ORIGIN example.com.
$TTL 3600
@ 300 IN A 203.0.113.10
www 300 IN CNAME example.com.
@ 3600 IN MX 10 mail.example.net.
@ 3600 IN TXT "v=spf1 include:_spf.example.net ~all"
_dmarc 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
selector1._domainkey 3600 IN CNAME selector1.dkim.example.net.
@ 3600 IN CAA 0 issue "letsencrypt.org"書き出したファイルを使う前に、次の点を見直します。
- SOA と頂点の NS：これらは Cloud DNS がゾーン作成時に自動で用意します。旧 DNS の値がファイルに含まれていても、そのまま使うものではありません（扱いは後述）。
- 名前の末尾のドット：
example.net.のように末尾にドットがある名前は完全な名前、ドットがない名前は$ORIGINが付け足されます。CNAME や MX の値でドットを付け忘れると、mail.example.net.example.com.のような意図しない値になります。 - TTL：切り替え直後に直せるよう、サイトの A や CNAME は 300 秒程度にしておきます。
- 旧サービス固有の記法：一部のサービスは、独自の転送レコードや ALIAS のような標準外のレコードを書き出すことがあります。Cloud DNS に同じ種類がない場合は、A レコードに置き換えるなど別の形にします。
手順2：Cloud DNS にゾーンを作ってインポートする
公開ゾーンを作ります。--dns-name は末尾にドットを付けたドメイン名、ゾーン名（ここでは example-com）はプロジェクト内での識別名で、ドメイン名とは別に決めます。
gcloud dns managed-zones create example-com \
--dns-name="example.com." \
--description="example.com production" \
--visibility=public
gcloud dns record-sets import example.com.zone \
--zone=example-com \
--zone-file-format--zone-file-format を付けると、BIND 形式のファイルとして読み込みます。付けない場合は YAML 形式（gcloud dns record-sets export が既定で書き出す形式）として扱われます。
インポートで迷いやすいのが、ゾーン頂点の NS と SOA の扱いです。既定では、ファイルに含まれる頂点の NS レコードは取り込まれず、Cloud DNS が割り当てたネームサーバーが残ります。--replace-origin-ns を付けると頂点の NS もファイルの値で置き換えられますが、移行の場面で旧 DNS の NS を取り込むと委任が壊れる原因になるため、通常は付けません。--delete-all-existing は既存のレコードを消してから読み込むフラグで、やり直したいときに使えますが、すでにレコードを手で足したゾーンに使うと消えてしまうので注意します。
インポートが終わったら、登録内容を一覧で確認します。
gcloud dns record-sets list --zone=example-com手順3：Cloud DNS のネームサーバーに直接問い合わせて照合する
ゾーンに割り当てられたネームサーバーを確認します。ns-cloud- で始まる名前が4つ返るのが一般的です。
gcloud dns managed-zones describe example-com \
--format="value(nameServers)"レジストラを変更する前に、このネームサーバーへ直接問い合わせ、旧 DNS と同じ答えが返るかを比べます。
#!/bin/bash
# records.txt には「名前 種類」を1行ずつ書く（例: www.example.com CNAME）
OLD=ns1.old-dns.example # 旧DNSのネームサーバー名
NEW=ns-cloud-a1.googledomains.com # describe で確認した名前に置き換える
while read -r name type; do
a=$(dig +short @"$OLD" "$name" "$type" | sort)
b=$(dig +short @"$NEW" "$name" "$type" | sort)
[ "$a" = "$b" ] || printf '差分: %s %s\n 旧: %s\n 新: %s\n' "$name" "$type" "$a" "$b"
done < records.txt差分は、この段階でゾーンファイルを直して再インポートするか、個別のレコードを修正して解消します。まだ誰も Cloud DNS を参照していないので、何度修正しても影響はありません。TXT は引用符の付き方やスペースの違いだけで差分に見えることがあるため、値そのものが同じかを目で確かめます。
手順4：DNSSEC の扱いを決める
旧 DNS で DNSSEC を使っていて、レジストラに DS レコードが登録されている場合は、ネームサーバーを切り替える前に方針を決めます。DS が旧 DNS の鍵を指したまま Cloud DNS へ切り替えると、DNSSEC を検証する公開 DNS からは名前解決に失敗します。
一般的に安全なのは、いったん DNSSEC を外す方法です。
- レジストラで DS レコードを削除する
- DS の TTL（TLD によって異なり、1日程度のことが多い）が過ぎるまで待つ
- ネームサーバーを Cloud DNS に切り替える
- 切り替えが安定したら、Cloud DNS で DNSSEC を有効にし、新しい DS をレジストラに登録する
# 移行後に DNSSEC を有効にする
gcloud dns managed-zones update example-com --dnssec-state=on
# レジストラに登録する DS レコードの値を表示する（KSK の ID は list で確認）
gcloud dns dns-keys list --zone=example-com
gcloud dns dns-keys describe KSK_ID --zone=example-com \
--format="value(ds_record())"Cloud DNS には、署名を途切れさせずに移行するための状態（--dnssec-state=transfer）も用意されていますが、旧 DNS 側で新しい鍵を扱えることが前提になり、手順も複雑です。使う場合は Google Cloud の公式ドキュメントの移行手順を読み、検証用のドメインで試してから本番に適用してください。
手順5：レジストラでネームサーバーを切り替える
レジストラの管理画面で、ネームサーバーを手順3で確認した Cloud DNS の4つの名前に変更します。末尾のドットを入力欄が受け付けない場合は、ドットを外して入力します。
# TLD のサーバーが Cloud DNS のネームサーバーを返すか
dig example.com NS +trace
# 公開DNSで答えを確認
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com MX +short上位のレジストリが持つ NS レコードのキャッシュが切れるまで、1〜2日程度は旧 DNS にも問い合わせが届きます。この間は旧 DNS のゾーンを消さず、Cloud DNS 側でレコードを変更した場合は旧 DNS にも同じ変更を入れておきます。
切り替え後に確認すること
- サイトとメール：WordPress のフロントと管理画面の表示、外部とのメールの送受信、受信メールのヘッダーにある SPF・DKIM・DMARC の判定結果
- 証明書の自動更新：DNS 認証（DNS-01）で証明書を更新している場合、更新の仕組みが旧 DNS の API に依存していないか。Cloud DNS に切り替えるなら、ACME クライアントの設定とサービスアカウントの権限も見直します
- TTL を戻す：安定したら、短くしていたサイトの TTL を 3600 などに戻します
- 旧 DNS の停止：上位の NS の TTL を十分過ぎ、問題がないことを確かめてから停止します。契約の解約と同時にゾーンが消えるサービスもあるため、解約の時期も計画に入れます
最後に、移行直後の状態を gcloud dns record-sets export example.com.zone --zone=example-com --zone-file-format で書き出して保管しておくと、後で誤って消したときの復元に使えます。
まとめ
- 旧 DNS のレコードを BIND 形式のゾーンファイルにし、末尾のドットと TTL を見直してから
gcloud dns record-sets import --zone-file-formatで登録します。 - 頂点の NS と SOA は Cloud DNS が用意するものを使い、通常は
--replace-origin-nsを付けません。 - レジストラを触る前に、Cloud DNS のネームサーバーへ dig で直接問い合わせて旧 DNS と照合します。
- DNSSEC を使っている場合は、DS を外して待ってから切り替え、安定後に Cloud DNS で有効にして新しい DS を登録するのが安全です。
- gcloud のフラグや機能は更新されるため、
--helpと公式ドキュメントで手元の環境の動作を確認してください。