DNS-Abfrage mit dem Befehl „dig“: Beispiele

Linux 9 Min. Lesezeit

dig (Domain Information Groper) ist ein grundlegendes Werkzeug zur DNS-Fehlerbehebung: Es fragt einen DNS-Server nach einem bestimmten Eintrag einer Domain ab und gibt die Antwort detailliert aus. Damit können Sie überprüfen, ob die Domain auf die richtige IP-Adresse verweist, ob der MX- oder TXT-Eintrag korrekt eingerichtet wurde und ob eine DNS-Änderung bereits auf einem bestimmten Server angekommen ist.

Die Beispiele wurden im Oktober 2026 auf einem AlmaLinux 10.2-System mit der Version 9.18.33 von „dig“ auf unserer eigenen Domain awh.hu ausgeführt. Die Ergebnisse spiegeln den Stand zum Zeitpunkt des Tests wider; auf Ihrer Domain werden Sie natürlich andere Ergebnisse sehen. Einen Überblick zur schnellen Netzwerkfehlerbehebung (Ping, Traceroute, curl) bietet der Artikel „Netzwerkfehlerbehebung“.

Installation

dig ist im Paket „bind-utils“ enthalten (unter Ubuntu und Debian „dnsutils“). Im Cloud-Image von AlmaLinux ist es standardmäßig nicht enthalten:

sudo dnf install bind-utils
dig -v

Die erste Abfrage und die Ausgabe

dig @1.1.1.1 www.awh.hu

Die vollständige Ausgabe von „dig @1.1.1.1 www.awh.hu“: Header mit dem Status „NOERROR“, Abfrageabschnitt, Antwortabschnitt mit einem CNAME- und zwei A-Einträgen, Abfragezeit und antwortender Server

Bestandteile der Ausgabe:

  • ÜBERSCHRIFT: Der status gibt das Ergebnis der Anfrage an. NOERROR = erfolgreich, NXDOMAIN = dieser Name existiert nicht, SERVFAIL = der Server konnte nicht antworten (häufig fehlerhaftes DNSSEC oder nicht erreichbarer Nameserver).
  • Flags: „qr“ kennzeichnet, dass es sich um eine Antwort handelt, „rd“ und „ra“, dass eine rekursive Abfrage angefordert wurde und der Server diese unterstützt. Wenn in der Antwort „aa“ enthalten ist, stammt diese von den eigenen (autoritativen) Nameservern der Domain; wenn „ad“ enthalten ist, wurde die Antwort einer DNSSEC-Überprüfung unterzogen.
  • FRAGEN: Was haben wir gefragt?
  • ANTWORTBEREICH: Die Einträge der Antwort. Die Spalten: Name, TTL (wie viele Sekunden die Antwort im Cache gespeichert werden kann), Klasse (IN), Typ, Wert. Im obigen Beispiel ist www.awh.hu ein CNAME, der auf einen anderen Namen verweist, und dig hat auch dessen A-Einträge ausgegeben.
  • AUTHORITY und ADDITIONAL SECTION: Die Nameserver der Domain und deren Adressen, sofern der Server diese ebenfalls übermittelt hat.
  • Abfragezeit, SERVER: Wie lange hat die Abfrage gedauert und welcher DNS-Server hat geantwortet?

Datensatztypen

Der Typ kann hinter der Domain angegeben werden; die Standardeinstellung ist „A“:

dig awh.hu A        # IPv4-cím
dig awh.hu AAAA     # IPv6-cím
dig awh.hu MX       # levelezőszerverek
dig awh.hu NS       # névszerverek
dig awh.hu TXT      # szöveges rekordok (SPF, ellenőrző kódok)
dig awh.hu SOA      # a zóna adatai
dig awh.hu CAA      # mely tanúsítványkiadók adhatnak SSL-t
dig awh.hu HTTPS    # kapcsolódási tippek a böngészőknek (HTTP/3, IP-címek)
dig _dmarc.awh.hu TXT

