DNS Troubleshooting im Netzwerk: NXDOMAIN, SERVFAIL und Latency Patterns

DNS Troubleshooting im Netzwerk ist eine der zuverlässigsten Methoden, um „alles fühlt sich kaputt an“-Incidents schnell einzugrenzen – denn DNS ist der Einstiegspunkt für fast jede moderne Anwendung. Wenn DNS nicht stimmt, wirken Web, VPN, SaaS, E-Mail und APIs plötzlich „langsam“ oder „down“, obwohl IP-Connectivity, Routing und Firewalls scheinbar sauber sind. Gleichzeitig ist DNS ein Protokoll, das viele Fehlerzustände kennt, die unterschiedlich behandelt werden müssen: NXDOMAIN bedeutet „Name existiert nicht“, SERVFAIL bedeutet „Server konnte nicht korrekt antworten“, und Latenzspitzen im DNS-Lookup erzeugen Kaskaden aus Timeouts, Retries und überlasteten Resolvers. In komplexen Umgebungen kommen weitere Variablen hinzu: Split-Horizon DNS, mehrere Resolver (On-Prem, Cloud, Anycast), DNSSEC-Validierung, Forwarder-Ketten, EDNS0, UDP/TCP-Fallback, MTU-/Fragmentierungsprobleme und Security-Policies. Wer DNS Troubleshooting im Netzwerk professionell beherrscht, kann innerhalb weniger Minuten unterscheiden, ob das Problem in der Namensauflösung selbst liegt (Zone/Records/Delegation), im Resolver-Pfad (Forwarder, Cache, DNSSEC) oder im Transport (Latenz, Loss, Firewall, MTU). Dieser Artikel zeigt Ihnen ein systematisches Vorgehen, um NXDOMAIN, SERVFAIL und typische Latency Patterns sauber zu diagnostizieren – mit evidenzbasierten Checks, klaren Hypothesen und nachhaltigen Fixes.

DNS in 60 Sekunden: Was Sie für Troubleshooting wirklich brauchen

DNS besteht im Betrieb meist aus drei Rollen: Client/Stub Resolver (z. B. OS), rekursiver Resolver (intern oder öffentlich) und autoritative Nameserver (für eine Zone). Wenn ein Client „example.com“ auflösen will, fragt er in der Regel den rekursiven Resolver. Dieser beantwortet aus Cache oder fragt autoritative Server entlang der Delegationskette (Root → TLD → Zone). Die wichtigsten Erkenntnisse fürs Troubleshooting:

• NXDOMAIN kommt typischerweise von einem autoritativen Server (oder aus Cache) und bedeutet: Der Name existiert nicht.
• SERVFAIL kommt häufig vom rekursiven Resolver und bedeutet: Auflösung konnte nicht erfolgreich abgeschlossen werden (Timeouts, DNSSEC, Fehler bei Forwardern, Policy).
• Latenz entsteht meist im rekursiven Teil (Cache miss, Forwarder-Kette, Netzwerkpfad zu Autoritativen), weniger im Client.
• Transport nutzt primär UDP/53, fällt aber bei großen Antworten oder bestimmten Situationen auf TCP/53 zurück.

Als normative Basis für DNS dienen RFC 1034 (Concepts and Facilities) und RFC 1035 (Implementation and Specification). Für DNSSEC ist RFC 4033 ein guter Einstiegspunkt.

Fehlercodes richtig interpretieren: NXDOMAIN, SERVFAIL und NoERROR/NO DATA

Viele Eskalationen scheitern daran, dass Teams DNS-Rückmeldungen falsch deuten. Drei Antworten sind besonders wichtig:

• NXDOMAIN: Der Domainname existiert nicht. Das ist in vielen Fällen ein Daten-/Zonenproblem (Record fehlt, falsche Schreibweise, falscher Search Suffix), nicht unbedingt ein Netzwerkproblem.
• SERVFAIL: Der Resolver konnte die Anfrage nicht erfolgreich abschließen. Häufige Ursachen sind DNSSEC-Validierungsfehler, Timeouts zu autoritativen Servern, Probleme mit Forwardern oder Policy-Blocker.
• NoERROR (NO DATA): Der Name existiert, aber der angefragte Record-Typ (z. B. AAAA) existiert nicht. Das wird oft fälschlich als „DNS kaputt“ interpretiert.

