Skip to content
ViganoLabs Dokumentation

Private Endpoint DNS: nicht auflösbar

Symptom

Section titled “Symptom”

Ein Private Endpoint existiert, aber der Dienstname (FQDN) löst nicht auf die private IP auf. Je nach Setup siehst du:

  • Auflösung liefert eine öffentliche IP.
  • Auflösung schlägt komplett fehl (NXDOMAIN/timeout).
  • Unterschiedliche Ergebnisse je nach Standort (On-Prem vs Azure VNet).

Diagnosepfad

Section titled “Diagnosepfad”

1) Von wo testest du?

Section titled “1) Von wo testest du?”

DNS ist kontextabhängig. Kläre:

  • Client in Azure VNet (VM/Container)?
  • Client On-Prem?
  • Client über VPN/ER angebunden?

2) Welche DNS-Server werden genutzt?

Section titled “2) Welche DNS-Server werden genutzt?”
  • VNet: Azure-provided DNS oder Custom DNS?
  • On-Prem: welcher Resolver und welche Forwarder?

Quickwin: Teste gezielt gegen den Resolver, den der Client wirklich nutzt. Viele “DNS-Probleme” sind in Wahrheit “wir testen gegen den falschen Server”.

3) Private DNS Zone vorhanden und korrekt?

Section titled “3) Private DNS Zone vorhanden und korrekt?”

Checkliste:

  • Passende Private DNS Zone existiert (service-spezifisch).
  • A-Record(s) für den Private Endpoint vorhanden.
  • VNet Link zum Client-VNet vorhanden.

Wenn du peered VNets nutzt: Der Link muss zu jedem Client-VNet existieren, das den Dienst auflösen soll.

4) Hybrid: Forwarding stimmt?

Section titled “4) Hybrid: Forwarding stimmt?”

Wenn Custom DNS im Spiel ist:

  • Conditional Forwarder für die Private-Link-Zonen auf Azure Resolver/Private DNS Resolver.
  • Keine “catch-all” Weiterleitungen, die die Zone verschlucken.

5) Cache und Propagation

Section titled “5) Cache und Propagation”
  • DNS-Caches können Tests verfälschen.
  • Nach Änderungen: Cache flushen (Client/Resolver) und Zeit einplanen.

Häufige Ursachen

Section titled “Häufige Ursachen”
  • Private DNS Zone nicht verlinkt (oder nur mit dem “Endpoint-VNet”, nicht mit dem “Client-VNet”).
  • Custom DNS forwardet nicht zu Azure.
  • Split-Horizon unvollständig (unterschiedliche Resolverpfade pro Segment).

Wenn du es eingrenzen willst:

  • Liefert derselbe Query aus einer Azure-VM eine andere Antwort als On-Prem? → Forwarding/Resolver-Pfad.
  • Liefert ein peered VNet eine andere Antwort als das Endpoint-VNet? → fehlender VNet Link.

Weiterführend

Section titled “Weiterführend”