Die VPN-Verbindung steht, das Routing stimmt, die Firewall lässt durch — und trotzdem erreicht niemand aus dem Rechenzentrum die neue Datenbank in Azure. Meist liegt es nicht am Netz, sondern daran, dass zwei DNS-Welten nichts voneinander wissen.

Zwei Namensräume, die sich nicht kennen

On-prem steht in aller Regel ein Windows-DNS am Domaincontroller. Er ist autoritativ für die interne Zone, sagen wir corp.example.com, und leitet alles Übrige an einen Forwarder ins Internet weiter.

In Azure gibt es Private DNS Zones. Das sind vollwertige DNS-Zonen, die aber ausschließlich innerhalb der virtuellen Netze existieren, mit denen sie über einen Virtual Network Link verbunden sind. Aufgelöst werden sie über den plattformeigenen Resolver unter 168.63.129.16 — eine Adresse, die jede VM in jedem VNet erreicht.

Und genau hier liegt das Problem: 168.63.129.16 ist von on-prem aus nicht erreichbar. Nicht über VPN, nicht über ExpressRoute. Die Adresse ist nur aus dem VNet heraus gültig. Ein Conditional Forwarder auf dem Windows-DNS, der stumpf dorthin zeigt, läuft ins Leere.

Delegation oder Conditional Forwarding?

Bevor es an Azure geht, lohnt die saubere Unterscheidung — die beiden Mechanismen werden oft in einen Topf geworfen, obwohl sie auf verschiedenen Ebenen arbeiten.

Bei einer Delegation gibt eine Zone die Verantwortung für einen Teilbereich ab. In der Zone example.com stehen NS-Einträge für azure.example.com, die auf andere Nameserver zeigen. Das ist Teil der DNS-Daten selbst: Jeder, der die Kette von der Wurzel abwärts verfolgt, landet bei denselben Servern. Delegation ist autoritativ und global gültig.

Beim Conditional Forwarding entscheidet dagegen ein einzelner Resolver, wohin er Anfragen für eine bestimmte Zone schickt. Das steht in keiner Zonendatei, sondern in der Konfiguration dieses einen Servers. Wer ihn nicht befragt, weiß nichts davon. Conditional Forwarding ist reine Wegewahl, nicht Autorität.

Die Faustregel: Delegation, wenn die Zielserver öffentlich auffindbar sein sollen. Conditional Forwarding, wenn nur die eigenen Resolver den Weg kennen müssen.

Warum Delegation nach Azure nicht funktioniert

Für Azure Private DNS Zones scheidet Delegation aus, und zwar grundsätzlich. Eine Delegation braucht NS-Einträge, die auf erreichbare Nameserver zeigen. Private Zones haben aber keine eigenen Nameserver — sie sind kein Dienst mit IP-Adresse, den man eintragen könnte, sondern eine Datenhaltung, die der Plattform-Resolver eines verknüpften VNets ausliest.

Es gibt schlicht nichts, worauf ein NS-Eintrag zeigen könnte. Damit bleibt für den Weg von on-prem nach Azure nur das Conditional Forwarding — und ein Ziel, das von on-prem aus erreichbar ist.

Der DNS Private Resolver

Früher stellte man dafür eine VM ins VNet, installierte einen DNS-Dienst darauf und ließ ihn nach 168.63.129.16 weiterleiten. Das funktionierte, hatte aber alle Nachteile einer VM: Patchen, Verfügbarkeit, Lizenz, Monitoring — für einen Dienst, der nichts weiter tut als Anfragen durchzureichen.

Der Azure DNS Private Resolver ersetzt diese Konstruktion durch einen verwalteten Dienst. Er wird in ein VNet ausgerollt und besteht aus zwei Teilen, die man getrennt betrachten sollte, weil sie in entgegengesetzte Richtungen arbeiten.

Inbound Endpoint — von on-prem nach Azure

Der Inbound Endpoint bekommt eine private IP-Adresse aus einem eigenen Subnetz des VNets. Diese Adresse ist über VPN oder ExpressRoute von on-prem aus erreichbar. Der Windows-DNS im Rechenzentrum bekommt einen Conditional Forwarder auf diese IP — und löst darüber alles auf, was in den verknüpften Private DNS Zones steht.

Outbound Endpoint — von Azure nach on-prem

Die Gegenrichtung läuft über den Outbound Endpoint zusammen mit einem DNS Forwarding Ruleset. Das Ruleset enthält Regeln nach dem Muster „Zone → Ziel-DNS-Server" und wird mit einem oder mehreren VNets verknüpft. Eine Regel für corp.example.com mit den IP-Adressen der Domaincontroller sorgt dafür, dass VMs in Azure interne Namen auflösen können.

