O manual do 9 mostra a sinopse do dig, a sintaxe resumida do comando, numa linha só: dig [@servidor] [opções] [nome] [tipo] [classe] [opção-de-consulta...]. São seis tipos de palavra, e todos são opcionais. Se você rodar dig sem nada, ele pede os registros NS da raiz. Tudo o que você acrescenta restringe essa consulta, e a ordem importa menos do que muita gente teme, mas mais do que muita gente imagina: os seis tipos podem vir misturados, só que as opções com + são aplicadas em sequência, e duas delas, depois de definidas, não podem mais ser sobrescritas. Este artigo percorre uma linha de comando do dig da esquerda para a direita e mostra como o dig interpreta cada palavra e o que ele faz quando ela não aparece. O montador de comandos dig monta uma linha dessas a partir de um formulário e explica cada token; o explicador de saída do dig interpreta o que volta.

A quem perguntar: a palavra depois do @

A palavra que começa com @ indica o servidor. Pode ser um hostname, um endereço IPv4 ou um endereço IPv6, e o endereço vai sem nada em volta: @2001:db8::53, sem os colchetes que uma URL exigiria. Se for um hostname, o dig primeiro resolve esse nome pelo resolver comum e depois consulta o endereço que obteve. Se não houver nenhum @servidor na linha, o dig tenta, um de cada vez, os servidores listados no /etc/resolv.conf e, se nenhum deles puder ser usado, manda a consulta para o host local.

A porta não faz parte dessa palavra. Ela vem na opção -p, que existe, segundo o manual, para testar um servidor configurado para escutar numa porta fora do padrão. A porta padrão é a 53, que a 1035 atribui tanto ao UDP quanto ao TCP; os dois transportes com criptografia mudam esse padrão (veja mais abaixo).

