Linux / Comando dig: consultar registros DNS e interpretar respostas

O comando dig consulta servidores DNS (Domain Name System, sistema de nomes de domínio) e mostra registros e o estado da resposta. Ele ajuda a investigar resolução de nomes e comparar servidores, mas um registro DNS válido não comprova que o site ou outro serviço esteja funcionando.

Entre os tipos mais usados estão A, para endereço IPv4, AAAA, para IPv6, MX, para encaminhamento de email, e TXT, para dados textuais cujo significado depende do uso. Leia o status do cabeçalho separadamente da ANSWER SECTION: receber uma resposta não significa necessariamente receber o registro desejado.

As respostas podem mudar com o cache, o servidor consultado e a política de DNS. As formas abreviadas, como +short, são úteis para uma consulta rápida, mas escondem informações importantes para o diagnóstico, incluindo o status e o contexto do TTL (Time to Live), o intervalo de validade para cache.

Sintaxe básica

dig [@servidor-DNS] nome [tipo-de-registro] [opções]

Os colchetes representam argumentos facultativos; não devem ser digitados. O texto servidor-DNS é um marcador: substitua-o pelo endereço ou nome do servidor que você pode consultar. Sem @servidor, o dig do BIND consulta os servidores configurados em /etc/resolv.conf. Confira a implementação instalada com dig -v e as opções locais com man dig.

Com um nome informado e sem tipo explícito, a consulta padrão é de registros A; isso é diferente de executar dig sem nenhum argumento, que consulta os registros NS (servidores de nomes) da raiz. Preferências em ~/.digrc também podem alterar o comportamento; a opção -r desconsidera esse arquivo em scripts que precisam de opções previsíveis, conforme o manual oficial do dig no BIND 9.

Exemplos de consulta

Consultar registros A

O comando consulta o endereço IPv4 do nome e mantém a saída completa, incluindo o status e o servidor que respondeu:

dig example.com A

O domínio example.com é reservado para exemplos pela IANA. Os registros atuais podem mudar; não copie um endereço de uma saída didática para a configuração de produção. Para investigar outro domínio, substitua o nome e mantenha explícito o tipo que deseja consultar.

Consultar registros de email

A consulta MX mostra a preferência e o nome do servidor de email, quando esses dados existem:

dig example.com MX

Nos registros MX comuns, valores menores de preferência são priorizados entre registros do mesmo nome, segundo a definição de MX na RFC 1035. Há uma exceção importante: 0 . é um Null MX, que informa que o domínio não aceita email, e não um servidor chamado “.”. Essa convenção é definida pela RFC 7505.

Na verificação de 29 de outubro de 2026, uma consulta separada com Resolve-DnsName, no Windows 11 build 28000 e PowerShell 5.1.28000.3231, retornou dois registros A para example.com e um MX de preferência 0 com destino .. Isso confirma a necessidade de interpretar Null MX naquele resultado; não é uma execução do dig no Linux nem uma garantia sobre respostas futuras de outros servidores.

Exibir uma resposta curta

Para uma leitura rápida dos valores, use:

dig +short example.com A

Não use apenas a presença ou ausência de texto para diagnosticar o domínio. Uma saída curta vazia pode esconder situações diferentes; confira também mensagens de erro e volte à consulta completa, sem +short, para ler o status, o tipo consultado e o servidor. Em scripts, separe o código de saída do programa do código de resposta DNS.

Ler os campos da resposta DNS

A combinação +noall +answer desativa as opções de exibição e reativa a seção de respostas. Ela facilita a leitura dos registros, mas também omite o cabeçalho de status e os dados do servidor:

dig +noall +answer example.com A

Formato ilustrativo de um registro, com TTL e endereço didáticos, sem representar a resposta real do domínio:

example.com. 300 IN A 192.0.2.10

