Waarom werkt DNS-resolutie op de host, maar mislukt deze in een container?

DNS op de host kan werken terwijl DNS in een container faalt, omdat de container een ander resolverpad, een andere naamruimte, firewallroute of Docker-doorstuurstatus gebruikt.

Op een thuisserver kan de host rechtstreeks een router, Pi-hole- of VPN-resolver bevragen, terwijl een container op een bridgenetwerk verzoeken verstuurt via Docker’s ingebouwde resolver of een gekopieerde resolv.conf. De snelste diagnose test eerst een IP-adres en bevraagt daarna elke resolver expliciet vanuit de falende container, zodat DNS-problemen niet worden verward met algemene uitgaande connectiviteit.

Maak onderscheid tussen een DNS-storing en een algemene netwerkstoring

Test vanuit de falende container een bekend extern IP-adres en het IP-adres van de bedoelde DNS-server voordat je een hostnaam test. Noteer routes, pakketverlies en of TCP- en UDP-poort 53 bereikbaar zijn.

Een geval met een Manjaro-container laat de tegenovergestelde situatie zien: rechtstreeks IP-verkeer faalde ook, wat bewees dat het probleem breder was dan DNS. Deze test van IP-connectiviteit voorkomt dat resolverwijzigingen een defecte bridge-, NAT- of firewallroute verhullen.

Als IP-connectiviteit faalt, herstel dan eerst de containernetwerken. Als IP werkt maar namen niet, ga dan verder met de resolverconfiguratie en het querypad.

Inspecteer de resolverconfiguratie in de container

Lees /etc/resolv.conf in de container en vergelijk dit met de host. Let op nameserveradressen, zoekdomeinen, opties, de netwerkmodus en of het bestand na opnieuw aanmaken verandert.

In een geval met OpenMediaVault faalden zoekopdrachten vanuit containers via Docker’s ingebouwde 127.0.0.11-resolver na een runtime-update. Dat pad via de ingebouwde resolver kan afwijken van de geslaagde zoekopdracht van de host.

Pas het gegenereerde bestand in een actieve container niet permanent aan. Stel bewuste DNS-servers en zoekdomeinen in de configuratie van Compose of het platform in, zodat ze behouden blijven na het opnieuw aanmaken.

Bevraag Docker-DNS en de upstream-resolver afzonderlijk

Voer dezelfde zoekopdracht uit tegen Docker’s ingebouwde resolver, de router of lokale DNS-server en, waar het beleid dit toestaat, een bekende externe resolver. Vergelijk time-outs, weigeringen, NXDOMAIN en het geretourneerde adres.

In een geval uit de TrueNAS-community bleek dat een routertoegangsprofiel de verzoeken blokkeerde, hoewel ander verkeer van de host wel werkte. De doorslaggevende vaststelling was dat DNS voor het containerpad werd geblokkeerd, niet dat de hostnaam ongeldig was.

Als rechtstreekse upstream-zoekopdrachten werken maar de ingebouwde resolver faalt, start dan Docker’s resolver en netwerkstatus opnieuw op of herstel deze. Als elke DNS-server een time-out geeft, controleer dan de routering van poort 53, de firewall, VPN en het retourverkeer.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Controleer lokale DNS-lussen en onjuiste interne antwoorden

Bepaal of de container een DNS-service op dezelfde host, een andere container of een hostnaam probeert te bevragen die via de reverse proxy naar zichzelf terugverwijst. Leg het antwoord vast in plaats van aan te nemen dat elke geslaagde zoekopdracht correct is.

In een geval uit de Traefik-community bleek dat één container een aangepast domein naar zichzelf resolveerde in plaats van naar de bedoelde peer. Dat onjuiste DNS-antwoord vanuit de container doorstond een eenvoudige resolutietest, maar verbrak toch de API-verbinding.

Gebruik servicenamen voor verkeer tussen containers op hetzelfde netwerk en gebruik split-DNS voor openbare hostnamen alleen wanneer het retourpad bewust is ingericht. Vermijd hairpinroutes waarbij een container via de openbare proxy naar een lokale afhankelijkheid gaat, tenzij dat pad expliciet is getest.

Controleer UDP-antwoorden, NAT en netwerkisolatie

Leg verkeer op poort 53 vast op de containerinterface en de hostbridge. Controleer of de query vertrekt, de resolver deze ontvangt en het antwoord terugkomt vanaf het adres dat de client verwacht.

Gebruikers van Pi-hole hebben vastgelegd dat zoekopdrachten tussen containers op dezelfde host time-outs kregen omdat antwoorden terugkwamen vanaf een onverwachte vertaalde bron. Deze onverwachte bron van het DNS-antwoord maakt onderscheid tussen een probleem met het retourpad en een stille resolver.

Als het verzoek en antwoord verschillende Docker-netwerken doorkruisen, voeg dan het juiste gedeelde netwerk of de juiste route toe in plaats van elke service naar hostnetwerken te verplaatsen. Controleer firewallzones en VPN-beleid die bridgenetwerken mogelijk anders behandelen dan het hostadres.

Maak de netwerkstatus opnieuw aan en bewijs de oplossing

Maak na het corrigeren van de resolver, firewall of netwerkdefinitie één testcontainer opnieuw aan op het bedoelde netwerk en herhaal de tests voor IP, rechtstreekse resolver, ingebouwde resolver, servicenaam en openbare naam.

De ZimaSpace-gids over het scheiden van adres- en naamstoringen beschrijft de aangrenzende diagnostische grens aan de hostzijde.

Het probleem is pas opgelost wanneer de DNS-configuratie na opnieuw aanmaken en opnieuw opstarten behouden blijft, interne servicenamen en goedgekeurde openbare namen naar de bedoelde adressen verwijzen en applicatieverkeer via hetzelfde netwerkpad slaagt. Als de fout alleen na een Docker-update terugkeert, bewaar dan de versie en daemonlogboeken als grens voor een regressie in de runtime.