February 21, 2026

DNS-Outage im ISP: Cache, TTL und trügerische Propagation

Ein DNS-Outage im ISP ist selten ein „hartes“ Alles-oder-nichts-Ereignis. Viel häufiger ist er trügerisch: Einige Kunden sind betroffen, andere nicht; manche Websites gehen, manche nicht; in einem PoP wirkt alles stabil, im nächsten häufen sich Timeouts. Der Grund liegt fast immer in Cache, TTL und Propagation – drei Faktoren, die DNS im Normalbetrieb robust machen, im Incident aber die Lage verschleiern. Resolver-Caches können veraltete oder fehlerhafte Antworten länger festhalten als erwartet, negative Caches können „NXDOMAIN“ und andere Fehlerzustände konservieren, und TTL-Werte sorgen dafür, dass Änderungen nicht gleichzeitig weltweit wirken. Für Operations-Teams entsteht so ein gefährlicher Eindruck: „Wir haben den Fix ausgerollt, aber es ist noch kaputt“ – oder umgekehrt: „Es ist wieder ok“, obwohl nur ein Teil der Nutzer dank Cache noch funktioniert. Genau deshalb muss ein DNS-Outage im ISP anders triagiert werden als ein reiner Transportausfall: Sie brauchen Messpunkte entlang der Rekursionskette, eine klare Sicht auf TTL- und Cache-Zustände, und eine Diagnose-Logik, die trügerische Propagation erkennt. Dieser Artikel erklärt praxisnah, wie Cache, TTL und Propagation in DNS-Outages zusammenspielen, welche typischen Failure Modes im ISP auftreten und wie Sie im Incident schnell zu belastbaren Nachweisen und sicheren Mitigations kommen.

Table of Contents

DNS im ISP-Kontext: Rekursion, Autorität und wo Caches wirklich sitzen

Im ISP-Betrieb sind typischerweise mehrere Cache-Ebenen beteiligt – und genau das macht Outages so uneindeutig. Ein vereinfachtes Bild:

Stub Resolver: Client auf Endgerät oder CPE, fragt meist einen rekursiven Resolver des ISP oder eines Public DNS an.
Recursive Resolver: ISP-Resolver (z. B. in PoPs) oder zentrale Resolver-Farm; hält Cache für Antworten und Fehlantworten.
Forwarder/Resolver-Ketten: Manche Netze forwarden intern (z. B. Access → regional → zentral), wodurch zusätzliche Caches entstehen.
Authoritative Nameserver: Zoneninhaber (CDN/Provider/Enterprise) liefert autoritative Antworten.

DNS-Grundlagen sind in RFC 1034 und RFC 1035 beschrieben. Für die operative Fehlersuche ist wichtig: In einem ISP-Outage können unterschiedliche Kunden je nach genutztem Resolver (ISP vs. Public DNS), Standort (PoP) und Cache-Zustand unterschiedliche Ergebnisse sehen.

Warum DNS-Outages „trügerisch“ sind

Transportausfälle zeigen sich oft klar in Ping/Traceroute oder in Interface-Drops. DNS-Outages sind dagegen oft eine Mischung aus:

Cache-Heterogenität: Nicht alle Resolver haben dieselben Einträge zur selben Zeit.
TTL-Effekten: Gültigkeitszeiten bestimmen, wie lange alte Daten weiter genutzt werden.
Negativem Caching: Fehlerantworten werden ebenfalls gecacht und können Recovery verzögern.
Propagation-Mythos: „DNS propagiert“ klingt nach globaler Verzögerung, ist aber häufig schlicht Cache- und TTL-Logik – plus Resolver-Implementierungsdetails.

TTL richtig verstehen: Nicht nur „wie lange“, sondern „wo“

TTL (Time To Live) ist das Feld, das bestimmt, wie lange ein Resolver eine Antwort cachen darf. Operativ entscheidend: TTL wirkt auf jeder Cache-Ebene, aber jede Ebene kann andere Daten haben. Ein Fix kann deshalb „teilweise“ wirken.

TTL-Countdown im Cache (MathML)

$TTL_remaining = TTL_original - age$

