VPN経由のAzureプライベートDNS：リゾルバーのエンドポイントかフォワーダーか
どちらの設計もトンネル経由でプライベートゾーンに応答します。マネージドの受信エンドポイントとフォワーダーVMを比較し、どちらでも必要な経路を確認します。
オンプレミスのサーバーがプライベートアドレスでAzure VMに到達しても、そのプライベートホスト名を解決できないため、壊れたトンネルを探すことになる。トンネルは正常だ。欠けているのはDNSの境界である。オンプレミス側には、特定のAzureプライベートゾーンをVNet内のリゾルバーが応答すべきだと知るものがない。この隙間を埋める設計は二つあり、違いは最終的に何を運用するかにあって、クエリが通るかどうかではない。
トンネルが運ぶのはクエリであり、ゾーンの知識ではない
サイト間接続はパケットに二つのネットワーク間の経路を与える。どの名前空間がAzureに属し、どのアドレスが応答すべきかをオンプレミスのDNSサーバーに伝えるわけではない。そのためクエリはインターネットに出て空で戻るか、ローカルリゾルバーから出ないままになる。
修正は二つの半分に分かれ、切り分けは容易だ。一方はトンネル経由で届くクエリを受け付けるVNet内のリゾルバー。もう一方は、正確に一つの名前空間をそのリゾルバーへ送るオンプレミス側の条件付きフォワーダーだ。どちらか片方だけでは機能しない。
以降の説明ではゾーンをcloud.corp.exampleとし、アドレスはすべて例示とみなす。
選択肢A：マネージド受信エンドポイント
Azure DNS Private Resolverは、VNetの外から来るDNSクエリを受け付ける受信エンドポイントを提供する。専用の委任サブネットに配置し、プライベートゾーンをそのVNetにリンクし、サービスが割り当てる受信アドレスを控える。
次にオンプレミスのDNSサーバーで、正確な名前空間をそのアドレスへ向ける条件付きフォワーダーを作成する。
Namespace: cloud.corp.example
Forward to: 10.20.2.4MicrosoftのハイブリッドDNSの手順は、ゾーンのリンクとフォワーダーの手順の両方を文書化している。マネージド経路ではパッチを当てるDNSソフトウェアが残らず、エンドポイントのアドレスはリソースの存続期間中安定する。
代償は、リゾルバーリソース、そのサブネット委任、そのコストを抱えることだ。クエリ量がごく少なくても実際にかかる。
選択肢B：VNet内のフォワーダーVM
古い設計はVNet内の通常のVMでDNSソフトウェアを動かす。Windows DNS、BIND、dnsmasqなどで、プライベートゾーンをローカルにホストするか、168.63.129.16のAzureリゾルバーへ転送する。オンプレミスの条件付きフォワーダーはそのVMのプライベートアドレスを指す。
この選択肢はすでにDNSサーバーを運用しているチームには馴染みがあり、ログ記録やスプリットホライズン応答などの追加ロジックを載せられる。一方でDNSサーバーの運用作業をすべて引き継ぐ。パッチ適用、可用性のための二台目、監視、VMが置き換わってアドレスが変わったときの再構築手順だ。
通常のVNetホストは、サービスが導入され、それらのクライアントに応答する許可が与えられるまでDNSプロキシではない。VMを複製するときに飛ばされがちなのはこの手順だ。
どちらが運用に合うか
比較の軸はどちらが速いかではない。DNSソフトウェアを運用したいのか、クエリ量がエンドポイント単位とクエリ単位で課金されるマネージドリソースに見合うのか、という点だ。
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
どちらの行で決まっても、オンプレミス側のフォワーダー規則は同じ形になる。両設計に必ず存在すべき部分であり、Azure内からは解決できるがオフィスからはできないという報告で最も欠けやすい部分だ。
経路を順に確認する
ゾーンがリゾルバーを持つVNetにリンクされていること、オンプレミスのフォワーダーが親ドメインではなく名前空間を指定していることを確認する。corp.example向けのフォワーダーは、リゾルバー自身が委任しない限りcloud.corp.exampleに一致せず、その不一致はレコード欠落に見えるきれいな否定応答を生む。
次にクエリがエンドポイントに届くか確認する。オンプレミスの送信元にはリゾルバーアドレスへの経路と戻り経路が必要で、ポリシーが許す場所ではUDPとTCPの両方の53番ポートを許可すべきだ。NSGは欠けたゾーンレコードを補えず、正しいゾーンも届かないクエリには応答できない。
診断時は要求したFQDNを選んだリゾルバーの横に置き、タイムアウトと否定応答を切り分ける。タイムアウトは経路かポリシーの問題だ。否定応答はクエリが届き、名前空間が一致しなかったという意味だ。作業順序は、ゾーンをリンクし、条件付きフォワーダーを追加し、53番ポートを両方向に開け、オンプレミスから一つの名前を試し、その後で初めてアプリケーション自身の認可を見る。