Como usar dig e nslookup para diagnosticar problemas de DNS

Diagnosticar problemas de DNS com dig e nslookup consiste em usar ferramentas de linha de comando para consultar servidores DNS, identificar registros incorretos e detectar falhas de propagação em domínios no Linux. Para diagnosticar problemas de DNS, siga estes passos:

1. Instale os pacotes dnsutils (dig) e bind-utils/nslookup conforme sua distro
2. Execute dig para consultar registros A, MX, CNAME e TXT do domínio
3. Compare a resposta com o servidor DNS autoritativo usando dig +trace
4. Use nslookup para verificar respostas de resolvers específicos
5. Confirme o TTL e o tempo restante de cache dos registros
6. Valide a propagação em múltiplos resolvers públicos (Google, Cloudflare)

Pré-requisitos

• Acesso root ou sudo em servidor Linux (Ubuntu 25.10, Debian 13 ou AlmaLinux 10 usados neste guia)
• Pacote dnsutils (Debian/Ubuntu) ou bind-utils (RHEL-like) instalado
• Domínio já registrado com zona DNS configurada
• Conhecimento básico de tipos de registro DNS (A, AAAA, MX, CNAME, TXT, NS)
• Acesso ao painel de gerenciamento de DNS do seu domínio, quando for necessário alterar registros

Como usar dig para diagnosticar DNS no Linux

O diagnóstico de DNS com dig começa instalando o utilitário e testando consultas básicas contra o domínio afetado. O dig é mais detalhado que o nslookup e mostra seção de autoridade, tempo de resposta e flags da consulta, o que ajuda a identificar rapidamente se o problema está no servidor autoritativo ou no resolver local. Ao trabalhar com FQDN (Fully Qualified Domain Name), é importante que o domínio consultado inclua o ponto final para evitar ambiguidades na resolução.

Primeiro, instale a ferramenta caso ainda não esteja presente:

sudo apt update && sudo apt install -y dnsutils
# ou em AlmaLinux/Rocky:
sudo dnf install -y bind-utils

Output esperado: o pacote é baixado e instalado sem erros, tornando os binários dig, nslookup e host disponíveis no PATH.

Agora execute uma consulta simples para o registro A do domínio:

dig seudominio.com.br A +short

Output esperado:
203.0.113.10

Se o IP retornado não corresponder ao servidor esperado, o problema pode estar na zona DNS ou em cache antigo. Para investigar mais a fundo, use a saída completa sem o +short e observe a seção ANSWER, AUTHORITY e ADDITIONAL:

dig seudominio.com.br MX

Output esperado (resumido):
;; ANSWER SECTION:
seudominio.com.br. 3600 IN MX 10 mail.seudominio.com.br.

;; Query time: 24 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)

Usando dig +trace para rastrear a cadeia de resolução DNS

Quando a propagação parece incompleta, o dig +trace simula toda a cadeia de resolução, desde os root servers até o servidor autoritativo, revelando exatamente onde a resposta diverge do esperado. Esse processo de consulta recursiva percorre cada nível da hierarquia DNS — raiz, TLD e zona autoritativa — permitindo identificar em qual ponto a delegação falha.

dig seudominio.com.br +trace

Output esperado (resumido):
.                       518400  IN  NS  a.root-servers.net.
com.br.                 172800  IN  NS  a.dns.br.
seudominio.com.br.       3600    IN  A   203.0.113.10

Se algum salto da cadeia retornar SERVFAIL ou timeout, o problema está entre esse nível e o próximo, ajudando a isolar se é falha do registro.br, do provedor de DNS ou do servidor de destino. Em redes que utilizam infraestrutura Anycast, diferentes instâncias do mesmo servidor DNS podem responder dependendo da localização geográfica, o que pode causar variações na resposta durante o trace.

Usando nslookup para validar servidores DNS específicos

