Azure DNS Private DNS Resolver が Public Preview (2022/05/16) GA (2022/10/12) となりました。この機能を利用することでオンプレから Private DNS zone へ名前解決要求を転送できるようになりますので、Azure 上にフォワーダーとして機能する DNS サーバーを構成する必要がなくなります。公開情報でも高可用性や運用費用の削減、高パフォーマンス等の利点があげられています。
実際に検証を行い、検証の中で確認した留意点等をまとめてみましたので利用する際はご一読いただけたらと思います。パブリックプレビューですので、今後、修正・変更が入る可能性がある点はご了承ください。
参考手順
構成図
前提
- 対象リージョンは EastUS (Japan East でも GA しており検証済み。)
※2022/05/17 時点では JapanEast/West はサポートされてません
https://docs.microsoft.com/en-us/azure/dns/dns-private-resolver-overview#regional-availability - 構成図内の DNS Private Resolver と DNS forwarding rule set 以外のリソースは作成済みであること
- Onpre-VNet / Hub-VNet / Sopke1 の各仮想ネットワークは相互に通信できる構成であること (VNet ピアリングの Use remote gateway 有効)
- Hub-VNet に受信エンドポイント、送信エンドポイント専用のサブネットを作成済みであること (/24-/28 の範囲)
用語、機能について
- 受信エンドポイント : DNS フォワーダーとして名前解決要求をうけつけるエンドポイント
- 送信エンドポイント : 条件付き転送を行うためのエンドポイント。受信エンドポイントとは別の専用サブネットが必要となります。
- DNS 転送ルールセット : 条件付きフォワーダーのルールをまとめたグループ。送信エンドポイントと関連付けて利用します。
- 仮想ネットワーク リンク : DNS 転送ルールセットの条件付きフォワーダーを利用する仮想ネットワークを指定します。
1. DNS Private Resolver [Inbound Endpoint (受信エンドポイント)]
以下の構成図のような流れで自宅の端末から VPN と DNS Private Resolver の受信エンドポイントを経由して Private DNS zone の名前解決を行います。
1-1. リソース作成
まず DNS Private Resolver のリソースを作成して、自宅から Private DNS zone の名前解決を行い、Private Endpoint への接続を試してみます。
-
以下のリンクから preview が有効化されているポータルにログインします。
https://go.microsoft.com/fwlink/?linkid=2194569 -
ポータル上の部の検索画面で dns と検索し、"DNS Private Resolver" を選択します。
実際の操作画面は利用する時期によって異なる可能性があります。見つからない時は Marktplace から resolver や ruleset を検索してみてください。
1-2. 動作確認
-
自宅から P2S VPN 経由で Azure に接続し、DNS Private Resolver で名前解決を行えるか確認します。
クライアントの DNS が適切に構成されていないため、そのままだと BLOB のパブリックのエンドポイントが返ってきます。
-
受信エンドポイントの IP アドレス "10.0.0.4" を付け足して、nslookup を実行します。
期待通り、BLOB の Private Endpoint 用の IP アドレスが返ってきました。
-
クライアントの DNS の設定を 10.0.0.4 に変更し、WSL の curl コマンドにて BLOB へ接続してみます。
問題なく Private Endpoint 経由で接続できました。
$ curl -v https://testdnsresolver.blob.core.windows.net/test1/index.html
* Trying 10.0.5.4:443...
* TCP_NODELAY set
* Connected to testdnsresolver.blob.core.windows.net (10.0.5.4) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: CN=*.blob.core.windows.net
* start date: Feb 25 18:47:29 2022 GMT
* expire date: Feb 25 18:47:29 2023 GMT
* subjectAltName: host "testdnsresolver.blob.core.windows.net" matched cert's "*.blob.core.windows.net"
* issuer: C=US; O=Microsoft Corporation; CN=Microsoft RSA TLS CA 02
* SSL certificate verify ok.
> GET /test1/index.html HTTP/1.1
> Host: testdnsresolver.blob.core.windows.net
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Length: 12
< Content-Type: text/html
< Content-MD5: bLL+2vK0uXm1HPdaivMY1w==
< Last-Modified: Tue, 17 May 2022 01:25:57 GMT
< ETag: 0x8DA37A431D6A9A2
< Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
< x-ms-request-id: 436326b5-c01e-008d-0f99-69d72c000000
< x-ms-version: 2009-09-19
< x-ms-lease-status: unlocked
< x-ms-blob-type: BlockBlob
< Date: Tue, 17 May 2022 02:53:22 GMT
<
* Connection #0 to host testdnsresolver.blob.core.windows.net left intact
Test BLOB
2. DNS Private Resolver [Outbound Endpoint (送信エンドポイント)]
以下の構成図のような流れで、Spoke 側の VM から DNS Private Resolver の送信エンドポイントと VPN を経由して、疑似オンプレ環境 (Azure) の DNS サーバーを利用した名前解決を行います。
2-1. 送信エンドポイントの設定
outbound 用のサブネットを 10.0.1.0/24や 10.0.4.0/26 で作ったところ、以下のエラーで失敗してしまいました。Validation の不具合のように見えますが、先に進めませんでしたので公開ドキュメントを真似て 10.1.1.0/26 で作ったところ成功しました。現時点ではエラーにあるような 10.0.x.0/24 のようなアドレス帯は使わないほうがよさそうです。 ポータルの Warning にある通り、10.0.0.0/24 - 10.0.16.0/24 のアドレス空間は使えないようです。
outbound-endpoint の送信エンドポイントの追加に失敗しました:
The specified subnet '/subscriptions/xxxx/resourceGroups/TestDNSResolver/providers/Microsoft.Network/virtualNetworks/Hub-VNet/subnets/outbound-subnet' could not be used to provision the outbound endpoint.
Please make sure you use a subnet of at least /28 and at most /24 size, which is not currently in use by any other DNS resolver endpoint or any other Azure service workloads,
and does not collide with the reserved subnet spaces of '10.0.1.0/24;10.0.2.0/24;10.0.3.0/24'.
2-2. DNS 転送ルールセットの設定
-
DNS 転送ルールセットの設定の作成
ポータル上の部の検索画面で dns と検索し、"DNS 転送ルールセット" を選択します。
実際の操作画面は利用する時期によって異なる可能性があります。見つからない時は Marktplace から resolver や ruleset を検索してみてください。
-
サブスクリプション、リソースグループ、ルールセット名、リージョン、Private Resolver、Outbound endpoints を選択/入力します。
-
ルール名、ドメイン名、ルールの状態 [Enable のまま]、接続先 IP アドレス [DNS サーバー] を設定し、追加を押します。
2-3. 動作確認
SpokeVM1 から test1.testdnsreslvzone.com を nslookup した際、ルールセットを作成する前は、"Non-existent domain" のエラーで終わっていました。
ルールセットを作成した後は下記のように Azure provided DNS 経由で、疑似オンプレ環境の DNS サーバーの名前解決ができるようになりました。
ただし、プレビューのためかこの条件付きフォーワーダーの動作は不安定なようで、二回に一回くらいはタイムアウトが出る動作となってました。受信エンドポイントと比べるとこちらはまだまだ改善が必要そうです。 GA 後は安定して名前解決できました。
ちなみに送信エンドポイントを利用する場合、クライアントと送信エンドポイントのサブネットとの接続は必須ではないようで、以下の様に VNet ピアリングを削除した状態でも利用可能でした。需要があるかはわかりませんが、条件付きフォワーダーのドメインをドット (.) としてすべての要求を指定した DNS サーバーに転送することもできます。
こちらも高確率でタイムアウトが発生していたので、今後の改善に期待したいです。 GA 後は安定して名前解決できました。
ちなみに DNS サーバー側からみたときの送信元アドレスは送信エンドポイントで指定したサブネット内のアドレスが複数利用されておりました。
3. DNS Private Resolver [送受信のエンドポイントを利用]
公開ドキュメントの以下のアーキテクチャを見る限り、受信エンドポイントで名前解決要求を受け付けた後、条件付きフォーワーダーと送信エンドポイントを利用できるように読み取れます。
自宅から受信エンドポイントを指定して、nslookup した際、ルールセットを作成する前は、"Non-existent domain" のエラーで終わっていました。
DNS 転送ルールセットに Hub-VNet のリンクを追加したところ、タイムアウトは発生しましたが、疑似オンプレ環境の DNS サーバーの名前解決ができるようになりました。 GA 後は安定して名前解決できました。
4. 名前解決のフロー
公開情報の内容と確認した動作をふまえると DNS Private Resolver を利用した名前解決は以下のようなフローチャートになります。