VMware ESXi and vSphere Cluster Management

dig-Befehl unter Linux: DNS-Abfragen durchführen und auswerten

Lerne den Linux-Befehl dig kennen: DNS-Records abfragen, Antworten interpretieren, Reverse-DNS prüfen und DNS-Probleme systematisch diagnostizieren.

dig ist ein Kommandozeilenprogramm zur Abfrage und Analyse des Domain Name System (DNS). Mit dig kannst du zum Beispiel prüfen, welche IPv4- oder IPv6-Adresse zu einem Domainnamen gehört, welche Mailserver zuständig sind oder ob eine IP-Adresse einen Reverse-DNS-Eintrag besitzt.

Dieses Kapitel richtet sich an Linux-Anwender mit grundlegender Terminal-Erfahrung. Es behandelt die wichtigsten Befehle, Ausgabeformen und Diagnosemethoden für Webserver, Mailserver und allgemeine Netzwerkprobleme.

Was ist dig und wofür wird es verwendet?

DNS ist ein Namenssystem, das Domainnamen wie example.com mit IP-Adressen und weiteren Einträgen verknüpft. Ein DNS-Server kann beispielsweise einen A-Record für IPv4 oder einen AAAA-Record für IPv6 liefern.

dig fragt DNS-Server gezielt ab und zeigt nicht nur das Ergebnis, sondern auch technische Details der Antwort. Das macht es besonders nützlich für:

• die Prüfung der Namensauflösung einer Domain,
• die Kontrolle von A-, AAAA-, MX-, NS-, CNAME-, PTR- und TXT-Records,
• die Untersuchung von DNS-Konfigurationsfehlern,
• den Vergleich verschiedener Resolver,
• die Analyse von Caching, Delegationen und Antwortzeiten,
• die Fehlersuche bei Webseiten, Mailservern und Netzwerkdiensten.

Ein Resolver ist ein DNS-Server, der Anfragen für Clients rekursiv beantwortet oder an andere DNS-Server weiterleitet. Ein autoritatives Nameserver stellt dagegen die verbindlichen DNS-Daten für eine bestimmte Zone bereit. Mit dig kannst du beide Rollen getrennt untersuchen.

Das einfachere Werkzeug host liefert meist eine kompakte Antwort und eignet sich für schnelle Prüfungen. nslookup ist ebenfalls weit verbreitet und interaktiv nutzbar. dig bietet jedoch detailliertere Kontrolle über Record-Typen, Server, Flags und Ausgabeformat und ist deshalb für DNS-Diagnosen besonders geeignet.

Installation und Verfügbarkeit

dig wird üblicherweise zusammen mit DNS-Werkzeugpaketen installiert. Prüfe zunächst, ob der Befehl vorhanden ist:

dig -v

Auf Debian, Ubuntu und verwandten Distributionen stammt dig normalerweise aus dem Paket dnsutils:

sudo apt update && sudo apt install dnsutils

Auf Fedora, RHEL und verwandten Distributionen wird das Paket meist bind-utils genannt:

sudo dnf install bind-utils

Die genaue Paketbezeichnung kann je nach Distribution und Version abweichen. Entscheidend ist, dass nach der Installation der Befehl dig im Suchpfad verfügbar ist.

Grundaufbau eines dig-Aufrufs

Die allgemeine Struktur lautet:

dig [@server] [domainname] [-t record-typ] [optionen]

• domainname ist der abzufragende Name.
• -t record-typ legt den DNS-Record-Typ fest.
• @server bestimmt den DNS-Server, der die Anfrage beantworten soll.
• Optionen wie +short oder +noall +answer steuern die Ausgabe.

Eine einfache Abfrage sieht so aus:

dig example.com

Wenn kein Record-Typ angegeben wird, fragt dig standardmäßig einen A-Record ab. Das Ergebnis enthält daher typischerweise IPv4-Adressen. Für IPv6 muss ausdrücklich nach AAAA gefragt werden.

Ein vollständig qualifizierter Domainname, kurz FQDN, kann mit einem abschließenden Punkt geschrieben werden:

dig example.com.

Der Punkt kennzeichnet die DNS-Wurzel. Dadurch wird der Name eindeutig als vollständig qualifiziert behandelt. Ohne Punkt kann ein Resolver je nach Suchdomänen-Konfiguration versuchen, einen lokalen Domain-Suffix anzuhängen. Bei öffentlichen Namen ist dieser Unterschied oft unsichtbar, bei internen Netzwerken kann er aber wichtig sein.

Eine vollständige DNS-Antwort lesen

Eine typische dig-Ausgabe besteht aus mehreren Bereichen. Die genaue Darstellung kann je nach Server und Optionen leicht variieren.

