DNS Load Balancing Probleme: TTL, Failover und Cache-Effekte

DNS Load Balancing ist verlockend einfach: Mehrere IP-Adressen in einem A/AAAA-Record, ein niedriger TTL-Wert, und schon verteilt sich Traffic „automatisch“ auf mehrere Standorte oder Server. In der Praxis entstehen jedoch genau hier die häufigsten Missverständnisse, die zu Ausfällen, unzuverlässigem Failover und schwer erklärbaren Performance-Schwankungen führen. Der Grund ist, dass DNS kein Load Balancer im klassischen Sinn ist, sondern ein verteiltes Caching-System mit eigenen Regeln: Resolver cachen Antworten, Clients cachen zusätzlich, manche Resolvers „pin“nen Antworten pro Nutzer, und viele Komponenten ignorieren kurze TTLs oder haben Mindest-TTLs. Dadurch kann ein DNS-Failover deutlich länger dauern als erwartet – selbst wenn Sie den DNS-Eintrag sofort ändern. Außerdem verteilt DNS Load Balancing nicht gleichmäßig: Resolver, NAT-Gateways und Browser/Apps verändern die Lastverteilung, sodass einzelne Ziel-IP-Adressen „heiß“ laufen, während andere kaum Traffic sehen. Wer DNS Load Balancing Probleme sauber debuggen will, muss daher TTL, Failover-Mechanik und Cache-Effekte als zusammenhängendes System betrachten. Dieser Artikel zeigt, wie Sie typische Fehlerbilder erkennen, die tatsächliche Wirkdauer von TTLs messen und DNS-Failover so gestalten, dass es unter realen Cache-Bedingungen zuverlässig funktioniert.

DNS Load Balancing ist kein „echtes“ Load Balancing

Ein klassischer Load Balancer (L4/L7) sieht Verbindungen und kann per Health Checks, Queueing, Sticky Sessions oder gewichteter Verteilung entscheiden. DNS hingegen liefert nur Antworten auf Namensauflösungen. Sobald ein Resolver eine Antwort erhalten hat, kann er sie für die Dauer der TTL cachen und ohne erneute Rückfrage ausliefern. Deshalb ist DNS Load Balancing eher „Traffic Steering durch Namensauflösung“ und nicht „Lastverteilung pro Request“.

• DNS entscheidet selten pro Request: Oft entscheidet der Resolver einmal pro TTL-Fenster.
• Verteilung hängt von Resolvern ab: Nicht jeder Client fragt selbst den autoritativen DNS ab; meist tun das recursive Resolver.
• Failover ist nicht instant: Selbst nach einer DNS-Änderung können Caches alte IPs weiter ausliefern.

TTL verstehen: Was der Wert wirklich bedeutet

Die TTL (Time to Live) ist die Zeit, die ein Resolver eine DNS-Antwort cachen darf, bevor er erneut beim autoritativen Server nachfragt. In vielen Designs wird TTL als „Failover-Zeit“ interpretiert. Das ist nur teilweise richtig, denn TTL ist eine Obergrenze für den Cache – keine Garantie, dass nach Ablauf sofort umgeschaltet wird. Außerdem können mehrere Cache-Schichten existieren.

Die drei Cache-Schichten, die Ihre TTL beeinflussen

• Recursive Resolver Cache: Der häufigste und wichtigste Cache. Er bestimmt, wie lange ganze Nutzergruppen dieselbe Antwort sehen.
• Client/OS Cache: Betriebssysteme cachen ebenfalls; die Implementierung unterscheidet sich nach Plattform und Konfiguration.
• Application Cache: Browser, Java-VMs, Container-Libraries oder eigene DNS-Resolver in Anwendungen können zusätzlich cachen.

Warum niedrige TTLs nicht immer wirken

• Mindest-TTLs: Einige Resolver erzwingen Minimums (z. B. 30s/60s), um Last zu reduzieren.
• Prefetch/Serve-Stale: Resolver können Antworten proaktiv erneuern oder kurzzeitig „stale“ Antworten weitergeben (implementationsabhängig).
• Negative Caching: Auch NXDOMAIN/NoData kann gecacht werden, was Failover-Szenarien stören kann.

Für einen Standard-Hintergrund zu DNS ist RFC 1034 und RFC 1035 eine solide Referenzbasis.

