DNS im WAN Edge Kontext: Split-Horizon, Latenz und Failover richtig bauen

DNS ist am WAN Edge nicht „nur ein Dienst“, sondern ein Performance- und Verfügbarkeitshebel: Schon wenige Millisekunden mehr Resolver-Latenz wirken sich auf jede Verbindung aus (Web, SaaS, APIs). Gleichzeitig ist DNS ein klassischer Single Point of Failure, wenn Split-Horizon (intern/extern), Routing-Failover und Cache-Strategien nicht sauber zusammenpassen. Im Betrieb sieht man dann Symptome wie „Internet geht, aber nichts löst auf“, „nur interne Namen gehen“, „VPN-User bekommen falsche Antworten“ oder „Failover schaltet, aber DNS bleibt auf dem toten Pfad“. Dieser Artikel zeigt, wie du Split-Horizon, Latenzoptimierung und Failover am WAN Edge stabil designst.

Warum DNS am WAN Edge so kritisch ist

DNS ist in vielen Protokollen der erste Schritt. Jede zusätzliche Round-Trip-Time zum Resolver multipliziert sich über viele Abfragen. Wenn DNS ausfällt, wirkt alles „down“, obwohl Routing noch funktioniert.

• Latenz: Resolver-RTT beeinflusst Time-to-First-Byte
• Verfügbarkeit: DNS-Ausfall wirkt wie „Internet down“
• Policy: Split-Horizon steuert, welche Antworten intern/extern gelten

Split-Horizon: Konzept und typische Fallstricke

Split-Horizon DNS bedeutet: dieselbe Domain liefert unterschiedliche Antworten je nach Quelle (intern vs. extern, VPN vs. LAN, Standort A vs. B). Das ist notwendig für interne Services, kann aber schnell inkonsistent werden, wenn Zonen, TTLs und Forwarding nicht sauber geplant sind.

• Intern: private IPs, interne VIPs, AD-Records
• Extern: öffentliche IPs, CDN/WAF Endpunkte
• VPN: oft „intern“, aber abhängig vom Split-Tunnel-Modell

Merker

$\text{Split-Horizon}=\text{gleicher Name}+\text{andere Antwort nach Scope}$

DNS-Rollen am Edge: Authoritative, Resolver, Forwarder

Viele Designs scheitern, weil Rollen vermischt werden. Am WAN Edge betreibst du in der Regel keinen „Authoritative DNS“ für Unternehmenszonen, sondern Resolver/Forwarder, der Anfragen effizient verteilt und cached.

• Authoritative DNS: Quelle der Wahrheit für Zonen (meist DC/Cloud)
• Recursive Resolver: löst Namen aus dem Internet rekursiv auf
• Forwarder: leitet Queries an definierte Upstream Resolver
• Cache: reduziert Latenz und WAN-Traffic massiv

Latenzdesign: Local Caching ist der größte Gewinn

Der stabilste Performance-Hebel ist ein lokaler Resolver (oder ein lokaler Forwarder mit Cache) pro Standort/PoP. Damit minimierst du RTT und reduzierst Abhängigkeit vom WAN. Wichtig ist, dass Cache-Policies und TTL-Strategien bewusst gewählt werden.

• Lokaler Cache: reduziert RTT für wiederkehrende Queries
• Upstream-Auswahl: 2–3 Resolver, Anycast sinnvoll
• TTL-Policy: nicht zu aggressiv „override“, sonst falsche Failover-Effekte

Failover: DNS muss dem Routing folgen (und umgekehrt)

In Dual-WAN-Designs ist DNS-Failover oft der echte Engpass. Wenn der Default-Route-Failover schaltet, aber DNS weiterhin den alten Upstream nutzt, wirkt das Netz „kaputt“. Deshalb müssen DNS-Forwarder/Resolver und WAN-Failover gekoppelt sein.

• WAN-Failover (IP SLA/Tracking) steuert Default Route
• DNS-Upstream muss auf den aktiven Pfad umschalten
• Health Checks: nicht nur Ping, sondern DNS/TCP 53 oder DoH/443

IP SLA als DNS-Proxy-Check (Pattern)

