Como resolver o erro DNS_PROBE_FINISHED_NXDOMAIN

O usuário liga, o site não abre.

A mensagem no navegador diz: "Não foi possível encontrar o endereço IP do servidor." Para quem presta suporte a PMEs, esse cenário é mais comum do que deveria, e, quando o diagnóstico é feito no improviso, ele volta.

O erro DNS_PROBE_FINISHED_NXDOMAIN tem causas variadas: algumas triviais, outras que apontam para falhas sérias de infraestrutura ou até comprometimento de segurança.

Este guia organiza o raciocínio técnico para que você identifique a origem correta e resolva na primeira chamada.

O que significa o erro DNS_PROBE_FINISHED_NXDOMAIN?

O código DNS_PROBE_FINISHED_NXDOMAIN é exibido pelo Google Chrome (e navegadores baseados em Chromium, como o Edge) quando o sistema tentou resolver um nome de domínio e o servidor DNS retornou a resposta NXDOMAIN — abreviação de Non-Existent Domain, ou seja, domínio inexistente.

Na prática: o navegador pediu ao DNS "qual é o IP desse domínio?" e a resposta foi "esse domínio não existe."

O que parece simples esconde uma ambiguidade importante:

o domínio pode existir perfeitamente. O erro NXDOMAIN não indica necessariamente que o site está fora do ar — indica que o servidor DNS consultado não encontrou o registro. As causas vão de um cache desatualizado até uma zona DNS mal configurada ou um bloqueio de firewall.

Diferença em relação a outros erros de DNS:

• DNS_PROBE_FINISHED_NXDOMAIN — o servidor DNS respondeu: domínio não encontrado.
• DNS_PROBE_FINISHED_NO_INTERNET — sem conectividade com a internet.
• DNS_PROBE_FINISHED_BAD_CONFIG — configuração de DNS inválida no dispositivo.
• ERR_CONNECTION_TIMED_OUT — o servidor DNS não respondeu (timeout).

Identificar qual erro está ocorrendo já delimita o diagnóstico.

Principais causas do erro

Antes de sair aplicando correções, vale localizar onde está o problema. As causas mais comuns em ambientes de PME são:

1. Domínio digitado errado ou inexistente O caso mais óbvio — e o primeiro a ser descartado. Um caractere errado na URL já gera NXDOMAIN.

2. Cache DNS corrompido ou desatualizado O dispositivo ou o servidor DNS armazenou uma resposta antiga (ou inválida). Quando o registro mudou no servidor autoritativo, o cache ainda guarda a versão anterior — incluindo, eventualmente, uma resposta NXDOMAIN que não é mais válida.

3. Servidor DNS configurado incorretamente O roteador, o DHCP ou o dispositivo está apontando para um servidor DNS errado, inacessível ou que não tem autoridade sobre aquele domínio.

4. Falha na resolução interna (DNS split-horizon) Em redes corporativas com domínios internos (ex.: sistemas.empresa.local), o DNS precisa ser configurado para resolver nomes internos separadamente dos externos. Qualquer falha nessa configuração gera NXDOMAIN para domínios que existem — mas só internamente.

5. Bloqueio por firewall ou DNS filtering Uma política de segurança pode estar bloqueando o domínio — seja por categoria, reputação ou regra manual. O resultado para o usuário é idêntico a um NXDOMAIN real.

6. Propagação DNS incompleta Domínio recém-criado ou registro alterado ainda propagando pela internet. Dependendo do TTL configurado, pode levar de minutos a 48 horas.

7. Falha no servidor DNS do ISP O servidor DNS do provedor de internet está com problemas e retornando NXDOMAIN para domínios que existem.

Starti Partners pode ajudar: Se o problema é recorrente em clientes PME e aponta para falhas de DNS filtering ou configuração de firewall, o Starti Partners oferece suporte técnico especializado para MSPs — da infraestrutura ao diagnóstico avançado de rede.

Como diagnosticar o erro? O passo a passo

1. Confirme se o problema é local ou amplo

Antes de qualquer comando, isolem o escopo:

• Teste em outro dispositivo na mesma rede — se funcionar, o problema é no dispositivo original (cache, configuração local)
• Teste com dados móveis (fora da rede do cliente) — se funcionar fora, o problema está na rede local ou no servidor DNS interno
• Acesse via IP direto (se souber o IP do servidor) — se funcionar, confirma que é um problema de resolução DNS, não de conectividade

Esse isolamento evita perder tempo com comandos no lugar errado.

2. Verifique qual servidor DNS está sendo usado

Identifique o servidor DNS configurado. Depois, teste se ele responde:

Se o comando retornar NXDOMAIN, o servidor consultado não encontrou o registro. Se retornar o IP corretamente, o problema está no cache local ou na configuração do navegador.

3. Teste a resolução com um DNS alternativo

Interpretação:

• Resolveu nos DNSs públicos, mas não no DNS da rede → problema está no servidor DNS interno
• Não resolveu em nenhum servidor → o domínio pode não existir, ou a propagação ainda não foi concluída
• Resolveu apenas no DNS interno → configuração de split-horizon, domínio exclusivamente interno

4. Limpe o cache DNS local

