Por padrão, o dig mostra a mensagem DNS inteira, o que é exatamente o que você quer num troubleshooting e muito mais do que você quer num script. Umas poucas opções resolvem quase todos os casos.

Como escolher o que perguntar

  • dig example.com consulta um registro A usando o resolver (o servidor DNS recursivo) configurado no seu sistema.
  • -t TIPO (ou simplesmente o tipo escrito na linha de comando) muda o tipo de registro: dig -t MX example.com ou dig example.com AAAA. Os tipos mais comuns são A, , , NS, , , e ANY.
  • @servidor pergunta a um servidor específico, em vez do seu resolver 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 e monta o nome in-addr.arpa para você: dig -x 93.184.216.34.

Como controlar a saída

  • +short reduz a resposta aos valores essenciais, um por linha. dig +short example.com mostra só o endereço. É a opção certa para usar em scripts.
  • +noall +answer é o meio-termo: esconde todas as seções, menos a answer, e assim você vê os registros de verdade, com os TTLs e os tipos, sem nada do ruído de header, question e stats. Muita gente cria um alias para isso.
  • +norecurse (ou +norec) pede ao servidor que não faça recursão, e assim você vê só o que aquele servidor sabe localmente. Mandada a um servidor autoritativo, ela mostra os dados autoritativos; mandada a um resolver, mostra só o que já está em cache.
  • +tcp força a consulta por TCP em vez de UDP, o que ajuda quando uma resposta por UDP voltou truncada (a flag tc).
  • +dnssec pede os registros (o RRSIG e companhia) e liga o bit DO, para você poder ver as assinaturas.

Como combinar as opções

As opções podem ser combinadas. dig @1.1.1.1 example.com MX +short pergunta ao resolver da Cloudflare pelos registros MX e mostra só os valores. dig example.com +noall +answer +dnssec mostra os registros da answer com as assinaturas, e mais nada. Quando estiver diagnosticando, comece pela saída completa padrão e passe para +short ou +noall +answer quando já souber exatamente o que quer ver. Para seguir o caminho da resolução a partir da raiz, em vez de confiar num resolver, veja o artigo complementar sobre +trace.

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

O @servidor parece só uma conveniência, mas é a flag com mais consequências da lista. Ela ignora completamente o resolver do sistema e pergunta direto ao servidor indicado.

Por isso ela é a ferramenta certa para "esta zona está correta?" e a ferramenta errada para "a resolução funciona aqui?", porque uma consulta a @8.8.8.8 não prova nada sobre o resolver que as suas aplicações usam de fato: o cache dele, os forwarders dele, as regras de acesso dele, nem se o host consegue sequer chegar até ele.

Pergunte sem @ primeiro. Se funcionar, a resolução está bem. Se falhar e o @ funcionar, você já localizou a falha: ela está no caminho até o seu próprio resolver, e isso é mais do que a maior parte dos troubleshootings consegue no primeiro minuto.