Beide Endpunkte brauchen jeweils ein eigenes Subnetz, das an Microsoft.Network/dnsResolvers delegiert ist. Die Subnetze lassen sich nicht mit anderen Ressourcen teilen, und ein /28 ist die kleinste zulässige Größe. Das plant man besser gleich zu Beginn ein, statt später ein produktives VNet umzubauen.

Der praktische Aufbau

Für eine typische Hub-and-Spoke-Umgebung sieht die Aufteilung so aus:

Private Resolver im Hub-VNet
  Inbound  Endpoint  →  10.0.10.4   (Subnetz 10.0.10.0/28)
  Outbound Endpoint  →              (Subnetz 10.0.11.0/28)

On-prem Windows-DNS
  Conditional Forwarder
    privatelink.database.windows.net  →  10.0.10.4
    privatelink.blob.core.windows.net →  10.0.10.4

DNS Forwarding Ruleset, verknüpft mit Hub und Spokes
    corp.example.com  →  10.50.1.10, 10.50.1.11

Die Spoke-VNets brauchen keinen eigenen Resolver. Sie behalten ihre DNS-Einstellung auf „Azure-provided" und bekommen die Weiterleitung über die Ruleset-Verknüpfung. Die Private DNS Zones werden mit allen VNets verknüpft, die darin auflösen sollen.

Private Link und die privatelink-Zonen

Der häufigste Anlass für den ganzen Aufwand sind Private Endpoints. Legt man einen Private Endpoint für eine Azure-SQL-Datenbank an, entsteht ein A-Record in der Zone privatelink.database.windows.net, der auf die private IP zeigt.

Der Trick dabei steckt im öffentlichen DNS. Der reguläre Name der Datenbank löst öffentlich nicht direkt auf eine Adresse auf, sondern über einen CNAME:

meinedb.database.windows.net
   → CNAME meinedb.privatelink.database.windows.net
        → A  10.0.20.5      (aus der Private DNS Zone)
        → A  20.x.x.x       (öffentlich, ohne Private DNS Zone)

Wer die private Zone auflösen kann, bekommt die interne Adresse. Wer nicht, bekommt die öffentliche. Deshalb muss der Conditional Forwarder on-prem exakt auf die privatelink.*-Zonen zeigen — der CNAME führt von allein dorthin.

Wichtig: Weitergeleitet wird nur die privatelink-Zone, niemals database.windows.net oder gar core.windows.net als Ganzes. Sonst schickt man auch alle öffentlichen Auflösungen dieser Dienste durch den Resolver — mit unnötiger Abhängigkeit und schwer zu findenden Ausfällen, sobald die Verbindung nach Azure einmal steht.

Stolpersteine

Gleiche Zone auf beiden Seiten. Existiert corp.example.com sowohl on-prem als auch als Private DNS Zone, entscheidet der zufällig befragte Resolver, welche Antwort kommt. Solche Split-Brain-Konstruktionen erzeugen Fehler, die je nach Standort des Clients auftreten oder eben nicht. Besser ist eine eigene Subdomain für Azure, etwa az.corp.example.com.

Weiterleitungsschleifen. Wenn das Ruleset corp.example.com nach on-prem schickt und der dortige DNS dieselbe Zone zurück nach Azure leitet, kreisen die Anfragen. Jede Zone gehört genau einer Seite, und die andere fragt dort nach — nicht umgekehrt.

Zu breite Regeln. Eine Regel für . oder für ganze Anbieter-Domains im Ruleset macht den Resolver zum Single Point of Failure für sämtliche Namensauflösung. Regeln so eng wie möglich fassen.

Vergessene VNet-Verknüpfungen. Sowohl Private DNS Zones als auch das Ruleset wirken nur in verknüpften VNets. Ein neues Spoke, das niemand verknüpft hat, löst plötzlich öffentlich auf — und verbindet sich über das Internet statt über den Private Endpoint. Das fällt oft erst bei einem Security-Review auf.

Region. Der Private Resolver lebt in derselben Region wie sein VNet. Für mehrere Regionen braucht es entsprechend mehrere Resolver oder eine bewusste Entscheidung, den Umweg in Kauf zu nehmen.

Was hängen bleiben sollte

Delegation und Conditional Forwarding lösen unterschiedliche Aufgaben: Die eine verteilt Autorität, die andere nur den Weg zur Frage. Für Azure Private DNS Zones gibt es keine Autorität zum Verteilen — deshalb bleibt nur die Weiterleitung, und sie braucht ein Ziel, das von on-prem aus erreichbar ist.

Genau dieses Ziel liefert der Inbound Endpoint des DNS Private Resolver. Der Outbound Endpoint mit seinem Ruleset macht die Gegenrichtung auf. Beides zusammen ist heute der vorgesehene Weg — und deutlich weniger Arbeit als die DNS-Forwarder-VM, die man dafür früher gepflegt hat.