Abschnitt – Enthaltene Informationen – Praktischer Nutzen

Header – Status, Kennung, Flags sowie Anzahl der Einträge in den Abschnitten – zeigt, wie der Server die Anfrage verarbeitet hat.

Question – der abgefragte Name, die Klasse und der Record-Typ – macht sichtbar, welche DNS-Frage tatsächlich gestellt wurde.

Answer – die Resource Records als Ergebnis – enthält normalerweise die gesuchten Adressen, Namen oder Textwerte.

Authority – zuständige Nameserver oder Informationen zur Zone – hilft bei der Untersuchung von Delegationen und nicht vorhandenen Namen.

Additional – ergänzende Daten, etwa IP-Adressen von Nameservern oder Glue-Records – liefert passende Zusatzinformationen zur Antwort.

Statistikbereich – Antwortzeit, abgefragter Server, Zeitpunkt und Nachrichtengröße – unterstützt die Bewertung von Latenz und Transportweg.

Header, Status und Flags

Im Header findest du unter anderem einen Statuscode, eine Anfragekennung und Flags. Typische Statuswerte sind:

• NOERROR: Die Anfrage wurde erfolgreich verarbeitet. Das bedeutet nicht zwingend, dass der gewünschte Record existiert; ein Name kann existieren, ohne den angefragten Typ zu besitzen.
• NXDOMAIN: Der angefragte Domainname existiert aus Sicht des befragten Servers nicht.
• SERVFAIL: Der Server konnte die Auflösung nicht erfolgreich abschließen. Häufige Ursachen sind fehlerhafte Delegationen, nicht erreichbare autoritative Server oder DNSSEC-Probleme.
• REFUSED: Der Server verweigert die Anfrage, beispielsweise wegen Zugriffsregeln oder weil er für diese Anfrage nicht zuständig ist.

Wichtige Flags sind:

• qr kennzeichnet die Nachricht als Antwort.
• rd bedeutet, dass der Client eine rekursive Auflösung angefordert hat.
• ra zeigt, dass der Server rekursive Abfragen unterstützt.
• aa steht für eine autoritative Antwort. Der antwortende Server ist für die betreffende Zone zuständig.

Eine Antwort mit rd und ra stammt typischerweise von einem rekursiven Resolver. Das Flag aa deutet dagegen auf eine direkte autoritative Antwort hin. Nicht jede Antwort eines Resolvers enthält aa, selbst wenn die enthaltenen Daten korrekt sind.

Question Section

Die Question Section zeigt die formulierte DNS-Anfrage. Sie enthält normalerweise den Namen, die Abfrageklasse IN für Internet und den Record-Typ, zum Beispiel A oder MX. Dieser Bereich ist hilfreich, wenn du überprüfen möchtest, ob ein Befehl tatsächlich den erwarteten Namen und Typ abgefragt hat.

Answer Section

Die Answer Section enthält Resource Records. Ein Resource Record ist ein einzelner DNS-Eintrag mit Name, TTL, Klasse, Typ und Wert.

example.com.    300    IN    A    203.0.113.10

In diesem Beispiel ist 300 die TTL in Sekunden. Sie gibt an, wie lange ein Eintrag von einem Cache verwendet werden darf. IN bezeichnet die Internet-Klasse, A den Record-Typ und 203.0.113.10 den IPv4-Wert.

Authority und Additional Section

Die Authority Section kann die für eine Zone zuständigen Nameserver nennen. Bei einer negativen Antwort kann sie außerdem Hinweise liefern, welche Zone die Auskunft über den Namen verantwortet.

Die Additional Section enthält ergänzende Daten. Dazu gehören beispielsweise die IP-Adressen zu Nameservernamen oder sogenannte Glue-Records. Glue-Records sind zusätzliche Adressinformationen, die bei bestimmten Delegationen benötigt werden, damit ein Nameserver überhaupt erreichbar ist.

Statistikbereich

Am Ende zeigt dig normalerweise die Antwortzeit, den verwendeten DNS-Server, den Zeitpunkt und die Nachrichtengröße. Die Antwortzeit ist ein Hinweis auf die Netzwerklatenz und die Verarbeitung, aber kein vollständiger Leistungstest des DNS-Systems.

Gezielte und kompakte Ausgabe

Die vollständige Ausgabe ist für Diagnosen wertvoll, kann bei schnellen Prüfungen aber unübersichtlich sein. Dafür bietet dig verschiedene Ausgabeoptionen.

Option – Wirkung – Beispiel

+short – kompakte Ausgabe mit den wichtigsten Ergebniswerten – dig example.com +short

