Por que um contêiner proxy não usa automaticamente o contêiner DNS

Executar um proxy e um servidor DNS no mesmo host Docker não conecta os caminhos DNS deles. Três relações separadas importam:

• Alcançabilidade de rede. Projetos Compose separados normalmente têm redes padrão separadas. Coloque os serviços em uma rede compartilhada adequada, seja dentro de um projeto ou por meio de uma rede explicitamente compartilhada entre projetos.
• Descoberta de serviço. O DNS embutido de uma rede Docker personalizada pode resolver nomes de contêineres. Isso permite que uma aplicação descubra um vizinho; mas não seleciona automaticamente esse vizinho como seu resolvedor DNS.
• Seleção do resolvedor. Identifique o resolvedor usado dentro do contêiner proxy. O campo dns do Compose aceita endereços de servidores DNS. Um nome como dns.local que resolve em uma aplicação não o torna um valor válido para esse campo.

Acompanhe a consulta do contêiner proxy até seu endereço de resolvedor configurado. Confirme que existe uma rota e um ouvinte DNS nesse endereço. Publicar a porta 53 do host cria um caminho de acesso do lado do host; mas não diz aos contêineres para usá-lo. Contêineres que compartilham uma rede podem, em vez disso, comunicar-se diretamente.

Se a configuração faz referência ao endereço do contêiner DNS, mantenha-o estável em uma configuração IPAM compatível. Um endereço atribuído dinamicamente e copiado do contêiner de ontem pode falhar na recriação. Inspecione também o caminho ascendente do resolvedor: encaminhar consultas sem resposta de volta para ele mesmo cria uma falha diferente de um resolvedor inalcançável.

Por fim, identifique quem resolve o destino. Um proxy HTTP que resolve um nome CONNECT pode usar este caminho de contêiner; um cliente SOCKS que resolve localmente talvez não. Uma consulta no host prova a rota do host, não a do processo proxy.