DNS-Incident-Playbook: Resolver, Cache, TTL und Propagation

Ein DNS-Ausfall fühlt sich für Nutzer oft an wie „das Internet ist kaputt“: Webseiten laden nicht, APIs sind nicht erreichbar, Mail-Server wirken offline – obwohl Netzwerk, Server und Anwendungen gesund sein können. Genau deshalb braucht ein NOC ein klares DNS-Incident-Playbook, das schnell zwischen Resolver-Problemen, Cache-Effekten, TTL-Fallen und echter Propagation unterscheidet. DNS ist ein verteiltes System mit mehreren Ebenen: Stub-Resolver auf dem Client, rekursive Resolver im Unternehmen oder beim ISP, autoritative Nameserver beim Provider sowie Caches dazwischen. Jeder Layer kann Fehler maskieren oder verstärken. Im Incident zählt deshalb eine strukturierte Vorgehensweise: Welche Domain ist betroffen? Welche Record-Typen? Welche Resolver-Pfade? Welche TTLs greifen? Wurde kürzlich ein Change gemacht (Zone-Update, Nameserver-Wechsel, DNSSEC, CDN-Onboarding)? Dieses Playbook liefert eine praxistaugliche Schrittfolge, Minimaldaten fürs Ticket und typische Failure-Modes inklusive schneller Mitigation. Ziel ist nicht akademische DNS-Theorie, sondern reproduzierbare Diagnostik mit minimalem Rätselraten – und eine Owner-Zuordnung, die Eskalationen beschleunigt statt verzögert.

Minimaldaten, die bei jedem DNS-Incident sofort gesammelt werden sollten

Bevor Sie Tests starten, sammeln Sie die Daten, die später für Korrelation und Root Cause entscheidend sind. Ohne diese Basis entstehen „fliegende“ Hypothesen.

• Zeitpunkt: Exakter Timestamp inkl. Zeitzone; seit wann tritt es auf?
• Betroffene FQDNs: Vollqualifizierte Names (z. B. api.example.com), nicht nur „example.com“.
• Record-Typ: A/AAAA/CNAME/MX/TXT/SRV/NS/SOA; „DNS geht nicht“ ist oft nur ein Typ.
• Client-Kontext: Standort/Region, Client-Netz (VPN, Office, ISP), Betriebssystem (Windows/macOS/Linux), ob DoH/DoT aktiv ist.
• Resolver-Pfad: Welcher rekursive Resolver wird genutzt? (Corporate, ISP, Public DNS, lokaler Cache).
• Symptomklasse: NXDOMAIN, SERVFAIL, Timeout, falsche IP, intermittierend, nur IPv6, nur einzelne Resolver.
• Letzte Changes: DNS-Update, Zone-Transfer/Provider-Wechsel, TTL-Anpassung, DNSSEC-Änderung, CDN/Load-Balancer-Routing.

Mit diesen Minimaldaten können Sie den Incident in wenigen Minuten in „Autoritativ“, „Rekursiv/Cache“, „Client/Stub“ oder „Propagation/TTL“ einordnen.

DNS-Architektur in Incident-Sprache: Wer macht was?

Für schnelle Fehlerisolation ist es hilfreich, DNS als Kette von Rollen zu denken. Jede Rolle hat typische Failure-Modes und typische Owner-Teams.

• Stub-Resolver (Client): Fragt DNS an, cached oft kurz (OS, Browser, Runtime). Owner: Client/Workplace/Endpoint.
• Rekursiver Resolver: Fragt autoritative Server ab, cached Ergebnisse nach TTL. Owner: Netzwerk/Plattform/ISP.
• Autoritativer Nameserver: Quelle der Wahrheit für eine Zone. Owner: DNS/Platform/Provider.
• Parent Zone / Delegation: NS-Records beim Registrar/TLD. Owner: Domain/Registrar/Platform.
• DNSSEC-Vertrauenspfad: Validierungskette, die SERVFAIL auslösen kann. Owner: DNS/PKI/Platform.

Das Playbook nutzt diese Kette als Navigationshilfe: Wenn autoritative Antworten korrekt sind, aber nur manche Clients scheitern, ist die Wahrscheinlichkeit hoch, dass Resolver oder Caches der Engpass sind.

Erster Entscheidungsfilter: NXDOMAIN, SERVFAIL, Timeout oder falsche Antwort?

DNS-Fehler sehen ähnlich aus, haben aber sehr unterschiedliche Ursachen. Klassifizieren Sie zuerst das Symptom:

