Servidor DNS Não Responde: Guia Completo de Solução de Problemas

Um erro de "servidor DNS não responde" significa que o seu sistema operativo enviou uma consulta de resolução para um resolvedor DNS e não recebeu resposta dentro do período de tempo limite — portanto, o navegador nunca obteve o endereço IP necessário para abrir uma ligação TCP. O resultado é uma falha no carregamento da página, mesmo quando a sua ligação de rede física está totalmente operacional. A causa raiz pode estar em qualquer ponto da cadeia de resolução: o seu resolvedor stub local, o resolvedor recursivo do seu ISP, um servidor autoritativo upstream, ou um dispositivo de rede mal configurado entre si e qualquer um deles.

Este guia percorre cada camada dessa cadeia — desde um reinício do router de 30 segundos até à substituição de drivers de baixo nível — com comandos exatos para Windows, macOS e Linux, além de uma comparação de resolvedores públicos e uma matriz de decisão para ajudá-lo a isolar a falha rapidamente.

O Que Acontece Realmente Durante a Resolução DNS

Antes de corrigir o erro, compreender o caminho de resolução evita esforço desperdiçado. Quando escreve example.com num navegador:

1. O SO verifica a sua cache DNS local (e o ficheiro hosts).
2. Se não existir nenhum registo em cache, o resolvedor stub encaminha a consulta para o resolvedor recursivo configurado na interface de rede (normalmente o seu router ou um servidor atribuído pelo ISP).
3. O resolvedor recursivo percorre a hierarquia DNS — servidores raiz, servidores de nomes TLD, servidores de nomes autoritativos — e devolve o registo A ou AAAA final.
4. O SO coloca o resultado em cache durante a duração do TTL do registo e passa o IP para o navegador.

Um erro de "não responde" normalmente ocorre no passo 2 ou 3. O resolvedor stub enviou um pacote UDP para a porta 53 e obteve silêncio. Esse silêncio tem um número surpreendentemente grande de causas.

Causas Raiz do Erro de Servidor DNS Não Responde

Falhas do Lado do Resolvedor DNS

• O resolvedor recursivo configurado está temporariamente sobrecarregado ou offline.
• A infraestrutura DNS do seu ISP está sob um ataque DDoS ou em manutenção.
• O endereço IP do resolvedor mudou, mas o seu dispositivo ainda mantém o valor antigo.

Problemas de Rede Local e Hardware

• Bugs no firmware do router que corrompem o relay DNS (comum em dispositivos de consumo após longos períodos de funcionamento).
• Uma concessão DHCP que forneceu um endereço de servidor DNS desatualizado ou inválido.
• Um cabo Ethernet defeituoso ou um sinal Wi-Fi degradado que causa perda de pacotes especificamente na porta UDP 53.

Configurações Incorretas ao Nível do Host

• Uma cache DNS local corrompida ou envenenada contendo respostas negativas desatualizadas.
• Um endereço DNS introduzido manualmente que está errado ou já não é acessível.
• Uma entrada no ficheiro hosts que entra em conflito com a resposta DNS esperada.

Interferência de Software de Segurança

• Firewalls ou ferramentas de segurança de endpoint que bloqueiam a porta UDP/TCP 53 de saída ou intercetam consultas DNS para inspeção e depois descartam-nas.
• Clientes VPN que redirecionam o tráfego DNS através de um endpoint de túnel que está atualmente inacessível.
• Software de controlo parental que atua como proxy DNS local e falha silenciosamente.

Problemas de Driver e ao Nível do SO

• Um driver NIC desatualizado ou corrompido que trata incorretamente datagramas UDP.
• O serviço DNS Client do Windows (Dnscache) num estado bloqueado.
• Um processo mDNSResponder do macOS que consumiu memória excessiva e parou de responder.

Correções Passo a Passo: Ordenadas por Esforço e Probabilidade

Siga estes passos por ordem. Cada passo demora menos de cinco minutos e elimina uma camada específica do problema.

Passo 1: Verificar Primeiro o Âmbito do Problema

