DNS não responde
DNS não responde: veja as causas comuns, o erro DNS_PROBE_FINISHED_NXDOMAIN, fluxo de diagnóstico e como alternar para DNS público no Brasil.
Quando o DNS não responde, o navegador sabe chegar na internet mas falha em traduzir o nome do site para um endereço IP. A conexão pode estar perfeita, o sinal no topo, o roteador piscando normalmente. Mesmo assim, nada abre. A causa quase sempre é resolução de nome. Siga o fluxo abaixo para identificar o ponto exato da falha e corrigi-la em minutos, sem suporte técnico.
A solução mais rápida na maioria dos casos: trocar o DNS do provedor pelo Cloudflare (1.1.1.1 / 1.0.0.1) ou Google (8.8.8.8 / 8.8.4.4) e rodar ipconfig /flushdns no Windows. Para confirmar qual DNS está respondendo suas consultas agora, use a ferramenta consulta DNS.
O que significa "DNS não responde"
O DNS (Domain Name System) funciona como a lista telefônica da internet. Quando você digita google.com, o sistema operacional precisa saber qual endereço IP corresponde a esse nome antes de abrir qualquer conexão. Esse trabalho é feito pelo servidor DNS configurado no dispositivo, que costuma ser o do próprio provedor de internet.
"DNS não responde" indica que o servidor consultado não retornou resposta dentro do tempo limite. Pode ser que o servidor esteja sobrecarregado, fora do ar temporariamente ou inacessível por algum problema de rota. O resultado prático é idêntico ao de não ter internet, mesmo que o link esteja funcionando normalmente.
Distinguir DNS de conexão é o primeiro passo. Com o DNS quebrado, um ping para IP numérico (como ping 8.8.8.8) funciona; um ping para nome de domínio (como ping google.com) falha. Essa diferença confirma o diagnóstico em segundos.
Códigos de erro: NXDOMAIN, SERVFAIL, timeout
Nem todo erro de DNS é igual. Três códigos aparecem com frequência e indicam causas distintas:
| Código de erro | O que significa | Onde aparece no Chrome | Causa mais provável |
|---|---|---|---|
| NXDOMAIN | Domínio não existe nos servidores autoritativos | DNS_PROBE_FINISHED_NXDOMAIN | Typo no domínio, registro DNS expirado, arquivo hosts com conflito |
| SERVFAIL | O resolver recebeu a consulta mas não conseguiu completar a resolução | DNS_PROBE_FINISHED_BAD_CONFIG | Servidor DNS autoritativo do site com problema, DNSSEC inválido |
| Timeout | Sem resposta dentro do limite de tempo | DNS_PROBE_FINISHED_NO_INTERNET ou ERR_NAME_NOT_RESOLVED | Servidor DNS do provedor inacessível, firewall bloqueando porta 53 |
| REFUSED | Servidor recusou a consulta | ERR_NAME_RESOLUTION_FAILED | Filtro de DNS, política do servidor recusando consultas externas |
Para diferenciar NXDOMAIN de timeout diretamente no terminal, use nslookup domínio.com 8.8.8.8. Se retornar Non-existent domain, o problema é no próprio domínio. Se o comando travar sem resposta, o servidor DNS não está acessível.
O arquivo hosts local pode causar NXDOMAIN mesmo quando o domínio existe no DNS global. No Windows ele fica em C:\Windows\System32\drivers\etc\hosts; no macOS e Linux em /etc/hosts. Entradas antigas ou maliciosas nesse arquivo sobrepõem o DNS e causam falhas silenciosas para domínios específicos.
Causas frequentes de DNS não responde
| Causa | Como identificar | Quem afeta | Frequência prática |
|---|---|---|---|
| Servidor DNS do provedor fora do ar ou sobrecarregado | nslookup google.com falha; trocar para 8.8.8.8 resolve |
Todos os dispositivos da rede | Alta (horário de pico) |
| Cache DNS local corrompido | Problema em sites específicos; outros abrem normalmente | Um único dispositivo | Média |
| Configuração incorreta no roteador após reinício ou troca de firmware | Todos os dispositivos afetados; roteador sem DNS configurado | Toda a rede local | Média |
| Firewall ou antivírus interceptando porta 53 | Problema aparecer após instalar software de segurança | Um único dispositivo | Baixa |
| Arquivo hosts com entrada conflitante | Site específico não abre; nslookup com servidor externo resolve normalmente | Um único dispositivo | Baixa |
| DNSSEC inválido no domínio do site | SERVFAIL; funciona em DNS sem validação DNSSEC | Usuários de DNS com DNSSEC ativo (Quad9, Google) | Baixa (problema do servidor do site) |
Árvore de decisão: onde está o problema
O SVG abaixo mapeia o caminho de diagnóstico a partir do sintoma. Leia de cima para baixo seguindo o resultado de cada teste.
Distribuição de causas mais comuns (residencial BR)
Com base em relatos de suporte de provedores brasileiros e comunidades de redes, a distribuição aproximada das causas de "DNS não responde" em conexões residenciais:
Diagnóstico passo a passo
-
Teste a conexão de rede sem DNS: execute
ping 8.8.8.8no terminal. Se responder, a internet funciona e o problema é apenas resolução de nome. Se não responder, o problema é anterior ao DNS: verifique cabo, roteador e plano do provedor. -
Teste a resolução DNS atual: execute
nslookup google.com. Sem resposta ou com erro confirma falha no servidor DNS configurado. Com resposta normal, o problema pode ser específico do site ou do cache. -
Teste com DNS público alternativo: execute
nslookup google.com 1.1.1.1. Se resolver, o DNS do provedor está com problema. Troque definitivamente (veja como mudar DNS). Se também falhar, o problema pode ser firewall bloqueando a porta 53. -
Limpe o cache DNS local:
Windows:ipconfig /flushdns
macOS:sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
Linux (systemd):sudo systemd-resolve --flush-caches -
Verifique e edite o arquivo hosts: procure entradas manuais que referenciem o domínio afetado. Remova ou comente as linhas suspeitas com
#no início. -
Reinicie o serviço DNS local:
Windows:net stop dnscache && net start dnscache
Linux:sudo systemctl restart systemd-resolved - Reinicie o roteador: desligue por 30 segundos. Muitos roteadores residenciais mantêm cache DNS próprio que pode ficar corrompido após longa operação contínua.
- Desative temporariamente antivírus e firewall: se o problema desaparecer, o software de segurança está interceptando consultas DNS. Configure uma exceção para a porta 53 UDP/TCP.
- Contate o provedor: se todos os passos acima falharem, o servidor DNS do provedor pode estar com problema estrutural. Vivo, Claro e TIM disponibilizam status de serviço em seus portais de atendimento.
Tabela: sintoma, causa provável e solução
| Sintoma | Causa provável | Solução recomendada |
|---|---|---|
| Todos os sites falham; ping para IP funciona | Servidor DNS do provedor inacessível | Trocar para DNS público (1.1.1.1 ou 8.8.8.8) |
| DNS_PROBE_FINISHED_NXDOMAIN em um site específico | Domínio não existe ou arquivo hosts conflitante | Verificar digitação; revisar /etc/hosts; limpar cache |
| Problema só no meu dispositivo; outros funcionam | Cache local corrompido ou configuração de DNS manual errada | ipconfig /flushdns; voltar para DNS automático |
| Todos os dispositivos afetados ao mesmo tempo | DNS do roteador incorreto ou provedor instável | Reiniciar roteador; configurar DNS no roteador |
| Problema apareceu após instalar antivírus ou VPN | Software interceptando porta 53 | Configurar exceção no firewall; desativar e testar |
| SERVFAIL em site com HTTPS e certificado válido | DNSSEC inválido no domínio; resolver com validação rejeita | Trocar para DNS sem DNSSEC estrito (1.1.1.1 ou 8.8.8.8) temporariamente |
DNS públicos: comparativo e uso no Brasil
Trocar para um DNS público é o método mais simples e eficaz quando o servidor do provedor é a causa do problema. Os cinco mais usados no Brasil, com dados de configuração completos:
| Provedor | Primário IPv4 | Secundário IPv4 | IPv6 primário | Política de log | Filtros | Latência BR (aprox.) |
|---|---|---|---|---|---|---|
| Cloudflare | 1.1.1.1 | 1.0.0.1 | 2606:4700:4700::1111 | Sem log de IP após 24h, auditado pela KPMG | Nenhum (versão padrão) | 5-12 ms (SP/RJ) |
| Google Public DNS | 8.8.8.8 | 8.8.4.4 | 2001:4860:4860::8888 | Anonimiza IPs em 24-48h | Nenhum | 6-14 ms (SP/RJ) |
| Quad9 | 9.9.9.9 | 149.112.112.112 | 2620:fe::fe | Sem log de IP; sede na Suíça | Bloqueia domínios maliciosos (CISA/IBM) | 10-20 ms (SP) |
| OpenDNS | 208.67.222.222 | 208.67.220.220 | 2620:119:35::35 | Log com opção de gerenciamento | Opcional via painel (phishing, malware) | 15-25 ms |
| AdGuard DNS | 94.140.14.14 | 94.140.15.15 | 2a10:50c0::ad1:ff | Sem log de IP | Bloqueia anúncios e trackers | 15-30 ms |
Para usuários residenciais sem necessidade de filtros, Cloudflare e Google são as escolhas mais comuns. Quad9 adiciona uma camada de proteção contra domínios maliciosos sem necessidade de configuração adicional. Para instruções de configuração em cada sistema operacional, veja como mudar DNS.
DNS no Brasil: provedores e latência
Vivo (AS26599), Claro NET (AS28573) e TIM Live (AS26615) operam servidores DNS próprios com cobertura nacional. Esses servidores geralmente funcionam, mas apresentam instabilidade pontual em horários de pico, especialmente entre 19h e 23h quando o tráfego nos backbones residenciais é maior.
O PTT-SP (IX.br em São Paulo) é o maior ponto de troca de tráfego da América Latina. Cloudflare, Google e Quad9 têm presença nesse ponto, o que significa latência DNS similar ou inferior a do servidor do próprio provedor para usuários em São Paulo e capitais próximas. Para cidades do interior com menor conectividade ao PTT, a diferença pode ser mais expressiva.
| Cidade | Latência DNS provedor (aprox.) | Latência Cloudflare 1.1.1.1 (aprox.) | Latência Google 8.8.8.8 (aprox.) |
|---|---|---|---|
| São Paulo | 5-15 ms | 4-10 ms | 5-12 ms |
| Rio de Janeiro | 8-18 ms | 6-12 ms | 7-14 ms |
| Belo Horizonte | 10-22 ms | 8-16 ms | 9-18 ms |
| Porto Alegre | 12-25 ms | 10-20 ms | 11-22 ms |
| Fortaleza / Recife | 15-30 ms | 12-24 ms | 14-26 ms |
| Manaus / interior Norte | 25-50 ms | 20-40 ms | 22-45 ms |
As medições acima são estimativas baseadas em dados do DNSperf e relatos de comunidades de redes brasileiras. A latência real varia com o provedor específico, o ponto de acesso e o horário. Para medir a latência real no seu caso, use nslookup -debug google.com 1.1.1.1 e observe o campo Query time. Repita o mesmo comando com 8.8.8.8 e com o DNS atual do seu roteador.
Como o cache TTL afeta a frequência de consultas DNS
Cada resposta DNS vem acompanhada de um TTL (Time to Live) que indica por quantos segundos o resultado pode ser armazenado em cache. Um TTL de 300 significa que o registro pode ser reutilizado por 5 minutos sem nova consulta ao servidor. TTLs longos (86400 = 24 horas) reduzem o número de consultas mas atrasam a propagação de mudanças. TTLs curtos (60-300) garantem atualizações rápidas mas aumentam a carga nos servidores e a frequência de consultas.
Para domínios em transição (troca de hosting, mudança de IP), TTLs curtos são comuns temporariamente. Se um site que funcionava normalmente parou de abrir em um dispositivo específico mas outros acessam sem problema, o cache local pode ter capturado uma resposta antiga antes da propagação ser concluída. Limpar o cache DNS resolve nesses casos.
DNS over HTTPS e DNS over TLS no Brasil
Consultas DNS tradicionais viajam em texto claro pela porta 53 UDP/TCP, visível para qualquer elemento na rota entre o dispositivo e o servidor DNS. Dois protocolos modernos criptografam essas consultas: DNS over HTTPS (DoH, porta 443) e DNS over TLS (DoT, porta 853). Cloudflare, Google e Quad9 suportam ambos.
No Windows 11, DoH pode ser configurado diretamente nas propriedades de rede (Configurações > Rede > Propriedades do adaptador > Configurações DNS). No Android 9+, o campo "DNS Privado" nas configurações de rede aceita o hostname do servidor DoT. No iOS, perfis de configuração permitem ativar DoH para todo o dispositivo. Para usuários preocupados com privacidade, DoH adiciona uma camada de proteção contra sniffing DNS sem necessidade de VPN completa.
Verifique qual DNS está respondendo suas consultas agora com a ferramenta consulta DNS. Para comparar desempenho detalhado entre as opções, veja DNS Google vs Cloudflare vs Quad9 e melhores DNS públicos.
Como evitar que DNS não responda no futuro
A maioria dos episódios de "DNS não responde" é evitável com duas medidas preventivas simples: configurar um DNS secundário confiável e manter o roteador atualizado.
Configure sempre um DNS secundário
Dispositivos e roteadores permitem configurar um servidor DNS primário e um secundário. Se o primário não responder dentro do timeout, o sistema usa automaticamente o secundário. Usar servidores de provedores diferentes aumenta a redundância: por exemplo, 1.1.1.1 (Cloudflare) como primário e 8.8.8.8 (Google) como secundário. Mesmo que um dos dois tenha uma instabilidade pontual, o outro garante resolução contínua.
Atualize o firmware do roteador
Firmware desatualizado pode ter bugs que corrompem o cache DNS interno do roteador. Fabricantes como TP-Link, ASUS, Intelbras e Multilaser lançam atualizações periódicas que corrigem problemas de estabilidade. O painel de administração do roteador (geralmente em 192.168.1.1 ou 192.168.0.1) tem a opção de verificar e instalar atualizações.
Considere DNS sobre HTTPS no navegador
Chrome, Firefox e Edge permitem ativar DoH nas configurações de privacidade e segurança. Com DoH ativo, o navegador faz suas próprias consultas DNS criptografadas, ignorando o servidor configurado no sistema operacional. Isso resolve o problema de "DNS não responde" causado por firewall ou antivírus interceptando a porta 53, já que DoH usa a porta 443 que raramente é bloqueada.
A hierarquia do DNS: por que a resolução pode falhar em qualquer ponto
Uma consulta DNS percorre vários níveis antes de retornar um resultado. Entender cada nível ajuda a identificar onde a falha ocorreu quando o DNS não responde por razões específicas de domínio.
O primeiro nível é o cache local do sistema operacional. Se a resposta estiver em cache e for válida, o sistema retorna sem consultar nenhum servidor externo. Se não estiver em cache, consulta o resolver configurado (Cloudflare, Google ou do provedor). O resolver verifica seu próprio cache e, se não encontrar, inicia o processo de resolução recursiva.
A resolução recursiva parte dos servidores raiz (13 conjuntos de endereços anycast ao redor do mundo, operados por ICANN, verisign, RIPE, entre outros). Os servidores raiz redirecionam para os servidores TLD (.com, .net, .br, .org). Os servidores TLD redirecionam para os servidores autoritativos do domínio específico. Esses servidores autoritativos são operados pelo dono do domínio ou pelo registrador.
Uma falha em qualquer elo dessa cadeia pode causar "DNS não responde". Quando o problema é em um domínio específico (e não em todos), a causa geralmente está no servidor autoritativo do próprio domínio ou em problemas de propagação DNS. Isso é externo ao seu controle, e o correto é aguardar ou contactar o dono do domínio.
TTL negativo e NXDOMAIN em cache
Quando um resolver recebe uma resposta NXDOMAIN (domínio não existe), ele armazena essa resposta negativa em cache pelo tempo definido no TTL negativo (geralmente de 30 segundos a 5 minutos). Isso significa que mesmo após o problema ser corrigido no servidor autoritativo, o resolver ainda pode retornar NXDOMAIN por alguns minutos para usuários que fizerem a consulta nesse intervalo.
Limpar o cache DNS local não ajuda nesses casos se o resolver escolhido (1.1.1.1 ou 8.8.8.8) ainda tiver a resposta negativa em cache. Para contornar, troque temporariamente para um servidor DNS diferente que ainda não tenha cacheado o NXDOMAIN, como Quad9 (9.9.9.9).
Diagnóstico com dig (Linux/macOS)
O comando dig oferece muito mais detalhe que o nslookup para diagnosticar problemas de DNS. Exemplo:
dig @1.1.1.1 domínio.com.br +shortRetorna apenas o IP, útil para confirmar se o resolver está resolvendo o domínio. Para verificar diretamente o servidor autoritativo:
dig NS domínio.com.brPara seguir toda a cadeia de delegação e ver onde a resolução falha:
dig +trace domínio.com.br
No Windows, o dig não vem instalado por padrão, mas está disponível via BIND para Windows ou pelo Windows Subsystem for Linux (WSL). O nslookup com opção -debug oferece saída similar no Windows.
Perguntas frequentes
Significa que o servidor DNS configurado no dispositivo ou roteador não retornou resposta para a consulta de nome de domínio. A conexão com a internet pode estar funcionando, mas a tradução de nome para IP falhou. O resultado é que nenhum site abre pelo nome, mesmo com ping para IPs numéricos funcionando normalmente.
Execute ping 8.8.8.8 no terminal. Se responder normalmente mas sites não abrirem pelo nome, o problema é DNS. Se o ping para IP também falhar, a conexão de rede está comprometida e o DNS é consequência, não causa. Nesse caso, verifique cabo, roteador e contate o provedor.
É o código de erro que o Chrome exibe quando o servidor DNS retorna código NXDOMAIN (Non-Existent Domain). Indica que nenhum registro A ou AAAA foi encontrado para o domínio solicitado. Causas comuns: digitação errada no endereço, domínio com registro vencido, ou arquivo hosts local com entrada conflitante. Difere de timeout, onde o servidor não responde; no NXDOMAIN o servidor respondeu dizendo que o domínio não existe.
Em muitos casos, resolve. Quando o cache local tem um registro desatualizado, o sistema continua tentando contato com um IP que não é mais válido para aquele domínio. O comando no Windows é ipconfig /flushdns; no macOS é sudo dscacheutil -flushcache seguido de sudo killall -HUP mDNSResponder; no Linux com systemd é sudo systemd-resolve --flush-caches. Se o problema persistir após limpar o cache, o servidor DNS em si está com problema.
Medições do DNSperf ao longo de 2025 indicam Cloudflare (1.1.1.1) com a menor latência média global, com ponto de presença anycast no IX.br em São Paulo. Google (8.8.8.8) tem desempenho similar para usuários brasileiros próximos de São Paulo e Rio. A diferença prática entre os dois é pequena; ambos costumam ser mais rápidos que o DNS do provedor em horários de pico.
Pode. Softwares de segurança e firewalls corporativos que filtram a porta 53 (UDP e TCP) bloqueiam consultas DNS antes que cheguem ao servidor. O sintoma é que nslookup trava sem resposta mesmo com internet funcionando. Para diagnosticar, desative temporariamente o firewall e repita o teste. Se resolver, configure uma exceção para DNS na porta 53 UDP e TCP.
NXDOMAIN significa que o domínio definitivamente não existe nos servidores autoritativos. SERVFAIL indica que o resolver recebeu a consulta mas não conseguiu completar a resolução por algum erro intermediário, como problema no servidor autoritativo do próprio domínio ou assinatura DNSSEC inválida. Um SERVFAIL em um domínio que funcionava antes pode indicar problema temporário no lado do servidor do site, não no seu dispositivo.
Ajuda quando o problema é no cache DNS do próprio roteador. Muitos roteadores residenciais funcionam como resolvers locais e mantêm cache próprio. Um cache corrompido ou com entradas muito antigas pode causar falhas que afetam todos os dispositivos da rede. Desligar por 30 segundos e religar limpa esse cache.
Resolve para dispositivos que recebem IP via DHCP do roteador. Dispositivos com DNS configurado manualmente continuam usando a configuração manual. Para aplicar o novo DNS a toda a rede, configure no roteador E remova configurações manuais de cada dispositivo, ou aguarde o lease DHCP renovar.
Em termos de privacidade, o DNS do provedor é o que tem mais acesso aos dados de navegação do usuário, já que o provedor vê o tráfego por definição. Provedores brasileiros são obrigados pelo Marco Civil (Art. 13, Lei 12.965/2014) a manter registros de conexão por 12 meses. DNS públicos com política de no-log auditada (Cloudflare, Quad9) reduzem essa exposição, mas o provedor ainda vê que você acessou o servidor DNS de destino.
Use a ferramenta consulta DNS do SaberMeuIP.com.br, que mostra qual servidor DNS está respondendo suas consultas no momento. Também é possível confirmar via nslookup: o campo Server no início da resposta indica qual servidor respondeu. Se ainda aparecer o servidor antigo após a mudança, execute ipconfig /flushdns e aguarde alguns minutos para o sistema usar a nova configuração.
Pode ajudar quando o problema é firewall bloqueando a porta 53 UDP/TCP, já que DoH usa a porta 443 (HTTPS), raramente bloqueada. O Chrome e Firefox têm opção de ativar DoH nas configurações de privacidade e segurança. Cloudflare (1.1.1.1) e Google (8.8.8.8) suportam DoH. Para "DNS não responde" causado por instabilidade do servidor do provedor, trocar o servidor (com ou sem DoH) é a solução direta.
Ferramentas relacionadas
DNS não responde tem solução direta em quase todos os casos residenciais: limpe o cache, troque para um DNS público e reinicie o roteador. Esses três passos resolvem a grande maioria das ocorrências sem necessidade de suporte técnico. Manter um DNS alternativo configurado no roteador evita que uma instabilidade do servidor do provedor derrube toda a rede de uma vez.
Consultar DNS
Leituras Relacionadas
- O que é DNS -- O que e DNS: como funciona a resolução de nomes para IP, hierarquia de servidores, raiz, TLD, autoritativo, cache e impacto na privacidade e velocidade.
- Como mudar DNS -- Como mudar DNS passo a passo: Windows 10/11, macOS, Linux, Android, iOS e roteador. DNS públicos recomendados para o Brasil com instrucoes ilustradas.
- Melhores DNS públicos -- Melhores DNS públicos em 2026: comparativo de Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9, OpenDNS e AdGuard. Velocidade no Brasil, privacidade e filtros.