Netzwerk, DNS und WLAN

IP-Verbindung funktioniert, DNS-Auflösung scheitert

Bei Namensfehlern Upstream-Server und resolv.conf-Anbindung von systemd-resolved prüfen; DNS-Schleifen und Validierung gezielt untersuchen.

Auf dieser Seite
  1. Symptome und Geltungsbereich
  2. Mögliche Ursachen
  3. Sicher prüfen
  4. Nächste Schritte nach Befund
  5. Quellen und Prüfung
  6. Verwandte Probleme

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 found

DNS 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 us

Lokale 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-expired

Zeit, 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 status

Ergebnis 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.conf

Ergebnis 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 HOSTNAME

Ergebnis 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?

Hinweis teilen#

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?

Hinweis teilen#

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?

Hinweis teilen#

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.