DNS-Auflösungsprobleme systematisch troubleshooten

1. Warum DNS-Probleme selten am DNS-Server liegen

Ein DNS-Problem äußert sich meist als "die Website ist manchmal nicht erreichbar" oder "die Datenbankverbindung schlägt sporadisch fehl", obwohl der Zielserver selbst nachweislich läuft. Die instinktive erste Reaktion ist oft, den DNS-Server selbst zu verdächtigen, doch in der Praxis liegt die Ursache in der überwältigenden Mehrheit der Fälle in der lokalen Auflösungskette auf dem betroffenen Linux-Host: einer falsch konfigurierten resolv.conf, einem hängenden lokalen Resolver-Cache oder einer widersprüchlichen nsswitch.conf. Der eigentliche autoritative DNS-Server oder Upstream-Resolver ist fast immer der letzte Ort, an dem man suchen sollte, nicht der erste.

Diese Fehleinschätzung kostet in der Praxis wertvolle Zeit, weil Teams reflexhaft mit dig @8.8.8.8 gegen einen externen Resolver testen, ein sauberes Ergebnis erhalten und daraus fälschlich schließen, dass DNS insgesamt funktioniert. Das Problem dabei: Ein direkter Test gegen einen externen Server umgeht genau die lokale Konfigurationsschicht, in der das eigentliche DNS-Problem sitzt. Die richtige Reihenfolge beginnt deshalb immer bei der lokalen Konfiguration und arbeitet sich erst danach nach außen vor.

2. Die Auflösungskette: nsswitch.conf, resolv.conf und NSS

Bevor überhaupt ein DNS-Paket das System verlässt, entscheidet die Name Service Switch-Konfiguration in /etc/nsswitch.conf, welche Quellen in welcher Reihenfolge für die Namensauflösung befragt werden. Die Zeile hosts: files dns bedeutet, dass zuerst /etc/hosts geprüft wird und erst danach DNS. Ein häufig übersehener Fehler: Ein veralteter, manuell eingetragener Eintrag in /etc/hosts überschreibt jede DNS-Antwort vollständig, ohne dass ein Fehler oder eine Warnung sichtbar wird, weil files vor dns in der Kette steht und bei einem Treffer die Suche sofort beendet.

Ist /etc/hosts unauffällig, folgt der Blick in /etc/resolv.conf, die die eigentlichen Nameserver sowie Optionen wie timeout, attempts und search enthält. Auf modernen Systemen mit systemd-resolved ist diese Datei oft nur ein Symlink auf /run/systemd/resolve/stub-resolv.conf, das auf den lokalen Stub-Resolver 127.0.0.53 zeigt, statt direkt die tatsächlichen Upstream-Server zu nennen. Wer das nicht weiß und versucht, die Nameserver manuell in resolv.conf zu ändern, wird beim nächsten Neustart von systemd-resolved überschrieben und wundert sich über scheinbar zufällig verschwindende Änderungen.

# Which sources are consulted, and in which order?
cat /etc/nsswitch.conf | grep ^hosts

# Is resolv.conf a real file or a systemd-resolved symlink?
ls -la /etc/resolv.conf

# If it is a symlink to the stub resolver, the real upstream servers
# are configured elsewhere — check systemd-resolved directly instead
readlink -f /etc/resolv.conf

# Check for a stale manual entry in /etc/hosts overriding DNS entirely
grep -v '^#' /etc/hosts | grep -v '^$'

3. Mit dig und drill die Auflösung isoliert testen

dig ist das präziseste Werkzeug, um eine DNS-Auflösung isoliert von der Anwendung zu testen, aber genau diese Isolation ist auch seine größte Falle. dig example.com ohne weitere Optionen nutzt die in /etc/resolv.conf konfigurierten Nameserver und durchläuft damit die gleiche Kette wie eine normale Anwendung, während dig @1.1.1.1 example.com den lokalen Resolver komplett umgeht und nur die Erreichbarkeit von Cloudflares Resolver testet. Für eine belastbare Diagnose muss man beide Varianten ausführen und die Ergebnisse vergleichen, denn nur ein Unterschied zwischen beiden zeigt eindeutig, ob das Problem lokal oder extern liegt.

Die Antwortzeit in der dig-Ausgabe (Query time) ist ebenfalls aussagekräftig: Werte über 100 Millisekunden bei einem eigentlich lokalen Resolver deuten auf ein Weiterleitungsproblem oder eine überlastete Upstream-Verbindung hin. Die Flags +trace zeigen zusätzlich den kompletten Auflösungspfad von den Root-Servern bis zur autoritativen Zone und sind besonders hilfreich, wenn der Verdacht besteht, dass eine Delegation zwischen den DNS-Zonen fehlerhaft konfiguriert ist, statt dass ein lokales Problem vorliegt.

# Resolve through the locally configured resolver (same path as applications)
dig example.com

# Bypass the local resolver entirely — tests only the upstream server
dig @1.1.1.1 example.com

# Full resolution path from root servers down to the authoritative zone
dig +trace example.com

# Query time and answer section side by side for quick comparison
dig +noall +answer +stats example.com

