Pourquoi la résolution DNS fonctionne-t-elle sur l’hôte, mais échoue-t-elle dans un conteneur ?

Le DNS de l’hôte peut fonctionner alors que celui du conteneur échoue, car le conteneur utilise un chemin de résolution, un espace de noms, une route de pare-feu ou un état de transfert Docker différent.

Sur un serveur domestique, l’hôte peut interroger directement un routeur, Pi-hole ou un résolveur VPN, tandis qu’un conteneur connecté à un réseau bridge envoie ses requêtes via le résolveur intégré de Docker ou un fichier resolv.conf copié. Le diagnostic le plus rapide consiste à tester d’abord une adresse IP, puis à interroger explicitement chaque résolveur depuis le conteneur défaillant afin de ne pas confondre une panne DNS avec un problème général de connectivité sortante.

Distinguer une panne DNS d’un problème réseau général

Depuis le conteneur défaillant, testez une adresse IP externe connue et l’adresse IP du serveur DNS prévu avant de tester un nom d’hôte. Notez les routes, les pertes de paquets et l’accessibilité des ports TCP et UDP 53.

Un cas concernant un conteneur Manjaro illustre la situation inverse : le trafic IP direct échouait également, ce qui prouvait que le problème dépassait le DNS. Ce test de connectivité IP directe évite que des changements de résolveur masquent un bridge, un NAT ou un chemin de pare-feu défaillant.

Si la connectivité IP échoue, réparez d’abord le réseau du conteneur. Si l’IP fonctionne mais que les noms échouent, poursuivez avec la configuration du résolveur et le chemin des requêtes.

Inspecter la configuration du résolveur dans le conteneur

Lisez /etc/resolv.conf dans le conteneur et comparez-le à celui de l’hôte. Notez les adresses des serveurs DNS, les domaines de recherche, les options, le mode réseau et les éventuelles modifications du fichier après la recréation du conteneur.

Un cas OpenMediaVault a signalé l’échec des recherches DNS des conteneurs via le résolveur intégré de Docker 127.0.0.11 après une mise à jour du moteur. Ce chemin de résolution intégré peut différer de celui utilisé par l’hôte, qui réussit ses recherches.

Ne modifiez pas définitivement le fichier généré dans un conteneur en cours d’exécution. Définissez les serveurs DNS et les domaines de recherche souhaités dans la configuration Compose ou celle de la plateforme afin qu’ils soient conservés lors de la recréation.

Interroger séparément le DNS de Docker et le résolveur en amont

Effectuez la même recherche auprès du résolveur intégré de Docker, du routeur ou du serveur DNS local, ainsi que d’un résolveur externe connu lorsque la politique réseau l’autorise. Comparez les délais d’attente, les refus, les réponses NXDOMAIN et les adresses renvoyées.

Dans un cas rapporté par la communauté TrueNAS, l’échec DNS limité aux conteneurs était dû à un profil d’accès du routeur qui bloquait les requêtes, alors que les autres communications de l’hôte fonctionnaient. L’observation déterminante était un blocage du DNS sur le chemin du conteneur, et non un nom d’hôte invalide.

Si les requêtes directes vers le résolveur en amont fonctionnent mais que le résolveur intégré échoue, redémarrez ou réparez le résolveur et l’état réseau de Docker. Si tous les serveurs DNS expirent, inspectez le routage du port 53, le pare-feu, le VPN et le trafic de réponse.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Rechercher les boucles DNS locales et les mauvaises réponses internes

Déterminez si le conteneur tente d’interroger un service DNS situé sur le même hôte, dans un autre conteneur, ou un nom d’hôte qui est résolu à nouveau via le proxy inverse. Capturez la réponse au lieu de supposer que toute recherche réussie est correcte.

Dans un cas rapporté par la communauté Traefik, un conteneur résolvait un domaine personnalisé vers lui-même au lieu du pair prévu. Cette mauvaise réponse DNS côté conteneur réussissait un test de résolution élémentaire, mais empêchait tout de même la connexion à l’API.

Utilisez les noms de service pour les communications entre conteneurs sur un même réseau, et le DNS fractionné pour les noms d’hôte publics uniquement lorsque le chemin de retour est intentionnel. Évitez les routes en boucle qui font passer un conteneur par le proxy public pour atteindre une dépendance locale, sauf si ce chemin a été explicitement testé.

Vérifier les réponses UDP, le NAT et l’isolation réseau

Capturez le trafic du port 53 sur l’interface du conteneur et le bridge de l’hôte. Vérifiez que la requête sort, que le résolveur la reçoit et que la réponse revient depuis l’adresse attendue par le client.

Des utilisateurs de Pi-hole ont signalé que les requêtes de conteneurs situés sur le même hôte expiraient parce que les réponses revenaient depuis une source traduite inattendue. Cette source de réponse DNS inattendue permet de distinguer un problème de chemin de réponse d’un résolveur silencieux.

Si la requête et la réponse traversent des réseaux Docker différents, ajoutez le réseau partagé ou la route appropriée au lieu de faire passer tous les services en mode réseau hôte. Vérifiez les zones du pare-feu et les politiques VPN qui peuvent traiter les sous-réseaux bridge différemment de l’adresse de l’hôte.

Recréer l’état réseau et vérifier la correction

Après avoir corrigé le résolveur, le pare-feu ou la définition réseau, recréez un conteneur de test sur le réseau prévu et répétez les tests d’IP, de résolveur direct, de résolveur intégré, de nom de service et de nom public.

Le guide ZimaSpace consacré à la séparation des problèmes d’adresse et de nom fournit une limite de diagnostic complémentaire côté hôte.

Le problème n’est résolu que lorsque la configuration DNS subsiste après la recréation et le redémarrage, que les noms de services internes et les noms publics autorisés renvoient les adresses prévues, et que le trafic applicatif fonctionne sur le même chemin réseau. Si la panne ne réapparaît qu’après une mise à jour de Docker, conservez la version et les journaux du démon afin de délimiter une éventuelle régression du moteur.