Um dig normal pergunta a um resolver e confia na resposta dele. O dig +trace faz algo diferente e muito mais revelador: ele mesmo faz a resolução, hop a hop (servidor por servidor), do jeito que um resolver recursivo faria.

O que o +trace faz, na prática

O DNS é um sistema hierárquico e delegado. Nenhum servidor sozinho sabe tudo; cada nível aponta para o seguinte. O dig +trace example.com percorre essa cadeia e mostra cada etapa:

  1. Ele começa perguntando a um servidor raiz sobre o nome. A raiz não conhece o example.com, mas sabe quem opera o .com, e por isso devolve os registros NS dos servidores do .com (um referral, a indicação de quem consultar em seguida).
  2. Depois, o dig pergunta a um desses servidores do .com, que também não tem o example.com, mas sabe quais servidores são autoritativos para ele, e devolve outro referral.
  3. Por fim, o dig pergunta a um dos servidores autoritativos do próprio domínio, que devolve a resposta de verdade.

Cada etapa aparece como um conjunto de registros NS (a delegação), seguido da consulta ao nível de baixo. O último bloco é a resposta autoritativa.

Por que ele é tão útil

Como o +trace segue a cadeia real, e não uma cópia em cache, ele mostra exatamente onde está o problema. Se os servidores do .com devolvem os registros NS errados para o seu domínio, o problema é de delegação, no registrador. Se a delegação está certa, mas os servidores autoritativos dão timeout ou respondem coisas diferentes entre si, o problema está no seu provedor de DNS. Uma consulta simples mostraria só um SERVFAIL ou uma resposta desatualizada; o +trace mostra em qual hop a coisa falhou.

É também a forma mais clara de entender o DNS. Ver um nome sendo resolvido a partir da raiz, referral por referral, deixa a hierarquia concreta de um jeito que uma resposta isolada nunca consegue.

Como ler bem o resultado

Duas coisas para ter em mente. O +trace faz a própria resolução iterativa, então passa totalmente por fora do resolver configurado na máquina, e é por isso que o resultado dele pode ser diferente do de uma consulta normal quando o cache do seu resolver está desatualizado. E cada referral é um conjunto de registros NS, não a resposta final, então leia até o último bloco para chegar ao dado de verdade. Se algum nível devolver registros que você não esperava, é por esse nível que você deve começar a investigar.

O +trace não testa o seu caminho de resolução

O +trace é a ferramenta certa para ler uma cadeia de delegação e a ferramenta errada para provar que a resolução de nomes funciona, porque ele passa por fora do seu resolver de propósito. Ele mesmo faz as iterações a partir da raiz, perguntando a cada servidor, um de cada vez.

Por isso o +trace pode funcionar perfeitamente enquanto todas as aplicações do host continuam falhando, porque o que está quebrado é o resolver que o +trace nunca usou: os forwarders dele, o cache, as regras de acesso ou o caminho até ele.

Use o +trace para descobrir onde uma delegação está errada. Use uma consulta comum para descobrir se a resolução funciona. São perguntas diferentes, e quase sempre a pergunta que estão fazendo é a segunda.