4. systemd-resolved verstehen und dessen Status prüfen

Auf den meisten modernen Distributionen läuft systemd-resolved als lokaler Caching-Resolver und Stub-Server auf 127.0.0.53:53, der Anfragen entgegennimmt, cached und an die tatsächlich konfigurierten Upstream-Server weiterleitet. Der Befehl resolvectl status zeigt die pro Netzwerk-Interface konfigurierten DNS-Server, Suchdomains und den aktuellen Modus (etwa DNS-over-TLS), und ist damit der zentrale erste Anlaufpunkt bei jedem DNS-Problem auf einem systemd-basierten System. Ein häufiger Fund: Zwei Netzwerk-Interfaces mit widersprüchlichen DNS-Servern, etwa ein VPN-Interface, das seine eigenen internen Nameserver durchsetzen will, während das physische Interface weiterhin auf die öffentlichen Resolver zeigt.

resolvectl statistics liefert zusätzlich Cache-Trefferquoten und Fehlerzähler, die zeigen, ob ein hoher Anteil an Anfragen tatsächlich zeitüberschritten oder mit SERVFAIL beantwortet wird. Bei anhaltenden Problemen hilft ein gezielter Cache-Flush mit resolvectl flush-caches, um einen möglicherweise fehlerhaft zwischengespeicherten negativen Eintrag zu entfernen, bevor man weiter in Richtung Netzwerk oder Anwendung sucht.

# Per-interface DNS servers, search domains, and current mode
resolvectl status

# Cache hit ratio and failure counters since the last restart
resolvectl statistics

# Force-flush the local resolver cache — useful after fixing a
# misconfigured upstream server or a stale negative cache entry
sudo resolvectl flush-caches

# Confirm the stub resolver is actually listening
sudo ss -tulpn | grep ':53'

5. Warum Anwendungen anders auflösen als dig

Ein erfolgreicher dig-Aufruf beweist nicht, dass eine konkrete Anwendung dasselbe Ergebnis erhält, weil viele Laufzeitumgebungen ihre eigene DNS-Implementierung mitbringen, die die Systemkonfiguration nur teilweise respektiert. PHP mit aktiviertem curl nutzt beispielsweise standardmäßig die glibc-Resolver-Funktionen und damit dieselbe Kette wie dig, aber Java-Anwendungen cachen erfolgreiche DNS-Antworten oft für die gesamte Prozesslaufzeit, unabhängig von der tatsächlichen TTL, weil die JVM standardmäßig networkaddress.cache.ttl auf einen sehr hohen oder unendlichen Wert setzt. Ein Failover auf einen neuen Server-IP-Adresse via DNS-Änderung greift dann bei laufenden Java-Prozessen erst nach einem Neustart.

Für PHP-FPM- und Nginx-Setups relevant ist zudem, dass Nginx upstream-Blöcke mit Hostnamen standardmäßig nur einmal beim Start auflöst, es sei denn, resolver mit expliziter TTL wird konfiguriert. Ein DNS-Wechsel des Backends, etwa bei einem Cloud-Loadbalancer mit wechselnden IP-Adressen, wird von Nginx dann schlicht ignoriert, bis der Prozess neu geladen wird. Diese Unterschiede zwischen Anwendungslaufzeit und Systemresolver sind eine der häufigsten Ursachen für "dig funktioniert, die Anwendung aber nicht"-Situationen.

# Check what a PHP process actually resolves, bypassing the CLI
php -r 'var_dump(gethostbyname("example.com"));'

# Nginx: verify whether a resolver directive with explicit TTL is configured
grep -A2 "resolver " /etc/nginx/nginx.conf

# Confirm actual TTL returned by DNS vs. what the application might cache
dig +noall +answer example.com | awk '{print $1, $2}'

6. Caching-Fallstricke: negative Caches und TTL-Ignoranz

Ein besonders tückisches Muster ist der negative Cache: Wenn ein Resolver einen NXDOMAIN oder SERVFAIL für eine Anfrage erhält, cached er dieses negative Ergebnis für eine gewisse Zeit, oft basierend auf dem SOA-Minimum-TTL-Wert der Zone. Wird das eigentliche DNS-Problem, etwa ein kurzzeitig nicht erreichbarer autoritativer Server, danach behoben, liefert der lokale Resolver trotzdem weiterhin den gecachten Fehler zurück, bis die negative TTL abläuft. Das erklärt, warum ein DNS-Problem manchmal Minuten nach der eigentlichen Behebung noch fortbesteht, was ohne Kenntnis dieses Mechanismus zu unnötiger, wiederholter Fehlersuche in die falsche Richtung führt.

Ein zweites häufiges Muster ist die bewusste oder unbewusste Ignoranz der TTL durch Anwendungen, wie im vorherigen Abschnitt beschrieben. Für Magento-Setups mit mehreren Servern hinter einem Loadbalancer ist es deshalb ratsam, DNS-TTLs bei geplanten Migrationen rechtzeitig, idealerweise Tage vorher, auf einen niedrigen Wert wie 60 Sekunden zu reduzieren, damit sowohl Resolver-Caches als auch Anwendungs-Caches den Wechsel zeitnah übernehmen, statt tagelang veraltete IP-Adressen zu verwenden.

