Linux · Netzwerkdiagnose

Linux: DNS-Probleme systematisch eingrenzen

Wenn ein Hostname nicht funktioniert, ist „DNS kaputt“ noch keine Diagnose. Diese Reihenfolge trennt die lokale Resolver-Konfiguration, die Namensauflösung des Systems und eine DNS-Abfrage voneinander – und zeigt, was jeder Befund tatsächlich belegt.

1. Lokale Netz- und DNS-Konfiguration ansehen

Beginne beim betroffenen Gerät und während der Störung. Die Linux-Diagnose von admin-tools liest mit ip -j address show die Schnittstellenadressen und führt danach resolvectl status aus. So erkennst du aktive Links, zugeordnete DNS-Server und gegebenenfalls Such- oder Routing-Domains.

ip -j address show
resolvectl status

resolvectl gehört zu systemd-resolved und ist nicht auf jeder Distribution vorhanden oder aktiv. Fehlt das Programm, liest die Projektprüfung ersatzweise /etc/resolv.conf:

cat /etc/resolv.conf

Die Datei kann statisch, durch NetworkManager oder ein anderes Netzwerkwerkzeug erzeugt oder ein Stub-Eintrag für einen lokalen Resolver sein. Deshalb zeigt sie nicht immer den vollständigen Weg bis zum Upstream-DNS. Verlasse dich auf resolvectl-Angaben nur, wenn systemd-resolved tatsächlich verwendet wird; distributions- und VPN-spezifische DNS-Routen können pro Verbindung abweichen.

Noch nichts ändern

Ein unerwarteter DNS-Server oder eine leere Ausgabe ist ein Hinweis, aber noch kein Beweis für die Ursache. Überschreibe /etc/resolv.conf nicht und starte keinen Dienst neu, bevor geklärt ist, welches Netzwerkwerkzeug die Konfiguration verwaltet.

2. Systemauflösung von einer DNS-Abfrage unterscheiden

Zuerst den Systempfad: getent

getent ahosts service.example

getent fragt die vom System konfigurierte Namensauflösung ab. Auf glibc-Systemen läuft das über die NSS-Regeln in /etc/nsswitch.conf: Die Antwort kann zum Beispiel aus /etc/hosts, DNS, einem lokalen systemd-resolved-Stub oder einer weiteren eingerichteten Quelle stammen. Eine erfolgreiche Ausgabe beweist daher nicht, dass gerade ein DNS-Server erreicht wurde. Bei Fehlschlag liefert getent oft weniger Diagnosehinweise als ein DNS-Werkzeug.

Dann den DNS-Resolver direkt fragen: dig

dig +time=3 +tries=1 service.example A

dig fragt den im Resolverpfad konfigurierten DNS-Server nach einem A-Record. Es umgeht dabei die NSS-Auswahl und /etc/hosts, verwendet ohne zusätzliche Serverangabe aber weiterhin den konfigurierten Resolver. Das ist die direkte DNS-Abfrage, die der Linux-Katalog vorsieht; eine Abfrage an einen frei gewählten Server gehört nicht zu dieser Prüfung. Ist dig nicht installiert, versucht das Diagnosewerkzeug nslookup -timeout=3 service.example. Fehlen beide Programme, lautet das Ergebnis „nicht verfügbar“ – installiere für diese Anleitung nichts ungeprüft nach.

Interne Namen schützen

Gib interne Hostnamen oder Suchdomains nicht testweise an öffentliche DNS-Server weiter. Split-DNS und VPN können absichtlich andere Antworten liefern. Nutze für Vergleiche nur freigegebene Ziele und beachte die Regeln deiner Organisation.

3. Ausgabe und Fehlermeldungen einordnen

Diese vollständig erfundene Ausgabe nutzt nur Dokumentationsadressen aus 192.0.2.0/24. service.example und die Werte sind Beispiele, keine echten internen Systeme oder Nutzerdaten:

$ getent ahosts service.example
192.0.2.42  STREAM service.example

$ dig +time=3 +tries=1 service.example A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; ANSWER SECTION:
service.example.  60  IN  A  192.0.2.42

