DNS in PCAP diagnostizieren: Cache vs. Resolver vs. Authoritative

Bei Störungen im Betrieb ist DNS oft der erste unsichtbare Engpass: Anwendungen melden „Timeout“, Webseiten laden nur teilweise, APIs liefern sporadisch Fehler oder Verbindungen scheitern scheinbar zufällig. Genau hier wird das Thema DNS in PCAP diagnostizieren: Cache vs. Resolver vs. Authoritative zum entscheidenden Werkzeug für NOC, SRE und Netzwerkbetrieb. Wer in Paketmitschnitten sauber trennt, ob die Ursache im lokalen Cache, im rekursiven Resolver oder beim autoritativen Nameserver liegt, spart Eskalationsschleifen und reduziert die Mean Time to Repair deutlich. Statt pauschal „DNS ist langsam“ zu melden, entsteht eine belastbare, technisch präzise Aussage mit klarer Ownership. Dieser Artikel zeigt praxisnah, wie du DNS-Verhalten in PCAP-Dateien systematisch analysierst, welche Paketmuster typische Fehlerbilder aufdecken, wie du Timeouts, NXDOMAIN, SERVFAIL, Truncation, Retries und Delegationsprobleme richtig einordnest und wie aus Rohpaketen ein verwertbarer Incident-Output für große Teams wird. Dabei liegt der Fokus auf einer methodischen Trennung der drei Ebenen Cache, Resolver und Authoritative, damit Diagnosen reproduzierbar, auditfähig und im Tagesbetrieb sofort nutzbar sind.

Warum DNS-Störungen so oft falsch eingeordnet werden

DNS-Fehler sehen auf Anwendungsebene häufig gleich aus: „Service nicht erreichbar“, „Host unbekannt“, „sporadische Verbindungsabbrüche“. Technisch können die Ursachen jedoch völlig unterschiedlich sein. Ein abgelaufener Cache-Eintrag verhält sich anders als ein überlasteter Resolver oder ein fehlerhafter autoritativer Server. Wenn diese Ebenen vermischt werden, eskaliert man an das falsche Team und verlängert die Ausfallzeit.

• Cache-Probleme betreffen häufig nur einzelne Clients oder Standorte.
• Resolver-Probleme wirken meist domänenübergreifend für eine Nutzergruppe.
• Authoritative-Probleme zeigen sich oft global oder regionsabhängig für eine bestimmte Zone.
• Netzwerkpfadfehler können DNS-Symptome imitieren, obwohl die Zone korrekt ist.

Ein PCAP-basierter Ansatz schafft hier Klarheit, weil er den tatsächlichen Query-/Response-Fluss sichtbar macht.

DNS-Rollen im Incident sauber trennen: Cache, Resolver, Authoritative

Cache-Ebene

Der Cache sitzt typischerweise im Client, im Betriebssystem-Stub, im Browser, im Sidecar oder in einem lokalen DNS-Forwarder. Sichtbar in PCAP ist ein Cache-Treffer indirekt: Es fehlt die erwartete Query auf dem Draht, oder es gibt deutlich weniger Queries als Anwendungsaufrufe vermuten lassen.

Resolver-Ebene

Der rekursive Resolver nimmt Anfragen vom Stub entgegen, führt Iteration/Recursion durch, cached Resultate und beantwortet den Client. In PCAP erkennst du, ob der Resolver sauber antwortet, ob Retries auftreten, ob Upstream-Lookups dauern und ob negative Antworten (NXDOMAIN/SERVFAIL) konsistent sind.

Authoritative-Ebene

Der autoritative Server ist die Quelle der Zonendaten. Probleme hier zeigen sich in fehlerhaften oder inkonsistenten Antworten, hoher Antwortzeit, fehlerhaften Delegationen, DNSSEC-Fehlerbildern oder nicht erreichbaren Nameservern der Zone.

PCAP-Strategie fürs NOC: Wo mitschneiden, um nicht im Blindflug zu arbeiten

Die beste Analyse scheitert, wenn am falschen Punkt mitgeschnitten wird. Für DNS empfiehlt sich ein Multi-Vantage-Ansatz, besonders bei intermittierenden Störungen.

• Client-nah: Zeigt, was der Stub sendet und was tatsächlich zurückkommt.
• Resolver-nah: Zeigt Eingangsqueries vom Client und Upstream-Verhalten.
• Egress/Edge: Hilft, Paketverlust, Fragmentierung oder Filtereffekte zu erkennen.
• Authoritative-nah: Belegt, ob Anfragen den autoritativen Server erreichen.

