Cloud DNS の転送、ピアリング、限定公開ゾーンについて

※この投稿は米国時間 2020 年  5 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

ドメイン ネーム システム（DNS）は、インターネットの最も基礎的なサービスの 1 つであり、人間が理解しやすいドメイン名を IP アドレスに変換します。多くの場合、組織内の専門のネットワーク エンジニアによって設定されるため、これに携わらなければ DNS は構造がわからない謎めいたものに思えるかもしれません。たとえば、DNS 用語には混乱を招くものがあり、一部の用語はクラウド ネットワークの別の部分では異なる意味を持っていることがあります（例: ピアリング）。しかし、DNS の仕組みについて理解することは重要です。とりわけ、企業ユーザーがアプリケーションを使用できるようにするために DNS が必要なクラウド環境にとっては不可欠といえるでしょう。

アプリケーションを Google Cloud で実行している場合、Cloud DNS を使用している可能性があります。Cloud DNS はスケーラブルで信頼性の高いマネージド権威 DNS サービスであり、Google と同じインフラストラクチャ上で動作します。低レイテンシかつ可用性が高くスケーラブルな、コスト効率に優れた方法でアプリケーションやサービスをユーザーに提供できます。

お客様が苦戦を強いられる複雑度の高い DNS 設定の 1 つに、複数のプロジェクトと VPC の構築が挙げられます。これらはすべて、オンプレミスの DNS リソースへの接続が確立されていなくてはなりません。オンプレミス ネットワークまたは別のクラウドへの外部接続がない限り、VPC は論理的に「アイランド」（自己完結型）のネットワークのようになります。このような理由から、各 VPC が独自の転送ゾーンを使用し、解決のために DNS クエリを個別にオンプレミスに転送するという論理的な仮説を立てるとします。

ただしこの場合、VPC をそれぞれ分離することで困難な課題が発生し、VPC の数が増えるほどその対応は難しくなっていきます。では、これがなぜ難しいのかを明らかにし、解決する方法について説明します。

複数の VPC で DNS 転送リクエストを処理する場合の問題点

これが難しい理由は、基本的にルーティングにあります。Google では、送信転送ゾーンからオンプレミス環境へのすべての送信 DNS リクエストに、下り（外向き）プロキシを活用します。この可用性の高いスケーラブルなプロキシのプールは、同じ IP アドレスのブロックを使用し、すべての VPC に対してこれを使用します。DNS リクエストを同じオンプレミス ネットワークに転送する複数の VPC がある場合、送信元の VPC にレスポンスを返すためのルートを作成することはできません（それらはすべて、プロキシに同じ IP ブロックを使用しているため）。プロキシのプールを使用する VPC が多いほど、間違った VPC にデータを送り返す可能性が高くなります。

下図では、2 つの VPC、A と B は両方とも送信転送ゾーンをオンプレミスに設定していて、Cloud Router A と B は両方とも 35.199.192.0/19 の DNS プロキシ範囲をアドバタイジングしています。オンプレミス ネットワークには、すべてのトラフィックが 35.199.192.0/19 から送信されているように見え、オンプレミスでレスポンスが生成されると、戻りトラフィックが間違った VPC ネットワークに到達する可能性があります。このシナリオでは、オンプレミス ネットワークがリクエストの送信元の VPC を正しく推測できる可能性は 50% です。そして、より多くの VPC がこのモデルに導入されるにつれて、適切なソースに到達する可能性は急激に低下していきます。

複数の VPC に接続するための送信転送ゾーンと DNS ピアリング

複数の VPC をオンプレミス ネットワークに接続する課題に対処するには、ハブアンドスポーク型で DNS ピアリングと送信転送ゾーンを組み合わせて使用する必要があります。ハブ VPC は DNS 転送を活用してオンプレミス ネットワークへのハイブリッド接続を実行し、スポーク VPC は DNS ピアリングを使用してハブ VPC に接続します。

下図では、VPC H に単一の送信転送ゾーンが設定されています。その他のすべての VPC は VPC H にピアリングされています。オンプレミスから解決されるように設定されたクエリは、送信元 VPC（この例では、A、B、C のいずれか）から VPC H に送信されます。クエリが VPC H に入ると、これを送信転送ゾーンの一部として識別し、確立されたネットワーク接続を介してオンプレミスにリクエストを転送します。この場合、35.199.192.0/19 範囲は VPC H の Cloud Router からのみアドバタイジングされるため、クエリが Google Cloud にルーティングして返される場合、そのルートには単一の VPC ネットワーク パスしかありません。VPC H は適切な情報を送信元の VPC（A、B、C のいずれか）にカスケードし、すべてが期待どおりに機能します。

Cloud DNS の最新情報の入手

DNS の管理はユーザーにとっての日常業務ではないかもしれませんが、企業のクラウド環境を構成するうえで、DNS の仕組みを理解することが重要になる場合があります。この投稿では、ゾーン、ピアリング、転送の組み合わせを活用し、Google の DNS 構成をいくつか使用して複数のゾーンをオンプレミスの DNS インフラストラクチャに接続する方法を紹介しました。DNS サービスをはじめとした Google Cloud のネットワーキング ポートフォリオについて詳しくは、こちらをご覧ください。お問い合わせについては gcp-networking@google.com までお寄せください。

- By カスタマー エンジニア兼ネットワーキング スペシャリスト Ryan Przybyl、プロダクト マネージャー Karthik Balakrishnan