Ergebnis	Bedeutung und nächster Schritt
NOERROR mit Antwort	Der angefragte Record-Typ wurde im verwendeten DNS-Namensraum beantwortet. Das beweist weder die Erreichbarkeit des Dienstes noch, dass jede Anwendung denselben Resolverpfad nutzt.
NOERROR ohne Antwort	Der Name kann existieren, aber keinen Record des abgefragten Typs haben (NODATA). Vergleiche A und AAAA, bevor du „Name existiert nicht“ folgerst.
NXDOMAIN	Der befragte DNS-Namensraum meldet den Namen als nicht vorhanden. Prüfe Schreibweise, Suchdomain und ob der richtige VPN- oder interne DNS-Kontext aktiv ist; es bedeutet nicht automatisch, dass der DNS-Dienst ausgefallen ist.
SERVFAIL	Der Resolver konnte die Anfrage nicht erfolgreich beantworten. Ursachen können etwa ein Upstream-, Delegations- oder Validierungsproblem sein; der Status allein bestimmt die konkrete Ursache nicht.
REFUSED	Der Server lehnt die Anfrage nach seiner Richtlinie ab. Prüfe, ob dieser Client und dieser Name für den verwendeten Resolver vorgesehen sind.
Zeitüberschreitung / kein Server erreichbar	Es kam keine passende DNS-Antwort zurück. Prüfe zuerst den ausgewiesenen Resolver, lokale Route und Filter sowie VPN-Verbindung; Timeout beweist für sich weder einen DNS-Serverdefekt noch einen allgemeinen Netzausfall.
getent ohne Treffer	Das zeigt nur, dass die Systemauflösung keinen Treffer lieferte. Ein hosts-Eintrag, NSS-Reihenfolge, fehlende Werkzeuge oder ein abweichender Suchpfad können den Unterschied zu dig erklären.

4. In dieser Reihenfolge weiter eingrenzen

Ziel und Zeitpunkt festhalten. Notiere den betroffenen Hostnamen, Anwendung, Netzwerk/VPN und ob der Fehler gerade auftritt. Nutze keine echten internen Namen in einem öffentlichen Ticket.
Konfiguration prüfen. Führe ip -j address show und – wenn vorhanden – resolvectl status aus. Bei fehlendem resolvectl zeigt cat /etc/resolv.conf nur die lokale Resolverdatei, nicht zwingend alle dynamischen Regeln.
Systemauflösung testen. getent ahosts service.example zeigt den Weg, den typische Systemanwendungen nutzen. Keine Antwort ist ein Anlass für den direkten Vergleich, keine Fehlerursache für sich.
DNS-Antwort separat prüfen. dig +time=3 +tries=1 service.example A; falls dig fehlt, nslookup -timeout=3 service.example. Vergleiche Status und Record-Typ, nicht nur den Exitcode.
Auflösung und Erreichbarkeit trennen. Löst der Name auf, aber die Anwendung scheitert, liegt der nächste Schritt bei Route, Firewall, TCP-Port, Dienst oder Anwendung. Ein Ping zu einer numerischen Adresse – als separate vorhandene Linux-Prüfung – testet ICMP, nicht den Anwendungsport; keine Ping-Antwort kann auch an ICMP-Filterung liegen.
Mit einem funktionierenden Vergleichsgerät abgleichen. Gleicher Name, gleicher Record-Typ, gleiche Verbindung und derselbe Zeitpunkt helfen, clientseitige von standort-, VPN- oder resolverbezogenen Unterschieden zu trennen. Jede Probe bleibt eine Momentaufnahme.

Was die Ergebnisse nicht aussagen

Ein unter Linux nicht portabel abfragbarer DNS-Cache ist für sich kein Defekt. Linux-Installationen verwenden unterschiedliche Resolver und Cache-Dienste; der Diagnosekatalog kennzeichnet eine portable Cache-Auflistung deshalb als nicht verfügbar. Fehlende Cache-Ausgabe heißt nicht, dass Namensauflösung fehlt oder fehlerhaft ist.
resolvectl, dig, nslookup und getent sind nicht auf jeder Installation vorhanden. Die vorhandene Linux-Diagnose fällt bei resolvectl auf /etc/resolv.conf und bei dig auf nslookup zurück; ist auch das Ersatzwerkzeug nicht da, wird die Prüfung als nicht verfügbar markiert.
Ein erfolgreicher DNS-Record beweist keine TCP-Erreichbarkeit; ein fehlgeschlagener Ping beweist keinen DNS-Fehler. DNS-Caches, lokale hosts-Einträge, Split-DNS, Suchdomains, IPv4/IPv6 und Anwendungseinstellungen können zu verschiedenen Antworten führen.
Fehlertexte und Statusnamen unterscheiden sich zwischen dig und nslookup sowie nach Distribution. Bei fehlenden Werkzeugen, eingeschränkten Rechten oder nicht verwalteten Resolvern kann die Ausgabe unvollständig bleiben.

Die Linux-Informationsseite beschreibt die tatsächlich verfügbaren Prüfungen und ihre Voraussetzungen. Die dort verlinkte Beispielauswertung enthält ausschließlich statische, erfundene Werte und führt selbst keine Diagnose aus.

Quellen und Befehlsgrundlage

Die Befehle und Rückfallwege entsprechen dem Linux-Prüfungskatalog und Runner dieses Projekts. Die allgemeine Bedeutung stützt sich auf die jeweiligen Handbuchseiten und Dokumentationen: