O que faz

Você descreve a consulta; a página escreve a linha de comando do dig. Quatro grupos de controles correspondem às quatro coisas que uma invocação do dig diz:

  • O que consultar: um nome e um tipo de registro (A por padrão, qualquer mnemônico do registro da IANA, TYPEnn, ou os tipos de consulta ANY, AXFR e IXFR com o serial que você tem), uma classe (IN por padrão; CH e HS), ou um endereço para uma consulta reversa com -x, caso em que o dig deriva o nome PTR sozinho e o nome, o tipo e a classe não são escritos.
  • A quem perguntar: o servidor (@servidor, um nome de host ou um endereço IPv4 ou IPv6 sem colchetes), uma porta fora do padrão (-p), o transporte (UDP, +tcp, +tls, +https com o seu endpoint), uma família de endereços (-4, -6) e um endereço de origem (-b).
  • Como perguntar: +trace, +nssearch, +norecurse, +dnssec, +cd, +ignore; os controles de EDNS +bufsize, +subnet, +nsid, +nocookie, +noedns; e os tempos +timeout, +tries, +retry.
  • O que imprimir: a mensagem inteira, +short (com +identify), +noall +answer, ou +yaml; mais +multiline, +ttlunits e +qr.
  • Na sua máquina: -k arquivo para uma consulta assinada e -r para ignorar o ~/.digrc.

Três coisas voltam: o comando, numa ordem canônica, com um botão Copiar; os achados, onde uma combinação é contraditória, redundante ou provável de surpreender; e um resumo do que a consulta vai carregar, derivado dos padrões e interações que o manual declara: a pergunta que o dig vai pôr na mensagem, a quais servidores pergunta, o transporte e a porta depois dos padrões por tipo, se uma resposta UDP truncada é tentada de novo por TCP, e os bits RD, DO, CD e AD, o registro OPT do EDNS e o tamanho do buffer, o cookie, e se a consulta é assinada. Cada parte é explicada embaixo.

A ordem do comando

O dig lê a linha inteira e não se importa muito com a ordem, com duas exceções que o manual declara: as opções de consulta (as palavras com +) são sensíveis à ordem, e +short e +cmd são globais. O montador escreve uma ordem fixa para que a mesma intenção dê sempre os mesmos bytes: dig, @servidor, as opções (-r, -4/-6, -b, -p, -k), a pergunta (-x endereço, ou o nome, depois o tipo, depois a classe), e então as opções de consulta agrupadas em transporte, modo, bits do header, EDNS, tempos, saída. +noall é sempre escrito antes de +answer, porque eles se aplicam em sequência.

Os padrões não são escritos: tipo A, classe IN, porta 53 (853 para TLS, 443 para HTTPS), UDP. Um nome que também é mnemônico de tipo ou de classe (o domínio de topo ch, um host chamado literalmente mx) é escrito com -q, porque o dig lê as palavras soltas como tipos e classes antes de nomes; a nota do próprio manual sobre os domínios de topo IN e CH é a razão de a opção existir.

O que os achados verificam

