Porque é que a resolução de DNS funciona no anfitrião, mas falha dentro de um contentor?

O DNS do host pode funcionar enquanto o DNS do contentor falha, porque o contentor utiliza um caminho de resolução, um espaço de nomes, uma rota de firewall ou um estado de encaminhamento do Docker diferente.

Num servidor doméstico, o host pode consultar diretamente um router, o Pi-hole ou um resolvedor VPN, enquanto um contentor numa rede bridge envia pedidos através do resolvedor integrado do Docker ou de um resolv.conf copiado. O diagnóstico mais rápido testa primeiro um endereço IP e, em seguida, consulta explicitamente cada resolvedor a partir do contentor afetado, para que uma falha de DNS não seja confundida com um problema geral de conectividade de saída.

Separe a falha de DNS de uma falha geral de rede

A partir do contentor afetado, teste um IP externo conhecido e o endereço IP do servidor DNS pretendido antes de testar qualquer nome de host. Registe as rotas, a perda de pacotes e se as portas TCP e UDP 53 estão acessíveis.

Um caso com um contentor Manjaro demonstra o ramo oposto: o tráfego IP direto também falhou, provando que o problema era mais abrangente do que o DNS. Este teste de conectividade por IP direto evita que alterações ao resolvedor ocultem uma bridge, uma NAT ou um caminho de firewall avariado.

Se a conectividade IP falhar, corrija primeiro a rede do contentor. Se o IP funcionar, mas os nomes falharem, continue a analisar a configuração do resolvedor e o caminho das consultas.

Inspecione a configuração do resolvedor dentro do contentor

Leia o /etc/resolv.conf dentro do contentor e compare-o com o do host. Observe os endereços dos servidores de nomes, os domínios de pesquisa, as opções, o modo de rede e se o ficheiro é alterado após a recriação.

Um caso do OpenMediaVault relatou falhas nas consultas dos contentores através do resolvedor integrado do Docker, 127.0.0.11, após uma atualização do runtime. Esse caminho do resolvedor integrado pode divergir da resolução bem-sucedida do host.

Não edite permanentemente o ficheiro gerado dentro de um contentor em execução. Defina os servidores DNS e os domínios de pesquisa pretendidos na configuração do Compose ou da plataforma, para que persistam após a recriação.

Consulte separadamente o DNS do Docker e o resolvedor a montante

Execute a mesma consulta contra o resolvedor integrado do Docker, o router ou servidor DNS local e um resolvedor externo conhecido, quando as políticas o permitirem. Compare o tempo limite, a recusa, o NXDOMAIN e o endereço devolvido.

Um caso da comunidade TrueNAS atribuiu uma falha de DNS exclusiva dos contentores a um perfil de acesso do router que bloqueava os pedidos, embora outro tráfego do host funcionasse. A observação decisiva foi o bloqueio do DNS no caminho do contentor, e não um nome de host inválido.

Se as consultas diretas ao servidor a montante funcionarem, mas o resolvedor integrado falhar, reinicie ou repare o resolvedor e o estado da rede do Docker. Se todos os servidores DNS excederem o tempo limite, inspecione o encaminhamento da porta 53, a firewall, a VPN e o tráfego de resposta.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Procure ciclos de DNS locais e respostas internas incorretas

Determine se o contentor está a tentar consultar um serviço DNS no mesmo host, noutro contentor ou um nome de host que seja resolvido novamente através do proxy inverso. Capture a resposta em vez de assumir que todas as consultas bem-sucedidas estão corretas.

Um caso da comunidade Traefik revelou que um contentor resolvia um domínio personalizado para si próprio, em vez de o resolver para o peer pretendido. Essa resposta DNS incorreta no contentor passou num teste básico de resolução, mas continuou a impedir a ligação à API.

Utilize nomes de serviço para o tráfego entre contentores na mesma rede e DNS dividido para nomes de host públicos apenas quando o caminho de retorno for deliberado. Evite rotas hairpin que enviem um contentor através do proxy público para alcançar uma dependência local, a menos que esse caminho tenha sido explicitamente testado.

Verifique as respostas UDP, a NAT e o isolamento da rede

Capture o tráfego da porta 53 na interface do contentor e na bridge do host. Confirme que a consulta sai, que o resolvedor a recebe e que a resposta regressa a partir do endereço esperado pelo cliente.

Utilizadores do Pi-hole documentaram tempos limite nas consultas entre contentores no mesmo host porque as respostas regressavam de uma origem traduzida inesperada. Esta origem inesperada da resposta DNS distingue um problema no caminho de resposta de um resolvedor silencioso.

Se o pedido e a resposta atravessarem redes Docker diferentes, adicione a rede partilhada ou a rota correta, em vez de transferir todos os serviços para a rede do host. Verifique as zonas da firewall e as políticas da VPN que possam tratar as sub-redes bridge de forma diferente do endereço do host.

Recrie o estado da rede e confirme a correção

Depois de corrigir o resolvedor, a firewall ou a definição da rede, recrie um contentor de teste na rede pretendida e repita os testes de IP, resolvedor direto, resolvedor integrado, nome de serviço e nome público.

O guia da ZimaSpace sobre separar falhas de endereço e de nome apresenta o limite de diagnóstico adjacente do lado do host.

O problema só está resolvido quando a configuração DNS persiste após a recriação e o reinício, os nomes de serviço internos e os nomes públicos aprovados devolvem os endereços pretendidos e o tráfego da aplicação funciona através do mesmo caminho de rede. Se a falha voltar apenas depois de uma atualização do Docker, preserve a versão e os registos do daemon como limite de diagnóstico de uma regressão do runtime.