このページは Cloud Translation API によって翻訳されました。

DNS ゾーンの概要

Cloud DNS は、さまざまな種類の一般公開ゾーンと限定公開ゾーンをサポートしています。このドキュメントでは、さまざまなゾーンタイプと、それらを使用するタイミングについて説明します。

転送ゾーン

Cloud DNS 転送ゾーンを使用すると、特定の限定公開ゾーン用に転送先ネームサーバーを構成できます。VPC ネットワークからの送信 DNS 転送を実装する方法の 1 つに、転送ゾーンの使用があります。

Cloud DNS 転送ゾーンは、特別なタイプの Cloud DNS 限定公開ゾーンです。ゾーン内にレコードを作成する代わりに、一連の転送先を指定します。各転送先は、VPC ネットワーク内に配置された DNS サーバーの IP アドレスか、Cloud VPN または Cloud Interconnect によって VPC ネットワークに接続されたオンプレミスネットワーク内にある DNS サーバーの IP アドレスです。

転送先とルーティング方法

Cloud DNS は 3 つのタイプの転送先をサポートしており、接続用のルーティング方法（標準または限定公開）を提供します。

転送先	説明	標準ルーティングのサポート	限定公開ルーティングのサポート	リクエスト元
タイプ 1	Google Cloud VM、または転送ゾーンの使用が許可されている同じ VPC ネットワーク内の内部パススルーネットワークロードバランサの内部 IP アドレス。	RFC 1918 の IP アドレスのみ - トラフィックは、常に承認済み VPC ネットワーク経由でルーティングされます。	内部 IP アドレス（RFC 1918 のプライベートアドレス、RFC 1918 以外のプライベート IP アドレス、またはプライベートで再利用された外部 IP アドレスなど、ただし禁止されている転送先の IP アドレスを除く） - トラフィックは常に承認済みの VPC ネットワーク経由でルーティングされます。	`35.199.192.0/19`
タイプ 2	Cloud VPN または Cloud Interconnect を使用して、転送ゾーンのクエリが承認された VPC ネットワークに接続されている、オンプレミスシステムの IP アドレス。	RFC 1918 の IP アドレスのみ - トラフィックは、常に承認済み VPC ネットワーク経由でルーティングされます。	内部 IP アドレス（RFC 1918 のプライベートアドレス、RFC 1918 以外のプライベート IP アドレス、またはプライベートで再利用された外部 IP アドレスなど、ただし禁止されている転送先の IP アドレスを除く） - トラフィックは常に承認済みの VPC ネットワーク経由でルーティングされます。	`35.199.192.0/19`
タイプ 3	インターネットからアクセス可能な DNS ネームサーバーの外部 IP アドレスまたは Google Cloud リソースの外部 IP アドレス（別の VPC ネットワークにある VM の外部 IP アドレスなど）。	インターネットルーティング可能な外部 IP アドレスのみ - トラフィックは、常にインターネットまたは Google Cloud リソースの外部 IP アドレスにルーティングされます。	限定公開ルーティングはサポートされていません。限定公開ルーティングがオフになっていることを確認してください。	Google Public DNS ソース範囲

転送先を転送ゾーンに追加するときには、次の 2 つのルーティング方法のいずれかを選択できます。

標準ルーティング: 転送先が RFC 1918 IP アドレスであるかどうかに基づいて、認可済みの VPC ネットワークまたはインターネット経由でトラフィックをルーティングします。転送先が RFC 1918 IP アドレスの場合、Cloud DNS は転送先をタイプ 1 またはタイプ 2 転送先に分類し、リクエストを認可済みの VPC ネットワークを通じて転送します。転送先が RFC 1918 IP アドレスでない場合、Cloud DNS は転送先をタイプ 3 として分類し、転送先がインターネットにアクセスできることが必要となります。
限定公開ルーティング: 転送先の IP アドレスが RFC 1918 であるか否かにかかわらず、常に認可済みの VPC ネットワーク経由でトラフィックをルーティングします。したがって、タイプ 1 とタイプ 2 の転送先のみがサポートされます。

タイプ 1 またはタイプ 2 の転送先にアクセスするために、Cloud DNS は DNS クライアントが配置されている、認可済みの VPC ネットワーク内のルートを使用します。これらのルートは、転送先への安全なパスを定義します。

タイプ 1 の転送先にトラフィックを送信するために、Cloud DNS では自動的に作成されたサブネットルートが使用されます。応答するには、タイプ 1 の転送先は、Cloud DNS レスポンス用の特別なルーティングパスを使用します。
タイプ 2 の転送先にトラフィックを送信するために、Cloud DNS はカスタム動的ルートまたはカスタム静的ルート（ネットワークタグを持つカスタム静的ルートを除く）を使用します。タイプ 2 の転送先が応答する際は、オンプレミスネットワーク内のルートを使用します。