Wenn nur ein Capture-Punkt möglich ist, sollte der Resolver-nahe Mitschnitt priorisiert werden, weil dort Client- und Upstream-Perspektive oft zusammenlaufen.

Wireshark-Analyse vorbereiten: Filter und Spalten, die sofort Mehrwert liefern

Display-Filter für DNS-Kernanalyse

• DNS-Verkehr isolieren (UDP und TCP Port 53 berücksichtigen).
• Queries und Responses getrennt betrachten.
• Antwortcodes (RCODE) sichtbar machen.
• Retransmissions, Truncation und TCP-Fallback schnell auffinden.

Sinnvolle Spalten in der Paketansicht

• Transaktions-ID (TXID)
• Query Name (QNAME)
• Record Type (A, AAAA, CNAME, NS, SOA, TXT, SRV)
• Response Code (NOERROR, NXDOMAIN, SERVFAIL)
• Antwortzeit pro Query/Response-Paar
• Flags (RD, RA, AA, TC, AD, CD)

Diese Spalten reduzieren Analysezeit erheblich, weil Muster sofort sichtbar werden.

Die zentrale Methode: Query-Pfad als Kette lesen

Für jede betroffene Domain analysierst du nicht isolierte Pakete, sondern die komplette Kette vom Stub bis zur finalen Antwort. Ein belastbarer Workflow besteht aus vier Schritten:

• 1) Ausgangsquery identifizieren (Zeit, Client, QNAME, QTYPE).
• 2) Resolver-Antwort auswerten (RCODE, Answer/Authority/Additional).
• 3) Falls nötig Upstream-Pakete des Resolvers verfolgen (Delegation, Glue, Retry).
• 4) Ergebnis mit Applikationszeitpunkt korrelieren (Fehlerfenster, Wiederholungen).

So entsteht eine nachvollziehbare Ursache-Wirkung-Kette statt einer Vermutung auf Basis einzelner Frames.

Cache-Verhalten in PCAP erkennen: Treffer, Misses und Stale-Zustände

Typische Cache-Treffer-Signale

• Wiederholte App-Requests ohne entsprechende DNS-Queries am Client-Uplink.
• Sehr kurze Auflösungszeiten ohne Upstream-Aktivität am Resolver.
• Konsistente Antworten bis kurz vor TTL-Ablauf.

Cache-Miss und Refresh

• Nach TTL-Ablauf plötzlich wieder sichtbare Upstream-Queries.
• Burst von identischen Queries bei hoher Last („thundering herd“).
• Kurzzeitige Latenzspitzen beim erstmaligen Refill.

Stale- oder inkonsistente Cache-Effekte

• Unterschiedliche Antworten für gleiche QNAME/QTYPE je nach Clientgruppe.
• Alte CNAME-Ketten trotz bereits geänderter Zone.
• Sporadische Fehler direkt nach Changes, bis alle Caches konvergiert sind.

Gerade nach DNS-Änderungen sind Cache-Effekte der häufigste Grund für „funktioniert bei mir, nicht bei dir“.

Resolver-Diagnose: Wenn Recursion der Engpass ist

Der Resolver ist oft die betriebliche Schaltstelle. In PCAP zeigen sich resolverseitige Probleme sehr klar, wenn man auf Timing, Retry-Muster und RCODE-Verteilung achtet.

• Viele parallele Retries auf denselben Upstream deuten auf Erreichbarkeits- oder Lastprobleme.
• SERVFAIL-Spitzen bei ansonsten korrekten Autoritatives sprechen für Resolver-internes Problem, Policy oder DNSSEC-Validation.
• Lange Antwortzeiten bei allen Domains können auf Ressourcenengpässe oder Netzwerkpfad zum Upstream hinweisen.
• Nur bestimmte Zonen betroffen: eher Delegation, DNSSEC oder autoritative Besonderheit.

Negative Caching richtig interpretieren

NXDOMAIN ist nicht automatisch „DNS kaputt“. Wenn NXDOMAIN korrekt und wiederholbar für einen falschen Namen kommt, funktioniert DNS technisch oft einwandfrei. Kritisch wird es, wenn legitime Namen unerwartet NXDOMAIN liefern oder unterschiedliche Resolver unterschiedliche RCODEs zurückgeben.

Authoritative-Diagnose: Delegation, Glue, SOA und Zonenkonsistenz