Die Authentifizierungsdatensätze für E-Mails lauten auf eigene Namen und nicht auf den Domainnamen: DMARC ist der TXT-Eintrag „_dmarc.domain.hu“, DKIM der TXT-Eintrag „<szelektor>._domainkey.domain.hu“. Der DKIM-Selektor wird durch den Wert „s=“ im DKIM-Signature-Header einer gesendeten E-Mail angegeben. Der Befehl „dig domain.hu TXT“ gibt daher nur den SPF-Eintrag zurück, nicht jedoch den DMARC- und den DKIM-Eintrag.

Welcher Eintrag wozu dient, wird im Artikel „Arten von DNS-Einträgen“ zusammengefasst.

Nur die Antwort: +short und +noall +answer

Anstelle der vollständigen Ausgabe gibt „+short“ nur die Werte aus:

dig +short awh.hu MX
40 route2.mx.cloudflare.net.
87 route1.mx.cloudflare.net.
55 route3.mx.cloudflare.net.

Bei einem MX-Eintrag gibt die erste Zahl die Priorität an: Der Server mit der niedrigeren Zahl erhält die E-Mail zuerst. Wenn Sie den Namen und die TTL anzeigen möchten, die übrigen Angaben jedoch nicht:

dig awh.hu MX +noall +answer
awh.hu.                 286     IN      MX      87 route1.mx.cloudflare.net.
awh.hu.                 286     IN      MX      55 route3.mx.cloudflare.net.
awh.hu.                 286     IN      MX      40 route2.mx.cloudflare.net.

+ttlunits gibt die TTL in lesbarer Form aus (beispielsweise 5h58m46s). In einem Befehl können mehrere Abfragen angegeben werden: dig +noall +answer awh.hu A www.awh.hu CNAME.

Wenn Sie eine bestimmte Einstellung stets verwenden möchten, tragen Sie diese in die Datei „.digrc“ in Ihrem eigenen Verzeichnis ein (beispielsweise „+noall +answer“); „dig“ liest diese bei jedem Start ein. Dies kann zu Überraschungen führen: Im Test gab „dig awh.hu“ awh.hu neben einer „.digrc“-Datei mit dem Inhalt „+short“ ebenfalls nur die IP-Adressen aus. Der Schalter -r ignoriert die .digrc-Datei; seine Verwendung empfiehlt sich in Skripten und bei der Fehlersuche (dig -r awh.hu).

Abfrage eines bestimmten DNS-Servers

dig fragt den nach dem @ angegebenen Server anstelle der standardmäßigen DNS-Server des Computers ab:

dig @1.1.1.1 awh.hu +short          # Cloudflare
dig @8.8.8.8 awh.hu +short          # Google
dig @jakub.ns.cloudflare.com awh.hu +norecurse

Letzterer fragt den eigenen Nameserver der Domain ab. In der Kopfzeile der Antwort steht in diesem Fall „aa“ (authoritative answer): Dies ist die Quelle; alle anderen Server liefern eine zwischengespeicherte Kopie davon. Wenn nach einer DNS-Änderung der autoritative Server bereits den neuen Wert liefert, der Server @8.8.8.8 jedoch noch den alten, ist die Änderung in den Caches noch nicht vollständig durchgelaufen; dies klärt sich von selbst, sobald die TTL abgelaufen ist. Ausführlich: Was ist eine DNS-Propagierung?

Verschiedene Server können für denselben Namen unterschiedliche, aber gleichermaßen korrekte Antworten liefern. Im Test lieferten beispielsweise für den „awh.hu“-A-Eintrag hinter Cloudflare der eigene DNS-Server des Rechners und die IP-Adresse 1.1.1.1 unterschiedliche IP-Adressen zurück, da Cloudflare die Antwort je nach Abfragender Server variiert.

Der vollständige Pfad: +trace

dig +trace www.awh.hu

+trace arbeitet nicht mit einem Cache, sondern durchläuft die gesamte Kette: von den Root-Servern (.) über die .hu-Nameserver bis hin zum eigenen Nameserver der Domain. So verlief die Abfrage im Test:

;; Received 813 bytes from 10.0.2.3#53(10.0.2.3) in 10 ms
;; Received 794 bytes from 199.7.83.42#53(l.root-servers.net) in 20 ms
;; Received 465 bytes from 5.28.0.97#53(a.hu) in 20 ms
;; Received 176 bytes from 172.64.34.116#53(treasure.ns.cloudflare.com) in 20 ms