タイプ 1 転送先とタイプ 2 転送先のネットワーク要件の詳細については、転送先ネットワークの要件をご覧ください。

禁止された転送先の IP アドレス

Cloud DNS の転送先に次の IP アドレスは使用できません。

169.254.0.0/16
192.0.0.0/24
192.0.2.0/24
192.88.99.0/24
198.51.100.0/24
203.0.113.0/24
224.0.0.0/4
240.0.0.0/4
::1/128
::/128
2001:db8::/32
fe80::/10
fec0::/10
ff00::/8

転送先の選択順序

Cloud DNS では、転送ゾーンの転送先のリストを構成できます。

2 つ以上の転送先を構成すると、Cloud DNS は内部アルゴリズムを使用して転送先を選択します。このアルゴリズムでは、各転送先がランク付けされます。

リクエストを処理するため、Cloud DNS はまずランクが最も高い転送先に接続し、DNS クエリを試みます。このサーバーが応答しない場合、Cloud DNS はランクがその次に高い転送先にリクエストを再度試みます。応答する転送先がない場合、Cloud DNS は SERVFAIL レスポンスを合成します。

ランキングアルゴリズムは自動で、次の要因により転送先のランキングが増分されます。

転送先で処理された、成功した DNS レスポンスの数が多いほど増分されます。成功した DNS レスポンスには NXDOMAIN レスポンスが含まれます。
転送先との通信のレイテンシ（ラウンドトリップ時間）が少ないほど増分されます。

転送ゾーンの使用

VPC ネットワーク内の VM では、次の場合に Cloud DNS 転送ゾーンを使用できます。

VPC ネットワークで Cloud DNS 転送ゾーンを使用することが承認されている場合。転送ゾーンを使用するには、VPC ネットワークが同じ組織内にある限り、同じプロジェクト内またはプロジェクト間で複数の VPC ネットワークを承認できます。
VPC ネットワーク内の各 VM のゲストオペレーティングシステムが、VM のメタデータサーバー 169.254.169.254 をネームサーバーとして使用している場合。

重複する転送ゾーン

Cloud DNS 転送ゾーンは Cloud DNS 限定公開マネージドゾーンの一種であるため、重複する複数のゾーンを作成できます。前述のように構成された VM は、サフィックスが最も長いゾーンを使用して、名前解決順序に従ってレコードを解決します。詳しくは、重複するゾーンをご覧ください。

キャッシュと転送ゾーン

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 インスタンスがオンプレミスの転送先をクエリできます。

転送ゾーンの作成方法については、転送ゾーンを作成するをご覧ください。

ピアリングゾーン

ピアリングゾーンは、異なる VPC ネットワーク内の Cloud DNS ゾーン間で DNS リクエストを送信できる Cloud DNS 限定公開ゾーンです。たとえば、ソフトウェアアズサービス（SaaS）プロバイダは、Cloud DNS のマネージド DNS レコードに顧客がアクセスできるようにすることができます。

DNS ピアリングを提供するには、Cloud DNS の限定公開ピアリングゾーンを作成し、そのゾーンの名前空間のレコードが利用可能な VPC ネットワークで DNS ルックアップを実行するように構成する必要があります。DNS ピアリングゾーンがルックアップを実行する VPC ネットワークは、DNS プロデューサーネットワークと呼ばれます。

ピアリングゾーンは、ゾーン構成中に選択した VPC ネットワークにのみ表示されます。ピアリングゾーンの使用を認可された 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 ルックアップを実行できます。

DNS ピアリングの制限事項と要点

DNS ピアリングを構成する場合、次の点に注意してください。

DNS ピアリングは一方向の関係です。これにより、DNS コンシューマネットワーク内の Google Cloud リソースは、ピアリングゾーンの名前空間内のレコードを、Google Cloud リソースが DNS プロデューサーネットワーク内にあるかのように検索できます。
DNS プロデューサーネットワークとコンシューマネットワークは、VPC ネットワークである必要があります。
通常、DNS プロデューサーネットワークとコンシューマネットワークは同じ組織に属しますが、組織間の DNS ピアリングもサポートされています。
DNS ピアリングと VPC ネットワークピアリングは異なるサービスです。VPC ネットワークピアリングでは、DNS 情報が自動的に共有されません。DNS ピアリングは VPC ネットワークピアリングと組み合わせて使用できますが、VPC ネットワークピアリングは DNS ピアリングに必須ではありません。
推移的 DNS ピアリングはサポートされていますが、単一の推移的ホップを介した場合に限られます。つまり、3 つの VPC ネットワーク（中間のネットワークが推移的ホップとなる）の他に VPC ネットワークを含めることはできません。たとえば、vpc-net-b を転送先とするピアリングゾーンを vpc-net-a に作成し、vpc-net-c を転送先とするピアリングゾーンを vpc-net-b に作成できます。
DNS ピアリングを使用して転送ゾーンをターゲットにする場合は、転送ゾーンがあるターゲット VPC ネットワークの VM、VLAN アタッチメント、または Cloud VPN トンネルが、DNS ピアリングゾーンを使用するソース VM と同じリージョンに配置されている必要があります。この制限の詳細については、コンシューマ VPC ネットワーク内の VM からプロデューサー VPC ネットワークへのクエリ転送が機能しないをご覧ください。

