Help Center / domains
DNS mit dig und nslookup prüfen
DNS mit dig und nslookup prüfen
dig und nslookup sind kostenlose Kommandozeilen-Tools, die dem DNS-System direkt Fragen stellen, ohne einen Browser dazwischen. Sie beantworten Fragen wie: Auf welche IP zeigt meine Domain? Ist meine DNS-Änderung live? Welche Nameserver verwendet meine Domain tatsächlich? Diese Anleitung beginnt bei null und arbeitet sich bis zu den fortgeschrittenen Optionen vor, die Support-Ingenieure täglich nutzen.
Welches Tool sollten Sie verwenden?
| Tool | Am besten für | Vorinstalliert auf |
|---|---|---|
| nslookup | Schnelle Prüfungen, Windows-Nutzer | Windows, macOS, Linux |
| dig | Detaillierte Ausgabe, Skripte, ernsthaftes Debugging | macOS, die meisten Linux-Distributionen |
Faustregel: nslookup genügt für die Frage, was ein Eintrag gerade enthält. dig ist das bessere Tool, sobald etwas nicht stimmt, weil es die vollständige DNS-Antwort einschließlich Statuscodes und TTLs anzeigt.
dig installieren, wo es fehlt:
- Windows: BIND-Tools installieren oder WSL verwenden (
sudo apt install dnsutils) - Debian/Ubuntu:
sudo apt install dnsutils - RHEL/Fedora/Alma/Rocky:
sudo dnf install bind-utils
Einsteiger: Ihre erste Abfrage
Beide Befehle nehmen einen Domainnamen entgegen. Ohne weitere Optionen liefern sie den A-Record der Domain (ihre IPv4-Adresse):
nslookup example.com
dig example.com
Die Antwort von nslookup ist kurz:
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: example.com
Address: 96.7.128.175
- Server ist der DNS-Resolver, der Ihnen geantwortet hat (Ihr Router, Ihr Internetanbieter oder ein öffentlicher Resolver), nicht der Nameserver Ihrer Domain.
- Non-authoritative answer bedeutet, dass die Antwort aus dem Cache dieses Resolvers kam, nicht direkt von den Nameservern der Domain. Das ist normal.
dig-Ausgabe lesen
dig gibt mehr aus, in beschrifteten Abschnitten:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31337
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 3600 IN A 96.7.128.175
;; Query time: 24 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
| Teil | Bedeutung |
|---|---|
status: NOERROR |
Die Abfrage war erfolgreich (siehe Statustabelle unten) |
| QUESTION | Was Sie gefragt haben |
| ANSWER | Die zurückgegebenen Einträge |
3600 |
Die TTL in Sekunden - wie lange Resolver diese Antwort cachen dürfen |
| SERVER | Welcher Resolver geantwortet hat |
Sie möchten nur die Antwort, sonst nichts? Fügen Sie +short hinzu:
dig example.com +short
96.7.128.175
Bestimmte Record-Typen abfragen
DNS enthält mehr als IP-Adressen. Übergeben Sie den Record-Typ nach der Domain:
| Record | Was er enthält | dig | nslookup |
|---|---|---|---|
| A | IPv4-Adresse | dig example.com A |
nslookup -type=A example.com |
| AAAA | IPv6-Adresse | dig example.com AAAA |
nslookup -type=AAAA example.com |
| MX | Mailserver | dig example.com MX |
nslookup -type=MX example.com |
| TXT | Verifizierung, SPF, DKIM | dig example.com TXT |
nslookup -type=TXT example.com |
| CNAME | Alias auf einen anderen Namen | dig www.example.com CNAME |
nslookup -type=CNAME www.example.com |
| NS | Die Nameserver der Domain | dig example.com NS |
nslookup -type=NS example.com |
| SOA | Zonen-Metadaten + Seriennummer | dig example.com SOA |
nslookup -type=SOA example.com |
| CAA | Zugelassene TLS-Zertifikatsaussteller | dig example.com CAA |
nslookup -type=CAA example.com |
Zwei, die Sie ständig verwenden werden:
# Wohin geht die E-Mail dieser Domain?
dig example.com MX +short
10 mail.example.com.
# Ist mein SPF- oder Site-Verification-TXT-Record live?
dig example.com TXT +short
"v=spf1 include:_spf.example.com ~all"
Die Zahl vor einem MX-Ziel (10) ist seine Priorität - niedrigere Werte werden zuerst versucht.
Fortgeschritten: Einen bestimmten DNS-Server fragen
Standardmäßig fragen beide Tools den Resolver, den Ihr System verwendet. Sie können aber jeden Server direkt fragen - der nützlichste Trick überhaupt, um die DNS-Propagation zu prüfen:
# Googles öffentlichen Resolver fragen
dig @8.8.8.8 example.com
# Cloudflares Resolver fragen
dig @1.1.1.1 example.com
# Den eigenen (autoritativen) Nameserver der Domain fragen
dig @ns1.osir.com example.com
Bei nslookup steht der Server am Ende: nslookup example.com 8.8.8.8
Propagationsprüfung in zwei Befehlen. Fragen Sie nach einer Änderung zuerst den autoritativen Nameserver, dann einen öffentlichen Resolver:
dig @ns1.osir.com example.com +short- zeigt sofort den neuen Wert. Falls nicht, wurde der Eintrag nicht korrekt gespeichert; prüfen Sie Ihr DNS-Dashboard erneut.dig @8.8.8.8 example.com +short- kann den alten Wert zeigen, bis die gecachte Kopie abläuft (bis zur TTL des alten Eintrags). Das ist kein Fehler, sondern Caching, wie es vorgesehen ist.
Es gibt keine Möglichkeit, fremde Resolver zu zwingen, einen gecachten Eintrag zu vergessen. Deshalb ist es der professionelle Weg, die TTL vor einer geplanten Änderung zu senken.
Fortgeschritten: Reverse-Lookups
Ein Reverse-Lookup fragt: Welcher Name gehört zu dieser IP? Nützlich, um einen Server in Ihren Logs zu identifizieren:
dig -x 96.7.128.175
nslookup 96.7.128.175
Dies fragt den PTR-Record der IP ab. Beachten Sie: PTR-Records kontrolliert der Eigentümer des IP-Blocks (in der Regel der Hosting-Anbieter), nicht die DNS-Zone Ihrer Domain.
Fortgeschritten: Interaktiver Modus von nslookup
Starten Sie nslookup ohne Argumente für den interaktiven Modus - praktisch, um mehrere Einträge zu prüfen, ohne neu zu tippen:
> server ns1.osir.com # zu einem bestimmten Server wechseln
> set type=MX # Record-Typ wechseln
> example.com # abfragen
> set type=TXT
> example.com
> exit
Profi: Den vollständigen Auflösungspfad verfolgen
dig +trace ignoriert Caches vollständig und läuft den DNS-Baum so ab, wie es ein Resolver bei einem Kaltstart tut: Root-Server, dann die Server der TLD, dann die Nameserver Ihrer Domain:
dig +trace example.com
Lesen Sie die Ausgabe beim Debuggen von unten nach oben: Der letzte Schritt zeigt, welcher Nameserver die endgültige Antwort gegeben hat. Bricht der Trace auf TLD-Ebene ab, ist Ihre Delegation (die beim Registrar gesetzten NS-Einträge) defekt - die Registry zeigt nicht auf die Nameserver, die Sie erwarten. Bricht er beim letzten Schritt ab, sind die Nameserver korrekt delegiert, antworten aber nicht für die Zone.
Profi: Seriennummern vergleichen und asynchrone Nameserver erkennen
Jede Zone hat eine SOA-Seriennummer, die bei jeder Änderung hochgezählt wird. Wenn Ihre Nameserver nicht übereinstimmen, erhalten manche Nutzer veraltete Antworten:
dig @ns1.osir.com example.com SOA +short
dig @ns3.osir.com example.com SOA +short
Das dritte Feld in jeder Antwort ist die Seriennummer. Sie sollten übereinstimmen. Ein hinterherhinkender Secondary erklärt das Phänomen, dass es bei manchen funktioniert und bei anderen nicht, besser als fast alles andere.
Profi: Nützliche dig-Optionen
| Option | Was sie bewirkt |
|---|---|
+short |
Nur die Antwortwerte |
+noall +answer |
Nur den ANSWER-Abschnitt, mit TTLs - das Beste aus beiden Welten |
+trace |
Vollständiger Auflösungspfad ab der Root, an allen Caches vorbei |
+norecurse |
Einen Server nur fragen, was er bereits weiß (Cache-Inspektion) |
+dnssec |
DNSSEC-Signaturen (RRSIG-Records) mit der Antwort anfordern |
+tcp |
TCP erzwingen - testet, ob große Antworten / Zonen-Firewalls funktionieren |
-x <ip> |
Reverse-Lookup (PTR) |
# Saubere Antwort mit TTL - das Alltagswerkzeug
dig example.com A +noall +answer
example.com. 3600 IN A 96.7.128.175
Statuscodes: Was der Server Ihnen mitgeteilt hat
Das Feld status: im dig-Header ist das Erste, was Sie bei einem Fehler lesen sollten:
| Status | Bedeutung | Typische Ursache |
|---|---|---|
| NOERROR | Abfrage erfolgreich | Achtung: Kann trotzdem eine leere Antwort haben - der Name existiert, hat aber keinen Eintrag dieses Typs |
| NXDOMAIN | Der Name existiert überhaupt nicht | Tippfehler, oder der Eintrag wurde nie angelegt |
| SERVFAIL | Der Server konnte nicht antworten | Defekte Delegation, fehlgeschlagene DNSSEC-Validierung, Nameserver ausgefallen |
| REFUSED | Der Server hat die Antwort verweigert | Sie haben einen Nameserver gefragt, der für diese Zone nicht zuständig ist |
Der Fall NOERROR-mit-leerer-Antwort stolpert die meisten: Liefert dig sub.example.com A NOERROR ohne ANSWER-Abschnitt, existiert sub.example.com (etwa als MX oder TXT), hat aber keinen A-Record.
Rezepte zur Fehlerbehebung
| Symptom | Auszuführende Befehle |
|---|---|
| Eintrag geändert, aber alter Wert sichtbar | dig @ns1.osir.com name +short vs. dig @8.8.8.8 name +short - stimmt der erste, ist es TTL-Caching; abwarten |
| Website lädt nicht | dig example.com NS +short (richtige Nameserver?), dann dig example.com A +short (richtige IP?) |
| E-Mails kommen nicht an | dig example.com MX +short, dann dig example.com TXT +short (SPF vorhanden?) |
| Verifizierung schlägt fehl (Google, Microsoft 365 usw.) | dig example.com TXT +short - ist das exakte Token schon live? |
| Funktioniert bei manchen Besuchern, bei anderen nicht | SOA-Seriennummern aller Nameserver vergleichen (siehe oben) |
| Ist die Domain überhaupt delegiert? | dig +trace example.com ausführen und lesen, wo er abbricht |
Die Einträge selbst verwalten
Diese Tools lesen DNS; zum Ändern verwenden Sie den DNS-Editor Ihres Dashboards. Bei uns registrierte Domains verwenden standardmäßig ns1.osir.com und ns3.osir.com, sodass dig @ns1.osir.com yourdomain.com Ihnen immer genau das zeigt, was wir veröffentlichen. Das große Ganze zu Nameservern, Glue-Records und TTLs finden Sie in DNS und Nameserver erklärt.