DNS prüfen auf der Kommandozeile: nslookup, dig und PowerShell

nslookup unter Windows

nslookup ist auf jedem Windows seit Jahrzehnten vorhanden und reicht für die meisten Fragen. Ohne weitere Angabe fragt es den Resolver, der in den Netzwerkeinstellungen steht, also meist die Fritzbox oder den DNS des Providers. Der Record-Typ wird mit -type= gewählt, ein Nameserver optional als letztes Argument.

nslookup beispiel.de
nslookup -type=MX beispiel.de
nslookup -type=TXT beispiel.de
nslookup -type=NS beispiel.de
nslookup -type=TXT _dmarc.beispiel.de
nslookup -type=A beispiel.de 8.8.8.8

Die Zeile "Nicht autorisierende Antwort" ist kein Fehler: Sie bedeutet nur, dass ein Resolver aus dem Cache geantwortet hat und nicht der Nameserver der Zone. Für den aktuellen Zustand nach einer Änderung fragst du den autoritativen Nameserver direkt, indem du ihn als letztes Argument angibst: nslookup -type=TXT beispiel.de ns1.hoster.de.

dig unter Linux und macOS

dig ist ausführlicher und besser für Skripte. macOS bringt es mit, unter Debian und Ubuntu steckt es im Paket dnsutils, unter Fedora in bind-utils. Der Record-Typ steht hinter der Domain, ein Nameserver mit @ davor. +short reduziert die Ausgabe auf die Werte.

dig beispiel.de A +short
dig beispiel.de MX
dig beispiel.de TXT +short
dig beispiel.de NS +short
dig _dmarc.beispiel.de TXT +short
dig selector1._domainkey.beispiel.de TXT +short
dig @ns1.hoster.de beispiel.de A
dig beispiel.de ANY +noall +answer

Im Kopf der vollen Ausgabe stehen zwei nützliche Angaben: das flags-Feld, in dem aa für eine autoritative Antwort steht, und die TTL in der zweiten Spalte jeder Antwortzeile. Bei einer Antwort aus dem Cache zählt die TTL herunter; beim autoritativen Server steht der volle Wert aus der Zone. ANY liefern viele Server nicht mehr vollständig, für ein Gesamtbild fragst du die Typen einzeln ab.

Resolve-DnsName in PowerShell

PowerShell hat mit Resolve-DnsName ein Cmdlet, das Objekte statt Text liefert und sich deshalb sortieren, filtern und in Skripte einbauen lässt. Der Nameserver wird mit -Server angegeben, -DnsOnly umgeht Hosts-Datei und Cache des Rechners.

Resolve-DnsName beispiel.de
Resolve-DnsName beispiel.de -Type MX
Resolve-DnsName beispiel.de -Type TXT | Select-Object -ExpandProperty Strings
Resolve-DnsName _dmarc.beispiel.de -Type TXT
Resolve-DnsName beispiel.de -Type A -Server 1.1.1.1 -DnsOnly
Resolve-DnsName beispiel.de -Type NS | ForEach-Object { Resolve-DnsName beispiel.de -Type A -Server $_.NameHost }

Die letzte Zeile ist der Trick für Umzüge: Sie ermittelt die Nameserver der Zone und fragt jeden einzeln nach dem A-Record. Liefern alle denselben Wert, ist die Zone konsistent und Unterschiede bei Nutzern sind nur noch eine Frage der TTL.

Autoritativ oder aus dem Cache: der Unterschied

Alle drei Werkzeuge fragen standardmäßig den Resolver deines Rechners, und der antwortet aus seinem Cache, solange die TTL nicht abgelaufen ist. Nach einer DNS-Änderung siehst du deshalb oft noch den alten Wert, obwohl der Hoster längst gespeichert hat. Der Weg zur Wahrheit ist immer derselbe:

1. Nameserver der Zone ermitteln: dig beispiel.de NS +short oder nslookup -type=NS beispiel.de.
2. Einen davon direkt fragen: dig @ns1.hoster.de beispiel.de TXT oder nslookup -type=TXT beispiel.de ns1.hoster.de.
3. Steht dort der neue Wert, ist die Änderung korrekt. Alle Resolver ziehen nach, sobald ihre alte Kopie abgelaufen ist.
4. Zur Kontrolle einen öffentlichen Resolver fragen (8.8.8.8, 1.1.1.1) und den lokalen Cache leeren: ipconfig /flushdns unter Windows, sudo resolvectl flush-caches unter Linux, sudo dscacheutil -flushcache unter macOS.

Häufige Aufgaben mit Kundendomains

Die Kommandos, die im Agenturalltag am häufigsten gebraucht werden:

• Hosterwechsel prüfen: dig beispiel.de NS +short zeigt, ob die neuen Nameserver bereits bei der Registry hinterlegt sind.
• SPF lesen: dig beispiel.de TXT +short | grep spf1 filtert den SPF-Record aus allen TXT-Einträgen.
• DKIM-Schlüssel prüfen: dig selector1._domainkey.beispiel.de TXT +short, bei Microsoft 365 erscheint ein CNAME auf onmicrosoft.com.
• Mailserver finden: dig beispiel.de MX +short, danach die Hosts mit dig mail.beispiel.de A +short auflösen.
• Reverse DNS einer Mailserver-IP: dig -x 203.0.113.10 +short oder nslookup 203.0.113.10.
• Zertifizierungsstellen: dig beispiel.de CAA +short zeigt, wer Zertifikate ausstellen darf.

Wann ein Tool sinnvoller ist

Die Kommandozeile zeigt einen Moment auf einem Rechner. Der DNS Checker fragt immer autoritativ ab, erklärt jeden Record und bewertet Fehler wie CNAME neben anderen Records oder fehlende CAA-Einträge. Und für die Frage, ob sich morgen etwas ändert, braucht es ohnehin ein Monitoring, das die Zone regelmäßig abfragt und Abweichungen meldet.

Häufige Fragen

nslookup sagt "Nicht autorisierende Antwort", was bedeutet das?

Die Antwort kam aus dem Cache eines Resolvers, nicht vom Nameserver der Zone. Das ist normal und kein Fehler. Für den aktuellen Zustand den autoritativen Nameserver direkt angeben.

Warum zeigt dig einen anderen Wert als mein Browser?

Browser und Betriebssystem haben eigene Caches, dazu kommt der Resolver. Nach einer Änderung stimmen die Werte erst überein, wenn alle TTLs abgelaufen sind. Cache leeren und den autoritativen Server fragen.

Kann ich mit dig alle Records einer Domain sehen?

Nicht zuverlässig. ANY wird von vielen Servern eingeschränkt beantwortet, und einen Zonentransfer (AXFR) erlauben Hoster nicht. Die Typen einzeln abfragen oder den DNS Checker nutzen, der die gängigen Typen gebündelt zeigt.