DNS Troubleshooting: NXDOMAIN, Zeitouts und falsche Auflösungen

DNS Troubleshooting gehört zu den wichtigsten Fähigkeiten im IT-Betrieb, weil DNS-Probleme selten wie „DNS-Probleme“ aussehen. Für Nutzer wirkt es eher so: „Webseiten laden nicht“, „Teams geht nicht“, „VPN ist langsam“, „E-Mails kommen nicht an“ oder „Nur diese eine Anwendung spinnt“. In Wirklichkeit ist DNS die Namensauflösungsschicht, die fast jede moderne Kommunikation voraussetzt. Wenn sie ausfällt oder falsche Antworten liefert, sind IP-Verbindungen oft weiterhin möglich – aber niemand findet mehr das richtige Ziel. Besonders häufig begegnen Admins drei DNS-Fehlerklassen: NXDOMAIN (Name existiert nicht), Timeouts (Resolver antwortet zu spät oder gar nicht) und falsche Auflösungen (Name zeigt auf die falsche IP, falsche CNAME-Kette oder falsche Zone). Diese Fehler können lokale Ursachen haben (Client, Cache, falsche DNS-Server, Split-DNS, VPN), aber auch in der Resolver-Kette entstehen (Forwarder, Root/Authoritative, DNSSEC, Firewall/Proxy, Rate Limits). Dieser Leitfaden zeigt Ihnen einen praxiserprobten Standardablauf, um DNS-Probleme systematisch zu finden, zu beweisen und nachhaltig zu beheben – ohne Aktionismus, aber mit klaren Checks, die im Alltag funktionieren.

DNS in der Praxis: Was passiert bei einer Auflösung?

Wenn ein Client einen Hostnamen (z. B. app.example.com) nutzen möchte, stellt er eine DNS-Anfrage an seinen konfigurierten Resolver (meist per DHCP oder VPN gesetzt). Dieser Resolver beantwortet die Anfrage entweder aus dem Cache oder er fragt weiter: entweder direkt iterative DNS-Infrastruktur (Root → TLD → Authoritative) oder über Forwarder/Upstream-Resolver. Das Ergebnis ist typischerweise eine IP-Adresse (A/AAAA-Record) oder eine Kette aus Aliasen (CNAME), die am Ende ebenfalls zu A/AAAA führt. Wichtig: DNS ist nicht „nur ein Server“, sondern häufig eine Kette aus Komponenten, die jede für sich Probleme verursachen kann.

• Stub Resolver (Client): fragt DNS-Server, cacht ggf. lokal.
• Recursive Resolver: liefert die finale Antwort (aus Cache oder durch Nachfragen).
• Forwarder: leitet Anfragen an einen Upstream-Resolver weiter.
• Authoritative DNS: ist „Quelle der Wahrheit“ für eine Zone.

Die DNS-Grundlagen sind in RFC 1034 und RFC 1035 beschrieben.

Fehlerbilder sauber unterscheiden: NXDOMAIN, Timeout, falsche Antwort

DNS-Troubleshooting wird deutlich einfacher, wenn Sie das Symptom korrekt klassifizieren. „DNS geht nicht“ ist zu ungenau. Entscheidend sind Response Codes (Rcodes) und Timing.

• NXDOMAIN: Der Name existiert nicht (aus Sicht des antwortenden Servers). Häufig Ursache: falsche Zone, Tippfehler, Split-DNS, falscher Suchsuffix, unerwünschte Filterung.
• Timeout: Keine Antwort innerhalb der Zeit. Häufig Ursache: Resolver/Forwarder down, Firewall blockt UDP/TCP 53, Paketverlust, Rate Limiting, MTU/Fragmentierung bei großen Antworten.
• Falsche Auflösung: Antwort kommt, ist aber falsch oder unerwartet. Häufig Ursache: Cache-Poisoning-Schutz, alte Caches, falscher Record/TTL, falsches Load-Balancer/Geo-DNS, Split-DNS-Vermischung.

Die wichtigsten Tools für DNS Troubleshooting

Sie benötigen keine exotischen Werkzeuge. Entscheidend ist, dass Sie Abfragen gezielt an bestimmte Resolver richten können und Antworten inklusive TTL, Authority und Zusatzdaten sehen. Unter Linux ist dig der Standard (Referenz: dig(1)). Unter Windows sind nslookup und PowerShell-Resolve-DnsName verbreitet; auch hier ist wichtig, gezielt den Server anzugeben.

• dig: detaillierte Abfragen, ideal für Profis (Antwortsektionen, TTL, Flags).
• nslookup: verbreitet, oft ausreichend für schnelle Checks.
• Resolve-DnsName: Windows PowerShell, gut für strukturierte Ausgaben.
• Packet Capture: Wireshark/tcpdump, wenn Timeouts oder Policy-Blocks vermutet werden (Einstieg: Wireshark-Dokumentation).