Cada regra aponta para a frase do manual ou da RFC que a justifica:

  • +trace liga +dnssec e +cookie e desliga a recursão; @servidor então afeta só a consulta inicial pelos servidores da raiz. Pedir +dnssec ou +norecurse junto é sinalizado como redundante, e a nota sobre o servidor é mostrada.
  • +nssearch também desliga a recursão.
  • O tipo ANY e ixfr=N usam TCP por padrão; AXFR sempre usa TCP, e uma transferência sem @servidor iria para os resolvers do /etc/resolv.conf em vez de para um servidor que tem a zona (RFC 5936). ANY pode ter resposta mínima ou um registro HINFO sintetizado (RFC 8482).
  • +bufsize vai de 0 a 65535; um valor abaixo de 512 é tratado como 512 por quem recebe (RFC 6891, seção 6.2.3); acima de 4096 passa do ponto de partida sugerido pela RFC 6891; o DNS Flag Day 2020 nomeia 1232 como o tamanho mínimo seguro.
  • +bufsize=0 aparece como verificação: ele anuncia um buffer UDP de EDNS de 0 bytes, que quem recebe trata como 512. Ele não restaura o padrão; o manual dá essa função ao +bufsize sem valor. O padrão do dig é 1232 bytes (DEFAULT_EDNS_BUFSIZE no código-fonte da 9.20.29). A troca de 4096 para 1232 é a entrada 5516 do CHANGES do BIND, lançada na 9.17.6 e, portanto, presente em toda versão a partir da 9.18.0; no ramo 9.16 a mesma entrada chegou ao named, mas não ao dig, que manteve 4096 até a 9.16.50.
  • +dnssec, +trace, +bufsize, +nsid e +subnet vivem no registro OPT (RFC 6891; o bit DO é a RFC 3225), então +noedns não pode ser combinado com eles e não é escrito quando estão presentes.
  • +subnet=0 (ou um comprimento de prefixo 0) pede ao resolver que não use o seu endereço (RFC 7871).
  • -4 contra um literal IPv6 de servidor, ou -6 contra um IPv4, deixa o dig sem ter para onde mandar a consulta.
  • +timeout abaixo de 1 e +tries igual a 0 são silenciosamente elevados a 1 pelo dig.
  • +identify não faz nada sem +short; +ignore não faz nada sem UDP.
  • Só -k é oferecido para TSIG. O manual manda usá-lo em vez de -y, porque -y põe o segredo compartilhado na linha de comando, onde o ps e o histórico do shell o veem.

Limites

  • O montador emite uma consulta por comando. O dig aceita várias consultas numa linha, cada uma com as suas opções, e um arquivo de lote com -f; nenhum dos dois é modelado.
  • Ele não roda o dig, não resolve nada e não verifica se um servidor existe. O resumo é derivado das declarações do manual, não observado.
  • As opções não oferecidas (+aaonly, +besteffort, +cmd, +comments, +crypto, +domain, +ednsopt, +expire, +header-only, +keepopen, +ndots, +onesoa, +opcode, +padding, +proxy, +qid, +search, +split, +stats, +tls-ca e os demais arquivos de TLS, +unknownformat, +zoneversion, -c como opção, -f, -F, -m, -t como opção, -u, -y) estão documentadas no manual; as comuns estão aqui.
  • Os nomes são verificados pela forma (rótulos de letras, dígitos, hifens e sublinhados, de até 63 caracteres cada, até 253 no total; um asterisco sozinho como rótulo curinga); o montador não sabe se um nome existe.
  • O manual do dig lido para esta página é a documentação "latest" do BIND 9 (9.21) e, para o +bufsize, o manual estável da 9.20.29 (lido em 2026-10-19). Versões mais antigas do dig não têm algumas opções de consulta (+tls, +https, +yaml são recentes); o dig imprime "Invalid option" para uma palavra que não conhece.

API

O mesmo motor responde à operação /api/v1/dig-command-builder da API HTTP do site, descrita campo a campo no contrato OpenAPI da página da API, com exemplos tirados dos vetores de ouro. O contrato também diz se este site serve a API.

  • Requisição. Um objeto JSON com os campos do formulário: name, type, ixfrSerial, klass, reverse, server, port, ipv, source, transport, httpsEndpoint, bufsize, subnet, timeout, tries, retry, output e keyfile como strings, e as chaves trace, nssearch, norecurse, dnssec, cd, noedns, nocookie, nsid, ignore, identify, multiline, ttlunits, qr e norc como booleanos.
  • Resposta. ok, command, parts (text, kind e explain, o id da explicação), findings (code, severity e params) e effective, o que a consulta carrega.
  • Erros. Um achado de erro não é erro HTTP: ok vem false, command vem vazio e effective vem null. Um corpo que não é objeto JSON responde HTTP 400.

Desde 2026-10-19, {"name": "example.com", "bufsize": "0"} devolve o achado bufsize-default com severidade warning; antes era um info que dizia que 0 restaura o padrão.

Fontes