Warum NXDOMAIN manchmal „richtig“ und trotzdem ein Incident ist

NXDOMAIN kann technisch korrekt sein und dennoch betrieblich ein Problem darstellen, z. B. wenn eine interne Anwendung in der falschen Zone angelegt wurde, wenn Split-Horizon-DNS falsch konfiguriert ist oder wenn Clients falsche Suchdomänen verwenden und deshalb unerwartete FQDNs generieren. Der Fix liegt dann nicht im Netzwerkpfad, sondern in Naming, Zone-Design oder Client-Konfiguration.

DNS Latency Patterns: Warum „DNS ist langsam“ selten nur ein Problem ist

DNS-Latenz ist ein Musterproblem. Es reicht nicht, einmal „dig dauert 200 ms“ zu sehen. Sie müssen verstehen, ob es sich um Cache Misses, Forwarder-Serialisierung, Netzwerk-Jitter oder TCP-Fallback handelt. Typische Muster:

• Spike nur beim ersten Lookup: Cache Miss – danach schnell. Normal, wenn TTL niedrig oder Cache leer.
• Jeder Lookup langsam: Forwarder/Resolver überlastet, Netzwerkpfad instabil, DNSSEC-Probleme, oder Policy-Inspection.
• Nur bestimmte Domains langsam: autoritative Server dieser Zone schlecht erreichbar, Geo-/Anycast-Path, Filterung, MTU/TCP-Fallback.
• Nur AAAA oder nur A langsam: Dual-Stack-Asymmetrien, IPv6-Pfadprobleme, NAT64/DNS64 oder Filterregeln.
• Periodische Peaks: Cache-Flushing, Resolver-Rotation, Key-Rollover (DNSSEC), oder Scheduled Jobs/Traffic-Spikes.

EDNS0 und TCP-Fallback als versteckte Latenztreiber

Viele Resolver nutzen EDNS0, um größere UDP-Antworten zu ermöglichen. Wenn UDP-Fragmente oder große UDP-Pakete im Pfad droppen (z. B. durch Firewalls/MTU-Probleme), fällt DNS auf TCP zurück. TCP ist robuster, aber deutlich teurer (Handshake, State, ggf. TLS bei DoT/DoH). Das erzeugt ein sehr typisches Pattern: kleine Antworten schnell, große Antworten langsam oder mit Timeouts.

Für EDNS0 ist RFC 6891 relevant.

Systematisches DNS Troubleshooting: Die 3-Domänen-Methode

Professionelles DNS Troubleshooting lässt sich sehr gut in drei Domänen trennen. Diese Trennung verhindert Tool-Hopping und führt schnell zur richtigen Eskalation.

• Datenebene: Zone/Records/Delegation/TTL – ist der Name überhaupt korrekt definiert?
• Resolver-Ebene: Cache, Forwarder, DNSSEC, Rate Limits – kann der rekursive Resolver korrekt arbeiten?
• Transport-Ebene: UDP/TCP Reachability, Latenz, Loss, MTU/Fragmentation, Firewall/NAT – kommt die Anfrage/Antwort zuverlässig durch?

NXDOMAIN Troubleshooting: Vom Symptom zum Record-Fix

Wenn Sie NXDOMAIN sehen, ist die wichtigste Frage: Von welchem Server kommt diese Antwort? Ein NXDOMAIN vom rekursiven Resolver kann aus Cache stammen oder von einem autoritativen Server übernommen worden sein. Entscheidend ist, ob Sie die Autorität der Antwort verifizieren.

Checkliste für NXDOMAIN

