O que é o Consulta DNS
A Consulta de DNS mostra quais registros um domínio publica hoje, direto nos servidores autoritativos, sem depender do cache do seu computador ou do resolvedor do seu provedor. Você escolhe o tipo de registro — A, AAAA, MX, NS, TXT, CNAME, SOA — ou consulta todos de uma vez. É a ferramenta que responde às três perguntas mais frequentes de quem administra domínio: para qual IP o site está apontando, quem recebe os e-mails deste domínio, e se o registro SPF, DKIM ou o TXT de verificação do Google já propagou. Como o DNS é a primeira etapa de qualquer acesso, quando um registro está errado nada funciona — site, e-mail, painel administrativo — mesmo com servidor perfeitamente configurado.
Como usar o Consulta DNS
Informe o domínio sem http:// nem www (exemplo: centraltools.com.br) e escolha o tipo de registro. Deixe em ALL para ver o panorama completo do domínio. A consulta é feita em tempo real: se você acabou de alterar uma zona no painel do registrador, a diferença entre o que aparece aqui e o que seu computador resolve indica exatamente quanto de propagação ainda falta.
Consulta DNS — Passo a Passo
-
1
Digite o domínio
Use o domínio raiz para registros NS, SOA, MX e TXT. Para registros A ou CNAME de um subdomínio, informe o host completo, como blog.seusite.com.
-
2
Escolha o tipo de registro
A para IPv4, AAAA para IPv6, MX para servidores de e-mail, NS para servidores de nomes, TXT para SPF/DKIM/DMARC e verificações, CNAME para apelidos e SOA para dados da zona.
-
3
Execute a consulta
O resultado vem dos servidores autoritativos do domínio, não do cache local, então reflete o estado atual da zona publicada.
-
4
Compare com o esperado
Confronte o valor retornado com o que você configurou no painel. Divergência significa erro de digitação na zona ou propagação em andamento.
-
5
Avalie o TTL
O TTL indica por quantos segundos resolvedores guardam a resposta em cache. Ele define quanto tempo uma mudança leva para chegar a todos os usuários.
Quando usar o Consulta DNS
- Migração de hospedagem: depois de apontar o domínio para o novo servidor, consulte o registro A para confirmar que o IP publicado é o novo. Enquanto parte dos usuários vê o site antigo, a propagação ainda está em curso — e o TTL antigo diz quanto tempo falta.
- E-mail parando de chegar: a consulta MX mostra qual servidor recebe as mensagens do domínio. Erro de digitação no host, prioridade duplicada ou MX apontando para um provedor já cancelado explicam a maioria dos casos de "não recebo mais e-mail".
- Validação de SPF, DKIM e DMARC: os três vivem em registros TXT. Antes de investigar por que seus e-mails caem em spam, confirme que o SPF existe, que há apenas um registro SPF na zona e que o seletor DKIM responde no host correto.
- Verificação de propriedade em serviços externos: Google Search Console, Microsoft 365, Meta Business e ferramentas de e-mail marketing pedem um TXT de verificação. A consulta confirma se ele já está publicado antes de você clicar em "verificar" e receber erro.
- Diagnóstico de CNAME em CDN e SaaS: Cloudflare, Vercel, Netlify, plataformas de loja e sistemas de suporte entregam um CNAME para apontar. A consulta revela cadeias de CNAME encadeadas e o erro clássico de tentar usar CNAME no domínio raiz.
- Confirmação de delegação: o registro NS mostra quais servidores de nomes respondem oficialmente pelo domínio. Se ele ainda aponta para o registrador antigo, alterações feitas no painel novo simplesmente não têm efeito.
Benefícios do Consulta DNS
Como funciona: explicação técnica
O DNS é um banco de dados distribuído e hierárquico. Quando alguém acessa seusite.com.br, a resolução percorre a hierarquia: o resolvedor pergunta a um servidor raiz quem responde por .br, este indica quem responde por com.br, que aponta os servidores autoritativos do seu domínio — e são eles que finalmente entregam o IP.
Registro A e AAAA. O A associa um nome a um endereço IPv4 e o AAAA a um IPv6. São os registros que fazem o site abrir. Vários registros A para o mesmo nome distribuem tráfego por round-robin, técnica simples de balanceamento que não faz verificação de saúde do servidor.
Registro CNAME. Cria um apelido que aponta para outro nome, não para um IP. Regra crítica: um nome com CNAME não pode ter nenhum outro registro. Por isso o domínio raiz, que obrigatoriamente tem NS e SOA, não aceita CNAME. Provedores contornam isso com registros proprietários como ALIAS, ANAME ou CNAME flattening.
Registro MX. Define quais servidores recebem e-mail do domínio, com um número de prioridade — menor número tem preferência maior. MX 10 é tentado antes de MX 20, que funciona como servidor reserva. O valor de um MX deve ser sempre um nome de host com registro A, nunca um IP nem um CNAME.
Registro TXT. Texto livre, usado hoje principalmente para autenticação de e-mail e verificação de propriedade. O SPF lista quem pode enviar em nome do domínio e o domínio deve ter apenas um registro SPF — dois registros invalidam a política inteira. O DKIM publica a chave pública em seletor._domainkey.seudominio. O DMARC vive em _dmarc.seudominio e diz aos receptores o que fazer quando SPF e DKIM falham.
Registro NS e SOA. O NS delega autoridade sobre a zona e precisa ser idêntico ao configurado no registrador — divergência causa comportamento intermitente. O SOA guarda os metadados da zona: servidor primário, e-mail do responsável, número de serial (que muda a cada edição) e os temporizadores de atualização.
TTL e propagação. Cada registro tem um TTL em segundos. Resolvedores de provedores guardam a resposta por esse tempo antes de perguntar de novo. Não existe "forçar propagação global": a única forma de reduzir o tempo de troca é baixar o TTL antes da mudança. O procedimento correto é reduzir o TTL para 300 segundos, esperar o TTL antigo expirar, executar a alteração e só depois voltar o TTL para um valor alto.
Tipos de registro DNS e para que servem
| Tipo | Função | Exemplo de valor | Onde costuma quebrar |
|---|---|---|---|
| A | Aponta o nome para um IPv4 | 192.0.2.10 | IP do servidor antigo após migração |
| AAAA | Aponta o nome para um IPv6 | 2001:db8::1 | IPv6 configurado sem o serviço escutando nele |
| CNAME | Apelido que aponta para outro nome | loja.plataforma.com | Tentativa de usar CNAME no domínio raiz |
| MX | Servidor que recebe e-mail (menor prioridade vence) | 10 mx.provedor.com | MX apontando para IP ou para CNAME |
| TXT | Texto livre: SPF, DKIM, DMARC, verificações | v=spf1 include:_spf.google.com ~all | Dois registros SPF na mesma zona |
| NS | Delega autoridade sobre a zona | ns1.provedor.com | NS no registrador diferente do NS na zona |
| SOA | Metadados e serial da zona | ns1.provedor.com. admin.dominio. | Serial que não incrementa após edição |
Exemplos práticos de uso
- Site abrindo no servidor errado: após migrar a hospedagem, parte dos visitantes vê a página antiga. A consulta A no autoritativo já mostra o IP novo, mas o TTL do registro anterior era 86400 — ou seja, até 24 horas de cache residual nos provedores.
- E-mails do domínio caindo em spam: a consulta TXT revela dois registros começando com
v=spf1, herdados de dois provedores diferentes. Pela especificação, SPF duplicado resulta em permerror e a política é descartada. A correção é mesclar osincludeem um único registro. - Verificação do Google Search Console falhando: o TXT foi criado no painel como
seudominio.com.br.seudominio.com.brporque o campo já concatena o domínio automaticamente. A consulta expõe o nome duplicado na hora. - CNAME no domínio raiz rejeitado: a plataforma pediu para apontar
meusite.comvia CNAME, mas o painel recusa. Motivo técnico: o apex já tem NS e SOA, e a especificação proíbe coexistência com CNAME. A saída é usar registro ALIAS/ANAME ou apontar um A para o IP indicado. - Alterações no painel sem nenhum efeito: a consulta NS mostra os servidores de nomes do registrador antigo. Todas as edições estavam sendo feitas na zona de um provedor que não é autoritativo pelo domínio.
- DKIM não validando: o provedor informou o seletor
s1, mas a consulta ems1._domainkey.dominionão retorna nada — o registro foi criado sem o sufixo._domainkey.
Como reduzir o tempo de propagação de uma mudança de DNS
Propagação de DNS não é um processo que você acelera depois de iniciado. O tempo é determinado pelo TTL que estava publicado antes da alteração, porque resolvedores do mundo inteiro já guardaram a resposta antiga por aquele período. O roteiro correto tem quatro etapas:
- Reduza o TTL antes. Um ou dois dias antes da migração, baixe o TTL dos registros que vão mudar para 300 segundos.
- Espere o TTL antigo expirar. Se ele era 86400, aguarde 24 horas para que os caches passem a operar com o valor curto.
- Faça a mudança. Com TTL de 5 minutos, a troca alcança praticamente todos os resolvedores em minutos.
- Restaure o TTL alto. Depois de confirmar que tudo funciona, volte para 3600 ou mais, reduzindo consultas e melhorando o tempo de resposta.
Se a mudança já foi feita com TTL alto, não há atalho. Limpar o cache do seu computador (ipconfig /flushdns no Windows) resolve só para você. Trocar seu resolvedor para 8.8.8.8 ou 1.1.1.1 mostra o valor novo mais rápido, mas não altera nada para os visitantes. Nesses casos, mantenha o servidor antigo respondendo durante todo o período de TTL residual.
SPF, DKIM e DMARC: o trio que decide se seu e-mail chega
Desde 2024, Gmail e Yahoo exigem autenticação para remetentes em volume, e provedores rejeitam ou classificam como spam mensagens sem os três mecanismos configurados. Todos vivem em registros TXT.
SPF declara quais servidores podem enviar e-mail em nome do domínio. Fica no domínio raiz, no formato v=spf1 include:_spf.google.com ~all. Duas regras invioláveis: só pode existir um registro SPF na zona, e a resolução completa não pode exceder 10 consultas DNS — cada include consome pelo menos uma. Empilhar provedores de e-mail, CRM e ferramenta de marketing estoura esse limite e causa permerror.
DKIM assina criptograficamente cada mensagem enviada. A chave pública é publicada em seletor._domainkey.seudominio. O seletor é definido pelo provedor de e-mail e cada serviço usa o seu, o que permite ter vários DKIM simultâneos sem conflito — diferente do SPF.
DMARC fica em _dmarc.seudominio e informa ao receptor o que fazer quando SPF e DKIM falham, além de para onde enviar relatórios. Comece sempre com v=DMARC1; p=none; rua=mailto:relatorios@seudominio, analise os relatórios por algumas semanas para descobrir quem envia legitimamente em seu nome, e só então endureça para p=quarantine e depois p=reject. Ir direto para reject sem essa observação costuma bloquear sistemas internos legítimos, como notas fiscais e notificações do ERP.
Erros de DNS que derrubam site e e-mail com mais frequência
MX apontando para IP ou CNAME. O valor de um registro MX precisa ser um nome de host com registro A. IP direto ou CNAME viola a especificação e vários servidores de envio recusam a entrega.
NS divergente entre registrador e zona. Se o registrador delega para um provedor e você edita a zona em outro, as alterações não têm efeito. Sempre confirme o NS autoritativo antes de investigar qualquer outro registro.
Registro criado com o domínio duplicado. A maioria dos painéis concatena o domínio automaticamente no campo nome. Digitar www.seusite.com.br gera www.seusite.com.br.seusite.com.br. Para o subdomínio www, o campo correto contém apenas www.
Cadeia longa de CNAME. CNAME apontando para outro CNAME que aponta para um terceiro aumenta a latência de resolução e alguns resolvedores abandonam a busca. Aponte direto para o destino final.
Registro AAAA órfão. Publicar IPv6 sem que o servidor realmente atenda nesse endereço faz clientes com IPv6 preferencial tentarem primeiro o caminho quebrado, gerando lentidão intermitente difícil de diagnosticar. Se não há suporte real a IPv6, remova o AAAA.
Wildcard mascarando erro de digitação. Um registro * na zona faz qualquer subdomínio responder, inclusive os digitados errado. Isso esconde problemas e pode enviar tráfego legítimo para o destino errado.
É útil para administradores de sistemas, desenvolvedores e suporte técnico diagnosticar problemas de e-mail, apontamento de subdomínios e configurações de DNS.