Split-Horizon DNS in der Cloud: Konzept, Setup und Troubleshooting

Split-Horizon DNS in der Cloud beschreibt ein DNS-Design, bei dem derselbe Domainname je nach Abfragequelle unterschiedliche Antworten liefert. Ein interner Client (z. B. Workload in einer VPC/VNet) erhält private IPs oder private Endpoints, während ein externer Client (z. B. aus dem Internet oder aus einem Partnernetz) öffentliche IPs oder andere Ziele sieht. Dieses Konzept ist in Cloud-Umgebungen besonders relevant, weil moderne Architekturen häufig private Zugriffe auf Managed Services, PrivateLink/Private Endpoint oder interne Load Balancer verlangen – ohne die öffentliche Namensstruktur zu verändern. Gleichzeitig ist Split-Horizon DNS in der Cloud eine der häufigsten Ursachen für schwer zu diagnostizierende Produktionsprobleme: „Bei mir geht’s, bei dir nicht“, zufällige Timeouts, TLS-Zertifikatsfehler oder überraschende Egress-Kosten durch unbeabsichtigte Auflösung auf öffentliche Endpoints. Wer Split-Horizon DNS sauber plant, konsistent umsetzt und richtig troubleshootet, reduziert Ausfälle, verbessert Security (weniger Exposure) und gewinnt Kontrolle über Datenpfade in Hybrid- und Multi-Cloud-Szenarien.

Konzept: Was genau ist Split-Horizon DNS?

Beim Split-Horizon DNS existieren für dieselbe Zone oder denselben Hostnamen unterschiedliche „Sichten“ (Views) – typischerweise eine interne und eine externe Sicht. Die Antwort hängt davon ab, welcher Resolver die Anfrage verarbeitet und aus welchem Netzwerk der Client kommt. In der Cloud wird das oft über private DNS-Zonen, Resolver-Endpoints und Conditional Forwarding umgesetzt.

• Interne Sicht: Hostname → private IP (z. B. interne NLB/ALB-Adresse, Private Endpoint, Service-IP)
• Externe Sicht: Hostname → öffentliche IP (z. B. CDN/WAF/Ingress, Public Load Balancer)
• Resolver-Entscheidung: Welche Zone/Antwort gilt, bestimmt die DNS-Auflösungskette (Client → Stub Resolver → rekursiver Resolver → autoritativer DNS)

Warum Split-Horizon DNS in der Cloud so verbreitet ist

Cloud-Provider liefern für private Services häufig private IPs, die nur in Ihrem Netzwerk routbar sind. Gleichzeitig wollen Sie oft denselben Hostnamen für interne und externe Nutzer beibehalten (z. B. „api.example.com“), damit Anwendungen keine Umgebungslogik (intern/extern) in Code oder Konfiguration tragen müssen. Split-Horizon DNS löst das elegant – solange die Resolver-Pfade klar sind.

Typische Anwendungsfälle in AWS, Azure und GCP

Die konkreten Produktnamen unterscheiden sich, das Muster ist sehr ähnlich: private Zonen werden an Netze „gelinkt“, und Resolver/Forwarder sorgen dafür, dass interne Clients die privaten Antworten sehen.

• Private Endpoints/PrivateLink: Intern soll „service.vendor.com“ auf private IPs zeigen, extern auf öffentliche.
• Interne Load Balancer: „app.example.com“ soll intern zur internen LB-Adresse auflösen, extern zur Public Edge.
• Hybrid Connectivity: On-Prem und Cloud sollen dieselben Namen nutzen, aber unterschiedliche Ziel-IPs erhalten (z. B. lokal vs. cloud-intern).
• Staging/Prod-Trennung: Gleiches Domain-Schema, aber unterschiedliche Antworten je nach Netzwerk/Resolver.
• Sicherheitszonen: Admin- oder Backend-Services nur intern resolvable, extern gar nicht oder auf „sinkhole“.

Dokumentationen für den Einstieg: Amazon Route 53 Private Hosted Zones, Azure Private DNS, Google Cloud DNS.

Aufbau: Die DNS-Auflösungskette verstehen

Split-Horizon DNS scheitert selten „im DNS selbst“, sondern fast immer an der tatsächlichen Auflösungskette. Eine saubere mentale Modellierung hilft beim Setup und beim Troubleshooting:

