# Anatomia da linha de comando do dig: como o dig interpreta o que você digita > O dig aceita um servidor depois de um @, opções com hífen, um nome, um tipo, uma classe e query options (opções de consulta) com +, em quase qualquer ordem, e usa um valor padrão para tudo o que você deixar de fora. Este artigo percorre a linha da esquerda para a direita: quais palavras valem pela posição e como o dig distingue um nome de um tipo, por que a ordem das opções com + faz diferença e por que duas delas são globais, como o transporte é escolhido (UDP com retry por TCP, TCP para ANY e para transferências de zona, TLS e HTTPS nas suas próprias portas), quais opções mudam bits do header e quais vão no registro OPT do EDNS, o que +trace e +nssearch fazem com a recursão e por que o manual manda guardar o segredo do TSIG num arquivo. Cada afirmação vem do manual do BIND 9 ou de uma RFC, com a fonte citada. Source: https://ronutz.com/pt-BR/learn/anatomy-of-a-dig-command-line Updated: 2026-10-04 Related tools: https://ronutz.com/pt-BR/tools/dig-command-builder, https://ronutz.com/pt-BR/tools/dig-output-explainer --- O manual do BIND 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](https://ronutz.com/pt-BR/tools/dig-command-builder) monta uma linha dessas a partir de um formulário e explica cada token; o [explicador de saída do dig](https://ronutz.com/pt-BR/tools/dig-output-explainer) 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 RFC 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, MX é 15, TXT é 16; IN é 1, CH é 3, HS é 4). De lá para cá, a lista cresceu com o AAAA (RFC 3596) e com o resto da tabela de tipos da IANA, 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 PTR 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 DNS over HTTPS (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 AD (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 OPT, que a RFC 6891 acrescentou à seção adicional (additional section): é o mecanismo de extensão chamado EDNS. O dig envia um registro OPT por padrão, com EDNS versão 0; `+noedns` remove esse registro. O bit DNSSEC 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, DNSKEY, DS e NSEC (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 SOA 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 YAML; e `+qr` mostra também a consulta do jeito que ela foi enviada. Por fim, as consultas assinadas. O TSIG 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: - [BIND 9 Administrator Reference Manual, Manual Pages: dig](https://bind9.readthedocs.io/en/latest/manpages.html#man-dig), a documentação "latest" (9.21) - [Fonte do BIND 9, bin/dig/dig.c](https://github.com/isc-projects/bind9/blob/main/bin/dig/dig.c): a ordem em que uma palavra solta é tentada (ixfr=, tipo, classe, nome) e o TCP por padrão para ANY e ixfr - [RFC 1035](https://www.rfc-editor.org/rfc/rfc1035): valores de TYPE e CLASS, porta 53, IN-ADDR.ARPA, os bits do cabeçalho - [RFC 3596](https://www.rfc-editor.org/rfc/rfc3596): AAAA e IP6.ARPA - [RFC 6891](https://www.rfc-editor.org/rfc/rfc6891): EDNS(0) e as regras de tamanho de carga; [RFC 3225](https://www.rfc-editor.org/rfc/rfc3225): o bit DO - [RFC 4034](https://www.rfc-editor.org/rfc/rfc4034) e [RFC 4035](https://www.rfc-editor.org/rfc/rfc4035): os registros DNSSEC, os bits CD e AD - [RFC 5936](https://www.rfc-editor.org/rfc/rfc5936) e [RFC 1995](https://www.rfc-editor.org/rfc/rfc1995): AXFR e IXFR; [RFC 3597](https://www.rfc-editor.org/rfc/rfc3597): tipos desconhecidos - [RFC 7858](https://www.rfc-editor.org/rfc/rfc7858) e [RFC 8484](https://www.rfc-editor.org/rfc/rfc8484): DNS sobre TLS e DNS sobre HTTPS - [RFC 5001](https://www.rfc-editor.org/rfc/rfc5001), [RFC 7871](https://www.rfc-editor.org/rfc/rfc7871), [RFC 7873](https://www.rfc-editor.org/rfc/rfc7873): NSID, Client Subnet, Cookies - [IANA DNS Parameters](https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml): o registro de RR TYPEs - [DNS Flag Day 2020](https://www.dnsflagday.net/2020/): a recomendação de 1232 bytes