Auf autoritativer Ebene entstehen viele schwer erkennbare Fehlerbilder. Im PCAP helfen folgende Prüfungen:

• Delegation: Stimmen NS-Records der Parent-Zone mit der Child-Realität überein?
• Glue: Sind notwendige A/AAAA-Informationen in der Kette vorhanden?
• AA-Flag: Kommt die Antwort wirklich autoritativ?
• SOA: Sind Serial und negative TTL plausibel?
• Konsistenz: Antworten alle autoritativen Nameserver gleich?

Ein klassisches Incident-Muster ist Split-Authority: Ein Teil der autoritativen Server liefert neue Daten, ein anderer noch alte. Dann treten scheinbar zufällige Fehler auf, abhängig davon, welchen NS der Resolver gerade nutzt.

Antwortcodes praxisnah lesen: NOERROR, NXDOMAIN, SERVFAIL, REFUSED

• NOERROR: Technisch erfolgreiche Antwort; trotzdem kann die Antwort inhaltlich unbrauchbar sein (z. B. leere Antwort ohne erwartete Records).
• NXDOMAIN: Name existiert nicht; korrekt oder fehlerhaft je nach Erwartung.
• SERVFAIL: Server konnte Anfrage nicht erfolgreich verarbeiten; oft transient, häufig resolver- oder dnssec-nah.
• REFUSED: Anfrage policy-bedingt abgelehnt; wichtig bei ACLs, Split-Horizon oder fehlender Recursion-Berechtigung.

Im Ticket sollte niemals nur der RCODE stehen, sondern stets Kontext: betroffenes QNAME, Zeitpunkt, Quelle, Resolver, Wiederholbarkeit.

UDP vs. TCP bei DNS: Truncation und Fallback korrekt deuten

Viele Teams übersehen DNS über TCP, obwohl er bei großen Antworten entscheidend ist. Setzt ein Server das TC-Flag, muss der Client/Resolver per TCP nachfassen. Wenn dieser Fallback blockiert oder fehlerhaft ist, entstehen intermittierende Auflösungsprobleme, oft nur bei DNSSEC, großen TXT-Records oder umfangreichen Antwortsets.

• TC-Flag gesetzt, aber kein TCP-Handshake: wahrscheinlich Filter oder Client-Implementierungsproblem.
• TCP-Handshake erfolgreich, aber DNS-Dialog bricht ab: eher Applikations-/Serverproblem.
• Nur große Antworten betroffen: MTU/Fragmentierung/Fallback prüfen.

Retry-Muster und Timeouts quantifizieren

Für Incident-Berichte ist nicht nur „es gab Retries“ wichtig, sondern deren Ausmaß. Eine einfache Kennzahl ist die Retry-Rate pro Query.

$\mathrm{RetryRate}=\frac{\mathrm{Anzahl zusätzlicher Queries}}{\mathrm{Anzahl ursprünglicher Queries}}$

Auch die Erfolgsquote im Zeitfenster hilft bei der Priorisierung:

$\mathrm{SuccessRate}=\frac{\mathrm{NOERROR Responses}}{\mathrm{Gesamtanzahl Responses}}$

Diese Metriken machen Trends sichtbar und helfen, Schweregrade objektiver festzulegen.

Latenzanalyse im DNS-Dialog

Nicht jede hohe DNS-Latenz ist ein Autoritative-Problem. Miss die Antwortzeiten auf jeder Ebene separat:

• Client → Resolver
• Resolver → TLD/Delegation
• Resolver → Authoritative

Wenn nur der erste Abschnitt hoch ist, liegt der Engpass häufig nahe am Client oder am Resolver-Frontend. Wenn nur der dritte Abschnitt hoch ist, ist eher die authoritative Seite oder deren Erreichbarkeit betroffen.

DNSSEC-Indikatoren in PCAP für den Betrieb

DNSSEC bringt Sicherheit, aber auch zusätzliche Fehlerbilder. Im Incident-Alltag sind folgende Beobachtungen relevant:

• Viele SERVFAIL nur bei validierenden Resolvern.
• Große Antworten, häufiger TCP-Fallback.
• Unterschiedliche Ergebnisse zwischen Resolvern mit und ohne Validation.
• Auffälligkeiten bei DS/DNSKEY-bezogenen Abfragen.

Wichtig: Nicht sofort DNSSEC deaktivieren. Erst sauber belegen, ob die Validation der Auslöser ist und auf welcher Zone der Bruch entsteht.

