Cloud DNS

解決する課題

ドメイン名でサービスへ繋ぎつつ、可用性・性能・内部名前解決を 1 つのマネージドサービスで満たせます。

• ドメイン名でサービスに繋ぎたい（権威 DNS）
• VPC 内部だけで通用する名前を解決したい（限定公開ゾーン）
• ユーザーを 最も近い／健全なエンドポイントへ振りたい（ルーティングポリシー）
• DNS サーバーの構築・冗長化・スケールを Google に任せたい

主要概念と用語

• マネージドゾーン: ドメインの DNS 設定の入れ物。公開ゾーン（public）／限定公開ゾーン（private） がある（AWS のホストゾーンに相当）
• レコードセット: A / AAAA / CNAME / MX / TXT / NS / SOA / SRV / CAA など。同名・同タイプをまとめて 1 つの「レコードセット」として管理する
• ルーティングポリシー: 1 つのレコードセットに付与する応答制御。加重（weighted round robin）／位置情報（geolocation）／フェイルオーバー（プライマリ・バックアップ） をサポート
• ヘルスチェック: ルーティングポリシーと組み合わせ、内部ロードバランサ等のバックエンドの健全性に応じて応答を変える
• DNS ピアリング / 転送（フォワーディング）: VPC 間でプライベートゾーンを共有（ピアリング）したり、オンプレミスの DNS と双方向に問い合わせを転送する
• Cloud DNS の DNS64 / レスポンスポリシー（RPZ）: 特定ドメインの応答を上書き・ブロックするポリシー層
• 補足: ドメインの**登録（レジストラ）**は Cloud DNS 自体ではなく Cloud Domains（または外部レジストラ）が担う。ここが Route 53 と異なる（Route 53 は登録機能を内包）

仕様・制限・クォータ

• グローバルサービス。Google の Anycast ネームサーバー（ns-cloud-XX.googledomains.com 群）で権威応答を返す
• 権威ネームサーバーの 可用性 SLA は 100%
• 課金は マネージドゾーン数（月額）＋ DNS クエリ数の従量。ヘルスチェック等の付随リソースは別途
• 既定のクォータ例: 1 プロジェクトあたりマネージドゾーン 10,000、1 ゾーンあたりレコードセット 10,000、1 レコードセットあたりレコードデータ 100 件など（上限は引き上げ申請可能）
• TTL でリゾルバ側のキャッシュ時間を制御する

内部の仕組み

Cloud DNS は権威 DNS として、レコードセットとルーティングポリシーに基づいて問い合わせへ応答します。ネームサーバーは世界中のエッジに Anycast で展開され、利用者は最も近いノードへ自動的に到達します。

• 公開ゾーンはインターネットから解決可能。ドメインのレジストラ側で、Cloud DNS が払い出した NS レコード（ns-cloud-*）に委任する必要がある
• 限定公開ゾーンは紐づけた VPC ネットワーク内からのみ解決可能。内部 IP を返す用途に使う
• DNS 転送で、オンプレミス → GCP（インバウンド転送）／GCP → オンプレミス（アウトバウンド転送）の名前解決を相互接続できる
• ルーティングポリシーは応答そのものを状況に応じて変える（重み付け分散、地域別の出し分け、プライマリ障害時のバックアップ応答）

設計パターン / ベストプラクティス

• apex（example.com）は、外部 HTTP(S) ロードバランサの予約済みグローバル静的 IP を A レコードで指す
• フェイルオーバールーティングポリシー＋ヘルスチェックで、プライマリ異常時にバックアップへ自動切替（DR）
• 加重ルーティングで多リージョン分散やカナリアリリース、位置情報ルーティングで地域別の出し分け
• 内部マイクロサービスは限定公開ゾーンで名前解決し、内部 IP の変更をアプリから隠蔽する
• ハイブリッド構成では DNS 転送（インバウンド／アウトバウンド） と DNS ピアリングでオンプレと GCP の名前空間を統合する

運用・監視

• Cloud Monitoring で DNS クエリ数などのメトリクスを監視し、急増・異常を検知する
• Cloud DNS ロギング（VPC 単位で有効化）で、限定公開ゾーン・転送・ピアリングのクエリログを Cloud Logging に記録する
• 反映が遅い場合は TTL を確認（切替を予定するなら事前に TTL を短くしておく）
• 名前解決の確認は dig / nslookup。委任の確認は権威ネームサーバー（ns-cloud-*）を直接引く

コスト

課金は「ゾーンの月額」と「クエリ従量」が中心です。

セキュリティ

• DNSSEC を公開ゾーンで有効化し、応答の改ざん・キャッシュポイズニングを防ぐ（レジストラ側へ DS レコードの登録が必要）
• 限定公開ゾーンで内部名を外部に露出させず、VPC 内に閉じる
• IAM（roles/dns.admin など）でゾーン・レコードの変更権限を最小化する
• レスポンスポリシー（RPZ） で悪性ドメインの解決をブロック／上書きする

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# 公開マネージドゾーンを作成
gcloud dns managed-zones create example-zone \
  --description="public zone for example.com" \
  --dns-name="example.com." \
  --visibility=public

# トランザクションで A レコードを追加（apex をLBの静的IPへ）
gcloud dns record-sets transaction start --zone=example-zone
gcloud dns record-sets transaction add "203.0.113.10" \
  --name="example.com." --ttl=300 --type=A --zone=example-zone
gcloud dns record-sets transaction execute --zone=example-zone

# ゾーンの権威ネームサーバー（委任先）を確認
gcloud dns managed-zones describe example-zone \
  --format="value(nameServers)"

# DNSSEC を有効化（このあとレジストラ側に DS レコードを登録する）
gcloud dns managed-zones update example-zone --dnssec-state=on