Standardablauf: DNS-Probleme systematisch eingrenzen

Dieser Ablauf ist als Runbook gedacht. Er führt Sie vom Client über den Resolver bis zur autoritativen Quelle – und liefert an jeder Stelle klare Beweise, ob der Fehler „vor“ oder „nach“ diesem Punkt liegt.

Schritt: Client-Konfiguration prüfen

• Welche DNS-Server sind gesetzt? (DHCP, statisch, VPN, MDM-Policy)
• Stimmt der Suchsuffix? Besonders in AD-Umgebungen: falsche Suffixe erzeugen unerwartete NXDOMAINs.
• Gibt es DNS over HTTPS/DoT? Browser/Agenten können systemweite Resolver umgehen und dadurch „widersprüchliche“ Ergebnisse erzeugen.

Schritt: Abfrage an den konfigurierten Resolver

• Abfrage exakt des FQDN (vollqualifizierter Name) durchführen.
• Response Code und Antwort-IP notieren, plus Antwortzeit.
• Wenn möglich: gleiche Abfrage mehrfach wiederholen, um Cache-Effekte zu erkennen (erste Abfrage langsam, zweite schnell).

Schritt: Vergleichsresolver nutzen

• Abfrage an einen zweiten, bekannten Resolver (intern/extern) richten.
• Unterschiede interpretieren: Wenn Resolver A NXDOMAIN liefert und Resolver B korrekt antwortet, ist es kein „Internetproblem“, sondern ein Resolver-/Zonen-/Policy-Problem.

Schritt: Autoritative Quelle prüfen

• Wenn möglich: direkt die autoritativen Nameserver der Zone abfragen (SOA/NS ermitteln).
• Damit trennen Sie „Record existiert wirklich nicht“ von „Resolver/Forwarder liefert falsches Ergebnis“.

Schritt: Caching und TTL berücksichtigen

• TTL prüfen: Wie lange bleibt eine Antwort im Cache?
• Negative Caching: Auch NXDOMAIN kann gecacht werden (negative TTL über SOA-Parameter). Das führt dazu, dass ein frisch angelegter Record „trotzdem nicht geht“.

Schritt: Transport und Firewalls prüfen

• DNS läuft primär über UDP 53, kann aber bei großen Antworten oder bestimmten Operationen TCP 53 benötigen.
• Wenn UDP blockiert oder fragmentierte Antworten verworfen werden, entstehen Timeouts oder scheinbar „zufällige“ Ausfälle.

NXDOMAIN verstehen: Wann „Name existiert nicht“ wirklich stimmt

NXDOMAIN ist kein „Server down“, sondern eine explizite Aussage: Aus Sicht des antwortenden DNS-Servers existiert der Name nicht. Das kann korrekt sein – oder durch Kontext falsch wirken. Häufige Ursachen sind Tippfehler, falsche Domain, falsche Suchsuffixe oder Split-DNS, bei dem intern andere Zonen gelten als extern.

Typische NXDOMAIN-Ursachen

• Tippfehler oder falscher Hostname: banal, aber häufig.
• Suchsuffix-Fallen: Client hängt z. B. „.firma.local“ an und fragt dann den falschen Namen ab.
• Split-DNS: Intern existiert service.example.com anders als extern (oder gar nicht). Im VPN wird dann der „falsche“ Resolver genutzt.
• Zone nicht delegiert: Autoritative Nameserver sind falsch oder Delegation fehlt.
• Filtering/Sinkhole: Security-Resolver antwortet absichtlich NXDOMAIN für geblockte Domains.

Negative Caching: Warum NXDOMAIN nach einem Fix „weiter bleibt“

Ein häufiger Praxisfall: Ein Record wurde gerade erstellt, aber Clients bekommen weiterhin NXDOMAIN. Das kann an negativem Caching liegen: Resolver cachen NXDOMAIN-Antworten für eine Zeit, die aus der SOA der Zone abgeleitet wird. Erst nach Ablauf oder Cache-Flush sehen Clients die neue Antwort. Negative Caching ist in RFC 2308 beschrieben.

DNS-Timeouts: Wenn der Resolver nicht (rechtzeitig) antwortet

Timeouts sind meist schwieriger als NXDOMAIN, weil sie weniger eindeutig sind. Ein Timeout kann bedeuten: Paketverlust, Firewall-Drops, überlasteter Resolver, fehlerhafte Forwarder-Kette, oder auch MTU/Fragmentierungsprobleme bei großen Antworten. Wichtig ist deshalb, Timeouts mit Paketmitschnitt oder systematischem Segmentvergleich zu belegen.

