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 サーバーとして機能します。詳細については、Cloud DNS の概要をご覧ください。
  • Managed Service for Microsoft Active Directory は、Microsoft Active Directory(ドメイン コントローラを含む)用に強化された高可用性サービスです。
  • パブリック DNS は Google Cloud に含まれない Google サービスで、オープンな再帰 DNS リゾルバとして機能します。
  • Google Domains は、ドメインの購入、移管、管理ができるドメイン登録事業者です。これは、Google Cloud に含まれていない Google サービスです。

関係者、ツール、プロセスを特定する

ハイブリッド環境で DNS の戦略を検討する場合は、現在のアーキテクチャを理解し、すべての関係者と連絡をとることが重要です。次のことを行います。

  • 会社の DNS サーバーの管理者に連絡する。オンプレミス構成を Google Cloud の適切なアーキテクチャにマッピングするために必要な構成を管理者に確認する必要があります。条件付きの転送でオンプレミスから DNS レコードにアクセスするで、Google Cloud の DNS レコードにアクセスする方法を確認してください。
  • 現在の DNS ソフトウェアをよく理解し、組織内で限定公開されているドメイン名を特定する。
  • Cloud DNS サーバーへのトラフィックが正しくルーティングされていることを確認できるネットワーク チームの担当者を特定する。
  • ハイブリッド接続戦略についてよく理解し、ハイブリッド クラウドとマルチクラウドのパターンとプラクティスについても理解しておく。

シンプルで一貫した命名規則を作成する

組織全体で一貫性があり、覚えやすい命名規則を作成します。たとえば、組織で example.com をセカンドレベル ドメインとしてパブリック リソースに使用しているとします(例: www.example.com)。対象範囲は限定公開ゾーンの移行であるため、このドキュメントの目的としては、一般公開ゾーンがどこにホストされていても構いません。

会社のオンプレミス リソースに名前を付ける場合、次のパターンが考えられます。

  • オンプレミス サーバーと Google Cloud で別々のドメイン名を使用する。このパターンでは、異なる環境で別のドメインを使用します。たとえば、オンプレミス サーバーに corp.example.com、Google Cloud 上のすべてのリソースに gcp.example.com を使用します。他のパブリック クラウド環境を使用する場合は、それぞれに別のサブドメインを作成できます。環境間でリクエストを簡単に転送できるので、これがおすすめのパターンです。

    また、example.comexample.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 の限定公開マネージド ゾーンに使用します。

この関係を図にすると、次のようになります。

ドメイン名の設定例(クリックして拡大)
ドメイン名の設定例(クリックして拡大)

VPC ネットワーク内のリソースに名前を付ける場合は、VPC 設計のベスト プラクティスとリファレンス アーキテクチャのガイドラインなどを参照できます。

DNS 解決を実行する場所を選択する

ハイブリッド環境では、DNS 解決はさまざまな場所で実行できます。次のことが可能です。

  • 2 つの権威 DNS システムが存在するハイブリッド アプローチを使用する。
  • DNS 解決をオンプレミスに残す。
  • すべての DNS 解決を Cloud DNS に移行する。

おすすめはハイブリッド アプローチです。このドキュメントでは、このアプローチについて詳しく説明し、他の方法については簡単に触れることにします。

2 つの権威 DNS システムが存在するハイブリッド アプローチを使用する

2 つの権威 DNS システムを使用するハイブリッド アプローチをおすすめします。このアプローチでは、次のように名前解決が行われます。

  • 限定公開の Google Cloud 環境に対する権威 DNS の解決は Cloud DNS によって行われます。
  • オンプレミス リソースの権威 DNS 解決は、オンプレミスに存在する DNS サーバーで行われます。

この関係を図にすると、次のようになります。

2 つの権威 DNS システムが存在するハイブリッド アーキテクチャ(クリックして拡大)
2 つの権威 DNS システムが存在するハイブリッド アーキテクチャ(クリックして拡大)

これがおすすめのユースケースです。このドキュメントでは、このシナリオについて詳しく説明します。このドキュメントでは、次のことについて説明します。

  • 限定公開ゾーンを使用する環境間に転送を設定し、DNS 転送を行う方法。
  • ファイアウォールとルーティングを構成する方法。
  • 1 つ以上の VPC の使用方法を説明するリファレンス アーキテクチャ。