Wenn ein Resolver einen Record erst vor 10 Minuten gecacht hat und der TTL 3600 Sekunden beträgt, bleibt die Antwort noch 50 Minuten gültig – selbst wenn der Autoritative Server inzwischen korrigiert wurde. Das ist kein Fehler, sondern DNS-Design. Problematisch wird es, wenn Outage- und Recovery-Kommunikation „TTL“ ignorieren.

Negative Caching: Der unterschätzte Recovery-Killer

Nicht nur erfolgreiche Antworten werden gecacht, sondern auch negative Antworten wie NXDOMAIN oder SERVFAIL-ähnliche Zustände (je nach Resolver). Negative Caching wird über den SOA-Record und dessen Parameter beeinflusst; wichtig ist insbesondere die „negative TTL“ (häufig aus dem SOA MINIMUM bzw. dem SOA/TTL-Kontext abgeleitet). Der Mechanismus ist in RFC 2308 beschrieben.

Typisches Outage-Muster: Ein Autoritative Nameserver ist kurz nicht erreichbar oder liefert Fehler; Resolver cachen negative Antworten.
Trügerische Recovery: Der Autoritative ist wieder ok, aber Clients sehen weiterhin NXDOMAIN/SERVFAIL, bis der negative Cache abläuft.
Operative Folge: „Wir haben gefixt, aber Kunden melden weiter Störung“ – und beide haben recht.

„Propagation“ im Alltag: Was wirklich passiert

Der Begriff Propagation ist im Incident oft irreführend. DNS verteilt nicht aktiv neue Werte an alle Resolver. Stattdessen:

Resolver holen Daten on-demand,
sie nutzen Cache bis TTL abläuft,
und erst dann fragen sie wieder beim Autoritativen nach.

Das bedeutet: Eine Änderung „propagiert“ schnell bei Resolvern, die gerade einen Cache-Miss haben, und langsam bei Resolvern, die frische Einträge im Cache halten. In ISP-Umgebungen wird dieses Verhalten noch stärker, weil viele Resolver-Farmen und Forwarder parallel existieren.

Typische DNS-Outage-Ursachen im ISP – und warum Cache sie verschleiert

Ein DNS-Outage im ISP hat selten nur „eine“ Ursache. Die folgenden Muster sind besonders verbreitet und führen oft zu trügerischer Propagation.

Muster 1: Rekursiver Resolver überlastet oder teildegradiert

Symptom: erhöhte Latenz, Timeouts, SERVFAIL-Spikes, aber nicht für alle Domains.
Trugbild: häufig angefragte Domains gehen weiter (Cache-Hits), seltene brechen weg (Cache-Miss braucht Rekursion).
Beweisführung: Cache-Hit-Rate vs. Miss-Rate, Query-Latenz, CPU/Memory, UDP Drops.

Muster 2: Forwarder-Kette bricht (regionaler DNS-Failure)

Symptom: nur bestimmte PoPs betroffen, andere stabil.
Trugbild: Kunden, die Public DNS nutzen, sind nicht betroffen; ISP-DNS-Kunden schon.
Beweisführung: Vergleich: Queries über ISP-Resolver vs. Public Resolver; per-PoP Metriken.

Muster 3: Autoritative Nameserver intermittierend erreichbar

Symptom: sporadische SERVFAIL/NXDOMAIN, oft in Wellen; besonders bei Cache-Miss sichtbar.
Trugbild: manche Nutzer haben noch gültige Caches, andere treffen genau den Miss-Zeitpunkt.
Beweisführung: aktive Probes gegen Authoritatives, NS-Set-Konsistenz, Antwortcodes, Latenz.

Muster 4: DNSSEC/Validierungsprobleme

DNSSEC kann Outages „hart“ machen: Ein falsch signierter Record führt bei validierenden Resolvern zu SERVFAIL, während nicht validierende Resolver „funktionieren“. Dadurch entsteht ein extrem trügerisches Bild: „Bei mir geht’s, bei anderen nicht.“ DNSSEC-Grundlagen sind in RFC 4035 beschrieben.