• Client/Stub Resolver: Betriebssystem, Container Runtime oder Sidecar entscheidet, welchen DNS-Server er fragt.
• Rekursiver Resolver: Der Resolver beantwortet aus Cache oder fragt autoritative Server ab.
• Autoritative Zone: Dort liegen die Records. Bei Split-Horizon existieren meist zwei autoritative Zonen/Sichten.
• Routing-Realität: Eine private Antwort ist nur dann „richtig“, wenn der Client sie auch routen kann.

Der häufigste Denkfehler: „DNS ist richtig“ ≠ „Service ist erreichbar“

Ein Hostname kann korrekt auf eine private IP auflösen, aber dennoch nicht erreichbar sein (Security Groups/NSGs, NACLs, Firewall, fehlende Routen, falsche Subnetze). Umgekehrt kann ein Service erreichbar sein, aber Sie nutzen unbeabsichtigt den öffentlichen Pfad, weil DNS aus einem anderen View antwortet.

Setup-Muster: So wird Split-Horizon DNS in der Cloud umgesetzt

In der Praxis haben sich drei Muster etabliert. Welches am besten passt, hängt davon ab, ob Sie nur Cloud-intern arbeiten oder Hybrid/Multi-Cloud integrieren müssen.

Muster 1: Private DNS-Zone + VPC/VNet-Verknüpfung

Sie legen eine private Zone an (z. B. „example.com“ oder „internal.example.com“) und verknüpfen sie mit Ihren Cloud-Netzen. Interne Resolver beantworten Anfragen aus dieser Zone mit privaten Records.

• Vorteil: Einfach, robust, wenige bewegliche Teile.
• Nachteil: Hybrid-Zugriffe (On-Prem) benötigen zusätzlich Resolver-Integration.

Muster 2: Split-Horizon über Conditional Forwarding

Sie betreiben (oder nutzen) zentrale Resolver, die bestimmte Zonen gezielt an interne Autoritäten weiterleiten (z. B. „corp.example.com“ → On-Prem DNS, „privatelink.*“ → Cloud Private DNS). Das ist typisch bei Hybrid-Architekturen.

• Vorteil: Klare Trennung, gut für Hybrid und Multi-Cloud.
• Nachteil: Mehr Komponenten, Fehlerquellen durch Forwarder-Ketten.

Muster 3: Zentraler DNS-Hub (Hub-and-Spoke Resolver)

Ein zentraler DNS-Resolver-Dienst (oder ein DNS-Hub-VNet/VPC) stellt Resolver-Endpoints bereit (Inbound/Outbound) und verteilt DNS-Policies (Weiterleitungen, Regeln, Logging) zentral. Spokes nutzen den Hub als Standardresolver.

• Vorteil: Governance, Logging, standardisierte Policies.
• Nachteil: DNS wird kritische Abhängigkeit; Redundanz und Change-Disziplin sind Pflicht.

AWS: Praxis-Setup und Stolpersteine

In AWS wird Split-Horizon häufig über Route 53 Private Hosted Zones und Route 53 Resolver umgesetzt. Private Hosted Zones können mit einer oder mehreren VPCs assoziiert werden; Route 53 Resolver kann über Inbound/Outbound Endpoints DNS zwischen On-Prem und VPC vermitteln. Einstieg: Private Hosted Zones und Route 53 Resolver.

• Private Hosted Zone: interne Records für „api.example.com“ → private IP oder interne LB.
• Öffentliche Hosted Zone: externe Records für denselben Namen → öffentliche IP/ALB/CDN.
• Resolver Regeln: Conditional Forwarding zu On-Prem für Unternehmenszonen oder zu Dritt-Resolvern.

AWS-spezifische Failure Modes

• Falsche VPC-Assoziation: Zone ist nicht mit der VPC verknüpft, deshalb wird die öffentliche Antwort genutzt.
• Überlappende Zonen: Eine private Zone für „example.com“ überschattet unintendiert andere Subdomains.
• Resolver Endpoint Security: SG/NACL blockieren UDP/TCP 53 oder Rückverkehr, Queries laufen in Timeouts.
• DNS-Caching: Clients cachen alte Antworten; Fixes wirken nicht sofort (TTL beachten).

Azure: Praxis-Setup und Stolpersteine

In Azure wird Split-Horizon DNS typischerweise über Azure Private DNS Zones umgesetzt, die an VNets verlinkt werden. Für Hybrid-Szenarien spielen DNS Forwarder und der Azure DNS Private Resolver (in vielen Architekturen) eine zentrale Rolle. Einstieg: Azure Private DNS und Azure DNS Private Resolver.