Wenn die Kette an einer Stelle unterbrochen ist oder zu einem falschen Nameserver führt, liegt dort der Fehler. Nach dem Kauf einer Domain oder einem Nameserver-Wechsel können Sie auf diese Weise überprüfen, ob die Registrierung der .hu-Domain (oder einer anderen Domainendung) bereits die neuen Nameserver angibt.

Umgekehrte Suche: -x

Den zu einer IP-Adresse gehörenden Namen (PTR-Eintrag) ermitteln:

dig -x 1.1.1.1 +short
one.one.one.one.

Bei E-Mail-Servern ist es wichtig, dass der PTR-Eintrag der ausgehenden IP-Adresse auf einen Namen verweist, der bei einer Rückwärtsauflösung wieder auf dieselbe IP-Adresse führt; fehlt dieser Eintrag, stuft viele empfangende Server die E-Mail als Spam ein. Der PTR-Eintrag befindet sich nicht in der DNS-Zone der Domain, sondern beim Inhaber der IP-Adresse, also beim Serveranbieter; bei einem eigenen Server muss die Einrichtung dort beantragt werden.

Nicht vorhandener Name

dig nincsilyen-domain-12345.hu

In der Kopfzeile steht „status: NXDOMAIN“, der Antwortabschnitt ist leer. Wenn Sie bei einer existierenden Domain einen NXDOMAIN-Eintrag erhalten, ist entweder der Name des Eintrags fehlerhaft oder die Domain ist nicht (oder nicht mehr) registriert.

Wenn der Name existiert, der angeforderte Datensatztyp jedoch nicht vorhanden ist (beispielsweise wenn für eine Domain kein AAAA-Eintrag vorliegt), lautet der Antwortstatus: NOERROR, der Antwortabschnitt ist jedoch leer. Dies ist kein Fehler, sondern bedeutet lediglich, dass der betreffende Datensatz fehlt.

Fehlerzustände: SERVFAIL, REFUSED, Zeitüberschreitung

SERVFAIL

Der Server konnte die Anfrage nicht beantworten. Eine häufige Ursache hierfür ist ein fehlerhaftes DNSSEC. Mit dem Schalter „+cdflag“ (Prüfung deaktiviert) antwortet der Server ohne Überprüfung; wenn in diesem Fall eine Antwort erfolgt, liegt der Fehler bei DNSSEC. Der Test wurde mit einer absichtlich fehlerhaft gestalteten Testdomain durchgeführt:

dig @1.1.1.1 dnssec-failed.org A            # status: SERVFAIL, EDE: 9 (DNSKEY Missing)
dig @1.1.1.1 dnssec-failed.org A +cdflag    # status: NOERROR, flags: qr rd ra cd

Die Zeile „EDE“ (Extended DNS Error) gibt auch die Ursache des Fehlers an. Das +cdflag dient lediglich der Fehlersuche, nicht der Behebung.

ABGELEHNT

Der Server hat die Antwort verweigert. Dies tritt auf, wenn ein autoritativer Nameserver nach einer Domain abgefragt wird, die er nicht bedient (im Test endete der Befehl „dig @jakub.ns.cloudflare.com google.com“ so), oder wenn ein geschlossener DNS-Server von außen abgefragt wird.

Zeitüberschreitung

Wenn der Server nicht antwortet, gibt „dig“ folgende Meldung aus:

;; communications error to 192.0.2.1#53: timed out
;; no servers could be reached

Standardmäßig werden mehrere Versuche unternommen; bei den Einstellungen „+time=2 +tries=1“ wird der Vorgang nach zwei Sekunden und einem Versuch abgebrochen.

Exit-Code in Skripten

Bei Skripten ist es wichtig, dass der Exit-Code von „dig“ unabhängig vom Ergebnis der DNS-Antwort ist: Im Test betrug er auch nach einer „NXDOMAIN“-Antwort 0, bei einem nicht erreichbaren Server hingegen 9. Ob der Name existiert, muss dem Feld „status“ entnommen werden.