O nslookup é mais simples que o dig e útil para testes rápidos, especialmente quando você precisa consultar um servidor DNS específico e comparar a resposta com o resolver padrão do sistema. Isso é essencial para verificar se a propagação já chegou a resolvers públicos como Google (8.8.8.8) e Cloudflare (1.1.1.1).

nslookup seudominio.com.br 8.8.8.8

Output esperado:
Server:  8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name:    seudominio.com.br
Address: 203.0.113.10

Repita o teste apontando para outro resolver:

nslookup seudominio.com.br 1.1.1.1

Se as respostas divergirem entre os dois resolvers, isso confirma que a propagação está em andamento e ainda não atingiu todos os resolvers globais. Para consultas de tipo específico, use a flag -type:

nslookup -type=TXT seudominio.com.br

Output esperado:
seudominio.com.br text = "v=spf1 include:_spf.google.com ~all"

Registros TXT são frequentemente usados para SPF e DKIM; para validar esses mecanismos em conjunto, veja o checklist de como testar se DKIM e SPF estão configurados.

Checklist de DNS: diagnosticando falhas de propagação passo a passo

O checklist de propagação de DNS reúne uma sequência de comandos que revela se a demora é normal (aguardando expiração do TTL) ou se há um erro de configuração na zona. Antes de suspeitar do provedor, confirme que a zona está correta na origem.

1. Consulte o TTL atual do registro com dig seudominio.com.br A e observe o valor entre o nome e o tipo de registro
2. Compare a resposta do servidor autoritativo direto: dig @ns1.seudominio.com.br seudominio.com.br A
3. Teste em múltiplos resolvers públicos (8.8.8.8, 1.1.1.1, 9.9.9.9) para ver se todos já convergiram
4. Verifique se há registros duplicados ou conflitantes com dig seudominio.com.br ANY
5. Confirme o registro NS do domínio no registro.br ou no provedor com dig seudominio.com.br NS

dig @ns1.seudominio.com.br seudominio.com.br A +short

Output esperado:
203.0.113.10

Se o servidor autoritativo já retorna o IP correto mas os resolvers públicos ainda mostram o valor antigo, o problema é puramente de cache aguardando expiração do TTL — não há nada de errado na configuração. Para entender esse comportamento em detalhe, veja o guia de zona DNS: registros A, MX, CNAME e TXT do zero.

Atenção: reduzir o TTL para forçar propagação mais rápida só funciona se feito antes da mudança de registro; alterar o TTL após já ter propagado o valor antigo não acelera a atualização em resolvers que já fizeram cache.

Automatizando o diagnóstico de DNS com scripts simples

Para ambientes com múltiplos domínios em um servidor Linux, vale criar um script que roda dig contra vários resolvers automaticamente, economizando tempo em diagnósticos recorrentes.

#!/bin/bash
DOMINIO="seudominio.com.br"
RESOLVERS=("8.8.8.8" "1.1.1.1" "9.9.9.9")

for r in "${RESOLVERS[@]}"; do
  echo "Resolver: $r"
  dig @"$r" "$DOMINIO" A +short
  echo "---"
done

Output esperado:
Resolver: 8.8.8.8
203.0.113.10
---
Resolver: 1.1.1.1
203.0.113.10
---
Resolver: 9.9.9.9
203.0.113.10
---

Salve como check-dns.sh, dê permissão de execução com chmod +x check-dns.sh e rode sempre que precisar validar propagação após alterações. Se você gerencia e-mail no mesmo domínio, também é recomendável revisar o passo a passo para configurar servidor de e-mail no VPS Linux, já que registros MX incorretos são uma causa comum de falha de entrega.

Problemas comuns e como resolver

Sintoma: dig retorna "connection timed out; no servers could be reached"

Causa: firewall bloqueando a porta 53 (UDP/TCP) ou resolver DNS inacessível.
Solução: teste conectividade com dig @8.8.8.8 seudominio.com.br; se funcionar, o problema está no resolver local configurado em /etc/resolv.conf. Verifique regras de firewall com sudo ufw status ou iptables -L e libere a porta 53 se necessário.

