Azure の仮想ネットワークまたは NIC の設定 (VM/VMSS のみ) で DNS サーバーを指定できますが、可用性のために DNS サーバーを複数指定することができます。Azure の代表的なサービスにてどのような場合に複数の DNS サーバーが機能するのかを確認してみます。
構成
以下のような構成にて DNS サーバーを 3 台構成し、DNS サーバー側でパケットキャプチャを確認して、いくつかの代表的なプロダクトの挙動を確認します。
DNS フォワーダーの準備
Windows Server 2022 の仮想マシンを 3 台作成し、DNS サーバーの役割を追加します。
DNS サーバーのフォーワーダーの設定にて 168.63.129.16 を追加します。
フォーワーダーのみ利用したいためルートヒントはすべて消しておきます。
仮想ネットワークの DNS 設定
仮想ネットワークの DNS 設定にて DNS サーバーの IP アドレスを設定します。
Windows VM の挙動
Windows Server 2022 の仮想マシンにて動作を確認します。
フォワーダーが構成されている場合の挙動
nslookup での動作確認
nslookup で AzureDNS でホストしている FQDN の名前解決を行います。
パケットをみると DNS の設定で一番上に位置している DNS サーバーのみで名前解決要求が行われています。
ブラウザでの動作確認
ブラウザで FQDN で接続します。
パケットをみると DNS の設定で一番上に位置している DNS サーバーのみで名前解決要求が行われています。
フォワーダーが構成されていない場合の挙動
3 台の DNS サーバーのフォワーダーを削除して、DNS サービスを再起動します。
nslookup での動作確認
名前解決は失敗するようになりました。
パケットをみると DNS の設定で一番上に位置している DNS サーバーのみで名前解決要求が行われています。
ブラウザでの動作確認
ブラウザで FQDN で接続し、名前解決が失敗することを確認します。
パケットをみると名前解決要求が全台の DNS サーバーに送られていることがわかります。
試しに上から 2 番目の 10.30.0.5 の DNS サーバーだけフォワーダーの設定を入れたところ、名前解決要求が成功しました。名前解決要求が失敗する場合はブラウザが各 DNS サーバーに名前解決要求を行い利用可能な DNS サーバーを利用する動作であるようです。
Linux VM の挙動
Linux VM (Ubuntu 20.04 LTS) でも同様の確認をしてみます。
フォワーダーが構成されている場合の挙動
nslookup での動作確認
nslookup を実行し、名前解決が成功することを確認します。Linux の場合、127.0.0.53 が DNS サーバーとして表示されていますが、これは "systemd-resolved" というサービスが DNS クエリを処理しているために、このような動作になるようです。
hiyama@vm-lin-cl01:~$ nslookup appgwv2.hiyamanet2.org
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: appgwv2.hiyamanet2.org
Address: 4.xx.xx.40
hiyama@vm-lin-cl01:~$ nslookup appgwv2.hiyamanet2.org
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: appgwv2.hiyamanet2.org
Address: 4.xx.xx.40
DNS サーバー側のパケットキャプチャをみると DNS の設定で 1 番上に位置している DNS サーバー (10.30.0.4) のみで名前解決要求が行われています。
curl での動作確認
curl コマンドを実行し、名前解決が成功することを確認します。
hiyama@vm-lin-cl01:~$ curl -v http://appgwv2.hiyamanet2.org
* Trying 4.xx.xx.40:80...
DNS サーバー側のパケットキャプチャをみると DNS の設定で 1 番上に位置している DNS サーバーのみで名前解決要求が行われています。
フォワーダーが構成されていない場合の挙動
nslookup での動作確認
名前解決が失敗することを確認します。
hiyama@vm-lin-cl01:~$ nslookup appgwv2.hiyamanet2.org
;; Got SERVFAIL reply from 127.0.0.53
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find appgwv2.hiyamanet2.org: SERVFAIL
hiyama@vm-lin-cl01:~$ nslookup appgwv2.hiyamanet2.org
;; Got SERVFAIL reply from 127.0.0.53
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find appgwv2.hiyamanet2.org: SERVFAIL
DNS サーバー側のパケットキャプチャをみると 3 台すべての DNS サーバーへで名前解決要求が行われています。
3 台目のみフォワーダーを追加したところ、名前解決が成功しました。名前解決要求が失敗する場合は各 DNS サーバーに名前解決要求を行い利用可能な DNS サーバーを利用する動作であるようです。
curl での動作確認
名前解決が失敗することを確認します。
hiyama@vm-lin-cl01:~$ curl -v http://appgwv2.hiyamanet2.org
* Could not resolve host: appgwv2.hiyamanet2.org
* Closing connection 0
curl: (6) Could not resolve host: appgwv2.hiyamanet2.org
DNS サーバー側のパケットキャプチャをみると 3 台すべての DNS サーバーへで名前解決要求が行われています。
3 台目のみフォワーダーを追加したところ、名前解決が成功しました。名前解決要求が失敗する場合は各 DNS サーバーに名前解決要求を行い利用可能な DNS サーバーを利用する動作であるようです。
Application Gateway の挙動
DNS テスト用の WebApps を作成し、Application Gateway のバックエンドに登録します。
フォワーダーが構成されてる場合でも DNS サーバー側のパケットキャプチャをみると 3 台すべての DNS サーバーへで名前解決要求が行われています。
意図的に全台の DNS サーバーから DNS フォーワーダーを削除し、Application Gateway で 502 Bad Gateway が表示される状態で 1 台だけ DNS フォーワーダーを追加したところ Application Gateway が正常に動作したため、各 DNS サーバーに名前解決要求を行い利用可能な DNS サーバーを利用する動作であるようです。
Azure Firewall DNS Proxy の挙動
Azure Firewall を Standard SKU で構成し、DNS Servers と DNS Proxy の設定を行います。仮想ネットワークの DNS 設定と同様 3 台の DNS サーバーを指定します。
フォワーダーが構成されていない場合の挙動
Windows VM から Azure Firewall のプライベート IP アドレスを指定して nslookup を行い、名前解決が失敗することを確認します。
パケットキャプチャをみると 3 台すべての DNS サーバーへで名前解決要求が行われています。
2 台目の DNS サーバーにフォワーダーを追加
Azure Firewall のプライベート IP アドレスを指定して nslookup を行うと、うまく行ったり、いかなかったりしています。
パケットキャプチャをみると 3 台すべての DNS サーバーへランダムで名前解決要求が行われており、2 台目にリクエストが飛んだ時だけ成功しています。
1,3 台目の DNS サーバーの DNS サービスを停止
nslookup が毎回成功するようになりました。
パケットも 2 台目の DNS サーバーのみに転送されるようになりました。
Private DNS Resolver 転送ルールの挙動
Private DNS Resolver 転送ルールセットの動作確認をします。フォーワーダーは 168.63.129.16 だとループしてしまうため、8.8.8.8 を指定します。
Private DNS Resolver 転送ルールセットを作成し、仮想ネットワークの DNS 設定と同様 3 台の DNS サーバーを指定します。
転送条件はすべてのリクエストを転送する構成にしています。
クライアントの VM がある仮想ネットワークにリンクします。ループを防ぐため DNS サーバー内のフォーワーダー設定は事前にすべて削除しておきます。
Windows VM から 168.63.129.16 を指定して nslookup を実行し、名前解決が失敗することを確認します。
パケットをみると DNS の設定で 1 番上に位置している DNS サーバーのみで名前解決要求が行われています。
2 番目の DNS サーバーだけフォワーダーを追加してみます。
Windows VM から複数回 168.63.129.16 を指定して nslookup を実行してみましたが、名前解決は失敗しています。
パケットをみると DNS の設定で一番上に位置している DNS サーバーのみで名前解決要求が行われています。
1 番目の DNS Server サービスを停止します。
nslookup が成功するようになりました。
パケットからは DNS の設定で 1 番上に位置している DNS サーバーにリクエストが送られた後、2 番目の DNS サーバーで処理されていることがわかります。
まとめ
仮想ネットワークの DNS 設定に複数の DNS サーバーがある状態で、シナリオ毎に動作するかを以下の表にまとめています。 x は切り替わらないまたは不安定な動作になる場合を示しています。〇 はシナリオに該当する状況でも問題なく利用できたという意味合いです。
| クライアント | 1 番上の DNS サーバーにフォーワーダーなし | 1 番上の DNS サーバーの DNS サービスダウン |
|---|---|---|
| Windows Server (nslookup) | x | × |
| Windows Server (Edge ブラウザ) | 〇 | 〇 |
| Linux (nslookup) | 〇 | 〇 |
| Linux (curl) | 〇 | 〇 |
| Application Gateway | 〇 | 〇 |
| Azure Firewall DNS Proxy | x | 〇 |
| Private DNS Resolver | x | 〇 |
クライアントの動作に依存するところがありますが、上記をふまえると DNS サーバーは全台でフォワーダーを正しく構成し、不具合を招くようなゾーンは作らずに稼働させるべきだと思います。