DNS-Diagnose in Wireshark: Query, Response und Cache-Verhalten

DNS-Diagnose in Wireshark gehört zu den schnellsten Wegen, um scheinbar „mysteriöse“ Applikationsprobleme auf harte Fakten herunterzubrechen: Wird überhaupt eine Anfrage (Query) gestellt? Kommt eine Antwort (Response) zurück? Ist der Resolver erreichbar, ist die Antwort valide, und kommt sie aus einem Cache oder wirklich aus dem autoritativen DNS? Gerade im NOC wirken viele Incidents zunächst wie Netzwerkfehler („Service down“, „Login hängt“, „API sporadisch langsam“), obwohl die IP-Konnektivität völlig in Ordnung ist. In der Praxis sind es häufig DNS-Zeitouts, falsche Records, aggressive Caches, negative Caching-Effekte, EDNS- und MTU-Themen oder schlicht eine Verzögerung durch Retries, die sich erst in der Paketspur sauber nachweisen lässt. Wireshark macht die DNS-Kommunikation transparent: Sie sehen Query-Typen (A/AAAA/CNAME/SRV), Transaction IDs, Flags (RD/RA/AA), Response Codes (NXDOMAIN/SERVFAIL), TTLs und die zeitliche Abfolge von Retries. Dieser Artikel zeigt einen NOC-tauglichen Workflow für DNS-Diagnose in Wireshark: von Capture-Setup und Filtern über das Lesen von Query und Response bis hin zum Cache-Verhalten entlang der gesamten DNS-Kette (Stub Resolver, lokaler Cache, rekursiver Resolver, autoritative Server) – inklusive typischer Muster, mit denen Sie echte Ursachen von Messrauschen unterscheiden.

Voraussetzung: Ein Capture, das DNS wirklich abbildet

DNS-Diagnose scheitert selten an Wireshark, sondern an einem Capture, der am falschen Ort oder mit falschem Scope erstellt wurde. DNS ist außerdem ein Kettenprozess: Client fragt häufig einen rekursiven Resolver, der wiederum autoritative Nameserver abfragt. Wenn Sie nur an einer Stelle mitschneiden, sehen Sie oft nur die Hälfte der Geschichte.

• Capture-Punkt wählen: Für schnelle NOC-Diagnose ist ein Capture nahe am betroffenen Client oft am effektivsten, weil Sie dort sehen, ob der Client überhaupt fragt und wie schnell Antworten zurückkommen.
• Beidseitige Sicht, wenn möglich: Bei komplexen Fällen ist zusätzlich ein Capture am rekursiven Resolver sinnvoll (Client↔Resolver und Resolver↔Internet/Authoritative).
• UDP und TCP berücksichtigen: DNS läuft meist über UDP/53, wechselt aber bei großen Antworten, DNSSEC oder Truncation (TC-Flag) auf TCP/53.
• Scope klein halten: Filtern Sie früh nach Client-IP, Resolver-IP und Port 53, um Datenmenge und Risiko zu reduzieren.

Wireshark selbst ist unter Wireshark dokumentiert, die DNS-Protokollbasis finden Sie in RFC 1035 (DNS).

Die wichtigsten Wireshark-Display-Filter für DNS im NOC

Wireshark-Display-Filter sind der Schlüssel, um in Minuten statt in Stunden zu arbeiten. Für DNS-Diagnosen reichen wenige Filterkombinationen, die Sie in 80% der Fälle ans Ziel bringen.

• Alles DNS: dns
• DNS nur zwischen Client und Resolver: ip.addr == 10.0.0.10 and ip.addr == 10.0.0.53 and dns
• Nur Queries: dns.flags.response == 0
• Nur Responses: dns.flags.response == 1
• Nur Fehlercodes: dns.flags.rcode != 0
• Nur NXDOMAIN: dns.flags.rcode == 3
• Nur SERVFAIL: dns.flags.rcode == 2
• DNS über TCP: tcp.port == 53
• DNS über UDP: udp.port == 53

Wenn Sie gezielt nach einem Namen suchen, nutzen Sie im DNS-Detailbaum die Felder zu Query Name (qname) und Query Type (qtype) oder die Wireshark-Suche (Find Packet) nach dem Domainnamen.

DNS Query lesen: Welche Anfrage wird wirklich gestellt?

Eine DNS-Query ist mehr als „Name → IP“. Für die Diagnose sind vor allem Query Name, Query Type und die Flags relevant. In Wireshark finden Sie diese Informationen im DNS-Layer unter „Queries“ sowie im Header.

