Google Cloud DNS でゾーンを作成する手順｜公開ゾーンと限定公開ゾーンの違い・gcloud での作成・委任の確認

Google Cloud DNS でゾーンを作るときは、最初に「インターネットに公開するゾーン（公開ゾーン）」か「指定した VPC ネットワークの中だけで使うゾーン（限定公開ゾーン）」かを決め、ゾーン名と DNS 名を分けて考えるのが要点です。この記事では、作成前の準備、gcloud とコンソールでの作成方法、自動で作られる NS と SOA の意味、レコードの追加、限定公開ゾーンとサブドメインのゾーンの作り方、作成後の確認までを説明します。

既存のドメインを別の DNS サービスから Cloud DNS へ移す手順（ゾーンファイルのインポートやネームサーバーの切り替え）は、別記事の Cloud DNS への移行手順で扱っています。ここでは新しくゾーンを作り、正しく応答させるまでに絞ります。Cloud DNS のコンソールの表記や gcloud のフラグは更新されることがあるため（2026年10月現在）、作業前に gcloud dns managed-zones create --help で手元のバージョンの説明を確認してください。

作成前に準備すること

ゾーンは Google Cloud のプロジェクトに属します。プロジェクトを選び、Cloud DNS の API を有効にします。

gcloud config set project your-project-id
gcloud services enable dns.googleapis.com

ゾーンを作る人には、DNS の管理者権限（roles/dns.admin）が必要です。ゾーンの作成は頻繁に行う作業ではないため、管理者権限は少人数に絞り、日々のレコード変更を担当する人や自動化のサービスアカウントには、必要な範囲だけの権限を割り当てる設計にしておくと安全です。

あわせて、ゾーンごとに課金が発生することを確認しておきます。料金体系はゾーン数とクエリ数で決まるため、検証のために作ったゾーンを放置しないように、作成時に説明欄やラベルで用途を残しておきます。

公開ゾーンと限定公開ゾーンの違い

公開ゾーンは、インターネット上のだれからの問い合わせにも答えるゾーンです。WordPress サイトのドメインのように外部から名前解決される必要があるものは、こちらで作ります。作成すると Cloud DNS のネームサーバーが割り当てられ、レジストラでそのネームサーバーを登録した時点から実際に使われ始めます。

限定公開ゾーンは、指定した VPC ネットワーク内の仮想マシンなどからの問い合わせにだけ答えるゾーンです。社内向けの名前（db.internal.example.com など）を、外部に公開せずに使いたいときに向いています。インターネット側からは見えないため、レジストラの設定は必要ありません。

このほか、ほかの DNS サーバーへ問い合わせを転送する「転送ゾーン」や、別の VPC ネットワークの名前解決を参照する「ピアリングゾーン」もあります。オンプレミスの DNS と組み合わせる場合に使うもので、構成が複雑になるため、この記事では公開ゾーンと限定公開ゾーンを扱います。

ゾーン名と DNS 名を決める

Cloud DNS のゾーンには、二つの名前があります。

• ゾーン名：プロジェクト内でゾーンを識別する名前です。小文字の英字で始め、小文字の英字・数字・ハイフンで作ります。ドメイン名のドットは使えないため、example-com のように置き換えるのが一般的です。作成後は変更できません。
• DNS 名：実際に応答するドメイン名です。example.com. のように末尾にドットを付けて指定します。

同じプロジェクトの中で、同じ DNS 名の公開ゾーンを複数作ることもできてしまいます。この場合、レジストラに登録したネームサーバーがどのゾーンのものかで、実際に使われるゾーンが決まります。誤って二つ目を作り、使われていない側を編集して「変更が反映されない」と悩むことがあるので、作成前に一覧で確認します。

gcloud dns managed-zones list

gcloud で公開ゾーンを作る

gcloud dns managed-zones create example-com \
  --dns-name="example.com." \
  --description="example.com public zone" \
  --visibility=public

コンソールで作る場合は、Cloud DNS の画面からゾーンの作成を選び、種類（公開か限定公開か）、ゾーン名、DNS 名、説明を入力します。入力する内容は gcloud と同じです。DNSSEC を有効にする設定も作成時に選べますが、レジストラへの DS レコードの登録と組み合わせて初めて機能するため、ドメインの委任が済んでから有効にするほうが手順を追いやすくなります。

自動で作られる NS と SOA を確認する

ゾーンを作ると、頂点（example.com.）に NS レコードと SOA レコードが自動で作られます。

gcloud dns record-sets list --zone=example-com

NS レコードには、このゾーンに割り当てられた Cloud DNS のネームサーバー（ns-cloud- で始まる名前が4つのことが多い）が並びます。これがレジストラに登録する値です。ゾーンごとに割り当てられる組み合わせが異なる場合があるため、ほかのゾーンの値を流用せず、このゾーンの値を使います。

SOA は、ゾーンの管理情報（プライマリのネームサーバー、シリアル番号、ネガティブキャッシュの時間など）を持つレコードです。通常は変更する必要はありません。頂点の NS を手で書き換えると委任が壊れる原因になるので、意図がない限り触らないでください。

レコードを追加する

レコードは gcloud dns record-sets create で1件ずつ追加できます。名前には末尾のドットを付けた完全な名前を指定します。