Split-Horizon, GeoDNS und Anycast: warum „gleicher Name, andere Antwort“ normal sein kann

In modernen Architekturen ist es normal, dass derselbe FQDN je nach Standort, Quellnetz oder Resolver andere Antworten liefert. Ohne diesen Kontext wirkt es wie Fehler. In PCAP musst du daher immer Quelle, Standort und Resolver-Pfad dokumentieren.

• Split-Horizon: interne und externe Sicht unterscheiden sich bewusst.
• GeoDNS: Antwort richtet sich nach geografischer Nähe oder Policy.
• Anycast-Resolver: gleiche IP, aber unterschiedliche Instanz je nach Routing.

Für saubere Diagnosen sollten Vergleichscaptures immer unter identischen Bedingungen erfolgen.

Incident-Playbook: DNS in PCAP in 15 Minuten triagieren

Minute 1–3: Scope setzen

• Betroffene Domain(s), Clients, Zeitraum, Fehlerbild

Minute 4–7: Resolver-Antwortqualität prüfen

• RCODE-Verteilung, Latenz, Retries, TC-Flag, Antwortinhalt

Minute 8–11: Upstream/Authoritative-Pfad prüfen

• Delegation, NS-Konsistenz, Erreichbarkeit, Zeitverhalten

Minute 12–15: Aussage für Eskalation formulieren

• Ebene benennen: Cache vs Resolver vs Authoritative
• Evidence-Punkte: 3–5 harte Befunde
• Nächster Owner und Handlungsvorschlag

Template für Ticket und Eskalation

• Incident-ID: eindeutige Referenz
• Betroffener FQDN/QTYPE: z. B. api.example.tld / A
• Capture-Punkt: Client-nah, Resolver-nah, Edge
• Zeitraum: inkl. Zeitzone
• Befund 1: RCODE-Muster (z. B. 68% SERVFAIL)
• Befund 2: Latenz (Median, P95)
• Befund 3: Retry-/Timeout-Verhalten
• Befund 4: Delegation/Authoritative-Konsistenz
• Hypothese: primärer Fehlerort
• Nächster Schritt: konkrete Aktion mit Owner

Häufige Fehlinterpretationen bei DNS-PCAPs

• NXDOMAIN pauschal als „Resolver kaputt“ bewerten.
• Nur UDP betrachten und TCP-Fallback ignorieren.
• Einzelne Fehlpakete überbewerten, ohne Häufigkeit zu prüfen.
• Asymmetrische Sichtpunkte als vollständige Wahrheit behandeln.
• Applikations-Timeout automatisch DNS zuschreiben, ohne Query-Beleg.

Outbound-Links für vertiefende Praxis

• Wireshark Dokumentation
• Wireshark User’s Guide
• Wireshark Display-Filter
• RFC 1034 – DNS Concepts and Facilities
• RFC 1035 – DNS Implementation and Specification
• RFC 2308 – Negative Caching
• RFC 7766 – DNS over TCP
• IANA Root Server Informationen

Praktische Taxonomie für wiederverwendbare NOC-Analysen

Damit Diagnosen teamübergreifend konsistent bleiben, lohnt sich eine feste Klassifikation pro Incident:

• DNS-CACHE-STALE: veraltete oder inkonsistente Cache-Antworten
• DNS-RESOLVER-TIMEOUT: Recursion-/Upstream-Timeouts
• DNS-RESOLVER-SERVFAIL: resolverseitige Fehlerverarbeitung
• DNS-AUTH-DELEGATION: NS/Glue/Parent-Child-Fehler
• DNS-AUTH-INCONSISTENT: abweichende Antworten zwischen autoritativen NS
• DNS-TRANSPORT-TC-TCP: Truncation/Fallback-Probleme
• DNS-POLICY-REFUSED: ACL/Policy-bedingte Ablehnung

Mit einer solchen Taxonomie werden Reports vergleichbar, Trends messbar und Verbesserungen über mehrere Quartale nachvollziehbar.

Im operativen Alltag entscheidet selten ein einzelnes Paket, sondern das saubere Lesen der gesamten DNS-Kette. Wer in PCAPs strukturiert zwischen Cache, Resolver und Authoritative unterscheidet, erkennt die eigentliche Fehlerdomäne schneller, eskaliert präziser und reduziert unnötige Parallelfehler in Incident-War-Rooms. Genau diese methodische Trennung macht aus DNS-Troubleshooting eine reproduzierbare Betriebsfähigkeit statt reaktiver Einzelfallarbeit.

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.