Antes de alterar qualquer definição, execute um diagnóstico rápido para confirmar que o DNS é realmente o ponto de falha e não a conectividade geral:

# Windows — ping a known IP directly (bypasses DNS entirely)
ping 8.8.8.8

# Windows — attempt a DNS lookup explicitly
nslookup example.com

# macOS / Linux
ping -c 4 8.8.8.8
dig example.com

Se ping 8.8.8.8 tiver êxito mas nslookup example.com falhar, a resolução DNS é definitivamente o problema. Se ping 8.8.8.8 também falhar, o problema é mais profundo — provavelmente roteamento ou conectividade física — e o DNS é um sintoma, não a causa.

Passo 2: Reiniciar o Router e o Modem

Um ciclo de energia limpa a cache de relay DNS interno do router, repõe as concessões DHCP e restabelece a ligação WAN com novas atribuições de servidor DNS do seu ISP.

1. Desligue o cabo de alimentação tanto do modem como do router.
2. Aguarde 30 segundos completos (os condensadores precisam de tempo para descarregar).
3. Ligue primeiro o modem; aguarde que sincronize completamente (luz WAN estável).
4. Ligue depois o router; aguarde que complete a sequência de arranque.
5. Volte a ligar o seu dispositivo e repita o teste nslookup do Passo 1.

Caso especial: Se o seu router estiver em funcionamento há semanas sem reiniciar, o seu relay DNS (dnsmasq ou similar) pode ter a cache cheia ou uma fuga de memória. Alguns routers fornecidos pelo ISP têm bugs conhecidos em que o relay DNS para de encaminhar consultas após um determinado limiar de tempo de funcionamento. Um reinício é a correção mais rápida.

Passo 3: Limpar a Cache DNS Local

Entradas de cache desatualizadas ou corrompidas fazem com que o SO devolva resultados incorretos ou gere falhas de pesquisa antes mesmo de uma consulta sair da máquina.

Windows:

ipconfig /flushdns

Deverá ver: Successfully flushed the DNS Resolver Cache.

macOS (específico por versão — utilize o comando correto para o seu SO):

# macOS Ventura, Monterey, Big Sur, Catalina
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# macOS Mojave and earlier
sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches
# Verify the cache was cleared
sudo systemd-resolve --statistics | grep "Current Cache Size"

Linux (nscd):

sudo service nscd restart

Passo 4: Mudar para um Resolvedor DNS Público Fiável

Se o resolvedor DNS do seu ISP for o problema, mudar para um resolvedor público bem mantido é a solução alternativa mais rápida. A tabela abaixo compara as opções mais utilizadas:

O Cloudflare 1.1.1.1 mede consistentemente a menor latência média global de consultas em benchmarks independentes. O Quad9 é a melhor escolha se pretender bloqueio passivo de domínios de malware sem gerir um filtro DNS separado.

Alterar DNS no Windows 10/11:

1. Abra Definições > Rede e Internet > Alterar opções do adaptador.
2. Clique com o botão direito no adaptador ativo e selecione Propriedades.
3. Selecione Protocolo Internet Versão 4 (TCP/IPv4) e clique em Propriedades.
4. Selecione Utilizar os seguintes endereços de servidor DNS.
5. Introduza os IPs do resolvedor primário e secundário escolhidos.
6. Clique em OK e depois execute ipconfig /flushdns para limpar entradas de cache desatualizadas.

Para redes IPv6, repita o processo para Protocolo Internet Versão 6 (TCP/IPv6) utilizando os endereços IPv6 do resolvedor (por exemplo, Cloudflare: 2606:4700:4700::1111 e 2606:4700:4700::1001).

Alterar DNS no macOS:

1. Abra Definições do Sistema > Rede.
2. Selecione a sua ligação ativa e clique em Detalhes.
3. Vá ao separador DNS.
4. Remova as entradas existentes com o botão – e adicione os IPs do resolvedor escolhido com +.
5. Clique em OK e Aplicar.

Alterar DNS no Linux (NetworkManager):

# Edit the connection (replace "Wired connection 1" with your connection name)
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"

Passo 5: Reiniciar o Serviço DNS Client (Windows)

