DNS in der Cloud: Split-Horizon und Private DNS Troubleshooting

Red Snapper

2 months ago

DNS in der Cloud ist oft der unterschätzte Faktor, wenn Anwendungen „eigentlich erreichbar“ sein müssten, aber trotzdem Timeouts, falsche Ziel-IPs oder widersprüchliche Verbindungswege auftreten. Besonders in Hybrid- und Multi-Cloud-Umgebungen sind Split-Horizon DNS (auch Split-Brain DNS genannt) und Private DNS zentrale Bausteine, um interne Services sauber zu adressieren: Derselbe Hostname soll je nach Standort oder Netzwerksegment auf eine andere IP zeigen – zum Beispiel auf eine private Endpoint-IP innerhalb eines VNets/VPCs statt auf eine öffentliche IP im Internet. Genau hier entstehen die klassischen Fehlerbilder: On-Prem löst auf eine private IP auf, aber der Pfad zur Cloud fehlt. Ein Cloud-Client löst aus Versehen auf die öffentliche IP auf und läuft über den falschen Weg (oder wird durch Firewalls geblockt). Oder eine Private DNS Zone ist zwar vorhanden, aber nicht mit dem richtigen Netzwerk verknüpft, sodass nur bestimmte Subnetze/Spokes auflösen können. Dieser Leitfaden zeigt, wie Sie Split-Horizon und Private DNS systematisch troubleshoot’en – von den Grundlagen über typische Symptome bis hin zu einem praxiserprobten Workflow, der DNS-Fehler schnell und belegbar eingrenzt.

Warum DNS in Cloud-Umgebungen komplexer ist als „nur ein Nameserver“

In klassischen On-Prem-Netzen ist DNS oft zentral: Ein oder wenige Resolver, klare Zonen, meist eine eindeutige Antwort pro Name. In Cloud-Architekturen kommen mehrere Dimensionen hinzu:

Mehrere Resolver-Ebenen: Client-Resolver, VPC/VNet-Resolver, Forwarder, zentrale Unternehmensresolver, Provider-DNS.
Mehrere Routing-Domänen: Public Internet, Private Links/Endpoints, VPN/Peering/Transit, getrennte VRFs/VNets/VPCs.
Mehrere Identitäts- und Sicherheitslagen: DNS-Filter, DoH/DoT, Split-DNS für SSO, private Service Discovery.
Hoher Automatisierungsgrad: IaC-Änderungen können DNS-Verknüpfungen (Links/Associations) unbemerkt verschieben.

Die Konsequenz: DNS ist nicht nur „Namensauflösung“, sondern ein Steuerungsmechanismus für Pfade und Sicherheitsgrenzen. Wenn DNS falsch antwortet, kann Routing „korrekt“ sein und die Anwendung trotzdem scheitern – weil sie zur falschen IP geht.

Begriffe: Split-Horizon, Private DNS und Resolver-Modelle

Damit Troubleshooting schnell funktioniert, sollten die Begriffe sauber sitzen:

Split-Horizon DNS (Split-Brain): Derselbe Name liefert je nach Abfragequelle unterschiedliche Antworten (z. B. intern private IP, extern öffentliche IP).
Private DNS Zone: Eine Zone ist nur innerhalb definierter Netzwerke gültig (z. B. VPC/VNet-Links), oft für Private Endpoints/Services.
Resolver: Das System, das rekursiv auflöst (fragt Root/TLD/Authoritative ab oder forwardet).
Authoritative DNS: Der Server, der „zuständig“ ist und die endgültige Antwort für eine Zone liefert.
Forwarder: Resolver, der Anfragen für bestimmte Zonen an definierte Server weiterleitet (conditional forwarding).

DNS-Grundlagen (Records, Authoritative/Recursive, TTL, NXDOMAIN) sind in den klassischen Spezifikationen beschrieben, z. B. in RFC 1034 und RFC 1035.

Typische Symptome bei Split-Horizon und Private DNS Problemen

DNS-Probleme in der Cloud zeigen häufig charakteristische Muster. Wenn Sie diese Muster erkennen, können Sie die Ursache oft in wenigen Minuten eingrenzen.