+noall – unterdrückt die standardmäßig angezeigten Bereiche – dig example.com +noall

+answer – zeigt die Answer Section an – dig example.com +answer

-t – wählt einen Record-Typ aus – dig example.com -t MX

-x – führt eine Reverse-DNS-Abfrage aus – dig -x 203.0.113.10

@server – verwendet einen bestimmten DNS-Server – dig @8.8.8.8 example.com

Nur die Answer Section erhältst du mit:

dig example.com +noall +answer

Die Kombination bedeutet: Alle Standardbereiche ausblenden und anschließend nur den Antwortbereich aktivieren. Das ist gut geeignet, wenn du TTL, Record-Typ und Wert sehen möchtest.

Für eine besonders schnelle Prüfung verwendest du:

dig example.com +short

+short eignet sich für interaktive Tests und einfache Skripte. Die Ausgabe enthält jedoch weniger Kontext. Für eine echte Diagnose solltest du zusätzlich die vollständige Ausgabe oder mindestens +noall +answer prüfen.

Häufige DNS-Record-Typen abfragen

Typ – Zweck – Typischer Inhalt – Beispielhafte Anwendung

A – Zuordnung zu IPv4 – IPv4-Adresse – Erreichbarkeit eines Webservers prüfen.

AAAA – Zuordnung zu IPv6 – IPv6-Adresse – IPv6-Namensauflösung testen.

CNAME – Alias auf einen kanonischen Namen – Ziel-Domainname – Weiterleitung eines Hostnamens nachvollziehen.

MX – Mailserver einer Domain – Priorität und Mailservername – Zustellung von E-Mails untersuchen.

NS – autoritative Nameserver einer Zone – Nameservername – Delegation und Zuständigkeit prüfen.

PTR – Reverse-Auflösung – Hostname zu einer IP-Adresse – Reverse DNS und Mailserver-Reputation prüfen.

TXT – textbasierte Zusatzinformationen – Zeichenkette – SPF, DKIM-bezogene Informationen und Domainverifizierung untersuchen.

A- und AAAA-Records

dig example.com -t A

dig example.com -t AAAA

Mit der ersten Abfrage prüfst du IPv4-Adressen, mit der zweiten IPv6-Adressen. Ein fehlender AAAA-Record bedeutet nicht automatisch einen Fehler; die Domain kann ausschließlich über IPv4 erreichbar sein.

MX-Records

dig example.com -t MX

Ein MX-Record enthält eine Priorität und einen Mailservernamen. Niedrigere Zahlen haben höhere Priorität. Existieren mehrere MX-Records, versucht ein sendender Mailserver normalerweise zuerst den Eintrag mit der niedrigsten Prioritätszahl.

Die im MX-Record genannten Hostnamen müssen selbst auflösbar sein. Prüfe sie deshalb zusätzlich mit A- und AAAA-Abfragen.

NS-Records

dig example.com -t NS

NS-Records nennen die autoritativen Nameserver einer Domain oder Zone. Sie sind ein wichtiger Ausgangspunkt, wenn du eine Delegation untersuchen oder einen autoritativen Server direkt abfragen möchtest.

CNAME-Records

dig www.example.com -t CNAME

Ein CNAME ist ein Alias auf einen anderen Domainnamen. Der Alias kann anschließend weitere Abfragen auslösen. Bei einer Diagnose solltest du deshalb sowohl den CNAME als auch den Zielnamen prüfen:

dig www.example.com -t CNAME
dig ziel.example.net -t A
dig ziel.example.net -t AAAA

In einer technischen HTML-Dokumentation wird der Zeilenumbruch im Beispiel durch die Ausgabeformatierung dargestellt; im Terminal stehen die Befehle jeweils in einer eigenen Zeile.

TXT-Records

dig example.com -t TXT

TXT-Records enthalten Textwerte. Sie werden häufig für SPF-Mailrichtlinien, DKIM-bezogene Informationen und Domainverifizierungen verwendet. Die Ausgabe kann mehrere Zeichenketten enthalten und durch Anführungszeichen oder Escaping unübersichtlich wirken.

ANY-Abfragen

dig example.com -t ANY

ANY fragt nicht einfach zuverlässig alle vorhandenen Record-Typen ab. Moderne DNS-Server liefern aus Sicherheits-, Last- oder Datenschutzgründen häufig eine eingeschränkte Antwort oder verweigern die Anfrage. Für eine belastbare Prüfung sind getrennte Abfragen von A, AAAA, MX, NS, CNAME und TXT besser geeignet.

Reverse DNS mit -x

