Behebung des Fehlers „Temporärer Fehler bei der DNS-Auflösung“ in Debian 12 mit systemd-resolved

Der Fehler Temporary failure in name resolutionbedeutet, dass eine Anwendung einen Hostnamen wie z. B. nicht deb.debian.orgin eine IP-Adresse auflösen konnte. Unter Debian 12 (Bookworm) bedeutet dies nicht automatisch, dass DNS systemd-resolveddefekt ist. Debian 12 installiert DNS nicht systemd-resolvedstandardmäßig, und DNS kann stattdessen direkt über NetworkManager, ifupdown, DHCP-Tools oder einen anderen Resolver verwaltet werden. Wenn Sie DNS bewusst aktiviert haben systemd-resolved, besteht die schnellste Lösung darin, die fehlerhafte Ebene zu identifizieren, bevor Sie die Konfiguration ändern.

Diese praktische Anleitung konzentriert sich auf Systeme, die systemd-resolved verwenden oder verwenden sollen systemd-resolved. Die Dokumentation des Debian-Pakets Bookworm beschreibt die Installation systemd-resolvedvon Schaltern /etc/resolv.conffür die systemd-basierte Verwaltung. Der Dienst selbst stellt einen lokalen DNS-Stub bereit 127.0.0.53und empfängt DNS-Informationen von globalen Konfigurationen, Netzwerkkonfigurationen pro Verbindung, DHCP resolvectlund Netzwerkverwaltungsdiensten. Weitere Informationen finden Sie auf der Debian-Paketseite und im Debian-Handbuch zu systemd-resolved .

Checkliste für die Schnelldiagnose

1. Stellen Sie sicher, dass das Problem am DNS liegt und nicht an der allgemeinen Verbindungsqualität.

Testen Sie zunächst einen Hostnamen und anschließend eine IP-Adresse:

getent ahosts debian.org
ping -c 3 debian.org
ping -c 3 1.1.1.1

Schlägt die Hostnamenauflösung fehl, der direkte IP-Test jedoch erfolgreich, ist wahrscheinlich das DNS die Fehlerursache. Schlagen beide Tests fehl, überprüfen Sie zunächst die Schnittstelle, die Route, das Gateway, das VLAN, die WLAN-Verbindung, die Firewall oder das vorgelagerte Netzwerk. Eine DNS-Änderung kann eine fehlende Standardroute nicht beheben.

Für eine deterministischere Routenprüfung führen Sie außerdem Folgendes aus:

ip address
ip route

Normalerweise sollten Sie eine Adresse auf der erwarteten Schnittstelle und eine Standardroute haben. Der genaue Schnittstellenname kann beispielsweise enp1s0, ens160, eth0oder etwas anderes sein.

2. Überprüfen Sie, ob systemd-resolved tatsächlich verwendet wird.

Gehen Sie nicht davon aus, dass es vorhanden ist, nur weil die Maschine systemd verwendet. Überprüfen Sie sowohl das Paket als auch den Dienst:

dpkg -s systemd-resolved 2>/dev/null | grep '^Status'
systemctl status systemd-resolved --no-pager
resolvectl status

Wenn das Paket fehlt und Ihr System über eine andere funktionierende DNS-Verwaltung verfügt, systemd-resolvedist die Installation nicht automatisch die richtige Lösung. Wenn das System das Paket verwenden soll und der Dienst installiert, aber beendet ist, aktivieren und starten Sie ihn.

sudo systemctl enable --now systemd-resolved

Falls dieser Befehl fehlschlägt, überprüfen Sie die Protokolle, bevor Sie den Dienst wiederholt neu starten:

journalctl -u systemd-resolved -b --no-pager

3. Überprüfen Sie die Datei /etc/resolv.conf, bevor Sie sie ersetzen.

Der häufigste Konfigurationsfehler besteht darin, die /etc/resolv.confDatei als isolierte Konfigurationsdatei zu behandeln. Mit systemd-resolveddieser Datei kann sie in mehreren unterstützten Modi betrieben werden. Der von den Entwicklern empfohlene Stub-Modus verweist /etc/resolv.confauf die Datei `/etc/servers` /run/systemd/resolve/stub-resolv.conf, wodurch herkömmliche DNS-Clients auf die Datei `/etc/servers` weitergeleitet werden 127.0.0.53. Ein weiterer gültiger Modus verweist auf die /run/systemd/resolve/resolv.confDatei `/etc/servers`, wodurch bekannte Server direkt zugänglich gemacht werden, jedoch die DNS-Weiterleitung pro Link von systemd-resolved für Anwendungen verloren geht, die diese Datei direkt lesen.

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Eine reguläre Datei ist nicht automatisch fehlerhaft. NetworkManager oder ein anderer Resolver-Manager kann sie absichtlich verwalten. Wenn dieser Host jedoch für den systemd-resolved Stub-Modus konfiguriert ist, können eine veraltete reguläre Datei, ein verwaister symbolischer Link oder eine Datei, die auf nicht erreichbare Nameserver verweist, zu Namensauflösungsfehlern führen.

Stellen Sie die empfohlene Stub-Verbindung wieder her, wenn der Stub-Modus vorgesehen ist.

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved
ls -l /etc/resolv.conf
cat /etc/resolv.conf

Das Vorhandensein von Einträgen nameserver 127.0.0.53in der Stub-Datei ist zu erwarten. Es handelt sich um den lokalen Listener, nicht um den Upstream-DNS-Server. Verwenden Sie die Funktion `systemd resolvectl status-resolved`, um zu sehen, welche Upstream-Server `systemd-resolved` tatsächlich kontaktiert. Diese Unterscheidung ist im Bookworm-Handbuch von `systemd-resolved` dokumentiert .

4. Prüfen Sie, ob systemd-resolved über einen nutzbaren Upstream-DNS-Server verfügt.

Laufen:

resolvectl status

Konzentrieren Sie sich auf den Link, der die Standardroute enthält. Eine korrekte Konfiguration sollte normalerweise einen oder mehrere DNS-Server für diesen Link oder geeignete globale DNS-Server anzeigen. Wenn kein nutzbarer DNS-Server vorhanden ist, reicht es nicht aus, nur den symbolischen Link zu reparieren: Der lokale Stub hat kein sinnvolles Ziel, an das er Anfragen senden kann.

Sie können den Resolver direkt testen:

resolvectl query debian.org

Das Debian resolvectl-Handbuch dokumentiert status, query, flush-caches, und die pro Link verwendeten DNS-Befehle zur Überprüfung und Fehlerbehebung.

5. Wenn NetworkManager die Schnittstelle besitzt, korrigieren Sie die DNS-Einstellungen im Verbindungsprofil.

Bei Desktop-Installationen und vielen Debian-Systemen für allgemeine Zwecke stellt NetworkManager möglicherweise DNS-Informationen pro Verbindung für systemd-resolved bereit. Zuerst muss das aktive Profil und die aktuellen DNS-Werte ermittelt werden:

nmcli connection show --active
nmcli device show

Wenn DHCP einen fehlerhaften DNS-Server bereitstellt, ändern Sie das NetworkManager-Profil, anstatt es /etc/resolv.confnach jedem Neustart zu bearbeiten. Beispiel: Wenn Ihre Netzwerkrichtlinie öffentliche Resolver zulässt:

sudo nmcli connection modify "Wired connection 1"   ipv4.ignore-auto-dns yes   ipv4.dns "1.1.1.1 9.9.9.9"
sudo nmcli connection up "Wired connection 1"

Ersetzen Sie den Profilnamen und die DNS-Server durch die für Ihr Netzwerk passenden Werte. Unternehmensnetzwerke, VPNs, Active Directory-Umgebungen und Split-DNS-Konfigurationen benötigen häufig interne Resolver; öffentliche DNS-Server können private Hostnamen beeinträchtigen. Die offizielle Konfigurationsreferenz von NetworkManager beschreibt die Integration mit systemd-resolved.

6. Wenn systemd-networkd die Schnittstelle besitzt, konfigurieren Sie DNS pro Verbindung.

Bei Servern, die DHCP verwenden systemd-networkd, müssen die DNS-Einstellungen in der entsprechenden .networkDatei unter eingetragen werden /etc/systemd/network/. Ein einfaches Beispiel für DHCP ist:

[Match]
Name=ens160

[Network]
DHCP=yes
DNS=1.1.1.1
DNS=9.9.9.9
Domains=~.

[DHCPv4]
UseDNS=no

UseDNS=noDies ist relevant, wenn Sie die von DHCP bereitgestellten DNS-Server explizit ignorieren möchten. Ohne diese Angabe wird standardmäßig DHCP-DNS verwendet. Domains=~.Es handelt sich um eine reine Routing-Domäne für den DNS-Root-Server, wodurch diese Verbindung für Anfragen geeignet ist, die keiner spezifischeren Routing-Domäne zugeordnet werden können. Fügen Sie diese Domäne nicht ohne Weiteres auf Systemen mit mehreren Netzwerkanschlüssen oder VPN-Systemen hinzu, bei denen Split-DNS beabsichtigt ist.

sudo systemctl restart systemd-networkd
resolvectl status ens160

Das Verhalten von DNS=, Domains=und DHCP UseDNS=ist im Debian Bookworm systemd.network-Handbuch dokumentiert .

7. Verwenden Sie die globale resolved.conf nur dann, wenn Sie wirklich systemweites DNS benötigen.

/etc/systemd/resolved.confAlternativ kann man über eine Drop-in- /etc/systemd/resolved.conf.d/Konfiguration System-DNS-Server festlegen. Dies ist nützlich für eine hostweite Richtlinie, jedoch weniger präzise als die Konfiguration pro Verbindung auf Rechnern mit VPNs, mehreren Schnittstellen oder privaten DNS-Zonen.