„Von On-Prem geht es, aus der Cloud nicht“ (oder umgekehrt): Unterschiedliche Resolver oder unterschiedliche Zonenansichten (Split-Horizon greift nicht wie gedacht).
„Nur manche Subnetze/VNets/VPCs können auflösen“: Private DNS Zone nicht mit allen Netzwerken verknüpft oder Forwarding nur in einem Teilpfad aktiv.
„Hostname löst auf private IP, aber Verbindung timeoutet“: DNS ist korrekt, aber Routing/Firewall zum Private Endpoint fehlt.
„Hostname löst auf öffentliche IP statt private“: Private DNS Zone greift nicht, falscher Resolver, fehlende Conditional Forwarder.
„NXDOMAIN oder SERVFAIL nur intern“: Forwarder-Kette kaputt, Resolver hat keine Berechtigung/Erreichbarkeit, oder DNSSEC/Filter-Probleme.
„Es geht manchmal“: Caching/TTL, mehrere Resolver liefern unterschiedliche Antworten, Lastverteilung über Resolver (Round Robin) oder Race Conditions bei IaC.

Das wichtigste Troubleshooting-Prinzip: Erst den Resolver-Pfad klären

Bei DNS-Fehlern ist die häufigste falsche Annahme: „Der Client fragt den DNS-Server X.“ In Wahrheit fragt der Client oft den lokalen Stub Resolver, der wiederum einen Unternehmensresolver nutzt, der wiederum in die Cloud forwardet. Deshalb ist der erste Schritt im Troubleshooting immer:

Welcher Resolver wird tatsächlich genutzt? (Client-DNS-Settings, DHCP, VPN-Profile, Cloud-Resolver)
Wer ist für die Zone authoritative? (Public Zone vs. Private Zone vs. On-Prem AD DNS)
Gibt es Conditional Forwarding? (z. B. private.cloud.example → Cloud-Resolver)
Wo greift Split-Horizon? (nach Quelle/VNet/VPC/Resolver-IP, nicht nach „Gefühl“)

Praxis-Tipp: Notieren Sie für jeden Test die Abfragequelle (IP/Netz), den verwendeten Resolver (IP), den Record-Typ (A/AAAA/CNAME) und die TTL. Ohne diese vier Informationen ist DNS-Debugging unnötig schwer.

Split-Horizon in der Cloud: Häufige Architekturvarianten

Split-Horizon wird in Cloud-Umgebungen typischerweise auf eine von drei Arten umgesetzt:

Variante A: Separate Zonen (Public + Private) mit identischem Zonennamen
Beispiel: example.com öffentlich mit Public IPs; example.com privat in einer Private DNS Zone mit Private IPs (nur in verknüpften Netzwerken sichtbar).
Variante B: Unterschiedliche Subdomains
Beispiel: app.example.com öffentlich, app.internal.example.com privat. Weniger elegant, aber oft einfacher zu betreiben.
Variante C: Zentraler Resolver mit Views/Policies
Beispiel: Unternehmensresolver entscheidet anhand der Client-Quelle, welche Antwort zurückkommt (Policy-based DNS).

Variante A ist in Cloud-Designs mit Private Endpoints sehr verbreitet, kann aber gefährlich sein, wenn On-Prem-Resolver „die falsche“ Zone priorisiert oder wenn Private Zone Links fehlen.

Private Endpoints und Private DNS: Der Klassiker für „auflösbar, aber nicht erreichbar“

Private Endpoints (je nach Cloud-Begrifflichkeit) verlagern den Zugriff auf einen Dienst von einer öffentlichen IP in das private Netzwerk. DNS ist der Mechanismus, der den Hostnamen auf die private IP umbiegt. Das ist elegant – aber im Troubleshooting muss man zwei Dinge trennen:

DNS korrekt? Name zeigt auf private IP/CNAME, die erwartet wird.
Netzpfad korrekt? Route/Security erlaubt den Zugriff auf diese private IP aus dem Abfrage-/Clientnetz.

Ein typischer Fehler: On-Prem-Clients bekommen bereits die private IP (weil Split-Horizon greift), aber es gibt noch kein VPN/Peering/Transit oder die Firewall blockt den Pfad. Ergebnis: alles „hängt“, und die Ursache wirkt wie DNS – ist aber Routing/Security.

Der Standard-Workflow: DNS in der Cloud systematisch debuggen

