このページでは、Cloud DNS の特長と機能の概要について説明します。Cloud DNS の使用を開始するには、クイックスタートをご覧ください。
はじめに
Cloud DNS は、高パフォーマンスで復元力を備えたグローバル ドメインネーム システム（DNS）サービスで、費用対効果の高い方法でグローバル DNS にドメイン名を公開します。
コンセプト
DNS は、IP アドレスやその他のデータを格納し、名前でそれらを検索できる階層型分散データベースです。Cloud DNS を使用すると、独自に DNS サーバーやソフトウェアを管理する負担なく、ゾーンとレコードを DNS で公開できます。
一般的な DNS 用語のリストについては、一般的な DNS の概要をご覧ください。
Cloud DNS は、一般公開ゾーンと限定公開マネージド DNS ゾーンの両方を提供します。一般公開ゾーンは公共のインターネットに公開され、限定公開ゾーンは指定した 1 つ以上の VPC ネットワークからのみ公開されます。
Cloud DNS の用語
Cloud DNS API は、プロジェクト、マネージド ゾーン、レコードセット、レコードセットへの変更を中心に構築されています。
- プロジェクト
- Google Cloud Console プロジェクトは、リソースのコンテナであり、アクセス制御のためのドメインであり、さらには課金の構成と集計を行う場所でもあります。詳しくは、組織の作成と管理をご覧ください。
- マネージド ゾーン
- マネージド ゾーンでは、同じ DNS 名サフィックス（
example.comなど）の DNS レコードが保持されます。プロジェクトには複数のマネージド ゾーンを含めることができますが、それぞれ一意の名前にする必要があります。Cloud DNS では、マネージド ゾーンは DNS ゾーンをモデル化するリソースです。マネージド ゾーン内のすべてのレコードは Google が運用する同じネームサーバー上でホストされています。これらのネームサーバーは、ゾーンの構成方法に応じて、マネージド ゾーンに対する DNS クエリに応答します。プロジェクトには複数のマネージド ゾーンを含めることができます。マネージド ゾーンが存在する各ゾーンに対し、毎日料金が発生します。マネージド ゾーンでは、課金の整理に役立つラベルをサポートしています。 - 一般公開ゾーン
一般公開ゾーンはインターネットに公開されます。Cloud DNS には、クエリの発信元に関係なく、一般公開ゾーンに関するクエリに応答する一般公開された権威ネームサーバーがあります。一般公開ゾーンに DNS レコードを作成して、サービスをインターネットで公開できます。たとえば、パブリック ウェブサイト
www.example.comでは、一般公開ゾーンexample.comに次のレコードを作成できます。DNS 名 型 TTL（秒） データ www.example.com A 300 198.51.100.0 Cloud DNS は、一般公開ゾーンの作成時に一連のネームサーバーを割り当てます。一般公開ゾーン内の DNS レコードをインターネット経由で解決できるようにするには、登録事業者を通してドメイン登録のネームサーバー設定を更新する必要があります。ドメインの登録と設定について詳しくは、Cloud DNS を使用してドメインを設定するをご覧ください。
- 限定公開ゾーン
限定公開ゾーンを使用すると、基になる DNS データを公共のインターネットにさらすことなく、仮想マシン、ロードバランサ、その他の Google Cloud リソースのカスタム ドメイン名を管理できます。限定公開ゾーンは、承認した 1 つ以上の VPC ネットワークによってのみクエリできる DNS レコードのコンテナです。
限定公開ゾーンは、定義されている同じプロジェクト内のリソースによってのみ照会できます。承認する VPC ネットワークは、限定公開ゾーンと同じプロジェクト内に配置する必要があります。他のプロジェクトの限定公開マネージド ゾーンにホストされているレコードをクエリする必要がある場合は、DNS ピアリングを使用します。
限定公開ゾーンを作成または更新するときは、その限定公開ゾーンをクエリできる承認済みの VPC ネットワークのリストを指定する必要があります。承認済みのネットワークだけが限定公開ゾーンをクエリできます。承認済みのネットワークを指定しない場合、限定公開ゾーンは一切クエリできません。
共有 VPC で限定公開ゾーンを使用できます。共有 VPC で限定公開ゾーンを使用する場合の重要な情報については、共有 VPC に関する考慮事項をご覧ください。
限定公開ゾーンは、DNSSEC（Domain Name System Security Extensions）または
NS型のカスタム リソース レコードセットをサポートしていません。限定公開ゾーンでの DNS レコードのリクエストは、メタデータ サーバー
169.254.169.254を介して送信する必要があります。このサーバーは、Google が提供するイメージから作成された VM のデフォルトの内部ネームサーバーです。このネームサーバーへのクエリは、承認された VPC ネットワークを使用する任意の VM から送信できます。たとえば、
dev.gcp.example.comに対して限定公開ゾーンを作成して、実験的なアプリケーション用の内部 DNS レコードをホストできます。次の表に、そのゾーン内のレコードの例を示します。データベース クライアントは、データベース サーバーdb-01.dev.gcp.example.comに接続する場合、その IP アドレスの代わりに内部 DNS 名を使用できます。データベース クライアントは、VM 上のホストリゾルバを使用してこの内部 DNS 名を解決し、VM は DNS クエリをメタデータ サーバー169.254.169.254に送信します。このメタデータ サーバーは、限定公開ゾーンを照会する再帰リゾルバとして機能します。DNS 名 型 TTL（秒） データ db-01.dev.gcp.example.com A 5 10.128.1.35 instance-01.dev.gcp.example.com A 50 10.128.1.10 限定公開ゾーンを使用すると、スプリット ホライズン DNS 構成を作成できます。これは、レコードセットが異なる限定公開ゾーンを作成して、一般公開ゾーン内のレコードをオーバーライドできるためです。これにより、どの VPC ネットワークで限定公開ゾーン内のレコードをクエリするかを制御できます。例については、重複するゾーンをご覧ください。
- 転送ゾーン
転送ゾーンとは、そのゾーンに対するリクエストを転送先の IP アドレスに送信する Cloud DNS 限定公開マネージド ゾーンのタイプです。詳しくは、DNS 転送方式をご覧ください。
- ピアリング ゾーン
ピアリング ゾーンは、別の VPC ネットワークの名前解決順序に従う Cloud DNS 限定公開マネージド ゾーンのタイプで、他の VPC ネットワークで定義されている名前の解決に使用できます。
- ゾーン オペレーション
Cloud DNS のマネージド ゾーンに加えた変更はすべて、オペレーション コレクションに記録されます。ここには、マネージド ゾーンの更新内容（説明、DNSSEC 状態、または構成の変更）がリストされます。
- 登録事業者
ドメイン名登録事業者は、インターネット ドメイン名の予約を管理する組織です。登録事業者は、ジェネリック トップレベル ドメイン（gTLD）レジストリまたは国別コード トップレベル ドメイン（ccTLD）レジストリによる認可を受ける必要があります。
- 内部 DNS
Google Cloud は、Cloud DNS を使用しない場合でも、VM に内部 DNS 名を自動的に作成します。内部 DNS について詳しくは、内部 DNS のドキュメントをご覧ください。
- 委任されたサブゾーン
DNS では、ゾーンのオーナーが NS レコードを使用してサブドメインを別のネームサーバーに委任できます。リゾルバは、これらのレコードに従い、委任で指定されたターゲット ネームサーバーにサブドメインに関するクエリを送信します。
- リソース レコードセット コレクション
リソース レコードセット コレクションは、マネージド ゾーンを構成する DNS レコードの現在の状態を保持します。このコレクションは読み取ることはできますが、直接変更しないでください。代わりに、変更コレクション内に
Changeリクエストを作成することで、マネージド ゾーン内のリソース レコードセットを編集します。リソース レコードセット コレクションには、すべての変更がすぐに反映されます。ただし、API で変更されてから、権威 DNS サーバーでそれらの変更が有効になるまでには、遅延があります。レコードの管理では、レコードの管理方法を説明します。- リソース レコードの変更
リソース レコードセット コレクションを変更するには、追加または削除を含む
Changeリクエストを送信します。追加と削除は、1 つのアトミック トランザクションまたは一括で行うことができ、それぞれの権威 DNS サーバーで同時に有効になります。たとえば、次のような A レコードがあるとします。
www A 203.0.113.1 203.0.113.2
次のようなコマンドを実行します。
DEL www A 203.0.113.2 ADD www A 203.0.113.3
一括変更後のレコードは次のようになります。
www A 203.0.113.1 203.0.113.3
ADD と DEL は同時に行われます。
- SOA シリアル番号形式
Cloud DNS マネージド ゾーンで作成された SOA レコードのシリアル番号は、
gcloud dns record-sets transactionコマンドを使用してゾーンのレコードセットに対するトランザクション変更が行われるごとに単調に増加します。SOA レコードのシリアル番号は任意の番号に手動で変更できますが、RFC 1912 で推奨されている ISO 8601 形式の日付を含める必要があります。たとえば、次の SOA レコードがあるとします。ns-gcp-private.googledomains.com. cloud-dns-hostmaster.google.com. [serial number] 21600 3600 259200 300Google Cloud Console から直接シリアル番号を変更するには、レコードの 3 番目のスペース区切りフィールドに希望の値を入力します。
- DNS サーバー ポリシー
DNS サーバー ポリシーにより、受信転送を使用して VPC ネットワーク内の Google Cloud が提供する名前解決サービスにアクセスできます。また、送信転送を使用して VPC 名前解決順序を変更することもできます。
- ドメイン、サブドメイン、委任
ほとんどのサブドメインは、親ドメインのマネージド ゾーンに含まれるレコードにすぎません。親ドメインのゾーン内に NS（ネームサーバー）レコードを作成することによって委任されたサブドメインには、独自のゾーンも設定する必要があります。Cloud DNS で親ドメインのマネージド ゾーンを作成した後に、委任されたサブドメインのゾーンを作成してください。この操作は、別の DNS サービスに親ドメインをホストしている場合も行います。サブドメイン ゾーンが複数あるのに親ゾーンを作成しない場合、後で親ゾーンを Cloud DNS に移動しようとしても、親ゾーンを作成するのが複雑になることがあります。
- DNSSEC
DNSSEC（Domain Name System Security Extensions）は、Internet Engineering Task Force（IETF）による DNS に対する一連の拡張機能で、ドメインネーム ルックアップに対するレスポンスを認証します。DNSSEC はこれらのルックアップに対するプライバシー保護は行いませんが、攻撃者が DNS リクエストに対するレスポンスを改ざんまたは汚染できないようにします。
- DNSKEY コレクション
DNSKEY コレクションには、DNSSEC 対応のマネージド ゾーンの署名に使用される DNSKEY レコードの現在の状態が保持されます。このコレクションは読み取りのみが可能です。DNSKEY に対する変更はすべて Cloud DNS によって行われます。DNSKEY コレクションには、ドメイン登録事業者が DNSSEC を有効にするために必要なすべての情報が含まれています。
共有 VPC に関する考慮事項
共有 VPC で Cloud DNS 限定公開マネージド ゾーン、Cloud DNS 転送ゾーン、または Cloud DNS ピアリング ゾーンを使用するには、ホスト プロジェクトにゾーンを作成し、そのゾーンの承認済みネットワークのリストに適切な共有 VPC ネットワークを追加する必要があります。
詳しくは、Cloud DNS 限定公開ゾーンのベスト プラクティスをご覧ください。
VPC の名前解決の順序
各 VPC ネットワークは、ネットワークを使用する仮想マシン（VM）インスタンスに DNS 名前解決サービスを提供します。VM がメタデータ サーバー（169.254.169.254）をネームサーバーとして使用する場合、Google Cloud は次の順序で DNS レコードを検索します。
VPC ネットワークに送信サーバー ポリシーが設定されている場合、Google Cloud はすべての DNS クエリをそれらの代替サーバーに転送します。VPC 名前解決順序は、このステップのみで構成されています。
VPC ネットワークに送信サーバー ポリシーが設定されていない場合は次のようになります。
- Google Cloud は、リクエストされたレコードにできるだけ多く一致する限定公開ゾーンを探そうとします（最長サフィックス マッチング）。これには、次の操作が含まれます。
- 限定公開ゾーンに作成したレコードを検索する
- 転送先に対して転送ゾーンをクエリする
- ピアリング ゾーンを使用して別の VPC ネットワークの名前解決順序をクエリする
- Google Cloud は、プロジェクトで自動的に作成された Compute Engine の内部 DNS レコードを検索します。
- Google Cloud は、適切に構成された start-of-authority（SOA）に従って一般公開ゾーンを照会します。これには、Cloud DNS の一般公開ゾーンも含まれます。
- Google Cloud は、リクエストされたレコードにできるだけ多く一致する限定公開ゾーンを探そうとします（最長サフィックス マッチング）。これには、次の操作が含まれます。
DNS 転送方式
Google Cloud には、限定公開ゾーンの DNS 転送方式として受信転送と送信転送があります。
受信転送とは、オンプレミス DNS クライアントまたはサーバーが Cloud DNS に DNS リクエストを送信できるようにすることです。DNS クライアントまたはサーバーは、VPC ネットワークの名前解決順序に従ってレコードを解決できます。受信転送により、オンプレミス クライアントは VPC ネットワークが承認済みとなっている限定公開ゾーン、転送ゾーン、ピアリング ゾーンでレコードを解決できます。オンプレミス クライアントは、Cloud VPN または Cloud Interconnect を使用して VPC ネットワークに接続します。
送信転送とは、Google Cloud の VM が DNS リクエストを任意の DNS ネームサーバーに送信できるようにすることです。ネームサーバーは、同じ VPC ネットワーク、オンプレミス ネットワーク、またはインターネット上に配置できます。
DNS 転送を構成するには、転送ゾーンを作成するか、Cloud DNS サーバー ポリシーを作成します。次の表に、この 2 つの方法をまとめます。
| 転送 | Cloud DNS 方式 |
|---|---|
| 受信 | VPC ネットワークの受信サーバー ポリシーを作成すると、オンプレミス システムがそのネットワークにリクエストを送信して VPC 名前解決順序を使用できるようになります。 |
| 送信 | VPC ネットワーク内の VM を次のように構成できます。
|
VPC ネットワークの受信転送と送信転送を同時に構成できます。双方向転送を使用すると、VPC ネットワーク内の VM がオンプレミス ネットワーク内のレコードも、別のクラウド プロバイダでホストされているネットワーク内のレコードも解決できます。このタイプの転送では、オンプレミス ネットワーク内のホストが Google Cloud リソースのレコードを解決することもできます。
Cloud DNS コントロール プレーンは、アルゴリズムを使用して転送先の応答性を判断します。送信転送クエリで SERVFAIL エラーが発生することがあります。この問題を回避する方法については、トラブルシューティング ドキュメントの関連するセクションをご覧ください。
限定公開ゾーンの PTR レコード
RFC 1918 アドレス用の PTR レコード
RFC 1918 アドレス用のカスタム PTR レコードを使用してリバース ルックアップを行うには、少なくとも次のいずれかと同程度に限定的な Cloud DNS 限定公開ゾーンを作成する必要があります。このようになるのは、VPC の名前解決の順序で説明している最長サフィックス マッチングが機能するからです。
10.in-addr.arpa.168.192.in-addr.arpa.16.172.in-addr.arpa.、17.172.in-addr.arpa.、...31.172.in-addr.arpa.まで。
RFC 1918 アドレス用の Cloud DNS 限定公開ゾーンを作成すると、そのゾーンの VM 用に作成したカスタム PTR レコードは Compute Engine 内部 DNS が自動的に作成する PTR レコードによってオーバーライドされます。これは、Compute Engine の内部 DNS PTR レコードは、上記にリストされている、より限定的なゾーンで作成されるためです。
たとえば、IP アドレスが 10.1.1.1 の VM に次の PTR レコードを使用して in-addr.arpa. の限定公開マネージド ゾーンを作成するとします。
1.1.1.10.in-addr.arpa. -> test.example.domain
1.1.1.10.in-addr.arpa. に対する PTR クエリには、これよりも限定的な 10.in-addr.arpa. Compute Engine 内部 DNS ゾーンが応答します。test.example.domain の Cloud DNS 限定公開ゾーン内の PTR レコードは無視されます。
VM に対して自動的に作成される Compute Engine の内部 DNS PTR レコードをオーバーライドするには、少なくともこのセクションで提示しているゾーンのうちのいずれかの、特定の限定公開ゾーン内でカスタム PTR レコードを作成してください。たとえば、10.in-addr.arpa. の限定公開ゾーン内で次の PTR レコードを作成すると、このレコードにより、自動的に生成されるレコードがオーバーライドされます。
1.1.1.10.in-addr.arpa. -> test.example.domain
ネットワーク ブロックの一部だけをオーバーライドする必要がある場合は、さらに具体的なリバース Cloud DNS 限定公開ゾーンを作成することもできます。たとえば、IP アドレスが 10.5.0.0/16 アドレス範囲にある VM 用に自動的に作成される Compute Engine 内部 DNS PTR レコードを特定の PTR レコードでオーバーライドする場合、5.10.in-addr.arpa. の限定公開ゾーンを使用して、それらのレコードを保持できます。
サポートされている DNS レコード型
Cloud DNS でサポートされるレコード型は次のとおりです。
| レコード型 | 説明 |
|---|---|
A |
アドレス レコード。ホスト名を IPv4 アドレスにマッピングします。 |
AAAA |
IPv6 アドレス レコード。ホスト名を IPv6 アドレスにマッピングします。 |
CAA |
認証局（CA）承認。ドメイン証明書の作成を許可する CA を指定します。 |
CNAME |
正規名レコード。エイリアス名を指定します。 |
IPSECKEY |
日和見暗号化を有効にするための IPSEC 対応クライアントの IPSEC トンネル ゲートウェイ データと公開鍵。 |
MX |
メール エクスチェンジ レコード。メールサーバーへのリクエストをルーティングします。 |
NAPTR |
RFC 3403 で定義された Naming Authority Pointer レコード。 |
NS |
ネームサーバー レコード。DNS ゾーンを権威サーバーに委任します。 |
PTR |
ポインタ レコード。DNS の逆引きによく使用されます。 |
SOA |
Start of authority レコード。DNS ゾーンに関する信頼できる情報を指定します。 |
SPF |
Sender Policy Framework レコード。以前、メール検証システムで使用されていたレコード型で、非推奨になりました（代わりに TXT レコードを使用してください）。 |
SRV |
Service locator レコード。一部の VoIP やインスタント メッセージング プロトコルなどのアプリケーションで使用されます。 |
SSHFP |
SSH クライアントが SSH サーバーの公開鍵を検証するための SSH フィンガープリント。 |
TLSA |
TLS クライアントが X.509 サーバー証明書を検証するための TLS 認証レコード。 |
TXT |
テキスト レコード。任意のテキストを含めることができ、セキュリティ情報や不正防止情報などのマシンが読み取れるデータを定義するためにも使用できます。TXT レコードには、1 つまたは複数のテキスト文字列を含めることができます。個々の文字列は 255 文字以下にしてください。複数の文字列がある場合は、メール エージェントや他のソフトウェア エージェントによって連結されます。各文字列は引用符で囲みます。次に例を示します。 "Hello world" "Bye world" |
DNS レコードの操作方法については、レコードの管理をご覧ください。
ワイルドカード DNS レコード
ワイルドカード レコードは、NS レコードを除くすべてのレコード型でサポートされます。
DNSSEC
Cloud DNS はマネージド DNSSEC をサポートしており、なりすまし攻撃やキャッシュ汚染攻撃からドメインを保護します。Google Public DNS などの検証リゾルバを使用すると、DNSSEC によりドメイン ルックアップの強力な認証機能が提供されます（暗号化は行われません）。DNSSEC について詳しくは、DNSSEC 構成の管理をご覧ください。
転送ゾーン
Cloud DNS 転送ゾーンを使用すると、特定の限定公開ゾーン用に転送先ネームサーバーを構成できます。VPC ネットワークからの送信 DNS 転送を実装する方法の 1 つに、転送ゾーンの使用があります。
Cloud DNS 転送ゾーンは、特別なタイプの Cloud DNS 限定公開ゾーンです。ゾーン内にレコードを作成する代わりに、一連の転送先を指定します。各転送先は、VPC ネットワーク内に配置された DNS サーバーの IP アドレスか、Cloud VPN または Cloud Interconnect によって VPC ネットワークに接続されたオンプレミス ネットワーク内にある DNS サーバーの IP アドレスです。
転送先とルーティング方法
Cloud DNS は、3 つのタイプの転送先をサポートし、それらの転送先にトラフィックを標準または限定公開の方法でルーティングできます。
| 転送先 | 説明 | 標準ルーティング | 限定公開ルーティング | リクエストの送信元 |
|---|---|---|---|---|
| タイプ 1 | 転送ゾーンの使用が承認されている同じ VPC ネットワーク内にある Google Cloud VM の IP アドレス | RFC 1918 IP アドレスである必要があります。トラフィックは常に承認済みの VPC ネットワーク経由でルーティングされます。 | 任意の内部 IP アドレス。トラフィックは常に承認済みの VPC ネットワーク経由でルーティングされます。 | 35.199.192.0/19 |
| タイプ 2 | Cloud VPN または Cloud Interconnect を使用して、転送ゾーンのクエリが承認された VPC ネットワークに接続されている、オンプレミス システムの IP アドレス | RFC 1918 IP アドレスである必要があります。トラフィックは常に承認済みの VPC ネットワーク経由でルーティングされます。 | 任意の内部 IP アドレス。トラフィックは常に承認済みの VPC ネットワーク経由でルーティングされます。 | 35.199.192.0/19 |
| タイプ 3 | インターネットで一般公開されている DNS ネームサーバーの IP アドレス | インターネット ルーティング可能なアドレスである必要があります。トラフィックは常にインターネットにルーティングされます。 | 限定公開ルーティングはサポートされていません。 | Google Public DNS ソース範囲 |
転送先を転送ゾーンに追加するときには、次の 2 つのルーティング方法のいずれかを選択できます。
標準ルーティング: 転送先が RFC 1918 アドレスを使用しているかどうかに基づいて、承認済みの VPC ネットワークまたはインターネット経由でトラフィックをルーティングします。タイプ 1 とタイプ 2 の転送先は RFC 1918 IP アドレスである必要があり、タイプ 3 のアドレスはインターネットにアクセス可能なものである必要があります。
限定公開ルーティング: 転送先の IP アドレスに関係なく、常に承認済みの VPC ネットワーク経由でトラフィックをルーティングします。したがって、タイプ 1 とタイプ 2 の転送先のみがサポートされます。
限定公開ルーティングは、VPC ネットワークで転送されたすべてのクエリを追跡し、VPC ネットワークごとにクエリを分離してセキュリティを確保します。そのため、送信されるレスポンスが送信リクエストと同じ VPC ネットワーク上にあることを確認する必要があります。
転送ゾーンの使用
VPC ネットワーク内の VM では、次の場合に Cloud DNS 転送ゾーンを使用できます。
- VPC ネットワークで Cloud DNS 転送ゾーンを使用することが承認されている場合。同じプロジェクト内の複数の VPC ネットワークに対して転送ゾーンの使用を承認できます。
- VPC ネットワーク内の各 VM のゲスト OS が、VM のメタデータ サーバー
169.254.169.254をネームサーバーとして使用している場合。
重複する転送ゾーン
Cloud DNS 転送ゾーンは Cloud DNS 限定公開マネージド ゾーンの一種であるため、重複する複数のゾーンを作成できます。前述のように構成された VM は、サフィックスが最も長いゾーンを使用して、VPC 名前解決順序に従ってレコードを解決します。詳しくは、重複するゾーンをご覧ください。
キャッシュと転送ゾーン
Cloud DNS は、Cloud DNS 転送ゾーンに送信されたクエリに対するレスポンスをキャッシュに保存します。Cloud DNS は、到達可能な転送先からキャッシュに保存したレスポンスを次の期間のうち短いほうの期間維持します。
- 60 秒
- レコードの有効期間（TTL）
転送ゾーンのすべての転送先が到達不能になった場合、Cloud DNS はそのゾーンで以前にリクエストされたレコードのキャッシュを各レコードの TTL の期間維持します。
代わりにピアリングを使用する場合
Cloud DNS は、推移的ルーティングによって転送先に接続することはできません。次のシナリオで無効な構成について検討します。
Cloud VPN または Cloud Interconnect を使用して、オンプレミス ネットワークを
vpc-net-aという名前の VPC ネットワークに接続しました。VPC ネットワーク ピアリングを使用して、VPC ネットワーク
vpc-net-aをvpc-net-bに接続しました。カスタムルートをエクスポートするようにvpc-net-aを構成し、それらをインポートするようにvpc-net-bを構成しました。vpc-net-aが接続されているオンプレミス ネットワークに転送先がある転送ゾーンを作成しました。vpc-net-bに対してその転送ゾーンの使用を承認しました。
このシナリオでは、vpc-net-b からオンプレミス ネットワークへの接続があるにもかかわらず、転送先によって提供されるゾーンのレコードを解決できません。このエラーを実際に確認するために、vpc-net-b の VM から次のテストを行います。
- VM のメタデータ サーバー
169.254.169.254に対して、転送ゾーンに定義されたレコードをクエリします。Cloud DNS では転送先への推移的ルーティングがサポートされていないため、このクエリは失敗します。転送ゾーンを使用するには、メタデータ サーバーを使用するように VM を構成する必要があります。 - 転送先に対して同じレコードを直接クエリします。Cloud DNS がこのパスを使用していないにもかかわらず、推移的接続が成功していることが示されます。
この無効なシナリオを修正するには、Cloud DNS ピアリング ゾーンを使用します。
vpc-net-aを転送先とするvpc-net-bに対して承認される Cloud DNS ピアリング ゾーンを作成します。- 転送先がオンプレミス ネームサーバーである
vpc-net-aに対して承認される転送ゾーンを作成します。
これらの手順は、任意の順序で行うことができます。これらの手順を完了すると、vpc-net-a と vpc-net-b の両方の Compute Engine インスタンスがオンプレミスの転送先をクエリできます。
DNS ピアリング
DNS ピアリングを使用すると、あるゾーンの名前空間を送信元とするレコードに対するリクエストを別の VPC ネットワークに送信できます。たとえば、SaaS プロバイダはそれ自体が管理する DNS レコードに SaaS 顧客がアクセスできるようにすることができます。
DNS ピアリングを提供するには、Cloud DNS ピアリング ゾーンを作成し、そのゾーンの名前空間のレコードが利用可能な VPC ネットワークで DNS ルックアップを行うように構成する必要があります。DNS ピアリング ゾーンがルックアップを行う VPC ネットワークは、DNS プロデューサー ネットワークと呼ばれます。
DNS ピアリングを使用するには、ピアリング ゾーンを使用するようにネットワークを承認する必要があります。ピアリング ゾーンの使用を承認された VPC ネットワークは、DNS コンシューマ ネットワークと呼ばれます。
承認されると、DNS コンシューマ ネットワーク内の Google Cloud リソースは、ピアリング ゾーンの名前空間内のレコードを、DNS プロデューサー ネットワーク内に存在するかのように検索できます。ピアリング ゾーンの名前空間内のレコードのルックアップは、DNS プロデューサー ネットワークの名前解決順序に従います。したがって、DNS コンシューマ ネットワーク内の Google Cloud リソースは、DNS プロデューサー ネットワークで利用可能な次のソースからゾーンの名前空間内のレコードを検索できます。
- DNS プロデューサー ネットワークによる使用が承認された Cloud DNS 限定公開マネージド ゾーン
- DNS プロデューサー ネットワークによる使用が承認された Cloud DNS マネージド転送ゾーン
- DNS プロデューサー ネットワーク内の Compute Engine の内部 DNS 名
- DNS プロデューサー ネットワーク内で送信 DNS ポリシーが構成されている場合、代替ネームサーバー
DNS ピアリングの制限事項
DNS ピアリングを構成する場合、次の点に注意してください。
- DNS ピアリングは一方向の関係です。これにより、DNS コンシューマ ネットワーク内の Google Cloud リソースは、ピアリング ゾーンの名前空間内のレコードを、Google Cloud リソースが DNS プロデューサー ネットワーク内にあるかのように検索できます。
- DNS プロデューサー ネットワークとコンシューマ ネットワークは、VPC ネットワークである必要があります。
- DNS ピアリングと VPC ネットワーク ピアリングは異なるサービスです。DNS ピアリングは VPC ネットワーク ピアリングと組み合わせて使用できますが、VPC ネットワーク ピアリングは DNS ピアリングに必須ではありません。
- 推移的 DNS ピアリングはサポートされていますが、単一の推移的ホップを介した場合に限られます。つまり、3 つの VPC ネットワーク（中間のネットワークが推移的ホップとなる）の他に VPC ネットワークを含めることはできません。たとえば、
vpc-net-bを転送先とするピアリング ゾーンをvpc-net-aに作成し、vpc-net-cを転送先とするピアリング ゾーンをvpc-net-bに作成できます。
ピアリング ゾーンを作成するには、DNS プロデューサー ネットワークを含むプロジェクトの DNS ピア IAM ロールが必要です。
重複するゾーン
2 つのゾーンのうち、1 つのゾーンの起点のドメイン名がもう一方のゾーンの起点と同一であるか、その起点のサブドメインである場合、これらは互いに重複しています。次のような例が挙げられます。
gcp.example.comのゾーンとgcp.example.comの別のゾーンは、ドメイン名が同一であるため重複します。dev.gcp.example.comのゾーンとgcp.example.comのゾーンは、dev.gcp.example.comがgcp.example.comのサブドメインであるため重複します。重複するゾーンに適用されるルールについては、次のセクションをご覧ください。
重複するゾーンのルール
Cloud DNS では、重複するゾーンに対して次のルールが適用されます。
重複する一般公開ゾーン同士は、同じ Cloud DNS ネームサーバー上に存在できません。重複ゾーンを作成すると、Cloud DNS はそれらを別のネームサーバーに配置しようとします。それができない場合、Cloud DNS は重複するゾーンを作成できません。
限定公開ゾーンは、一般公開ゾーンと重複できます。
また、スコープの VPC ネットワークが異なる限定公開ゾーン同士も重複が可能です。たとえば、2 つの VPC ネットワークが、それぞれ、ゾーン
gcp.example.com内にdatabase.gcp.example.comというデータベース VM を持つことができます。database.gcp.example.comに対するクエリは、それぞれの VPC ネットワークに対して承認されたゾーンに定義されているゾーンレコードに応じて異なる回答を受け取ります。同じ VPC ネットワークからアクセス可能な 2 つの限定公開ゾーンは、1 つのゾーンがもう一方のゾーンのサブドメインでない限り、同一の起点を持つことはできません。メタデータ サーバーは、最長サフィックス マッチングを使用して、特定のゾーン内のレコードをクエリする起点を決定します。
クエリ解決の例
VPC 名前解決順序で説明しているように、Google Cloud は Cloud DNS ゾーンを解決します。特定のレコードのクエリするゾーンを決定するとき、Cloud DNS はリクエストされたレコードとできるだけ多く一致するゾーンを探そうとします（最長サフィックス マッチング）。
送信サーバー ポリシーで代替ネームサーバーを指定しない限り、Google Cloud はまず、VPC ネットワークに対して承認された限定公開ゾーン（または転送ゾーンかピアリング ゾーン）でレコードを探し、その後一般公開ゾーンでレコードを探そうとします。
次の例は、メタデータ サーバーが DNS レコードをクエリするときに使用する順序を示しています。これらの例では、gcp.example.com と dev.gcp.example.com という 2 つの限定公開ゾーンを作成し、同じ VPC ネットワークからアクセスできることを前提としています。Google Cloud は、VPC ネットワーク内の VM からの DNS クエリを次のように処理します。
- VPC ネットワークに対して承認された
example.comの限定公開ゾーンがないため、メタデータ サーバーは一般公開ネームサーバーを使用してmyapp.example.comのレコードを解決します。 - メタデータ サーバーは、承認済みの限定公開ゾーン
gcp.example.comを使用してレコードmyapp.gcp.example.comを解決します。これは、リクエストされたレコード名と使用可能な限定公開ゾーンに共通する最長のサフィックスがgcp.example.comであるからです。限定公開ゾーンにmyapp.gcp.example.comのレコードが定義されていない場合、一般公開ゾーンgcp.example.comにmyapp.gcp.example.comのレコードが定義されていても、NXDOMAINが返されます。 - 同様に、
myapp.dev.gcp.example.comに対するクエリは、承認済みの限定公開ゾーンdev.gcp.example.comのレコードに従って解決されます。dev.gcp.example.comゾーンにmyapp.dev.gcp.example.comのレコードが定義されていない場合、別の限定公開ゾーンまたは一般公開ゾーンにmyapp.dev.gcp.example.comのレコードが定義されていても、NXDOMAINが返されます。 - リクエストされた DNS レコードと使用可能な限定公開ゾーンの中で
gcp.example.comが共通の最長サフィックスとなるため、myapp.prod.gcp.example.comのクエリは限定公開ゾーンgcp.example.comのレコードに従って解決されます。
スプリット ホライズン DNS の例
スプリット ホライズン DNS 構成では、一般公開ゾーンと限定公開ゾーンの組み合わせを使用できます。限定公開ゾーンを使用すると、承認済みの VPC ネットワーク内の VM からの、同じレコードへのクエリに対して、異なるレスポンスを定義できます。スプリット ホライズン DNS は、発信元の VPC ネットワークに応じて同じ DNS クエリに異なるレコードを提供する必要がある場合に便利です。
例として次のスプリット ホライズンを検討します。
- 一般公開ゾーン
gcp.example.comを作成し、Cloud DNS ネームサーバーを使用するようにその登録事業者を構成しました。 - 限定公開ゾーン
gcp.example.comを作成し、VPC ネットワークに対してこのゾーンへのアクセスを承認しました。
限定公開ゾーンにレコードを 1 つ作成しました。その内容は次のとおりです。
| レコード | 型 | TTL（秒） | データ |
|---|---|---|---|
| foo.gcp.example.com | A | 5 | 10.128.1.35 |
一般公開ゾーンにレコードを 2 つ作成しました。その内容は次のとおりです。
| レコード | 型 | TTL（秒） | データ |
|---|---|---|---|
| foo.gcp.example.com | A | 5 | 104.198.6.142 |
| bar.gcp.example.com | A | 50 | 104.198.7.145 |
次のクエリは、ここで説明するとおりに解決されます。
- VPC ネットワークの VM からの
foo.gcp.example.comに対するクエリは10.128.1.35を返します。 - インターネットからの
foo.gcp.example.comに対するクエリは104.198.6.142を返します。 - VPC ネットワークの VM からの
bar.gcp.example.comに対するクエリは、限定公開ゾーンgcp.example.comにbar.gcp.example.comのレコードがないため、NXDOMAINエラーを返します。 - インターネットからの
bar.gcp.example.comに対するクエリは104.198.7.145を返します。
DNS サーバーのポリシー
VPC ネットワークごとに 1 つの DNS サーバー ポリシーを構成できます。このポリシーでは、受信転送、送信転送、またはその両方を指定できます。このセクションでは、受信サーバー ポリシーとは受信 DNS 転送を許可するポリシーのことを指し、送信サーバー ポリシーとは送信 DNS 転送の実装に使用可能な 1 つの方法のことを指します。ポリシーに両方の機能を実装した場合、そのポリシーは受信サーバー ポリシーにも送信サーバー ポリシーにもなります。
詳しくは、サーバー ポリシーの適用をご覧ください。
受信サーバー ポリシー
各 VPC ネットワークは、ネットワークを使用する VM に DNS 名前解決サービスを提供します。VM がメタデータ サーバー 169.254.169.254 をネームサーバーとして使用する場合、Google Cloud は VPC 名前解決順序に従って DNS レコードを検索します。
デフォルトでは、VPC ネットワークの名前解決サービスは、その名前解決順序に従って、VPC ネットワーク自体でのみ使用できます。Cloud VPN または Cloud Interconnect を使用して接続されたオンプレミス ネットワークでこのような名前解決サービスを利用できるようにするには、VPC ネットワークに受信 DNS ポリシーを作成します。
受信ポリシーを作成すると、VPC ネットワークが使用する各リージョン内にあるサブネットのプライマリ IP アドレス範囲から、Cloud DNS が内部 IP アドレスを取得します。取得された内部 IP アドレスは、受信 DNS リクエストのエントリ ポイントとして使用されます。
受信ポリシーのエントリ ポイント
Cloud DNS で受信 DNS ポリシーに使用されるリージョン内部 IP アドレスは、VPC ネットワークの名前解決サービスへのエントリ ポイントとして機能します。受信 DNS ポリシーを使用するには、オンプレミス ネットワークを VPC ネットワークに接続する Cloud VPN トンネルまたは Cloud Interconnect アタッチメント（VLAN）と同じリージョン内にあるプロキシ IP アドレスに DNS クエリを転送するようにオンプレミス システムまたはネームサーバーを構成する必要があります。
受信サーバー ポリシーを作成する方法については、受信サーバー ポリシーの作成をご覧ください。
送信サーバー ポリシー
VPC 名前解決順序を変更するには、送信 DNS ポリシーを作成して代替ネームサーバーのリストを指定します。VPC ネットワークの代替ネームサーバーを指定すると、Google Cloud は、メタデータ サーバー（169.254.169.254）を使用するように構成されている VPC ネットワーク内の VM から DNS リクエストが送られてきた場合に、そのサーバーを唯一のネームサーバーとしてクエリして DNS リクエストを処理します。
送信サーバー ポリシーを作成する方法については、送信サーバー ポリシーの作成をご覧ください。
代替ネームサーバーとルーティング方法
Cloud DNS は、3 つのタイプの代替ネームサーバーをサポートし、それらのサーバーにトラフィックを標準と限定公開の方法でルーティングできます。
次の表に、代替ネームサーバーを定義します。
| 代替ネームサーバー | 説明 | 標準ルーティング | 限定公開ルーティング | リクエストの送信元 |
|---|---|---|---|---|
| タイプ 1 | 送信サーバー ポリシーが定義されているのと同じ VPC ネットワークにある Google Cloud VM の IP アドレス | RFC 1918 IP アドレスである必要があります。トラフィックは常に承認済みの VPC ネットワーク経由でルーティングされます。 | 任意の内部 IP アドレス。トラフィックは常に承認済みの VPC ネットワーク経由でルーティングされます。 | 35.199.192.0/19 |
| タイプ 2 | Cloud VPN または Cloud Interconnect を使用して、送信サーバー ポリシーが設定されている VPC ネットワークに接続されている、オンプレミス システムの IP アドレス | RFC 1918 IP アドレスである必要があります。トラフィックは常に承認済みの VPC ネットワーク経由でルーティングされます。 | 任意の内部 IP アドレス。トラフィックは常に承認済みの VPC ネットワーク経由でルーティングされます。 | 35.199.192.0/19 |
| タイプ 3 | インターネットで一般公開されている DNS ネームサーバーの IP アドレス | インターネット ルーティング可能なアドレスである必要があります。トラフィックは常にインターネットにルーティングされます。 | 限定公開ルーティングはサポートされていません。 | Google Public DNS ソース範囲 |
送信転送ポリシーの代替ネームサーバーを指定する場合は、次の 2 つのルーティング方法のいずれかを選択できます。
標準ルーティング: 代替ネームサーバーが RFC 1918 アドレスを使用しているかどうかに基づいて、承認済みの VPC ネットワークまたはインターネット経由でトラフィックをルーティングします。タイプ 1 とタイプ 2 の代替ネームサーバーは RFC 1918 IP アドレスである必要があり、タイプ 3 のアドレスはインターネットにアクセス可能なものである必要があります。
限定公開ルーティング: 代替ネームサーバーの IP アドレスに関係なく、常に承認済みの VPC ネットワーク経由でトラフィックをルーティングします。したがって、タイプ 1 とタイプ 2 の代替ネームサーバーのみがサポートされます。
アクセス制御
一般的なアクセス制御
Google Cloud Console の [IAM と管理] ページで、DNS レコードへの変更を許可されたユーザーを管理できます。変更を行うことを承認されたユーザーは、Cloud Console の [権限] セクションに editor または owner のいずれかとしてリスト表示されている必要があります。権限レベルが閲覧者の場合は、Cloud DNS レコードへの読み取り専用アクセスが付与されます。
これらの権限は、DNS サービスの管理に使用できるサービス アカウントにも適用されます。
マネージド ゾーンのアクセス制御
プロジェクト オーナーまたはプロジェクトの編集者のロールを持つユーザーは、管理している特定のプロジェクトのマネージド ゾーンを管理または表示できます。
DNS 管理者または DNS の読み取りのロールを持つユーザーは、アクセス権を持つすべてのプロジェクトのマネージド ゾーンを管理または表示できます。
プロジェクト オーナー、編集者、DNS 管理者、および DNS の読み取りのロールを持つユーザーは、現在のプロジェクトの任意の VPC ネットワークに適用されている限定公開ゾーンのリストを表示できます。
パフォーマンスとタイミング
Cloud DNS は、エニーキャストを使用して、全世界の複数のロケーションからマネージド ゾーンをサポートし、高い可用性を提供します。リクエストは最も近いロケーションに自動的にルーティングされるため、レイテンシが低減され、ユーザーの権威名の検索パフォーマンスが改善されます。
変更の伝播
変更は、2 段階で伝播されます。まず、API またはコマンドライン ツールを介して送信する変更を、Cloud DNS の権威 DNS サーバーに push する必要があります。次に、DNS リゾルバがレコードのキャッシュ期限が切れたときにこの変更をピックアップする必要があります。
DNS リゾルバのキャッシュは、レコードに設定した有効期間（TTL）値（秒で指定）で制御されます。たとえば、TTL 値を 86,400（24 時間の秒数）に設定すると、DNS リゾルバにレコードを 24 時間キャッシュ保存することを指示したことになります。一部の DNS リゾルバでは、TTL 値を無視したり、レコードの完全な伝播を遅延させることができる独自の値を使用します。
時間が非常に限られているサービスへの変更を計画している場合は、変更を行う前に、TTL の値を変更して短縮できます。この方法は、キャッシングの時間枠を短縮して、新しいレコードの設定に変更をより迅速に反映するのに効果的です。変更したら、TTL の値を元に戻して、DNS リゾルバの負荷を軽減できます。
次のステップ
- Cloud DNS の使用を開始するには、クイックスタートをご覧ください。
- ドメインの登録と設定の詳細な手順については、Cloud DNS を使用してドメインを設定するをご覧ください。
- API クライアント ライブラリについて学習する。