DNS 解決をオンプレミスに残す

別のアプローチとして、オンプレミスの権威 DNS サーバーを引き続き使用し、すべての内部ドメイン名を格納することもできます。この場合、代替ネームサーバーを使用し、送信 DNS 転送で Google Cloud からのリクエストをすべて転送できます。このアプローチには次のような利点があります。

  • ビジネス プロセスの変更が少なくなる。
  • 既存のツールを引き続き使用できる。
  • 拒否リストを使用して、個々の DNS リクエストをオンプレミスでフィルタリングできる。

ただし、次のような欠点もあります。

  • Google Cloud からの DNS リクエストでレイテンシが長くなる。
  • DNS の処理でシステムがオンプレミスに接続する必要がある。
  • 自動スケーリングされたインスタンス グループなど、柔軟性の高い環境との連携が難しくなることがある。
  • システムが Cloud 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 ネットワークに接続している限定公開ゾーンのレコードに自動的にアクセスできます。

次の図に、共有 VPC ネットワークで限定公開ゾーンがどのようにホストされるのかを示します。

共有 VPC ネットワークにホストされている限定公開ゾーン(クリックして拡大)
共有 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 転送は、相互接続かどうかにかかわらず、異なる Google Cloud 環境間で行うことはできません。その場合は、DNS ピアリングを使用します。

転送ゾーンを使用してオンプレミス サーバーにクエリを送信する

オンプレミス環境の DNS レコードを確実にクエリできるようにするには、オンプレミスで自社のリソースに使用するドメイン(corp.example.com など)のための転送ゾーンを設定します。これは、代替ネームサーバーを有効にする DNS ポリシーの作成よりもおすすめの方法です。これにより、オンプレミスのネームサーバーを経由してホップ数を増やすことなく、Compute Engine 内部 DNS 名とパブリック IP アドレスにアクセスできます。

この設定を使用するトラフィック フローについては、リファレンス アーキテクチャをご覧ください。

代替ネームサーバーを使用するのは、すべての DNS トラフィックをオンプレミスでモニタリングまたはフィルタリングするために必要な場合に限定してください。また、要件が限定公開 DNS ロギングの条件を満たしていない場合にも、同様の制限を行います。

DNS サーバー ポリシーでオンプレミスからのクエリを許可する