ピアリングゾーンの作成方法については、ピアリングゾーンを作成するをご覧ください。

マネージド逆引き参照ゾーン

マネージド逆引き参照ゾーンは特別な属性を持つ限定公開ゾーンです。この属性により、Cloud DNS は、Compute Engine の DNS データに対して PTR 参照を実行します。

限定公開ゾーンの RFC 1918 アドレス用 PTR レコード

RFC 1918 アドレス用のカスタム PTR レコードを使用してリバースルックアップを行うには、少なくとも次のいずれかと同程度に限定的な Cloud DNS 限定公開ゾーンを作成する必要があります。このようになるのは、名前解決の順序で説明している最長サフィックスマッチングが機能するからです。

ゾーンの例を次に示します。

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 レコードは、内部 DNS が自動的に作成する PTR レコードによってオーバーライドされます。これは、内部 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. 内部 DNS ゾーンが応答します。test.example.domain の Cloud DNS 限定公開ゾーン内の PTR レコードは無視されます。

VM に対して自動的に作成される内部 DNS PTR レコードをオーバーライドするには、このセクションで提示しているゾーンの少なくとも 1 つと同程度に限定的な限定公開ゾーン内で、カスタム 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 用に自動的に作成される内部 DNS PTR レコードを特定の PTR レコードでオーバーライドする場合、5.10.in-addr.arpa. の限定公開ゾーンを使用して、それらのレコードを保持できます。

マネージド逆引き参照ゾーンの作成方法については、マネージド逆引き参照ゾーンを作成するをご覧ください。

重複するゾーン

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 ネットワークに対して承認されたゾーンに定義されているゾーンレコードに応じて異なる回答を受け取ります。
1 つのゾーンが他のゾーンのサブドメインでない限り、同じ VPC ネットワークからアクセス可能な 2 つの限定公開ゾーンは同一の起点を持つことはできません。メタデータサーバーは、最長サフィックスマッチングを使用して、特定のゾーン内のレコードをクエリする起点を決定します。

クエリ解決の例

名前解決順序で説明しているように、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.（末尾のドットに注意）のレコードを解決します。Compute Engine VM から dig を使用して、VM のデフォルトのネームサーバーにクエリを実行します。
```
dig myapp.example.com.
```
詳細については、メタデータサーバーを使用して DNS 名を照会するをご覧ください。
メタデータサーバーは、承認済みの限定公開ゾーン 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 ネットワークに対してこのゾーンへのアクセスを承認しました。

限定公開ゾーンでは、次の表に示すように単一のレコードを作成しました。

レコード	タイプ	TTL（秒）	データ
myrecord1.gcp.example.com	A	5	10.128.1.35

一般公開ゾーンにレコードを 2 つ作成しました。

レコード	タイプ	TTL（秒）	データ
myrecord1.gcp.example.com	A	5	104.198.6.142
myrecord2.gcp.example.com	A	50	104.198.7.145

次のクエリは、ここで説明するとおりに解決されます。

VPC ネットワークの VM からの myrecord1.gcp.example.com に対するクエリは 10.128.1.35 を返します。
インターネットからの myrecord1.gcp.example.com に対するクエリは 104.198.6.142 を返します。
VPC ネットワークの VM からの myrecord2.gcp.example.com に対するクエリは、限定公開ゾーン gcp.example.com に myrecord2.gcp.example.com のレコードがないため、NXDOMAIN エラーを返します。
インターネットからの myrecord2.gcp.example.com に対するクエリは 104.198.7.145 を返します。

クロスプロジェクトバインディング

プロジェクト間のバインディングを使用すると、VPC ネットワーク全体の DNS 名前空間の所有権とは無関係に、サービスプロジェクトの DNS 名前空間の所有権を保持できます。

