Como corrigir "servidor DNS não está respondendo"

O que o erro significa

Toda conexão começa com uma consulta. O seu dispositivo envia o nome de host para um resolvedor, normalmente o seu roteador, o seu provedor de internet ou um serviço público como o 1.1.1.1, e espera por um endereço IP. Se nenhuma resposta chega dentro do tempo limite, o sistema operacional tenta de novo, tenta o servidor secundário e no fim desiste. O Windows então roda a solução de problemas, que informa que o servidor DNS não está respondendo.

O texto aponta para o servidor, mas na verdade é uma afirmação sobre um caminho. Qualquer uma destas situações produz a mesma mensagem: o resolvedor está fora do ar, o resolvedor está no ar mas inacessível a partir da sua rede, um firewall descarta a porta 53, o endereço configurado no seu adaptador está errado, ou o roteador no meio parou de encaminhar. O silêncio é idêntico nos cinco casos.

Separe esse erro dos vizinhos antes de começar. Um resolvedor que responde "nome inexistente" devolve NXDOMAIN, tratado em DNS_PROBE_FINISHED_NXDOMAIN. Um resolvedor que responde devagar mas corretamente é outro problema, com sua própria seção abaixo. Este erro é o caso em que nada volta.

Por que acontece

• O roteador parou de encaminhar. Roteadores domésticos rodam um pequeno encaminhador de DNS que trava mais do que o resto do aparelho, então a rede parece funcionar e só as consultas de nome falham.
• O servidor DNS configurado está errado. Um endereço fixo que sobrou de uma rede antiga, ou um servidor que foi desativado.
• O resolvedor do provedor está com uma queda ou está sobrecarregado e descartando consultas em vez de respondê-las.
• Um firewall ou pacote de segurança bloqueia a porta 53. Alguns produtos interceptam o DNS por conta própria e bloqueiam tudo quando o serviço deles não está rodando.
• Uma VPN está pela metade. O túnel empurrou os resolvedores internos dele para o seu adaptador e depois caiu, deixando endereços que só são acessíveis dentro do túnel.
• O IPv6 está configurado mas não é utilizável. O sistema prefere um resolvedor IPv6, não encontra rota até ele e espera o tempo limite inteiro antes de recorrer ao IPv4.
• O serviço Cliente DNS do Windows está parado ou o cache dele está corrompido.
• Um malware ou aplicativo indesejado mudou o resolvedor para um endereço que ele controla, e esse endereço some depois.
• A rede exige login em um portal cativo que ainda não aconteceu, então todo DNS de saída é engolido.

Como corrigir

Descubra se a rede em si está funcionando antes de mexer nas configurações de DNS. ping 1.1.1.1 não usa resolução de nomes nenhuma. Se isso também falhar, você tem um problema de conectividade, não de DNS. Se funcionar enquanto ping example.com falha, o DNS está confirmado como a peça quebrada e os passos abaixo se aplicam.

Windows

1. Limpe o cache e reinicie o serviço de cliente:

   ipconfig /flushdns
   net stop dnscache
   net start dnscache

2. Veja o que o seu adaptador está usando: ipconfig /all | findstr /C:"DNS Servers"
3. Configure um resolvedor público no lugar: netsh interface ipv4 set dnsservers name="Wi-Fi" static 1.1.1.1 primary
4. Teste esse servidor específico diretamente: nslookup example.com 1.1.1.1
5. Reinicie a pilha se nada se mantiver, e depois reinicie o computador:

   netsh int ip reset
   netsh winsock reset

6. Desmarque o IPv6 no adaptador se a máquina não tiver IPv6 funcionando, e teste de novo.

macOS

1. Limpe o cache: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
2. Leia os resolvedores em uso: scutil --dns | grep nameserver
3. Substitua-os: sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1
4. Volte ao que o DHCP entrega: sudo networksetup -setdnsservers Wi-Fi empty

Linux