• FQDN prüfen: Ist der Name wirklich korrekt oder wird ein Search Suffix angehängt?
• Split-Horizon: Interner Resolver liefert intern andere Zone als extern? Passt das zu Ihrem Design?
• Autoritative Antwort prüfen: Welche Nameserver sind für die Zone zuständig? Ist Delegation korrekt?
• Wildcard/Overrides: Gibt es lokale Overrides (Hosts-Datei, DNS Policies, RPZ), die NXDOMAIN erzwingen?
• Negative Caching: NXDOMAIN kann gecacht werden (negative TTL). Nach Fix kann es „noch kaputt“ wirken.

Negative Caching ist in RFC 2308 beschrieben – sehr relevant, wenn „wir haben den Record angelegt, aber es geht immer noch nicht“.

SERVFAIL Troubleshooting: Der Resolver ist in Schwierigkeiten

SERVFAIL ist der Fehlercode, bei dem Teams am häufigsten falsch eskalieren. SERVFAIL heißt nicht „Server down“, sondern „Resolver konnte nicht zu einem validen Ergebnis kommen“. Häufige Ursachen:

• DNSSEC Validation Failure: Signaturen/Keys passen nicht, Kette nicht validierbar, falsche DS Records.
• Timeouts: autoritative Nameserver nicht erreichbar (Netzpfad, Provider, Firewall).
• Forwarder-Probleme: interner Resolver forwardet zu Upstream, der blockiert/überlastet ist.
• Rate Limits: RRL oder Resolver-Limits greifen bei Last/Attacken, legitime Queries scheitern.
• Policy/Filtering: RPZ/Threat-Blocking oder Content-Filter erzeugen SERVFAIL-ähnliche Effekte.

DNSSEC als häufiger SERVFAIL-Treiber

DNSSEC erhöht Integrität, aber auch Komplexität. Ein kaputter Key-Rollover oder falsche DS-Einträge führen schnell zu SERVFAIL auf validierenden Resolvern – während nicht-validierende Resolver weiterhin Antworten liefern. Genau dieses Muster ist diagnostisch sehr stark: „Mit Resolver A geht’s, mit Resolver B nicht“.

• Indiz: SERVFAIL nur auf validierenden Resolvern
• Nachweis: DNSSEC-Status/AD-Flag, Validierungslogs am Resolver
• Fix: DS/DNSKEY/RRSIG-Kette korrekt, Rollovers sauber planen

DNSSEC-Überblick: RFC 4033.

Transportprobleme: Wenn DNS eigentlich richtig ist, aber nicht ankommt

DNS ist klein, aber nicht immer klein genug. Große Antworten (DNSSEC, viele Records, große TXT, viele NS/Additional Records) können UDP fragmentieren oder TCP erfordern. Genau hier entstehen klassische Netzwerkfehlerbilder.

UDP/53, Fragmentation und MTU-Fallen

• Symptom: kleine Queries ok, große Queries timeouten oder sind sehr langsam
• Ursachen: UDP-Fragmente werden gedroppt, PMTUD Blackholes, Firewall blockt Fragmente
• Nachweis: PCAP zeigt Fragmentierung oder TCP-Fallback; Drops/Firewall-Logs korrelieren
• Fix: MTU/PMTUD sauber, ICMP gezielt erlauben, EDNS0 Buffer Size sinnvoll konfigurieren

Für PMTUD-Mechaniken sind RFC 1191 (IPv4) und RFC 8201 (IPv6) relevant.

TCP/53 blockiert: Der stille Killer

Viele Security-Policies erlauben UDP/53, blockieren aber TCP/53. Das wirkt lange unauffällig, bis eine Zone/Antwortgröße TCP benötigt. Dann entstehen sporadische Failures, oft nur bei bestimmten Domains (z. B. DNSSEC-signed Zonen). Ein sehr starkes Indiz ist: UDP-Query sieht man, aber TCP-Handshake auf 53 scheitert.

Split-Horizon, Forwarder-Ketten und Anycast: Architektur als Fehlerquelle

In Enterprise-Umgebungen ist DNS selten „ein Server“. Häufig gibt es interne Zonen, Forwarder zu Cloud-Resolvern, Conditional Forwarding, Anycast-Resolver-IPs und manchmal mehrere Resolver-Tiers. Das erhöht die Fehlermöglichkeiten:

