DNS-Störungen am Dedicated Server schrittweise eingrenzen

Wenn ein Anwendungsprozess eine fehlgeschlagene Namensauflösung meldet, der Zugriff über die Adresse aber weiterhin funktioniert, kann ein sofortiger Wechsel des DNS-Servers wichtige Hinweise verdecken. Die Ursache kann im Anwendungscache, in der NSS-Abfragereihenfolge oder im Auflösungsdienst des Systems liegen, aber auch in einer fehlerhaften Antwort des Upstream-Servers. Ziel der Diagnose ist nicht, dass ein einzelner Befehl gelegentlich erfolgreich ist. Entscheidend ist, welchen Auflösungsweg der Anwendungsprozess tatsächlich nutzt und auf welcher Ebene der Fehler entsteht.

Diese Anleitung verwendet Ubuntu Server 24.04 LTS. Nach der Bezahlung eines Dedicated Servers bei AMDSSH rufen Sie die Zugangsdaten in der Konsole ab und melden sich per SSH an. Hat der Rechner mehrere Adressen, verwenden Sie die erste für die Verbindung. Die folgenden Prüfungen ändern weder Schnittstellenadressen noch Routen oder Firewall-Regeln und eignen sich daher, um zunächst belastbare Diagnoseinformationen zu sammeln.

1. Abfrageziel festlegen und ursprünglichen Fehler dokumentieren

Halten Sie zunächst die Fehlermeldung der Anwendung, den abgefragten Namen, den Record-Typ und den Zeitpunkt fest. Dokumentieren Sie außerdem, ob alle Domainnamen oder nur ein bestimmter Name betroffen sind und ob der fehlerhafte Prozess auf dem Host oder in einem Container läuft. Kurznamen werden durch Suchdomänen beeinflusst. Verwenden Sie für die Diagnose deshalb vorzugsweise einen vollständig qualifizierten Domainnamen mit abschließendem Punkt.

Die folgenden Beispiele zeigen das Abfrageformat anhand von amdssh.com., ohne vorauszusetzen, dass eine bestimmte Adresse zurückgegeben werden muss. Für die tatsächliche Abnahme ersetzen Sie den Namen durch einen von der Anwendung benötigten Namen, für den die erforderlichen Records nachweislich existieren. Prüfen Sie zuerst die verfügbaren Werkzeuge und dokumentieren Sie anschließend die grundlegende Systemumgebung:

command -v getent resolvectl dig
date -Is
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
grep '^hosts:' /etc/nsswitch.conf
systemctl is-active systemd-resolved
resolvectl status

dig wird vom Paket dnsutils bereitgestellt. Falls es noch nicht installiert ist, stellen Sie die Werkzeuge über die bereits konfigurierten Paketquellen bereit. Ist die Namensauflösung bereits gestört, liefert eine fehlgeschlagene Installation keinen neuen Beleg für die ursprüngliche Fehlerursache.

Erreichbarkeit über eine Adresse bedeutet nicht, dass der DNS-Abfrageweg funktioniert. Auch eine DNS-Antwort beweist nicht, dass die Anwendung den benötigten Record erhält. Prüfen Sie daher immer Antwortstatus, Record-Typ und tatsächlich zurückgegebenen Inhalt zusammen.

2. NSS und den Auflösungsdienst des Systems vergleichen

Drei Abfragen mit unterschiedlicher Aussagekraft

getent fragt über NSS ab und kommt damit den üblichen Systemaufrufen zur Adressauflösung näher. resolvectl fragt systemd-resolved ab. dig führt eine DNS-Abfrage aus, kann aber nicht den vollständigen NSS-Auflösungsweg überprüfen.

getent ahostsv4 amdssh.com.
resolvectl query --type=A amdssh.com.
dig amdssh.com. A +time=2 +tries=1

Bewerten Sie die drei Ergebnisse gemeinsam. Liefert getent eine alte Adresse, während die DNS-Abfrage eine neue zurückgibt, prüfen Sie zuerst /etc/hosts und die Modulreihenfolge in der Zeile hosts:. Ist resolvectl erfolgreich, aber getent nicht, prüfen Sie, ob die NSS-Module vorhanden und sinnvoll angeordnet sind und ob der Dienst in einer anderen Dateisystemumgebung läuft.

