このドキュメントでは、限定公開ゾーン、DNS 転送、ハイブリッド DNS のリファレンス アーキテクチャのベスト プラクティスについて説明します。
アプリケーションやサービスのアドレス指定にドメイン ネーム システム（DNS）を使用すると、人間にもアプリケーションにとっても便利です。ドメイン名のほうが IP アドレスよりも覚えやすく柔軟に利用できるからです。オンプレミスと 1 つ以上のクラウド プラットフォームで構成されるハイブリッド環境では、環境間で内部リソースの DNS レコードへの参照が必要になることが少なくありません。従来の方法では、オンプレミスの DNS レコードは権威 DNS サーバー（UNIX / Linux 環境の BIND や Microsoft Windows 環境の Active Directory など）を使用して手動で管理されます。
この記事では、限定公開の DNS リクエストを環境間で転送し、オンプレミス環境と Google Cloud 内の両方からサービスを参照できるようにするためのベスト プラクティスについて説明します。
一般原則
Google Cloud での DNS のコンセプト
Google Cloud で DNS を使用する場合、Google Cloud で DNS の名前解決とドメイン名の処理に利用できるさまざまなシステムとサービスについて理解しておく必要があります。
- 内部 DNS は、Compute Engine の仮想マシンと内部ロードバランサ用に DNS 名を自動的に作成するサービスです。
- Cloud DNS は、低レイテンシで高可用性の DNS ゾーンサービスを提供するサービスです。インターネットに公開されている一般公開ゾーンや、ネットワーク内にのみ公開される限定公開ゾーンの権威 DNS サーバーとして機能します。
- Managed Service for Microsoft Active Directory は、Microsoft Active Directory（ドメイン コントローラを含む）用に強化された高可用性サービスです。
- パブリック DNS は Google Cloud に含まれない Google サービスで、オープンな再帰 DNS リゾルバとして機能します。
- Cloud Domains は、Google Cloud 内でドメインの購入、移管、管理を行うドメイン登録事業者です。Cloud Domains では、API を介してドメイン登録システムを操作できます。
関係者、ツール、プロセスを特定する
ハイブリッド環境で DNS の戦略を検討する場合は、現在のアーキテクチャを理解し、すべての関係者と連絡をとることが重要です。次の手順を行います。
- 会社の DNS サーバーの管理者に連絡する。オンプレミス構成を Google Cloud の適切なアーキテクチャにマッピングするために必要な構成を管理者に確認する必要があります。Google Cloud DNS レコードへのアクセス方法の詳細については、条件付きの転送でオンプレミスから DNS レコードにアクセスするをご覧ください。
- 現在の DNS ソフトウェアをよく理解し、組織内で限定公開されているドメイン名を特定する。
- Cloud DNS サーバーへのトラフィックが正しくルーティングされていることを確認できるネットワーク チームの担当者を特定する。
- ハイブリッド接続戦略についてよく理解し、ハイブリッド クラウドとマルチクラウドのパターンとプラクティスについても理解しておく。
シンプルで一貫した命名規則を作成する
組織全体で一貫性があり、覚えやすい命名規則を作成します。たとえば、組織で example.com をセカンドレベル ドメインとしてパブリック リソースに使用しているとします（例: www.example.com）。対象範囲は限定公開ゾーンの移行であるため、このドキュメントの目的としては、一般公開ゾーンがどこにホストされていても構いません。
会社のオンプレミス リソースに名前を付ける場合、次のパターンが考えられます。
オンプレミス サーバーと Google Cloud で別々のドメイン名を使用する。このパターンでは、異なる環境で別のドメインを使用します。たとえば、オンプレミス サーバーに
corp.example.com、Google Cloud 上のすべてのリソースにgcp.example.comを使用します。他のパブリック クラウド環境を使用する場合は、それぞれに別のサブドメインを作成できます。環境間でリクエストを簡単に転送できるので、これがおすすめのパターンです。また、
example.comとexample.cloudのように別のドメイン名を使用することもできます。オンプレミス サーバーが含まれるドメインのサブドメインとして Google Cloud ドメインを使用する。
example.comドメインを作成し、オンプレミスにcorp.example.comを使用して Google Cloud にgcp.corp.example.comを使用します。このパターンは、ほとんどのリソースをオンプレミスに残す場合によく使用されます。Google Cloud レコードを含むドメインのサブドメインとしてオンプレミス ドメインを使用する。
example.comドメインを作成し、Google Cloud にcorp.example.comを使用してオンプレミスにdc.corp.example.comを使用します。これは、よく使われるパターンではありませんが、オンプレミスのフットプリントが小さいデジタル組織で使用されます。Google Cloud とオンプレミスで同じドメインを使用する。この場合、Google Cloud とオンプレミスの両方で
corp.example.comドメインを使用するリソースを使用します。ハイブリッド環境では、レコードの管理が難しくなるため、このパターンはおすすめしません。権威 DNS システムが 1 つだけの場合に限ります。
このページの残りの部分では、次のドメイン名を使用します。
example.com。ホストされている場所に関係なく、一般公開レコードのドメイン名に使用します。corp.example.com。オンプレミスの DNS サーバーにホストされているゾーンに使用します。このゾーンには、オンプレミス リソースのレコードがホストされます。gcp.example.com。Google Cloud リソースのレコードをホストする Cloud DNS 限定公開マネージド ゾーンに使用します。
図 1 は、オンプレミス ネットワークと Google Cloud の両方で一貫したドメイン名の設定を示しています。
Virtual Private Cloud（VPC）ネットワーク内のリソースに名前を付ける場合は、VPC 設計のためのベスト プラクティスとリファレンス アーキテクチャなどのソリューション ガイドに記載されているガイドラインに従います。
DNS 解決を実行する場所を選択する
ハイブリッド環境では、DNS 解決はさまざまな場所で実行できます。以下の操作を行います。
- 2 つの権威 DNS システムが存在するハイブリッド アプローチを使用する。
- DNS 解決をオンプレミスに残す。
- すべての DNS 解決を Cloud DNS に移行する。
おすすめはハイブリッド アプローチです。このドキュメントでは、このアプローチについて詳しく説明し、他の方法については簡単に触れることにします。
2 つの権威 DNS システムが存在するハイブリッド アプローチを使用する
2 つの権威 DNS システムを使用するハイブリッド アプローチをおすすめします。このアプローチでは、次のように名前解決が行われます。
- 限定公開の Google Cloud 環境に対する権威 DNS の解決は Cloud DNS によって行われます。
- オンプレミス リソースの権威 DNS 解決は、オンプレミスに存在する DNS サーバーで行われます。
この配置を図 2 に示します。
おすすめのユースケースは図 2 のシナリオです。詳細については、このページの後半で説明します。
- 限定公開ゾーンを使用する環境間に転送を設定し、DNS 転送を行う方法。
- ファイアウォールとルーティングを構成する方法。
- 1 つ以上の VPC ネットワークの使用方法を示すリファレンス アーキテクチャ。
DNS 解決をオンプレミスに残す
別のアプローチとして、オンプレミスの権威 DNS サーバーを引き続き使用し、すべての内部ドメイン名を格納することもできます。その場合、代替ネームサーバーを使用して、送信 DNS 転送により Google Cloud からのすべてのリクエストを転送できます。
このアプローチには次のような利点があります。
- ビジネス プロセスの変更が少なくなる。
- 既存のツールを引き続き使用できる。
- 拒否リストを使用して、オンプレミスで個々の DNS リクエストをフィルタできる。
ただし、次のような欠点もあります。
- Google Cloud からの DNS リクエストでレイテンシが長くなる。
- DNS の処理でシステムがオンプレミス環境に接続する必要がある。
- 自動スケーリングされたインスタンス グループなど、柔軟性の高い環境との連携が難しくなることがある。
- システムが Dataproc などのプロダクトと互換性がない可能性がある。これらのプロダクトは、Google Cloud インスタンス名の逆引きに依存しています。
すべての DNS 解決を Cloud DNS に移行する
また、すべてのドメインの解決を行う権威サービスとして Cloud DNS に移行することもできます。その後、限定公開ゾーンと受信 DNS 転送を使用して、オンプレミスの名前解決を Cloud DNS に移行できます。
このアプローチには次のような利点があります。
- オンプレミスに高可用性の DNS サービスを維持する必要はない。
- Cloud DNS を使用してロギングとモニタリングを一元管理できる。
ただし、次のような欠点もあります。
- オンプレミスからの DNS リクエストでレイテンシが長くなる。
- 名前解決には、VPC ネットワークとの安定した接続が必要になる。
Cloud DNS 限定公開ゾーンのベスト プラクティス
限定公開ゾーンには、組織内で公開される DNS レコードがホストされます。このドキュメントでは Cloud DNS の一般公開ゾーンについて説明しません。一般公開ゾーンは、一般公開サイトの DNS レコードなど、組織の公開レコードがホストされます。これらは、ハイブリッド環境の設定に関係ありません。
自動化を使用して共有 VPC ホスト プロジェクトの限定公開ゾーンを管理する
組織内で共有 VPC ネットワークを使用するには、ホスト プロジェクト内に Cloud DNS のすべての限定公開ゾーンを格納する必要があります。すべてのサービス プロジェクトが、共有 VPC ネットワークに接続している限定公開ゾーンのレコードに自動的にアクセスできます。また、クロス プロジェクト バインディングを使用して、サービス プロジェクト内にゾーンを設定することもできます。
図 3 は、共有 VPC ネットワークで限定公開ゾーンがどのようにホストされているかを示しています。
チームで独自の DNS レコードを設定する場合は、DNS レコードの作成を自動化することをおすすめします。たとえば、ユーザーが特定のサブドメインの下に独自の DNS レコードを作成できるようにウェブ アプリケーションや内部 API を作成します。また、レコードが組織のルールに従っているかどうかアプリで検証を行います。
Cloud Source Repositories などのコード リポジトリに Terraform または Cloud Deployment Manager 記述子の形式で記述された DNS 構成を置いて、チームからの pull リクエストを受け入れることもできます。
どちらの場合も、ホスト プロジェクトで IAM ロールが DNS 管理者であるサービス アカウントは、変更が承認されたら自動的にその変更をデプロイできます。
最小権限の原則に従って IAM ロールを設定する
最小権限のセキュリティ原則を使って、DNS レコードの変更権限はそれを必要とする組織にのみ付与します。基本ロールは使用しないでください。このロールを使用すると、ユーザーに不要なリソースへのアクセス権が付与される可能性があります。Cloud DNS では、DNS に固有の読み取り / 書き込み操作の権限を付与できるロールと権限が用意されています。
限定公開 DNS ゾーンを作成する権限と一般公開ゾーンを作成する権限を分離する必要がある場合は、dns.networks.bindPrivateDNSZone 権限を使用します。
DNS 転送ゾーンとサーバー ポリシーのベスト プラクティス
Cloud DNS では、DNS 転送ゾーンと DNS サーバー ポリシーを使用して、オンプレミスと Google Cloud 環境間での DNS 名の参照を可能にします。DNS 転送の構成には複数のオプションがあります。次のセクションでは、ハイブリッド DNS の設定に関するベスト プラクティスを説明します。このベスト プラクティスについては、ハイブリッド DNS のリファレンス アーキテクチャでも説明されています。
転送ゾーンを使用してオンプレミス サーバーにクエリを送信する
オンプレミス環境で DNS レコードの問い合わせができるようにするには、オンプレミスで会社のリソースに使用しているドメイン（corp.example.com など）に転送ゾーンを設定します。corp.example.comこれは、代替ネームサーバーを有効にする DNS ポリシーの作成よりもおすすめの方法です。これにより、オンプレミスのネームサーバーを経由してホップ数を増やすことなく、Compute Engine 内部 DNS 名とパブリック IP アドレスにアクセスできます。
この設定を使用するトラフィック フローについては、ハイブリッド DNS のリファレンス アーキテクチャをご覧ください。
代替ネームサーバーは、すべての DNS トラフィックをオンプレミスでモニタリングまたはフィルタリングする必要があり、限定公開 DNS ロギングの要件を満たすことができない場合にのみ使用します。
DNS サーバー ポリシーでオンプレミスからのクエリを許可する
Cloud DNS 限定公開ゾーン（gcp.example.comgcp.example.com など）にホストされている DNS レコードをオンプレミス ホストからクエリできるようにするには、受信 DNS 転送を使用して DNS サーバー ポリシーを作成します。受信 DNS 転送により、プロジェクト内のすべての限定公開ゾーンだけでなく、内部 DNS IP アドレスやピアゾーンもクエリで取得できます。
この設定を使用するトラフィック フローについては、ハイブリッド DNS のリファレンス アーキテクチャをご覧ください。
Google Cloud とオンプレミスのファイアウォールで DNS トラフィックを許可する
次の操作を行い、VPC ネットワークまたはオンプレミス環境内の DNS トラフィックがフィルタリングされていないことを確認します。
オンプレミス ファイアウォールが Cloud DNS からクエリを渡すことを確認します。Cloud DNS は、IP アドレス範囲（
35.199.192.0/19）からのクエリを返します。リクエストまたはレスポンスのサイズに応じて、DNS は UDP ポート 53 または TCP ポート 53 を使用します。DNS サーバーがクエリをブロックしないようにしてください。オンプレミスの DNS サーバーが特定の IP アドレスからのリクエストのみを許可する場合は、IP アドレス範囲
35.199.192.0/19を含める必要があります。オンプレミスから転送 IP アドレスにトラフィックが送信されるようにします。Cloud Router インスタンスで、VPC ネットワーク内の IP アドレス範囲
35.199.192.0/19のカスタム アドバタイズ ルートをオンプレミス環境に追加します。
条件付きの転送でオンプレミスから DNS レコードにアクセスする
Cloud DNS で、オンプレミスにある会社の DNS サーバーにホストされている限定公開レコードにアクセスするには、転送ゾーンを使用する必要があります。ただし、使用している DNS サーバー ソフトウェアによっては、別の方法でオンプレミスから Google Cloud の DNS レコードにアクセスできる場合があります。いずれの場合も、レコードへのアクセスは受信 DNS 転送を使用して行われます。
条件付き転送。条件付き転送では、会社の DNS サーバーが特定のゾーンまたはサブドメインに対するリクエストを Google Cloud の転送 IP アドレスに転送します。このアプローチは最も簡単で、会社の DNS サーバーですべての DNS リクエストを集中管理できるので、この方法を使用することをおすすめします。
委任。Google Cloud の限定公開ゾーンがオンプレミスで使用するゾーンのサブドメインの場合、ゾーン内に NS エントリを設定して、このサブドメインを Google Cloud のネームサーバーに委任することもできます。この設定を使用すると、クライアントは Google Cloud の転送 IP アドレスに直接アクセスできるので、これらのリクエストがファイアウォールを通過するように設定します。
ゾーン転送。Cloud DNS はゾーン転送をサポートしていません。このため、ゾーン転送を使用して、DNS レコードをオンプレミス DNS サーバーと同期することはできません。
DNS ピアリングで複数の VPC ネットワークからの送信転送を回避する
戻りのトラフィックで問題が発生するため、複数の VPC ネットワークからオンプレミス DNS サーバーに送信転送を行わないでください。Google Cloud は、クエリの送信元である VPC ネットワークにルーティングされる DNS サーバーからのレスポンスのみを受け入れます。ただし、任意の VPC ネットワークからのクエリでは、同じ IP アドレス範囲 35.199.192.0/19 がソースとして使用されます。このため、オンプレミスの環境が分離されていないと、レスポンスが正しくルーティングされません。
アウトバウンド転送でオンプレミスのネームサーバーにクエリを送信する VPC ネットワークを 1 つだけ指定することをおすすめします。指定した VPC ネットワークをターゲットに設定し、DNS ピアリング ゾーンを使用することで、追加の VPC ネットワークはオンプレミスのネームサーバーにクエリを送信できます。これらのクエリは、指定した VPC ネットワークの名前解決順序に従ってオンプレミスのネームサーバーに転送されます。この設定については、ハイブリッド DNS のリファレンス アーキテクチャをご覧ください。
DNS ピアリングと VPC ネットワーク ピアリングの違い
VPC ネットワーク ピアリングと DNS ピアリングは同じではありません。VPC ネットワーク ピアリングを使用すると、複数のプロジェクトの仮想マシン（VM）インスタンスが相互に接続可能になりますが、名前解決は変更されません。各 VPC ネットワークのリソースは、引き続き独自の解決順序に従います。
一方、DNS ピアリングでは、特定のゾーンに対するリクエストを別の VPC ネットワークに転送できます。VPC ネットワークが相互に接続されているかどうかにかかわらず、別の Google Cloud 環境にリクエストを転送できます。
また、VPC ネットワーク ピアリングと DNS ピアリングとでは設定方法も異なります。VPC ネットワーク ピアリングでは、両方の VPC ネットワークで相手の VPC ネットワークとのピアリング関係を設定する必要があります。これにより、ピアリングは自動的に双方向になります。
DNS ピアリングでは DNS リクエストは一方向に転送されます。VPC ネットワーク間で双方向の関係を定義する必要はありません。DNS コンシューマ ネットワークとして参照される VPC ネットワークが、別の VPC ネットワークの Cloud DNS ピアリング ゾーンを検索します。後者の VPC ネットワークは、DNS プロデューサー ネットワークといいます。プロデューサー ネットワークのプロジェクトに IAM 権限 dns.networks.targetWithPeeringZone を持つユーザーは、コンシューマ ネットワークとプロデューサー ネットワーク間で DNS ピアリングを確立できます。コンシューマ VPC ネットワークから DNS ピアリングを設定するには、プロデューサー VPC ネットワークのホスト プロジェクトに対する DNS ピアのロールが必要です。
自動生成された名前を使用する場合は内部ゾーンに DNS ピアリングを使用する
VM に内部 DNS サービスが自動的に生成する名前を使用する場合、DNS ピアリングを使用して projectname.internal ゾーンを他のプロジェクトに転送できます。図 5 のように、ハブ プロジェクト内のすべての .internal ゾーンをグループ化して、オンプレミス ネットワークからアクセスできるようにします。
.internal ゾーンをハブにまとめるために使用されます。問題が発生した場合は、トラブルシューティング ガイドをご覧ください。
Cloud DNS トラブルシューティング ガイドには、Cloud DNS を設定する際に発生する一般的なエラーの解決方法が記載されています。
ハイブリッド DNS のリファレンス アーキテクチャ
このセクションでは、ハイブリッド環境で Cloud DNS 限定公開ゾーンを使用する一般的なシナリオのリファレンス アーキテクチャについて説明します。いずれの場合も、オンプレミス リソースと Google Cloud リソースの両方のレコードとゾーンが環境内で管理されます。すべてのレコードが、オンプレミス ホストと Google Cloud ホストの両方からのクエリで使用できます。
VPC ネットワークの設計に対応するリファレンス アーキテクチャを使用します。
単一の共有 VPC ネットワークを使用するハイブリッド アーキテクチャ: オンプレミス環境との接続に単一の VPC ネットワークを使用します。
複数の VPC ネットワークを使用するハイブリッド アーキテクチャ: 異なる VPN トンネルまたは VLAN アタッチメントを介して複数の VPC ネットワークをオンプレミス環境に接続します。オンプレミスでは同じ DNS インフラストラクチャを共有します。
スポーク VPC ネットワークに接続されたハブ VPC ネットワークを使用するハイブリッド アーキテクチャ: VPC ネットワーク ピアリングを使用して、複数の独立したスポーク VPC ネットワークにハブ VPC ネットワークを接続します。
いずれの場合も、オンプレミス環境は 1 つ以上の Cloud VPN トンネル、Dedicated Interconnect、または Partner Interconnect 接続を介して Google Cloud VPC ネットワークに接続します。各 VPC ネットワークに使用する接続方式には関係ありません。
単一の共有 VPC ネットワークを使用するハイブリッド アーキテクチャ
最も一般的なユースケースは、図 6 に示すように、オンプレミス環境に接続されている単一の共有 VPC ネットワークです。
このアーキテクチャを設定するには:
- オンプレミス DNS サーバーを
corp.example.comの権威として設定します。 - 共有 VPC ネットワークのホスト プロジェクトの Cloud DNS で権威限定公開ゾーン（例:
gcp.example.com）を構成し、そのゾーンのリソースのすべてのレコードを設定します。 - 共有 VPC ネットワークのホスト プロジェクトに DNS サーバー ポリシーを設定し、受信 DNS 転送を許可します。
corp.example.comをオンプレミス DNS サーバーに転送する DNS 転送ゾーンを設定します。共有 VPC ネットワークには、転送ゾーンにクエリを送信する権限が必要です。- オンプレミス DNS サーバーに
gcp.example.comへの転送を設定し、共有 VPC ネットワークの受信フォワーダ IP アドレスを指定します。 - オンプレミス ファイアウォールで DNS トラフィックを許可します。
- Cloud Router インスタンスで、範囲
35.199.192.0/19のカスタム アドバタイズ ルートをオンプレミス環境に追加します。
複数の VPC ネットワークを使用するハイブリッド アーキテクチャ
複数の VPC ネットワークを使用するハイブリッド アーキテクチャを構成することもできます。Google Cloud 環境で、これらの VPC ネットワークは VPC ネットワーク ピアリングで相互に接続されていません。すべての VPC ネットワークは、個別の Cloud VPN トンネルまたは VLAN アタッチメントを使用してオンプレミス環境に接続します。
図 7 に示すように、このアーキテクチャは、相互に通信を行わない本番環境と開発環境が別々に存在し、これらの環境が DNS サーバーを共有する場合によく使用されます。
このアーキテクチャを設定するには:
- オンプレミス DNS サーバーを
corp.example.comの権威として設定します。 - 本番環境の共有 VPC ネットワークのホスト プロジェクトにある Cloud DNS で限定公開ゾーン（例:
prod.gcp.example.com）を構成し、そのゾーンのリソースのすべてのレコードを設定します。 - 開発環境の共有 VPC ネットワークのホスト プロジェクトにある Cloud DNS で限定公開ゾーン（例:
dev.gcp.example.com）を構成し、そのゾーンのリソースのすべてのレコードを設定します。 - 本番環境の共有 VPC ネットワークのホスト プロジェクトに DNS サーバー ポリシーを設定し、受信 DNS 転送を許可します。
- 本番環境の共有 VPC ネットワークで、
corp.example.comをオンプレミス DNS サーバーに転送する DNS ゾーンを設定します。 prod.gcp.example.comに対して、開発環境の共有 VPC ネットワークから本番環境の共有 VPC ネットワークへの DNS ピアリング ゾーンを設定します。dev.gcp.example.comに対して、本番環境の共有 VPC ネットワークから開発環境の共有 VPC ネットワークに DNS ピアリング ゾーンを設定します。- オンプレミス ネームサーバーの Cloud DNS 受信転送仮想 IP アドレスに
gcp.example.com.の解決を委任して、受信転送を設定します。 - オンプレミスと Google Cloud の両方のファイアウォールで DNS トラフィックを許可するように設定します。
- Cloud Router インスタンスで、本番環境の共有 VPC ネットワークの IP アドレス範囲
35.199.192.0/19のカスタム アドバタイズ ルートをオンプレミス環境に追加します。
スポーク VPC ネットワークに接続されたハブ VPC ネットワークを使用するハイブリッド アーキテクチャ
この他にも、Cloud Interconnect または Cloud VPN を使用して、オンプレミス インフラストラクチャをハブ VPC ネットワークに接続する方法があります。図 8 のように、VPC ネットワーク ピアリングを使用して、複数のスポーク VPC ネットワークと VPC ネットワークをピアリングできます。各スポーク VPC ネットワークは、Cloud DNS に独自の限定公開ゾーンをホストします。VPC ネットワーク ピアリングのカスタムルートと、Cloud Router のカスタムルート アドバタイズにより、完全なルート交換が可能になり、オンプレミスとすべてのスポーク VPC ネットワークが接続されます。DNS ピアリングは、VPC ネットワーク ピアリング接続と並行して実行され、環境間での名前解決が可能になります。
次の図は、このアーキテクチャを示しています。
このアーキテクチャを設定するには:
- オンプレミス DNS サーバーを
corp.example.comの権威として設定します。 - 各スポーク VPC ネットワークの Cloud DNS に限定公開ゾーン（例:
projectX.gcp.example.com）を構成し、そのゾーンのリソースのすべてのレコードを設定します。 - 本番環境の共有 VPC ネットワークのハブ プロジェクトに DNS サーバー ポリシーを設定し、受信 DNS 転送を許可します。
- ハブ VPC ネットワークで、
corp.example.comに限定公開 DNS ゾーンを作成し、オンプレミスの DNS サーバーに送信転送を構成します。 projectX.gcp.example.comに対して、ハブ VPC ネットワークからスポーク VPC ネットワークへの DNS ピアリング ゾーンを設定します。example.comに対して、スポーク VPC ネットワークからハブ VPC ネットワークへの DNS ピアリング ゾーンを設定します。- オンプレミスの DNS サーバーで
gcp.example.comへの転送を設定し、ハブ VPC ネットワークの受信フォワーダ IP アドレスを指定します。 - オンプレミスと Google Cloud の両方のファイアウォールで DNS トラフィックを許可するように設定します。
- Cloud Router インスタンスで、ハブ VPC ネットワークの IP アドレス範囲
35.199.192.0/19のカスタム アドバタイズ ルートをオンプレミス環境に追加します。 - （省略可）自動的に生成された内部 DNS 名を使用する場合は、各スポーク プロジェクト ゾーン（例:
spoke-project-x.internal）とハブ プロジェクトをピアリングし、オンプレミスからの.internalのすべてのクエリを転送します。
Cloud DNS を使用したマルチプロバイダのパブリック DNS
アプリケーション ネットワーキングの基本コンポーネントとして、ユーザーがアプリケーションやサービスを確実に利用できるようにするには、信頼性の高い DNS が重要です。複数の DNS プロバイダを構成することで、アプリケーションとサービスの可用性と復元性を向上させることができます。複数の DNS プロバイダが構成されている場合、いずれかの DNS プロバイダで停止が発生しても、ユーザーはアプリケーションやサービスを利用できます。また、マルチプロバイダの DNS 構成を使用すると、オンプレミス環境とクラウド環境の間で依存関係があるハイブリッド アプリケーションのデプロイと移行を簡素化できます。
Google Cloud には、複数の DNS プロバイダを使用する環境の設定と運用に役立つ、octoDNS に基づくオープンソース ソリューションが用意されています。マルチプロバイダ DNS ソリューションでは、アクティブ / アクティブ（推奨）またはアクティブ / パッシブ構成の DNS プロバイダの一つとして Cloud DNS を活用し、高可用性の DNS アーキテクチャを確保します。ソリューションをデプロイすると、octoDNS は、現在の DNS ゾーンと Cloud DNS でホストされているマネージド DNS ゾーンの間で 1 回限りの同期と継続的な同期を実行します。個々の DNS レコードが更新されると、CI / CD パイプラインを変更しなくても、Cloud DNS でホストされている対応する DNS ゾーンに変更が伝播されます。
- マルチプロバイダのパブリック DNS 構成で Cloud DNS を構成するには、multi-provider-dns-with-clouddns をご覧ください。
次のステップ
- Cloud DNS の使用時に発生する可能性のある一般的な問題の解決策については、トラブルシューティングをご覧ください。
- Google Cloud を使用するハイブリッド環境を構成し、実装する方法については、ソリューション ガイドのハイブリッドおよびマルチクラウドのパターンとプラクティスをご覧ください。
- リファレンス アーキテクチャ、図、ベスト プラクティスの詳細については、Cloud アーキテクチャ センターをご覧ください。