• NXDOMAIN: Der Name existiert nicht (aus Sicht des antwortenden Servers). Typisch bei Tippfehlern, falscher Zone, fehlendem Record, falsch gesetztem CNAME, Split-Horizon-Missmatch.
• SERVFAIL: Server konnte nicht zuverlässig antworten. Häufig DNSSEC-Validierungsfehler, kaputte Delegation, Rate-Limits, Upstream-Probleme beim Resolver.
• Timeout: Keine Antwort innerhalb der Zeit. Typisch bei Netzwerkpfadproblemen zu Resolver/Authority, Firewall/UDP-Block, Fragmentierung/EDNS, überlasteten Nameservern.
• Falsche Antwort: IP/Record stimmt nicht. Typisch bei Caching mit alten TTLs, Split-Horizon, falsch gerouteten CNAME-Ketten, GeoDNS/CDN.
• Intermittierend: Mal geht es, mal nicht. Typisch bei Anycast/POP-Problemen, inkonsistenten Authoritys, Round-Robin-Fehlern oder Resolver-Farmen.

Diese Einordnung entscheidet, ob Sie primär die Zone/Delegation prüfen (NXDOMAIN), DNSSEC/Resolver (SERVFAIL), Netzpfad/MTU (Timeout) oder Cache/Propagation (falsche Antwort).

Schrittfolge im DNS-Incident-Playbook

Die folgende Reihenfolge ist so gewählt, dass Sie mit wenigen Abfragen die größten Fehlerklassen ausschließen.

Autoritative Wahrheit prüfen

Ermitteln Sie zuerst, was die autoritativen Nameserver für den betroffenen Record liefern. Damit trennen Sie „Zone ist falsch“ von „Resolver liefert falsches Ergebnis“.

• NS-Records der Zone prüfen: Welche Nameserver sind zuständig?
• SOA prüfen: Seriennummer, Minimum TTL, Authority-Quelle.
• Record direkt gegen Authority abfragen: Stimmen IP, CNAME, MX, TXT?

Wenn die autoritativen Antworten bereits falsch sind, ist das Owner-Team in der Regel DNS/Platform/Registrar – nicht Netzwerk.

Delegation und Parent-Records validieren

Viele DNS-Incidents entstehen nicht in der Zone selbst, sondern in der Delegation: NS-Records beim Parent zeigen auf falsche Nameserver, oder Glue-Records sind inkonsistent. Typische Symptome sind SERVFAIL oder intermittierendes Verhalten, weil Resolver mal den einen, mal den anderen Nameserver erreichen.

• Parent-NS vs. Child-NS: Stimmen die Nameserverlisten überein?
• Glue prüfen (bei in-bailiwick NS): Passen A/AAAA der Nameserver?
• Erreichbarkeit: Antworten alle autoritativen Nameserver konsistent?

Rekursive Resolver vergleichen (A/B-Test)

Vergleichen Sie Antworten über mindestens zwei unterschiedliche rekursive Resolver (z. B. Corporate Resolver vs. Public DNS). Das ist der schnellste Weg, Cache-Probleme oder Resolver-spezifische Störungen zu erkennen.

• Corporate Resolver: Reproduziert der Fehler hier zuverlässig?
• Public Resolver: Ist das Ergebnis dort korrekt?
• ISP Resolver: Wenn möglich, Vergleich aus betroffener Region.

Wenn nur ein Resolver-Pfad betroffen ist, ist die Ursache häufig Cache-Konsistenz, DNSSEC-Validierung, Upstream-Reachability oder Rate-Limits in der Resolver-Infrastruktur.

Client-/Stub-Caches ausschließen

Auch wenn die Resolver korrekt sind, können Clients „alt“ bleiben. Betriebssysteme und Anwendungen cachen unterschiedlich lang und nicht immer strikt nach TTL.

• OS-DNS-Cache: Flush/Restart des DNS-Clients (je nach Plattform).
• Browser-/App-Caches: Manche Anwendungen cachen DNS unabhängig.
• VPN/Proxy: Kann eigene Resolver erzwingen oder DoH/DoT umleiten.

Operativ wichtig: Wenn nur einzelne Nutzer betroffen sind, aber NOC-Tests sauber sind, ist Client/Endpoint-Ownership wahrscheinlicher als DNS/Network.

Cache und TTL: Warum „wir haben es geändert“ nicht gleich „es ist wirksam“ bedeutet