• example.com. é o nome do registro. O ponto final indica um nome DNS absoluto, terminado na raiz.
• 300 é o TTL (Time to Live) em segundos: um intervalo de validade para cache, não o tempo de resposta da consulta nem o prazo de atualização de todos os caches do mundo. Em um resolvedor com cache, o valor pode refletir o tempo restante.
• IN identifica a classe Internet do registro.
• A indica que o valor é um endereço IPv4; outros tipos têm formatos de dados diferentes.
• 192.0.2.10 é um endereço de documentação da TEST-NET-1, definida pela RFC 5737. Não é o endereço medido de example.com nem um destino público de teste.

Se a seção de respostas estiver vazia, repita a consulta completa e leia o status. NXDOMAIN indica que o nome consultado não existe no contexto da resposta; NOERROR indica ausência de erro DNS, mas não garante a existência do tipo solicitado. Uma resposta sem os dados desse tipo pode ser NODATA; esse termo não é um código de status próprio e exige interpretar as seções da resposta, incluindo possíveis aliases ou referências. A distinção é detalhada na RFC 2308 sobre respostas negativas e cache.

SERVFAIL indica que o servidor não conseguiu processar a consulta; isso não equivale a NXDOMAIN. Um timeout sem resposta também é diferente de uma resposta DNS negativa. No dig do BIND, o código de saída 0 inclui respostas NXDOMAIN, enquanto 9 indica ausência de resposta do servidor. Portanto, sucesso do processo não comprova existência de um registro.

No Git Bash 5.3.9 deste ambiente Windows, o dig não estava instalado: dig -v retornou “command not found”, código 127. As quatro linhas de exemplo passaram apenas pela análise de sintaxe do Bash; a consulta Windows mencionada na seção MX foi um teste separado. Não houve alteração de DNS, limpeza de caches ou execução nativa Linux.

Opções principais

Ao comparar servidores, mantenha o mesmo nome e tipo e substitua o marcador @servidor por cada endereço autorizado. Registre qual servidor respondeu e quando. Com +trace, se houver também @servidor, ele afeta apenas a consulta inicial aos servidores da raiz; o restante segue as referências. Uma rede pode permitir apenas consultas ao resolvedor configurado e impedir acesso direto aos demais servidores.

Investigar diferenças e respostas vazias

1. Confira o nome completo, o tipo solicitado e o servidor indicado na saída completa. Para comparar caches, repita a mesma consulta sem opções que escondam o cabeçalho.
2. Diferencie NXDOMAIN, ausência do tipo desejado, SERVFAIL e falta de resposta. Não trate todas essas situações como “o domínio não existe”.
3. Compare respostas levando em conta cache, TTL e políticas de DNS interno ou externo. Uma diferença entre servidores não prova, sozinha, que um deles esteja errado ou que uma atualização já deveria aparecer em toda parte.
4. Se o dig responde e a aplicação falha, confira a resolução realmente usada pela aplicação e teste o serviço. No Linux, /etc/hosts, bibliotecas de resolução e caches locais podem fazer parte de um caminho diferente da consulta DNS direta.

Um navegador também pode usar cache próprio, um proxy ou DNS sobre HTTPS (DoH), como descreve a Mozilla para o Firefox, que pode consultar outro resolvedor. Uma resposta A ou AAAA informa um endereço; ela não valida a conexão, o certificado do site, a autenticação ou o estado da aplicação. Investigue cada etapa sem mudar o DNS do sistema apenas para fazer duas saídas coincidirem.

Pergunta frequente

Por que o resultado do dig pode ser diferente do acesso pelo navegador?

O dig mostra a resposta do servidor DNS selecionado naquela consulta. O navegador pode usar outro resolvedor, cache próprio, proxy ou outro caminho de resolução; o sistema também pode considerar arquivos locais. Compare o nome, o tipo e o resolvedor e, depois, teste a conexão com o serviço. Uma resposta DNS correta, sozinha, não garante que a página será carregada.