dig-Befehl: DNS-Abfragen unter Linux und die Ausgabe von +short und +trace lesen
Wenn du die DNS-Records einer Domain bis hin zum Antwort-Header des DNS-Servers prüfen willst, verwendest du den Befehl dig. Als wir auf Servern mit AlmaLinux 9 und Debian 12 die Records von example.com nach Typ abgefragt und den befragten DNS-Server gewechselt haben, zeigte sich: Allein an status und flags im Antwort-Header lässt sich unterscheiden, ob ein Name nicht existiert, ob der DNS-Server keine Antwort liefern konnte oder ob der Server, der die Records verwaltet, direkt geantwortet hat.
Die Ausgaben unten stammen von einem AlmaLinux-9.8-Server (root-Konto) und einem Debian-12-Server (normales Konto). Die Adresse des auf dem Server eingestellten DNS-Servers wurde durch den Beispielwert 192.0.2.53 ersetzt, die Versionsnummern von dig ebenfalls durch Beispielwerte.
1️⃣ So verwendest du den dig-Befehl
Die Grundform lautet [dig @Server Name Typ], wobei Server und Typ weggelassen werden können. Laut offiziellem Handbuch fragt dig ohne Server den in /etc/resolv.conf eingestellten DNS-Server und ohne Typ den A-Record ab.
dig example.com; <<>> DiG 9.16.20-RH <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62441
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 62 IN A 104.20.23.154
example.com. 62 IN A 172.66.147.243
;; Query time: 1 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:18 UTC 2026
;; MSG SIZE rcvd: 72Zeilen, die mit einem Semikolon beginnen, sind Kommentarzeilen; Zeilen ohne Semikolon sind die tatsächlich empfangenen Records. Was jeder Abschnitt zeigt, steht unten.
| Ausgabe | Was er zeigt |
|---|---|
| ; <<>> DiG 9.16.20-RH <<>> example.com | Ausgeführte dig-Version und eingegebene Argumente |
| ->>HEADER<<- … status: NOERROR, id: 62441 | Antwortcode (status) und Abfragenummer (id) |
| flags: qr rd ra | Flags im Antwort-Header — ob der antwortende Server rekursiv gesucht hat und ob er die Records verwaltet |
| QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 | Anzahl der Records in jedem Abschnitt |
| OPT PSEUDOSECTION · EDNS … udp: 4096 | EDNS-Erweiterungsinformationen und die per UDP empfangbare Antwortgröße (Bytes) |
| QUESTION SECTION | Gesendete Frage — Name, Klasse (IN), Record-Typ |
| ANSWER SECTION | Empfangene Records — Name, TTL (Sekunden), Klasse, Typ und Wert in dieser Reihenfolge |
| Query time: 1 msec | Zeit bis zum Eintreffen der Antwort |
| SERVER: 192.0.2.53#53(192.0.2.53) | Adresse und Portnummer des antwortenden DNS-Servers |
| WHEN · MSG SIZE rcvd: 72 | Zeitpunkt der Abfrage und Größe der empfangenen Antwort (Bytes) |
In der flags-Zeile steht qr für Antwort, rd für angeforderte Rekursion und ra für verfügbare Rekursion (RFC 1035). Da ra ohne aa vorhanden ist, stammt diese Antwort nicht von dem Server, der die Records verwaltet, sondern von einem DNS-Server, der rekursiv sucht.
Die 62 im ANSWER-Abschnitt ist die TTL, also die verbleibende Zeit (Sekunden), die der Record im Cache bleiben darf. Direkt danach lieferte dieselbe Frage an 8.8.8.8 den Wert 300 — die Zahl hing davon ab, wann der jeweilige DNS-Server den Eintrag zwischengespeichert hatte.
Führst du dieselbe Abfrage mit dem Befehl nslookup aus, erscheinen Antwortcode und TTL nicht in der Standardausgabe. Die Unterschiede zwischen den Ausgaben der beiden Befehle stehen unten.
| Vergleich | dig | nslookup |
|---|---|---|
| Antwortcode | Immer in status der HEADER-Zeile | Nur bei Fehlern als Zeile server can't find |
| TTL | In jeder Record-Zeile unter ANSWER | Nur mit -debug |
| Antwortender DNS-Server | SERVER-Zeile ganz unten | Zeilen Server · Address ganz oben |
| Exit-Code bei NXDOMAIN | 0 | 1 |
Die installierte dig-Version prüfst du mit -v. Auf dem AlmaLinux-9-Server war es 9.16, auf dem Debian-12-Server 9.18.
dig -vDiG 9.16.20-RH2️⃣ Records mit dig abfragen
Schreibst du nach dem Namen einen Record-Typ, wird nur dieser Record abgefragt. Was jeder Typ enthält und welche Ergebnisse in diesem Artikel abgefragt wurden, steht unten.
| Art | Inhalt | Abfrageergebnis |
|---|---|---|
| A | IPv4-Adresse | example.com → 104.20.23.154 und 1 weitere |
| AAAA | IPv6-Adresse | example.com → 2606:4700:10::6814:179a und 1 weitere |
| MX | Mailserver und Priorität | example.com → 0 . (nimmt keine Mails an) |
| NS | Nameserver, die die Records verwalten | example.com → hera · elliott.ns.cloudflare.com. |
| TXT | Textwert ohne festes Format (SPF usw.) | example.com → v=spf1 -all und 1 weiterer |
| CNAME | Alias für einen anderen Namen | www.github.com → github.com. |
| SOA | Primärer Nameserver der Zone und Zeitwerte | example.com → elliott.ns.cloudflare.com. … |
| PTR | Mit einer IP-Adresse verknüpfter Name (Reverse) | -x 8.8.8.8 → dns.google. |
Mailserver prüfst du über den MX-Record. Die Abfrage des MX von example.com ergab im ANSWER-Abschnitt eine einzige Zeile [0 .].
dig example.com MX; <<>> DiG 9.16.20-RH <<>> example.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34433
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN MX
;; ANSWER SECTION:
example.com. 300 IN MX 0 .
;; Query time: 5 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:23 UTC 2026
;; MSG SIZE rcvd: 550 ist die Priorität, und ein MX, bei dem an der Stelle des Mailservernamens nur ein Punkt steht, ist ein Null MX: Die Domain nimmt keine Mails an (RFC 7505). Auch mit dem kleingeschriebenen Typ mx kam dasselbe Ergebnis.
Willst du nur die Record-Zeilen sehen, hängst du [+noall +answer] an. Laut offiziellem Handbuch schaltet +noall alle Ausgabeabschnitte ab, und +answer schaltet nur den ANSWER-Abschnitt wieder ein.
dig example.com NS +noall +answerexample.com. 12192 IN NS hera.ns.cloudflare.com.
example.com. 12192 IN NS elliott.ns.cloudflare.com.example.com hatte zwei Nameserver. Diese beiden sind die autoritativen Nameserver, die die Records von example.com direkt verwalten.
dig example.com TXT +noall +answerexample.com. 300 IN TXT "v=spf1 -all"
example.com. 300 IN TXT "_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"Ein TXT-Record kann einen Textwert ohne festes Format enthalten. v=spf1 -all ist ein SPF-Wert, der besagt, dass kein Server unter diesem Domainnamen Mails versenden darf.
dig www.github.com CNAME +noall +answerwww.github.com. 291 IN CNAME github.com.www.github.com war ein Alias (CNAME) von github.com. Bei derselben Abfrage ohne Typ folgte auf die CNAME-Zeile direkt der A-Record von github.com.
Mit +multiline erhält ein SOA-Record neben jeder Zahl einen Kommentar mit Name und Zeit und ist so leichter zu lesen.
dig example.com SOA +multiline +noall +answerexample.com. 1765 IN SOA elliott.ns.cloudflare.com. dns.cloudflare.com. (
2418004112 ; serial
10000 ; refresh (2 hours 46 minutes 40 seconds)
2400 ; retry (40 minutes)
604800 ; expire (1 week)
1800 ; minimum (30 minutes)
)serial ist eine laufende Nummer, die bei jeder Änderung der Records steigt; refresh, retry und expire sind Zeitwerte, mit denen ein sekundärer Nameserver seine Records mit dem primären abgleicht. minimum ist die Zeit, die eine Antwort zu einem nicht vorhandenen Namen oder Record im Cache bleiben darf.
Brauchst du nur die Werte, hängst du +short an. Beim A-Record blieben nur die IP-Adressen übrig, beim MX nur Priorität und Mailservername.
dig +short example.com172.66.147.243
104.20.23.154dig google.com MX +short10 smtp.google.com.Fügst du nach [+noall +answer] noch +stats hinzu, erscheinen auch die Abfragezeit und die Zeile des antwortenden Servers. Bei dig 9.18 auf dem Debian-12-Server stand am Ende der SERVER-Zeile die Übertragungsart der Abfrage, (UDP); dig 9.16 auf dem AlmaLinux-9-Server zeigte diesen Hinweis nicht.
dig example.com +noall +answer +statsexample.com. 235 IN A 172.66.147.243
example.com. 235 IN A 104.20.23.154
;; Query time: 0 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)
;; WHEN: Thu Oct 29 00:10:26 UTC 2026
;; MSG SIZE rcvd: 723️⃣ DNS-Server mit dig angeben und Reverse-Lookup
Schreibst du @ und einen DNS-Server vor den Namen, wird statt des auf dem Server eingestellten DNS-Servers dieser Server gefragt. Bei der Frage an 8.8.8.8 wechselte die SERVER-Zeile zu 8.8.8.8, und in flags kam ad hinzu.
dig @8.8.8.8 example.com; <<>> DiG 9.16.20-RH <<>> @8.8.8.8 example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61431
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 300 IN A 104.20.23.154
example.com. 300 IN A 172.66.147.243
;; Query time: 30 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct 29 00:09:29 UTC 2026
;; MSG SIZE rcvd: 72ad ist das Flag dafür, dass der antwortende Server die DNSSEC-Signaturen geprüft und die Records der Antwort als vertrauenswürdig eingestuft hat (RFC 4035). In den Antworten des auf dem Server eingestellten DNS-Servers fehlte ad.
Schreibst du einen Nameserver aus der NS-Abfrage hinter @, fragst du direkt den Server, der die Records von example.com verwaltet.
dig @elliott.ns.cloudflare.com example.com; <<>> DiG 9.16.20-RH <<>> @elliott.ns.cloudflare.com example.com
; (6 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61828
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 300 IN A 172.66.147.243
example.com. 300 IN A 104.20.23.154
;; Query time: 4 msec
;; SERVER: 2606:4700:58::a29f:2ce4#53(2606:4700:58::a29f:2ce4)
;; WHEN: Thu Oct 29 00:09:29 UTC 2026
;; MSG SIZE rcvd: 72Diesmal erschien aa in flags — der autoritative Nameserver hatte also direkt geantwortet. Weil dieser Server keine rekursive Suche unterstützt, bei der Namen über andere Server gesucht werden, fiel ra weg, und die Zeile [WARNING: recursion requested but not available] kam hinzu.
(6 servers found) bedeutet, dass der Name des Nameservers zu drei IPv4- und drei IPv6-Adressen aufgelöst wurde. In der SERVER-Zeile stand davon die IPv6-Adresse, die die Antwort geschickt hat.
Schreibst du nach -x eine IP-Adresse, fragt dig den PTR-Record ab und findet den mit dieser Adresse verknüpften Namen.
dig -x 8.8.8.8 +noall +answer8.8.8.8.in-addr.arpa. 300 IN PTR dns.google.dig fragte einen Namen ab, der aus 8.8.8.8 in umgekehrter Reihenfolge plus in-addr.arpa besteht, und dessen PTR-Wert dns.google. war der Name von 8.8.8.8.
4️⃣ Der Delegationspfad mit dig +trace
Mit +trace fragt dig der Reihe nach, beginnend bei den Root-Nameservern, und gibt Schritt für Schritt aus, an welchen Server der Name weitergegeben wurde. Laut offiziellem Handbuch fordert +trace auch DNSSEC-Signaturzeilen an; deshalb kam +nodnssec dazu, um nur den Delegationspfad zu sehen.
dig +trace +nodnssec example.com; <<>> DiG 9.16.20-RH <<>> +trace +nodnssec example.com
;; global options: +cmd
. 86333 IN NS j.root-servers.net.
. 86333 IN NS g.root-servers.net.
. 86333 IN NS b.root-servers.net.
. 86333 IN NS e.root-servers.net.
. 86333 IN NS k.root-servers.net.
. 86333 IN NS f.root-servers.net.
. 86333 IN NS l.root-servers.net.
. 86333 IN NS m.root-servers.net.
. 86333 IN NS h.root-servers.net.
. 86333 IN NS c.root-servers.net.
. 86333 IN NS d.root-servers.net.
. 86333 IN NS a.root-servers.net.
. 86333 IN NS i.root-servers.net.
;; Received 239 bytes from 192.0.2.53#53(192.0.2.53) in 1 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; Received 836 bytes from 2001:7fd::1#53(k.root-servers.net) in 30 ms
example.com. 172800 IN NS hera.ns.cloudflare.com.
example.com. 172800 IN NS elliott.ns.cloudflare.com.
;; Received 359 bytes from 2001:503:d414::30#53(f.gtld-servers.net) in 66 ms
example.com. 300 IN A 104.20.23.154
example.com. 300 IN A 172.66.147.243
;; Received 72 bytes from 108.162.195.228#53(elliott.ns.cloudflare.com) in 3 msIn jedem Schritt zeigt die letzte Zeile [Received … from] den Server, der diese Antwort geschickt hat. Die in den vier Schritten befragten Server und was zurückkam, stehen unten.
| Stufe | Befragter Server | Erhalten |
|---|---|---|
| 1 | Auf dem Server eingestellter DNS-Server (192.0.2.53) | 13 Root-Nameserver (.) |
| 2 | k.root-servers.net | 13 .com-Nameserver (gtld-servers.net) |
| 3 | f.gtld-servers.net | 2 Nameserver von example.com |
| 4 | elliott.ns.cloudflare.com | 2 A-Records von example.com |
Die Ausgabe von +trace ist wie die Sendungsverfolgung eines Einschreibens.
Der A-Record im letzten Schritt kam direkt vom Nameserver von example.com und ist daher der aktuelle Wert, nicht aus einem Cache. Direkt nach einem Nameserver-Wechsel prüfst du zuerst in Schritt 3, ob die .com-Server mit den neuen Nameservern antworten.
5️⃣ Antwortfehler und Optionen von dig
🔲 Antwortfehler
Fragst du einen Namen ab, der nicht existiert, steht in status NXDOMAIN. .invalid ist eine Top-Level-Domain, die reserviert ist, damit sie nie wirklich verwendet wird — deshalb diente sie zum Prüfen dieser Antwort.
dig example.invalid; <<>> DiG 9.16.20-RH <<>> example.invalid
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23779
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.invalid. IN A
;; AUTHORITY SECTION:
invalid. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800
;; Query time: 1 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:33 UTC 2026
;; MSG SIZE rcvd: 96ANSWER war 0, und im AUTHORITY-Abschnitt stand der SOA-Record dieser Zone. Die letzte Zahl im SOA, 10800, ist die Zeit (Sekunden), die diese Antwort im Cache bleiben darf.
no-such-host.example.com endete statt mit NXDOMAIN mit status NOERROR und ANSWER 0. Das ist eine Antwort ohne Fehlercode, in der nur die Records fehlen — prüfe deshalb status und die Anzahl unter ANSWER zusammen.
dig no-such-host.example.com; <<>> DiG 9.16.20-RH <<>> no-such-host.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31671
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;no-such-host.example.com. IN A
;; AUTHORITY SECTION:
example.com. 1800 IN SOA elliott.ns.cloudflare.com. dns.cloudflare.com. 2418004112 10000 2400 604800 1800
;; Query time: 7 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:33 UTC 2026
;; MSG SIZE rcvd: 115SERVFAIL ist der Antwortcode dafür, dass der DNS-Server keine Antwort erstellen konnte (RFC 1035). Bei der Frage an 8.8.8.8 nach dnssec-failed.org, einer öffentlichen Domain zum Testen fehlgeschlagener DNSSEC-Validierung, kam SERVFAIL zusammen mit einer EDE-Zeile.
dig @8.8.8.8 dnssec-failed.org; <<>> DiG 9.16.20-RH <<>> @8.8.8.8 dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57521
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 9 (DNSKEY Missing): (No DNSKEY matches DS RRs of dnssec-failed.org)
;; QUESTION SECTION:
;dnssec-failed.org. IN A
;; Query time: 333 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct 29 00:09:41 UTC 2026
;; MSG SIZE rcvd: 97EDE ist ein erweiterter Fehlercode, der den Grund des Fehlers angibt (RFC 8914). 9 (DNSKEY Missing) bedeutet, dass kein DNSKEY gefunden wurde, der zum DS-Record der übergeordneten Zone passt; 8.8.8.8 lieferte für einen Namen, dessen Signatur es nicht prüfen konnte, statt einer Adresse SERVFAIL.
Antwortet der DNS-Server nicht, endet die Ausgabe ohne status-Zeile mit [connection timed out; no servers could be reached]. Bei der Frage an 192.0.2.1, eine Adresse für Dokumentationsbeispiele, mit [+timeout=2 +tries=1] erschien diese Zeile nach 2 Sekunden.
dig @192.0.2.1 example.com +timeout=2 +tries=1; <<>> DiG 9.16.20-RH <<>> @192.0.2.1 example.com +timeout=2 +tries=1
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reachedOhne Optionen kam bei derselben Adresse dieselbe Zeile nach 15 Sekunden. Der Grund: Die Standardwerte im offiziellen Handbuch sind 5 Sekunden pro Antwort und 3 Versuche. Bei dig 9.18 auf dem Debian-12-Server kam zuerst die Zeile [communications error to 192.0.2.1#53: timed out], und die letzte Zeile war [no servers could be reached].
Wenn ein Skript Ergebnisse nach dem Exit-Code trennt, bedenke, dass auch NXDOMAIN 0 liefert. Nach einer Abfrage von example.invalid mit +short ergab die Ausgabe des Exit-Codes 0 bei leerem Ergebnis, während die Abfrage an 192.0.2.1, die keine Antwort bekam, 9 ergab.
dig +short example.invalid; echo $?0Für jeden Antwortfehler stehen unten die Zeile, die du in der Ausgabe prüfst, und was du danach prüfst.
| Ausgabe | Bedeutung | Als Nächstes prüfen |
|---|---|---|
| status: NXDOMAIN | Dieser Name existiert nicht | Schreibweise und Registrierungsstatus der Domain, Delegationspfad mit +trace |
| status: NOERROR · ANSWER: 0 | Kein Record dieses Typs in der Antwort | Record-Typ und Record-Einstellungen des Nameservers |
| status: SERVFAIL | Der DNS-Server konnte keine Antwort erstellen | EDE-Zeile, Antworten anderer DNS-Server (@8.8.8.8 · @1.1.1.1) |
| connection timed out | Der DNS-Server antwortet nicht | Adresse des DNS-Servers und Firewalls, die Port 53 sperren |
🔲 Optionen des dig-Befehls
📌 Wichtige Optionen: Ergebnisse aus diesem Artikel
| Option | Was es tut | Ergebnis in diesem Artikel | |
|---|---|---|---|
| @Server | Fragt statt des auf dem Server eingestellten DNS-Servers den angegebenen Server | Mit @8.8.8.8 wechselte die SERVER-Zeile zu 8.8.8.8 und in flags kam ad hinzu; beim autoritativen Nameserver aa | |
| Art | Fragt nur den Record-Typ ab, der nach dem Namen steht | example.com MX ergab eine Zeile [0 .]; kleingeschriebenes mx dasselbe Ergebnis | |
| -x Adresse | Fragt den PTR-Record einer IP-Adresse ab | -x 8.8.8.8 ergab dns.google. | |
| -v | Gibt die Version aus | 9.16 auf dem AlmaLinux-9-Server, 9.18 auf dem Debian-12-Server | |
| -r | Liest die .digrc im Home-Ordner nicht | Selbst mit +short in .digrc erschienen mit -r die Record-Zeilen vollständig | |
| +short | Gibt nur die Werte der Records aus | A ergab zwei IP-Adressen; google.com MX ergab 10 smtp.google.com. | |
| +noall +answer | Schaltet alle Ausgabeabschnitte ab und nur ANSWER wieder ein | Bei example.com NS blieben nur die zwei Nameserver-Zeilen | |
| +multiline | Teilt lange Records wie SOA auf mehrere Zeilen mit Kommentaren auf | Namen und Zeiten wie serial und refresh stehen als Kommentar neben jeder Zahl | |
| +stats | Gibt zusätzlich die Abfragezeit und die Zeile des antwortenden Servers aus | Bei dig 9.18 auf dem Debian-12-Server (UDP) am Ende der SERVER-Zeile | |
| +trace | Fragt der Reihe nach ab den Root-Nameservern und gibt den Delegationspfad aus | In jedem der vier Schritte zeigt die letzte Zeile [Received … from] den antwortenden Server | |
| +nodnssec | Fordert keine DNSSEC-Signatur-Records an | Zusammen mit +trace, damit nur der Delegationspfad bleibt | |
| +timeout=Sekunden | Wartezeit pro Antwort, Standard 5 Sekunden | Bei 192.0.2.1 mit +timeout=2 +tries=1 kam [connection timed out] nach 2 Sekunden, ohne Optionen nach 15 Sekunden | |
| +tries=Anzahl | Anzahl der gesendeten Abfragen, Standard 3 | Auf 1 gesetzt zusammen mit +timeout=2 fragte dig nur einmal und endete nach 2 Sekunden | |
| +tcp | Sendet die Abfrage per TCP statt per UDP | Bei dig 9.18 auf dem Debian-12-Server wechselte das Ende der SERVER-Zeile von (UDP) zu (TCP), die Records blieben gleich |
📎 Weitere Optionen: laut offiziellem Handbuch
| Option | Was es tut | |
|---|---|---|
| -4 | Abfrage nur über IPv4 | |
| -6 | Abfrage nur über IPv6 | |
| -t Typ | Legt den abzufragenden Record-Typ fest | |
| -q Name | Legt den abzufragenden Namen fest, damit er nicht mit anderen Argumenten verwechselt wird | |
| -p Port | Fragt über den angegebenen Port statt über Port 53 | |
| -b Adresse | Legt die Quell-IP-Adresse fest, von der die Abfrage gesendet wird | |
| -f Datei | Führt die Abfragen, die zeilenweise in einer Datei stehen, der Reihe nach aus | |
| +norecurse | Fragt mit ausgeschalteter Rekursionsanforderung (RD) | |
| +dnssec | Fordert zusätzlich DNSSEC-Records an | |
| +nssearch | Sucht die autoritativen Nameserver und gibt den SOA-Record jedes Servers aus | |
| +nocmd | Gibt ohne die Versions- und Optionszeilen am Anfang aus | |
| +nocomments | Gibt ohne Kommentarzeilen wie Antwort-Header und Abschnittsnamen aus | |
| +ttlunits | Gibt die TTL in den Einheiten s, m, h, d und w aus | |
| +retry=Anzahl | Anzahl der Wiederholungen ohne die erste Abfrage, Standard 2 |
🔲 dig-Befehl-Simulator
Im Simulator unten kannst du dig selbst eingeben und dabei Record-Typ, DNS-Server und Ausgabeoptionen wechseln.
🔢 FAQ & empfohlene Inhalte
Tools · Domains
WHOIS-Domainabfrage · Nameserver prüfen
Ein Abfrage-Tool, das nach Eingabe einer Domain Registrierungsdaten, Nameserver und DNS-Records direkt im Browser anzeigt.
Netzwerk · DNS
Linux host-Befehl | Befehl für DNS-Abfragen
Der Befehl host, mit dem du die IP-Adresse zu einem Hostnamen findest oder eine IP-Adresse in einen Hostnamen umwandelst.
ℹ️ Affiliate-Hinweis
Die Inhalte dieser Website enthalten Affiliate-Links. Kauft ein Besucher über einen dieser Links ein Produkt oder eine Dienstleistung, erhält die Website vom Verkäufer eine Provision. Der Betrag, den der Käufer zahlt(bei Aktionsrabatten sinkt er ↓), steigt dadurch nicht. Angegebene Preise, Rabatte und Lagerbestände entsprechen dem Stand bei Erstellung und können abweichen; prüfe sie daher vor dem Kauf beim Verkäufer. Produkte werden nach eigenen Kriterien ausgewählt und bewertet, und Provisionen beeinflussen weder die Reihenfolge noch den Inhalt der Bewertungen.