Wie man DNS-Auflösung verfolgt: Debugging von Lookups mit dig und nslookup

Wenn eine Domain nicht aufgelöst wird, langsam lädt oder eine unerwartete IP zurückgibt, liegt die Ursache fast immer irgendwo in der DNS-Auflösungskette. Eine einzelne Abfrage gegen Ihren lokalen Resolver verbirgt, was tatsächlich passiert ist — welche Nameserver abgefragt wurden, welche geantwortet haben und wo die Kette unterbrochen wurde. Um die ganze Geschichte zu sehen, benötigen Sie einen DNS-Trace.

Dieses Handbuch zeigt Ihnen, wie Sie eine DNS-Auflösung von Anfang bis Ende mit Standard-Tools nachverfolgen, die Ausgabe lesen und die häufigsten Fehlerarten diagnostizieren.

Was ist ein DNS-Trace?

Ein DNS-Trace ist ein Schritt-für-Schritt-Durchgang durch die rekursive Auflösung eines Domainnamens, beginnend bei den Root-Nameservern und der Delegationskette bis hin zum autoritativen Nameserver der Domain. Im Gegensatz zu einer Standardabfrage, die nur die endgültige Antwort liefert, zeigt ein Trace jede Zwischenabfrage und -antwort, sodass genau festgestellt werden kann, wo eine Auflösung fehlschlägt oder Fehlverhalten zeigt.

Wie funktioniert die DNS-Auflösung (Kurze Einführung)

Jede Domainauflösung folgt derselben Hierarchie:

1. Root-Nameserver (.) — 13 logische Server, die wissen, welche Nameserver für jede Top-Level-Domain (TLD) zuständig sind.
2. TLD-Nameserver (.com, .org, .fr, …) — delegieren an die autoritativen Nameserver der registrierten Domain.
3. Autoritative Nameserver — enthalten die tatsächlichen Einträge (A, AAAA, MX, TXT, …) für die Domain.

