Como diagnosticar problemas de DNS: workflow prático para sysadmins

1. Defina o sintoma antes de alterar DNS

"O DNS está com problema" pode significar coisas diferentes: apenas uma estação não resolve o nome, o resolver da empresa mantém uma resposta antiga, um resolver público retorna SERVFAIL, os servidores autoritativos discordam ou o DNS está correto e a falha real está em HTTP, TLS, rota ou firewall.

Registre hostname, tipo de registro, local do cliente, resolver utilizado, resposta esperada e resposta observada. Evite limpar caches imediatamente; o conteúdo em cache pode explicar por que apenas parte dos usuários está afetada.

2. Teste o resolver que o cliente realmente utiliza

Primeiro reproduza o problema no host afetado. Isso mostra o que o sistema operacional e o resolver recursivo configurado estão enxergando.

# Windows PowerShell
Resolve-DnsName example.com
Resolve-DnsName example.com -Type AAAA

# Windows clássico
nslookup example.com

# Linux com systemd-resolved
resolvectl status
resolvectl query example.com

# Linux/macOS com dig
dig example.com A
dig example.com AAAA

Registre valor retornado, status e TTL. NXDOMAIN, SERVFAIL, timeout e uma resposta válida porém incorreta apontam para cenários diferentes.

3. Compare resolvers recursivos independentes

Se o resolver configurado retornar algo inesperado, compare com resolvers públicos independentes. Respostas diferentes normalmente apontam para cache, filtragem, split DNS ou um problema específico do resolver.

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
dig @9.9.9.9 example.com A

Um resolver público não é a fonte autoritativa. O próximo passo é remover o cache recursivo da equação.

4. Descubra e consulte os servidores autoritativos diretamente

Localize os registros NS e consulte cada servidor autoritativo para o registro que apresenta problema.

dig NS example.com
dig @ns1.example-dns.net example.com A
dig @ns2.example-dns.net example.com A

Os servidores autoritativos da mesma zona devem apresentar uma visão coerente. Se um deles retorna dados antigos, timeout ou um serial SOA diferente, investigue distribuição da zona ou configuração do provedor autoritativo.

O DNS Lookup ajuda a inspecionar os registros e o Domain Health amplia a análise para o domínio como um todo.

5. Verifique delegação, glue e DNSSEC

Uma zona correta ainda pode falhar quando o domínio pai delega para nameservers errados, registros glue estão incorretos ou a cadeia DNSSEC não valida.

dig +trace example.com
dig DS example.com
dig DNSKEY example.com +dnssec
dig example.com A +dnssec

Em problemas de DNSSEC, testes que não validam a assinatura podem funcionar enquanto resolvers validadores retornam SERVFAIL. Compare o DS no domínio pai, as DNSKEY da zona filha e a cadeia de assinaturas antes de mexer na aplicação.

6. Use o TTL para explicar respostas antigas

Uma alteração DNS não "propaga" como um único evento global. Resolvers recursivos mantêm respostas em cache até o TTL expirar. Se o registro anterior possuía TTL elevado, parte dos clientes pode continuar recebendo o valor antigo legitimamente até o cache vencer.

Compare resposta e TTL restante entre resolvers. Limpe o cache local apenas depois de registrar as evidências.

# Windows
ipconfig /displaydns
ipconfig /flushdns

# systemd-resolved
resolvectl flush-caches

7. Prove se a falha continua sendo DNS

Quando o hostname já retorna o IP esperado, suba uma camada. DNS correto não garante que TCP, TLS ou HTTP estejam funcionando.

curl -I https://example.com
curl -vk https://example.com/

# Teste um IP específico preservando hostname/SNI
curl --resolve example.com:443:203.0.113.10 https://example.com/

Se --resolve funciona contra o IP correto enquanto a resolução normal aponta para outro destino, DNS continua envolvido. Se os dois testes falham da mesma forma, investigue rota, firewall/WAF, listener, certificado/SNI ou aplicação. Para a rota, use o Traceroute.

Padrões de falha comuns

• Só uma estação falha: cache local, VPN, hosts file, política de endpoint ou DNS configurado na máquina.
• Só uma filial/rede falha: resolver interno, forwarder, conditional zone, split DNS ou política de rede.
• Resolvers públicos divergem temporariamente: estado de cache/TTL ou comportamento específico do resolver.
• Servidores autoritativos divergem: replicação da zona ou configuração do provedor.
• Resolvers validadores retornam SERVFAIL: investigue DNSSEC.
• DNS entrega o IP correto mas o serviço não responde: avance para TCP, TLS, HTTP, firewall e aplicação.

8. Checklist operacional repetível

1. Registre hostname, tipo de registro, valor esperado e usuários afetados.
2. Consulte a partir de um cliente afetado usando o resolver configurado.
3. Compare pelo menos dois resolvers recursivos independentes.
4. Descubra os nameservers autoritativos.
5. Consulte cada servidor autoritativo diretamente.
6. Inspecione delegação e DNSSEC quando a cadeia parecer inconsistente.
7. Use TTL para explicar respostas antigas.
8. Com DNS correto, teste TCP/TLS/HTTP separadamente.
9. Altere apenas a camada que apresentou evidência de falha e repita exatamente o mesmo teste.

O fluxo fica objetivo: cliente → resolver recursivo → DNS autoritativo → delegação/DNSSEC → camada de aplicação.