Privates DNS in Azure über VPN: Resolver-Endpunkt oder Forwarder
Beide Designs beantworten private Zonen über den Tunnel. Vergleichen Sie einen verwalteten eingehenden Endpunkt mit einer Forwarder-VM und prüfen Sie dann den Pfad, der in beiden Fällen vorhanden sein muss.
Ein Server im lokalen Netz erreicht eine Azure-VM über eine private Adresse und kann deren privaten Hostnamen trotzdem nicht auflösen, was dazu führt, dass man nach einem defekten Tunnel sucht. Der Tunnel ist in Ordnung. Es fehlt eine DNS-Grenze: Auf der lokalen Seite weiß niemand, dass eine bestimmte private Azure-Zone von einem Resolver innerhalb des VNet beantwortet werden muss. Zwei Designs schließen diese Lücke, und sie unterscheiden sich darin, was Sie am Ende betreiben, nicht darin, ob Abfragen funktionieren.
Der Tunnel transportiert Abfragen, kein Zonenwissen
Eine Site-to-Site-Verbindung gibt Paketen eine Route zwischen den beiden Netzen. Sie sagt dem lokalen DNS-Server nicht, welcher Namespace zu Azure gehört oder welche Adresse antworten soll, also geht die Abfrage entweder ins Internet und kommt leer zurück, oder sie verlässt den lokalen Resolver nie.
Die Lösung hat zwei Hälften, die sich leicht trennen lassen. Die eine Hälfte ist ein Resolver im VNet, der Abfragen annimmt, die über den Tunnel eintreffen. Die andere ist ein bedingter Forwarder auf der lokalen Seite, der genau einen Namespace an diesen Resolver schickt. Keine der Hälften funktioniert allein.
Nehmen Sie für den Rest dieser Anleitung an, die Zone sei cloud.corp.example, und behandeln Sie jede Adresse als illustrativ.
Option A: der verwaltete eingehende Endpunkt
Azure DNS Private Resolver stellt einen eingehenden Endpunkt bereit, der DNS-Abfragen von außerhalb des VNet annimmt. Sie stellen ihn in einem dedizierten delegierten Subnetz bereit, verknüpfen die private Zone mit diesem VNet und notieren die eingehende Adresse, die der Dienst zuweist.
Auf dem lokalen DNS-Server legen Sie dann einen bedingten Forwarder für den exakten Namespace auf diese Adresse an:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Die Hybrid-DNS-Prozedur von Microsoft dokumentiert sowohl die Zonenverknüpfung als auch den Forwarder-Schritt. Der verwaltete Weg hinterlässt keine DNS-Software zum Patchen, und die Endpunktadresse bleibt über die Lebensdauer der Ressource stabil.
Der Preis ist, dass Sie nun eine Resolver-Ressource, ihre Subnetzdelegierung und ihre Kosten besitzen, die auch bei winzigem Abfragevolumen real sind.
Option B: eine Forwarder-VM im VNet
Das ältere Design betreibt DNS-Software auf einer gewöhnlichen VM im VNet: Windows DNS, BIND oder dnsmasq, wobei die private Zone entweder lokal gehostet oder an den Azure-Resolver unter 168.63.129.16 weitergeleitet wird. Der lokale bedingte Forwarder zeigt auf die private Adresse dieser VM.
Diese Option ist Teams vertraut, die bereits DNS-Server betreiben, und sie kann zusätzliche Logik wie Protokollierung oder Split-Horizon-Antworten tragen. Sie erbt auch jede Betriebspflicht eines DNS-Servers: Patchen, eine zweite Instanz für Verfügbarkeit, Überwachung und einen Wiederaufbaupfad, wenn die VM ersetzt wird und sich ihre Adresse ändert.
Ein gewöhnlicher VNet-Host ist kein DNS-Proxy, bis der Dienst installiert ist und antworten darf, und genau diesen Schritt überspringt man beim Klonen einer VM.
Welches zu Ihrem Betrieb passt
Der Vergleich dreht sich nicht darum, welches Design schneller ist. Es geht darum, ob Sie überhaupt DNS-Software betreiben wollen und ob das Abfragevolumen eine verwaltete Ressource rechtfertigt, die pro Endpunkt und pro Abfrage abgerechnet wird.
| 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 |
Welche Zeile auch entscheidet, die Forwarder-Regel lokal sieht gleich aus. Das ist der Teil, der in beiden Designs existieren muss, und er fehlt am häufigsten, wenn jemand meldet, dass die Auflösung aus Azure heraus funktioniert, aber nicht aus dem Büro.
Prüfen Sie den Pfad der Reihe nach
Bestätigen Sie, dass die Zone mit dem VNet verknüpft ist, das den Resolver enthält, und dass der lokale Forwarder den Namespace und nicht eine übergeordnete Domäne nennt. Ein Forwarder für corp.example passt nicht auf cloud.corp.example, es sei denn, der Resolver delegiert selbst, und die Abweichung erzeugt eine saubere negative Antwort, die wie ein fehlender Eintrag aussieht.
Prüfen Sie dann, ob die Abfrage den Endpunkt erreicht: Die lokale Quelle braucht eine Route zur Resolver-Adresse und einen Rückweg, und sowohl UDP- als auch TCP-Port 53 sollten erlaubt sein, wo die Richtlinie es zulässt. Eine NSG kann keinen fehlenden Zoneneintrag liefern, und eine korrekte Zone kann keine Abfrage beantworten, die nie ankommt.
Halten Sie den angefragten FQDN neben dem gewählten Resolver, wenn Sie diagnostizieren, und trennen Sie eine Zeitüberschreitung von einer negativen Antwort. Eine Zeitüberschreitung ist ein Pfad- oder Richtlinienproblem. Eine negative Antwort bedeutet, dass die Abfrage ankam und der Namespace nicht passte. Reihenfolge: Zone verknüpfen, bedingten Forwarder hinzufügen, Port 53 in beide Richtungen öffnen, einen Namen vom lokalen Netz aus testen und erst dann die eigene Autorisierung der Anwendung prüfen.