ip sla 10
 tcp-connect 1.1.1.1 53 source-interface GigabitEthernet0/0
 frequency 10
 timeout 1500
ip sla schedule 10 life forever start-time now
track 10 ip sla 10 reachability

delay down 10 up 5

Split-Horizon + Failover: Die häufigste Fehlerquelle

Wenn interne Zonen über Forwarder erreichbar sind, externes DNS aber über andere Upstreams läuft, kann ein WAN-Failover zu „half broken“ führen: intern geht, extern nicht (oder umgekehrt). Stabil wird das nur mit klaren Resolver-Pfaden pro Scope.

• Interne Zonen: feste Forwarder zu internen DNS-Quellen (DC/Resolver)
• Externe Zonen: rekursiv oder separate Upstreams
• VPN-Clients: bewusstes DNS-Routing (split oder full)

Anycast Resolver am Edge: sinnvoll, aber nur mit Health-Withdraw

Anycast für DNS (z. B. ein Anycast-IP für Resolver-Cluster) kann Failover und Latenz verbessern. Voraussetzung ist, dass Nodes bei Service-Failure withdrawen, sonst erzeugst du DNS-Blackholes.

• Anycast-IP als Resolver-VIP
• Health Checks steuern Announcement
• TTL und Cache beeinflussen Failover-Speed

TTL und Caching: Wie du Failover-Zeiten wirklich steuerst

Viele erwarten, dass DNS-Failover „sofort“ ist. In Realität wirken TTL und Client-Caches. Niedrige TTLs beschleunigen Änderungen, erhöhen aber Query-Last. Sinnvoll ist: kurze TTL nur für wirklich failoverkritische Records, nicht für alles.

• Niedrige TTL: schneller Wechsel, mehr Queries
• Hohe TTL: stabil, aber langsamer Failover
• Gezielt: TTL-Reduktion nur für VIPs/Edge-Endpunkte

Security und Governance: DNS ist Policy-Plane

DNS steuert, wohin Traffic geht. Deshalb gehören Filter, Logging und Schutzmechanismen ins Design: Response Policy Zones (RPZ), DoT/DoH-Strategie, Rate-Limits und saubere Segmentierung für interne Zonen.

• Split-Horizon Zonen strikt trennen (Views/Policies)
• Logging: Query Logs selektiv (Datenschutz/Volumen)
• Schutz: Rate-Limits, ACLs, keine offenen Resolver

WAN Edge Troubleshooting: DNS-Probleme systematisch isolieren

DNS Troubleshooting funktioniert am besten in Schichten: erst Connectivity zum Resolver, dann Resolution, dann Policy (Split-Horizon), dann Cache/TTL. Wichtig: „ping geht“ beweist DNS nicht.

• 1) Erreichbarkeit Upstream (TCP/UDP 53 oder DoH/443)
• 2) Query-Erfolg (A/AAAA, NXDOMAIN vs. Timeout)
• 3) Split-Horizon: kommt die richtige Antwort für den Scope?
• 4) Cache/TTL: wird alte Antwort gecached?

Router-nahe Checks (Pattern)

show ip route 0.0.0.0
show ipv6 route ::/0
show ip sla summary
show track brief
show interfaces | include drops|error

Typische Edge-Cases, die in der Praxis Tickets erzeugen

Diese Fälle wirken „random“, sind aber meist designbedingt: asymmetrisches Routing bei DNS, falsche VPN-DNS-Zuweisung oder PMTUD/MTU-Probleme bei DNS over TCP/DoH.

• Nur große Antworten fail (DNSSEC, viele Records) → MTU/PMTUD
• VPN split-tunnel, aber DNS intern → Queries gehen über falschen Pfad
• Failover schaltet Default Route, DNS nutzt alten Uplink → Timeouts
• Anycast Resolver ohne Health Withdraw → „sporadische“ DNS-Ausfälle

Quick-Runbook: DNS am WAN Edge stabil prüfen

Diese Checkliste trennt Routing-/Failover-Probleme von echten DNS-Problemen und liefert schnell verwertbare Hinweise.

show ip sla summary
show track brief
show ip route 0.0.0.0
show ipv6 route ::/0
show interfaces | include drops|error
show logging | include SLA|track|BGP|route

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.