Private Endpoints: DNS-Stolperfallen

Warum DNS bei Private Endpoints fast immer das eigentliche Problem ist

Ein Private Endpoint macht einen PaaS-Dienst (z. B. Storage, Key Vault) über eine private IP im VNet erreichbar. Damit das funktioniert, muss der Dienstname (FQDN) auf diese private IP auflösen.

Wenn der Name weiter auf die öffentliche IP zeigt, ist der Endpoint “da” – aber die Anwendung landet am falschen Ziel (oder scheitert, wenn Public Access deaktiviert wurde).

Grundprinzip: FQDN → private IP

Die übliche Kette:

Dienst hat einen bekannten FQDN (z. B. *.vault.azure.net, *.blob.core.windows.net).
Private Endpoint erzeugt (optional) passende DNS Records in einer Private DNS Zone.
Das VNet muss mit der Private DNS Zone verknüpft sein (VNet Link).
Clients im VNet (oder via Hybrid DNS Forwarding) müssen diese Zone auch wirklich abfragen.

Konkrete Zone-Namen (häufige Services)

In der Praxis scheitert DNS oft daran, dass “die falsche” Zone gebaut oder geforwardet wird. Häufige Private-Link-Zonen:

Key Vault: privatelink.vaultcore.azure.net
Storage Blob: privatelink.blob.core.windows.net
Storage File: privatelink.file.core.windows.net
Storage Queue: privatelink.queue.core.windows.net
Storage Table: privatelink.table.core.windows.net
Azure SQL: privatelink.database.windows.net

Je nach Dienst gibt es weitere Varianten (Region/Service-spezifisch). Entscheidend ist: Der Client muss am Ende eine private IP bekommen.

CNAME-Kette verstehen (warum “es sieht richtig aus” trotzdem falsch sein kann)

Viele Azure-Dienste arbeiten mit CNAMEs. Typischer Effekt:

Der “öffentliche” Name bleibt gleich.
Die DNS-Antwort zeigt auf einen privatelink-Namen.
Erst dieser privatelink-Name wird in der Private DNS Zone auf die private IP aufgelöst.

Wenn du nur den ersten Schritt prüfst, wirkt DNS “okay” – bis du feststellst, dass die privatelink-Zone nicht erreichbar ist.

Häufige Stolperfallen (mit Diagnosehinweisen)

1) Private DNS Zone ist nicht (richtig) verlinkt

Symptom: Auflösung liefert eine öffentliche IP.

Check:

Existiert die passende Private DNS Zone für den Service?
Gibt es einen VNet Link zum VNet des Clients?
Liegt der Client ggf. in einem anderen VNet (Peering) und braucht ebenfalls einen Link?

2) Custom DNS Server kennt die Private DNS Zone nicht

Symptom: Portal-Test/VM in Azure funktioniert, On-Prem oder via eigener DNS-Infrastruktur nicht.

Ursache: Eigener DNS forwardet nicht korrekt zu Azure (oder ignoriert Conditional Forwarders).

Bewährte Optionen:

Azure Private DNS Resolver (Inbound/Outbound) als klaren Integrationspunkt nutzen.
Conditional Forwarder auf die Resolver-IP(s) setzen, getrennt nach Zonen.

3) Split-Horizon ist unvollständig

Symptom: Einige Clients lösen korrekt auf, andere nicht; oft abhängig vom Netzwerkpfad.

Ursache: Unterschiedliche DNS-Server/Forwarder je Segment.

Gegenmaßnahme: DNS-Pfade vereinheitlichen und dokumentieren. Private Endpoint ohne konsistentes DNS-Design skaliert schlecht.

4) Private Endpoint existiert, aber Ziel ist nicht erreichbar

Symptom: DNS zeigt private IP, aber Verbindungen scheitern.

Typische Ursachen:

NSGs/UDRs/Firewall blockieren den Pfad.
Private Endpoint liegt in einem Subnet mit unerwarteten Restriktionen.
Client nutzt Proxy/Firewall-Regeln, die den privaten Pfad nicht erlauben.

Best Practices

Pro Service-Kategorie die passende Private DNS Zone sauber etablieren (kein Wildwuchs pro Team).
VNet Links bewusst verwalten (wer darf welche Zonen konsumieren?).
Hybrid: DNS-Forwarding explizit planen, nicht “später”.
Wenn Public Access deaktiviert wird: zuerst DNS/Connectivity sauber verifizieren.

Diagnose-Quickwins (Tools)

Wenn du schnell Klarheit brauchst, prüfe (je nach Client):

Linux/macOS: dig <fqdn> und dig <privatelink-fqdn>
Windows: Resolve-DnsName <fqdn>
Allgemein: testen mit dem DNS-Server, den der Client wirklich nutzt (nicht “irgendein” Resolver)

Und immer mit Kontext: gleiche Abfrage aus VNet-VM, aus On-Prem und ggf. aus einem peered VNet.

Quick-Check für incident response

Welcher FQDN wird tatsächlich verwendet?
Von wo wird abgefragt (VNet, On-Prem, Client-Segment)?
Welche IP kommt zurück (private vs public)?
Ist der Netzwerkpfad zur privaten IP offen?

Wenn du ein konkretes Symptom debuggen willst, ist auch Private Endpoint DNS nicht auflösbar hilfreich.