Como Rastrear a Resolução DNS: Depure Consultas com dig e nslookup
Aprenda a rastrear uma resolução DNS passo a passo com dig +trace, nslookup e drill. Depure NXDOMAIN, consultas lentas e problemas de propagação com exemplos práticos.
Quando um domínio não consegue ser resolvido, carrega lentamente ou retorna um IP inesperado, a causa raiz quase sempre está em alguma parte da cadeia de resolução DNS. Uma única consulta ao seu resolvedor local oculta o que realmente aconteceu — quais servidores de nomes foram consultados, quais responderam e onde a cadeia quebrou. Para ver toda a história, você precisa de um rastreamento DNS.
Este guia mostra como rastrear uma resolução DNS de ponta a ponta usando ferramentas padrão, interpretar a saída e diagnosticar os modos de falha mais comuns.
O que é um Rastreamento DNS?
Um rastreamento DNS é uma caminhada passo a passo pelo resolução recursiva de um nome de domínio, começando pelos servidores de nomes raiz e seguindo a cadeia de delegação até o servidor de nomes autoritativo do domínio. Diferente de uma consulta padrão que retorna apenas a resposta final, um rastreamento mostra cada consulta intermediária e resposta, tornando possível identificar exatamente onde uma resolução falha ou se comporta de forma incorreta.
Como Funciona a Resolução DNS (Guia Rápido)
Cada resolução de domínio segue a mesma hierarquia:
- Servidores de nomes raiz (
.) — 13 servidores lógicos que sabem quais servidores de nomes lidam com cada TLD (domínio de nível superior). - Servidores de nomes TLD (
.com,.org,.fr, …) — delegam aos servidores de nomes autoritativos do domínio registrado. - Servidores de nomes autoritativos — possuem os registros reais (A, AAAA, MX, TXT, …) do domínio.
Um resolvedor recursivo (seu DNS do ISP, 1.1.1.1, 8.8.8.8, Pi-hole, etc.) percorre essa cadeia em seu nome e armazena em cache os resultados. Quando você rastreia a resolução por conta própria, você pula o cache e observa o caminho de delegação bruto.
Executando um Rastreamento DNS com dig
O comando dig (parte do bind-utils no Linux, bind9-dnsutils no Debian/Ubuntu, e enviado por padrão no macOS) é a ferramenta padrão para depuração DNS. Sua flag +trace executa um rastreamento recursivo completo desde a raiz:
dig +trace example.com
A saída lista, para cada nível, os servidores de nomes consultados e suas respostas. Um rastreamento típico para example.com fica assim:
;; global options: +cmd
. 86400 IN NS a.root-servers.net.
. 86400 IN NS b.root-servers.net.
...
;; Received 811 bytes from 192.168.1.1#53(192.168.1.1) in 4 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
...
;; Received 1174 bytes from 198.41.0.4#53(a.root-servers.net) in 12 ms
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.
;; Received 289 bytes from 192.5.6.30#53(a.gtld-servers.net) in 24 ms
example.com. 86400 IN A 93.184.216.34
;; Received 56 bytes from 199.43.135.53#53(a.iana-servers.net) in 18 ms
Cada bloco mostra a delegação naquele nível, o TTL, o servidor de nomes que respondeu e o tempo de consulta. O bloco final contém a resposta autoritativa.
Alternativas: nslookup e drill
nslookup (disponível em todos os lugares, incluindo Windows) é mais simples, mas menos flexível. Ele não suporta um rastreamento recursivo, mas você pode consultar manualmente cada nível:
nslookup -type=NS com.
nslookup -type=NS example.com. a.gtld-servers.net
nslookup example.com. a.iana-servers.net
drill (do ldns) é uma substituição moderna para dig com saída mais limpa e melhor suporte ao DNSSEC:
drill -T example.com
No Windows, Resolve-DnsName no PowerShell é o equivalente moderno, embora não produza um rastreamento por si só.
Interpretando a Saída do Rastreamento
Três campos importam ao interpretar um rastreamento:
- TTL (primeiro número) — quanto tempo o registro pode ser armazenado em cache. Um TTL muito baixo (menos de 60 s) frequentemente indica balanceamento de carga ou uma mudança recente; um TTL alto (24 h+) significa que as mudanças se propagam lentamente.
- Fonte do servidor de nomes (
from X.X.X.X#53(hostname)) — quem respondeu em cada etapa. Se o mesmo servidor de nomes aparece em vários níveis, algo está mal configurado. - Tempo de consulta (
em N ms) — latência para cada servidor de nomes. Um hop lento pode adicionar centenas de milissegundos a toda resolução não em cache.
Problemas Comuns de DNS e Como Detectá-los
- NXDOMAIN — o servidor de nomes autoritativo retorna "nome não existe". Verifique erros de digitação, domínios expirados ou delegação incorreta no nível do TLD.
- SERVFAIL — um servidor de nomes na cadeia está inacessível ou retornando respostas malformadas. Execute o rastreamento duas vezes: se o servidor que falha muda, o problema é transitório; se for consistente, o problema está nesse servidor específico.
- Resolução lenta — observe os tempos de consulta por nível. Uma consulta lenta na raiz ou TLD é rara e sugere problemas na rede local. Uma consulta lenta ao servidor autoritativo indica problema com o operador do domínio.
- Dados desatualizados — se um rastreamento mostra o IP correto, mas seu navegador acessa um antigo, seu resolvedor recursivo ainda está em cache. Limpe com
sudo resolvectl flush-caches(systemd-resolved),sudo dscacheutil -flushcache(macOS) ouipconfig /flushdns(Windows). - Problemas de propagação — após uma mudança de DNS, resolvers diferentes veem valores diferentes até que os TTLs expirem. Consulte vários resolvers públicos (
1.1.1.1,8.8.8.8,9.9.9.9) para verificar a consistência. - Delegação inadequada — um TLD delega para servidores de nomes que não respondem de forma autoritativa para a zona. Visível como um
SERVFAILde um ou mais servidores enquanto outros funcionam.
Rastreamento DNS vs Consulta DNS: Conheça a Diferença
Um dig example.com simples atinge seu resolvedor recursivo, retorna a resposta em cache e não informa nada sobre o caminho. Um rastreamento ignora o cache e percorre a cadeia por conta própria. Use uma consulta para verificar o resultado; use um rastreamento para depurar o processo.
Quando Rastrear Não É Suficiente
DNS é apenas metade de uma conexão. Uma vez que um nome é resolvido, seus pacotes ainda precisam encontrar o servidor através de redes roteadas por BGP. Se o DNS retornar o IP correto, mas o serviço estiver inacessível ou lento, execute um traceroute para o endereço resolvido para ver onde a rota de rede falha. Ferramentas como TraceMapper combinam ambas as perspectivas: resolvem o hostname e visualizam o caminho da rede hop por hop, para que você possa descartar problemas de DNS e focar na rota real.
Principais Conclusões
- Use
dig +trace(oudrill -T) para percorrer toda a cadeia de delegação desde a raiz até o servidor de nomes autoritativo. - Verifique TTLs, fontes dos servidores de nomes e tempos de consulta em cada nível para identificar qual hop apresenta problema.
NXDOMAIN,SERVFAILe hops lentos indicam diferentes classes de problemas — delegação, saúde do servidor de nomes ou latência.- Limpe caches locais e consulte múltiplos resolvers públicos ao diagnosticar problemas de propagação.
- Após descartar problemas de DNS, um traceroute no IP resolvido completa o quadro de diagnóstico.