Symptome und Geltungsbereich
- Ein bekannter Dienst bleibt über seine bestätigte IP erreichbar, der Hostname scheitert jedoch.
- resolvectl meldet fehlende Nameserver, Resolver-Schleife oder gescheiterte DNSSEC-Prüfung.
Betroffene Umgebung
Systeme mit bewusst eingesetztem systemd-resolved, häufig an NetworkManager angebunden; andere Resolver benötigen ihre dokumentierte Konfiguration.
Erkennbare Meldungen (synthetische Beispiele)
intranet.example: resolve call failed: No appropriate name servers or networks for name foundDNS je Verbindung und Domainrouting prüfen; dies ist keine autoritative Meldung eines nicht vorhandenen Namens.
intranet.example: resolve call failed: Configured DNS server loops back to usLokale Stub-Adresse als Upstream-DNS oder Schleife zwischen lokalen weiterleitenden Resolvern prüfen.
systemd-resolved[720]: DNSSEC validation failed for question signed.example IN A: signature-expiredZeit, Signierungskette der Domain und Upstream-Verhalten vor Änderung der Validierungsrichtlinie prüfen.
Mögliche Ursachen
Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.
- DNS je Verbindung kann fehlen oder falsch zugeordnet sein; /etc/resolv.conf kann auf eine alte Datei oder einen inaktiven lokalen Stub zeigen.
- Ein lokaler DNS-Stub als eigener Upstream erzeugt eine Schleife; DNSSEC-Fehler benötigen dagegen Befunde zu Zeit, Signierung und Upstream.
Sicher prüfen
Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.
Prüfschritt 1
Globale und verbindungsspezifische DNS-Server, Domains und Standard-Richtlinie unverändert lesen. Bei nicht verfügbarem Dienst klären, ob dieses System resolved einsetzen soll.
resolvectl statusErgebnis einordnen: 127.0.0.53 ist gewöhnlich der lokale Client-Stub, kein Upstream-DNS-Server für resolved. Auch ein korrekter Server je Verbindung benötigt eine IP-Route und kann absichtlich nur eine Domain bedienen.
Prüfschritt 2
Dateipfad ohne Bearbeitung auflösen. Eine gewöhnliche Datei kann ein gültiger Modus sein; Ergebnis mit der vorgesehenen Resolver-Anbindung der Distribution vergleichen.
readlink -f /etc/resolv.confErgebnis einordnen: Ein stub-resolv.conf-Ziel erwartet verfügbaren lokalen Stub. Der Upstream-resolv.conf-Modus umgeht dessen verbindungsspezifisches Routing für direkt lesende Clients; keinen Modus ungeprüft erzwingen.
Prüfschritt 3
HOSTNAME durch einen bekannten, zur Abfrage freigegebenen Namen ersetzen. Der Befehl sendet eine DNS-Abfrage, verändert aber keine Konfiguration; private Namen vor Weitergabe entfernen.
resolvectl query HOSTNAMEErgebnis einordnen: No appropriate name servers ist ein Serverauswahl-/Routingfehler, kein Beweis für einen nicht existierenden Namen. DNSSEC validation failed unterscheidet sich von NXDOMAIN und erfordert das detaillierte Resolver-Log.
Nächste Schritte nach Befund
Vorgesehene lokale Resolver-Anbindung herstellen
Wenn das System resolved vorsieht, /etc/resolv.conf oder NetworkManagers DNS-Plugin aber abweichen, Datei/Symlink sichern und die dokumentierte Distributions-Anbindung herstellen. Lokalen Stub-Dienst nur aktivieren, wenn der gewählte Modus ihn benötigt.
Vorsicht: VPN-Domainrouting und bewusst genutzte andere Resolver erhalten. resolv.conf nicht unveränderlich setzen und nicht alle Server durch einen öffentlichen DNS ohne interne Namen ersetzen.
Wiederherstellung / Rücknahme: Gesicherte resolv.conf-Form und vorigen DNS-Plugin-/Dienstzustand wiederherstellen; bei schlechterem DNS betroffenes Profil erneut verbinden.
Hat dir dieser Hinweis geholfen?
Bestätigten Upstream oder Schleife korrigieren
Wenn resolved der vorgesehene DNS je Verbindung fehlt oder der eigene Stub als Upstream eingetragen ist, DNS-Quelle dieses Profils auf den vorgegebenen Server oder gültige DHCP-Konfiguration korrigieren. Routing-Domains an ihrer vorgesehenen Verbindung erhalten und denselben Namen vergleichen.
Vorsicht: Der DNS-Server muss über sein vorgesehenes Netz erreichbar sein. Nur die Serveradresse zu ändern repariert weder getrenntes VPN noch fehlende IP-Route.
Wiederherstellung / Rücknahme: Gesicherte DNS-Adressen, Domainliste und ignore-auto-dns-Einstellung je Verbindung wiederherstellen; bei Bedarf voriges Profil aktivieren.
Hat dir dieser Hinweis geholfen?
DNSSEC-Prüffehler anhand der Befunde beheben
Bei gemeldetem DNSSEC-Fehler tatsächliche Systemzeit und genauen Fehlergrund vor Richtlinienänderung prüfen. Belegte Uhrabweichung über den vorgesehenen Zeitdienst korrigieren; bei nur einer betroffenen signierten Domain Signatur/Vertrauenskette oder filternden Upstream mit deren Verwaltung prüfen.
Vorsicht: DNSSEC nicht global zur Umgehung ungeklärter Validierungsfehler abschalten. Größere Zeitsprünge beeinflussen Zertifikate und Sitzungen; normales Verfahren zur Zeitsynchronisierung nutzen.
Wiederherstellung / Rücknahme: Bei schlechterem Ergebnis gesicherte DNS-Server- oder Zeitdienst-Konfiguration zurücknehmen; Validierungsrichtlinie während Klärung des autoritativen Problems erhalten.
Hat dir dieser Hinweis geholfen?
Quellen und Prüfung
Diese Anleitung basiert auf Originalquellen von Projekten oder Distributionen und wurde am genannten Datum redaktionell geprüft. Das ist eine Quellenprüfung, kein Nachweis einer auf deiner Hardware reproduzierten Lösung. Log-Beispiele sind synthetische Testdaten. Versionsabhängige Details müssen zur installierten Ausgabe passen.
- Debian systemd manual: resolved routing and resolv.conf modes (Projekt- oder Distributionsdokumentation)
- Debian systemd manual: resolvectl(1) (Projekt- oder Distributionsdokumentation)
- NetworkManager: unmanaged devices, DNS and connectivity configuration (Projekt- oder Distributionsdokumentation)
- systemd: resolvectl resolution errors (Upstream-Implementierung; Verhalten ist versionsabhängig)
- systemd: DNSSEC transaction failure reporting (Upstream-Implementierung; Verhalten ist versionsabhängig)