Varför fungerar DNS-upplösning på värden men misslyckas i en container?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

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

Värdens DNS kan fungera medan containerns DNS misslyckas eftersom containern använder en annan resolver-sökväg, namnrymd, brandväggsrutt eller Docker-vidarebefordran.

På en hemmaserver kan värden fråga en router, Pi-hole eller VPN-resolver direkt, medan en container i ett bryggnätverk skickar förfrågningar via Dockers inbäddade resolver eller en kopierad resolv.conf. Den snabbaste felsökningen testar först en IP-adress och frågar sedan varje resolver uttryckligen från den felande containern, så att DNS-fel inte förväxlas med generell utgående anslutning.

Skilj DNS-fel från allmänna nätverksfel

Testa från den felande containern en känd extern IP-adress och IP-adressen till den avsedda DNS-servern innan du testar något värdnamn. Dokumentera rutter, paketförluster och om TCP- och UDP-port 53 är nåbara.

Ett fall med en Manjaro-container visar den motsatta grenen: direkt IP-trafik misslyckades också, vilket bevisade att problemet var bredare än DNS. Detta direkta IP-anslutningstest förhindrar att resolverändringar döljer en trasig brygga, NAT- eller brandväggsrutt.

Om IP-anslutningen misslyckas ska du åtgärda containerns nätverk först. Om IP fungerar men namn misslyckas fortsätter du med resolverkonfigurationen och frågevägen.

Inspektera resolverkonfigurationen i containern

Läs /etc/resolv.conf i containern och jämför den med värdens. Notera namnserveradresser, sökdomäner, alternativ, nätverksläge och om filen ändras när containern återskapas.

I ett OpenMediaVault-fall rapporterades att namnuppslagning i containrar misslyckades via Dockers inbäddade 127.0.0.11-resolver efter en runtime-uppdatering. Den inbäddade resolver-sökvägen kan skilja sig från värdens fungerande namnuppslagning.

Redigera inte den genererade filen permanent i en körande container. Ange avsiktliga DNS-servrar och sökdomäner i compose- eller plattformskonfigurationen så att de överlever när containern återskapas.

Fråga Docker-DNS och uppströmsresolver separat

Kör samma namnuppslagning mot Dockers inbäddade resolver, routern eller den lokala DNS-servern samt en känd extern resolver där policyn tillåter det. Jämför tidsgräns, avvisning, NXDOMAIN och den returnerade adressen.

Ett fall i TrueNAS-communityn spårade ett DNS-fel som endast drabbade containrar till en åtkomstprofil i routern som blockerade förfrågningarna, trots att annan trafik från värden fungerade. Den avgörande observationen var blockerad DNS för containerns sökväg, inte ett ogiltigt värdnamn.

Om direkta frågor till uppströmsresolver fungerar men den inbäddade resolvern misslyckas ska du starta om eller reparera Dockers resolver och nätverkstillstånd. Om alla DNS-servrar får tidsgräns ska du kontrollera routning för port 53, brandvägg, VPN och returtrafik.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Kontrollera lokala DNS-loopar och felaktiga interna svar

Ta reda på om containern försöker fråga en DNS-tjänst på samma värd, en annan container eller ett värdnamn som går tillbaka via reverse proxyn. Fånga svaret i stället för att anta att varje lyckad namnuppslagning är korrekt.

I ett Traefik-communityfall upptäcktes att en container slog upp en anpassad domän till sig själv i stället för till den avsedda partnern. Det felaktiga DNS-svaret i containern klarade ett grundläggande upplösningstest men bröt ändå API-anslutningen.

Använd tjänstenamn för trafik mellan containrar i samma nätverk och delad DNS för offentliga värdnamn endast när returvägen är avsiktlig. Undvik hårnålsrutter som skickar en container via den offentliga proxyn för att nå ett lokalt beroende, såvida den vägen inte uttryckligen har testats.

Verifiera UDP-svar, NAT och nätverksisolering

Fånga trafik på port 53 på containerns gränssnitt och värdens brygga. Bekräfta att frågan lämnar containern, att resolvern tar emot den och att svaret återkommer från den adress klienten förväntar sig.

Pi-hole-användare har dokumenterat att förfrågningar från container till container på samma värd får tidsgräns eftersom svaren återkommer från en oväntad översatt källa. Denna oväntade DNS-svarskälla skiljer ett problem med svarsvägen från en tyst resolver.

Om begäran och svaret passerar olika Docker-nätverk ska du lägga till rätt gemensamt nätverk eller rätt rutt i stället för att flytta alla tjänster till värdnätverk. Kontrollera brandväggszoner och VPN-policyer som kan behandla bryggans subnät annorlunda än värdens adress.

Återskapa nätverkstillståndet och bevisa lösningen

Efter att du har korrigerat resolvern, brandväggen eller nätverksdefinitionen ska du återskapa en testcontainer på det avsedda nätverket och upprepa testerna av IP, direkt resolver, inbäddad resolver, tjänstenamn och offentligt namn.

ZimaSpace-guiden om att separera adress- och namnfel beskriver den närliggande diagnostiska gränsen på värdsidan.

Problemet är löst först när DNS-konfigurationen överlever att containern återskapas och startas om, när interna tjänstenamn och godkända offentliga namn returnerar de avsedda adresserna och när applikationstrafiken fungerar via samma nätverkssökväg. Om felet återkommer först efter en Docker-uppdatering ska du bevara versionen och daemonloggarna som gräns för en möjlig runtime-regression.