Um site não abre: diagnosticar pelo Made4DNS
Do relato do assinante até saber de quem é o problema — origem, bloqueio, rede ou cache.
O chamado chega sempre igual: "o site X não abre". Ele pode significar cinco coisas completamente diferentes, e cada uma tem uma ação diferente. Esta página é o caminho mais curto entre o relato e o desfecho — quem tem de agir, você ou outra pessoa.
Todo o percurso é leitura: nada aqui altera configuração.
As ferramentas rodam do servidor, não da sua máquina
Tudo em Sistema → Ferramentas é executado a partir do servidor Made4DNS. É exatamente por isso que elas servem: o que importa no diagnóstico é o que o seu servidor enxerga, não o que o seu notebook enxerga.
Onde clicar, passo a passo
Treze ferramentas em duas fileiras de botões. Clicar num botão troca o formulário logo abaixo — a tela não muda de página, só de ferramenta. Ao abrir, o DIG já vem selecionado.
O que importa entender antes do primeiro clique: tudo aqui é executado a partir do servidor Made4DNS, não do seu navegador. É por isso que o resultado vale como prova: ele responde "o que o meu resolvedor enxerga", que é justamente a pergunta do chamado.
Aqui o DIG já rodou contra globo.com. Três coisas na saída decidem o desfecho:
| Linha | Como ler |
|---|---|
status: NOERROR | O servidor resolveu. NXDOMAIN = o nome não existe; SERVFAIL = falha de resolução |
ANSWER SECTION | A resposta em si. Aqui, globo.com. 17799 IN A 186.192.83.12 — o número do meio é o tempo de vida que ainda resta em cache |
Query time | Quanto demorou. 16 msec é resolução normal; centenas de milissegundos já contam história |
O campo Servidor DNS (opcional) está vazio — e vazio significa consultar este servidor.
Preencha com 8.8.8.8 e rode de novo: comparar as duas saídas é o teste mais informativo da
tela, porque separa "o domínio está quebrado" de "só aqui não funciona".
O selo verde OK e o tempo ao lado do comando são do processo, não da resposta DNS: dizem que a ferramenta rodou, não que o domínio está bom.
Um único campo — Domínio com problema — e o botão Diagnosticar. A caixa azul acima resume o que ele faz sozinho: descobre o autoritativo consultando um DNS público, testa se ele responde para este servidor e, se não responder, roda ping, traceroute e TCP/53 para apontar a causa.
É por isso que ele é o primeiro teste quando o DIG deu falha de resolução: a saída não é dado cru, é o veredito da tabela acima. Não estranhe a demora — com tempos esgotados no caminho, até 2 minutos é normal, e a espera é o próprio teste.
Host / IP, Porta e Protocolo, com atalhos prontos: DNS UDP/53, DNS TCP/53,
DoT/853, DoH/443, HTTP/80, SSH/22. Use o atalho de TCP/53 primeiro.
A frase na caixa azul é o aviso mais importante da tela, e vale ler literalmente: em UDP, a ausência de resposta pode significar porta aberta ou filtrada. Um "sem resposta" em UDP não prova nada; em TCP, conectar ou não conectar é resposta de verdade.
Um campo só: o host ou IP de destino. Rode-o depois do teste de porta, nunca antes — ele responde "onde para", não "se chega".
O que você leva para a operadora é o último salto que respondeu. Se a perda for intermitente, o Traceroute vai enganar: ele é uma foto única. Nesse caso troque para o MTR, o botão ao lado, que acumula estatística por salto.
Domínio e Tipo, e a ferramenta consulta 12 resolvedores públicos espalhados pelo mundo em paralelo, comparando as respostas.
É o teste que fecha o desfecho 5. Se todos respondem igual e igual ao que você vê aqui, o DNS está certo e o problema é do cliente. Se uns respondem o valor novo e outros o antigo, é propagação em curso — normal por minutos, suspeito por horas.
DNS principal → Recursor, seção Recuperação automática de falhas (SERVFAIL). Neste
servidor o interruptor está desligado, e a tela diz por extenso: Inativo — SERVFAILs não são
interceptados.
Confira isso antes de concluir qualquer coisa a partir do DIG. Com o interruptor ligado, o Made4DNS refaz no DNS público toda consulta que ia falhar — então o DIG responde bonito enquanto a sua resolução própria continua quebrada. O sintoma some, a causa fica.
Repare também no Caminho rápido para domínios crônicos, marcado logo abaixo: os domínios que falham repetidamente passam a ir direto ao público. Essa lista, na aba Saúde do Dashboard, é o inventário do que está quebrado e ninguém percebeu.
Antes de começar
O nome exato
loja.example e www.loja.example são nomes diferentes e podem ter destinos diferentes.
Peça o nome como o assinante digitou, não a descrição do site.
O endereço do assinante
Serve para separar "não abre para ninguém" de "não abre para este cliente". Sem ele, metade dos desfechos fica indistinguível.
Desde quando
Minutos, horas ou dias. Mudança recente aponta para publicação e cache; problema antigo e constante aponta para rede ou bloqueio.
Se a recuperação automática de falhas está ligada
Confira em Recursor. Ligada, ela muda o que você vai ver — o motivo está mais abaixo, e vale ler antes de tirar conclusão.
O primeiro teste: Diag. Autoritativo
Em Sistema → Ferramentas, o Diag. Autoritativo faz sozinho o que levaria vários testes manuais: descobre os servidores autoritativos do domínio consultando um DNS público, compara a resolução pública com a deste servidor, sonda cada autoritativo e emite um veredito.
Ele exige perfil de Operador ou Administrador e o alvo fica registrado na auditoria. Com tempos esgotados no caminho, o diagnóstico pode levar até 2 minutos — a demora é o próprio teste, não travamento.
Cada veredito já aponta o desfecho:
| Veredito | Leitura | Desfecho |
|---|---|---|
| Tudo OK | O autoritativo responde e este servidor resolve | 5 — cache do cliente |
| Causa LOCAL | O autoritativo responde, mas a resolução daqui falha | 2 — bloqueio ou política deste servidor |
| ROTEAMENTO | Nem ICMP chega; o caminho morre no meio | 3 — a rede não alcança |
| FIREWALL | O host responde, a porta 53 não | 3 — a rede não alcança |
| UDP/53 sem resposta (TCP abre) | Filtro de UDP no caminho, ou serviço quebrado do outro lado | 3 — a rede não alcança |
| SEM ROTA local | Este servidor não tem rota até nenhum IP do autoritativo | 3 — mas o lado a corrigir é o seu |
| AUTORITATIVO FORA | A porta 53 recusa conexão | 1 — quebrado na origem |
| AUTORITATIVO MAL CONFIGURADO (lame) | Responde, mas sem autoridade sobre a zona | 1 — quebrado na origem |
| AUTORITATIVO diz que o nome NÃO existe | Resposta com autoridade de que o nome não existe | 1 — quebrado na origem |
| Domínio NÃO resolve nem no público | Não delegado, não registrado ou delegação quebrada | 1 — quebrado na origem |
| Sem NS | O DNS público não devolveu nameservers | Confira a grafia e o WHOIS |
| Causas MISTAS | Cada nameserver falhou de um jeito | Leia o resultado servidor a servidor, na própria tela |
| RECUSADO: NS em IP privado | A ferramenta não sonda IP privado, de propósito | Use o DIG apontando o servidor manualmente |
Cada veredito traz junto a evidência crua — as saídas de consulta, ping, traceroute e teste de porta — num bloco expansível. Ela é o que você anexa ao chamado quando precisa acionar outra equipe.
A árvore de decisão
Se preferir conduzir na mão, ou se o Diag. Autoritativo devolveu causas mistas, esta é a ordem que separa os desfechos com o menor número de testes:
O diagrama é o resumo visual — cada saída do primeiro teste leva direto a um desfecho. A lista logo abaixo traz o detalhe de cada ramo.
- O DIG resolve o nome contra este servidor? (campo de servidor vazio consulta o próprio)
- Sim, e a resposta é a esperada.
- Compare com o mundo na ferramenta Propagação.
- Consistente → o DNS está certo. O problema está no cliente, no equipamento dele ou no site em si. É o desfecho 5.
- Inconsistente há poucos minutos → é propagação normal em curso. Aguarde.
- Inconsistente há horas → problema de publicação do domínio: desfecho 1.
- Compare com o mundo na ferramenta Propagação.
- Sim, mas a resposta é diferente da esperada (endereço antigo, ou de bloqueio).
- Endereço antigo → desfecho 5.
- Resposta de bloqueio → desfecho 2.
- Não resolve: volta domínio inexistente.
- O DIG contra um DNS público também diz inexistente → o nome realmente não existe: desfecho 1.
- O público resolve e só aqui dá inexistente → é bloqueio seu: desfecho 2.
- Não resolve: volta falha de resolução (SERVFAIL).
- Rode o Diag. Autoritativo e siga a tabela acima. Os desfechos possíveis são 1 (origem), 3 (rede) ou 4 (política e caminho).
- Não resolve: a consulta simplesmente não volta.
- Se nem o próprio servidor responde a nenhuma consulta, o problema não é este domínio. Comece pela aba Saúde do Dashboard.
- Sim, e a resposta é a esperada.
Consulte o servidor e o mundo, lado a lado
O DIG tem um campo de servidor opcional. Vazio, consulta este servidor; preenchido com um DNS público, consulta o mundo. Comparar as duas respostas é o teste mais informativo da tela — é ele que separa "o domínio está quebrado" de "só aqui não funciona".
Desfecho 1 — o domínio está quebrado na origem
O nome não existe, expirou, perdeu a delegação, ou os servidores autoritativos dele estão fora do ar. Não é problema seu, e não há o que configurar aqui.
Como confirmar:
| Sinal | Onde |
|---|---|
| Veredito de autoritativo fora, lame, NXDOMAIN com autoridade ou domínio não delegado | Diag. Autoritativo |
| O domínio não resolve em nenhum dos resolvedores públicos consultados | Propagação |
| Domínio expirado, sem servidores de nomes, ou em situação de bloqueio no registro | WHOIS |
O que fazer: registre a evidência e responda ao assinante que o defeito é do domínio, não da rede. Se o domínio é de um cliente seu, o caminho é o registrador ou o provedor de hospedagem dele.
Resista à tentação de "resolver" isso ligando o encaminhamento para um DNS público. Um domínio quebrado na origem continua quebrado em qualquer resolvedor — você só perde visibilidade sem ganhar nada. Veja o custo de cada paliativo em o servidor está saudável.
Desfecho 2 — o Made4DNS está bloqueando
O sintoma clássico: o mundo resolve e só o seu servidor não. Três mecanismos produzem isso, e eles se confirmam em telas diferentes.
| Mecanismo | Como confirmar | Onde resolver |
|---|---|---|
| Domínio numa lista de bloqueio, sua ou de terceiros | Verificar na aba Domínios Customizados de Bloqueio de domínios, no modo ao vivo | Bloquear domínios — há a ação de desbloquear |
| Regra de limite de consultas alcançando o cliente | A regra ativa cobre a faixa do assinante | Ajuste o alvo, ou use a lista de liberados |
| DNSSEC quebrado do domínio, com a validação em modo Estrito | Assinatura DNS inválida em Dashboard → Segurança | Recursor, seção de validação DNSSEC |
O modo ao vivo é a única prova
A verificação rápida lê os arquivos de bloqueio; o modo ao vivo resolve de verdade. Um domínio pode estar numa lista e ainda assim responder, ou sair da lista e continuar bloqueado pela resposta guardada em cache. Só o teste ao vivo decide.
Depois de desbloquear, a resposta anterior continua guardada até expirar. Remova aquela entrada em Visualizar cache — não o cache inteiro.
Desfecho 3 — a rede não alcança os autoritativos
Aqui o DNS está certo e a rede é que não entrega. É o desfecho que mais depende de quem opera a rede, e o que mais exige evidência para acionar terceiros.
A sequência é sempre a mesma, e a ordem importa: Porta → Ping → Traceroute/MTR.
Porta
Teste TCP na porta 53 contra o IP do autoritativo. É o teste mais direto: se conecta, o caminho até o serviço existe.
O atalho de porta 53 já está na tela. Use TCP primeiro — em UDP, ausência de resposta não distingue porta aberta de porta filtrada, e o resultado é inconclusivo por natureza do protocolo.
Ping
Se a porta não conecta, o Ping separa dois mundos:
| Resultado | Significa |
|---|---|
| Ping responde, porta 53 não conecta | O host está vivo e há firewall filtrando DNS no caminho |
| Nem o ping responde | O problema é roteamento: o caminho não chega até lá |
Traceroute ou MTR
Mostra onde o caminho morre. O Traceroute dá a foto; o MTR acrescenta estatística por salto, que é o que revela perda intermitente — a que aparece e some, e por isso nunca aparece num teste único.
O último salto que responde é a informação que você leva para a operadora ou para o time de trânsito.
Confirme que o filtro não é seu
Antes de acionar o outro lado, confira o Firewall deste servidor. Um template restritivo aplicado sem os grupos certos produz exatamente o mesmo sintoma de filtro do lado de lá.
TCP abre e UDP não é um caso à parte
Quando a porta 53 conecta em TCP mas as consultas UDP não voltam, o problema é filtro de UDP no caminho — ou o serviço DNS quebrado do outro lado. Não é falha de rota, e o traceroute não vai mostrar nada de errado. O Diag. Autoritativo classifica esse caso separadamente.
Se a sonda apontar sem rota local, o lado a corrigir é o seu: normalmente o autoritativo só tem endereços IPv6 e este servidor não tem conectividade v6. Confira a rota padrão do servidor antes de acionar qualquer outra pessoa.
Com acesso ao terminal do servidor, os mesmos testes em linha de comando:
dig @192.0.2.10 loja.example A +norecursetraceroute -n 192.0.2.10Desfecho 4 — falha de resolução por problema de caminho
Este é o desfecho mais confundido com o anterior, e a diferença é útil: aqui o resolvedor está devolvendo falha de resolução (SERVFAIL) ao assinante mesmo quando parte dos autoritativos responderia.
Onde isso aparece:
| Sinal | Onde olhar |
|---|---|
| Contador de Falha de resolução subindo | Dashboard → Visão Geral |
| Lista de domínios com falha de resolução | Dashboard → Segurança |
| Timeouts Externos crescendo | Dashboard → Saúde |
| Análise de timeouts e falhas, no fim da aba Saúde | Dashboard → Saúde |
Se a falha atinge muitos domínios diferentes ao mesmo tempo, pare de investigar domínio a domínio: o problema é do próprio servidor ou da saída de internet dele. O roteiro é verificar a saúde do servidor, que também traz os paliativos para manter o assinante navegando enquanto a causa é corrigida.
A lista de domínios com falha de resolução traz uma ressalva na própria tela, e ela é literal: não é falha deste servidor. São domínios cujos autoritativos não responderam. Um punhado de nomes ali é normal na internet.
Desfecho 5 — resposta velha em cache
O DNS já está certo e alguém ainda vê o valor antigo. Há três caches possíveis no caminho, e eles se resolvem em lugares diferentes:
| Onde está preso | Como confirmar | O que fazer |
|---|---|---|
| Cache deste servidor | Buscar o nome em Visualizar cache | Remova aquela entrada, não o cache inteiro |
| Cache de resolvedores de terceiros | Propagação: uns respondem o valor novo, outros o antigo | Nada a fazer: expira quando o tempo de vida do registro vence |
| Cache do cliente, do roteador dele ou do navegador | O DIG daqui responde certo e só a máquina dele erra | Orientação ao assinante |
O tempo de vida do registro é decidido antes, não depois
Não existe como forçar um resolvedor de terceiro a esquecer uma resposta. A prevenção é reduzir o tempo de vida do registro antes da mudança planejada, no Editor de registros, e voltar ao valor normal depois que ela assentar.
A recuperação automática de falhas esconde o sintoma
A Recuperação automática de falhas (SERVFAIL), no Recursor, intercepta as resoluções que falhariam e refaz a consulta em DNS públicos configurados. Se o público responde, o assinante recebe a resposta real em vez de um erro.
Para o assinante, isso é ótimo. Para o diagnóstico, é uma armadilha: o sintoma desaparece enquanto a causa continua lá. O domínio "volta a abrir" e ninguém investiga por que a resolução própria falhou.
O que muda no seu roteiro:
| Ferramenta | Com a recuperação ligada |
|---|---|
| DIG contra este servidor | Pode responder normalmente — a resposta veio do público, não da sua recursão |
| Diag. Autoritativo | Continua confiável: ele sonda os autoritativos direto e compara com a resolução local |
| Dashboard → Saúde | O bloco de recuperações de falha mostra quantas resoluções foram resgatadas |
Por isso, quando o assinante reclama de algo que "às vezes funciona":
Abra Dashboard → Saúde e olhe o bloco de recuperações. Se ele estiver vazio, a função está desligada — a tela diz isso.
Veja a lista de domínios em caminho rápido: são os que falham cronicamente e passaram a ser resolvidos direto pelos públicos. Essa lista é um inventário do que está quebrado e ninguém percebeu.
Para cada domínio dessa lista, rode o Diag. Autoritativo e trate pelo desfecho — origem, rede ou política local. A recuperação é rede de proteção, não conserto.
Um volume alto e crescente de resgates é sinal de que a resolução própria está degradada, não de que a função está funcionando bem. O que fazer com isso está em o servidor está saudável.
Quando só um assinante é afetado
Se o DIG daqui resolve certo e o problema é de um cliente só, o DNS já foi descartado. Ainda assim, dá para confirmar de dentro do produto:
Filtre o endereço no registro de consultas e veja se as consultas daquele cliente estão chegando. Lembre que ele trabalha por amostragem — ausência não prova nada.
Confira se a faixa dele está na ACL de recursão. Recusa em volume vindo de endereços seus aparece em Dashboard → Segurança e se resolve em restringir quem usa o resolvedor.
Confira se alguma regra de limite de consultas alcança o endereço dele — principalmente se ele estiver atrás de endereço compartilhado.
Armadilhas
- Testar da sua máquina e concluir sobre o servidor. As duas coisas resolvem por caminhos diferentes. Use as ferramentas do produto, que rodam do servidor.
- Confundir "não existe" com "não resolve". Domínio inexistente e falha de resolução são respostas distintas e apontam para desfechos opostos.
- Ler "porta fechada" em UDP como prova. Em UDP o resultado é inconclusivo por natureza.
- Concluir pelo cache do cliente sem limpar o do servidor — ou o contrário.
- Esquecer a recuperação automática de falhas e concluir que está tudo bem porque o nome resolveu.
- Acionar a operadora sem a evidência. O bloco de evidência crua do Diag. Autoritativo e a saída do MTR são o que fazem o chamado andar do outro lado.
Depois do diagnóstico
| Se o desfecho foi | Vá para |
|---|---|
| Bloqueio deste servidor | Bloquear domínios |
| Lentidão, não falha | O servidor está lento? |
| Falha ampla, muitos domínios | O servidor está saudável? |
| Outro sintoma | Índice de sintomas |