Dieser Ablauf ist bewusst praxistauglich und herstellerneutral. Er funktioniert für Azure/AWS/GCP gleichermaßen, auch wenn die konkreten UI-Begriffe variieren.

Schritt: Erwartung definieren

Welcher Hostname soll auf welche IP zeigen?
Soll die Antwort je nach Standort unterschiedlich sein (Split-Horizon)?
Welche Record-Typen sind im Spiel (A/AAAA/CNAME)?
Welche Netze dürfen den privaten Dienst erreichen?

Schritt: Auflösung aus mehreren Perspektiven testen

Test aus On-Prem (typischer Clientresolver)
Test aus einer Cloud-VM im betroffenen VPC/VNet
Test aus einem anderen VPC/VNet (Hub vs. Spoke)
Test aus „extern“ (Mobilfunk/Heimnetz), um die Public-Zone zu verifizieren

Ziel: Sie wollen sehen, ob Split-Horizon wie geplant greift und ob Private DNS in den richtigen Netzen sichtbar ist.

Schritt: Resolver und Forwarding-Kette prüfen

Welcher DNS-Server wird wirklich gefragt (DHCP/VPN/Cloud-DNS Settings)?
Gibt es Conditional Forwarding für die private Zone?
Kommt die Anfrage beim richtigen Authoritative an?
Gibt es Caches, die alte Antworten liefern (TTL beachten)?

Schritt: Private DNS Zone Verknüpfungen (Links/Associations) validieren

Ist die private Zone mit dem richtigen VNet/VPC verknüpft?
Ist sie mit allen relevanten Spokes verknüpft oder nur mit dem Hub?
Gibt es mehrere private Zonen mit identischem Namen in unterschiedlichen Accounts/Subscriptions?

Ein häufiger Root Cause ist „Zone existiert, aber Link fehlt“ – dann können nur manche Netze auflösen.

Schritt: Routing und Security für Private IPs prüfen

Existiert eine Route vom Clientnetz zur Private Endpoint IP?
Blocken Security Groups/NSGs/NACLs/Firewalls den Port?
Gibt es Asymmetrie (Hinweg über Transit, Rückweg über anderes Gateway)?

Schritt: Negative Antworten und Servfail sauber deuten

NXDOMAIN: Name existiert in dieser Zone nicht oder falscher Resolver/Zonenansicht.
SERVFAIL: Resolver kann nicht rekursiv auflösen (Forwarder nicht erreichbar, DNSSEC/Policy, Timeout).
REFUSED: Server lehnt ab (ACL/Policy/Views).

Häufige Root Causes bei Split-Horizon und Private DNS

Wenn Sie die häufigsten Fehlerquellen kennen, können Sie gezielt prüfen statt zu raten.

Falscher Resolver durch DHCP, VPN oder Split-Tunnel

VPN-Profile überschreiben DNS-Server (oder nur für bestimmte Domains).
Split-Tunnel führt dazu, dass DNS intern geht, aber der Datenpfad extern bleibt (oder umgekehrt).
Mobile Clients nutzen DoH/DoT und umgehen Unternehmens-DNS, wodurch Split-Horizon nicht greift.

Private Zone nicht (vollständig) verknüpft

Hub-VNet hat Link, Spoke-VNet nicht → nur Hub-Workloads können private Records auflösen.
Mehrere VNets/VPCs, aber nur ein Teil ist in der Zone verlinkt.
Falsche Subscription/Account: Zone existiert in einem anderen Mandanten als gedacht.

Record-Design: CNAME-Ketten, TTL und falsche Targets

CNAME zeigt auf einen privaten Namen, der wiederum nicht auflösbar ist (fehlende Zone/Forwarder).
TTL zu hoch: nach Änderungen halten Clients/Resolver alte Antworten.
AAAA/IPv6 spielt rein: Client bevorzugt IPv6, aber es gibt keine passende private IPv6-Route.

Routing/Firewall: DNS korrekt, aber private IP nicht erreichbar

VPN/Peering/Transit existiert nicht oder Route fehlt (UDR/Route Table Binding).
Firewall blockt den Dienstport oder Ephemeral Ports für Rückverkehr.
Asymmetrisches Routing über mehrere Gateways führt zu stateful Drops.

Debugging mit Logs und Telemetrie: Was Ihnen wirklich hilft