Symptom: nur Resolver mit DNSSEC-Validation betroffen.
Trugbild: Public DNS A geht, Public DNS B geht nicht – oder umgekehrt, je nach Validation/Policy.
Beweisführung: DNSSEC validation failure counters, testweise Queries mit/ohne Validation (kontrolliert).

Muster 5: EDNS0/Fragmentation/PMTUD-Probleme

DNS-Antworten können durch EDNS0 größer werden und Fragmentation auslösen. Wenn fragmentierte UDP-Pakete im Netz gedroppt werden (Firewall/ACL/Path-MTU/Fragment-Policy), wirken große Antworten kaputt, kleine aber ok. EDNS0 ist in RFC 6891 beschrieben.

Symptom: bestimmte Domains (mit großen DNSSEC-Antworten) schlagen fehl, andere gehen.
Trugbild: „DNS ist teilweise down“ – weil nur große Antworten betroffen sind.
Beweisführung: UDP Fragment Drops, Vergleich UDP vs. TCP fallback, Antwortgrößenprofil.

Messmethoden: So machen Sie DNS-Outages im ISP beweisbar

Um trügerische Propagation zu entlarven, brauchen Sie Messpunkte auf mehreren Ebenen. Eine einzige Probe reicht nicht.

Messpunkt 1: Synthetische Resolver-Probes pro PoP

Success Rate: Anteil erfolgreicher A/AAAA-Queries für ein Domain-Set.
Latenz: p50/p95/p99 Query-RTT.
Antwortcodes: NOERROR, NXDOMAIN, SERVFAIL – getrennt auswerten.

Messpunkt 2: Cache-Statistiken (Hit/Miss, Negative Cache)

Cache Hit Ratio: hoch ist gut, aber im Outage verschleiert sie Probleme.
Negative Cache Rate: Anstieg bei NXDOMAIN/SERVFAIL kann Recovery verzögern.
Evictions: Cache thrashing (zu kleiner Cache) erhöht Rekursionslast und kann Outage verstärken.

Cache Hit Ratio (MathML)

$HitRatio = \frac{cache_hits}{cache_hits + cache_misses}$

Messpunkt 3: Autoritative Reachability und NS-Konsistenz

NS-Set erreichbar: alle Nameserver antworten konsistent?
Latenz/Timeouts: ist ein NS langsam und erzeugt Retries?
Served Zone Consistency: unterschiedliche Antworten je NS deuten auf Rollout-/Zonendrift hin.

Messpunkt 4: Netzwerk-Telemetrie (Drops, Fragmentation, Anycast Drift)

UDP Drops: besonders auf Port 53 und für fragmentierte Pakete.
Anycast Resolver Drift: wenn Resolver anycasted sind, kann Traffic zwischen PoPs wechseln und unterschiedliche Cache-Zustände treffen.
ECMP/LAG Partial Failures: selektive Drops können DNS als erstes sichtbar machen.

Diagnose-Runbook: DNS-Outage im ISP strukturiert triagieren

Dieses Runbook ist darauf ausgelegt, die drei Hauptfragen schnell zu beantworten: (1) Ist es wirklich DNS? (2) Ist es Rekursion, Autorität oder Transport? (3) Welche Rolle spielt Cache/TTL?

Schritt: Impact eingrenzen (DNS vs. „Internet down“)

Vergleich Resolver: ISP-Resolver vs. Public DNS (z. B. 8.8.8.8/1.1.1.1) – wenn Public DNS geht, ist ISP-DNS verdächtig.
Vergleich Protokoll: DNS über UDP vs. DNS über TCP (wenn möglich) – hilft bei Fragment/PMTUD-Problemen.
Domain-Set: mehrere Domains testen (kleine Antworten vs. große DNSSEC-Antworten).

Schritt: Cache- und TTL-Effekte sichtbar machen

TTL prüfen: ist der Record im Cache noch gültig? Wie lange bis Ablauf?
Negative Cache prüfen: sind NXDOMAIN/SERVFAIL gecacht?
Per-PoP Unterschiede: unterschiedliche Cachezustände zwischen Resolvern erklären regionale „Geht/Geht nicht“-Muster.

Schritt: Rekursion vs. Autoritative trennen