Query Name und Query Type

• qname: der abgefragte Name (z. B. api.example.com)
• qtype: der Record-Typ, z. B. A (IPv4), AAAA (IPv6), CNAME (Alias), SRV (Service), TXT (Policies/Verifikation)

Typische NOC-Falle: Der Client fragt AAAA zuerst, bekommt aber Probleme im IPv6-Pfad. In Wireshark sehen Sie dann AAAA-Queries mit Timeouts oder SERVFAIL, während A-Queries schnell beantwortet werden. Das wirkt wie „DNS ist langsam“, ist aber oft „IPv6 ist kaputt“.

Flags: RD, RA und was sie im Betrieb bedeuten

• RD (Recursion Desired): Client möchte rekursive Auflösung. Im Client↔Resolver-Verkehr fast immer gesetzt.
• RA (Recursion Available): Resolver signalisiert, dass er Rekursion anbietet. Fehlt RA bei einem „Resolver“, ist das ein starker Hinweis auf falsches Ziel oder eine falsch konfigurierte Instanz.
• AA (Authoritative Answer): Antwort ist autoritativ. Im Client↔rekursiver Resolver-Verkehr ist AA oft nicht gesetzt, weil der Resolver nicht autoritativ ist.

DNS Response lesen: Antwort, Fehler und „was ist wirklich zurückgekommen?“

Die Response entscheidet, ob ein Incident DNS-bedingt ist oder nicht. In Wireshark prüfen Sie dabei systematisch: Response Code, Answers, Authority, Additional sowie TTLs.

Response Codes, die im NOC am häufigsten zählen

• NOERROR (0): Die Anfrage wurde erfolgreich verarbeitet. Wichtig: NOERROR bedeutet nicht automatisch „es gab eine IP“. Es kann auch „NOERROR, aber no data“ sein (z. B. AAAA existiert nicht).
• SERVFAIL (2): Der Resolver konnte die Anfrage nicht erfolgreich auflösen (z. B. DNSSEC-Validierung, Timeout zu Authoritative, Upstream-Probleme). SERVFAIL ist oft ein Resolver-/Upstream-Problem, nicht „Domain existiert nicht“.
• NXDOMAIN (3): Name existiert nicht. Häufig echte Konfigurationsfehler (falscher Hostname) oder Split-DNS/Views, manchmal auch „negative caching“-Thema.
• REFUSED (5): Server verweigert Antwort (Policy, ACL, falscher Client, Rate-Limit).

Answers, CNAME-Ketten und warum „es sieht richtig aus“ trotzdem falsch sein kann

Viele moderne Setups nutzen CNAMEs (CDNs, SaaS, Service-Mesh). In Wireshark sehen Sie dann in der Answer Section zuerst einen CNAME und anschließend A/AAAA für das Ziel. Typische Probleme:

• Unvollständige Kette: CNAME zeigt auf einen Namen, der nicht auflösbar ist (NXDOMAIN in Folgequeries).
• Sehr niedrige TTL: führt zu vielen Cache-Misses und dadurch zu Last/Spikes beim Resolver.
• Split-Horizon: intern anderer CNAME/Record als extern; Client im falschen DNS-View.

Zeitverhalten: Retries, Timeouts und die Illusion „DNS ist langsam“

DNS-Probleme wirken oft wie Latenzprobleme, sind aber in Wahrheit Retry-Kaskaden. Ein einzelner verlorener DNS-Response kann je nach Client/Resolver zu mehreren Sekunden Verzögerung führen.

Wie Sie Retries in Wireshark erkennen

• Gleiche Transaction ID? Bei UDP können Retries neue IDs nutzen, aber oft sehen Sie wiederholte Queries mit identischem qname/qtype.
• Gleiche Query in kurzen Abständen: deutet auf Timeout und Retry-Policy hin.
• Wechsel des Servers: Client probiert Resolver A, dann Resolver B (z. B. zwei konfigurierten DNS-Servern).

Praktischer NOC-Tipp: Sortieren Sie nach „Time“ und nutzen Sie die „Delta time displayed“-Spalte (Wireshark kann Zeitdeltas anzeigen), um zu sehen, ob das Delay durch Retries entsteht oder ob die Antworten langsam sind.

UDP vs. TCP bei DNS: Truncation, DNSSEC und große Antworten

Wenn DNS-Antworten zu groß für UDP werden (klassisch wegen EDNS0, DNSSEC, vielen Records), kann der Server das TC-Flag (Truncated) setzen. Dann muss der Client über TCP erneut anfragen. Das sieht in Wireshark so aus:

