Bei Private Endpoints in Azure scheitert die Verbindung meist am DNS

Wer in Azure mit Private Endpoints arbeitet – und das gehört inzwischen in fast jedem ernsthaft betriebenen Tenant dazu –, muss sich früher oder später mit DNS auseinandersetzen. In vielen Umgebungen sehe ich dasselbe Bild: Anfangs freuen sich alle über den privaten Zugriff, doch sobald es um DNS für Private Endpoints geht, ist die Stimmung schnell dahin. Anwendungen laufen plötzlich nicht mehr, nslookup liefert weiterhin öffentliche IP-Adressen, und die Fehlersuche zieht sich. Die Private Endpoints selbst sind dabei selten schuld. Fast immer hakt es an den privaten DNS-Zonen, an den Resolvern oder an der Anbindung des lokalen Netzes.

Private DNS-Zonen gehören zentral in den Hub und nicht in jeden Spoke

Der erste Fehler passiert meist schon beim Anlegen der privaten DNS-Zonen, etwa privatelink.blob.core.windows.net. Viele erstellen diese Zone ohne viel Nachdenken in jedem Spoke-VNet, manchmal sogar mehrfach. Die Namensauflösung ist dann uneinheitlich oder schlicht falsch. Besser fährt man, wenn die Zone zentral im Hub-VNet liegt und mit allen relevanten VNets verknüpft ist. Nur dann bekommen sämtliche Ressourcen, die Private Endpoints nutzen, dieselben DNS-Antworten. Die Grundlagen hat Microsoft auf dieser Seite übersichtlich zusammengestellt.

Oft übersehen wird, dass die private DNS-Zone mit jedem VNet verknüpft sein muss, aus dem Clients auf die privaten Ressourcen zugreifen. Legt man Zonen nur im Spoke an oder verlinkt sie nicht sauber, löst zum Beispiel eine VM im benachbarten Spoke auf einmal falsche oder gar keine IPs auf. Regelmäßig treffe ich auf Umgebungen mit doppelten privaten DNS-Zonen in mehreren VNets, meist Überbleibsel früherer Tests. Das Ergebnis ist jedes Mal gleich: widersprüchliche DNS-Antworten und Fehler, die sich nur mühsam finden lassen.

Der Azure DNS Private Resolver im Hub übernimmt die zentrale Auflösung

In aktuellen Hub-and-Spoke-Architekturen steuert man die DNS-Auflösung heute meist zentral über den Azure DNS Private Resolver. Er beantwortet Anfragen aus der Cloud genauso zuverlässig wie solche aus dem lokalen Netzwerk. Entscheidend sind dabei die Inbound- und Outbound-Endpunkte. Über den Inbound-Endpunkt leiten On-Premises-DNS-Server ihre Anfragen an Azure weiter, zum Beispiel über ein Site-to-Site-VPN oder ExpressRoute. Die Outbound-Endpunkte wiederum erlauben es, aus Azure heraus interne, nicht öffentliche Zonen aufzulösen, etwa lokale AD-Domänen. Welche Möglichkeiten es im Einzelnen gibt, beschreibt Microsoft in dieser Übersicht.

Voraussetzung ist, dass der DNS-Resolver im Hub steht und alle Spokes ihre DNS-Anfragen über einen Forwarder dorthin schicken. Im On-Premises-AD legt man anschließend für die privaten Azure-Zonen eine bedingte Weiterleitung (Conditional Forwarder) an, die auf die IP des Inbound-Endpunkts zeigt. Ist das sauber eingerichtet, funktioniert die Namensauflösung auch über Standortgrenzen hinweg, und nslookup gibt im Rechenzentrum keine öffentlichen IPs mehr zurück.

Öffentliche IPs in nslookup deuten fast immer auf ein Zonenproblem hin

In Projekten begegnet mir immer wieder folgende Situation: Die Umstellung auf Private Endpoints ist erledigt, aber nslookup meldet nach wie vor die öffentliche IP. Das passiert typischerweise, wenn die private DNS-Zone nur in einem Spoke existiert oder nie mit dem richtigen VNet verknüpft wurde. Von einer Azure-VM aus lässt sich das schnell prüfen:

nslookup storageaccountname.blob.core.windows.net