Failover über DNS: Was realistisch ist und was nicht

DNS-Failover bedeutet meist: Wenn ein Standort oder Service ausfällt, soll DNS statt IP-A eine andere IP-B liefern. Das klappt, aber nur, wenn Sie die Cache-Realität akzeptieren und das System entsprechend bauen. DNS-Failover ist typischerweise nicht für „Sekunden-Switchover“ geeignet, sondern eher für Minuten- bis wenige-Minuten-Fenster – abhängig von TTL, Caches und Monitoring.

Typische Failover-Modelle

• Active/Passive: Primär-IP wird ausgeliefert, Sekundär-IP nur bei Ausfall. Risiko: TTL-Caches halten Primär-IP zu lange.
• Active/Active: Mehrere IPs werden gleichzeitig ausgeliefert. Vorteil: Verteilung und Redundanz, Nachteil: Ungleichverteilung durch Cache-Effekte.
• Geo-DNS: Antwort abhängig von Standort/Resolver-IP. Vorteil: bessere Latenz, Nachteil: Geolocation ist nicht perfekt, Client-IP ist oft nicht sichtbar.
• Weighted DNS: Gewichte steuern, wie häufig eine IP geliefert wird. Vorteil: graduelles Steering, Nachteil: Gewichte wirken auf Resolver-Ebene, nicht auf echte Endnutzer.

Cache-Effekte, die DNS Load Balancing „unfair“ machen

Wenn Sie mehrere A/AAAA-Records ausliefern, erwarten viele eine gleichmäßige Verteilung. In der Praxis entstehen Hotspots aus drei Gründen: Resolver bündeln viele Clients, Clients teilen sich NAT-IPs, und Antworten werden pro TTL-Fenster wiederholt genutzt.

Resolver-Bündelung

• Wenige Resolver, viele Nutzer: Ein großer ISP-Resolver kann für Millionen Clients dieselbe Antwort cachen.
• Enterprise Resolver: In Unternehmen hängt oft ein ganzer Standort an einem Resolver-Cluster.

NAT und „scheinbar gleiche Clients“

• Carrier-Grade NAT: Mobile Nutzer teilen sich öffentliche IPs; Geo-DNS und Client-affine Mechaniken werden ungenau.
• Proxy/VDI: Viele Sessions kommen aus wenigen IPs, was Auswertung verzerrt.

Client-Verhalten bei mehreren IPs

• Happy Eyeballs (IPv6/IPv4): Clients probieren IPv6 und IPv4 parallel oder nacheinander, was Last unerwartet verschiebt. Hintergrund: RFC 8305.
• Retry-Logik: Manche Clients behalten die „erste erfolgreiche“ IP und nutzen sie länger als TTL vermuten lässt.
• Connection Reuse: HTTP/2/HTTP/3 halten Verbindungen länger; DNS wird seltener konsultiert, als man denkt.

Die häufigsten DNS Load Balancing Probleme im Betrieb

Problem: Failover dauert viel länger als die TTL

• Wahrscheinliche Ursachen: Client- oder App-Caches, Mindest-TTLs im Resolver, lange Keep-Alive-Verbindungen, „serve stale“ Verhalten.
• High-Signal Nachweis: Vergleich von autoritativer Antwort vs. Antwort des recursiven Resolvers über Zeit; messen, wann welcher Resolver umschaltet.
• Fix-Richtung: TTL realistisch wählen, Failover nicht allein auf DNS bauen, zusätzlich L7/L4 Mechaniken nutzen (Load Balancer, Anycast, Service Mesh).

Problem: Einige Nutzer sind dauerhaft auf der „kaputten“ IP

• Wahrscheinliche Ursachen: Resolver hält alte Antwort, Client pinnt IP, DNS-Änderung erreicht nicht alle Caches gleichzeitig.
• High-Signal Nachweis: Client-seitige Resolver-Quelle (welcher recursive Resolver?) und gemessene Antwort-IP korrelieren; Problem tritt clusterweise pro Resolver auf.
• Fix-Richtung: „Remove from rotation“ mit ausreichend Vorlauf (Drain), parallele IPs nicht sofort hart entfernen, Health-Check-basierte Steering nutzen.

Problem: Ungleichmäßige Last trotz Round Robin

