Azure DNS Private Resolver使ってみる
はじめに
ちょっと間が空いてしまいましたが、下の記事にて「Azure DNS Private Resolver」を机上調査しました。お値段が若干高いような気がしますが、VMの維持管理が無くなると思えば「まぁこんなものかな」というところでしょう。。
ということで今回は、実際に構成を考えてみる＋作ってみて動きを確認してみます。
構成
やりたいこと
前回も貼った下記のような環境にDNS Private Resolverを適用したい、という状況を想定します
ポイントは下記の通り。
- オンプレミスにDNSサーバー（ドメインコントローラーなど）が存在する
- ExpressRoute経由でAzureと接続されている
- Azure内部やインターネットの名前解決をAzure DNSに任せたい
- オンプレミス、ドメイン内の名前解決はオンプレDNSサーバーに任せたい
検証環境
この中心に存在する、DNS ForwarderをDSN Private Resolverに置き換えます。
検証のため、オンプレミスを模したVNETを作成し、VNETピアリングで接続します。
併せて、Azure Bastionを作成し、VM（Windows）にRDPログインできるようにします。
DNS Resolverの構成ポイント
作成するものポイントは2つあります。
Inbound/Outbound Endpoint
役割の違いで2つのエンドポイントを作成します。
Inbound Endpoint
外からAzure DNSに問い合わせる際に使用するEndpointです。
オンプレミス側から問い合わせる際は、このEndpointのIPアドレスに対して、DNSクエリを行います。
Outbound Endpoint
Azure DNSに問い合わせた内容のうち、外部のDNSサーバーに問い合わせる必要があるものは、このEndpointから外向きに再問い合わせが行われます。
DNS 転送ルールセット
Outbound Endpointから再問い合わせを行う対象になるドメインや、問い合わせ先は「DNS 転送ルールセット」に記述します。
DNS 転送ルールセットはVNETと関連付けて使用し、そのVNET内からの問い合わせに対して効力を発揮します。
構成案１
公式ドキュメント通りに作成すると下記の構成になります。
ポイントとなるのは、vm-subnetに対するDNS設定です。
通常、AzureではVNET/SubnetのレイヤでDNSサーバーを指定し、配下のVMはDHCPによりDNSサーバーの情報を受領します。
この構成の場合は、デフォルト通り「168.63.129.16」を指定すればよい、と言うことになります。
構成案２
公式ドキュメントとは違いますが、前回の記事でも「こっちの方がイイのでは」と書いた構成です。
こちらのパターンの場合、VMから見たDNS問合せ先は「Inbound Endpoint（172.16.2.4）」になるので、subnetに対するDNSの設定が変更になります。
何処から問い合わせるときも「172.16.2.4」になるので、構成自体がシンプルになると思いますが、見落としている制約があるようだったら、気付いた方はコメント欄でぜひ教えてください。
作って見る
あとは実際に作ってみて、動作の確認を行います。
DNS Private Resolverの作成
リソースグループ、名前、リージョン、VNETあたりを指定するのみです。
Endpointの作成
続けて、Inbound/Outboundのエンドポイントを作成します。
名前とサブネットを指定するのみです。
ルールセットの作成
ルール名、転送対象のドメイン名、転送先のIP：ポートを指定して転送ルールセットを作成します。いわゆる「条件付きフォワーダー」ですね。
今回の場合は、「オンプレADのドメインコントローラ」を想定したVMに向けて転送する設定とします。
動作確認
構成案①の状態で、メンバーサーバー相当のVMから、①インターネット上のリソースの名前解決と②オンプレADの名前解決の両方を行います。
どちらも「168.63.129.16」に問い合わせを行い、名前解決に成功していることが分かります。
もちろん構成案②でも動作しましたので、このレベルのシンプルな環境においては、どちらでも問題なく実行できることが分かりました。
おわりに
以上のように、、構成の検討と動作確認を行いました。この手のマネージドサービスは、深く考えなくとも簡単に使えます。それだけでもちょっとしたお値段の価値はあるのではないでしょうか。
DNS Forwarder用のVMを作っている皆様、ぜひ置き換えを検討して見てください！
Discussion