O serviço DNS Client do Windows (Dnscache) coloca em cache os nomes resolvidos e gere o resolvedor stub. Se entrar num estado bloqueado, todas as consultas DNS falham silenciosamente.

net stop dnscache
net start dnscache

Em alternativa, através da consola de Serviços: prima Win + R, escreva services.msc, localize DNS Client, clique com o botão direito e selecione Reiniciar. Note que em algumas versões do Windows 11 a opção de reinício está a cinzento na GUI — utilize o método de linha de comandos.

Passo 6: Desativar Temporariamente a Firewall ou Software de Segurança

Firewalls de terceiros e suites de proteção de endpoint por vezes intercetam o tráfego DNS para inspeção e, devido a um conflito de regras ou bug do motor, descartam os pacotes completamente.

Windows Defender Firewall (apenas para teste temporário):

netsh advfirewall set allprofiles state off

Reative imediatamente após o teste:

netsh advfirewall set allprofiles state on

macOS:

Navegue até Definições do Sistema > Privacidade e Segurança > Firewall e desative-a para fins de teste.

Se desativar a firewall resolver o problema, não a deixe desativada. Em vez disso, abra o editor de regras da firewall e procure regras que bloqueiem o tráfego de saída na porta UDP 53 e porta TCP 53. Adicione regras de permissão explícitas para os IPs do resolvedor DNS escolhido.

Os clientes VPN merecem atenção especial aqui. Muitas aplicações VPN instalam um proxy DNS local em 127.0.0.1:53 e redirecionam todas as consultas através do túnel. Se o servidor VPN estiver inacessível, todas as consultas DNS falham. Desconecte a VPN, teste o DNS e depois volte a ligar e verifique as definições de fuga DNS do cliente VPN.

Passo 7: Experimentar um Navegador Diferente

Certas extensões de navegador — particularmente bloqueadores de anúncios, ferramentas de privacidade e plugins de segurança — intercetam consultas DNS-over-HTTPS (DoH) ou modificam o comportamento do resolvedor do sistema. Se o DNS funcionar num navegador mas não noutro, o problema é ao nível da extensão, não ao nível do SO.

Teste primeiro numa janela privada/incógnito (as extensões estão normalmente desativadas). Se isso resolver o problema, desative as extensões uma a uma para identificar a culpada. Se o problema persistir em todos os navegadores, a falha está na camada do SO ou da rede.

Passo 8: Atualizar ou Reverter os Drivers de Rede

Um driver NIC corrompido pode causar tratamento errático de pacotes UDP, o que se manifesta como falhas intermitentes de DNS mesmo quando as ligações TCP funcionam.

Windows — atualizar via Gestor de Dispositivos:

1. Prima Win + X e selecione Gestor de Dispositivos.
2. Expanda Adaptadores de rede.
3. Clique com o botão direito no adaptador e selecione Atualizar driver > Procurar drivers automaticamente.
4. Reinicie após a instalação.

Windows — reverter um driver atualizado recentemente:

Se o erro DNS começou imediatamente após uma Atualização do Windows, o novo driver pode ser a regressão. No Gestor de Dispositivos, clique com o botão direito no adaptador, selecione Propriedades > Driver > Reverter Driver.

macOS: Os drivers NIC estão incluídos no macOS. Aplique todas as atualizações de sistema pendentes em Definições do Sistema > Geral > Atualização de Software.

Linux:

# Check current driver module
lspci -k | grep -A 3 "Network controller"

# Update kernel (which includes driver updates) on Debian/Ubuntu
sudo apt update && sudo apt upgrade linux-image-generic

Passo 9: Verificar as Ligações Físicas de Rede

Se estiver numa ligação com fio, um cabo Ethernet degradado causa perda intermitente de pacotes que afeta desproporcionalmente os protocolos baseados em UDP como o DNS (que não tem retransmissão incorporada na camada de aplicação).

• Reconecte ambas as extremidades do cabo Ethernet.
• Substitua o cabo por um que saiba estar em bom estado.
• Teste uma porta diferente no router ou switch.
• Verifique os LEDs indicadores de ligação do NIC — uma luz verde ou âmbar estável confirma ligação física; uma luz intermitente ou ausente indica um problema de camada 1.

