Por padrão o dig imprime a mensagem DNS inteira, que é exatamente o que você quer ao fazer troubleshooting e muito mais do que você quer ao escrever scripts. Algumas opções cobrem quase todos os casos.

Escolhendo o que perguntar

  • dig example.com consulta um registro A usando o resolvedor do seu sistema.
  • -t TIPO (ou apenas colocar o tipo na linha) muda o tipo de registro: dig -t MX example.com, ou dig example.com AAAA. Tipos comuns são A, , , NS, , , e ANY.
  • @servidor pergunta a um servidor específico em vez do seu resolvedor padrão: dig @1.1.1.1 example.com, ou dig @ns1.example.com example.com para ir direto a um servidor autoritativo.
  • -x ENDEREÇO faz uma consulta reversa, construindo o nome in-addr.arpa para você: dig -x 93.184.216.34.

Controlando a saída

  • +short reduz a resposta a apenas os valores essenciais, um por linha. dig +short example.com imprime só o endereço. Esta é a opção para usar em scripts.
  • +noall +answer é o meio-termo: suprime todas as seções exceto a answer, então você vê os registros de fato com seus TTLs e tipos, mas nenhum ruído de header, question ou stats. Muita gente cria um alias para isso.
  • +norecurse (ou +norec) pede ao servidor para não recursar, então você vê apenas o que aquele servidor sabe localmente. Enviado a um servidor autoritativo, mostra o dado autoritativo; enviado a um resolvedor, mostra apenas o que já está em cache.
  • +tcp força a consulta por TCP em vez de UDP, útil quando uma resposta UDP voltou truncada (a flag tc).
  • +dnssec pede os registros (RRSIG e companhia) e define o bit DO, para que você possa ver as assinaturas.

Combinando-as

As opções se compõem. dig @1.1.1.1 example.com MX +short pergunta ao resolvedor da Cloudflare pelos registros MX e imprime apenas os valores. dig example.com +noall +answer +dnssec mostra os registros da answer mais suas assinaturas e nada mais. Comece pela saída completa padrão quando estiver diagnosticando, e recorra a +short ou +noall +answer quando souber exatamente o que quer ver. Para seguir o caminho de resolução a partir da raiz em vez de confiar em um resolvedor, veja o artigo companheiro sobre +trace.

A opção que muda o que você está testando

@servidor parece uma conveniência e é a flag mais consequente da lista. Ela ignora o resolvedor do sistema por completo e pergunta direto ao servidor nomeado.

Isso a torna a ferramenta certa para "esta zona está correta" e a errada para "a resolução funciona aqui", porque uma consulta a @8.8.8.8 não prova nada sobre o resolvedor que suas aplicações realmente usam — seu cache, seus forwarders, suas regras de acesso, ou se o host sequer o alcança.

Pergunte sem @ primeiro. Se funcionar, a resolução está bem. Se falhar e o @ funcionar, você já localizou a falha no seu próprio caminho de resolução — mais do que a maioria das investigações consegue no primeiro minuto.