Cloud DNS は、さまざまな種類の プライベート ゾーンをサポートしています。このドキュメントでは、さまざまなゾーンタイプの詳細と、どのような場合にどのゾーンタイプを使用すればよいかについて説明します。
転送ゾーン
Cloud DNS 転送ゾーンを使用すると、特定のプライベート ゾーン用の転送先ネームサーバーを構成できます。VPC ネットワークからの送信 DNS 転送を実装する方法の 1 つに、転送ゾーンの使用があります。
Cloud DNS 転送ゾーンは、特別なタイプの Cloud DNS プライベート ゾーンです。ゾーン内にレコードを作成する代わりに、一連の転送先を指定します。各転送先は、VPC ネットワーク内にある DNS サーバーの完全修飾ドメイン名（FQDN）または IP アドレス、Cloud VPN または Cloud Interconnect によって VPC ネットワークに接続されたオンプレミス ネットワーク内にある DNS サーバーの完全修飾ドメイン名（FQDN）または IP アドレスです。
転送先とルーティング方法
Cloud DNS は 4 種類の転送先をサポートしており、標準ルーティングまたはプライベート ルーティングの接続方法を提供します。
| 転送先 | 説明 | 標準ルーティングのサポート | プライベート ルーティングのサポート | リクエスト元 |
|---|---|---|---|---|
| タイプ 1 | Trusted Cloud VM の内部 IP アドレス、または転送ゾーンの使用が承認されている同じ VPC ネットワーク内の内部パススルー ネットワーク ロードバランサ。 | RFC 1918 の IP アドレスのみ - トラフィックは、常に承認済み VPC ネットワーク経由でルーティングされます。 | 内部 IP アドレス（RFC 1918 のプライベート アドレス、RFC 1918 以外のプライベート IP アドレス、またはプライベートで再利用された外部 IP アドレスなど、ただし禁止されている転送先 IP アドレスを除く） - トラフィックは常に承認済みの VPC ネットワーク経由でルーティングされます。 | 177.222.82.0/25 |
| タイプ 2 | Cloud VPN または Cloud Interconnect を使用して、転送ゾーンのクエリが承認された VPC ネットワークに接続されている、オンプレミス システムの IP アドレス。 | RFC 1918 の IP アドレスのみ - トラフィックは、常に承認済み VPC ネットワーク経由でルーティングされます。 | 内部 IP アドレス（RFC 1918 のプライベート アドレス、RFC 1918 以外のプライベート IP アドレス、またはプライベートで再利用された外部 IP アドレスなど、ただし禁止されている転送先 IP アドレスを除く） - トラフィックは常に承認済みの VPC ネットワーク経由でルーティングされます。 | 177.222.82.0/25 |
| タイプ 4 | VPC ネットワークの解決順序で IPv4 アドレスと IPv6 アドレスの両方に解決できるターゲット ネームサーバーの完全修飾ドメイン名。 | 解決された転送先のネットワークに応じて、トラフィックは次のいずれかの方法でルーティングされます。
|
解決された転送先のネットワークに応じて、トラフィックは、RFC 1918 のプライベート アドレス、RFC 1918 以外のプライベート IP アドレスなどの内部 IP アドレス経由、またはプライベートで再利用される外部 IP アドレス経由でルーティングされます（ただし、禁止されている転送先の IP アドレスを除く）。トラフィックは常に承認済みの VPC ネットワーク経由でルーティングされます。 DNS ネームサーバーが、インターネットにアクセス可能な外部 IP アドレス、または外部 IP アドレスに解決された場合、限定公開ルーティングはサポートされません。 |
|
転送先を転送ゾーンに追加するときには、次の 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 の転送先のみがサポートされます。
転送先に FQDN を使用する場合は、ルーティング方法がネットワーク タイプと一致している必要があります。ドメイン ネームサーバーがパブリック IP アドレスに解決される場合は、標準ルーティングを使用する必要があります。
タイプ 1 またはタイプ 2 の転送先へのアクセスには、Cloud DNS で DNS クライアントが存在する承認済み VPC ネットワーク内のルートが使用されます。これらのルートは、転送先への安全なパスを定義します。
タイプ 1 の転送先へのトラフィックの送信には、Cloud DNS で自動的に作成されたサブネット ルートが使用されます。タイプ 1 の転送先からの応答には、Cloud DNS レスポンス用の特別なルーティング パスが使用されます。
タイプ 2 の転送先へのトラフィックの送信には、Cloud DNS でカスタム動的ルートまたはカスタム静的ルート（ネットワーク タグを持つカスタム静的ルートを除く）が使用されます。タイプ 2 の転送先からの応答には、オンプレミス ネットワーク内のルートが使用されます。
タイプ 1 転送先とタイプ 2 転送先のネットワーク要件の詳細については、転送先ネットワークの要件をご覧ください。
タイプ 4 の転送先にアクセスするには、Cloud DNS はまずドメイン名を解決し、次に送信元ネットワークのルーティング方法を使用します。たとえば、subdomain.example.com が Cloud VPN を介した転送ゾーンのクエリが承認された VPC ネットワークに接続されているオンプレミス システムの IP アドレスに解決される場合、タイプ 2 の転送ターゲットと同じルーティング ルールが使用されます。
転送のターゲットとして FQDN を使用する場合、使用できるのは 1 つだけです。転送ターゲットは最大 50 個の IP アドレスに解決できます。
禁止されている転送先 IP アドレス
Cloud DNS の転送先に次の IP アドレスは使用できません。
169.254.0.0/16192.0.0.0/24192.0.2.0/24192.88.99.0/24198.51.100.0/24203.0.113.0/24224.0.0.0/4240.0.0.0/4::1/128::/1282001:db8::/32fe80::/10fec0::/10ff00::/8
転送先の選択順序
Cloud DNS では、転送ゾーンの転送先のリストを構成できます。
2 つ以上の転送先を構成すると、Cloud DNS は内部アルゴリズムを使用して転送先を選択します。このアルゴリズムでは、転送先のランク付けが行われます。
転送ターゲットとして FQDN を使用すると、Cloud DNS はドメイン名を最大 50 個の IP アドレスのセットに解決し、これらの IP アドレスに同じアルゴリズムを適用します。
リクエストを処理するため、Cloud DNS はまずランクが最も高い転送先に接続し、DNS クエリを試みます。このサーバーが応答しない場合、Cloud DNS はランクがその次に高い転送先にリクエストを再度試みます。応答する転送先がない場合、Cloud DNS は SERVFAIL レスポンスを合成します。
ランキング アルゴリズムは自動で、次の要因により転送先のランキングが増分されます。
- 転送先で処理された、成功した DNS レスポンスの数が多いほど増分されます。成功した DNS レスポンスには NXDOMAIN レスポンスが含まれます。
- 転送先との通信のレイテンシ（ラウンドトリップ時間）が少ないほど増分されます。
転送ゾーンの使用
VPC ネットワーク内の VM では、次の場合に Cloud DNS 転送ゾーンを使用できます。
VPC ネットワークで Cloud DNS 転送ゾーンを使用することが承認されている場合。転送ゾーンを使用するために、同じプロジェクト内の複数の VPC ネットワーク、または属するプロジェクトが異なる複数の VPC ネットワークを承認できます。ただし、それらの VPC ネットワークが同じ組織内にあることを前提とします。
VPC ネットワーク内の各 VM のゲスト オペレーティング システムが、VM のメタデータ サーバー
169.254.169.254をネームサーバーとして使用している場合。
FQDN をターゲット ネームサーバーとして使用する場合は、次の項目を確認します。
- 転送先は 1 つのみ指定できます。
- 別の転送ゾーンを介した FQDN ターゲット解決はサポートされません。
- サーバー ポリシーで代替ネームサーバーとして FQDN を使用することはできません。
- FQDN ターゲットは、最大 50 個の関連付けられた IP アドレスに解決できます。解決されたアドレスが 50 を超える場合は切り捨てられます。
重複する転送ゾーン
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 プライベート ゾーンです。たとえば、Software as a Service（SaaS）プロバイダは、Cloud DNS に存在する自社のマネージド DNS レコードに顧客がアクセスできるようにすることができます。
DNS ピアリングを提供するには、Cloud DNS プライベート ピアリング ゾーンを作成し、そのゾーンの名前空間用のレコードが提供されている VPC ネットワークで DNS ルックアップが行われるようにピアリング ゾーンを構成する必要があります。DNS ピアリング ゾーンがルックアップを行う VPC ネットワークのことを「DNS プロデューサー ネットワーク」と呼びます。
ピアリング ゾーンは、ゾーン構成中に選択した VPC ネットワークからのみ見えます。ピアリング ゾーンを使用することを承認された VPC ネットワークのことを「DNS コンシューマ ネットワーク」と呼びます。
DNS コンシューマ ネットワーク内の Trusted Cloud リソースが承認された後、それらのリソースは、あたかもそれ自体が DNS プロデューサー ネットワーク内に存在するかのように、ピアリング ゾーンの名前空間内のレコードを検索できます。ピアリング ゾーンの名前空間内のレコードの検索は、DNS プロデューサー ネットワークの名前解決順序に従います。
したがって、DNS コンシューマ ネットワーク内の Trusted Cloud リソースは、DNS プロデューサー ネットワークで使用可能な次のソースからゾーンの名前空間内のレコードを検索できます。
- DNS プロデューサー ネットワークによる使用が承認された Cloud DNS マネージド プライベート ゾーン。
- DNS プロデューサー ネットワークによる使用が承認された Cloud DNS マネージド転送ゾーン。
- DNS プロデューサー ネットワーク内の Compute Engine の内部 DNS 名。
- DNS プロデューサー ネットワーク内で送信サーバー ポリシーが構成されている場合、代替ネームサーバー。
DNS ピアリングを使用すると、あるネットワーク（DNS コンシューマ ネットワーク）から別のネットワーク（DNS プロデューサー ネットワーク）に DNS リクエストを転送し、転送先で DNS ルックアップを実行できます。
DNS ピアリングの制限事項と要点
DNS ピアリングを構成する場合、次の点に注意してください。
- DNS ピアリングは一方向の関係です。これにより、DNS コンシューマ ネットワーク内の Trusted Cloud リソースは、ピアリング ゾーンの名前空間内のレコードを、あたかもその Trusted 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に作成できます。 - プロデューサー VPC ネットワークでグローバル動的ルーティングが無効になっている間に DNS ピアリングを使用して転送ゾーンをターゲットにする場合は、転送ゾーンがあるターゲット VPC ネットワークの VM、VLAN アタッチメント、または Cloud VPN トンネルが、DNS ピアリング ゾーンを使用するソース VM と同じリージョンに配置されている必要があります。この制限の詳細については、コンシューマ VPC ネットワーク内の VM からプロデューサー VPC ネットワークへのクエリ転送が機能しないをご覧ください。
ピアリング ゾーンの作成方法については、ピアリング ゾーンを作成するをご覧ください。
重複するゾーン
2 つのゾーンのうち、1 つのゾーンの起点のドメイン名がもう一方のゾーンの起点と同一であるか、その起点のサブドメインである場合、これらは互いに重複しています。次に例を示します。
gcp.example.comのゾーンとgcp.example.comの別のゾーンは、ドメイン名が同一であるため重複します。dev.gcp.example.comのゾーンとgcp.example.comのゾーンは、dev.gcp.example.comがgcp.example.comのサブドメインであるため重複します。
重複するゾーンのルール
Cloud DNS では、重複するゾーンに対して次のルールが適用されます。
スコープの VPC ネットワークが異なるプライベート ゾーン同士を重複させることができます。たとえば、2 つの VPC ネットワークが、それぞれ、ゾーン gcp.example.com 内に database.gcp.example.com というデータベース VM を持つことができます。database.gcp.example.com に対するクエリは、それぞれの VPC ネットワークに対して承認されたゾーンに定義されているゾーンレコードに応じて異なる回答を受け取ります。
一方のゾーンが他方のゾーンのサブドメインでない限り、同じ VPC ネットワークからのアクセスが承認されている 2 つのプライベート ゾーンが同一の起点を持つことはできません。メタデータ サーバーは、最長サフィックス マッチングを使用して、特定のゾーン内のレコードをクエリする起点を決定します。
クエリ解決の例
Trusted Cloud は、名前解決の順序で説明されているように Cloud DNS ゾーンを解決します。特定のレコードのクエリ送信先ゾーンを決定するとき、Cloud DNS はリクエストされたレコードとできるだけ多く一致するゾーンを探そうとします（最長サフィックス マッチング）。
送信サーバー ポリシーで代替ネームサーバーを指定していない限り、レコードの検索はまず VPC ネットワークで行われます。
クロス プロジェクト バインディング
クラス プロジェクト バインディングを使用すると、VPC ネットワーク全体の DNS 名前空間の所有権とは無関係に、サービス プロジェクトの DNS 名前空間の所有権を保持できます。
一般的な共有 VPC 設定では、サービス プロジェクトが仮想マシン（VM）アプリケーションまたはサービスの所有権を持っていますが、VPC ネットワークとネットワーク インフラストラクチャの所有権はホスト プロジェクトが所有します。多くの場合、VPC ネットワークの名前空間から DNS 名前空間が作成され、サービス プロジェクトのリソースと一致します。このような設定では、各サービス プロジェクトの DNS 名前空間の管理を各サービス プロジェクトの管理者（多くは別の部門または事業）に委任するほうが便利です。プロジェクト間のバインディングを使用すると、VPC ネットワーク全体の DNS 名前空間の所有権から、サービス プロジェクトの DNS 名前空間の所有権を分離できます。
次の図は、DNS ピアリングを使用した一般的な共有 VPC 設定を示しています。
次の図は、プロジェクト間のバインディングを使用した設定を示しています。Cloud DNS では、各サービス プロジェクトが独自の DNS ゾーンを作成して所有できますが、それはホスト プロジェクトが所有する共有ネットワークにバインドされています。これにより、DNS ゾーン管理者の自律性が高まり、権限の境界がより明確になります。
プロジェクト間のバインディングには次の機能があります。
- サービス プロジェクトの管理者とユーザーが独自の DNS ゾーンを作成して管理できます。
- プレースホルダ VPC ネットワークを作成する必要はありません。
- ホスト プロジェクトの管理者は、サービス プロジェクトを管理する必要がありません。
- IAM ロールは引き続きプロジェクト レベルで適用されます。
- すべての DNS ゾーンは共有 VPC ネットワークに直接関連付けられます。
- 多対多の DNS 解決がすぐに利用できます。共有 VPC ネットワークのどの VM も関連するゾーンを解決できます。
- 推移的なホップ上限はありません。ハブ アンド スポーク設計で管理できます。
クロス プロジェクト バインディングを有効にしてゾーンを作成する方法については、プロジェクト間のバインディング ゾーンを作成するをご覧ください。
ゾーン Cloud DNS ゾーン
ゾーン Cloud DNS を使用すると、 Trusted Cloud ゾーンのみをスコープとするプライベート DNS ゾーンを作成できます。クラスタ スコープを選択すると、GKE 用のゾーン Cloud DNS ゾーンが作成されます。
デフォルトの Cloud DNS サービスは本来グローバルであり、DNS 名は VPC ネットワーク全体から見えます。この構成では、サービスがグローバルな停止にさらされます。ゾーン Cloud DNS は、各 Trusted Cloud ゾーンに存在する新しいプライベート Cloud DNS サービスです。障害発生ドメインはその Trusted Cloud ゾーンの内部に含まれます。グローバルな停止が発生しても、ゾーン Cloud DNS のプライベート ゾーンは影響を受けません。 Trusted Cloud ゾーンが停止したとしても、影響が及ぶ範囲は、その特定の Trusted Cloud ゾーンと、その Trusted Cloud ゾーン内の Cloud DNS ゾーンのみです。ゾーンのサービス内で作成されたリソースは、その Trusted Cloudゾーンからのみ見えることに注意してください。
ゾーン Cloud DNS クラスタ スコープ ゾーンを構成する方法については、ゾーン GKE クラスタ スコープ ゾーンを構成するをご覧ください。
ゾーン Cloud DNS のサポート
次の表に、ゾーン Cloud DNS サービスでサポートされている Cloud DNS のリソースと機能を示します。
| リソースまたは機能 | グローバル Cloud DNS で利用可能か | ゾーン Cloud DNS で利用可能か |
|---|---|---|
| マネージド プライベート ゾーン（ネットワークまたは VPC スコープ） | ||
| マネージド プライベート ゾーン（GKE スコープ） | ||
| 転送ゾーン1 | ||
| ピアリング ゾーン | ||
| マネージド逆引き参照ゾーン | ||
| 変更の作成、またはレコードの管理2 | ||
| Service Directory ゾーン | ||
| ポリシー | ||
| レスポンス ポリシー（ネットワーク スコープ） | ||
| レスポンス ポリシー（GKE クラスタ スコープ） | ||
| レスポンス ポリシー ルール |
1 ゾーン Cloud DNS では、GKE クラスタをスコープとする転送ゾーンのみがサポートされます。
2 GKE コントローラは再起動時にレコードへの変更を上書きします。
ゾーン Cloud DNS ゾーンの料金
ゾーン Cloud DNS ゾーンとレスポンス ポリシーの料金は、対応するグローバル版の場合と同じです。
次のステップ
- マネージド ゾーンを操作するには、ゾーンの作成、変更、削除をご覧ください。
- Cloud DNS の使用時に発生する可能性のある一般的な問題の解決策については、トラブルシューティングをご覧ください。
- Cloud DNS の概要については、Cloud DNS の概要をご覧ください。