はじめに
Azure で名前解決をする場合、さまざまなオプションがありますがその一つの方法として Private Resolver があります。
簡単に言うとマネージドの DNS サーバーなのですが、いくつかマネージドサービスならではの機能があります。ハブアンドスポークやオンプレミス(から|へ)の名前解決をするためには、それらの機能を使う必要があります。
この記事では、いくつかの名前解決のシナリオを考えてみます。
Private Resolver のドキュメントはこちらです。
Private Resolver のリファレンスアーキテクチャーはこちらです。
また、機能を分かりやすく解説している記事がありましたのでこちらも参考になります。Private Resolver 特有の用語の解説もありますので確認しておきましょう。
名前解決のポイント
Azure において(特に Private Resolver を使う場合)名前解決を考える時には、どこから何の名前解決をしたいのか、を抑えておく必要があります。
- Azure のプライベート エンドポイント(=プライベート DNS ゾーン)の名前解決
- オンプレミスからの名前解決
- オンプレミス(他の DNS サーバー)への名前解決
また、特にハブアンドスポーク構成の場合、名前解決の管理をどこで行うか、ということも考える必要があります。
- スポークに名前解決の管理を委任する
- ハブで名前解決を集中管理する
これらを複合的に考慮し、その環境に適したベストな構成を選択する必要があります。
いくつかのシナリオを考えてみましょう。
シナリオ1: オンプレミスから PaaS リソースを名前解決する
オンプレミスとの閉域接続においてよくあるシナリオです。
プライベート エンドポイント構成の PaaS リソースを名前解決する場合、仮想ネットワークにリンクされた プライベート DNS ゾーン を使って名前解決することになりますが、Azure 既定の DNS を使用する必要があり、オンプレミスから直接名前解決ができません。
従来では、Azure 上に DNS サーバーを立てる、Azure Firewall で代用する、もしくは割り切った案として、オンプレミスの DNS サーバーで PaaS リソースの名前解決をする(プライベート DNS ゾーンと二重管理する)、 hosts に書くというソリューションがありました。
これらの方法について以下に詳しく書かれています。
Q: Private Endpoint に対応したサービスをオンプレミスから利用する場合のベストプラクティスを教えてください
ここに新たな解決策として、Private Resolver を使うことができます。
冒頭で記載したように、Private Resolver はマネージドの DNS サーバーなので、仮想マシンとして DNS サーバーを展開した時と同様の使い方ができます。
オンプレミスからは、Private Resolver の受信エンドポイントのプライベート IP アドレスに対してフォワードする(もしくは DNS サーバーとして指定する)ことで、Private Resolver が所属する仮想ネットワークにリンクされたプライベート DNS ゾーンを使って名前解決ができるようになります。
尚、このシナリオでは、仮想ネットワークにリンクされたプライベート DNS ゾーンが使用されるため、DNS 転送ルールセットは不要です。
シナリオ2: オンプレミスの DNS サーバーを使って Azure からオンプレミスのリソースを名前解決する
このシナリオは、Azure 上のリソースからオンプレミスのサーバー等のリソースを名前解決したい場合です。
また、オンプレミスだけでなく、他の DNS サーバーがあった時にその DNS サーバーが持つゾーンで名前解決したい場合も同様です。
このような場合、Private Resolver の送信エンドポイントを使って、オンプレミスの DNS サーバーに名前解決をフォワードします。
送信エンドポイントは、あくまでもエンドポイントとしてのリソースであり、このエンドポイントから DNS がクエリされます。
送信エンドポイントだけを作ってもオンプレミスに対する名前解決としては機能しません。
名前解決を機能させるには、DNS 転送ルールセットを作成し、送信エンドポイントと紐づける必要があります。
DNS 転送ルールセットでは、ゾーン名とフォワード先の DNS サーバーの IP アドレスを指定します。条件付きフォワーダーと同じ様な役割を持つと考えていいでしょう。
フォワードされたオンプレミスの DNS サーバーから見ると、クエリ元のクライアントは送信エンドポイントのサブネットの IP アドレスになります。
Azure からオンプレミスのリソースの名前解決をする場合は、受信エンドポイントに対してフォワード、もしくは DNS サーバーとして指定することで、DNS 転送ルールセットに従って名前解決が行われます。
シナリオ3: ハブアンドスポーク構成においてスポークに名前解決の管理を委任する
このシナリオ3、と続くシナリオ4は、Azure のネットワーク構成からの観点です。
Azure のランディングゾーンでは柔軟なネットワーク構成を実現するために、ハブアンドスポーク構成が推奨されています。
この時、管理主体がどこにあるかで名前解決の構成が変わってきます。スポークに PaaS リソース等名前解決の対象とするリソースが多くあり、管理もスポークが主体である場合、名前解決もスポークで管理したくなるはずです。
プライベート エンドポイントやそれに付随するプライベート DNS ゾーンはスポークに存在することが想定され、ハブやオンプレミスにある一部のリソースの名前解決をしたい場合を考えます。
この場合、Private Resolver のDNS 転送ルールセットをスポークの仮想ネットワークにリンクし、一部のゾーンの名前解決をハブの受信エンドポイントもしくは、オンプレミスの DNS サーバーに向けます。また、仮想ネットワークの DNS は、Azure 既定の DNS を参照します。
この図では、オンプレミスにあるゾーンの名前解決は、DNS 転送ルールセットを使ってオンプレミスの DNS サーバーに向けています(赤線)。
一方、スポークにあるストレージ アカウントの名前解決は、スポークにリンクされているプライベート DNS ゾーンを使って名前解決しています(緑線)。
この構成によってスポーク側に柔軟なリソース管理を行わせつつ、ハブやオンプレミスのリソースの名前解決を可能とします。
この構成は、ドキュメントの分散 DNS アーキテクチャとして紹介されています。
シナリオ4: ハブアンドスポーク構成においてハブで名前解決を集中管理する
このシナリオは、シナリオ3でスポークに管理主体を置いていたのに対し、ハブに管理主体を置いた場合です。
PaaS リソースやプライベート エンドポイントをハブに配置し、スポークには仮想マシン等のリソースを配置する場合を考えます。
このシナリオでは、スポークの名前解決はスポークの仮想ネットワークの DNS をAzure 既定の DNSからハブの受信エンドポイントに向けます。
オンプレミスにある DNS サーバーで名前解決をするためには、ハブの仮想ネットワークにリンクされているDNS 転送ルールセットを使って、フォワード先にオンプレミスの DNS サーバーの IP アドレスを指定します。
この図では、シナリオ3と同様に、オンプレミスにあるゾーンの名前解決は、DNS 転送ルールセットを使ってオンプレミスの DNS サーバーに向けています(赤線)。
一方、ハブあるストレージ アカウントの名前解決は、受信エンドポイントを使用してハブのプライベート DNS ゾーンを使って名前解決しています(緑線)。
プライベート エンドポイントやオンプレミス、その他のリソースの名前解決をハブで集中管理できるため、スポーク側の柔軟性は失われますが、一元的な管理が可能です。当然ながらハブの DNS の管理作業が増えることになります。
この構成は、ドキュメントの一元化された DNS アーキテクチャとして紹介されています。
構成する上での注意点
エンドポイント専用のサブネットを用意する
受信エンドポイント、送信エンドポイントは、サブネットの委任の機能を使って構成されます。従って、プライベート エンドポイントをそのサブネットに置くことは出来なくなるため、Private Resolver 専用のサブネットを用意するか、プライベート エンドポイント専用のサブネット(Private Resolverのエンドポイントを利用しないサブネット)を用意します。
サブネットの委任をした場合の影響については以下のドキュメントを参照してください。
以下の部分に該当します。
サブネットが委任された場合、プライベート エンドポイントと共に使用できない。
最後に
こういうパターンはどうなの？とかこれはちがうのでは？とかその他ご意見があればぜひコメントお願いします！
Discussion