Ein rekursiver Resolver (Ihr ISP's DNS, 1.1.1.1, 8.8.8.8, Pi-hole usw.) durchläuft diese Kette in Ihrem Auftrag und cached die Ergebnisse. Wenn Sie den Ablauf selbst nachverfolgen, umgehen Sie den Cache und beobachten den rohen Delegationspfad.

Ausführen eines DNS-Traces mit dig

Der dig-Befehl (Teil von bind-utils auf Linux, bind9-dnsutils auf Debian/Ubuntu, und standardmäßig auf macOS enthalten) ist das Standard-Tool für DNS-Debugging. Das +trace-Flag führt einen vollständigen rekursiven Trace vom Root aus durch:

dig +trace example.com

Die Ausgabe listet für jede Ebene die abgefragten Nameserver und deren Antworten auf. Ein typischer Trace für example.com sieht so aus:

;; global options: +cmd
.                       86400   IN      NS      a.root-servers.net.
.                       86400   IN      NS      b.root-servers.net.
...
;; Received 811 bytes from 192.168.1.1#53(192.168.1.1) in 4 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
...
;; Received 1174 bytes from 198.41.0.4#53(a.root-servers.net) in 12 ms

example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.
;; Received 289 bytes from 192.5.6.30#53(a.gtld-servers.net) in 24 ms

example.com.            86400   IN      A       93.184.216.34
;; Received 56 bytes from 199.43.135.53#53(a.iana-servers.net) in 18 ms

Jeder Block zeigt die Delegation auf dieser Ebene, die TTL, den antwortenden Nameserver und die Abfragezeit. Der letzte Block enthält die autoritative Antwort.

Alternativen: nslookup und drill

nslookup (überall verfügbar, inklusive Windows) ist einfacher, aber weniger flexibel. Es unterstützt keinen rekursiven Trace, aber Sie können manuell jede Ebene abfragen:

nslookup -type=NS com.
nslookup -type=NS example.com. a.gtld-servers.net
nslookup example.com. a.iana-servers.net

drill (von ldns) ist eine moderne Alternative zu dig mit saubererer Ausgabe und besserer DNSSEC-Unterstützung:

drill -T example.com

Unter Windows ist Resolve-DnsName in PowerShell das moderne Äquivalent, allerdings liefert es keinen Trace an sich.

Die Trace-Ausgabe lesen

Beim Interpretieren eines Traces sind drei Felder wichtig:

• TTL (erste Zahl) — wie lange der Eintrag zwischengespeichert werden darf. Ein sehr niedriger TTL (unter 60 s) deutet oft auf Lastverteilung oder eine kürzliche Änderung hin; ein hoher TTL (24 h+) bedeutet, dass Änderungen langsam propagieren.
• Quelle Nameserver (from X.X.X.X#53(hostname)) — wer hat auf jeder Ebene geantwortet. Wenn derselbe Nameserver auf mehreren Ebenen erscheint, ist etwas falsch konfiguriert.
• Abfragezeit (in N ms) — Latenz zu jedem Nameserver. Ein einzelner langsamer Hop kann Hunderte Millisekunden zu jeder nicht gecachten Auflösung hinzufügen.

Häufige DNS-Probleme und wie man sie erkennt

• NXDOMAIN — der autoritative Nameserver gibt "Name existiert nicht" zurück. Überprüfen Sie Tippfehler, abgelaufene Domains oder falsche Delegation auf TLD-Ebene.
• SERVFAIL — ein Nameserver in der Kette ist nicht erreichbar oder liefert fehlerhafte Antworten. Führen Sie den Trace zweimal aus: Wenn der fehlerhafte Nameserver wechselt, ist das Problem temporär; wenn er konstant bleibt, liegt das Problem an diesem Server.
• Langsame Auflösung — schauen Sie auf die Abfragezeiten pro Ebene. Eine langsame Root- oder TLD-Abfrage ist selten und deutet auf lokale Netzwerkprobleme hin. Eine langsame autoritative Abfrage weist auf den Domain-Operator hin.
• Veraltete Daten — wenn ein Trace die richtige IP zeigt, Ihr Browser aber eine alte trifft, cached Ihr rekursiver Resolver noch. Löschen Sie den Cache mit sudo resolvectl flush-caches (systemd-resolved), sudo dscacheutil -flushcache (macOS) oder ipconfig /flushdns (Windows).
• Propagationsprobleme — nach einer DNS-Änderung sehen verschiedene Resolver unterschiedliche Werte, bis die TTLs ablaufen. Fragen Sie mehrere öffentliche Resolver ab (1.1.1.1, 8.8.8.8, 9.9.9.9), um die Konsistenz zu prüfen.
• Lame Delegation — ein TLD delegiert an Nameserver, die nicht autoritativ für die Zone antworten. Sichtbar als SERVFAIL von einem oder mehreren Nameservern, während andere funktionieren.

DNS-Trace vs DNS-Lookup: Den Unterschied kennen

Ein einfacher dig example.com-Befehl trifft Ihren rekursiven Resolver, gibt die zwischengespeicherte Antwort zurück und sagt Ihnen nichts über den Pfad. Ein Trace umgeht den Cache und durchläuft die Kette selbst. Verwenden Sie einen Lookup, um das Ergebnis zu prüfen; verwenden Sie einen Trace, um den Prozess zu debuggen.

Wenn Tracing nicht ausreicht

DNS ist nur die Hälfte einer Verbindung. Sobald ein Name aufgelöst ist, müssen Ihre Pakete noch den Server durch BGP-geroutete Netzwerke finden. Wenn DNS die richtige IP zurückgibt, der Dienst aber unerreichbar oder langsam ist, führen Sie einen traceroute zur aufgelösten Adresse durch, um zu sehen, wo der Netzwerkpfad fehlschlägt. Tools wie TraceMapper kombinieren beide Perspektiven: Sie lösen den Hostnamen auf und visualisieren den Netzwerkpfad Hop für Hop, sodass Sie DNS ausschließen und sich auf die tatsächliche Route konzentrieren können.

Wichtige Erkenntnisse

• Verwenden Sie dig +trace (oder drill -T), um die vollständige Delegationskette vom Root bis zum autoritativen Nameserver zu durchlaufen.
• Überprüfen Sie TTLs, Quell-Nameserver und Abfragezeiten auf jeder Ebene, um zu erkennen, welcher Hop Fehlverhalten zeigt.
• NXDOMAIN, SERVFAIL und langsame Hops weisen jeweils auf unterschiedliche Problemklassen hin — Delegation, Nameserver-Gesundheit oder Latenz.
• Leeren Sie lokale Caches und fragen Sie mehrere öffentliche Resolver ab, wenn Sie Propagationsprobleme diagnostizieren.
• Nachdem ein DNS-Problem ausgeschlossen wurde, ergänzt ein traceroute auf die aufgelöste IP das Diagnosebild.