Cloud DNS 限定公開ゾーン(gcp.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 アドレスからのリクエストのみを許可する場合は、範囲 35.199.192.0/19 を含める必要があります。

  • オンプレミスから転送 IP アドレスにトラフィックが送信されるようにします。受信転送の場合は、オンプレミス DNS サーバーまたは他のクライアントから転送 IP アドレスへのトラフィックがオンプレミス ファイアウォールでブロックされないようにします。すべてのクライアントの UDP ポート 53 から転送 IP アドレスへのトラフィックを許可するには、オンプレミス ファイアウォールでファイアウォール ルールの作成が必要になる場合があります。

条件付きの転送でオンプレミスから 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 サーバーに送信転送を行わないでください。戻りのトラフィックで問題が発生します。DNS サーバーからのレスポンスは、クエリの送信元から VPC にルーティングされる場合にのみ、GCP に受け入れられます。ただし、任意の VPC からのクエリでは、同じ 35.199.192.0/19 IP 範囲がソースとして使用されます。このため、オンプレミスの環境が完全に分離されていないと、レスポンスが正しくルーティングされません。

次の図に、複数の VPC が送信転送を行う場合の問題を示します。

複数の VPC が送信転送を行う場合の問題(クリックして拡大)
複数の VPC が送信転送を行う場合の問題(クリックして拡大)

送信転送でオンプレミスのネームサーバーにクエリを送信する VPC を 1 つだけ指定することをおすすめします。指定した VPC をターゲットに設定し、DNS ピアリング ゾーンを使用することで、追加の VPC はオンプレミスのネームサーバーにクエリを送信できます。これらのクエリは、指定した VPC の名前解決順序に従ってオンプレミスのネームサーバーに転送されます。この設定の詳細については、リファレンス アーキテクチャのセクションをご覧ください。

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 ピアリングを使用します。

内部 DNS サービスによって VM に自動生成された名前を使用する場合、DNS ピアリングを使用して projectname.internal ゾーンを他のプロジェクトに転送できます。すべての .internal ゾーンをハブ プロジェクトに集約し、すべてをオンプレミスで使用できるように設定できます。

次の図に、この設定を示します。

メッシュ設定での DNS ピアリング(クリックして拡大)
メッシュ設定での DNS ピアリング(クリックして拡大)

問題が発生した場合は、トラブルシューティング ガイドをご覧ください。

Cloud DNS トラブルシューティング ガイドには、Cloud DNS を設定する際に発生する一般的なエラーの解決方法が記載されています。

ハイブリッド DNS のリファレンス アーキテクチャ

このセクションでは、ハイブリッド環境で Cloud DNS 限定公開ゾーンを使用する一般的なシナリオのリファレンス アーキテクチャについて説明します。いずれの場合も、オンプレミス リソースと Google Cloud リソースの両方のレコードとゾーンが環境内で管理されます。すべてのレコードが、オンプレミス ホストと Google Cloud ホストの両方からのクエリで使用できます。

VPC デザインに対応するリファレンス アーキテクチャを使用する必要があります。

  • 単一の共有 VPC を使用するハイブリッド アーキテクチャ - 1 つの VPC ネットワークをオンプレミスに接続します。

  • 複数の VPC を使用したハイブリッド アーキテクチャ - 別の VPN トンネルまたは VLAN アタッチメントを介して複数の VPC をオンプレミスに接続しますが、オンプレミスで同じ DNS インフラストラクチャを共有します。

  • スポーク VPC ネットワークに接続されたハブ VPC ネットワークを使用するハイブリッド アーキテクチャ - VPC ネットワーク ピアリングを使用して、複数の独立したスポーク VPC ネットワークにハブ VPC ネットワークを接続します。

いずれの場合も、オンプレミス環境は 1 つ以上の Cloud VPN トンネルまたは Cloud Interconnect(Dedicated または Partner 接続)を介して Google Cloud VPC に接続します。各 VPC ネットワークに使用する接続方式には関係ありません。

単一の共有 VPC ネットワークを使用するハイブリッド アーキテクチャ

最も一般的なケースは、単一の共有 VPC ネットワークをオンプレミス環境に接続するものです。次の図に、このシナリオを示します。

単一の共有 VPC ネットワークを使用するハイブリッド アーキテクチャ(クリックして拡大)
単一の共有 VPC ネットワークを使用するハイブリッド アーキテクチャ(クリックして拡大)

このアーキテクチャを設定するには:

  1. オンプレミスの DNS サーバーを corp.example.com の権威として設定します。
  2. 共有 VPC ネットワークのホスト プロジェクトの Cloud DNS で権威限定公開ゾーン(例: gcp.example.com)を構成し、そのゾーンのリソースのすべてのレコードを設定します。
  3. 共有 VPC ネットワークのホスト プロジェクトに DNS サーバー ポリシーを設定し、受信 DNS 転送を許可します。
  4. corp.example.com をオンプレミス DNS サーバーに転送する DNS 転送ゾーンを設定します。共有 VPC には、転送ゾーンにクエリを送信する権限が必要です。
  5. オンプレミス DNS サーバーに gcp.example.com への転送を設定し、共有 VPC ネットワークの受信フォワーダ IP アドレスを指定します。
  6. オンプレミス ファイアウォールで DNS トラフィックを許可します。
  7. Cloud Router インスタンスで、範囲 35.199.192.0/19 のカスタムルート アドバタイズをオンプレミスに追加します。

複数の VPC ネットワークを使用するハイブリッド アーキテクチャ

複数の VPC ネットワークを使用するハイブリッド アーキテクチャを構成することもできます。Google Cloud 環境で、これらの VPC ネットワークは VPC ネットワーク ピアリングで相互に接続されていません。すべての VPC ネットワークは、個々の Cloud VPN トンネルまたは VLAN アタッチメントを介してオンプレミス環境に接続します。通常、このアーキテクチャは、相互に通信を行わない個別の環境で DNS サーバーを共有する場合に使用します。典型的なユースケースとして、本番環境と開発環境を個別に用意している場合について説明します。

次の図に、このアーキテクチャを示します。

複数の VPC ネットワークを使用するハイブリッド アーキテクチャ(クリックして拡大)
複数の VPC ネットワークを使用するハイブリッド アーキテクチャ(クリックして拡大)

このアーキテクチャを設定するには:

  1. オンプレミス DNS サーバーを corp.example.com の権威として設定します。
  2. 本番環境の共有 VPC ネットワークのホスト プロジェクトにある Cloud DNS で限定公開ゾーン(例: prod.gcp.example.com)を構成し、そのゾーンのリソースのすべてのレコードを設定します。
  3. 開発環境の共有 VPC ネットワークのホスト プロジェクトにある Cloud DNS で限定公開ゾーン(例: dev.gcp.example.com)を構成し、そのゾーンのリソースのすべてのレコードを設定します。
  4. 本番環境の共有 VPC ネットワークのホスト プロジェクトに DNS サーバー ポリシーを設定し、受信 DNS 転送を許可します。
  5. 本番環境の共有 VPC ネットワークで、corp.example.com をオンプレミス DNS サーバーに転送する DNS ゾーンを設定します。
  6. example.com に対して、開発環境の共有 VPC ネットワークから本番環境の共有 VPC ネットワークへの DNS ピアリング ゾーンを設定します。
  7. dev.gcp.example.com に対して、本番環境の共有 VPC ネットワークから開発環境の共有 VPC ネットワークに DNS ピアリング ゾーンを設定します。
  8. オンプレミス DNS サーバーに gcp.example.com への転送を設定し、本番環境の共有 VPC ネットワークの受信フォワーダ IP を指定します。
  9. オンプレミスと Google Cloud の両方のファイアウォールで DNS トラフィックを許可するように設定します。
  10. Cloud Router インスタンスで、本番環境の VPC ネットワークにある範囲 35.199.192.0/19 のカスタムルート アドバタイズをオンプレミスに追加します。

スポーク VPC ネットワークに接続されたハブ VPC ネットワークを使用するハイブリッド アーキテクチャ

Cloud Interconnect または Cloud VPN を使用して、オンプレミス インフラストラクチャを 1 つのハブ VPC ネットワークに接続することもできます。この VPC ネットワークは、VPC ネットワーク ピアリングを使用して複数のスポーク VPC ネットワークにピアリングされます。各スポーク VPC ネットワークは、Cloud DNS に独自の限定公開ゾーンをホストします。VPC ネットワーク ピアリングのカスタムルートと、Cloud Router の カスタムルート アドバタイズにより、完全なルート交換が可能になり、オンプレミスとすべてのスポーク VPC ネットワークが接続されます。DNS ピアリングは、VPC ネットワーク ピアリング接続と並行して実行され、環境間での名前解決が可能になります。

次の図に、このアーキテクチャを示します。

スポーク VPC ネットワークに接続されたハブ VPC ネットワークを使用するハイブリッド アーキテクチャ(クリックして拡大)
スポーク VPC ネットワークに接続されたハブ VPC ネットワークを使用するハイブリッド アーキテクチャ(クリックして拡大)

このアーキテクチャを設定するには:

  1. オンプレミス DNS サーバーを corp.example.com の権威として設定します。
  2. 各スポーク VPC の Cloud DNS に限定公開ゾーン(例: projectX.gcp.example.com)を構成し、そのゾーンのリソースのすべてのレコードを設定します。
  3. 本番環境の共有 VPC ネットワークのハブ プロジェクトに DNS サーバー ポリシーを設定し、受信 DNS 転送を許可します。
  4. ハブ VPC で、corp.example.com に限定公開 DNS ゾーンを作成し、オンプレミスの DNS サーバーに送信転送を構成します。
  5. projectX.gcp.example.com に対して、ハブ VPC から各スポーク VPC への DNS ピアリング ゾーンを設定します。
  6. example.com に対して、各スポーク VPC からハブ VPC への DNS ピアリング ゾーンを設定します。
  7. オンプレミスの DNS サーバーで gcp.example.com への転送を設定し、ハブ VPC の受信フォワーダ IP アドレスを指定します。
  8. オンプレミスと Google Cloud の両方のファイアウォールで DNS トラフィックを許可するように設定します。
  9. Cloud Router インスタンスで、ハブ VPC にある範囲 35.199.192.0/19 のカスタムルート アドバタイズをオンプレミスに追加します。
  10. (省略可)自動的に生成された内部 DNS 名を使用する場合は、各スポーク プロジェクト ゾーン(例: spoke-project-x.internal)とハブ プロジェクトをピアリングし、オンプレミスからの .internal のすべてのクエリを転送します。

次のステップ