/etc/resolv.conf kann auf einen lokalen Einstiegspunkt der Namensauflösung verweisen, ohne die tatsächlich verwendeten Upstream-Server direkt aufzuführen. Die Datei kann außerdem von einem Netzwerkverwaltungswerkzeug erzeugt werden. Eine lokale Adresse ist daher allein kein Hinweis auf eine Fehlkonfiguration. Überschreiben Sie auch nicht zuerst den symbolischen Link, um anschließend zu prüfen, ob die Störung verschwunden ist.

Manche Anwendungen verwenden eine eigene DNS-Bibliothek und umgehen NSS. Ein erfolgreiches getent belegt deshalb lediglich, dass der Systempfad funktioniert, nicht aber, dass alle Anwendungen wieder ordnungsgemäß arbeiten.

3. Upstream gezielt abfragen und Antwortfehler von Transportproblemen trennen

Notieren Sie aus resolvectl status die DNS-Server, Routing-Domänen und den aktuell verwendeten Server der Schnittstelle, über die die fehlgeschlagene Abfrage läuft. Bei mehreren Schnittstellen kann der Upstream-Server abhängig vom Domainnamen gewählt werden. Übernehmen Sie deshalb nicht einfach den ersten Eintrag aus der Ausgabe. Im folgenden Beispiel geben Sie die Adresse des tatsächlich verwendeten Upstream-Servers interaktiv ein, statt einen ungeprüften öffentlichen Resolver einzuführen.

read -r -p 'DNS server address: ' DNS_SERVER
dig @"$DNS_SERVER" amdssh.com. A +time=2 +tries=1
dig @"$DNS_SERVER" amdssh.com. A +tcp +time=2 +tries=1
dig @"$DNS_SERVER" amdssh.com. AAAA +time=2 +tries=1

Das Zeitlimit von zwei Sekunden und der einzelne Versuch sind Diagnoseparameter, keine Empfehlung für die Zeitlimits der Anwendung. Bewahren Sie die vollständige Ausgabe auf und achten Sie besonders auf status, den Antwortabschnitt, die Abfragedauer und den tatsächlich abgefragten Server. Der Exit-Code des Befehls allein sagt nicht aus, ob der Record für die Anwendung gültig ist.

Nach Antwortstatus vorgehen

NXDOMAIN bedeutet, dass der Name nicht existiert. Prüfen Sie zuerst Schreibweise, Suchdomänen und autoritative Records. Bei NOERROR mit leerem Antwortabschnitt fehlt möglicherweise lediglich ein Record des angefragten Typs; das ist nicht als Netzwerkstörung zu werten. SERVFAIL steht für einen Fehler im Auflösungsprozess und erfordert die Prüfung von Upstream-Protokollen oder eine Abstimmung mit dem zuständigen Administrator. Bei REFUSED sollten Sie die Abfrageberechtigungen kontrollieren.

Läuft die UDP-Abfrage in ein Zeitlimit, während die TCP-Abfrage erfolgreich ist, verhalten sich die beiden Transportwege unterschiedlich. Prüfen Sie anschließend die entsprechenden Netzwerkrichtlinien. Laufen beide Abfragen in ein Zeitlimit, kontrollieren Sie die Route und die Zugriffsregeln zum Upstream-Server. Aus einem Zeitlimit allein lässt sich jedoch nicht schließen, dass der Server ausgefallen ist. Antwortet der Upstream-Server, während der Systempfad scheitert, setzen Sie die Diagnose bei der lokalen Konfiguration und den Caches fort.

4. Befundgestützt korrigieren, ohne die zuständige Konfigurationsverwaltung zu umgehen

Klären Sie zuerst, welche Ebene die DNS-Konfiguration verwaltet. Ubuntu Server kann die Konfiguration über Netplan an ein bestimmtes Netzwerk-Backend übergeben; möglich sind aber auch andere Verwaltungswege. Dauerhafte Änderungen gehören in die Konfigurationsdatei der tatsächlich zuständigen Komponente, nicht nur in die daraus erzeugte /etc/resolv.conf.