# A レコード
gcloud dns record-sets create example.com. \
  --zone=example-com --type=A --ttl=300 \
  --rrdatas=203.0.113.10

# www を CNAME で頂点に向ける
gcloud dns record-sets create www.example.com. \
  --zone=example-com --type=CNAME --ttl=300 \
  --rrdatas=example.com.

# MX（優先度とホスト名を1つの値として書く）
gcloud dns record-sets create example.com. \
  --zone=example-com --type=MX --ttl=3600 \
  --rrdatas="10 mail.example.net."

# TXT（値を引用符で囲む）
gcloud dns record-sets create example.com. \
  --zone=example-com --type=TXT --ttl=3600 \
  --rrdatas='"v=spf1 include:_spf.example.net ~all"'

Cloud DNS では、同じ名前と種類のレコードは1つの「レコードセット」にまとめて管理します。同じ名前の TXT を2つ足したいときに create をもう一度実行するとエラーになるため、--rrdatas にカンマ区切りで複数の値を並べて作るか、既存のレコードセットを gcloud dns record-sets update で値ごと置き換えます。update は指定した値で置き換える動作なので、既存の値も含めて書く点に注意してください。

CNAME の値と MX のホスト名には、末尾のドットを付けます。付け忘れると意図しない名前として扱われたり、エラーになったりします。頂点（example.com.）には CNAME を置けないため、頂点は A（と必要なら AAAA）で設定します。

限定公開ゾーンを作る

限定公開ゾーンは、--visibility=private と、名前解決を許す VPC ネットワークを指定して作ります。

gcloud dns managed-zones create internal-example \
  --dns-name="internal.example.com." \
  --description="internal names for VPC" \
  --visibility=private \
  --networks=default

gcloud dns record-sets create db.internal.example.com. \
  --zone=internal-example --type=A --ttl=300 \
  --rrdatas=10.0.0.5

--networks には、ゾーンを参照させる VPC ネットワークの名前を指定します。指定していないネットワークの仮想マシンからは、このゾーンの名前は解決できません。公開ゾーンと同じ DNS 名で限定公開ゾーンを作ると、指定した VPC の中からは限定公開ゾーンの答えが優先されるため、内部だけ別の IP を返す構成も作れますが、公開側との食い違いが分かりにくくなるので、内部向けにはサブドメインを分けるほうが管理しやすくなります。

サブドメインを別のゾーンにして委任する

dev.example.com のように、サブドメインを別のチームやプロジェクトに任せたいときは、サブドメイン用の公開ゾーンを作り、親ゾーンに NS レコードを置いて委任します。

# サブドメイン用のゾーンを作る
gcloud dns managed-zones create dev-example-com \
  --dns-name="dev.example.com." --description="dev subdomain" \
  --visibility=public

# 割り当てられたネームサーバーを確認する
gcloud dns managed-zones describe dev-example-com \
  --format="value(nameServers)"

# 親ゾーンに NS レコードを作る（値は上で確認した4つに置き換える）
gcloud dns record-sets create dev.example.com. \
  --zone=example-com --type=NS --ttl=3600 \
  --rrdatas="ns-cloud-b1.googledomains.com.,ns-cloud-b2.googledomains.com.,ns-cloud-b3.googledomains.com.,ns-cloud-b4.googledomains.com."

委任すると、dev.example.com 配下の名前は親ゾーンではなくサブドメインのゾーンが答えるようになります。親ゾーンに dev.example.com 配下の A レコードなどが残っていると、どちらの値が返るのか混乱するため、委任の前に整理しておきます。

作成後の確認

ゾーンを作ったら、レジストラの設定を変える前に Cloud DNS のネームサーバーへ直接問い合わせ、登録した答えが返るかを確かめます。

dig @ns-cloud-a1.googledomains.com example.com A +short
dig @ns-cloud-a1.googledomains.com www.example.com CNAME +short
dig @ns-cloud-a1.googledomains.com dev.example.com NS

ns-cloud-a1.googledomains.com は、自分のゾーンに割り当てられた名前に置き換えてください。期待どおりの答えが返れば、レジストラでネームサーバーを Cloud DNS の4つに登録します。登録後は dig example.com NS +trace で、TLD のサーバーが Cloud DNS のネームサーバーを返していることを確認します。

不要になったゾーンを削除するときは、自動作成された NS と SOA 以外のレコードをすべて消してからでないと、削除できない仕組みになっています。誤って本番のゾーンを消さないための仕組みでもあるので、削除前には gcloud dns record-sets export で内容を書き出して保管しておきます。

まとめ

• 外部から引かれるドメインは公開ゾーン、VPC 内だけで使う名前は限定公開ゾーンで作ります。
• ゾーン名（識別名、変更不可）と DNS 名（末尾にドット）は別物で、同じ DNS 名のゾーンを重複して作らないよう一覧で確認します。
• 自動で作られる NS がレジストラに登録する値で、頂点の NS と SOA は通常触りません。
• 同じ名前と種類のレコードは1つのレコードセットにまとめ、update は値の置き換えになる点に注意します。
• サブドメインは別ゾーンを作り、親ゾーンの NS レコードで委任します。

• NSレコードの仕組みとゾーン委任の設定｜サブドメインの委任と確認方法
• DNSのAレコードとCNAMEレコードの違いと設定方法｜使い分けと設定できない場所