Google Cloudの名前解決機能解説！〜内部DNSからCloud DNSまで〜
はじめに
こんにちは、クラウドエースのネットワークギルドに所属している清水です。
Google Cloud では DNS クライアント、DNS サーバーともに、選択肢が多数存在します。
そのため Google Cloud における名前解決の設計では、デフォルトで提供される「内部 DNS」や、マネージドサービスである「Cloud DNS」の各機能を要件に応じて適切に選択する必要があります。
本稿では、これら複数の名前解決手段について、具体的なユースケースを交えて解説します。
本記事の対象読者
- DNS の基礎知識（名前解決の仕組み、レコードの種類など）をお持ちの方
- Google Cloud の VPC やコンピューティングリソースの基本を理解している方
本記事のゴール
- Google Cloud 内部 DNS の仕組みを理解する
- Cloud DNS の各ゾーンタイプ（一般公開、限定公開、ピアリング、転送）の使い分けを理解する
1. 何もしなくても使える GCE の「内部 DNS」
内部 DNS の仕組み
Compute Engine（GCE）の仮想マシン（VM）インスタンスを作成すると、ユーザーが特別な設定をしなくても、内部 DNS 名が自動的に作成されます。この機能により、同じ VPC ネットワーク内のインスタンス同士は、内部 DNS 名を使用して相互にアクセスできます。
内部 DNS のタイプは以下の 2 種類がありますが、現在のデフォルトであり推奨されている形式は ゾーン DNS です。
-
ゾーン DNS ：<INSTANCE_NAME>.<ZONE>.c.<PROJECT_ID>.internal
例：my-web-server.asia-northeast1-c.c.my-project-id.internal -
グローバル DNS ：<INSTANCE_NAME>.c.<PROJECT_ID>.internal
例：my-web-server.c.my-project-id.internal
デフォルト内部 DNS タイプについての補足
- デフォルトの内部 DNS タイプは、Compute Engine API を有効にする際に決まります。
- 組織またはスタンドアロンのプロジェクトで 2018 年 9 月 6 日以降に Compute Engine API を有効にしている場合、デフォルトの内部 DNS タイプはゾーン DNS に設定されています。
メタデータサーバー
各 VM インスタンスは、DNS サーバーとして特別な IP アドレス 169.254.169.254 を使用するように設定されています。これはメタデータサーバーの IP アドレスであり、インスタンスからの DNS クエリを受け付けて、内部 DNS 名（.internal ゾーン）の解決や、インターネット上のドメインに対する再帰的問い合わせの両方を処理します。
内部 DNS でできないこと
内部 DNS は便利ですが、役割がインスタンス同士の名前解決に特化しています。
GCE 内部 DNS の特性
-
カスタマイズ不可: インスタンス名に基づいた
.internalドメインの A レコードや PTR レコードが自動で生成され、任意のレコードを追加するなどの運用はできません。 - プライマリ NIC への紐付け: インスタンスのプライマリネットワークインターフェース（nic0）のプライマリ内部 IPv4 アドレスに対して作成されます。
- 限定的なレコード: CNAME や TXT レコードといったカスタムレコードの作成はサポートされていません。
これらの特性があるため、「社内標準のドメイン名を使いたい」あるいは「複雑なサービスディスカバリを行いたい」場合には、次に紹介する Cloud DNS が必要になります。
2. Cloud DNS とは？
Cloud DNS は、高信頼性と高度な機能を提供するために設計された、費用対効果の高いマネージド DNS ゾーンサービスです。以下のような特徴があります。
Cloud DNSの主な特徴
| 特徴 | 詳細説明 |
|---|---|
| 高い可用性 (SLA 100%) | Google のグローバルネットワークとエニーキャスト技術を活用し、世界各地に分散されたサーバーで運用されるため、100% の可用性と低レイテンシが実現されます。 |
| オートスケール | Google の強固で広範なネットワークインフラストラクチャ上で動作しており、クエリ数に応じて自動的にスケーリングします。ユーザーは事前のサイジングやキャパシティ管理を行う必要がありません。 |
| DNSSEC | マネージド DNSSEC をサポートしており、なりすまし攻撃やキャッシュ汚染攻撃からドメインを保護できます。鍵の生成や定期的なローテーションといった運用は Google 側で自動的に行われるため、運用負荷なくセキュリティを強化できます。 |
また、Cloud DNS はさまざまな用途での利用が可能です。以降の章でこれら機能について解説します。
- 一般公開ゾーン
- 限定公開ゾーン
- DNS ピアリング
- オンプレミス連携
3. インターネットに公開する「一般公開ゾーン」
一般公開ゾーン（Public Zone） を使うと、インターネットにドメイン名を公開することができます。
一般的な権威DNSとしての利用
一般公開ゾーンは、公共のインターネットに公開される権威 DNS サーバーとして機能します。取得したドメイン名（例: example.com）のネームサーバーを Cloud DNS に設定することで、世界中のリゾルバからのクエリに応答し、Google Cloud 上のリソース（外部ロードバランサや VM の外部 IP アドレスなど）にトラフィックを誘導します。
Cloud DNS のグローバルなエニーキャストネットワークにより、高いクエリパフォーマンスが保証されます。
ユースケース
外部ロードバランサや公開サーバーの外部 IP アドレスを A レコードとして登録する一般公開ゾーンを設定することで、インターネットユーザーからの名前解決やアクセスが可能になります。
▲一般公開ゾーン利用イメージ
4. VPC内で自由に名前をつける「限定公開ゾーン」
限定公開ゾーン（Private Zone） は、インターネットに公開されることなく、指定した 1 つ以上の Virtual Private Cloud（VPC）ネットワーク内にのみ公開されるマネージド DNS ゾーンです。
VPC内での独自ドメイン利用
この機能は、GCE 内部 DNS の仕組みに似ていますが、カスタマイズ性があります。
- セキュリティ: DNS クエリがプライベートネットワーク内に制限されるため、内部 IP アドレスやサーバー構成情報が外部に漏洩するリスクを防げます。
-
承認されたネットワーク: ゾーン作成時に、そのゾーンのレコードを解決できる VPC ネットワークを指定します。この VPC 内の VM のみが、メタデータサーバー（
169.254.169.254）を介してプライベートレコードを解決できます。 -
カスタムレコード:
corp.localやmycompany.netなど、組織の命名規則に従った 任意のドメイン名 や、CNAME、TXT レコードなどを柔軟に定義し、内部サービスディスカバリに活用できます。
ユースケース
内部ロードバランサや内部サーバーの内部 IP アドレスを A レコードとして登録する限定公開ゾーンを設定することで、VPC 内のクライアントからの名前解決やアクセスが可能になります。インターネットユーザーからの名前解決やアクセスはできません。
▲限定公開ゾーン利用イメージ
5. VPC 間をつなぐ「DNS ピアリング」
大規模な組織やマイクロサービス環境では、セキュリティや管理上の理由から複数の VPC ネットワークを使用します。このとき、異なる VPC 間でプライベートな名前解決を可能にするのが DNS ピアリング（Peering Zone） です。
VPC をまたぐ名前解決
似た用語に VPC ピアリングがありますが、VPC ピアリングと DNS ピアリングは別物です。
VPC ピアリングを設定しても、L3レベル（IPパケットのルーティング）の到達性は確保されますが、DNS 情報は自動的に共有されません。
DNS ピアリングは、この名前解決の壁を越えるために使用されます。特定のゾーンに対する DNS クエリを、別の VPC ネットワークに転送し、名前解決を実行させます。
レコード定義やゾーン定義を持っている Cloud DNS が配置された VPC ネットワークをDNS プロデューサーネットワーク、名前解決を依頼する側の VPC ネットワークをDNS コンシューマーネットワークと呼びます。
ユースケース
VPC B 内にある内部サーバー用の内部ロードバランサ、もしくは内部サーバー自体に対して、別の VPC A 内にあるクライアントから名前解決やアクセスを可能にします。
VPC B には限定公開ゾーンを作成し、 VPC A には DNS ピアリングゾーンを設定します。
▲DNS ピアリングゾーン利用イメージ
6. オンプレミスと連携する「転送ゾーン」と「受信サーバーポリシー」
ハイブリッドクラウド環境では、Cloud VPN や Cloud Interconnect で接続されたオンプレミス環境と Google Cloud 間の名前解決の統合が不可欠です。これには、トラフィックの方向に応じて 2 種類の機能を使います。
転送ゾーン（Outbound）：Google Cloudからオンプレミスの名前解決
Google Cloud の VM が、オンプレミス環境にある DNS サーバー（Active Directory など）に特定のドメイン（例: onprem.local）のクエリを送信するためには 転送ゾーン を使用します。
ユースケース
Google Cloud 環境とオンプレミス環境が Cloud VPN / Interconnect で接続されています。この時に Google Cloud 環境内にあるクライアントから、オンプレミス環境内にあるターゲットへの名前解決やアクセスを可能にします。
▲転送ゾーン利用イメージ
- 設定方法: 転送ゾーンを作成し、オンプレミス DNS サーバーの IP アドレスを転送先（ターゲットネームサーバー）として指定します。
受信サーバーポリシー（Inbound）：オンプレミスからGoogle Cloudの名前解決
オンプレミスのクライアントが、Google Cloud の VPC ネットワーク内の限定公開ゾーン（例: googlecloud.example.com）のレコードをクエリできるようにするのが、受信サーバーポリシー機能です。
ユースケース
Google Cloud 環境とオンプレミス環境が Cloud VPN / Interconnect で接続されています。このときにオンプレミス環境内にあるクライアントから、Google Cloud 環境内にあるターゲットへの名前解決やアクセスを可能にします。
▲受信サーバーポリシー利用イメージ
- 仕組み: オンプレミスからのフォワーディング DNS クエリの受信を許可する受信 DNS サーバーポリシーを設定すると、VPC ネットワーク内のサブネット範囲から IP アドレスが割り当てられ、これがフォワーディング DNS クエリを受け付けるエントリポイントとなります。
- オンプレミス側設定: オンプレミスの DNS サーバーでは、Google Cloud のドメインに対する 条件付き転送ルール を設定し、転送先として VPC 側で払い出されたエントリポイントの IP を指定します。
Google Cloud の名前解決機能の紹介は以上です。
次の章からはオンプレミスと Google Cloud のハイブリッド環境における DNS サーバー構成設計での「よくある勘違い」と「おまけ」情報を紹介します！
補足情報（1）よくある勘違い：「ゾーン転送」と「転送ゾーン」は別物！
一般的な DNS 用語である「ゾーン転送」と Cloud DNS の一機能である「転送ゾーン」は、名前が似ていて混同しがちですが別物です。
「名前は似ているが機能は違う」
-
ゾーン転送 (Zone Transfer / AXFR / IXFR):
これは、DNS レコードのデータをプライマリ DNS サーバーからセカンダリ DNS サーバーへ 丸ごとコピーして同期 するために使用される機能です。オンプレミスの DNS サーバーで、冗長構成を確保するために使用されます。 -
転送ゾーン (Forwarding Zone):
これは、DNS クエリ（問い合わせ）を特定のドメインに対して 別の DNS サーバー転送し（フォワードし）、そのサーバーからの応答を待つ機能です。データの同期は行いません。
「オンプレミス DNS をプライマリ、Google Cloud DNS をセカンダリにできるのか？」
よくある質問として「オンプレミス DNS をプライマリとし、Cloud DNS をセカンダリとしてゾーン転送で同期できないか？」というものがあります。
-
結論:
Cloud DNS の限定公開ゾーンは ゾーン転送（AXFR）をサポートしていません。
したがって、オンプレミスの DNS サーバーをプライマリとして、Cloud DNS 限定公開ゾーンをセカンダリとして設定し、自動的にレコードデータを同期させる構成は不可能です。 -
解決策:
Cloud DNS はマネージドサービスであり、従来の BIND サーバーのような柔軟なプライマリ・セカンダリ構成とは考え方が異なります。データの同期に頼るのではなく、お互いの環境の名前解決を委任する 転送（フォワード）ベースのハイブリッドアプローチ が推奨されます。
前述の第6章で説明した機能を用いて、以下構成が可能です。
- Google Cloud → オンプレミス： 転送ゾーン（Outbound）
- オンプレミス → Google Cloud： 受信サーバーポリシー（Inbound）
これにより、レコードデータを同期せず、必要な名前解決がそれぞれの環境から可能になります。
補足情報（2）Cloud DNS へのレコードデータの一括インポート
Cloud DNS では、レコードデータを一括インポートする仕組みが用意されています。オンプレミス DNS サーバーからの移行などで大量データを登録する際に便利です。
レコードを一括でインポートする方法
インポートには、主に以下の 2 つの形式が利用できます。
- BIND ゾーン形式: 多くの DNS サーバー（BIND など）で標準的に使われている RFC 1035 準拠の形式です。既存サーバーからエクスポートしたファイルをそのまま活用できるため、移行時に最も重宝します。
-
YAML レコード形式:
gcloudコマンドでエクスポートした際に出力される Google Cloud 独自の形式です。プロジェクト間でのレコード複製などに適しています。
gcloud コマンドによる実行例:
gcloud dns record-sets import -z=<Cloud DNSゾーン名> --zone-file-format path-to-example-zone-file
--zone-file-format フラグはインポート対象が BIND ゾーン形式であることを指定します。
インポート対象が YAML レコード形式の場合は、本フラグを省略します。
インポート時の注意点と形式のルール
一括インポートを成功させるためには、ファイル形式に関するいくつかの重要なルールを守る必要があります。
-
FQDN 末尾のピリオド（.）に注意:
末尾のピリオド（.）が必要なレコード（例:example.com.）の全てに、末尾のピリオド（.）がついていることを確認の上でインポートしてください。意図しないレコードが作成される原因となります。 -
SOA と NS レコードの扱い:
Cloud DNS では、ゾーン作成時に SOA と NS レコードが自動生成されます。インポート ファイルから NS レコードまたは SOA レコードを削除して、Cloud DNS で自動生成されたレコードを使用することをおすすめしますが、詳細なユースケースは公式ドキュメントをご確認ください。
まとめ
Google Cloud には GCE インスタンス同士の名前解決機能としてデフォルトで内部 DNS 機能が用意されています。
また、Cloud DNS は、インターネット公開用の権威 DNS としてだけでなく、VPC 内部の名前解決、マルチ VPC 連携、そしてハイブリッド環境の統合に不可欠なプラットフォームです。
ユースケース別 機能マトリクス
| 要件・シナリオ | 推奨機能 | 備考 |
|---|---|---|
| VPC 内の VM 同士で設定なしに通信したい | GCE 内部 DNS (デフォルト) |
.internal ドメイン。自動生成されるため、レコードのカスタマイズは不可。 |
| インターネットに Web サイトを公開したい | Cloud DNS 一般公開ゾーン | Anycast IP により低遅延を実現。マネージド DNSSEC の有効化が可能。 |
| VPC 内で独自のドメイン名を使いたい | Cloud DNS 限定公開ゾーン | 任意のドメイン名、レコードの追加などが可能。 |
| VPC A から VPC B のプライベート名を解決したい | Cloud DNS ピアリング | VPC ピアリングとは別物。 |
| Google Cloud からオンプレミスのサーバー名を解決したい | 転送ゾーン (Outbound) | 送信元 IP は 35.199.192.0/19 となる。オンプレミス側の FW と戻りルートの設定が必須。 |
| オンプレミスから Google Cloud のプライベート名を解決したい | 受信サーバーポリシー (Inbound) | VPC 側で受信サーバーポリシーを作成し、払い出された IP をオンプレミス DNS の「条件付き転送先」に指定する。 |
本記事が、Google Cloud の名前解決機能を理解する一助となれば幸いです。
Discussion