Wenn nachweislich die autoritativen Records korrigiert wurden, systemd-resolved aber noch ein altes Ergebnis vorhält, können Sie nach der Dokumentation des aktuellen Zustands dessen Cache leeren:

resolvectl statistics
sudo resolvectl flush-caches
resolvectl query --type=A amdssh.com.
getent ahostsv4 amdssh.com.

Das Leeren des Caches ändert weder den Upstream-Server noch entfernt es den anwendungseigenen Cache. Wurde der Name zuvor als nicht existent gemeldet, kann außerdem ein negativer Cache-Eintrag wirken. Beziehen Sie zur Beurteilung die SOA-Informationen der Antwort ein. Wiederholte Dienstneustarts sind keine geeignete Reparaturmethode.

Sichern Sie vor einer Änderung der NSS-Reihenfolge die Originaldatei und klären Sie, welche Module lokale Dateien, DNS oder andere Namensquellen abfragen. Module mit bedingten Aktionen können die Abfrage vorzeitig beenden. Es reicht daher nicht, nur nach dem Wort dns zu suchen.

Ist eine Änderung der dauerhaften DNS-Konfiguration tatsächlich erforderlich, sichern Sie zuerst die Konfiguration, prüfen Sie die Syntax und bereiten Sie die Wiederherstellung der Originaldatei vor. Halten Sie vor dem Anwenden von Netzwerkänderungen aus der Ferne die bestehende SSH-Sitzung offen. Nutzen Sie vorzugsweise ein Verfahren mit Rücknahmemöglichkeit, sofern das Konfigurationsverwaltungswerkzeug eines anbietet. Ändern Sie nicht gleichzeitig DNS, Routen und Schnittstellennamen.

5. Im tatsächlichen Kontext des Anwendungsprozesses validieren

Nach der Wiederherstellung auf dem Host müssen Sie auch die Auflösungsdateien prüfen, die ein Container oder ein isolierter Dienst sieht. Ein Container kann eine eigene /etc/resolv.conf haben, und der Prozess kann noch eine alte Adresse zwischenspeichern. Wiederholen Sie die Abfragen in der tatsächlichen Laufzeitumgebung, statt denselben Befehl nur erneut im Terminal des Hosts auszuführen.

Zur abschließenden Validierung gehören folgende Prüfungen:

• Fragen Sie für den vollständig qualifizierten Domainnamen der Anwendung die benötigten Record-Typen einzeln ab und gleichen Sie die Adressen mit dem vorgesehenen Verwendungszweck ab.
• Prüfen Sie die Ergebnisse von NSS, dem Auflösungsdienst des Systems und dem tatsächlich verwendeten Upstream-Server zusammen.
• Führen Sie eine echte Anwendungsanfrage aus, um einen Fehler bei der Namensauflösung von einem nachfolgenden Verbindungsfehler zu unterscheiden.
• Prüfen Sie, ob die Anwendung an einer alten Adresse festhält und ob der Cache über ihre Verwaltungsschnittstelle aktualisiert werden muss.
• Stellen Sie sicher, dass die zuständige Komponente die Konfiguration dauerhaft speichert, und prüfen Sie nach einem kontrollierten Neustart, ob sie überschrieben wurde.
• Bewahren Sie die Ausgaben vor und nach der Änderung, die Konfigurationsunterschiede und die Ergebnisse der Anwendungsanfragen auf, statt lediglich „wiederhergestellt“ zu notieren.

Tritt das Problem nur bei einem einzelnen Prozess auf, untersuchen Sie weiter dessen Resolver, Laufzeitumgebung und Verbindungspool, statt die Änderungen auf das Netzwerk des gesamten Rechners auszuweiten. Eine vollständige Diagnose muss den ursprünglichen Fehler erklären, die betroffene Ebene benennen und nachweisen, dass die Anwendungsanfragen nach der Korrektur den vorgesehenen Auflösungsweg durchlaufen.

Häufig gestellte Fragen