• Split-Horizon: intern andere Records als extern; falsch gepflegt führt zu NXDOMAIN intern/external mismatch.
• Conditional Forwarders: bestimmte Domains werden zu speziellen Resolvern geschickt; wenn diese down sind, entsteht SERVFAIL nur für diese Domains.
• Anycast Resolver: gleiche IP, unterschiedliche Standorte; Routing/Latency bestimmt, wohin Queries gehen.
• Cache Divergence: ein Resolver hat stale/negative cache, ein anderer nicht; wirkt wie „sporadisch“.

Praktische Trennmessungen: Schnell zur Fehlerdomäne

DNS eignet sich hervorragend für Trennmessungen, weil Sie sehr gezielt verschiedene Resolver und verschiedene Query-Typen testen können. Sie brauchen dafür kein großes Tooling – die Methodik zählt.

• Resolver-Vergleich: interner Resolver vs. zweiter interner vs. öffentlicher Resolver (nur zum Vergleich, nicht als Dauerlösung)
• Record-Typ-Vergleich: A vs. AAAA vs. TXT; große Antworten provozieren MTU/TCP-Fallback
• Cache Miss simulieren: Random Subdomain (falls erlaubt) oder TTL/Cache flush in Testumgebung
• Transport-Vergleich: UDP vs. TCP Query (wenn Tooling vorhanden), um TCP/53-Blocker zu entlarven
• Standort-Vergleich: gleiche Query aus anderem Standort/Netzsegment → Anycast/Provider-Pfad sichtbar

Runbook-Baustein: DNS Troubleshooting in 15 Minuten

• Minute 0–3: Fehlercode klassifizieren (NXDOMAIN vs. SERVFAIL vs. Timeout) und betroffene Domains/Record-Typen sammeln; betroffene Resolver-IP identifizieren.
• Minute 3–6: Resolver-Vergleich: gleiche Query gegen zweiten Resolver; wenn Unterschiede bestehen, Fokus auf Resolver/DNSSEC/Cache.
• Minute 6–9: Autorität prüfen: welche Nameserver sind zuständig, existiert der Record, stimmt Split-Horizon/Delegation?
• Minute 9–12: Transport prüfen: UDP/53 und TCP/53 erreichbar? Hinweise auf Fragmentation/TCP-Fallback/MTU-Blackholes (große Records testen).
• Minute 12–15: Fix-Richtung wählen: Record/Zone/TTL/Negative Cache (NXDOMAIN), DNSSEC/Forwarder/Policy (SERVFAIL), oder Netzwerk/Firewall/MTU (Latency/Timeout). Danach Verifikation mit reproduzierbaren Queries und Perzentilen (P95/P99 Lookup-Time).

Stabile Baselines: Damit DNS nicht zum Dauerthema wird

DNS Troubleshooting wird deutlich einfacher, wenn Sie Baselines für Antwortzeiten und Fehlercodes haben – getrennt nach Resolver, Standort und Domain-Kategorie (intern/external, signed/unsigned).

• Resolver Telemetrie: QPS, Cache hit ratio, SERVFAIL rate, NXDOMAIN rate, latency percentiles
• Transport Telemetrie: UDP vs. TCP Anteil, Fragmentation-Indizien, Drops auf Firewalls
• Change-Markierung: DNSSEC-Rollovers, Zone-Updates, Forwarder-Änderungen als Events sichtbar machen
• Policy Governance: RPZ/Filtering dokumentieren; klare Erwartung, ob NXDOMAIN/REFUSED/SERVFAIL genutzt wird

Weiterführende Quellen für Standards und Praxis

• RFC 1034 für DNS-Konzepte und Namensraum
• RFC 1035 für DNS-Protokollspezifikation
• RFC 2308 für Negative Caching (wichtig bei NXDOMAIN „bleibt“ nach Fix)
• RFC 4033 für DNSSEC-Überblick (SERVFAIL durch Validation)
• RFC 6891 für EDNS0 (Antwortgrößen, UDP/TCP-Fallback-Muster)
• Wireshark Dokumentation für DNS-Analyse, Flags, EDNS0 und Timing
• tcpdump Manpage für effiziente Captures und Filter

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.