Erscheint hier eine öffentliche IP, obwohl ein Private Endpoint existiert, ist die DNS-Integration fehlerhaft. Dahinter steckt fast immer eine fehlende oder falsch verknüpfte private DNS-Zone. Richtig unangenehm wird es, wenn es die Zone mit gleichem Namen in mehreren VNets gibt. Je nach Standort der VM erhält man dann mal die richtige und mal die falsche Antwort, ein Klassiker unter den Fehlerquellen.

Aus Erfahrung: Am besten immer eine zentrale Zone anlegen und jede Änderung, auch Testzugänge, sauber dokumentieren. Schon eine nicht mehr verknüpfte „Leiche“ einer alten DNS-Zone kann die gesamte Auflösung in einer Subscription aushebeln.

Azure Policies nehmen in Landing Zones die Zonenverwaltung ab

In größeren Umgebungen mit vielen Landing Zones sollte das Anlegen und Verknüpfen privater DNS-Zonen nicht vom Zufall abhängen. Dafür eignen sich Azure Policies. Mit ihnen lässt sich erreichen, dass beim Anlegen eines Private Endpoints automatisch der passende DNS-Eintrag entsteht und die Zone richtig verknüpft wird. Das nimmt den Operations-Teams Arbeit ab und vermeidet Flüchtigkeitsfehler. Im Cloud Adoption Framework hat Microsoft brauchbare Templates und Beispiele für die Integration in großen Umgebungen veröffentlicht. In meinen Projekten gehört das längst zum Standard, und wer schon einmal unkontrolliert wuchernde DNS-Zonen aufräumen musste, versteht den Grund. Wie zentrale Governance und Policy-basierte Kontrolle grundsätzlich funktionieren, lest ihr in meinem Beitrag zu Azure Landing Zones.

Public Network Access und Netzwerk-Policies brauchen nach der Umstellung Aufmerksamkeit

Läuft der Zugriff vollständig über Private Endpoints, sollte man den Public Network Access an den Azure-Ressourcen aus Sicherheitsgründen ganz abschalten. Genau das bleibt häufig liegen, und so bleibt eine unnötige Angriffsfläche offen, obwohl ein einziger Schalter im Portal genügt. Außerdem lohnt sich ein Blick darauf, wie Network Security Groups (NSG) und User Defined Routes (UDR) auf den Subnetzen mit Private Endpoints greifen. Die Netzwerk-Policies für Private Endpoints sind standardmäßig deaktiviert. Wer auf NSG- und UDR-Ebene granular steuern will, muss sie ausdrücklich aktivieren.

Das folgende einfache Diagramm zeigt, wie die einzelnen Komponenten zusammenarbeiten:

flowchart TD
    OnPremises["On-Premises DNS"] --> ConditionalForwarder["Conditional Forwarder"]
    ConditionalForwarder --> InboundEndpoint["Azure DNS Private Resolver (Inbound)"]
    InboundEndpoint --> AzurePrivateDNS["Private DNS Zone"]
    SpokeVM["Spoke VM"] --> HubDNS["Hub DNS Forwarder"]
    HubDNS --> OutboundEndpoint["Azure DNS Private Resolver (Outbound)"]
    OutboundEndpoint --> AzurePrivateDNS
    AzurePrivateDNS --> PrivateEndpoint["Private Endpoint"]
    PrivateEndpoint --> AzureResource["Azure Resource"]

Abbildung: Zentrale DNS-Auflösung für Private Endpoints über den DNS Private Resolver im Hub.

Sauberes DNS ist bei Private Link die halbe Miete

Hinter vielen spektakulären Azure-Ausfällen, die ich in den vergangenen Jahren miterlebt habe, steckten im Kern simple DNS-Probleme mit großer Wirkung. Gerade beim DNS für Private Endpoints reicht eine kleine Unachtsamkeit, um stundenlange Ausfälle oder Sicherheitslücken zu verursachen. Ich empfehle deshalb, die Architektur gründlich zu dokumentieren, Zonen und Resolver zentral zu steuern und Testsysteme nicht dauerhaft im Produktivbetrieb weiterlaufen zu lassen. Wer sich daran hält, wird mit Private Link auf Dauer zufrieden sein.