Passo 10: Executar o Solucionador de Problemas de Rede do Windows

O Windows inclui um diagnóstico automatizado que pode detetar e corrigir configurações incorretas comuns de DNS, incluindo a reposição do cliente DNS e a limpeza da cache.

Navegue até Definições > Sistema > Resolução de problemas > Outros solucionadores de problemas > Ligações à Internet e execute o assistente. Tentará reparações automáticas e reportará o que encontrou. Embora não detete todos os cenários, é uma verificação útil que demora menos de um minuto.

Passo 11: Verificar e Editar o Ficheiro Hosts

Um ficheiro hosts corrompido ou modificado maliciosamente pode substituir o DNS para domínios específicos, causando falhas de resolução que parecem idênticas a um erro de servidor DNS.

Windows — abrir com privilégios elevados:

notepad C:WindowsSystem32driversetchosts

macOS / Linux:

sudo nano /etc/hosts

Procure entradas que redirecionem domínios comuns para 0.0.0.0 ou 127.0.0.1. Software de segurança, bloqueadores de anúncios e malware modificam este ficheiro. Remova quaisquer entradas suspeitas, guarde e limpe a cache DNS.

Passo 12: Repor a Pilha TCP/IP e Winsock (Windows)

Se vários componentes de rede estiverem mal configurados, uma reposição completa da pilha é mais rápida do que procurar definições individuais:

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /flushdns
ipconfig /renew

Reinicie a máquina após executar todos os cinco comandos. Isto repõe os parâmetros de registo TCP/IP e o catálogo Winsock para o estado predefinido sem afetar os drivers do adaptador de rede.

Passo 13: Repor o Router para as Predefinições de Fábrica

Utilize isto como último recurso antes de contactar o seu ISP. Uma reposição de fábrica apaga toda a configuração personalizada — SSIDs Wi-Fi, palavras-passe, regras de reencaminhamento de portas e quaisquer definições DNS personalizadas — e restaura o router para o estado de origem.

A maioria dos routers tem um botão de reposição recuado. Mantenha-o premido com um alfinete durante 10–15 segundos até os LEDs de estado ciclarem. Após o router reiniciar, reconfigure a sua rede de raiz. Se o DNS funcionar imediatamente após a reposição, uma definição de router mal configurada era a causa.

Passo 14: Contactar o Seu ISP

Se todos os passos acima falharem e o problema afetar todos os dispositivos na sua rede, o problema está quase certamente a montante do seu router — seja na infraestrutura de resolvedor recursivo do ISP ou na própria ligação WAN. Contacte o suporte técnico do seu ISP com as seguintes informações prontas:

• Resultados de nslookup example.com utilizando tanto o DNS do seu ISP como um resolvedor público como 8.8.8.8.
• Se o problema é intermitente ou constante.
• Se mudar para um hotspot móvel (contornando completamente o seu ISP) resolve o problema.

Este último teste é a verificação definitiva de isolamento do ISP.

Configuração DNS para Administradores de Servidores

Se gerir um ambiente de Alojamento VPS ou um Servidor Dedicado, os erros DNS assumem dimensões adicionais. Um resolvedor mal configurado num servidor afeta todas as aplicações que nele correm — servidores web, entrega de correio eletrónico, gestores de pacotes e agentes de monitorização dependem todos de resolução de nomes fiável.

Verificar a configuração do resolvedor em servidores Linux:

cat /etc/resolv.conf

Um ficheiro saudável deve conter pelo menos duas linhas nameserver apontando para resolvedores fiáveis:

nameserver 1.1.1.1
nameserver 8.8.8.8

Em sistemas que utilizam systemd-resolved, /etc/resolv.conf é um symlink. Editá-lo diretamente não tem efeito. Utilize resolvectl em vez disso:

resolvectl status
resolvectl dns eth0 1.1.1.1 8.8.8.8

Testar a latência de resolução a partir de um servidor:

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