• Wahrscheinliche Ursachen: DNS-Round-Robin rotiert zwar Records, aber Resolver cachen und liefern immer wieder dieselbe Reihenfolge; Clients nehmen nur die erste IP.
• High-Signal Nachweis: Backend-Telemetrie zeigt Hotspot; DNS-Queries zeigen, dass bestimmte Resolver konstant dieselbe IP bevorzugen.
• Fix-Richtung: Weighted DNS einsetzen, Antworten shufflen, aber vor allem L7 Load Balancing oder Anycast erwägen, wenn echte Gleichverteilung nötig ist.

Problem: Änderungen im DNS „kommen nicht an“

• Wahrscheinliche Ursachen: Falsche Zone geändert (Split-Horizon), falsches Record-Set (CNAME-Kette), lange Negative-Caching-TTL, Propagation-Verzögerungen bei sekundären Nameservern.
• High-Signal Nachweis: Autoritative Nameserver direkt abfragen und SOA/Serial prüfen; prüfen, ob alle autoritativen Instanzen konsistent antworten.
• Fix-Richtung: DNS-Change-Prozess mit Verifikation pro autoritativem Server, SOA-Serial, Monitoring auf Konsistenz.

Messmethodik: Latenz und Failover real messen, nicht schätzen

DNS Load Balancing ist ein Statistikproblem. Sie brauchen Messungen, die die reale Welt abbilden: verschiedene Resolver, verschiedene Regionen, verschiedene Client-Typen. Ein einzelner dig von Ihrem Laptop sagt wenig aus.

Praktische Messfragen

• Welche Resolver nutzen meine Clients? ISP, Public Resolver, Enterprise Resolver, VPN-Resolver.
• Welche TTL wird tatsächlich geliefert? Autoritativ vs. gecacht, inklusive „remaining TTL“.
• Wie schnell schaltet jeder Resolver um? Failover-Zeit = Monitoring-Detektion + DNS-Update + Cache-Expiry + Client-Requery.
• Welche IP wird von Clients wirklich genutzt? Nicht nur DNS-Antwort, sondern die tatsächlich verwendete Ziel-IP in Verbindungen.

Werkzeuge, die im Troubleshooting helfen

• dig/drill/kdig: gezielte Abfragen gegen autoritative Nameserver und gegen verschiedene recursive Resolver.
• Resolver-Logs: In Unternehmensumgebungen (z. B. Unbound/BIND) können Query-Logs die Cache-Wahrheit zeigen.
• Backend-Telemetrie: Verbindungsstatistiken pro Ziel-IP/Region sind oft der beste „Truth Source“ für Lastverteilung.

TTL-Strategien: Kurz genug für Failover, lang genug für Stabilität

TTLs zu niedrig zu setzen ist nicht kostenlos: Es erhöht Query-Last auf autoritativen Servern, kann die Abhängigkeit von DNS-Latenz verstärken und ist in manchen Resolvern wirkungslos. Zu hohe TTLs machen Failover zäh. Eine gute TTL-Strategie ist deshalb kontextabhängig.

• Stabile Services: TTL eher höher (z. B. Minuten), um Resolver-Load zu reduzieren.
• Failover-kritische VIPs: TTL moderat niedrig (z. B. 30–120 Sekunden), aber mit realistischem Erwartungsmanagement.
• Vor geplanten Änderungen: TTL temporär reduzieren (Drain-Fenster), Änderung durchführen, danach TTL wieder erhöhen.
• Negative TTL beachten: SOA MINIMUM/Negative-Caching kann NXDOMAIN länger festhalten, als man denkt.

Failover-Mechaniken: DNS allein reicht oft nicht

DNS-Failover ist am zuverlässigsten, wenn es mit einer zweiten Ebene kombiniert wird, die schneller reagieren kann. Typische Kombinationen:

• DNS + Load Balancer: DNS verteilt grob auf Regionen, L7 LB übernimmt feines Load Balancing und Health Checks.
• DNS + Anycast: Anycast bringt Traffic zum nächsten POP, Failover ist routing-basiert; DNS bleibt stabil, aber Routing-Design wird wichtiger.
• DNS + Client Retry Policy: Clients probieren bei Fehlern eine zweite IP; wichtig ist, dass mehrere IPs gleichzeitig geliefert werden.

