Wer in Azure heute noch klassische DNS-Forwarder-VMs betreibt, macht sich unnötig Arbeit. In vielen Tenants ist der Azure DNS Private Resolver längst die bessere Wahl. Er braucht keine Wartung, ist hochverfügbar und bringt Funktionen mit, die man im Unternehmensumfeld wirklich benötigt. Trotzdem erlebe ich in Projekten immer wieder Unsicherheit, sobald alte DNS-Umgebungen abgelöst werden sollen. Unklar ist dann meist, welche Subnetze man braucht und wie die Weiterleitung in beide Richtungen funktioniert, gerade bei Private-Link-Zonen. Und natürlich, woran die Umsetzung in der Praxis häufig scheitert.

Der Private Resolver gehört mit zwei delegierten Subnetzen in den Hub

Den Azure DNS Private Resolver platziert man üblicherweise im Hub-VNet, nicht in jedem einzelnen Spoke. Dieses zentrale Design spart Konfigurationsaufwand und Kosten, weil jeder Resolver eigene, dedizierte Subnetze benötigt. Für den Betrieb braucht er zwei getrennte Subnetze. Das eine nimmt die Inbound-Endpoints auf, also Anfragen aus anderen Netzen wie dem On-Premises-Netz. Das andere ist für die Outbound-Endpoints gedacht, über die Azure-Ressourcen DNS-Abfragen in Richtung On-Premises oder an externe Ziele schicken. Beide Subnetze müssen im VNet als dediziert gekennzeichnet und an den Dienst delegiert sein, sonst schlägt die Bereitstellung fehl. Stehen die Subnetze erst einmal, ist der Resolver schnell angelegt.

Erfahrungstipp: Das Subnetz muss vorab an „Microsoft.Network/dnsResolvers“ delegiert werden. Ohne diese Delegation bricht der Rollout mit einer Fehlermeldung ab, die kaum weiterhilft.

In Hub-Spoke-Topologien kann das Routing schnell knifflig werden. Die Resolver-Subnetze gehören deshalb in den zentralen Hub, damit alle Spokes sie erreichen, ebenso das On-Premises-Netz über VPN/ExpressRoute. Wer hier spart, bezahlt später mit DNS-Fehlern, deren Ursache sich nur mühsam finden lässt.

Der Inbound Endpoint macht Private-Link-Zonen für On-Premises erreichbar

Viele Unternehmen lösen Azure-Private-Link-Zonen wie privatelink.database.windows.net über Conditional Forwarder auf ihren lokalen DNS-Servern auf. Bevor der Resolver eingeführt wird, treffe ich oft auf einen Flickenteppich aus mehreren DNS-Forwarder-VMs, manchmal sogar mit NAT oder fehlerhaftem Routing. Mit dem Azure DNS Private Resolver stellt man stattdessen einen Inbound Endpoint im Hub-VNet bereit. Er bekommt eine private IP-Adresse, die in der On-Premises-DNS-Konfiguration als Ziel der Conditional Forwarder eingetragen wird.

Die Einrichtung selbst ist unkompliziert. Im Resolver legt man einen Inbound Endpoint an und gibt ihm die gewünschte IP-Adresse aus dem dedizierten Subnetz. Danach tragen die lokalen DNS-Server diese IP als Forwarder für die betreffenden Zonen ein. Die Auflösung läuft anschließend über den Hub in Azure DNS, Private-Link-Zonen eingeschlossen. Das Prinzip erklärt die offizielle Dokumentation. In der Praxis lohnt sich vor allem ein genauer Blick auf die Firewall-Regeln, denn von den On-Premises-DNS-Servern zum Endpoint muss UDP/TCP 53 offen sein.

Outbound Endpoint und Forwarding Ruleset leiten Anfragen nach On-Premises weiter