• Private DNS Zone: „privatelink.*“ oder eigene Zone wird an VNets gelinkt.
• VNet Link: steuert, welche VNets die private Sicht erhalten.
• Forwarding/Resolver: Hybrid-Auflösung (On-Prem ↔ Azure) über Forwarding Rulesets und Endpoints.

Azure-spezifische Failure Modes

• VNet Link fehlt oder ist falsch: nur manche VNets sehen private Antworten, andere nutzen öffentliche.
• DNS-Server-Einstellungen im VNet: Custom DNS Server überschreibt Azure-Resolver, private Zonen werden nicht erreicht.
• Private Endpoint DNS-Zonen fehlen: Private Endpoints existieren, aber Namen lösen nicht auf private IP auf.
• Mehrdeutige Namensräume: mehrere private Zonen/Records konkurrieren; falscher Record gewinnt.

Google Cloud: Praxis-Setup und Stolpersteine

In Google Cloud ist Cloud DNS die Basis. Für Split-Horizon und Hybrid sind insbesondere „Private Zones“, „Peering Zones“ und „Forwarding Zones“ relevant. Private Service Connect fügt zusätzliche DNS-Muster hinzu. Einstieg: Cloud DNS Zones und Cloud DNS mit VPC.

• Private Zone: gilt nur für bestimmte VPC-Netze.
• DNS Peering: ermöglicht DNS-Auflösung über VPC-Grenzen hinweg (kontrolliert).
• Forwarding Zone: leitet Queries für bestimmte Zonen an einen Zielresolver weiter (z. B. On-Prem).

GCP-spezifische Failure Modes

• Zone-Visibility falsch: Private Zone ist nicht dem richtigen VPC zugeordnet.
• DNS Peering nicht aktiv: Workloads in Spokes können Hub-Zonen nicht auflösen.
• Forwarding-Ketten: Queries laufen über mehrere Forwarder, Latenz steigt, Timeouts nehmen zu.
• PSC-Namensauflösung: Private Service Connect erfordert konsistente DNS-Records/Mechanismen, sonst fällt Traffic auf Public zurück.

TTL, Caching und „Warum wirkt mein Fix nicht?“

DNS ist ein Cache-System. Selbst wenn Sie Records korrigieren, können Clients, Sidecars, Resolver und Zwischen-Caches alte Antworten halten. Das führt zu dem klassischen Symptom: Ein Teil der Flotte funktioniert, ein Teil nicht. Um das planbar zu machen, müssen Sie TTLs bewusst setzen und Caches berücksichtigen.

Eine einfache Daumenregel für die „Wirkzeit“ von DNS-Änderungen

Wenn ein Resolver eine Antwort cached, bleibt sie in der Regel bis zum TTL-Ablauf gültig. In vereinfachter Form gilt: Je höher der TTL, desto länger kann die alte Antwort im Feld bleiben.

$\mathrm{MaxWartezeit}\approx \mathrm{TTL}+\mathrm{CacheSkew}$

CacheSkew steht hier für zusätzliche Verzögerungen durch gestaffelte Cache-Zeitpunkte, unterschiedliche Resolver und clientseitige Caches. Praxisempfehlung: Kritische Zonen mit potenziellen Failover-Szenarien nutzen moderate TTLs und testen Failover aktiv.

Troubleshooting: Systematisch vom Symptom zur Ursache

Gutes Troubleshooting für Split-Horizon DNS beginnt nicht mit „DNS ist kaputt“, sondern mit einer strukturierten Prüfung: Welche Sicht sollte gelten, welche Sicht gilt tatsächlich, und wo im Resolver-Pfad entsteht die Abweichung?

Schritt: Erwartete Sicht definieren

• Welche Clients sollen die private Antwort sehen (VPC/VNet/Subnet/Cluster)?
• Welche Clients sollen die öffentliche Antwort sehen (Internet/Partner/On-Prem)?
• Welche Namen sind betroffen (Root-Zone vs. einzelne Records)?

Schritt: Auflösung aus der Perspektive des Clients prüfen

• Welche DNS-Server sind auf dem Client konfiguriert (DHCP Options, VNet DNS Settings, /etc/resolv.conf, CoreDNS)?
• Antwortet der Client aus Cache? (Neustart von Resolver-Services oder Flush je nach System)
• Kommt die Antwort von einem lokalen Stub, einem Cluster-DNS oder einem zentralen Resolver?

