Azure Hybrid DNS

Private Endpoints sind essenziell, um Ressourcen sicher in Azure bereitzustellen. Sie sind einfach zu erstellen und funktionieren. Subnet auswählen, DNS Zone verknüpfen, Konfiguration abschließen. Innerhalb von Sekunden funktioniert die Namensauflösung in der Regel unmittelbar.

Die Komplexität steig mit der Anbindung von On-Premises-Umgebungen. Hier entseht oft der Punkt bei dem kein zentraler und vor allem skalierbarer Ansatz entsteht. Hier kann es dann vor allem bei der Zusammenarbeit mehrer Teams und keinem festen vorgehen zu Problemen kommen. Bei denen die Namensauflösung nicht wie gewünscht funktioniert.

Denn wie wir alle wissen. Es ist DNS. Immer DNS.

Ausgangssituation

Die Ausgangssituation ist eine hybride Umgebung mit Domain Controllern als DNS Server On-Premises und in Azure.

  • On-Premises Domain Controller fungieren als zentrale DNS Server für interne Clients
  • In Azure stehen zusätzliche Domain Controller bereit
  • Die Verbindung der Standorte erfolgt über VPN oder ExpressRoute
  • Ziel ist, dass On-Prem Clients PaaS Ressourcen in Azure über Private Endpoints per DNS korrekt auflösen können

Zielbild: Weniger Konfiguration, mehr Kontrolle

Nachfolgend werde ich einmal den Flow der gezeigten Architektur genauer erklären. Die Idee des ganzen ist einfach:

  • On-Prem DNS Server wissen nur, wohin sie bestimmte Namen schicken müssen
  • Azure DNS Infrastruktur erledigt den Rest
  • Private DNS Zones bleiben zentral in Azure gepflegt

Das reduziert Aufwand.

Der Ablauf

In diesem Beispiel möchte ein Client einen Azure File Share über einen Private Endpoint erreichen.

Der Name lautet zum Beispiel:
storageaccount.privatelink.file.core.windows.net

Und jetzt passiert Folgendes.

1. Client-Anfrage an DNS Server

Die VM On-Prem fragt ihren konfigurierten DNS Server. Meist ein Domain Controller.

2. Der On-Prem DC

Die Zone existiert nicht in der Domäne. Also greift die Conditional Forwarder Regel.

Konfiguriert ist:
privatelink.file.core.windows.net → Domain Controller in Azure

Das ist der erste wichtige Punkt. Nicht ein einzelner FQDN wird weitergeleitet. Nur die gewünschte Zone

2.1 Zusatzinfo Azure Firewall

Wenn eine Azure Firewall der SKU Standard oder höher bereitgestellt ist und die DNS Proxy Funktion genutzt wird, sollte im Conditional Forwarder die private IP der Firewall und nicht die der Domain Controller angegeben werden.

3. Der Cloud Domain Controller übernimmt

Jetzt landet die Anfrage bei den DNS Servern in Azure.

Diese Cloud DCs haben keinen individuellen Eintrag pro Private DNS Zone. Stattdessen haben sie einen generellen Forwarder:

168.63.129.16

Das ist die virtuelle Azure DNS IP. So etwas wie der stille Backbone für Namensauflösung innerhalb von Azure.

Das bedeutet:

Die Cloud DCs müssen keine Details kennen. Sie geben einfach weiter. Azure erledigt die Auflösung anhand der verknüpften Private DNS Zones.

Wichtig dabei: Root Hints sollten auf den Cloud DCs deaktiviert werden.
So wird verhindert, dass Anfragen ins Internet abfließen oder öffentliche Antworten zurückkommen.
Das reduziert das Risiko von Datenabfluss, vermeidet inkonsistente Auflösungen und stellt sicher, dass ausschließlich der definierte DNS-Pfad genutzt wird.

4. Azure DNS liefert die Antwort

Die Anfrage trifft auf die Private DNS Zone:

privatelink.file.core.windows.net

Dort liegt der A Record für den Private Endpoint.

Antwort geht zurück:

Azure DNS → Cloud DC → On-Prem DC → Client

Zusammenfassung

Auf On-Prem Seite wird nur ein Conditional Forwarder pro Zone gebraucht.

Keine einzelnen Records. Keine Kopien. Keine Synchronisation.

Zentrale Wahrheit in Azure

Alle Private Endpoint Einträge liegen in Azure. Keine Einträge für einzelne FQDNs in der Domäne.

Das Onboarding neuer Zonen für Private Endpoints ist superleicht.
Neue Zone für Blob oder Key Vault?

On-Prem Conditional Forwader hinzufügen:

privatelink.blob.core.windows.net
oder
privatelink.vaultcore.azure.net

Fertig.