Der umgekehrte Weg von Azure nach On-Premises ist genauso wichtig. Dafür legt man einen Outbound Endpoint an, ebenfalls im dedizierten Subnetz des Hubs. Mit einem Forwarding Ruleset bestimmt man dann sehr genau, welche DNS-Zonen an welche lokalen DNS-Server gehen. So lässt sich etwa die Zone „contoso.local“ gezielt an die On-Premises-Server weiterleiten, während Azure DNS alle übrigen Anfragen direkt auflöst. Die Bastelei mit Custom DNS oder VNet-übergreifender Weiterleitung fällt damit weg, und die Steuerung liegt sauber an einer zentralen Stelle. Einzelheiten stehen in der Dokumentation zu Endpoints und Rulesets.

Bei der Migration alter DNS-Forwarder-VMs sehe ich oft Fehler, wenn das Ruleset den VNets zugewiesen wird oder das Routing zwischen Spokes und Hub eingerichtet wird. Stimmt das Routing nicht oder sind die Ports von den Spokes zum Outbound Endpoint geschlossen, kommen die Anfragen nie an. Ein Test mit Azure Network Watcher deckt solche Blockaden schnell auf.

Ein Diagramm zeigt beide Richtungen auf einen Blick

Vor der Migration hilft eine einfache Skizze, um das Zusammenspiel zu verstehen. Im Diagramm unten nutzt das On-Premises-Netz den Inbound Endpoint als Ziel für die Conditional Forwarder, während der Outbound Endpoint Anfragen aus Azure an die lokalen DNS-Server weitergibt.

flowchart LR
    OnPrem["On-Prem DNS-Server"] --> Inbound["Inbound Endpoint (Hub-VNet)"]
    Inbound --> AzurePrivateDNS["Private Link Zone"]
    AzureVM["Azure VM (Spoke)"] --> Outbound["Outbound Endpoint (Hub-VNet)"]
    Outbound --> OnPrem

Abbildung: Azure DNS Private Resolver mit Inbound und Outbound Endpoint in einer Hub-Spoke-Topologie.

Die Kosten relativieren sich schnell, die Fehler stecken meist im Netzwerk

Die laufenden Kosten des Azure DNS Private Resolver schrecken viele zunächst ab. Verglichen mit eigenen DNS-VMs sieht die Rechnung aber schnell anders aus. Patches und Wartung entfallen, ein eigener Hochverfügbarkeits-Cluster ebenso, und SLA sowie Support kommen direkt von Microsoft. Unternehmen, die mehrere DNS-Forwarder-VMs betreiben, oft mit DNS-Load-Balancing oder Failover, haben nach meiner Beobachtung mehr Aufwand und höhere Kosten als mit dem Cloud-Dienst. Die häufigsten Stolpersteine sind die Anforderungen an die Subnetze und deren Delegation. Dazu kommen fehlerhafte Routing-Tabellen, durch die der Endpoint aus dem On-Premises-Netz oder aus den Spokes nicht erreichbar ist.

Wer in Azure mit Private Endpoints arbeitet, sollte auch meinen Artikel zu DNS-Fallstricken bei Private Endpoints lesen, denn viele Fehlerquellen ähneln sich.

Mit sauberer Planung ersetzt der Resolver alte DNS-VMs zuverlässig

Der Azure DNS Private Resolver hat die Arbeit mit DNS in Cloud- und Hybridumgebungen in den letzten Jahren deutlich vereinfacht. Wer gründlich plant und die Subnetze passend anlegt, bekommt eine hochverfügbare DNS-Integration zwischen On-Premises, Azure und Private Link, die keine Wartung braucht. Wichtig sind dabei vor allem Delegation und Routing. Die typischen Fehler lassen sich mit Checklisten und einfachen Tests vermeiden: Meist fehlt die Delegation, die Routing-Tabellen stimmen nicht oder jemand hat die Portfreigaben vergessen. In neuen Azure-Umgebungen setze ich den Resolver inzwischen standardmäßig ein, und für mich ist er einer der besten Wege, alte DNS-VMs endlich loszuwerden.