Por qué un contenedor proxy no usa automáticamente el contenedor DNS

Ejecutar un proxy y un servidor DNS en un mismo host Docker no conecta sus rutas DNS. Importan tres relaciones separadas:

• Alcance de red. Los proyectos Compose separados suelen tener redes predeterminadas separadas. Coloca los servicios en una red compartida adecuada, ya sea dentro de un proyecto o mediante una red compartida explícitamente entre proyectos.
• Descubrimiento de servicios. El DNS integrado de una red Docker personalizada puede resolver nombres de contenedores. Eso permite que una aplicación descubra un vecino; pero no selecciona automáticamente a ese vecino como su resolutor DNS.
• Selección del resolutor. Identifica el resolutor que se usa dentro del contenedor proxy. El campo dns de Compose acepta direcciones de servidores DNS. Un nombre como dns.local que se resuelve en una aplicación no lo convierte en un valor válido para ese campo.

Sigue la consulta desde el contenedor proxy hasta su dirección de resolutor configurada. Confirma que hay una ruta y un escucha DNS en esa dirección. Publicar el puerto 53 del host crea una vía de acceso del lado del host; pero no indica a los contenedores que la usen. Los contenedores que comparten una red pueden, en cambio, comunicarse directamente.

Si la configuración hace referencia a la dirección del contenedor DNS, mantenla estable con una configuración IPAM compatible. Una dirección asignada dinámicamente y copiada del contenedor de ayer puede fallar al recrearlo. Inspecciona también la ruta ascendente del resolutor: reenviar consultas sin respuesta hacia sí mismo crea un fallo distinto del de un resolutor inalcanzable.

Por último, identifica quién resuelve el destino. Un proxy HTTP que resuelve un nombre CONNECT puede usar esta ruta a través del contenedor; un cliente SOCKS que resuelve localmente puede que no. Una consulta en el host demuestra la ruta del host, no la del proceso del proxy.