Ein lokaler Drop-in ist in der Regel sauberer als die Bearbeitung der herstellerspezifischen Hauptdatei:

sudo mkdir -p /etc/systemd/resolved.conf.d
sudoedit /etc/systemd/resolved.conf.d/10-dns.conf

Beispiel:

[Resolve]
DNS=1.1.1.1 9.9.9.9

Dann wenden Sie es an:

sudo systemctl restart systemd-resolved
resolvectl status

Im Debian-Handbuch zu resolved.conf wird erläutert, dass diese DNS=Datei System-DNS-Server bereitstellt und dass Administrator-Einträge unter dieser Datei /etc/systemd/resolved.conf.d/Vorrang vor Konfigurationen mit niedrigerer Priorität haben.

8. Leeren Sie den Cache erst, nachdem die zugrunde liegende Konfiguration korrigiert wurde.

Ein veralteter Cache kann die Fehlersuche erschweren, aber das Leeren des Caches ersetzt nicht die Reparatur eines nicht erreichbaren Upstream-Servers oder einer fehlerhaften Verbindungskonfiguration. Nach einer tatsächlichen Konfigurationsänderung können Sie Folgendes ausführen:

sudo resolvectl flush-caches
resolvectl query debian.org

In der Dokumentation von Systemd wird darauf hingewiesen, dass Caches normalerweise automatisch geleert werden, wenn sich die Netzwerkkonfiguration ändert. Daher sollte wiederholtes manuelles Leeren nicht Ihre primäre Lösung sein.

9. Lesen Sie das Resolver-Journal, wenn der Fehler weiterhin besteht.

Wenn resolvectl statusdie Ergebnisse plausibel erscheinen, die Abfragen aber trotzdem ein Timeout verursachen, überprüfen Sie das Boot-Local-Resolver-Log:

journalctl -u systemd-resolved -b --no-pager
journalctl -u systemd-resolved -b --no-pager | tail -n 50

Achten Sie auf wiederholte Server-Timeouts, Änderungen des Fallback-Servers, DNSSEC-Validierungsfehler oder Meldungen, die auf eingeschränkte Protokollfunktionen hinweisen. Ein Resolver kann normal funktionieren, obwohl sein konfigurierter Upstream-Server durch eine Firewall, ein VPN, eine Routing-Richtlinie oder eine Netzwerk-ACL nicht erreichbar ist.

10. Überprüfen Sie den vollständigen Suchpfad

Hören Sie nicht nach einer erfolgreichen resolvectlAbfrage auf. Überprüfen Sie den Pfad, der von normalen Anwendungen verwendet wird:

getent ahosts debian.org
resolvectl query debian.org
sudo apt update

getentDies ist nützlich, da die Hostnamenauflösung von glibc der hosts:Zeile in folgt /etc/nsswitch.conf. Falls resolvectl queryerfolgreich ist, aber getentfehlschlägt, überprüfen Sie die NSS-Konfiguration. Das Debian- Handbuch zu nss-resolve beschreibt das optionale libnss-resolveModul und eine empfohlene Reihenfolge, die die Hostnamenauflösung von glibc über systemd-resolved leitet und gleichzeitig Fallback-Optionen beibehält.

Häufige Symptome und der wahrscheinlichste Ort, an dem man suchen sollte

Empfohlene Reparaturreihenfolge

1. Prüfen Sie, ob die grundlegende Netzwerkverbindung und die Standardroute vorhanden sind.
2. Prüfen Sie, ob systemd-resolvedes tatsächlich dazu bestimmt ist, die DNS-Einstellungen auf diesem Host zu verwalten.
3. Prüfen Sie systemd-resolvedden Servicestatus und resolvectl status.
4. Prüfen Sie /etc/resolv.confBesitzverhältnisse und Symlink-Modus, bevor Sie Änderungen vornehmen.
5. Falls der Stub-Modus beabsichtigt ist, stellen Sie die stub-resolv.confVerbindung wieder her.
6. Korrigieren Sie das Upstream-DNS beim tatsächlichen Eigentümer: NetworkManager, systemd-networkd, DHCP, VPN oder global aufgelöste Konfiguration.
7. Leeren Sie den Cache erst, nachdem die Konfiguration korrigiert wurde.
8. Überprüfen Sie dies mit resolvectl, getent, und der Anwendung, die ursprünglich fehlgeschlagen ist.

Das Schlüsselprinzip ist die Zuständigkeit: /etc/resolv.confsystemd-resolved und der Netzwerkmanager sind Teil einer einzigen Resolverkette. Eine dauerhafte Korrektur ändert die DNS-Einträge auf der Ebene, die dafür zuständig ist, anstatt die endgültig generierte Datei wiederholt zu ersetzen.