Se os tempos de consulta excederem consistentemente 200ms, o resolvedor está geograficamente distante ou sob carga. Mude para um resolvedor com um ponto de presença mais próximo do centro de dados do seu servidor.

Para servidores que executam ambientes cPanel VPS, a configuração DNS também é gerida através da página Configuração Básica do cPanel & WHM no WHM. Certifique-se de que os resolvedores listados aí correspondem ao que está em /etc/resolv.conf para evitar problemas de resolução split-brain.

DNS e Registo de Domínios: A Ligação Upstream

Um erro de "servidor DNS não responde" no seu próprio domínio — em vez do de outra pessoa — muitas vezes tem origem na configuração dos servidores de nomes ao nível do registador. Se registou recentemente um domínio ou alterou os servidores de nomes através do Registo de Domínios, a propagação demora até 48 horas. Durante esse período, alguns resolvedores ao redor do mundo ainda mantêm os registos NS antigos.

Utilize um verificador de propagação ou consulte diretamente múltiplos resolvedores geograficamente distribuídos:

# Query authoritative nameservers directly, bypassing cache
dig +trace example.com

# Check what specific resolvers currently return
dig @1.1.1.1 example.com NS
dig @8.8.8.8 example.com NS
dig @208.67.222.222 example.com NS

Discrepâncias entre respostas de resolvedores durante a propagação são normais. Se as respostas ainda forem inconsistentes após 48 horas, os registos NS no registador estão provavelmente mal configurados.

Proteger o DNS: DNSSEC e DNS-over-HTTPS

As consultas DNS padrão viajam em texto simples pela porta UDP 53, tornando-as vulneráveis a ataques de spoofing DNS e envenenamento de cache. Duas tecnologias complementares abordam isto:

DNSSEC adiciona assinaturas criptográficas aos registos DNS, permitindo que os resolvedores verifiquem que uma resposta é autêntica e não foi adulterada. Protege a integridade dos dados, mas não encripta a própria consulta.

DNS-over-HTTPS (DoH) e DNS-over-TLS (DoT) encriptam toda a consulta DNS, prevenindo escutas e manipulação no caminho. Os navegadores modernos suportam DoH nativamente. Para ativá-lo em todo o sistema no Windows 11, navegue até Definições > Rede e Internet > [o seu adaptador] > Atribuição de servidor DNS > Editar e defina a encriptação para Apenas encriptado (DNS over HTTPS).

Para servidores, configure systemd-resolved para utilizar DoT:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes
DNSSEC=yes

sudo systemctl restart systemd-resolved

Se estiver a executar Alojamento de Email ou a gerir o seu próprio servidor de correio, a configuração DNS correta — especificamente os registos SPF, DKIM e DMARC — é crítica para a entregabilidade. As falhas de DNS num servidor de correio não quebram apenas a navegação de saída; causam email diferido ou devolvido e falha na validação de certificados TLS.

Certificados SSL e Dependência de DNS

A emissão e renovação de certificados TLS dependem inteiramente do DNS. As Autoridades de Certificação que realizam validação de domínio (DV) através do desafio ACME DNS-01 devem resolver o registo TXT _acme-challenge do seu domínio. Se o DNS estiver quebrado no momento da renovação, ferramentas automatizadas como o Certbot falharão silenciosamente, e os seus Certificados SSL expirarão — derrubando o HTTPS com eles.

Configure monitorização tanto para a resolução DNS como para a expiração de certificados. Uma verificação simples baseada em cron:

# Check days until certificate expiry
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -dates

Matriz de Decisão: Isolar a Camada de Falha DNS

Utilize esta matriz para identificar a camada de falha antes de gastar tempo em correções que não se aplicam à sua situação.

Lista de Verificação de Pontos-Chave Técnicos