7. DNS in Containern und hinter VPNs richtig einordnen

In Docker-Containern wird die Namensauflösung standardmäßig über eine vom Docker-Daemon injizierte resolv.conf gesteuert, die entweder die Host-DNS-Server oder, bei nutzerdefinierten Netzwerken, den eingebauten Docker-DNS-Server auf 127.0.0.11 referenziert. Ein DNS-Problem, das nur innerhalb eines Containers auftritt, aber auf dem Host nicht reproduzierbar ist, deutet fast immer auf eine fehlerhafte Netzwerk-Konfiguration des Containers hin, etwa ein falsches --dns-Flag oder ein Netzwerk-Modus, der die Docker-eigene Auflösung umgeht.

Bei aktivem VPN mit Split-Tunneling-Konfiguration kann es zusätzlich zu einem Wettlauf zwischen mehreren DNS-Servern kommen, bei dem systemd-resolved je nach konfigurierter Routing-Domain (~firma.intern in resolvectl) unterschiedliche Anfragen an unterschiedliche Server schickt. Wird diese Domain-basierte Weiterleitung nicht korrekt konfiguriert, lösen interne Hostnamen mal über den internen, mal über den öffentlichen Resolver auf, mit entsprechend inkonsistenten Ergebnissen. Der Befehl resolvectl domain zeigt genau diese Zuordnung pro Interface und ist bei VPN-bezogenen DNS-Problemen der erste Blick.

# Which DNS server is configured inside a running container?
docker exec my-container cat /etc/resolv.conf

# Which routing domains are bound to which network interface?
# Reveals VPN split-tunnel DNS routing conflicts
resolvectl domain

# Force a specific interface's DNS server for one manual test query
resolvectl query --interface=tun0 internal-host.firma.intern

8. DNS-Latenz und Fehlerraten dauerhaft überwachen

Einmalige Diagnosebefehle lösen ein akutes Problem, verhindern aber nicht, dass sich intermittierende DNS-Probleme wiederholen, ohne dass jemand sie bemerkt, bevor Kunden betroffen sind. Ein einfacher Cron-Job, der regelmäßig dig gegen kritische Hostnamen ausführt und Antwortzeit sowie Rückgabecode protokolliert, macht sporadische Verzögerungen oder Fehler sichtbar, lange bevor sie zu sichtbaren Ausfällen führen. Für produktive Umgebungen lohnt sich die Integration in ein bestehendes Monitoring wie Prometheus über den blackbox_exporter, der DNS-Prüfungen als eigenen Probe-Typ unterstützt und Latenz sowie Erfolgsrate als Zeitreihe erfasst.

Besonders wertvoll ist die Überwachung mehrerer Auflösungspfade parallel, etwa direkt gegen den konfigurierten Resolver und zusätzlich gegen einen bekannten öffentlichen Resolver. Eine Divergenz zwischen beiden Pfaden über einen längeren Zeitraum ist ein verlässliches Frühwarnsignal für ein sich entwickelndes lokales Konfigurationsproblem, bevor es zu einem vollständigen Ausfall der Namensauflösung kommt.

9. Diagnosewerkzeuge für DNS-Probleme im Vergleich

Die vorgestellten Werkzeuge testen unterschiedliche Ausschnitte der DNS-Auflösung und sollten deshalb gezielt kombiniert statt beliebig ausgetauscht werden. Die folgende Übersicht ordnet sie nach Prüfumfang.

10. Zusammenfassung

Ein DNS-Problem unter Linux sitzt in der überwältigenden Mehrheit der Fälle nicht beim autoritativen Server, sondern in der lokalen Auflösungskette: /etc/hosts über die nsswitch.conf-Reihenfolge, einer möglicherweise falsch verstandenen resolv.conf, die auf systemd-basierten Systemen oft nur ein Symlink auf den Stub-Resolver ist, oder einem widersprüchlich konfigurierten systemd-resolved über mehrere Netzwerk-Interfaces hinweg. Die richtige Prüfreihenfolge beginnt lokal und arbeitet sich erst danach zum externen Resolver vor, statt reflexhaft zuerst gegen einen öffentlichen Server wie 8.8.8.8 zu testen.

Entscheidend ist außerdem, zwischen dem Systemresolver und der tatsächlichen Anwendungslaufzeit zu unterscheiden, da PHP, Nginx und Java unterschiedlich stark von der Systemkonfiguration abweichen und eigene Caching-Strategien mitbringen. Negative Caches und ignorierte TTLs erklären, warum ein DNS-Problem nach der Behebung noch minutenlang fortbesteht. Wer diese Kette systematisch von innen nach außen prüft und die Ergebnisse dauerhaft überwacht, statt bei jedem Vorfall wieder bei null anzufangen, löst DNS-Probleme in der Regel innerhalb weniger Minuten.

11. FAQ: DNS-Auflösungsprobleme systematisch troubleshooten