# Montador de comandos dig

> Diga o que consultar, a quem perguntar e como, e receba um comando dig pronto para colar, com cada parte explicada, as combinações que o manual chama de redundantes ou contraditórias sinalizadas, e um resumo do que a consulta vai carregar: transporte, porta, RD, DO, CD, EDNS e cookie. O inverso do explicador de saída do dig. Não executa nada; montado no seu navegador a partir do manual do BIND 9 e das RFCs do DNS.

- Tool: https://ronutz.com/pt-BR/tools/dig-command-builder
- Family: Redes

---

## 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](https://ronutz.com/pt-BR/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

- [BIND 9 Administrator Reference Manual, Manual Pages: dig](https://bind9.readthedocs.io/en/latest/manpages.html#man-dig) (lido em 2026-10-04): cada opção e opção de consulta, os padrões e as interações citadas acima
- [Fonte do BIND 9, bin/dig/dig.c](https://github.com/isc-projects/bind9/blob/main/bin/dig/dig.c) (lido em 2026-10-04): a ordem em que uma palavra solta é tentada (ixfr=, tipo, classe, nome), e o TCP por padrão para ANY e ixfr
- [RFC 1035: Domain Names - Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035) (lida em 2026-10-04): valores de TYPE e CLASS, porta 53, o limite de 512 bytes do UDP, IN-ADDR.ARPA, comprimentos de rótulo e de nome, o bit RD
- [RFC 3596: DNS Extensions to Support IP Version 6](https://www.rfc-editor.org/rfc/rfc3596) (lida em 2026-10-04): AAAA e a forma em nibbles do IP6.ARPA
- [RFC 6891: Extension Mechanisms for DNS (EDNS(0))](https://www.rfc-editor.org/rfc/rfc6891) (lida em 2026-10-04): o registro OPT, as regras de tamanho de carga, 4096 como ponto de partida
- [RFC 3225: Indicating Resolver Support of DNSSEC](https://www.rfc-editor.org/rfc/rfc3225) (lida em 2026-10-04): o bit DO
- [RFC 4034](https://www.rfc-editor.org/rfc/rfc4034) e [RFC 4035](https://www.rfc-editor.org/rfc/rfc4035) (lidas em 2026-10-04): os tipos de registro do DNSSEC; os bits CD e AD
- [RFC 5936: DNS Zone Transfer Protocol (AXFR)](https://www.rfc-editor.org/rfc/rfc5936) e [RFC 1995: Incremental Zone Transfer in DNS](https://www.rfc-editor.org/rfc/rfc1995) (lidas em 2026-10-04)
- [RFC 8482: Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY](https://www.rfc-editor.org/rfc/rfc8482) (lida em 2026-10-04)
- [RFC 7858: DNS over TLS](https://www.rfc-editor.org/rfc/rfc7858) e [RFC 8484: DNS Queries over HTTPS](https://www.rfc-editor.org/rfc/rfc8484) (lidas em 2026-10-04)
- [RFC 5001: NSID](https://www.rfc-editor.org/rfc/rfc5001), [RFC 7871: Client Subnet in DNS Queries](https://www.rfc-editor.org/rfc/rfc7871), [RFC 7873: DNS Cookies](https://www.rfc-editor.org/rfc/rfc7873) (lidas em 2026-10-04)
- [IANA: Domain Name System (DNS) Parameters](https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml) (lido em 2026-10-04): o registro de RR TYPEs que o campo de tipo aceita, e os códigos de opção do EDNS
- [ISC, BIND 9 9.20.29 documentation, Manual Pages: dig](https://bind9.readthedocs.io/en/stable/manpages.html) (lido em 2026-10-19): `+bufsize[=B]` define o tamanho anunciado em B bytes, de 0 a 65535; `+bufsize` sem valor restaura o padrão
- [BIND 9 source at tag v9.20.29, bin/dig/dighost.h](https://github.com/isc-projects/bind9/blob/v9.20.29/bin/dig/dighost.h) (lido em 2026-10-19): `DEFAULT_EDNS_BUFSIZE 1232`
- [ISC, BIND 9.18.0 CHANGES](https://downloads.isc.org/isc/bind9/9.18.0/CHANGES) (lido em 2026-10-19): a entrada 5516, sob a 9.17.6, muda o tamanho padrão do buffer EDNS de 4096 para 1232 bytes
- [BIND 9 source at tag v9.16.50, bin/dig/include/dig/dig.h](https://github.com/isc-projects/bind9/blob/v9.16.50/bin/dig/include/dig/dig.h) (lido em 2026-10-19): `DEFAULT_EDNS_BUFSIZE 4096`, o padrão do dig no ramo 9.16
- [DNS Flag Day 2020](https://www.dnsflagday.net/2020/) (lido em 2026-10-04): 1232 bytes como o tamanho mínimo seguro de buffer EDNS
- [RFC 5737](https://www.rfc-editor.org/rfc/rfc5737) e [RFC 3849](https://www.rfc-editor.org/rfc/rfc3849) (lidas em 2026-10-04): as faixas de endereços de documentação usadas nos exemplos (192.0.2.0/24, 2001:db8::/32)

## Standards and references

- [BIND 9 Administrator Reference Manual, Manual Pages: dig - DNS lookup utility (latest, 9.21)](https://bind9.readthedocs.io/en/latest/manpages.html#man-dig) - the synopsis and every option and query option this builder emits: @server, -4, -6, -b, -c, -k, -p, -q, -r, -t, -x, +bufsize, +cd, +cookie, +dnssec, +edns, +https, +identify, +ignore, +multiline, +noall, +answer, +nsid, +nssearch, +qr, +recurse, +retry, +short, +subnet, +tcp, +timeout, +tls, +trace, +tries, +ttlunits, +yaml; the defaults (A, IN, port 53, UDP, RD set, AD set, EDNS 0, cookie on, timeout 5, tries 3, retry 2); the interactions (+trace sets +dnssec and +cookie and disables recursion, as does +nssearch; @server with +trace affects only the root query; type any and ixfr=N default to TCP, AXFR always uses TCP; +ignore stops the TCP retry on truncation; +short and +cmd are global); the note that only -k should be used, because -y shows the secret in ps output and shell history
- [BIND 9 source, bin/dig/dig.c (isc-projects/bind9 on GitHub, main branch)](https://github.com/isc-projects/bind9/blob/main/bin/dig/dig.c) - how a bare command-line word is classified: tried as ixfr=N, then as a record type (dns_rdatatype_fromtext), then as a class (dns_rdataclass_fromtext), and only then taken as the name; -t and -c close that reading (open_type_class = false), -q sets the name directly; type ANY and ixfr=N switch tcp_mode on unless +tcp/+notcp was given
- [RFC 1035: Domain Names - Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035) - section 3.2.2 TYPE values (A 1, NS 2, CNAME 5, SOA 6, PTR 12, MX 15, TXT 16), 3.2.3 QTYPEs (AXFR 252, * 255), 3.2.4 CLASS values (IN 1, CH 3, HS 4); 2.3.4 labels of 63 octets or less and names of 255 octets or less; 3.5 the IN-ADDR.ARPA domain; 4.2 UDP and TCP on server port 53, UDP messages restricted to 512 bytes; 4.1.1 the RD bit
- [RFC 3596: DNS Extensions to Support IP Version 6](https://www.rfc-editor.org/rfc/rfc3596) - the AAAA type is 28; an IPv6 address is represented in the IP6.ARPA domain as a sequence of nibbles separated by dots with the suffix .IP6.ARPA
- [RFC 6891: Extension Mechanisms for DNS (EDNS(0))](https://www.rfc-editor.org/rfc/rfc6891) - the OPT pseudo-RR carries the requestor's UDP payload size and the options; section 6.2.3: values lower than 512 MUST be treated as equal to 512; section 6.2.5: 4096 octets as a starting point, with a fallback around 1280 to 1410 bytes
- [RFC 3225: Indicating Resolver Support of DNSSEC](https://www.rfc-editor.org/rfc/rfc3225) - the DNSSEC OK (DO) bit is the first bit of the extended flags in the EDNS0 OPT meta-RR; setting it tells the server the resolver accepts DNSSEC security RRs
- [RFC 4034: Resource Records for the DNS Security Extensions](https://www.rfc-editor.org/rfc/rfc4034) - the type values DNSKEY 48, RRSIG 46, NSEC 47, DS 43
- [RFC 4035: Protocol Modifications for the DNS Security Extensions](https://www.rfc-editor.org/rfc/rfc4035) - the CD (Checking Disabled) and AD (Authentic Data) header bits; a security-aware server MUST NOT set AD in a response unless the data was authenticated; the CD bit from a query is copied into the response
- [RFC 5936: DNS Zone Transfer Protocol (AXFR)](https://www.rfc-editor.org/rfc/rfc5936) - AXFR is done only via TCP connections; the mechanism by which a zone is copied from the server that holds it
- [RFC 1995: Incremental Zone Transfer in DNS](https://www.rfc-editor.org/rfc/rfc1995) - the IXFR query type is 251; the client sends the serial of its copy of the zone; transport may be UDP or TCP
- [RFC 8482: Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY](https://www.rfc-editor.org/rfc/rfc8482) - a responder may answer an ANY query with a subset of the records or a synthesised HINFO record rather than everything it holds
- [RFC 7858: Specification for DNS over Transport Layer Security (TLS)](https://www.rfc-editor.org/rfc/rfc7858) - DNS over TLS servers listen on and clients connect to TCP port 853 unless another port is mutually agreed
- [RFC 8484: DNS Queries over HTTPS (DoH)](https://www.rfc-editor.org/rfc/rfc8484) - DNS messages carried in HTTP/2 requests with the application/dns-message media type; the URI template is the server's to publish (dig's default endpoint /dns-query comes from the dig manual)
- [RFC 5001: DNS Name Server Identifier (NSID) Option](https://www.rfc-editor.org/rfc/rfc5001) - EDNS option code 3; the server returns an identifier of the instance that answered
- [RFC 7871: Client Subnet in DNS Queries](https://www.rfc-editor.org/rfc/rfc7871) - EDNS option code 8; a SOURCE PREFIX-LENGTH of 0 tells the resolver not to use the client's address information
- [RFC 7873: Domain Name System (DNS) Cookies](https://www.rfc-editor.org/rfc/rfc7873) - EDNS option code 10; a lightweight transaction security mechanism against off-path attackers
- [IANA: Domain Name System (DNS) Parameters, Resource Record (RR) TYPEs and DNS EDNS0 Option Codes](https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml) - the registry of RR TYPE mnemonics and numbers the type field accepts (A 1 to DLV 32769, with * 255 written ANY), and the EDNS option codes NSID 3, edns-client-subnet 8, COOKIE 10
- [ISC, BIND 9 9.20.29 documentation, Manual Pages: dig - DNS lookup utility (stable)](https://bind9.readthedocs.io/en/stable/manpages.html) - +bufsize[=B]: sets the UDP message buffer size advertised using EDNS0 to B bytes, 0 to 65535; +bufsize with no value restores the default buffer size (so +bufsize=0 advertises 0)
- [BIND 9 source at tag v9.20.29, bin/dig/dighost.h](https://github.com/isc-projects/bind9/blob/v9.20.29/bin/dig/dighost.h) - #define DEFAULT_EDNS_BUFSIZE 1232: the size dig advertises when nothing sets it (and what a bare +bufsize restores, bin/dig/dig.c)
- [ISC, BIND 9.18.0 CHANGES](https://downloads.isc.org/isc/bind9/9.18.0/CHANGES) - entry 5516, under 9.17.6: the default EDNS buffer size has been changed from 4096 to 1232 bytes [GL #2183]; dig's DEFAULT_EDNS_BUFSIZE is 1232 from v9.17.6 and in every release from 9.18.0
- [BIND 9 source at tag v9.16.50, bin/dig/include/dig/dig.h](https://github.com/isc-projects/bind9/blob/v9.16.50/bin/dig/include/dig/dig.h) - #define DEFAULT_EDNS_BUFSIZE 4096: in the 9.16 branch the 1232 change (9.16.8, entry 5516) reached named, not dig
- [DNS Flag Day 2020](https://www.dnsflagday.net/2020/) - defaults in DNS software should reflect the minimum safe EDNS buffer size, which is 1232 bytes, to avoid IP fragmentation
- [RFC 5737: IPv4 Address Blocks Reserved for Documentation](https://www.rfc-editor.org/rfc/rfc5737) - 192.0.2.0/24 (TEST-NET-1) is reserved for documentation: the resolver address in the examples here is not a real resolver
- [RFC 3849: IPv6 Address Prefix Reserved for Documentation](https://www.rfc-editor.org/rfc/rfc3849) - 2001:DB8::/32 is reserved for documentation: the IPv6 addresses in the examples here are not real hosts

## Related reading

- [Anatomia da linha de comando do dig: como o dig interpreta o que você digita](https://ronutz.com/pt-BR/learn/anatomy-of-a-dig-command-line.md): 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.
- [Anycast: um endereço em muitos lugares](https://ronutz.com/pt-BR/learn/anycast.md): O anycast anuncia um mesmo endereço de serviço a partir de muitos lugares independentes e deixa o sistema de roteamento decidir qual deles cada cliente alcança. Depois de ler, você consegue defini-lo nas palavras da RFC 1546 e da BCP 126, explicar por que mais próximo quer dizer mais próximo na tabela de rotas e não no mapa, dizer por que o DNS sobre UDP se encaixa nele e o TCP sofre, ler a lista de servidores raiz do root-servers.org e rodar uma consulta dig que revela qual instância respondeu a você.
- [Como ler a saída do dig de cima a baixo](https://ronutz.com/pt-BR/learn/reading-dig-output.md): O dig imprime toda resposta DNS na mesma forma fixa: as linhas de versão e de opções, a linha do header, a linha de flags e contagens, a pseudo-seção OPT, as seções que têm registros e quatro linhas de estatísticas. Depois da leitura, você consegue percorrer qualquer resposta do dig bloco a bloco, dizer o que cada linha informa, reconhecer NODATA, NXDOMAIN, SERVFAIL e uma resposta truncada só pela forma, e escolher as formas mais curtas que um script precisa.
- [Como ler os registros em uma resposta do dig](https://ronutz.com/pt-BR/learn/dns-record-types-in-answers.md): Cada registro que o dig imprime é um resource record em cinco colunas: nome do owner, TTL, classe, tipo e os dados específicos do tipo, sem o campo de comprimento que viaja na mensagem. Depois da leitura, você consegue nomear cada coluna, decodificar os dados de registros A, AAAA, CNAME, NS, SOA, MX, TXT, PTR, SRV e CAA, distinguir o TTL decrescente de um cache do TTL da zona, seguir uma cadeia de CNAME até o nome que define o código de status e reconhecer os aliases, timers e erros de aspas que fazem uma resposta aparentemente correta falhar.
- [Como ler uma resposta de DNS: o diagnóstico está na linha que você pulou](https://ronutz.com/pt-BR/learn/reading-a-dns-answer.md): Uma resposta de DNS mostrada pelo dig ou pelo nslookup é a mensagem de resposta inteira: um header com flags e um código de resposta, a pergunta, um pseudorregistro OPT e até três seções de registros, nas quais o endereço é uma linha só. Depois da leitura, você consegue dizer quem respondeu e com que autoridade, ler as flags, a linha OPT, os TTLs e os códigos de falha, perguntar direto ao servidor autoritativo, seguir uma delegação com +trace e achar a parte desta série que aprofunda cada linha.
- [Como rodar IPv6 e IPv4 juntos: dual-stack e tradução](https://ronutz.com/pt-BR/learn/ipv6-transition.md): IPv4 e IPv6 não trocam pacotes entre si, então as redes rodam os dois lado a lado, carregam IPv6 dentro de IPv4 ou traduzem um protocolo no outro. Depois da leitura, você consegue prever qual família um host dual-stack tenta primeiro, montar à mão endereços 6to4, Teredo, 6rd e NAT64, acompanhar passo a passo uma sessão NAT64 com DNS64, explicar por que o 464XLAT traduz em vez de tunelar e reconhecer as falhas que esses mecanismos causam com literais IPv4, respostas DNS assinadas e tamanho de pacote.
- [DNSSEC de ponta a ponta: da chave da raiz à resposta validada](https://ronutz.com/pt-BR/learn/dnssec-end-to-end.md): Depois de ler, você consegue acompanhar uma validação DNSSEC desde o trust anchor da raiz até a resposta assinada, nomear o registro que carrega cada elo e explicar por que um resolver devolveu SERVFAIL, uma flag ad ou nada de especial. Também vai saber qual chave da raiz está assinando hoje, quais algoritmos o registro da IANA ainda permite e como conferir uma validação com dig e delv.
- [DoT, DoH e DoQ comparados: como cifrar a pergunta](https://ronutz.com/pt-BR/learn/encrypted-dns-dot-doh-doq.md): O DNS clássico manda toda pergunta às claras, e o trecho entre o stub resolver e o resolver recursivo é onde quem escuta aprende mais. DoT, DoH e DoQ cifram esse trecho de três maneiras diferentes. Depois da leitura você consegue dizer o que cada um esconde e o que nenhum deles esconde, ler suas portas e seu enquadramento, distinguir o perfil Strict do Opportunistic, explicar como um cliente descobre um resolver cifrado e escolher um transporte para uma rede com os argumentos dos próprios padrões.
- [Espaço de endereços IPv4 privados e a RFC 1918](https://ronutz.com/pt-BR/learn/private-address-space.md): A RFC 1918, Best Current Practice 5 desde fevereiro de 1996, reserva 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16 para endereços que qualquer organização pode usar internamente: únicos só dentro dela e mantidos fora do roteamento e do DNS da internet. Depois da leitura, você consegue dar os limites e o tamanho exatos de cada bloco, aplicar as regras da RFC 1918 para roteadores de borda e DNS, explicar por que juntar duas redes privadas obriga a renumerar, distinguir uma consulta reversa respondida localmente de uma que vazou para o sumidouro AS112 e conferir cada ponto com ip, dig e Python.
- [O cabeçalho DNS: opcode, status e flags](https://ronutz.com/pt-BR/learn/dns-message-header-and-flags.md): Toda mensagem DNS começa com o mesmo header de 12 bytes: um ID de 16 bits, uma palavra de flags que guarda o opcode, sete flags nomeadas, um bit reservado e o código de resposta, e quatro contadores de seção, que o dig imprime como as linhas de header e de flags. Depois da leitura, você consegue decodificar um header a partir dos bytes em hexadecimal, dizer o que cada flag, opcode e status conta para um diagnóstico, reconhecer uma resposta truncada e testar a repetição por TCP que ela exige, e explicar por que o ID e a porta de origem precisam ser imprevisíveis.
- [Opções de consulta do dig e como controlar a saída](https://ronutz.com/pt-BR/learn/dig-query-options.md): O poder de verdade do dig está nas opções: escolher a qual servidor perguntar, o tipo de registro e exatamente quanto da resposta mostrar. O artigo cobre as poucas que você vai usar todo dia, do @servidor e do -t ao +short e à combinação +noall +answer, que deixa na saída do dig só os registros.
- [Resolvedores DNS públicos: o que você está de fato escolhendo](https://ronutz.com/pt-BR/learn/choosing-a-public-dns-resolver.md): Um resolver público é um resolver recursivo que qualquer pessoa pode usar, e trocar para um deles entrega ao operador todo nome que o seu dispositivo consulta. O que separa 1.1.1.1, 8.8.8.8, 9.9.9.9 e 208.67.222.222 é política, não velocidade: o que é registrado e por quanto tempo, quais endereços filtram e como um bloqueio responde, se há validação DNSSEC, se a sua sub-rede é repassada aos servidores autoritativos e quais transportes cifrados são oferecidos. Depois da leitura, você consegue ler as páginas de um operador contra a lista que a RFC 8932 pede que ele publique, escolher por esses critérios e testar cada um com dig e curl.
- [Respostas autoritativas vs não autoritativas](https://ronutz.com/pt-BR/learn/authoritative-vs-non-authoritative-answers.md): Uma resposta é autoritativa quando o servidor que a enviou mantém a zona do nome perguntado, e ele diz isso com um único bit do header de DNS, o bit AA, que o nslookup mostra como o marcador Non-authoritative answer e o dig como a flag aa. Depois da leitura, você consegue distinguir uma resposta de cache de um referral, explicar por que uma consulta recursiva é não autoritativa por desenho, perguntar ao servidor da própria zona com a recursão desligada e ler aa na resposta, e dizer o que o bit ainda assim não prova.
- [Transferências de zona e NOTIFY: como os servidores secundários ficam em dia](https://ronutz.com/pt-BR/learn/dns-zone-transfers-and-notify.md): Toda zona DNS precisa ser servida por pelo menos dois servidores autoritativos, e as cópias precisam concordar. Depois da leitura, você vai saber ler os timers do registro SOA de uma zona e prever quando o secondary faz polling, reconhecer uma troca AXFR, IXFR ou NOTIFY numa captura de pacotes, explicar por que as transferências são restringidas e cifradas, e conferir com o dig se os servidores de uma zona têm o mesmo serial.