Site icon bintorosoft.com

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

Red Snapper

Organized network. 3d render white isolated graphic background

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.

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.

Merker

Split-Horizon = gleicher Name + 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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Sie erhalten

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.

Exit mobile version