1. Verifique o status e limpe o cache: resolvectl status, depois sudo resolvectl flush-caches
2. Consulte um servidor explicitamente para ver se ele responde: dig @1.1.1.1 example.com +short
3. Mude o resolvedor na conexão em vez de editar /etc/resolv.conf, que normalmente é gerado:

   nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1"
   nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
   nmcli con up "Wired connection 1"

4. Reinicie o resolvedor stub se ele estiver travado: sudo systemctl restart systemd-resolved

Roteador

1. Desligue e ligue o aparelho e espere o link WAN voltar antes de testar.
2. Na página de administração, defina os servidores DNS da WAN como um par público em vez de "obter automaticamente", se o suspeito for o resolvedor do provedor.
3. Atualize o firmware. Bugs no encaminhador de DNS são um motivo comum para um roteador precisar de reinício a cada poucas semanas.
4. Contorne o roteador como teste: conecte um celular à rede móvel e resolva o mesmo nome. Se funcionar, a falha está na sua rede.

Navegador

1. Chrome, Edge e Firefox podem enviar DNS sobre HTTPS para um provedor próprio, independente das configurações do sistema. Se o navegador falha enquanto o dig funciona, desligue o DNS seguro nas configurações de privacidade do navegador e teste de novo.
2. Limpe o cache interno do Chrome em chrome://net-internals/#dns.

Quando a consulta está lenta, não quebrada

Nem toda reclamação sobre DNS é uma falha. Se as páginas acabam carregando mas travam um ou dois segundos antes de qualquer coisa acontecer, o resolvedor está respondendo, só que tarde, e as correções acima não vão mudar muita coisa. Meça antes de adivinhar:

dig example.com | grep "Query time"
dig @1.1.1.1 example.com | grep "Query time"

Qualquer valor de um dígito ou de duas dezenas de milissegundos vindo de um cache quente é normal. Várias centenas de milissegundos, ou um número que varia muito entre execuções, significa que o resolvedor está longe, sobrecarregado ou estourando o tempo no primeiro servidor e recorrendo a um segundo. Esse é outro diagnóstico, com outras correções, descrito em como corrigir uma consulta DNS lenta.

Verifique de fora

Tudo até aqui pressupõe que a falha está perto de você, o que geralmente é verdade. Confirme isso antes de gastar uma tarde no assunto. Pergunte a um resolvedor que não tem nada a ver com a sua rede se o nome resolve:

dig @8.8.8.8 example.com +short
dig @9.9.9.9 example.com +short
nslookup example.com 1.1.1.1

Uma resposta desses servidores enquanto o seu resolvedor continua mudo prova que o domínio está bem e que o problema é do seu lado. Silêncio de todos eles desloca a atenção para os servidores de nomes do próprio domínio, que podem estar fora do ar ou inacessíveis a partir de uma parte da internet.

A acessibilidade de um servidor de nomes não é global. Rode a verificação de consulta DNS para enviar a mesma consulta de pontos de verificação em países diferentes e comparar as respostas lado a lado. Quando algumas localizações recebem resultado e outras estouram o tempo, o que você tem é um problema de roteamento ou de provedor afetando uma região, não um registro quebrado, e nenhuma limpeza de cache no seu notebook vai mostrar isso.

Quando o seu servidor de nomes fica mudo

Um servidor de nomes que fica mudo derruba um site tão completamente quanto um servidor web morto, e faz isso sem gerar uma única linha no seu log de acesso. Ninguém consegue avisar, porque ninguém consegue chegar até você. A HostTracker roda verificações programadas a partir de mais de 300 pontos de verificação em 158 cidades, em 13 tipos de monitoramento, então um nome que para de resolver em uma região é detectado pelos pontos de verificação de lá, não por um e-mail de cliente. O resto desta seção está no grupo de correções, e se a pergunta é se uma alteração recente de DNS já chegou a todo mundo, isso é como verificar a propagação de DNS.