Die häufigsten Ursachen für DNS-Timeouts

• DNS-Server down/überlastet: CPU/Memory hoch, Query-Rate zu groß, Thread-Pools erschöpft.
• Firewall/ACL blockt UDP 53: Besonders häufig bei Gastnetzen, segmentierten VLANs oder VPN-Tunneln.
• TCP 53 blockiert: Große Antworten (DNSSEC, viele Records) benötigen TCP – ohne TCP kommt es zu Retries und Timeouts.
• MTU/Fragmentierung: Große UDP-Antworten werden fragmentiert und unterwegs verworfen; der Client sieht Timeout.
• Forwarder-Kaskaden: interner Resolver forwardet an Upstream, Upstream antwortet nicht; lokale Clients warten.
• Rate Limiting: Autoritative Server oder Resolver drosseln, wenn zu viele Anfragen kommen (z. B. bei Loops/Storms).

DNSSEC als Timeout-Verstärker

DNSSEC kann Antworten größer machen, weil Signaturen und zusätzliche Records übertragen werden. Das ist kein Fehler, aber es erhöht die Wahrscheinlichkeit, dass TCP-Fallback oder Fragmentierung relevant wird. Wenn Netzpfade TCP 53 oder fragmentierte UDP-Pakete blockieren, äußert sich das oft als „DNS sporadisch langsam oder kaputt“ – besonders bei bestimmten Domains. DNSSEC-Grundlagen sind u. a. in RFC 4033 beschrieben.

Falsche Auflösungen: Wenn DNS antwortet, aber das falsche Ziel liefert

Falsche Antworten sind besonders gefährlich, weil sie „funktionieren“ – nur eben auf das falsche Ziel. Das kann als falsche IP, falscher CNAME, falsche Priorität (MX/SRV) oder unerwartete Geo-/Load-Balancer-Antwort auftreten. In Unternehmen sind häufige Ursachen: Split-DNS-Konflikte, veraltete Caches, falsche TTLs, fehlerhafte Migrationen (DNS-Record nicht aktualisiert) oder Filter-/Sinkhole-Lösungen.

Typische Ursachen für falsche DNS-Antworten

• Split-DNS falsch umgesetzt: Intern zeigt app.example.com auf alte On-Prem-IP, extern auf Cloud-IP.
• Cache-Staleness: Resolver cacht alte Antworten zu lange (TTL zu hoch) oder Clients cachen lokal.
• Mehrere Records: A/AAAA liefern mehrere IPs, eine davon ist falsch oder down – Symptome wirken sporadisch.
• CNAME-Ketten: Alias zeigt auf falsches Ziel, oder Kette ist zu lang/fehlerhaft.
• Geo-DNS/CDN: Antworten variieren je Standort; ein Standort bekommt einen problematischen Edge.
• Hosts-Datei/Overrides: Lokale Overrides umgehen DNS und liefern „falsche“ Ziele.

TTL richtig interpretieren: Warum „DNS-Änderung wirkt nicht“ oft normal ist

TTL (Time To Live) bestimmt, wie lange Resolver eine Antwort cachen dürfen. Eine Änderung am autoritativen DNS wirkt erst dann überall, wenn die alten Caches abgelaufen sind – oder wenn sie gezielt geleert werden. Ein häufiges operatives Problem ist, dass TTLs vor einer Migration nicht rechtzeitig reduziert wurden. Dann bleibt der alte Record über Stunden oder Tage wirksam.

Split-DNS und VPN: Der Klassiker für „intern geht’s nicht, extern schon“

Split-DNS bedeutet, dass dieselbe Domain intern und extern unterschiedliche Antworten liefert. Das ist oft gewollt (interne Services, private IPs, interne Load Balancer). Probleme entstehen, wenn Clients den „falschen“ Resolver benutzen – etwa weil ein VPN zwar Traffic tunnelt, aber DNS nicht korrekt umstellt, oder weil DoH/DoT den VPN-DNS umgeht. Dann wird intern nach extern aufgelöst (oder umgekehrt), was wie Routing-/Firewall-Probleme aussieht.

• Indiz: Über VPN kann der Client interne Namen nicht auflösen, extern aber schon.
• Indiz: Nur Namenauflösung falsch, aber IP-basierter Zugriff (direkte IP) funktioniert.
• Fix-Ansatz: DNS-Serverzuweisung im VPN korrekt, Suchsuffix korrekt, DoH/DoT-Policies prüfen.

DNS und Performance: Warum langsam oft „DNS langsam“ ist