DNS-Probleme lassen sich deutlich schneller lösen, wenn Sie nicht nur Endgeräte testen, sondern auch Telemetrie nutzen:

Resolver-Logs: Query Logs zeigen, welche Anfragen gestellt wurden und wie beantwortet wurde.
Flow Logs: Zeigen, ob Verkehr zur Resolver-IP/Private Endpoint IP überhaupt fließt oder geblockt wird.
Packet Capture: In hartnäckigen Fällen: Sehen Sie UDP/TCP 53, Antworten, Retries, Timeouts.

Für Paketmitschnitt-Methodik ist die Wireshark Dokumentation ein guter Einstieg, insbesondere um NXDOMAIN vs. Timeout sauber zu unterscheiden.

Best Practices: DNS in Hybrid- und Cloud-Umgebungen stabil betreiben

Viele DNS-Incidents sind wiederkehrend, weil DNS-Design und Ownership unklar sind. Diese Best Practices reduzieren Störungen deutlich:

Klare DNS-Quelle pro Zone: Definieren Sie, wer authoritative ist (Public, Private, On-Prem) und dokumentieren Sie die Zuständigkeit.
Conditional Forwarding sauber: Private Zonen gezielt an Cloud-Resolver/Forwarder weiterleiten, nicht „alles“ irgendwohin schicken.
Private DNS Links standardisieren: Hub-and-Spoke-Links über IaC, mit Tests, damit neue Spokes automatisch korrekt angebunden werden.
TTL bewusst wählen: Für häufig geänderte private Records eher niedrigere TTLs (ohne Übertreibung), damit Rollouts schneller greifen.
DoH/DoT Strategie: Entscheiden, ob DoH erlaubt ist und wie Split-Horizon trotzdem funktioniert (oder DoH kontrolliert blocken/steuern).
Diag-VM pro Segment: Eine kleine VM/Instance pro VNet/VPC spart bei DNS- und Routingproblemen enorm Zeit.
NTP stabilisieren: Zeitdrift kann TLS-Validierung und Log-Korrelation verfälschen, was DNS-Fehler „größer“ wirken lässt.

Outbound-Links zur Vertiefung

Checkliste: Split-Horizon und Private DNS Troubleshooting in der Cloud

Erwartung festlegen: Welche Antwort soll es intern/extern geben? Welche IP ist korrekt (public vs. private endpoint)?
Resolver klären: Welcher DNS-Server wird tatsächlich genutzt (DHCP/VPN/Cloud-DNS/DoH)?
Mehrfach testen: Auflösung aus On-Prem, aus Cloud-VM im Zielnetz, aus anderem VNet/VPC, sowie extern.
Zone-Zuständigkeit prüfen: Public Zone vs. Private Zone vs. On-Prem Zone – welche ist authoritative für den Namen?
Private Zone Links prüfen: Ist die Private DNS Zone mit allen relevanten VNets/VPCs verknüpft (Hub und Spokes)?
Forwarding prüfen: Conditional Forwarder korrekt? Erreichbarkeit der Forwarder/Resolver (UDP/TCP 53) gegeben?
Caching/TTL berücksichtigen: Alte Antworten in Resolvern/Clients möglich; Cache leeren oder TTL abwarten.
Routing/Security prüfen: Wenn private IP geliefert wird, existiert ein Pfad dorthin (UDR/Route Tables, Peering/Transit, Firewalls, SG/NSG/NACL)?
Fehlercodes deuten: NXDOMAIN (Name fehlt/Zone falsch), SERVFAIL (Resolver/Forwarder kaputt), Timeout (Netzpfad/Firewall/Load).
Beweise sammeln: Query Logs, Flow Logs, kurzer Paketmitschnitt, und Vorher/Nachher nach Fix mit identischem Testfall verifizieren.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Netzwerkdesign & Topologie-Planung
Router- & Switch-Konfiguration (Cisco IOS)
VLAN, Inter-VLAN Routing
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
NAT, ACL, DHCP, DNS-Konfiguration
Troubleshooting & Netzwerkoptimierung
Packet Tracer Projektentwicklung & Dokumentation
CCNA Lern- & Praxisunterstützung

Lieferumfang:

Konfigurationsdateien
Packet-Tracer-Dateien (.pkt)
Netzwerkdokumentation
Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.