こんにちは、アーキテクトのやまぱんです。
今回は 下記の Azure Private Resolver ブログを和訳いたしました。
*原著者にも許可取っております。
原著者：MSドイツ所属のCSA Sven Baeck 氏
https://techcommunity.microsoft.com/t5/user/viewprofilepage/user-id/1876236#profile
このブログはマイクロソフトの Tech Community の記事なのですが、非常に有益です。
ただし英語なので、少しハードルがあるのではないかと思います。
今回、より皆さんに読んでいただきたいので和訳し、リンクは日本語版がある場合は日本語へのリンクに変更し、また私のほうで参考リンクも一部追記しました。
*和訳や英語のプロではないので、気になるところは是非原文を読んでいただければと思います。また、コメントに指摘もいただければ幸いです。
間違ってたら優しく教えてください！
またコメントや質問、いいね、拡散、も是非お願いします🥺！
はじめに
DNS は、IP ルーティングの次に重要なネットワークサービスの1つです。
最新のハイブリッド・クラウド・ネットワークには、Azureプライベート DNS ゾーン、パブリック DNS 、ドメインコントローラーなどのさまざまなソースが存在します。
また、組織によっては、パブリックインターネットの DNS クエリを特定の DNS プロバイダー経由でルーティングすることを好む場合もあります。
したがって、（ハイブリッド）ネットワーク全体で一貫した DNS 解決を確保することが極めて重要です。
この記事では、このようなアーキテクチャを構築するために Azure DNS Private Resolver を活用する方法について説明します。
この記事は、ネットワーク・トポロジーが従来のネットワーキングを使用して構築されたことを前提としています。Azure Virtual WAN を活用する場合は、Virtual WAN の段落で説明するいくつかの調整が必要です。
アーキテクチャ
下の図は、これから作成するトポロジーです。
数字はこの記事で説明するステップに対応しています。
本書では、単一のハブ＆スポークネットワーク・トポロジーを取り上げます。
多くの場合、Azure ネットワーク全体には、メッシュ状に接続された複数のハブ＆スポーク構成が含まれます。
ここで説明するソリューションは、このようなメッシュ化されたハブ＆スポーク構成をサポートするように簡単に拡張できます。
この記事で説明するソリューションは、VNet に配置された Azure DNS Private Resolver に基づいています。
この Azure サービスにより、複数の DNS ソースを Azure DNS でシームレスに組み合わせることができます。
しかし、ハイブリッド・ハブ＆スポーク構成では、考慮すべき要件と制限がいくつかあります。
これについては、この記事で詳しく説明します。
アーキテクチャの展開
ステップ1: DNS Private Resolver 導入のためのネットワーク構築
仮想ネットワーク (VNet) に DNS Private Resolver を展開するには、2 つのサブネットを専用にする必要があります。1つはインバウンドエンドポイント用、もう1つはアウトバウンドエンドポイント用です。両方のサブネットの最小サイズは/28 です。
ハブ＆スポーク構成では、 DNS Private Resolver は VNet に存在する必要があります。
したがって、以下のスクリーンショットに示すように、ハブに2 つの /28 サブネットを作成する必要があります（サブネットの名前は「pr-dns-inbound」および「pr-dns-outbound」です）。
ステップ2： DNS Private Resolver のデプロイ
ハブに DNS Private Resolver をデプロイするには ハブの VNet と同じサブスクリプションに存在する必要がありますが、リソースグループは異なるリソースグループに存在することが理想的です。
また、展開中または展開後に、インバウンドエンドポイントとアウトバウンドエンドポイントの両方を作成する必要があります。
- インバウンドエンドポイント
インバウンドエンドポイントは、先ほど作成したサブネット内にあり、静的 IP アドレスを持っている必要があります。
サブネットで利用可能な IP アドレスから任意の IP アドレスを選択できますが、 IP アドレスを最適に利用するために最初の IP アドレスを使用することをお勧めします。 - アウトバウンド・エンドポイント
アウトバウンド・エンドポイントに必要なのは、名前とアウトバウンド・サブネットへの関連付けだけです。
次のステップは、ハブ VNet を持つサブスクリプションに新しいリソースグループと DNS Private Resolver を作成することです。まず、サブスクリプションに新しいリソースグループを作成します。
次に、新しいリソースグループに DNS Private Resolver を作成し、インバウンドエンドポイント（静的 IP アドレス付き）とアウトバウンドエンドポイントを1つずつ追加します。
エンドポイントには、前のステップで作成した適切なサブネットを選択してください。
ステップ3：外部 DNS システム
複数の DNS ソースを DNS Private Resolver に統合する予定です。
そのため、接続性を確保する必要があります。 DNS Private Resolver のアウトバウンドインターフェースは、統合する必要があるすべての「外部」ソースにアクセスできる必要があります。
ドメインコントローラー（AD DS または Entra ID DS）
DNS Private Resolver のアウトバウンド・サブネットから、Azure のドメイン・コントローラ（IaaS またはEntra ID DS (Microsoft Entra Domain Services) として展開）への IP 接続が必要です。
これには IP ルーティングと NSG/ファイアウォール の両方が必要です。
ドメインコントローラーをホストする仮想ネットワーク (VNet) をハブにピアリングする ことが望ましい。まだ実施できていない場合はグッドセキュリティプラクティスに従い、ドメインコントローラーを含むサブネットには NSG を割り当てましょう。
NSG を利用して、DNS Private Resolver アウトバウンドエンドポイントのサブネット全体からポート53(TCPとUDP)、宛先はドメインコントローラーの IP アドレス を許可する ルール を作成します。
オンプレミス DNS サーバー - アウトバウンド
オンプレミス DNS サーバーでホストされている名前を解決するには、これらを統合する必要があります。最初のステップは、IP 接続を確保することです。
通常、サーバーは VPN や ExpressRoute のようなハイブリッド接続で接続され、ハブのゲートウェイ（Virtual Network Gateway またはNVA）で終端します。セキュリティ要件に応じて、オンプレミスの DNS サーバーとの間の DNS トラフィックは、ハブのファイアウォールを通過するか、それをバイパスします。このアーキテクチャでは、完全に機能するハイブリッドハブ＆スポーク構成を想定しているため、この接続性はすでに有効になっている前提です。
ただし、ファイアウォールルールやネットワークセキュリティグループルールを追加する必要があるかもしれません。
他の外部システム（VPN や ExpressRoute で接続された他のクラウドなど）でホストされている DNS サーバーも同様に考えます。
オンプレミス DNS サーバー - インバウンド
オンプレミスと Azure の両方で一貫した DNS 解決を行うには、オンプレミスの DNS サーバーは DNS Private Resolver Inbound Endpoint に接続する必要があります。前述したように、このトラフィックはニーズに応じて、ファイアウォールを通過することも、バイパスすることもできます。この IP 接続を有効にするには、インバウンドエンドポイントの IP アドレス（またはサブネットのCIDR範囲）をオンプレミス ネットワークへのハイブリッド接続を介して広報する必要があります。
インバウンドエンドポイント、つまりオンプレミスの DNS サーバーを経由して名前を解決できるようにするには、これらにもいくつかの設定が必要である。
DNS Private Resolver を介して統合されたすべてのドメインに対して、インバウンド・エンドポイントの IP アドレスをターゲットとして条件付きフォワーダーを設定する必要があります。
他の外部システム（VPN や ExpressRoute で接続された他のクラウドなど）でホストされている DNS サーバーも同様に考えます。
カスタム パブリック DNS サーバー
Azure はデフォルトでパブリック DNS エントリを解決するパブリック DNS インフラを提供します。
しかし、シナリオによっては、 DNS リクエストの追加検証を実行する専用のカスタム DNS インフラストラクチャが必要になる場合があります。これらのサーバーは通常、パブリックインターネット上でホストされています。このような要件がある場合、 DNS Private Resolver の送信エンドポイントはパブリック・インターネットにアクセスする必要があります。
この記事を書いている時点では、デフォルトのアウトバウンド仮想ネットワーク (VNet) アクセスはまだ利用可能です。しかし、これは廃止される予定で、安全なソリューションではありません。
したがって、このトラフィックをハブのファイアウォール経由でルーティングすることをお勧めします。これには、すべてのトラフィック（0.0.0.0/0）をファイアウォールの内部 IP アドレスに誘導するカスタムルートをアウトバウンド・サブネット・ルート・テーブルに設定する必要があります。
次のスクリーンショットは、そのようなルートテーブルの例です（ファイアウォールの IP アドレスは10.0.4.4）：
ルートテーブルは DNS Private Resolver で使用されるアウトバウンドサブネットにリンクされる必要がある。
ルートテーブルと一緒にファイアウォールルールも必要である。このルールは、アウトバウンドサブネットのCIDR 範囲からUDPおよびTCPポート53を経由して外部 DNS ソースへのトラフィックを許可する必要があります。以下のスクリーンショットは、Azure ファイアウォール・ポリシーの例を示しています（外部システムが1.1.1.1でホストされていると仮定）：
外部 DNS システムへのすべての DNS リクエストは、送信元 IP アドレスとしてファイアウォールに割り当てられたパブリック IP アドレスを持ちます（Azure Firewall の場合、サードパーティ製ファイアウォールの場合は異なる可能性があります）。
通常、この IP アドレスは外部 DNS システムでホワイトリストに登録される必要があり、DNS リクエストソースを識別する役割を果たします。
ステップ4：プライベート DNS ゾーン
Azure で使用されるすべてのプライベート DNS ゾーンは、ハブ VNet のみにリンクされる必要があります。他の仮想ネットワーク (VNet) にリンクしてはなりません。
ステップ5： DNS 転送ルールセット
DNS 転送ルールセットは、1 つまたは複数のアウトバウンドエンドポイントに適用したり、1つまたは複数の仮想ネットワーク (VNet) にリンクしたりできる DNS 転送ルールのグループ（最大1000）です。このセットアップでは、Azure DNS Private Resolver のアウトバウンドエンドポイントに関連付け、ハブの仮想ネットワーク (VNet) にリンクする1つのルールセットが必要です。
ルールセットを仮想ネットワーク (VNet) にリンクすると、名前解決のための Azure DNS エンドポイントのロジックにルールが追加されます。仮想ネットワーク (VNet) の DNS エンドポイントはこのロジックを使用して、リンクされたルールセットで名前を解決します：
- その名前がプライベート DNS ゾーンで定義されている場合は、そのゾーンを使用して解決する。
- そうでない場合は、ルールセットを使用する。
- ルールセットに一致するルールがない場合は、パブリックDNSを使用する。
このアーキテクチャを構成するには、以下のルールを持つ DNS 転送ルールが必要です（順不同です）：
- ドメインコントローラ上でホストされるドメインは、対応するドメインコントローラで使用されるすべての IP アドレスにリンクされたルールを持つ必要がある（例：Entra ID DSを使用する場合は2インスタンス）
- オンプレミスまたは外部の DNS サーバーでホストされているドメインは、 DNS サーバーの IP アドレスと一緒に定義する必要があります
- パブリック DNS 名を解決するために専用サービスを使用する場合、このホストされたサービスのパブリック IP アドレスにリンクする、いわゆるワイルドカードルール（ドットまたは'.'ドメイン名）が存在する必要があります
以下のスクリーンショットは、そのようなルールセットの例を示しています：
以下のスクリーンショットに示すように、このルールをハブ仮想ネットワークにリンクする必要があります。
ステップ6：スポーク DNS の設定
これで一貫した DNS 解決のためのインフラがセットアップされた。最後の手順は、 DNS サーバーとしてすべての仮想ネットワーク (VNet) に受信エンドポイント IP アドレスを割り当てることです（DHCP オファーで使用）。これには、各仮想ネットワー ク・スポークの DNS サーバー設定を、受信エンドポイント IP アドレスを持つ「カスタム」 DNS サーバーに設定する必要があります。
これが完了すると、スポーク仮想ネットワーク (VNet) の各リソース（ネットワークインターフェース）は、 DNS サーバーを割り当てるために DHCP リースを更新する必要があります。
注：この記事にあるように、いくつかの DNS ゾーン（プライベートリンク用など）はワイルドカードルールから除外されています。したがって、スポーク内の DNS 転送ルールセットからプライベートエンドポイントを解決することはできません。したがって、スポーク VNet の DNS コンフィギュレーションでは、先に説明したように、受信エンドポイント IP アドレスを使用する必要があります。
ステップ7：テスト
これですべての設定が完了し、あとはテストを行うだけです。
テストには以下の要素が必要です：
- スポーク仮想ネットワーク (VNet) 内の仮想マシン
- オンプレミス（またはVPNまたはExpress Routeで接続された各外部ネットワークセグメント）の仮想マシン
- ハブに関連付けられた正しいプライベート DNS ゾーンに統合されたプライベートエンドポイント
スポーク内の仮想マシンから
- DHCP 経由で割り当てられた DNS サーバが DNS Private Resolver 受信エンドポイントであることを確認します。
- 以下の名前解決 NSLOOKUP を実行
- プライベート・エンドポイントがリンクされている PaaS サービスの DNS 名。これは、プライベート・エンドポイントのプライベート IP アドレスに解決する必要があります。
- 各ドメイン・コントローラーでホストされている DNS 名。これは、AD DS DNS 構成で定義された IP アドレスに解決する必要があります。
- 各外部（構内、他のクラウドなど） DNS サーバーでホストされる DNS 名。これは、その DNS ゾーンで定義されている正しい IP アドレスに解決する必要があります。
- オンプレミスまたは他のクラウドにある仮想マシンから、同じNSLOOKUPコマンドを実行する。返される IP アドレスは同一でなければならない。
Virtual WAN
Azure Virtual WANは、管理された仮想ハブの概念を使用します。
この仮想ハブに DNS Private Resolver を導入することはできません。しかし、このアーキテクチャーは若干の修正で活用することができます：
- DNS Private Resolver は、仮想ハブに接続される新しいスポーク仮想ネットワーク (VNet) に展開する必要があります。 DNS Private Resolver は、仮想ハブに接続される新しいスポーク仮想ネットワーク (VNet) に配備する必要があります。IP接続、ファイアウォール、またはネットワーク・セキュリティ・グループに関する要件はすべて同じです。
- 仮想ハブのファイアウォールは、 DNS Private Resolver のインバウンドエンドポイントを DNS サーバーとして使用するように設定する必要があります。以下のスクリーンショットは、Azure ファイアウォールの設定方法を示しています。サードパーティのファイアウォールでは、ベンダーとタイプによって異なります。
仮想ハブにデプロイされた各 NVA は、ファイアウォールと同様に DNS サーバーを設定する必要があります（DNS Private Resolver の受信エンドポイントを指す）。もちろん、設定方法は NVA のタイプによって異なります。
謝辞
この記事の貴重なフィードバックとレビューをしてくださったPieter Kestelyn氏とTomas Corveleyn氏に感謝いたします。
Q&A
複数のハブ・スポークを持つトポロジーで活用できますか？
はい。複数のハブ＆スポーク構成を作成する場合（異なる地域など）、このアーキテクチャを各ハブに導入する必要があります。
追加のファイアウォールルールや IP ルーティング設定を構成する必要があるかもしれません。1つのハブにピアリングされた仮想ネットワーク (VNet) にドメインコントローラーシステムがあり、それを別のハブの DNS Private Resolver に接続したいとします（DNS 目的）。
その場合、DNS Private Resolver とドメインコントローラーのあるスポーク間の DNS トラフィックを許可するために、両方のハブでファイアウォールルールを有効にする必要がある可能性があります。
また、ドメインコントローラーとの接続を可能にするために IP ルーティングを調整する必要がある可能性があります。
このアーキテクチャは回復力をサポートしますか?
はい、 DNS Private Resolverはデフォルトで回復力のためにアベイラビリティゾーンを活用します（Azure DNS Private Resolver の回復力）。
リージョンのフェイルオーバーが必要な場合は、このアーキテクチャを別のリージョンに再度導入する必要があります。