Schritt: Autoritative Quelle identifizieren

• Welche Zone ist autoritativ für den Namen? (öffentliche Zone, private Zone, überschattete Subzone)
• Gibt es konkurrierende Zonen gleichen Namens (z. B. „example.com“ privat und öffentlich)?
• Ist die private Zone korrekt verknüpft/visible für das Netzwerk des Clients?

Schritt: Netzwerkpfad und Security prüfen

• Kann der Client die private IP routen? (Peering, TGW, Hub-and-Spoke Routen)
• Blocken SG/NSG/NACL/Firewall DNS (UDP/TCP 53) oder den Zielservice-Port?
• Gibt es Asymmetrien (z. B. Client in Zone B nutzt Resolver/Endpoint in Zone A)?

Schritt: „Fallback auf Public“ erkennen

• Wenn private Auflösung fehlschlägt, fällt ein Client oft auf öffentliche Auflösung zurück (z. B. durch alternativen Resolver).
• Symptom: unerwartete Egress-Kosten, NAT-Last, öffentliche IPs in Logs, unterschiedliche TLS-Pfade.
• Gegenmaßnahme: Resolver-Pfade konsolidieren, Forwarding-Regeln eindeutig gestalten, Logging aktivieren.

Häufige Fehler in Cloud-Setups (und wie Sie sie vermeiden)

Viele Split-Horizon-Probleme lassen sich durch saubere Standards vermeiden. Die folgenden Fehlerbilder sind in Produktion besonders häufig.

• Zu breite private Zone: Statt nur „priv.example.com“ wird „example.com“ privat gezogen und überschattet unerwartet andere Records.
• Uneinheitliche Resolver: Ein Teil der Flotte nutzt Cloud-Resolver, ein anderer Teil Custom DNS; Antworten differieren.
• Unklare Ownership: Netzwerkteam verwaltet Zonen, App-Team verwaltet Records, niemand testet End-to-End.
• Fehlendes DNS-Logging: Ohne Query-Logs ist nicht nachvollziehbar, welcher Resolver welche Antwort gab.
• Hardcoded IPs: Anwendungen umgehen DNS; Split-Horizon kann dann nicht wirken.
• TTL zu hoch für Failover: DNS-Failover wird zäh, Incidents dauern länger.

Best Practices: Split-Horizon DNS stabil, sicher und wartbar betreiben

Split-Horizon DNS ist dann ein Gewinn, wenn es standardisiert ist: klare Zonenstrategie, klare Resolver-Pfade, konsistente Policies und reproduzierbare Änderungen.

• Zonenstrategie definieren: Root-Zone nur dann splitten, wenn zwingend; ansonsten Subdomains („priv.“, „internal.“, „corp.“) nutzen.
• Resolver-Pfade vereinheitlichen: Wenige, gut verstandene Resolver; Forwarding-Regeln zentral steuern.
• DNS als produktionskritische Abhängigkeit behandeln: Redundanz (zonal/regional), Monitoring, Change-Reviews.
• Logging aktivieren: Query-Logs und Resolver-Logs nutzen, um Sichten und Fehlpfade zu erkennen.
• IaC und Reviews: Zonen, Records, Links/Associations und Forwarding als Code verwalten.
• Failover testen: Regelmäßige Tests, ob interne Clients wirklich private Ziele erreichen und externe Clients nicht „aus Versehen“ intern landen.
• Dokumentation: Für jede Zone festhalten: Zweck, Sicht, verknüpfte Netze, Resolver-Regeln, TTL-Policy.

Minimaler Testplan für jede Änderung

• Test aus einem internen Subnetz/Cluster: Auflösung, Connect, TLS, HTTP-Status.
• Test aus einem externen Standort: Auflösung und Erreichbarkeit der Public-Edge.
• Test aus Hybrid/On-Prem (falls relevant): Forwarding-Pfad, Latenz, Zeitouts.
• Validierung der Logs: Query-Logs zeigen die erwartete Zone/Antwort.

Outbound-Links zu relevanten Informationsquellen

• AWS Route 53: Private Hosted Zones
• AWS Route 53 Resolver: Konzepte und Endpoints
• Azure Private DNS: Überblick
• Azure DNS Private Resolver: Überblick
• Google Cloud DNS: Overview
• Google Cloud: Cloud DNS mit VPC nutzen
• RFC 1034: Domain Names – Concepts and Facilities
• RFC 1035: Domain Names – Implementation and Specification

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.