Bei einer normalen DNS-Abfrage wird ein Name in eine Adresse aufgelöst. Eine Reverse-DNS-Auflösung versucht das Gegenteil: Eine IP-Adresse wird einem Hostnamen zugeordnet. Technisch basiert das auf einem PTR-Record.

dig -x 203.0.113.10

Für IPv4 verwendet DNS dafür die spezielle Zone in-addr.arpa; bei IPv6 wird ip6.arpa verwendet. Die Option -x erzeugt die passende Reverse-Abfrage automatisch.

Reverse DNS ist unter anderem wichtig für:

• Mailserver, deren ausgehende IP-Adresse häufig einen passenden PTR-Eintrag benötigt,
• lesbare Hostnamen in Logs und Monitoring-Systemen,
• Netzwerkdiagnosen und die Zuordnung von Adressen zu Geräten oder Diensten.

Nicht jede IP-Adresse besitzt einen PTR-Record. Bei vielen Netzen verwaltet der Provider oder der Inhaber des Adressbereichs die Reverse-Zone. Ein fehlendes Ergebnis ist daher nicht automatisch ein Problem des lokalen DNS-Servers.

Einen bestimmten DNS-Server abfragen

Mit @server legst du fest, an welchen DNS-Server die Anfrage gesendet wird:

dig @1.1.1.1 example.com

dig @8.8.8.8 example.com

Ohne @server verwendet dig normalerweise den im System konfigurierten Resolver, der häufig aus /etc/resolv.conf oder einer lokalen Netzwerkverwaltung stammt.

Ein öffentlicher oder lokaler rekursiver Resolver beantwortet Anfragen oft aus seinem Cache oder ermittelt die Daten über die DNS-Hierarchie. Ein autoritativer Nameserver liefert dagegen die verbindlichen Daten seiner Zone. Den autoritativen Server kannst du nach einer NS-Abfrage gezielt testen:

dig example.com -t NS
dig @ns1.example.com example.com -t A

Der Vergleich verschiedener Resolver ist eine wichtige Diagnosemethode:

• Unterschiede können durch Caching und noch nicht abgelaufene TTL-Werte entstehen.
• Abweichungen können auf unterschiedliche Zonendaten oder fehlerhafte Delegationen hinweisen.
• Eine direkte Abfrage des autoritativen Servers hilft, Cache-Effekte von tatsächlichen Zonendaten zu trennen.

Praktische DNS-Diagnose

Domain existiert nicht: NXDOMAIN

Wenn der Status NXDOMAIN erscheint, existiert der angefragte Name aus Sicht des befragten Servers nicht.

dig nicht-vorhanden.example

Prüfe zunächst die Schreibweise und den vollständigen Domainnamen. Wiederhole die Abfrage gegen einen anderen Resolver und untersuche anschließend die NS-Records der übergeordneten Zone. Beachte, dass ein Cache eine negative Antwort ebenfalls eine Zeit lang speichern kann.

SERVFAIL verstehen

SERVFAIL bedeutet, dass der Resolver die Auflösung nicht erfolgreich abschließen konnte. Mögliche Ursachen sind nicht erreichbare autoritative Nameserver, fehlerhafte Delegationen, Probleme bei DNSSEC oder eine allgemein gestörte rekursive Auflösung.

1. Frage die Domain über einen zweiten Resolver ab.
2. Ermittle die autoritativen Nameserver mit einer NS-Abfrage.
3. Frage einen autoritativen Nameserver direkt ab.
4. Untersuche bei widersprüchlichen Ergebnissen auch DNSSEC.

Fehlender A- oder AAAA-Record

Ein erwarteter Record kann fehlen, falsch geschrieben sein, noch nicht bei allen Resolvern angekommen sein oder durch einen CNAME ersetzt werden.

dig example.com -t A +noall +answer
dig example.com -t AAAA +noall +answer
dig example.com -t CNAME +noall +answer

Vergleiche außerdem TTL-Werte und frage den autoritativen Nameserver direkt ab. So lässt sich feststellen, ob der Eintrag in der Zone fehlt oder nur in einem Resolver-Cache noch nicht sichtbar ist.

Probleme bei der E-Mail-Zustellung

Wenn E-Mails eine Domain nicht erreichen, prüfe zunächst die MX-Records:

dig example.com -t MX +noall +answer

Kontrolliere anschließend für jeden genannten Mailserver die A- und AAAA-Records. Häufige Fehler sind fehlende MX-Einträge, nicht auflösbare Mailservernamen oder eine fehlerhafte Konfiguration der Prioritäten. Reverse DNS und TXT-Einträge mit Mailrichtlinien sind ergänzende Prüfungen, ersetzen aber nicht die Analyse der MX-Daten.