Recursive Health: Query-Latenz, CPU, UDP drops, cache miss rate.
Authoritative Health: direkte Probes zu NS, Antwortkonsistenz, timeouts.
DNSSEC-Check: validation failures (wenn aktiv), insbesondere bei SERVFAIL-Spikes.

Schritt: Transport-Fallen prüfen (EDNS0, Fragmentation, MTU)

Antwortgröße: schlagen große Antworten eher fehl?
Fragment Drops: gibt es Hinweise auf fragmentierte UDP Drops?
TCP-Fallback: wenn TCP funktioniert, ist UDP/Fragmentation ein starker Kandidat.

Sichere Mitigation: Was im DNS-Outage schnell hilft – und was nicht

DNS-Outages haben oft einen reflexartigen „Cache flush“-Impuls. Das kann helfen, kann aber auch schaden, wenn es unkontrolliert ist, weil es Cache-Misses erzeugt und Rekursionslast explodieren lässt. Sicheres Vorgehen ist deshalb abgestuft.

Mitigation 1: Resolver-Last stabilisieren

Rate-Limiting für Miss-Spikes: nicht für legitime Queries generell, sondern für anormale Miss- oder NXDOMAIN-Stürme.
Cache-Größe/Memory: wenn möglich, Cache-Kapazität erhöhen oder Evictions reduzieren.
Traffic Shaping zum Upstream: um Resolver nicht in Retries zu treiben.

Mitigation 2: Failover-Resolver sauber aktivieren

PoP-Failover: Traffic kontrolliert auf gesunde Resolver-Pools verschieben (stufenweise, um Überlast zu vermeiden).
Anycast Steering: wenn Resolver anycasted sind, PoP-spezifische Ankündigungen prüfen, um „schlechte PoPs“ zu entlasten.

Mitigation 3: Cache-Flush nur kontrolliert

Selektiv flushen: problematische Domains/Records statt „global flush“.
Stufenweise: nicht alle Resolver gleichzeitig flushen; Canary-Ansatz pro PoP.
Begründung: flushen Sie nur, wenn Sie sicher sind, dass Caches falsche Daten halten und die Autoritative Quelle wieder korrekt ist.

Mitigation 4: EDNS0/UDP-Größen temporär reduzieren

Wenn Fragmentation/PMTUD das Problem ist, kann es helfen, EDNS0 UDP Payload Size herunterzusetzen, damit Antworten kleiner werden und nicht fragmentieren. Das ist kein Dauerzustand, kann aber ein schneller Workaround sein, bis die Transportursache behoben ist. EDNS0-Details stehen in RFC 6891.

Kommunikation im Incident: Warum TTL in Statusupdates gehört

DNS-Incidents sind kommunikativ schwierig, weil die Recovery nicht sofort überall sichtbar ist. In Statusupdates sollten daher konkrete, technische Aussagen stehen:

Welche Resolver-Pools sind betroffen? (Region/PoP)
Welche Symptomklasse? (Timeouts, SERVFAIL, NXDOMAIN)
Welche TTL/Negative TTL Effekte erwarten wir? (z. B. „vollständige Normalisierung innerhalb von X Minuten nach Ablauf der Caches“)
Welche Workarounds gibt es? (z. B. alternative Resolver – wenn policyseitig akzeptiert)

Damit vermeiden Sie den klassischen Vertrauensverlust durch „Es sollte jetzt wieder gehen“, während ein Teil der Nutzer noch negative Caches hat.

Evidence Pack für RCA: Pflichtdaten bei DNS-Outages

Zeitlinie (UTC): Start, Peak, Mitigation, Stabilisierung, Ende.
Resolver-Metriken: query rate, hit/miss ratio, response code distribution, latency p95/p99, CPU/memory.
Negative Caching: NXDOMAIN/SERVFAIL cache rate, negative TTL Indizien.
Autoritative Daten: NS reachability, Antwortkonsistenz, DNSSEC validation failures (wenn relevant).
Transportdaten: UDP/53 drops, fragment drops, MTU/PMTUD Indizien, TCP fallback tests.

Outbound-Ressourcen

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.