Após o flush, tente acessar o domínio novamente. Se resolver, o problema era cache corrompido ou desatualizado.

5. Analise o servidor DNS interno

Se o problema está no servidor DNS da rede (identificado no passo 3):

• Verifique se o registro A ou CNAME existe na zona autoritativa
• Confirme que a zona está corretamente configurada (sem erros de sintaxe)
• Para ambientes com split-horizon: confirme que as zonas interna e externa não estão em conflito
• Verifique os logs do serviço DNS (Windows DNS Server, BIND, Unbound) por erros de carregamento de zona

6. Verifique regras de firewall e DNS filtering

Se o ambiente usa NGFW com inspeção de DNS ou filtro de categorias:

• Acesse os logs do firewall e filtre pelo domínio em questão
• Verifique se há bloqueio por política de segurança, categoria de conteúdo ou reputação de domínio
• Confirme se o bloqueio é intencional ou um falso positivo
• Para testes: desative temporariamente o DNS filtering em um dispositivo de teste (nunca em produção sem autorização)

Visibilidade é tudo: MSPs que gerenciam redes de PMEs com NGFW precisam de visibilidade unificada sobre DNS, tráfego e ameaças para não depender de diagnóstico manual a cada chamado. 

O Starti Partners tem as ferramentas e o suporte técnico para estruturar essa camada de forma escalável.

Soluções por cenário

Dica extra: Para redes com NGFW ativo, antes de alterar qualquer configuração de DNS, consulte as políticas de segurança vigentes. 

Mudanças indevidas no DNS filtering podem abrir brechas sem que ninguém perceba imediatamente.

Como evitar reincidência em ambientes de PME?

Resolver o problema uma vez é o mínimo. Estruturar o ambiente para que não reapareça é o que diferencia o suporte reativo do proativo. As práticas a seguir reduzem significativamente a ocorrência de erros DNS em clientes PME:

Configure DNS redundante via DHCP

Sempre defina servidor DNS primário e secundário. Se o primário falhar, a resolução continua — sem chamado de suporte.

Monitore a disponibilidade do servidor DNS interno

Um servidor DNS fora do ar gera centenas de reclamações simultâneas e raramente é identificado rapidamente. Inclua o DNS no monitoramento de serviços críticos.

Defina TTLs adequados para registros críticos

TTLs muito altos dificultam mudanças rápidas. TTLs muito baixos sobrecarregam o servidor. Para registros de sistemas internos críticos, TTLs entre 300 e 3600 segundos costumam ser um equilíbrio razoável.

Documente as zonas DNS internas

Em ambientes com split-horizon, a falta de documentação é a principal causa de erros após mudanças de infraestrutura. Mantenha um inventário atualizado das zonas e dos registros críticos.

Revise periodicamente as regras de DNS filtering

Falsos positivos acumulam com o tempo. Uma revisão trimestral das regras evita que domínios legítimos de fornecedores ou sistemas do cliente continuem bloqueados sem que ninguém saiba.

Quando o erro DNS aponta para algo maior

Nem todo NXDOMAIN é um problema de configuração. Em alguns casos, ele é sintoma de comprometimento de rede — e ignorar essa possibilidade é um erro grave.

DNS Hijacking

O servidor DNS da rede foi comprometido e está retornando respostas falsas — redirecionando usuários para IPs controlados por atacantes ou simplesmente negando domínios legítimos para dificultar a resposta a incidentes.

DNS Cache Poisoning

O cache do servidor DNS foi envenenado com registros falsos. O domínio "existe" no cache, mas aponta para o lugar errado.

Exfiltração via DNS

Malwares avançados usam consultas DNS para comunicar dados para servidores externos de comando e controle. Um volume anormal de consultas NXDOMAIN — especialmente para subdomínios aleatórios de um mesmo domínio — é um sinal clássico dessa técnica.

Sinal de alerta: se um domínio que funcionava normalmente começa a retornar NXDOMAIN sem que nenhuma mudança tenha sido feita na rede ou no DNS, investigue antes de aplicar qualquer correção. Pode ser mais do que uma falha de configuração.

Vá além das correções pontuais

O erro DNS_PROBE_FINISHED_NXDOMAIN parece simples na superfície, mas pode mascarar desde uma configuração errada no roteador até um incidente ativo de segurança. 

O diferencial do prestador de TI está em ter um fluxo de diagnóstico claro — e em não confundir o sintoma com a causa.

Para PMEs, onde cada hora de indisponibilidade tem impacto direto na operação, saber diagnosticar rápido e corretamente é parte central do serviço. E ter uma parceria técnica sólida por trás é o que viabiliza escalar esse nível de atendimento sem aumentar proporcionalmente a equipe.

Conheça o Starti Partners e veja como estruturar sua operação de TI para atender PMEs com mais eficiência, segurança e margem.

Eu Quero conhecer o programa →

Starti Group é referência em cibersegurança, proteção de borda, gerenciamento e infraestrutura para PMEs e MSPs no Brasil. Com a vertical Vituax by Starti, o grupo passa a oferecer infraestrutura de nuvem privada de ponta a ponta para o mercado corporativo — com o suporte consultivo que os hyperscalers globais não entregam.