Reverse Lookup ohne Ergebnis

Ein leerer Antwortbereich bei einer Reverse-Abfrage bedeutet meist, dass kein PTR-Record eingerichtet ist:

dig -x 203.0.113.10 +noall +answer

Klär bei produktiven Adressen, ob der Provider oder Netzbetreiber die Reverse-Zone verwaltet. Vorwärts- und Rückwärtsauflösung sind getrennte DNS-Konfigurationen: Ein A-Record garantiert keinen PTR-Record und umgekehrt.

Unterschiedliche Ergebnisse verschiedener DNS-Server

Wenn Resolver unterschiedliche Antworten liefern, vergleiche sie ausdrücklich:

dig @1.1.1.1 example.com -t A
dig @8.8.8.8 example.com -t A
dig example.com -t A

Prüfe in den Antworten den verwendeten Server, die TTL, den Status und die Flags. Danach frage die autoritativen Nameserver direkt ab. So kannst du Caching, unterschiedliche Zonendaten und Delegationsfehler voneinander unterscheiden.

Rekursive und autoritative Antworten unterscheiden

Bei einer rekursiven Abfrage bittet der Client einen Resolver, die vollständige Auflösung zu übernehmen. Das wird typischerweise durch das Flag rd signalisiert. Unterstützt der Server Rekursion, erscheint häufig zusätzlich ra.

Eine Antwort mit aa ist autoritativ. Sie stammt von einem Server, der die betreffende Zone selbst verwaltet. Ein rekursiver Resolver kann gültige Daten liefern, ohne autoritativ für die Zone zu sein. Für die Diagnose ist dieser Unterschied entscheidend: Der Resolver zeigt möglicherweise einen Cache-Zustand, während der autoritative Server den aktuellen Zoneninhalt liefert.

DNSSEC als weiterführendes Thema

DNSSEC ergänzt DNS um digitale Signaturen, mit denen Resolver die Authentizität von DNS-Daten prüfen können. dig kann DNSSEC-bezogene Records und Flags anzeigen. Für eine vertiefte Untersuchung werden häufig Optionen wie +dnssec verwendet.

Ein SERVFAIL kann bei DNSSEC-Problemen auftreten, etwa wenn Signaturen ungültig sind oder Delegationsinformationen nicht zusammenpassen. Eine DNSSEC-Diagnose erfordert jedoch zusätzliches Wissen über DNSKEY-, DS- und RRSIG-Records sowie die Vertrauenskette.

Häufige Statuscodes im Überblick

Status – Bedeutung – Mögliche nächste Prüfung

NOERROR – Anfrage erfolgreich verarbeitet – Answer Section und angefragten Record-Typ kontrollieren.

NXDOMAIN – Name existiert nicht – Schreibweise, anderen Resolver und übergeordnete NS-Records prüfen.

SERVFAIL – Auflösung konnte nicht abgeschlossen werden – anderen Resolver, autoritative Server und DNSSEC prüfen.

REFUSED – Server verweigert die Anfrage – Zugriffsregeln, Serverrolle und verwendeten Resolver untersuchen.

timeout – innerhalb der Wartezeit keine Antwort erhalten – Netzwerkverbindung, Firewall, Server-Erreichbarkeit und UDP/TCP-DNS prüfen.

Praktische Befehlsübersicht

dig example.com
 dig example.com +noall +answer
 dig example.com +short
 dig example.com -t A
 dig example.com -t AAAA
 dig example.com -t MX
 dig example.com -t NS
 dig www.example.com -t CNAME
 dig example.com -t TXT
 dig -x 203.0.113.10
 dig @8.8.8.8 example.com

Zusammenfassung

dig ist ein flexibles Werkzeug, um DNS-Abfragen unter Linux durchzuführen und ihre Antworten technisch zu bewerten. Die wichtigsten Grundlagen sind:

• Ohne Typangabe wird normalerweise ein A-Record abgefragt.
• Mit -t wählst du A, AAAA, MX, NS, CNAME, TXT oder andere Record-Typen.
• -x fragt den PTR-Record einer IP-Adresse ab.
• @server ermöglicht den Vergleich bestimmter Resolver oder autoritativer Nameserver.
• +noall +answer zeigt gezielt den Antwortbereich.
• +short liefert eine kompakte Ausgabe, aber weniger Diagnoseinformationen.
• NOERROR, NXDOMAIN, SERVFAIL, REFUSED, TTL und Flags wie aa, rd und ra helfen bei der Interpretation.

Für weiterführende Abfragen kannst du das Thema mit dem dig-Befehl unter Linux als Referenz verknüpfen.