Pourquoi un conteneur proxy n'utilise pas automatiquement le conteneur DNS

Faire tourner un proxy et un serveur DNS sur le même hôte Docker ne relie pas leurs chemins DNS. Trois relations distinctes comptent :

• Accessibilité réseau. Des projets Compose distincts ont généralement des réseaux par défaut distincts. Placez les services sur un réseau partagé approprié, soit au sein d'un même projet, soit via un réseau explicitement partagé entre projets.
• Découverte de services. Le DNS intégré d'un réseau Docker personnalisé peut résoudre des noms de conteneurs. Cela permet à une application de découvrir un voisin ; mais cela ne sélectionne pas automatiquement ce voisin comme résolveur DNS.
• Choix du résolveur. Identifiez le résolveur utilisé à l'intérieur du conteneur proxy. Le champ dns de Compose accepte des adresses de serveurs DNS. Un nom comme dns.local qui se résout dans une application n'en fait pas une valeur valide pour ce champ.

Suivez la requête depuis le conteneur proxy jusqu'à son adresse de résolveur configurée. Confirmez qu'une route et qu'un écouteur DNS existent à cette adresse. Publier le port 53 de l'hôte crée un chemin d'accès côté hôte ; cela n'indique pas aux conteneurs de l'utiliser. Des conteneurs partageant un réseau peuvent plutôt communiquer directement.

Si la configuration référence l'adresse du conteneur DNS, gardez-la stable avec une configuration IPAM compatible. Une adresse allouée dynamiquement et copiée depuis le conteneur d'hier peut échouer à la recréation. Inspectez aussi le chemin amont du résolveur : renvoyer les requêtes sans réponse vers lui-même crée une panne différente de celle d'un résolveur injoignable.

Enfin, identifiez qui résout la destination. Un proxy HTTP qui résout un nom CONNECT peut utiliser ce chemin via le conteneur ; un client SOCKS qui résout localement peut ne pas le faire. Une recherche sur l'hôte prouve la route de l'hôte, pas celle du processus proxy.