Der Befehl „dig“ berücksichtigt die Datei „/etc/hosts“ nicht

dig fragt immer direkt einen DNS-Server ab und liest die Datei /etc/hosts des Rechners nicht. Im Test wurde der in /etc/hosts eingetragene Name „proba.awh.hu“ vom Befehl „getent hosts proba.awh.hu“ gefunden, während „dig +short proba.awh.hu“ eine leere Antwort lieferte. Sollte ein Programm den Namen anders auflösen als dig, überprüfen Sie bitte auch die Datei /etc/hosts (sowie die Ausgabe von „getent hosts“, die der vollständigen Namensauflösung durch das System folgt).

ANY-Abfrage

Früher lieferte der Befehl „dig awh.hu ANY“ alle Einträge zurück. Heutzutage geben viele Nameserver bewusst keine aussagekräftigen Antworten auf diese Anfrage (RFC 8482). Im Test lieferten die autoritativen Cloudflare-Nameserver von awh.hu folgende Antwort:

awh.hu.                 3600    IN      HINFO   "RFC8482" ""

Der eigene, zwischenspeichernde DNS-Server des Systems hat auf dieselbe Anfrage zwar mehrere Einträge zurückgegeben, jedoch nicht unbedingt alle. Wenn Sie alle Einträge einer Domain einsehen möchten, fragen Sie diese bitte nach Typ ab oder sehen Sie in der DNS-Verwaltungsoberfläche nach.

DNSSEC

dig @1.1.1.1 +dnssec awh.hu
dig awh.hu DS +short

„+dnssec“ fordert zusammen mit der Antwort auch die Signatur (RRSIG-Eintrag) an. Wenn der abgefragte Server die Signaturen überprüft und alles in Ordnung ist, erscheint im Header die Kennzeichnung „ad“:

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

Der DS-Eintrag in der übergeordneten Zone (hier in der ..hu-Zone) gibt an, dass die Domain signiert ist. Ist der DS-Eintrag vorhanden, die Signaturen jedoch fehlerhaft, geben die Validierungsserver einen SERVFAIL-Fehler zurück. Weitere Informationen zu DNSSEC finden Sie in den Artikeln „Was ist DNSSEC?“ und „Kann DNSSEC Probleme verursachen?“.

Weiterleitung Was macht das Programm?
+tcp Die Abfrage erfolgt über TCP statt über UDP (falls die Firewall UDP-Verkehr filtert)
-p 5353 Die Frage an einen anderen Ansprechpartner weiterleiten
-4, -6 kommuniziert ausschließlich über IPv4 bzw. ausschließlich über IPv6
+norecurse keine Rekursion erforderlich; bei Abfrage eines autoritativen Servers
+time=2 +tries=1 Kürzere Wartezeit, ein Versuch
-r Die Datei „~/.digrc“ wird nicht eingelesen
-f fajl.txt Führt pro Zeile eine Abfrage aus einer Datei aus

Versuchen Sie eine Zonenübertragung (dig @szerver domain.hu AXFR) bitte nur bei Ihrer eigenen, von Ihnen verwalteten Zone: Auf fremden Servern könnte dies als unbefugter Versuch angesehen werden, und die konfigurierten Server würden den Versuch ohnehin ablehnen.

Überprüfung der DNS-Änderungen

Wenn die Domain die Nameserver des Webhostings nutzt, können Sie die Einträge im KeyHelp-DNS-Editor ändern: DNS-Einträge im Webhosting bearbeiten. Nach der Änderung zeigt der Befehl „dig +short NS domain.hu“ die Nameserver der Domain an, während der Befehl „dig @<névszerver> domain.hu“ die Informationen anzeigt, die der Nameserver bereits ausgibt; hier sollte sofort der neue Wert angezeigt werden. Bei den übrigen DNS-Servern kann bis zum Ablauf der alten TTL noch der alte Wert angezeigt werden. Eine neue Domain können Sie auf der Seite zur Domainregistrierung suchen; über die Einträge informiert Sie unser Blogbeitrag ausführlich.

Zurück: Linux-Artikel (62)