Sintoma: nslookup e dig retornam respostas diferentes para o mesmo domínio

Causa: cache local desatualizado ou consulta feita contra resolvers diferentes sem especificar o servidor.
Solução: sempre especifique o servidor explicitamente (dig @1.1.1.1) e limpe o cache do systemd-resolved com sudo resolvectl flush-caches antes de repetir o teste.

Sintoma: dig +trace falha na cadeia de resolução em algum ponto intermediário

Causa: delegação de NS incorreta na zona pai ou servidor autoritativo fora do ar.
Solução: confirme os NS configurados no registro.br ou provedor de domínio com dig seudominio.com.br NS e compare com os NS efetivamente respondendo consultas. Corrija a delegação se houver divergência entre o que está registrado e o que está ativo.

Perguntas frequentes sobre diagnóstico de DNS

Quanto tempo demora a propagação de DNS depois de alterar os registros?

O tempo de propagação depende do valor de TTL configurado no registro anterior, podendo variar de alguns minutos até 48 horas em casos de TTL alto ou cache persistente em resolvers intermediários. Reduzir o TTL antes de fazer a mudança ajuda a acelerar esse processo em futuras alterações.

Qual a diferença entre dig e nslookup no diagnóstico de DNS?

O dig oferece saída mais detalhada, incluindo seções de autoridade, flags técnicas da consulta recursiva e informações sobre o servidor autoritativo, sendo preferido por administradores de sistema. O nslookup é mais simples e interativo, adequado para verificações rápidas, mas com menos informações de depuração. Para instalar ambos no Ubuntu, basta executar sudo apt install dnsutils, que inclui dig, nslookup e host no mesmo pacote.

Por que dig retorna um IP diferente do configurado no painel DNS?

Isso geralmente indica cache local ou de resolver ainda não expirado, ou uma consulta feita contra um servidor DNS diferente do autoritativo. Use dig @ns1.seudominio.com.br para consultar diretamente a fonte e confirmar o valor correto.

Como saber se meu domínio já propagou globalmente?

Execute dig ou nslookup contra múltiplos resolvers públicos (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9) e compare as respostas. Se todos retornarem o mesmo valor atualizado, a propagação está completa nesses pontos de referência.

É possível forçar a propagação de DNS mais rápido?

Não é possível forçar resolvers de terceiros a atualizar o cache antes do TTL expirar, mas reduzir o TTL antecipadamente, antes de alterar o registro, minimiza o tempo de espera na próxima mudança.

Como fazer uma consulta de DNS reverso com dig?

O DNS reverso resolve um endereço IP de volta para um nome de domínio por meio do registro PTR. Use o comando dig -x 203.0.113.10 para consultar o PTR associado a um IP. Esse tipo de consulta é especialmente útil para verificar a configuração reversa de servidores de e-mail, pois muitos sistemas de antispam rejeitam mensagens de IPs sem registro PTR válido.

Conclusão

• Use dig para diagnósticos detalhados e nslookup para verificações rápidas e comparativas entre resolvers
• Sempre consulte o servidor autoritativo diretamente antes de suspeitar de erro de configuração
• Automatize verificações recorrentes com scripts simples para economizar tempo em ambientes com múltiplos domínios

Leia também

• Solucionar problemas de DNS no VPS Linux gratuito vs pago: vale a pena investir em 2025?
• Solucionar problemas de resolução de nomes DNS em VPS Linux e servidor dedicado
• Como solucionar problemas de rede em VPS Linux: Guia Completo

Precisa de ajuda com configuração de DNS no seu servidor?

Se a propagação de DNS ou a configuração de zona do seu domínio continua causando instabilidade, nossa equipe pode ajudar a revisar registros e servidores diretamente no seu ambiente Linux.

Conheça os planos de VPS Linux da AviraHost