Mais duas opções influenciam o caminho da consulta. -4 e -6 limitam o dig a uma família de endereços, e isso também filtra os servidores do resolv.conf que ele vai tentar. -b endereço[#porta] define o endereço de origem, que precisa ser um endereço da própria máquina, ou então 0.0.0.0 ou ::; é a opção certa quando uma regra de firewall ou um host multihomed (ligado a mais de uma rede) faz com que a origem padrão seja a errada.

O que perguntar: nome, tipo e classe

O nome é o owner name a consultar, ou seja, o nome ao qual os registros pertencem. O tipo vem logo depois dele, ou com -t; se nenhum tipo for informado, o dig busca registros A. A classe vem por último, ou com -c; o padrão é IN, e as alternativas documentadas no manual são CH, de Chaosnet, e HS, de Hesiod. Esses são os valores de TYPE e CLASS da RFC 1035 (A é 1, NS é 2, é 15, é 16; IN é 1, CH é 3, HS é 4). De lá para cá, a lista cresceu com o (RFC 3596) e com o resto da tabela de tipos da , que também inclui os tipos de consulta que não são tipos de registro: AXFR (252), IXFR (251) e * (255), que o dig escreve como ANY.

É aqui que está a única ambiguidade de verdade. Diante de uma palavra solta, o dig tenta interpretá-la primeiro como ixfr=N, depois como tipo, depois como classe e, só no fim, como nome. Essa ordem está no código-fonte, em bin/dig/dig.c, e o manual aponta os dois casos em que ela causa problema: os nomes das classes IN e CH coincidem com os domínios de topo IN e CH. As soluções que o manual indica são a opção -q nome, que informa explicitamente o nome a consultar, as opções -t e -c, para o tipo e a classe, ou escrever IN. e CH. com um ponto no final. O mesmo vale para qualquer nome que, por acaso, também seja o mnemônico de um tipo: um host chamado mx ou ns precisa ser passado com -q.

A consulta reversa (reverse lookup) dispensa essas três palavras. A opção -x endereço recebe um endereço IPv4 ou IPv6, e o próprio dig monta o nome: os quatro octetos em ordem inversa sob in-addr.arpa (RFC 1035, seção 3.5), ou trinta e dois nibbles em ordem inversa sob ip6.arpa (RFC 3596, seção 2.5), com o tipo e a classe IN. Não é preciso informar nome, tipo e classe na mesma linha.

Três palavras de tipo têm regras próprias. AXFR pede a zona inteira: na linha do dig, ela vai como um tipo, e o servidor entrega a zona ou recusa o pedido. ixfr=N pede as mudanças feitas desde o serial N, que é o serial da cópia que você já tem; é assim que a RFC 1995 define a transferência incremental. Já uma palavra TYPEnn, com o número do tipo, pede qualquer tipo pelo código, e um tipo que o dig não conhece aparece no formato de tipo desconhecido da RFC 3597.

As opções com +, aplicadas em ordem

Tudo o que começa com + é uma query option, uma opção de consulta. O manual divide essas opções em três famílias: umas ligam ou desligam bits no header (o cabeçalho) da consulta, outras escolhem quais partes da resposta aparecem na saída, e outras definem a estratégia de timeout e de retry. O prefixo no nega a opção (+norecurse), um =valor atribui um valor (+timeout=3), e qualquer abreviação sem ambiguidade é aceita (+cd no lugar de +cdflag).

Dois fatos sobre essas opções determinam como a linha deve ser escrita. O primeiro: a ordem das query options faz diferença. +noall +answer desliga todas as seções e depois religa só a seção de resposta (answer); na ordem inversa, nada aparece na saída. O segundo: duas opções são globais. +short e +cmd valem para todas as consultas da linha, e não dá para defini-las globalmente e depois sobrescrever o valor numa consulta específica. Com as outras opções isso é possível, porque o dig aceita várias consultas numa mesma linha, cada uma com as suas opções, e um conjunto de opções globais escrito antes do primeiro nome vale para todas elas. O próprio manual dá um exemplo com três consultas num único comando: uma consulta ANY, uma consulta reversa e uma consulta NS, com +qr valendo para todas e +noqr na última.

O transporte, que o dig escolhe por você

O transporte padrão é o UDP, e uma resposta UDP truncada (com o bit TC ligado) faz o dig repetir a consulta por TCP; +ignore desativa esse retry e aceita a resposta truncada. Três casos mudam o padrão. Uma consulta do tipo ANY e uma consulta ixfr=N usam TCP por padrão. O AXFR usa sempre TCP, e a RFC 5936 diz o mesmo: transferência de zona só se faz sobre conexões TCP. Para qualquer outra consulta, +tcp (ou a grafia antiga, +vc, de virtual circuit, o circuito virtual) força o uso de TCP.

Duas opções mais recentes abandonam de vez a porta 53. +tls leva a consulta por DNS over TLS, e a porta padrão passa a ser a 853, que é a porta atribuída pela RFC 7858. +https leva a consulta por (RFC 8484), num POST HTTP; a porta padrão é a 443, e a requisição vai para o endpoint /dns-query, a menos que +https=/outro/caminho indique outro. Nenhuma das duas precisa de +tcp: as duas já rodam dentro de uma conexão TCP.

Os bits do header e o registro OPT

Algumas opções mexem em bits do header DNS de doze bytes definido na RFC 1035. +norecurse desliga o RD (recursion desired, recursão desejada), que o dig liga por padrão: um servidor que recebe a consulta sem RD responde só com o que já tem, e é assim que se vê o que um servidor autoritativo realmente serve ou o que um resolver tem em cache. +cd liga o CD (checking disabled, verificação desativada) e, com isso, pede a um resolver com validação ligada que entregue os dados sem validá-los (RFC 4035, seção 3.2.2). O dig também liga por padrão, na consulta, o bit (authentic data, dados autênticos); numa resposta, esse bit indica que o servidor validou tudo o que devolveu (RFC 4035, seção 3.2.3).

Outras opções não têm um bit no header para ligar, porque são mais novas que o header de 1987. Elas vão no pseudo-registro , que a RFC 6891 acrescentou à seção adicional (additional section): é o mecanismo de extensão chamado . O dig envia um registro OPT por padrão, com EDNS versão 0; +noedns remove esse registro. O bit OK, o DO, que +dnssec liga, é a primeira das flags estendidas do registro OPT (RFC 3225), e é ele que faz o servidor incluir na resposta os registros RRSIG, , DS e (RFC 4034). +trace também liga esse bit, para imitar o que um resolver envia. +bufsize=B define o tamanho do payload UDP que o registro OPT anuncia, de 0 a 65535 no dig; a RFC 6891 diz que valores abaixo de 512 devem ser tratados como 512 e sugere 4096 como ponto de partida, e os operadores por trás do DNS Flag Day 2020 adotaram 1232 como o padrão, um tamanho que evita fragmentação em quase todas as redes atuais. +nsid acrescenta a opção que pede ao servidor que se identifique (RFC 5001); +subnet, a opção de client subnet, a sub-rede do cliente (RFC 7871, em que um tamanho de prefixo 0 significa: não use o meu endereço); e o dig envia por padrão a opção COOKIE (RFC 7873), que +nocookie remove. A consequência para a linha de comando: +noedns junto com +dnssec ou +bufsize é uma contradição, porque o que essas opções pedem não tem onde ir.

Três opções que mudam quem responde

+trace transforma o dig num resolver, só para aquela consulta. Ele pergunta aos servidores raiz, segue o referral (a resposta que indica quem responde pelo nível seguinte) até os servidores do domínio de topo, segue o referral seguinte e mostra cada passo. A recursão fica desligada durante esse processo, e, se houver um @servidor na linha, ele só vale para a consulta inicial, a que busca os name servers da raiz. +nssearch encontra os servidores autoritativos da zona que contém o nome e mostra o registro que cada um tem, junto com os endereços dos servidores que não responderam; ele também desliga a recursão. +norecurse, como vimos acima, pergunta a um único servidor o que ele sabe. Com +trace ou +nssearch na linha, +norecurse não acrescenta nada.

Timers, saída e o segredo que fica num arquivo

+timeout=T espera T segundos por consulta, cinco por padrão, e um valor abaixo de 1 vira 1 sem nenhum aviso. +tries=T é o número total de tentativas, três por padrão, e é arredondado para 1 quando é zero ou negativo; +retry=T conta só as novas tentativas depois da primeira, duas por padrão. Na saída, +short mostra só os dados da resposta, um registro por linha, e +identify acrescenta o endereço e a porta do servidor que respondeu; +noall +answer mostra a seção de resposta completa; +multiline mostra os registros SOA e DNSKEY em várias linhas, com comentários; +ttlunits mostra os TTLs em unidades, como 1h e 2d; +yaml mostra a troca inteira em ; e +qr mostra também a consulta do jeito que ela foi enviada.

Por fim, as consultas assinadas. O assina uma consulta com um segredo compartilhado, e o dig recebe a chave de duas formas: -k arquivo lê a chave de um arquivo, e -y [hmac:]nome:segredo recebe a chave na própria linha de comando. Sobre a segunda forma, o manual é mais direto do que de costume: só se deve usar -k, porque, com -y, o segredo compartilhado vira um argumento de linha de comando em texto claro, visível na saída do ps e no arquivo de histórico do shell. Um montador de comandos que oferece só -k está seguindo o manual, e não sendo cauteloso por conta própria.

Fontes

Cada afirmação sobre o comportamento do dig acima é do manual do BIND 9, e os fatos de protocolo são das RFCs, todos lidos em 2026-10-04: