Azure Private DNSを使用した際の名前解決した際にどうなるかど忘れしてしまったので、改めてAzure Private DNSを使用した際の名前解決の挙動について実際に動作を確認したうえで整理してみようと思います。
前提知識
Azure Private DNS
Azure Private DNSは仮想ネットワーク環境課内(プライベートネットワーク内)に対してのみ有効なDNSを提供するためのサービスです。よくある使用例としては、Private EndPointと組み合わせてストレージアカウントやKeyVaultを、VNET経由でのみURLを使用して接続する際に使用するようなケースになると思います。
Azure提供(既定)のDNS
Azureが提供するDNSです。仮想ネットワークのDNS設定では「既定 (Azure提供)」とかで表示されているやつです。「168.63.129.16」のIPアドレスから提供され、公開されているドメインやPrivate DNSに登録されているドメインの名前解決はもちろん、仮想ネットワーク内のホスト名の名前解決も可能なDNSです。
確認方法
仮想マシンとKeyVaultを用意して、仮想マシン側からnslookupコマンドでKeyVaultのURLの名前解決を実行しました。
※環境を変更したタイミングで毎回仮想マシンは再起動しています。
結果
Azure既定のDNSを使用して、パブリック接続のみ有効なKeyVaultにアクセスする場合
仮想ネットワーク内に所属する仮想マシンが、外部にあるKey Vaultに対して接続を行うパターンで、仮想ネットワークのDNSは既定(Azure提供)を使用しているパターン。
まぁもちろん当然ですが、KeyVaultのドメインをパブリックIPアドレスに名前解決できています。(KeyVaultのURLが別名で、AレコードはCloud Serviceのドメインが登録されてるのは少し気になりますが…)
GoogleのDNSを使用して、パブリック接続のみ有効なKeyVaultにアクセスする場合
仮想ネットワーク内に所属する仮想マシンが、外部にあるKey Vaultに対して接続を行うパターンで、仮想ネットワークのDNSはGoogleのパブリックDNS(8.8.8.8)を利用するパターン。
こちらも同様にKeyVaultのドメインをパブリックIPアドレスに名前解決できています。(Aレコードや別名も同じ結果)
Azure既定のDNSを使用して、同一ネットワーク内のプライベート接続のみ有効なKeyVaultにアクセスする場合
仮想ネットワーク内に所属する仮想マシンが、同一ネットワーク内に配置されている、プライベート接続のみ許可されたKeyVaultを利用するパターン。KeyVault自体はPrivate Endpointを利用してPrivate DNSにドメインを登録している状態。
KeyVaultのプライベートIPアドレスが取得できています。(しかもPrivate DNSに登録されているドメイン名がAレコードになるんですね)
GoogleのDNSを使用して、同一ネットワーク内のプライベート接続のみ有効なKeyVaultにアクセスする場合
仮想ネットワーク内に所属する仮想マシンが、同一ネットワーク内に配置されている、プライベート接続のみ許可されたKeyVaultを利用するパターンかつ、Azure既定以外のDNSを使用するパターン。
この場合はパブリックIPアドレスのほうで名前解決されました。
プライベートIPアドレスでも名前解決はAzure DNSによる機能なのでGoogle DNSではプライベートIPアドレスに名前解決のしようがないのは理解していましたが、別名にPrivate DNSに登録されているドメイン名も含まれているので、Azure DNS以外でPrivate DNSに登録されているドメイン名を名前解決しようとするとパブリックIPアドレスで名前解決されるようです。
Azure既定のDNSを使用して、同一ネットワーク内のパブリック接続もプライベート接続もどちらも可能なKeyVaultにアクセスする場合
仮想ネットワーク内に所属する仮想マシンが、同一ネットワーク内に配置されている、パブリック接続とプライベート接続どちらも許可されたKeyVaultを利用するパターン。
この場合はプライベートIPアドレスのほうで名前解決されました。なので、同一ネットワーク内でプライベートとパブリック両方が有効のKeyVaultがある場合はプライベートのほうが優先されるみたいです。
GoogleのDNSを使用して、同一ネットワーク内のパブリック接続もプライベート接続もどちらも可能なKeyVaultにアクセスする場合
仮想ネットワーク内に所属する仮想マシンが、同一ネットワーク内に配置されている、パブリック接続とプライベート接続どちらも許可されたKeyVaultを利用するパターンかつ、Azure既定以外のDNSを使用するパターン。
「GoogleのDNSを使用して、同一ネットワーク内のプライベート接続のみ有効なKeyVaultにアクセスする場合」でもパブリックIPアドレスに名前解決されていたので、ある意味では予想できる結果にはなりました。なのでAzure DNS以外で名前解決しょうとするとパブリックIPアドレスにすべて名前解決されるという認識でよさそうです。
Azure既定のDNSを使用して、異なるネットワーク内のプライベート接続のみ有効なKeyVaultにアクセスする場合
仮想ネットワーク内に所属する仮想マシンが、異なるネットワーク内に配置されている、プライベート接続のみ許可されたKeyVaultを利用するパターン。KeyVault自体はPrivate Endpointを利用してPrivate DNSにドメインを登録している状態。
この場合パブリックIPアドレスで名前解決されました。別名などをみてみると「GoogleのDNSを使用して、同一ネットワーク内のプライベート接続のみ有効なKeyVaultにアクセスする場合」と同じ結果ですね。おそらくプライベート接続だけ許可されている旨のエラーを出すためにこの挙動になっているのかなと思っています。
GoogleのDNSを使用して、異なるネットワーク内のプライベート接続のみ有効なKeyVaultにアクセスする場合
仮想ネットワーク内に所属する仮想マシンが、異なるネットワーク内に配置されている、プライベート接続のみ許可されたKeyVaultを利用するパターンかつ、Azure既定以外のDNSを使用するパターン。KeyVault自体はPrivate Endpointを利用してPrivate DNSにドメインを登録している状態。
同一のネットワークだった時と同じで、パブリックIPアドレスで名前解決され、かつPrivate DNSに登録されているドメインでもパブリックIPに名前解決されるようです。
Azure既定のDNSを使用して、異なるネットワーク内のパブリック接続もプライベート接続もどちらも可能なKeyVaultにアクセスする場合
仮想ネットワーク内に所属する仮想マシンが、異なるネットワーク内に配置されている、パブリック接続とプライベート接続どちらも許可されたKeyVaultを利用するパターン。
この場合も「GoogleのDNSを使用して、同一ネットワーク内のパブリック接続もプライベート接続もどちらも可能なKeyVaultにアクセスする場合」と同様の結果になりました。なので、ネットワークが異なるリソースに対する名前解決結果は、Azure DNS以外のDNSと同じになる認識でよさそうですね。
GoogleのDNSを使用して、異なるネットワーク内のパブリック接続もプライベート接続もどちらも可能なKeyVaultにアクセスする場合
仮想ネットワーク内に所属する仮想マシンが、異なるネットワーク内に配置されている、パブリック接続とプライベート接続どちらも許可されたKeyVaultを利用するパターンかつ、Azure既定以外のDNSを使用するパターン。
こちらもネットワークが同一/異なるかかわらずパブリックIPアドレスで名前解決されました。
まとめ
ということで簡単なまとめとしては、
- Azure DNS(既定)にて、同一のネットワーク内にPrivate DNSが登録されていると、パブリックなURL/プライベートなURL問わずプライベートIPアドレスで名前解決される。
- それ以外の条件の場合は、パブリックなURL/プライベートなURL問わずパブリックIPアドレスで名前解決される (おそらく403 Forbiddenのリクエストを返すため?) ということでした。
(あとどうでもいい余談ですが、今回の検証でDevelop SKUのBastionが使用できてコスト的に非常に助かりました東日本リージョンにもはよ)