• UDP-Response mit TC=1 (truncated)
• anschließend TCP-Handshake und gleiche DNS-Query über TCP/53

Wenn dieser Wechsel häufig passiert, kann das spürbar werden (mehr RTT, mehr State auf Firewalls). Hintergrund zu EDNS0 ist in RFC 6891 (EDNS(0)) beschrieben.

Cache-Verhalten verstehen: Wo DNS wirklich „gewinnt“ oder „verliert“

DNS-Caching existiert auf mehreren Ebenen. Wenn Sie Cache-Verhalten in Wireshark beurteilen möchten, müssen Sie wissen, welche Ebene Sie gerade beobachten. Eine schnelle Einordnung:

• Stub Resolver: Cache im Client-OS (und teils im Browser/Runtime). Kann dazu führen, dass überhaupt keine DNS-Queries im Trace erscheinen, obwohl die App „DNS nutzt“.
• Lokaler Resolver: z. B. ein DNS-Dienst auf dem Endgerät oder am Standort (Forwarder).
• Rekursiver Resolver: zentrale Resolver im Unternehmen oder beim Provider; hier passiert der Großteil der Caching-Logik.
• Autoritativ: hält Zonen, liefert autoritative Antworten; caching ist dort nicht das Ziel, sondern korrekte Auskunft.

Cache-Hit vs. Cache-Miss im Trace unterscheiden

Ein Cache-Hit am rekursiven Resolver zeigt sich typischerweise durch sehr kurze Antwortzeiten und dadurch, dass der Resolver keinen Upstream-Query auslöst. Das können Sie prüfen, wenn Sie am Resolver selbst capturen:

• Cache-Hit: Client-Query → schnelle Response; keine gleichzeitigen Queries des Resolvers an autoritative Server.
• Cache-Miss: Client-Query → Resolver fragt Upstream (Root/TLD/Authoritative) → Resolver antwortet danach an Client.

Wenn Sie nur am Client capturen, ist der Unterschied indirekter: sehr schnelle Antworten deuten auf Cache-Hits (oder sehr nahe Resolver), längere Antworten mit sporadischen Timeouts deuten auf Miss/Upstream-Probleme.

TTL lesen: „Wie lange hält diese Antwort im Cache?“

In Wireshark sehen Sie in der Answer Section die TTL-Werte. Wichtig: In vielen Umgebungen ist der TTL-Wert, den Sie am Client sehen, bereits „runtergezählt“, weil der rekursive Resolver die Antwort schon seit einer Weile im Cache hält. Das ist für die Diagnose nützlich, weil es Ihnen zeigt, ob Sie gerade einen „frischen Miss“ oder einen „gealterten Hit“ sehen.

Wenn TTL_orig der ursprünglich autoritative TTL ist und a das Alter (Zeit seit dem Cache-Eintrag), dann ist der verbleibende TTL:

${\mathrm{TTL}}_{\mathrm{remain}}={\mathrm{TTL}}_{\mathrm{orig}}-a$

Für NOC-Praxis bedeutet das: Wenn Sie wiederholt Antworten mit sehr niedrigem TTL sehen (z. B. 1–5 Sekunden), sind Cache-Misses bald unvermeidlich. Das kann Resolver-Last und Latenzspitzen erklären, besonders bei stark frequentierten Domains.

Negative Caching: NXDOMAIN ist nicht immer „sofort weg“

Ein häufig unterschätzter Effekt ist negative caching: Wenn ein Name nicht existiert (NXDOMAIN) oder „no data“ liefert, kann der Resolver diese Negativantwort für eine Zeit cachen. Das ist sinnvoll, kann aber bei Änderungen („Record gerade angelegt“) zu vermeintlich „stuck“ Verhalten führen.

• Symptom: Ein Name wurde neu angelegt, aber Clients sehen weiterhin NXDOMAIN.
• Ursache: Negative Cache TTL hält die Negativantwort fest.
• Wireshark-Hinweis: Wiederholte NXDOMAIN-Responses mit sehr kurzen Antwortzeiten (Cache-Hit), ohne Upstream-Queries.

Der Standard zu negativen Caches ist RFC 2308 (Negative Caching). Für die Incident-Kommunikation ist das besonders hilfreich: Nicht „DNS kaputt“, sondern „Negativcache muss auslaufen oder gezielt invalidiert werden“.

Praktische Diagnoseszenarien: Muster, die Sie in Wireshark sofort erkennen