DNS-Caching ist der häufigste Grund für scheinbar „inkonsistente“ Incidents. Die TTL (Time To Live) steuert, wie lange rekursive Resolver Antworten speichern dürfen. Allerdings wirkt TTL nur, wenn der Record zuvor bereits gecached wurde. Ein TTL-Change greift nicht rückwirkend für bestehende Caches, sondern erst bei der nächsten Abfrage nach Ablauf der alten TTL.

TTL-Effekt korrekt einschätzen

Wenn ein Record gestern eine TTL von 86400 Sekunden hatte und heute auf 300 Sekunden reduziert wird, können Resolver, die gestern gecached haben, noch bis zu 24 Stunden „alt“ bleiben. Das ist kein Fehler des Providers, sondern DNS-Design.

$\mathrm{MaxDelay}=\mathrm{OldTTL}-\mathrm{AgeInCache}$

Beispiel: OldTTL = 86400, AgeInCache = 20000. Dann kann die maximale Verzögerung bis zur Neubewertung noch 66400 Sekunden betragen. Für Incident-Kommunikation ist diese Zahl entscheidend, weil sie Erwartungsmanagement ermöglicht.

Negative Caching: NXDOMAIN kann „kleben“

Wenn ein Name nicht existiert (NXDOMAIN), dürfen Resolver dieses negative Ergebnis ebenfalls cachen. Die Dauer wird typischerweise durch SOA-Parameter (z. B. negative TTL/Minimum) beeinflusst. Das führt zu dem frustrierenden Effekt: Ein Record wird angelegt, aber manche Resolver liefern weiterhin NXDOMAIN.

• Symptom: NXDOMAIN verschwindet nicht sofort nach dem Anlegen.
• Mitigation: Record korrekt anlegen, SOA/Negative TTL prüfen, betroffene Resolver neu starten/flushen, wenn möglich.
• Owner: DNS/Platform, wenn SOA-Parameter unglücklich sind; Resolver-Team, wenn Cache aktiv geleert werden kann.

Propagation: Mythos, Realität und praxisnahe Erwartungswerte

„DNS-Propagation“ wird oft als magische Wartezeit verstanden. In der Praxis ist Propagation hauptsächlich ein Cache-Thema: Wie schnell bekommen rekursive Resolver das neue Ergebnis? Dazu kommen Delegations- und Registry/Registrar-Updatezeiten, insbesondere bei NS-Änderungen.

• Zone-Record-Änderung (A/AAAA/CNAME): wirkt nach Ablauf bestehender TTLs plus Resolver-Refresh.
• NS-Änderung (Delegation): kann länger dauern, weil Parent-Zone und Glue-Records involviert sind.
• DNSSEC-Änderungen: können durch Caches und Validierungszustände „hart“ fehlschlagen (SERVFAIL), wenn DS/DNSKEY inkonsistent sind.

Operative Empfehlung: Vor geplanten Changes TTL rechtzeitig senken (z. B. 24–48 Stunden vorher), damit im Incident-Fall das „Fenster der Unklarheit“ klein bleibt.

Resolver-Probleme: Erkennen, beweisen, mitigieren

Rekursive Resolver sind zentrale Infrastruktur. Fällt ein Resolver-Cluster aus oder validiert DNSSEC falsch, wirkt das wie ein globaler Service-Ausfall – obwohl die autoritativen Nameserver korrekt sind.

• Typische Symptome: SERVFAIL für viele Domains, hohe Latenz, Timeouts, nur im Corporate Netz betroffen.
• Beweise: Public Resolver liefert korrekt; Corporate Resolver liefert Fehler; Query-Latenz steigt stark.
• Mitigation: Failover auf sekundäre Resolver, temporär Public DNS für kritische Segmente, Cache-Flush/Restart, Rate-Limit prüfen.

Besonders häufig sind EDNS/UDP-Fragmen­tierungsprobleme oder Firewalls, die große UDP-Antworten blocken. Dann scheitern vor allem DNSSEC-signierte Antworten oder große TXT-Records.

DNSSEC als Incident-Treiber: Wenn SERVFAIL plötzlich überall auftaucht

DNSSEC erhöht Integrität, kann aber bei Fehlkonfiguration „hart“ brechen. Typisches Muster: Autoritative Server antworten, aber validierende Resolver liefern SERVFAIL, weil die Signaturkette nicht stimmt.

• Signale: SERVFAIL nur bei validierenden Resolvern, während „+cd“ (Checking Disabled) eine Antwort zeigt.
• Häufige Ursachen: Falscher DS beim Parent, abgelaufene Signaturen, inkonsistente DNSKEYs, Key-Rollover ohne sauberen Ablauf.
• Owner: DNS/Platform/Registrar, abhängig davon, ob DS/Delegation betroffen ist.