一般的な共有 VPC 設定では、サービスプロジェクトが仮想マシン（VM）アプリケーションまたはサービスの所有権を持っていますが、VPC ネットワークとネットワークインフラストラクチャの所有権はホストプロジェクトが所有します。多くの場合、VPC ネットワークの名前空間から DNS 名前空間が作成され、サービスプロジェクトのリソースと一致します。このような設定では、各サービスプロジェクトの DNS 名前空間の管理を各サービスプロジェクトの管理者（多くは別の部門または事業）に委任するほうが便利です。プロジェクト間のバインディングを使用すると、サービスプロジェクトの DNS 名前空間の所有権と VPC ネットワーク全体の DNS 名前空間の所有権を分離できます。

次の図は、DNS ピアリングを使用した一般的な共有 VPC 設定を示しています。

DNS ピアリングを使用した共有 VPC 設定。 — DNS ピアリングを使用した共有 VPC 設定（クリックで拡大）

次の図は、プロジェクト間のバインディングを使用した設定を示しています。Cloud DNS では、各サービスプロジェクトが独自の DNS ゾーンを作成して所有できますが、それでもホストプロジェクトが所有する共有ネットワークにバインドされています。これにより、DNS ゾーン管理者には、自律性が高まり、権限の境界がより正確になります。

プロジェクト間のバインディングには次の機能があります。

サービスプロジェクトの管理者とユーザーが独自の DNS ゾーンを作成して管理できます。
プレースホルダ VPC ネットワークを作成する必要はありません。
ホストプロジェクトの管理者は、サービスプロジェクトを管理する必要がありません。
IAM ロールは引き続きプロジェクトレベルで適用されます。
すべての DNS ゾーンは共有 VPC ネットワークに直接関連付けられます。
多対多の DNS 解決がすぐに利用可能。共有 VPC ネットワークのどの VM も関連付けられたゾーンを解決できます。
推移的なホップ上限はありません。ハブアンドスポーク設計で管理できます。

クロスプロジェクトバインディングを有効にしてゾーンを作成する方法については、プロジェクト間のバインディングゾーンを作成するをご覧ください。

ゾーン Cloud DNS ゾーン

ゾーン Cloud DNS を使用すると、Google Cloud ゾーンのみを対象とする限定公開 DNS ゾーンを作成できます。クラスタスコープを選択すると、GKE 用のゾーン Cloud DNS ゾーンが作成されます。

デフォルトの Cloud DNS サービスは本来グローバルであり、DNS 名は VPC ネットワーク全体で可視になります。この構成では、サービスがグローバルな停止にさらされることになります。ゾーン Cloud DNS は、各 Google Cloud ゾーンに存在する新しいプライベート Cloud DNS サービスです。障害発生ドメインはその Google Cloud ゾーンの内部に包含されます。グローバルな停止が発生しても、ゾーン Cloud DNS の限定公開ゾーンは影響を受けません。Google Cloud ゾーンが停止したとしても、影響が及ぶ範囲は、その特定の Google Cloud ゾーンと、その Google Cloud ゾーン内の Cloud DNS ゾーンのみです。ゾーンのサービス内で作成されたリソースは、その Google Cloud ゾーンのみで可視になることに注意してください。

ゾーンの Cloud DNS クラスタスコープゾーンを構成する方法については、ゾーンの GKE クラスタスコープゾーンを構成するをご覧ください。

ゾーン Cloud DNS のサポート

次の表に、ゾーン Cloud DNS サービスでサポートされている Cloud DNS のリソースと機能を示します。

リソースまたは機能	グローバル Cloud DNS で利用可能か	ゾーン Cloud DNS で利用可能か
一般公開マネージドゾーン
限定公開マネージドゾーン（ネットワークまたは VPC スコープ）
限定公開マネージドゾーン（GKE スコープ）
転送ゾーン¹
ピアリングゾーン
マネージド逆引きゾーン
変更の作成、またはレコードの管理²
Service Directory ゾーン
ポリシー
レスポンスポリシー（ネットワークスコープ）
レスポンスポリシー（GKE クラスタスコープ）
レスポンスポリシールール

¹ ゾーン Cloud DNS では、GKE クラスタをスコープとする転送ゾーンのみがサポートされます。

² GKE コントローラは再起動時にレコードへの変更を上書きします。

ゾーン Cloud DNS ゾーンの料金

ゾーン Cloud DNS ゾーンとレスポンスポリシーの料金は、対応するグローバル版の場合と同じです。

次のステップ

マネージドゾーンを操作するには、ゾーンの作成、変更、削除をご覧ください。
Cloud DNS の使用時に発生する可能性のある一般的な問題の解決策については、トラブルシューティングをご覧ください。
Cloud DNS の概要については、Cloud DNS の概要をご覧ください。