Die folgenden Muster sind im NOC besonders häufig. Wenn Sie sie sicher lesen, lösen Sie viele Tickets ohne Eskalation.

Queries gehen raus, keine Responses kommen zurück

• Interpretation: Netzwerkpfad/Firewall/Policy blockiert, Resolver down, oder UDP/53 wird gedrosselt.
• Wireshark-Check: Sehen Sie ICMP Unreachable? Sehen Sie, dass der Client nach Timeout den zweiten DNS-Server probiert?
• Nächster Schritt: Test mit TCP/53 (falls möglich), Firewall-Regeln, Reachability zum Resolver.

SERVFAIL-Spitzen, aber NXDOMAIN selten

• Interpretation: Resolver kann Upstream nicht sauber erreichen oder DNSSEC/Validierung schlägt fehl.
• Wireshark-Check: SERVFAIL Responses, oft mit Retries; am Resolver-Capture sehen Sie fehlende oder verspätete Upstream-Responses.
• Nächster Schritt: Resolver-Logs, Upstream-Connectivity, DNSSEC-Policy, EDNS/MTU prüfen.

NXDOMAIN nur in bestimmten Netzen oder Standorten

• Interpretation: Split-DNS (Views), falscher Resolver genutzt, Conditional Forwarding fehlt.
• Wireshark-Check: Welcher Resolver wird angesprochen? Sind Suffix/Search-Domains korrekt? Werden unerwartete Namen abgefragt (z. B. host.localdomain)?
• Nächster Schritt: DHCP Option 6 (DNS-Server), Search Domain, Split-Horizon-Konfiguration.

Sehr langsame Responses, aber keine Retries

• Interpretation: Upstream-Lookup dauert (Cache-Miss), Resolver überlastet, oder Netzlatenz zum Resolver ist hoch.
• Wireshark-Check: Zeit zwischen Query und Response ist konstant hoch; TTL in Responses eventuell hoch (frisch aus Upstream).
• Nächster Schritt: Baseline für Resolver-RTT, Resolver-Performance (CPU/Cache), Standortpfad.

Cache-Performance greifbar machen: Einfache Kennzahl für interne SLAs

Für interne Betriebsziele ist oft nicht nur „DNS funktioniert“ relevant, sondern „DNS ist schnell und stabil“. Ein praktikabler Hebel ist die Cache-Hit-Rate am rekursiven Resolver. Konzeptuell lässt sie sich als Verhältnis von Cache-Hits zu allen DNS-Anfragen definieren. Wenn H die Hits und M die Misses sind:

$\mathrm{HitRate}=\frac{H}{H+M}$

Wireshark selbst ist keine vollständige Statistikplattform, aber in einem Resolver-nahen Capture können Sie Misses oft daran erkennen, dass unmittelbar nach Client-Queries Upstream-Queries erfolgen. Für ein SLA-orientiertes Monitoring kombinieren Teams das meist mit Resolver-Metriken/Logs – Wireshark liefert die Evidence in konkreten Incidents.

Typische Fallstricke: Wenn Wireshark „richtig“ ist, aber Sie falsch schließen

• „Keine DNS-Pakete im Capture“: Das kann bedeuten, dass der Client aus lokalem Cache bedient wird oder DNS-over-HTTPS/DoT nutzt. Prüfen Sie, ob stattdessen HTTPS zu einem DoH-Endpoint läuft.
• „DNS ist langsam“: Oft ist es Retry-Verhalten durch sporadische Drops. Prüfen Sie Wiederholungen, Wechsel des Resolvers und Paketverlust auf dem Pfad.
• „NXDOMAIN = falscher Name“: Kann auch Split-DNS oder negative caching sein. Prüfen Sie Resolver-Quelle, TTL/Cache und Standortabhängigkeit.
• „TC-Flag = DNS kaputt“: Truncation ist nicht zwangsläufig Fehler, aber sie kann Performance beeinflussen, wenn TCP/53 blockiert oder teuer ist.

Outbound-Quellen für vertiefendes Verständnis

Für die DNS-Grundlagen (Header, Sections, Record-Typen) ist RFC 1035 (DNS) die zentrale Referenz. Für negative caching und die Auswirkungen von NXDOMAIN/no data ist RFC 2308 (Negative Caching) besonders relevant. Für EDNS0 (größere UDP-Payloads, Option Handling, Truncation-Kontext) ist RFC 6891 (EDNS(0)) hilfreich. Für Wireshark-Funktionen, Display-Filter und Bedienkonzepte ist die Projektseite Wireshark die verlässlichste Anlaufstelle.

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.