Operativ wichtig: Bei DNSSEC-Incidents ist Zeit kritisch, weil Validierungsfehler Nutzer komplett blockieren können. Ein sauber dokumentierter Rollover-Prozess und Monitoring auf Signaturablauf reduziert das Risiko.

Split-Horizon und „nur intern kaputt“: Wenn DNS je nach Netzwerk unterschiedlich ist

Viele Unternehmen nutzen Split-Horizon-DNS: interne Resolver liefern andere Antworten als externe. Das ist legitim, führt aber häufig zu Incidents, wenn Zonen versehentlich „divergieren“.

• Symptom: Intern NXDOMAIN oder falsche IP, extern korrekt (oder umgekehrt).
• Beweis: Abfrage über internen Resolver liefert anderes Ergebnis als Public DNS.
• Mitigation: Interne Zone/Views prüfen, Forwarding-Regeln korrigieren, Change-Drift beseitigen.

Owner liegt dann selten beim autoritativen Public DNS, sondern beim internen DNS- bzw. Netzwerkteam.

CDN, GeoDNS und Anycast: Warum Regionen unterschiedliche Antworten sehen

Bei modernen Setups kann DNS bewusst unterschiedliche Antworten liefern (GeoDNS, Latency-based Routing, Anycast). Ein Incident entsteht, wenn diese Logik fehlerhaft ist oder ein POP/Region-Backend ausfällt.

• Symptom: Nur bestimmte Regionen bekommen eine falsche IP oder erreichen einen defekten POP.
• Beweis: Vergleich aus mehreren Standorten/Resolvern; Antworten unterscheiden sich.
• Mitigation: Traffic-Steering ändern (CDN), fehlerhafte Targets entfernen, temporär statische Antwort erzwingen.

Mitigation-Toolkit: Was das NOC schnell tun kann, ohne „DNS zu erfinden“

Ein gutes Playbook trennt Diagnostik von Sofortmaßnahmen. Folgende Mitigations sind in vielen Umgebungen realistisch, ohne riskante Eingriffe:

• Resolver-Failover: Clients/Netze auf sekundäre Resolver umschalten, wenn Corporate Resolver betroffen ist.
• Gezieltes Cache-Flush: Nur dort, wo es kontrolliert ist (eigene Resolver-Farm), nicht unkoordiniert auf Clients.
• Temporäre TTL-Senkung: Für kritische Records, wenn noch eine Anpassungsphase bevorsteht (mit Vorsicht, erhöht Query-Last).
• Rollback der Zone: Wenn ein Change falsch war, sauberes Zurückrollen mit Seriennummer-Update.
• Workaround per Hosts/Config: Nur für kleinste kritische Segmente und nur kurzfristig, da operational riskant.
• Provider-Eskalation: Mit reproduzierbaren Beweisen (Authority korrekt/inkorrekt, Delegation-Fehler, DNSSEC-Indizien).

Ticket- und Update-Standard: So kommuniziert das NOC DNS-Probleme klar

DNS-Incidents sind erklärungsbedürftig, weil Cache/TTL die Wahrnehmung verzerren. Standardisieren Sie Updates entlang von Fakten, nicht Vermutungen:

• Was ist betroffen? (FQDN + Record-Typ + Impact-Scope)
• Was sehen wir? (NXDOMAIN/SERVFAIL/Timeout/falsche IP + Beispiele)
• Wo tritt es auf? (Resolver/Region/Netz; Vergleich intern/extern)
• Was ist die Wahrheit? (Antwort direkt vom autoritativen Nameserver)
• Welche TTL/Cache-Effekte erwarten wir? (Restzeit und realistische Propagation-Erwartung)

Outbound-Links für vertiefende Referenzen

• DNS Concepts and Facilities (RFC 1034) für Grundlagen der DNS-Architektur.
• Domain Names – Implementation and Specification (RFC 1035) für Record-Formate und Protokolldetails.
• Negative Caching of DNS Queries (RFC 2308) für NXDOMAIN-Caching und SOA-Parameter.
• DNS Security Introduction and Requirements (RFC 4033) als Einstieg in DNSSEC-Failure-Modes.
• EDNS(0) (RFC 6891) für EDNS/UDP-Größen und typische Timeout-Fallen.
• ISC BIND Dokumentation für Betrieb und Troubleshooting autoritativer/rekursiver DNS-Server.
• Unbound Resolver Projektseite für rekursive Resolver-Implementierung und Betriebsaspekte.

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.