Warum funktioniert die DNS-Auflösung auf dem Host, schlägt aber innerhalb eines Containers fehl?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Why Does DNS Resolution Work on the Host but Fail Inside a Container? - Zima Store Online

Die DNS-Auflösung des Hosts kann funktionieren, während die DNS-Auflösung im Container fehlschlägt, weil der Container einen anderen Resolver-Pfad, Namespace, eine andere Firewall-Route oder einen anderen Docker-Weiterleitungsstatus verwendet.

Auf einem Heimserver kann der Host einen Router, Pi-hole oder VPN-Resolver direkt abfragen, während ein Container in einem Bridge-Netzwerk Anfragen über Dockers integrierten Resolver oder eine kopierte resolv.conf sendet. Die schnellste Diagnose testet zuerst eine IP-Adresse und fragt anschließend jeden Resolver explizit aus dem fehlerhaften Container ab, damit ein DNS-Fehler nicht mit einer allgemeinen ausgehenden Verbindungsstörung verwechselt wird.

DNS-Fehler von allgemeinen Netzwerkfehlern unterscheiden

Teste aus dem fehlerhaften Container eine bekannte externe IP-Adresse und die IP-Adresse des vorgesehenen DNS-Servers, bevor du einen Hostnamen testest. Notiere Routen, Paketverluste und ob TCP- und UDP-Port 53 erreichbar sind.

Ein Fall mit einem Manjaro-Container zeigt den umgekehrten Zweig: Auch der direkte IP-Datenverkehr schlug fehl, was bewies, dass das Problem über DNS hinausging. Dieser Test der direkten IP-Konnektivität verhindert, dass Resolver-Änderungen eine fehlerhafte Bridge-, NAT- oder Firewall-Verbindung verdecken.

Wenn die IP-Konnektivität fehlschlägt, repariere zuerst die Container-Netzwerkverbindung. Wenn IP-Verbindungen funktionieren, aber Namen nicht aufgelöst werden, fahre mit der Resolver-Konfiguration und dem Abfragepfad fort.

Resolver-Konfiguration im Container prüfen

Lies /etc/resolv.conf im Container aus und vergleiche die Datei mit der des Hosts. Achte auf Nameserver-Adressen, Suchdomänen, Optionen, den Netzwerkmodus und darauf, ob sich die Datei nach einer Neuerstellung ändert.

In einem OpenMediaVault-Fall schlugen Abfragen im Container nach einem Laufzeit-Update über Dockers integrierten 127.0.0.11-Resolver fehl. Dieser integrierte Resolver-Pfad kann sich von der erfolgreichen Namensauflösung des Hosts unterscheiden.

Bearbeite die generierte Datei in einem laufenden Container nicht dauerhaft. Lege beabsichtigte DNS-Server und Suchdomänen in der Compose- oder Plattformkonfiguration fest, damit sie eine Neuerstellung überstehen.

Docker-DNS und den Upstream-Resolver getrennt abfragen

Führe dieselbe Abfrage gegen Dockers integrierten Resolver, den Router oder lokalen DNS-Server sowie – sofern Richtlinien dies erlauben – einen bekannten externen Resolver aus. Vergleiche Zeitüberschreitungen, Ablehnungen, NXDOMAIN und die zurückgegebene Adresse.

In einem TrueNAS-Community-Fall wurde der DNS-Fehler ausschließlich im Container auf ein Router-Zugriffsprofil zurückgeführt, das die Anfragen blockierte, obwohl anderer Datenverkehr des Hosts funktionierte. Die entscheidende Beobachtung war, dass DNS für den Container-Pfad blockiert wurde und nicht, dass der Hostname ungültig war.

Wenn direkte Abfragen an den Upstream funktionieren, der integrierte Resolver jedoch fehlschlägt, starte Dockers Resolver und Netzwerkstatus neu oder repariere sie. Wenn jeder DNS-Server mit einer Zeitüberschreitung antwortet, prüfe Routing und Firewall für Port 53 sowie VPN- und Antwortdatenverkehr.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

Lokale DNS-Schleifen und falsche interne Antworten prüfen

Ermittle, ob der Container versucht, einen DNS-Dienst auf demselben Host, in einem anderen Container oder einen Hostnamen abzufragen, der über den Reverse-Proxy zurück aufgelöst wird. Zeichne die Antwort auf, statt anzunehmen, dass jede erfolgreiche Auflösung korrekt ist.

In einem Traefik-Community-Fall wurde festgestellt, dass ein Container eine benutzerdefinierte Domäne auf sich selbst statt auf den vorgesehenen Peer auflöste. Diese falsche containerseitige DNS-Antwort bestand einen einfachen Auflösungstest, verhinderte aber weiterhin die API-Verbindung.

Verwende für den Datenverkehr zwischen Containern im selben Netzwerk die Dienstnamen und Split-DNS für öffentliche Hostnamen nur dann, wenn der Rückweg bewusst eingerichtet ist. Vermeide Hairpin-Routen, die einen Container über den öffentlichen Proxy zu einer lokalen Abhängigkeit führen, sofern dieser Pfad nicht ausdrücklich getestet wurde.

UDP-Antworten, NAT und Netzwerkisolation überprüfen

Zeichne Datenverkehr auf Port 53 an der Containerschnittstelle und der Host-Bridge auf. Bestätige, dass die Abfrage den Container verlässt, der Resolver sie empfängt und die Antwort von der Adresse zurückkommt, die der Client erwartet.

Pi-hole-Nutzer haben dokumentiert, dass Anfragen zwischen Containern auf demselben Host mit einer Zeitüberschreitung fehlschlugen, weil Antworten von einer unerwartet übersetzten Quelladresse zurückkamen. Diese unerwartete DNS-Antwortquelle unterscheidet ein Problem auf dem Antwortpfad von einem stummen Resolver.

Wenn Anfrage und Antwort verschiedene Docker-Netzwerke durchqueren, füge das richtige gemeinsame Netzwerk oder die richtige Route hinzu, statt alle Dienste in das Hostnetzwerk zu verschieben. Prüfe Firewall-Zonen und VPN-Richtlinien, die Bridge-Subnetze möglicherweise anders behandeln als die Hostadresse.

Netzwerkstatus neu erstellen und die Lösung bestätigen

Nachdem du Resolver, Firewall oder Netzwerkdefinition korrigiert hast, erstelle einen Testcontainer im vorgesehenen Netzwerk neu und wiederhole die Tests für IP-Adresse, direkten Resolver, integrierten Resolver, Dienstnamen und öffentliche Namen.

Der ZimaSpace-Leitfaden zur Trennung von Adress- und Namensfehlern beschreibt die angrenzende Diagnosegrenze auf Host-Seite.

Das Problem ist erst dann behoben, wenn die DNS-Konfiguration eine Neuerstellung und einen Neustart übersteht, interne Dienstnamen und genehmigte öffentliche Namen die vorgesehenen Adressen zurückgeben und der Anwendungsdatenverkehr über denselben Netzwerkpfad erfolgreich funktioniert. Wenn der Fehler erst nach einem Docker-Update wieder auftritt, sichere die Version und die Daemon-Protokolle, um die Grenze einer möglichen Regression der Laufzeit festzuhalten.