Consulta DNS Grátis
Toda queda, falha de entrega de email ou erro de emissão de certificado começa aqui. Puxe todos os registros DNS de um domínio em uma única requisição — A, AAAA, MX, CNAME, TXT, NS, SOA, CAA — com TTLs e prioridades, para comparar o que deveria estar lá com o que está.
Registros DNS e seu papel na performance e segurança do site
O DNS é a infraestrutura invisível que faz a internet funcionar. Toda visita a um site, email enviado e chamada de API começa com uma consulta DNS. Registros DNS mal configurados ou lentos impactam diretamente a disponibilidade, entregabilidade de emails e performance do seu site.
Problemas de DNS comuns que esta ferramenta ajuda a diagnosticar:
- Registros A ausentes ou incorretos: Se seu registro A apontar para o IP errado, seu site fica inacessível. Após uma migração de servidor, esse é o primeiro item a verificar.
- Configuração incorreta de MX: Registros MX errados fazem emails para o seu domínio serem perdidos. Verifique os valores de prioridade e se todos os servidores de email estão listados.
- SPF/DKIM nos registros TXT: Políticas de autenticação de email ficam em registros TXT. Registros SPF/DKIM ausentes ou mal formados fazem emails legítimos caírem no spam.
- TTL muito alto: TTL muito alto (24–48 horas) torna as mudanças de DNS lentas para propagar, causando downtime prolongado durante migrações de servidor.
- CAA mal configurado: Registros CAA controlam quais CAs podem emitir certificados SSL para o seu domínio. Um registro CAA incorreto pode bloquear a renovação do certificado.
Como interpretar os resultados
Cada tipo de registro responde a uma pergunta diferente. Leia na ordem:
- NS — quem é autoritativo para a zona? Se não bate com o que o registrador mostra, o domínio está sendo servido de um lugar que você talvez não controle.
- A / AAAA — para qual IP o domínio resolve? Compare com o IP do painel de hospedagem. Divergência = propagação em andamento ou zona editada no provedor errado.
- CNAME — o hostname é um alias? CNAME no apex (seudominio.com) é inválido pela RFC 1035; use ALIAS/ANAME ou A. Cadeia de CNAMEs acima de 2–3 saltos atrasa cada lookup.
- MX — para onde o email vai? Prioridade menor ganha. MX ausente ou com typo = bounce. MX obsoleto apontando para servidor desligado = email silenciosamente perdido.
- TXT — tokens de verificação, SPF (v=spf1…), DKIM, DMARC. Mais de um SPF no mesmo nome é violação de spec; consolide.
- CAA — quais autoridades podem emitir certificado. Um CAA
0 issue "letsencrypt.org"bloqueia as demais. Se trocar de CA, ajuste o CAA antes. - SOA — número de série e TTLs. O serial incrementa a cada alteração de zona; compará-lo no tempo confirma se a mudança realmente foi publicada.
- TTL — quanto tempo os resolvers cacheiam a resposta. Baixo = propagação rápida, mais carga no seu nameserver. Alto = mais barato, mais lento para mudar.
Problemas comuns e como resolver
Trocou o A e usuários continuam vendo o IP antigo
Navegador, SO e resolver recursivo estão cacheando o registro anterior até o TTL expirar. Limpe o cache local (ipconfig /flushdns no Windows, sudo dscacheutil -flushcache no macOS) e consulte por um resolver público (1.1.1.1, 8.8.8.8) para pular o cache do ISP.
Emails para o Gmail caindo no spam depois de migrar o domínio
O SPF da zona nova está ausente ou não inclui o novo serviço de envio. Confira que o TXT começa com v=spf1, inclui todas as origens de envio e existe apenas um registro SPF no domínio.
Renovação Let's Encrypt falhando com "CAA record prevents issuance"
Um CAA foi adicionado (muitas vezes por script de hardening) listando outra CA. Inclua 0 issue "letsencrypt.org" ou remova a entrada conflitante.
CNAME no apex não resolve
A RFC não permite CNAME no apex. Use o recurso ALIAS/ANAME/CNAME flattening do seu provedor — ou um registro A direto para o IP.
Próximos passos
DNS é a dependência silenciosa: quando quebra, tudo parece quebrado. Depois de confirmar que os registros estão ok agora, o passo seguinte é pegar drift antes que custe email ou uptime.
- Baixe o TTL para 300s pelo menos 48 horas antes de qualquer mudança planejada, e suba de volta depois.
- Tire um snapshot da zona atual (export para arquivo) como baseline conhecida para diff.
- Ative monitoramento de mudanças DNS no FlashMon.app — qualquer edição inesperada em A, MX ou NS dispara alerta, que é como a maioria dos sequestros de DNS é pega cedo.
Monitore mudanças de DNS automaticamente
Receba alertas instantâneos quando qualquer registro DNS do seu domínio mudar — detecte erros antes que causem downtime.
Perguntas Frequentes
DNS (Domain Name System) é a lista telefônica da internet — traduz nomes de domínio legíveis por humanos como exemplo.com em endereços IP como 93.184.216.34, que os computadores usam para rotear tráfego. Quando você digita uma URL no navegador, seu sistema consulta uma cadeia de resolvedores DNS: primeiro o cache local, depois um resolvedor recursivo (geralmente do seu ISP ou do Google/Cloudflare), que contata os servidores raiz, depois os servidores de domínio de nível superior (ex: .com.br), e finalmente os nameservers autoritativos do domínio para obter a resposta final. Todo esse processo normalmente se completa em menos de 100ms.
Registros DNS são instruções armazenadas nos nameservers autoritativos. Os tipos mais importantes: registros A mapeiam um domínio para um endereço IPv4. Registros AAAA mapeiam para IPv6. Registros CNAME criam aliases apontando um nome para outro. Registros MX identificam quais servidores de email aceitam mensagens para o domínio, com valores de prioridade (menor = preferido). Registros TXT armazenam texto arbitrário — usados para verificação de propriedade de domínio, políticas SPF anti-spam e autenticação DKIM de email. Registros NS identificam quais nameservers são autoritativos para o domínio. Registros SOA contêm metadados da zona, incluindo o nameserver primário, contato do admin e parâmetros de temporização de cache. Registros CAA especificam quais autoridades certificadoras podem emitir certificados SSL para o domínio.
TTL (Time to Live) é um valor nos registros DNS que indica aos resolvedores e caches por quanto tempo armazenar o registro antes de solicitar uma cópia atualizada do nameserver autoritativo. Um TTL de 3600 significa que os caches manterão o registro por 1 hora. O TTL é muito importante ao fazer mudanças de DNS: se seu registro A tem um TTL de 86400 (24 horas), alterar o IP do servidor pode levar até 24 horas para propagar globalmente, pois todos os caches precisam expirar antes de consultar novamente. Melhor prática antes de uma migração planejada: reduza seu TTL para 300 (5 minutos) pelo menos 48 horas antes, faça a mudança, depois aumente-o novamente após confirmar que tudo funciona.
A resolução DNS adiciona latência a cada nova conexão. Mesmo que as consultas DNS completem em 10–100ms, elas ocorrem antes do handshake TCP, negociação TLS e requisição HTTP — somando-se ao TTFB inicial (Time to First Byte). Estratégias para minimizar o impacto do DNS: use um provedor DNS anycast premium (Cloudflare, AWS Route 53, Google Cloud DNS) que roteia consultas para o servidor mais próximo; reduza o número de domínios de terceiros que sua página carrega (cada um requer uma consulta DNS separada); use prefetching de DNS (`<link rel="dns-prefetch">`) para origens críticas de terceiros; defina TTLs apropriados para maximizar as taxas de acerto do cache; e use DNS-over-HTTPS (DoH) que combina DNS e HTTPS para reduzir round trips.
Nameservers são os servidores DNS que são autoritativos para o seu domínio — eles armazenam os registros DNS reais e respondem às consultas sobre o seu domínio. Quando você registra um domínio, você o aponta para nameservers (geralmente fornecidos pelo seu provedor de DNS ou registrador). Cada domínio deve ter pelo menos dois registros NS para redundância. Nameservers são críticos: se ficarem offline ou estiverem mal configurados, ninguém consegue resolver seu domínio e todo o seu site fica inacessível. Sites corporativos grandes geralmente usam provedores DNS premium com SLAs de 100% de uptime e roteamento anycast para máxima disponibilidade e velocidade. O FlashMon monitora a disponibilidade dos nameservers continuamente.
A propagação DNS refere-se ao tempo que leva para registros DNS atualizados se espalharem para todos os resolvedores do mundo. Após uma mudança, a propagação se completa quando os registros armazenados em cache anteriores expiram (com base no TTL antigo) e os resolvedores buscam os novos valores. Você pode verificar a propagação consultando DNS de várias localizações geográficas e comparando os resultados — se algumas localidades retornam o IP antigo e outras o novo, a propagação ainda está em progresso. Ferramentas comuns incluem usar múltiplos resolvedores DNS (Google 8.8.8.8, Cloudflare 1.1.1.1, o resolvedor do seu ISP) para comparar respostas. A propagação completa normalmente leva minutos a horas — raramente mais de 48 horas. O monitoramento do FlashMon detecta mudanças de DNS automaticamente e notifica você no momento em que uma mudança é detectada.
Três causas comuns. Primeiro, a propagação não é instantânea — mesmo com TTL 300s, resolvers intermediários ainda podem responder o valor antigo. Consulte diretamente seus nameservers autoritativos (dig @ns1.seudns.com seudominio.com A) para confirmar que o registro está vivo na origem. Segundo, o registro foi adicionado na zona errada — por exemplo, no apex seudominio.com quando a zona ativa é de um subdomínio registrado à parte. Terceiro, alguns painéis aceitam o salvamento antes de persistir; atualize a página e confirme que a alteração continua lá depois de alguns minutos.
Não precisa, mas publicar um AAAA sem realmente servir IPv6 pode piorar: clientes dual-stack tentam IPv6 primeiro, dão timeout e caem para IPv4 — adicionando segundos ao TTFB em redes móveis. Publique A e AAAA com o mesmo serviço por trás, ou publique só A. Nunca publique AAAA apontando para um host inacessível.
SPF tem limite rígido de 10 lookups DNS por avaliação. Cada include: (Google, Microsoft 365, Mailgun, Salesforce, etc.) conta, e esses includes podem gerar lookups próprios. Passar de 10 gera permerror e servidores receptores podem tratar seu email como não autenticado. Achate includes pouco usados, substitua cadeias por IPs explícitos quando o fornecedor publicar, ou use um serviço de SPF flattening.
É assim que MX funciona — aponta para um hostname, e o servidor receptor resolve esse hostname para um A/AAAA. Essa indireção permite que provedores (Google Workspace, Microsoft 365, Zoho) troquem de IP sem forçar todos os clientes a atualizar DNS. Confira se o hostname de fato resolve para um IP vivo e se as prioridades estão corretas (menor = preferido).