• Execute ping 8.8.8.8 primeiro. Se falhar, o DNS não é o seu problema principal — corrija primeiro o roteamento ou a conectividade física.
• Limpe sempre a cache DNS local após alterar as definições do resolvedor; entradas desatualizadas mascarão se a correção funcionou.
• Mude para o Cloudflare 1.1.1.1 ou Quad9 9.9.9.9 como primeira alteração de resolvedor — ambos são mais rápidos e fiáveis do que a maioria dos resolvedores ISP.
• No Windows, se a GUI de Serviços apresentar a opção de reinício do DNS Client a cinzento, utilize net stop dnscache && net start dnscache a partir de uma linha de comandos elevada.
• Em servidores Linux, nunca edite /etc/resolv.conf diretamente em sistemas systemd-resolved — as alterações são substituídas no reinício da rede. Utilize resolvectl ou nmcli.
• Os clientes VPN são frequentemente culpados silenciosos. Teste sempre com a VPN desligada antes de escalar.
• Para os seus próprios domínios, dig +trace contorna todas as caches e mostra exatamente o que os servidores autoritativos estão a devolver — utilize-o antes de assumir um problema de resolvedor.
• Ative a validação DNSSEC e DNS-over-TLS/HTTPS em servidores de produção para eliminar toda uma classe de falhas DNS baseadas em spoofing.
• Em servidores, monitorize tanto a saúde da resolução DNS como a expiração de certificados SSL em conjunto — uma falha de DNS fará silenciosamente com que a renovação do certificado falhe dias depois.

Perguntas Frequentes

Por que razão o DNS falha mesmo tendo uma ligação à internet a funcionar?

A resolução DNS utiliza pacotes UDP para a porta 53, que é separada das ligações TCP que o seu navegador utiliza para carregar páginas. Uma regra de firewall, um relay DNS com falha no router, ou um resolvedor em baixo podem bloquear especificamente a porta 53 enquanto deixam todo o outro tráfego sem ser afetado. Execute ping 8.8.8.8 para confirmar a conectividade IP e depois nslookup example.com para confirmar que o DNS é a falha isolada.

É seguro utilizar permanentemente o DNS da Google ou da Cloudflare em vez do resolvedor do meu ISP?

Sim, para a maioria dos utilizadores e casos de uso. Tanto o Google Public DNS como o Cloudflare 1.1.1.1 suportam validação DNSSEC e oferecem SLAs de disponibilidade superiores aos resolvedores ISP típicos. A contrapartida é que as suas consultas DNS são processadas por um fornecedor de infraestrutura de terceiros em vez do seu ISP. A Cloudflare publica uma política estrita de não registo de consultas; a Google retém registos anonimizados por até 48 horas.

Qual é a diferença entre limpar a cache DNS e alterar o servidor DNS?

Limpar a cache elimina os resultados de resolução armazenados localmente, forçando o SO a enviar novas consultas para o resolvedor configurado. Alterar o servidor DNS redireciona para onde essas consultas são enviadas. Se a sua cache contiver uma entrada envenenada ou desatualizada, limpá-la resolve o problema sem alterar o resolvedor. Se o próprio resolvedor estiver em baixo ou lento, alterar o endereço do servidor resolve o problema sem tocar na cache. Na prática, fazer ambos em conjunto após uma falha de DNS é a abordagem mais limpa.

Por que razão nslookup tem êxito mas o navegador ainda mostra um erro de DNS?

Os navegadores utilizam cada vez mais a sua própria implementação de DNS-over-HTTPS, que contorna completamente o resolvedor do SO. Se o endpoint DoH configurado no navegador estiver inacessível, pode falhar mesmo quando o resolvedor do sistema funciona bem. Verifique as definições de privacidade ou segurança do navegador para uma opção de "DNS Seguro" ou "DNS over HTTPS" e desative-a ou aponte-a para um fornecedor DoH acessível.

Como diagnostico problemas de DNS num VPS Linux sem GUI?

Utilize dig, nslookup e resolvectl a partir da linha de comandos. Execute dig @1.1.1.1 example.com para testar um resolvedor específico diretamente, contornando completamente a configuração local. Execute resolvectl status para ver qual resolvedor o sistema está atualmente a utilizar e se o DNSSEC está ativo. Verifique /etc/resolv.conf para confirmar os servidores de nomes configurados e verifique se o ficheiro não é um symlink quebrado com ls -la /etc/resolv.conf.