DNS-Latenz wird unterschätzt. Wenn eine Anwendung für jeden API-Call DNS neu abfragt oder viele Subdomains nutzt (Microservices, SaaS), summieren sich Millisekunden schnell. Typische Ursachen für langsame DNS-Auflösung sind: überlastete Resolver, weit entfernte Forwarder, fehlerhafte Upstreams, DNSSEC-Validierung unter Last, oder eine zu aggressive Security-Inspection, die DNS bremst.

• Erste Abfrage langsam, danach schnell: Cache-Warmup – normal, aber kann bei kurzer TTL ständig wiederkehren.
• Viele kleine Timeouts: Retries erhöhen gefühlte Latenz, obwohl es nicht „komplett ausfällt“.
• Nur bestimmte Domains langsam: Upstream/Authoritative/Filtering betroffen, nicht „DNS generell“.

Beweisführung: Was Sie für eine saubere Eskalation sammeln sollten

DNS-Probleme werden schneller gelöst, wenn Sie sie mit Belegen eskalieren: Welche Domain? Welcher Resolver? Welcher Response Code? Welche Antwortzeit? Welche IPs kamen zurück? Welche TTL? Ob intern oder extern? Damit können Provider, Cloud-Anbieter oder interne Plattformteams gezielt reagieren.

• FQDN und Abfragezeitpunkt (mit Zeitzone)
• Verwendeter Resolver (IP/Name) und Antwortzeit
• Response Code (NXDOMAIN, SERVFAIL, Timeout) und Antwortdetails (A/AAAA/CNAME)
• Vergleich: anderer Resolver / anderer Standort / mit und ohne VPN
• Falls nötig: kurzer Packet Capture-Ausschnitt (DNS Query/Response) oder Logs

Häufige Praxisfallen im DNS Troubleshooting

• Nur „ping domain“ testen: Ping ist ICMP, nicht DNS. Wenn Ping über Name geht, testet er DNS und ICMP gleichzeitig – das kann verwirren.
• Nur einen Resolver fragen: Wenn der Resolver selbst das Problem ist, sehen Sie ohne Vergleich kein klares Bild.
• IPv6 übersehen: Manche Clients bevorzugen AAAA; wenn IPv6-Pfad kaputt ist, wirkt die Anwendung kaputt, obwohl A-Records ok sind.
• Cache ignorieren: Alte Antworten bleiben bestehen; ohne TTL/Cache-Wissen wird „Fix“ nicht nachvollziehbar.
• Split-DNS unterschätzen: VPN/DoH/Policies können Resolver-Pfade ändern.

Best Practices: DNS stabil und troubleshootbar betreiben

• Resolver-Redundanz: Mindestens zwei Resolver pro Standort/Zone, sauber verteilt.
• Monitoring: DNS-Response-Time, Error Codes (NXDOMAIN/SERVFAIL), Query-Rate, Cache-Hit-Rate.
• Change-Disziplin: Vor Migration TTL senken, danach wieder erhöhen; Änderungen dokumentieren.
• Split-DNS sauber: klare Zonenverantwortung, VPN-DNS korrekt, DoH/DoT-Policy bewusst.
• TCP 53 ermöglichen: Nicht nur UDP freigeben; große Antworten und DNSSEC benötigen TCP-Fallback.
• Security-Resolver bewusst: Sinkhole/Filterung transparent machen, damit NXDOMAIN nicht wie „Fehler“ wirkt.

Checkliste: DNS Troubleshooting bei NXDOMAIN, Timeouts und falschen Auflösungen

• Client prüfen: Welche DNS-Server und Suchsuffixe sind gesetzt? VPN/DoH aktiv?
• Abfrage an den konfigurierten Resolver: Response Code, Antwort, TTL und Timing notieren.
• Vergleichsresolver abfragen: intern vs. extern oder zweiter interner Resolver – Unterschiede auswerten.
• NXDOMAIN: Tippfehler, Split-DNS, Suffix, negative Caching (RFC 2308) prüfen.
• Timeout: UDP/TCP 53, Firewall/ACL, Forwarder, Overload, MTU/Fragmentierung und DNSSEC-Effekte prüfen.
• Falsche Auflösung: TTL/Cache, CNAME-Ketten, Split-DNS, Hosts-Datei/Overrides, Geo-DNS/CDN berücksichtigen.
• Autoritative Prüfung: SOA/NS ermitteln und autoritativ abfragen, um „Quelle der Wahrheit“ zu bestätigen.
• Beweise sammeln: Zeitpunkt, Resolver, Output, Vergleich, ggf. Mitschnitt; für Eskalation vorbereiten.
• Fix verifizieren: Vorher/Nachher mit identischen Abfragen; Cache/TTL beachten.
• Prävention: Monitoring, Resolver-Redundanz, klare Policies für Split-DNS und TCP 53 sicherstellen.

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.