Cache-Effekte bei Multi-Record Antworten: Reihenfolge und Auswahl

Viele autoritative DNS-Server rotieren die Reihenfolge von A/AAAA-Records („Round Robin“). Doch selbst wenn die Reihenfolge rotiert, wählen viele Clients die erste Adresse oder eine bevorzugte (z. B. IPv6 zuerst). Dadurch entsteht eine scheinbare Ungleichverteilung.

• Beobachtung: Record-Rotation ist nicht gleich Request-Rotation.
• Praxis: Wenn echte Gleichverteilung nötig ist, ist DNS allein meist nicht ausreichend.
• Mitigation: Weights, Health-basierte Antworten, oder Kombination mit L7 Load Balancing.

Health Checks bei DNS Load Balancing: schnell, aber vorsichtig

Viele DNS-Anbieter oder eigene DNS-Setups unterstützen Health-Check-basierte Antworten: Ein Record wird nur geliefert, wenn der Zielservice gesund ist. Das kann Failover verbessern, aber Cache-Effekte bleiben. Außerdem ist Health Checking selbst ein System, das false positives/negatives erzeugen kann.

• False Negative: Health Check misst vom falschen Standort, Backend ist lokal ok, remote aber erreichbar.
• False Positive: Check ist zu simpel (TCP open), aber App ist kaputt.
• Best Practice: Health Checks auf die kritische User Journey ausrichten und „flapping“ vermeiden (Hysterese, mehrere Probes).

Runbook-Baustein: DNS Load Balancing Probleme in 15 Minuten eingrenzen

• Minute 0–3: Symptom klassifizieren: Failover zu langsam, ungleichmäßige Last oder nur bestimmte Nutzer betroffen? Betroffene Domain/Record-Typ (A/AAAA/CNAME) festhalten.
• Minute 3–6: Autoritativ prüfen: Direkte Abfrage der autoritativen Nameserver – welche Records und welche TTL werden geliefert? SOA/Serial konsistent?
• Minute 6–9: Resolver-Realität prüfen: Abfragen über die wichtigsten recursive Resolver (ISP/Public/Enterprise). Welche „remaining TTL“ sehen Sie? Welche IPs werden wirklich ausgeliefert?
• Minute 9–12: Cache-Effekt quantifizieren: Wie lange bleibt die alte IP in verschiedenen Resolvern aktiv? Gibt es Mindest-TTL oder negative Caching?
• Minute 12–15: Mitigation: Records parallel liefern (nicht hart entfernen), TTL temporär senken (wenn planbar), Health-basiertes DNS oder L7/L4 Failover ergänzen. Danach Verifikation über dieselben Resolver-Checks.

Nachhaltige Stabilisierung: Best Practices für DNS Failover und Cache-Realität

• TTL-Playbook: Vorgehen für geplante Failover/Deployments: TTL vorher senken, drainen, umstellen, TTL wieder erhöhen.
• Multi-Resolver Monitoring: Nicht nur autoritativ messen, sondern echte recursive Resolver in verschiedenen Regionen.
• „Remove from rotation“ sicher: Ziel-IP nicht abrupt entfernen, sondern gestuft (Weights reduzieren) und ausreichend lang beobachten.
• Client-Verhalten berücksichtigen: Happy Eyeballs, Connection Reuse, Mobile NAT, VPN-Resolver – in Tests abbilden.
• Fallback-Ebene einplanen: DNS ist gut für grobes Steering; für harte SLOs zusätzlich L7/L4 Mechaniken einsetzen.

Weiterführende Quellen

• RFC 1034 und RFC 1035 für DNS-Grundlagen (Records, TTL, Resolver-Modell)
• RFC 2308 für Negative Caching (NXDOMAIN/NoData und Cache-Effekte)
• RFC 2181 für Klarstellungen zu DNS-Semantik (nützlich bei Interpretationsfehlern)
• RFC 8305 für Happy Eyeballs v2 (IPv6/IPv4 Auswahl und Auswirkungen auf Lastverteilung)
• BIND Dokumentation als praxisnahe Referenz für autoritative/recursive DNS-Betriebsdetails und TTL/Caching
• Unbound Projektseite als Referenz für Resolver-Verhalten, Caching und moderne DNS-Features

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.