# dig command builder

> Say what to look up, where to ask and how, and get one copy-pasteable dig command with every token explained, the combinations the manual calls redundant or contradictory flagged, and a summary of what the query will carry: transport, port, RD, DO, CD, EDNS and cookie. The inverse of the dig output explainer. Runs nothing; built in your browser from the BIND 9 manual and the DNS RFCs.

- Tool: https://ronutz.com/en/tools/dig-command-builder
- Family: Networking

---

## What it does

You describe the query; the page writes the `dig` command line. Four groups of controls map onto the four things a dig invocation says:

- **What to look up:** a name and a record type (A by default, any mnemonic in the IANA registry, `TYPEnn`, or the query types ANY, AXFR and IXFR with the serial you hold), a class (IN by default; CH and HS), or an address for a reverse lookup with `-x`, in which case dig derives the PTR name itself and the name, type and class are not written.
- **Where to ask:** the server (`@server`, a host name or a bare IPv4 or IPv6 address), a non-standard port (`-p`), the transport (UDP, `+tcp`, `+tls`, `+https` with its endpoint), one address family (`-4`, `-6`) and a source address (`-b`).
- **How to ask:** `+trace`, `+nssearch`, `+norecurse`, `+dnssec`, `+cd`, `+ignore`; the EDNS controls `+bufsize`, `+subnet`, `+nsid`, `+nocookie`, `+noedns`; and the timers `+timeout`, `+tries`, `+retry`.
- **What to print:** the whole message, `+short` (with `+identify`), `+noall +answer`, or `+yaml`; plus `+multiline`, `+ttlunits` and `+qr`.
- **On your machine:** `-k keyfile` for a signed query and `-r` to ignore `~/.digrc`.

Three things come back: the command, in one canonical order, with a Copy button; findings, where a combination is contradictory, redundant or likely to surprise; and a summary of what the query will carry, derived from the manual's stated defaults and interactions: the question dig will put in the message, which servers are asked, the transport and port after the type defaults, whether a truncated UDP answer is retried over TCP, and the RD, DO, CD and AD bits, the EDNS OPT record and its buffer size, the cookie, and whether the query is signed. Every token is explained underneath.

## The order of the command

dig reads the whole line and does not care much about order, with two exceptions the manual states: query options (the `+` words) are order sensitive, and `+short` and `+cmd` are global. The builder writes one fixed order so the same intent always gives the same bytes: `dig`, `@server`, the options (`-r`, `-4`/`-6`, `-b`, `-p`, `-k`), the question (`-x address`, or the name, then the type, then the class), then the query options grouped as transport, mode, header bits, EDNS, timers, output. `+noall` is always written before `+answer` because they apply in sequence.

Defaults are not written: type A, class IN, port 53 (853 for TLS, 443 for HTTPS), UDP. A name that is also a type or class mnemonic (the `ch` top-level domain, a host literally called `mx`) is written with `-q`, because dig reads bare words as types and classes before names; the manual's own note about the IN and CH top-level domains is the reason the option exists.

## What the findings check

Each rule points at the sentence in the manual or the RFC that justifies it:

- `+trace` sets `+dnssec` and `+cookie` and disables recursion; `@server` then affects only the initial query for the root servers. Asking for `+dnssec` or `+norecurse` alongside is flagged as redundant, and the server note is shown.
- `+nssearch` disables recursion too.
- Type ANY and `ixfr=N` default to TCP; AXFR always uses TCP, and a transfer with no `@server` would go to the resolvers in `/etc/resolv.conf` rather than to a server that holds the zone (RFC 5936). ANY may be answered minimally or with a synthesised HINFO record (RFC 8482).
- `+bufsize` is 0 to 65535; a value under 512 is treated as 512 by the receiver (RFC 6891, section 6.2.3); above 4096 is more than RFC 6891's suggested starting point; DNS Flag Day 2020 names 1232 as the minimum safe size.
- `+bufsize=0` is flagged as a check: it advertises a 0-byte EDNS UDP buffer, which the receiver treats as 512. It does not restore the default; the manual gives that job to `+bufsize` with no value. dig's default is 1232 bytes (`DEFAULT_EDNS_BUFSIZE` in the 9.20.29 source). The change from 4096 to 1232 is BIND CHANGES entry 5516, released in 9.17.6 and so in every release from 9.18.0; in the 9.16 branch the same entry reached `named` but not dig, which kept 4096 through 9.16.50.
- `+dnssec`, `+trace`, `+bufsize`, `+nsid` and `+subnet` live in the OPT record (RFC 6891; the DO bit is RFC 3225), so `+noedns` cannot be combined with them and is not written when they are present.
- `+subnet=0` (or a prefix length of 0) asks the resolver not to use your address (RFC 7871).
- `-4` against an IPv6 server literal, or `-6` against an IPv4 one, leaves dig with nowhere to send the query.
- `+timeout` below 1 and `+tries` of 0 are silently raised to 1 by dig.
- `+identify` does nothing without `+short`; `+ignore` does nothing without UDP.
- Only `-k` is offered for TSIG. The manual says to use it rather than `-y`, because `-y` puts the shared secret on the command line where `ps` and the shell history can see it.

## Limits

- The builder emits one lookup per command. dig can take several queries on one line, each with its own options, and a batch file with `-f`; neither is modelled.
- It does not run dig, resolve anything or check that a server exists. The summary is derived from the manual's statements, not observed.
- Options not offered (`+aaonly`, `+besteffort`, `+cmd`, `+comments`, `+crypto`, `+domain`, `+ednsopt`, `+expire`, `+header-only`, `+keepopen`, `+ndots`, `+onesoa`, `+opcode`, `+padding`, `+proxy`, `+qid`, `+search`, `+split`, `+stats`, `+tls-ca` and the other TLS files, `+unknownformat`, `+zoneversion`, `-c` as an option, `-f`, `-F`, `-m`, `-t` as an option, `-u`, `-y`) are documented in the manual; the common ones are here.
- Names are checked for shape (labels of letters, digits, hyphens and underscores, at most 63 characters each, at most 253 in all; a lone asterisk as a wildcard label); the builder does not know whether a name exists.
- The dig manual read for this page is the BIND 9 "latest" documentation (9.21), and for `+bufsize` the stable 9.20.29 manual (read 2026-10-19). Older dig versions lack some query options (`+tls`, `+https`, `+yaml` are recent); dig prints "Invalid option" for a word it does not know.

## API

The same engine answers the `/api/v1/dig-command-builder` operation of the site's HTTP API, written out field by field in the OpenAPI contract on the [API page](https://ronutz.com/en/api), with examples taken from the golden vectors. The contract also says whether this site serves the API.

- **Request.** A JSON object with the form's fields: `name`, `type`, `ixfrSerial`, `klass`, `reverse`, `server`, `port`, `ipv`, `source`, `transport`, `httpsEndpoint`, `bufsize`, `subnet`, `timeout`, `tries`, `retry`, `output` and `keyfile` as strings, and the switches `trace`, `nssearch`, `norecurse`, `dnssec`, `cd`, `noedns`, `nocookie`, `nsid`, `ignore`, `identify`, `multiline`, `ttlunits`, `qr` and `norc` as booleans.
- **Response.** `ok`, `command`, `parts` (`text`, `kind` and `explain`, the id of the explanation), `findings` (`code`, `severity` and `params`) and `effective`, what the query carries.
- **Errors.** An error finding is not an HTTP error: `ok` is `false`, `command` is empty and `effective` is `null`. A body that is not a JSON object answers HTTP 400.

Since 2026-10-19, `{"name": "example.com", "bufsize": "0"}` returns the finding `bufsize-default` with severity `warning`; it was an `info` that said 0 restores the default.

## Sources

- [BIND 9 Administrator Reference Manual, Manual Pages: dig](https://bind9.readthedocs.io/en/latest/manpages.html#man-dig) (read 2026-10-04): every option and query option, the defaults and the interactions quoted above
- [BIND 9 source, bin/dig/dig.c](https://github.com/isc-projects/bind9/blob/main/bin/dig/dig.c) (read 2026-10-04): the order in which a bare word is tried (ixfr=, type, class, name), and the TCP default for ANY and ixfr
- [RFC 1035: Domain Names - Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035) (read 2026-10-04): TYPE and CLASS values, port 53, the 512-byte UDP limit, IN-ADDR.ARPA, label and name lengths, the RD bit
- [RFC 3596: DNS Extensions to Support IP Version 6](https://www.rfc-editor.org/rfc/rfc3596) (read 2026-10-04): AAAA and the IP6.ARPA nibble form
- [RFC 6891: Extension Mechanisms for DNS (EDNS(0))](https://www.rfc-editor.org/rfc/rfc6891) (read 2026-10-04): the OPT record, the payload size rules, 4096 as a starting point
- [RFC 3225: Indicating Resolver Support of DNSSEC](https://www.rfc-editor.org/rfc/rfc3225) (read 2026-10-04): the DO bit
- [RFC 4034](https://www.rfc-editor.org/rfc/rfc4034) and [RFC 4035](https://www.rfc-editor.org/rfc/rfc4035) (read 2026-10-04): the DNSSEC record types; the CD and AD bits
- [RFC 5936: DNS Zone Transfer Protocol (AXFR)](https://www.rfc-editor.org/rfc/rfc5936) and [RFC 1995: Incremental Zone Transfer in DNS](https://www.rfc-editor.org/rfc/rfc1995) (read 2026-10-04)
- [RFC 8482: Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY](https://www.rfc-editor.org/rfc/rfc8482) (read 2026-10-04)
- [RFC 7858: DNS over TLS](https://www.rfc-editor.org/rfc/rfc7858) and [RFC 8484: DNS Queries over HTTPS](https://www.rfc-editor.org/rfc/rfc8484) (read 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) (read 2026-10-04)
- [IANA: Domain Name System (DNS) Parameters](https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml) (read 2026-10-04): the RR TYPE registry the type field accepts, and the EDNS option codes
- [ISC, BIND 9 9.20.29 documentation, Manual Pages: dig](https://bind9.readthedocs.io/en/stable/manpages.html) (read 2026-10-19): `+bufsize[=B]` sets the advertised size to B bytes, 0 to 65535; `+bufsize` with no value restores the default
- [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) (read 2026-10-19): `DEFAULT_EDNS_BUFSIZE 1232`
- [ISC, BIND 9.18.0 CHANGES](https://downloads.isc.org/isc/bind9/9.18.0/CHANGES) (read 2026-10-19): entry 5516 under 9.17.6, the default EDNS buffer size changed from 4096 to 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) (read 2026-10-19): `DEFAULT_EDNS_BUFSIZE 4096`, dig's default in the 9.16 branch
- [DNS Flag Day 2020](https://www.dnsflagday.net/2020/) (read 2026-10-04): 1232 bytes as the minimum safe EDNS buffer size
- [RFC 5737](https://www.rfc-editor.org/rfc/rfc5737) and [RFC 3849](https://www.rfc-editor.org/rfc/rfc3849) (read 2026-10-04): the documentation address ranges used in the examples (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

- [Anatomy of a dig command line: how dig reads what you type](https://ronutz.com/en/learn/anatomy-of-a-dig-command-line.md): dig takes a server after an @, options with a dash, a name, a type, a class and query options with a plus, in almost any order, and fills in a default for everything you leave out. This article walks the line from left to right: which words are positional and how dig tells a name from a type, why the plus options are order sensitive and two of them are global, how the transport is decided (UDP with a TCP retry, TCP for ANY and transfers, TLS and HTTPS on their own ports), which switches change header bits and which travel in the EDNS OPT record, what +trace and +nssearch do to recursion, and why the manual tells you to keep a TSIG secret in a file. Each statement is the BIND 9 manual's or an RFC's, cited.
- [Anycast: one address in many places](https://ronutz.com/en/learn/anycast.md): Anycast announces one service address from many independent places and lets the routing system decide which one each client reaches. After reading you can define it in the words of RFC 1546 and BCP 126, explain why nearest means nearest in the routing table rather than on the map, say why DNS over UDP suits it and TCP strains it, read the root server list on root-servers.org, and run a dig query that reveals which instance answered you.
- [Authoritative vs Non-Authoritative Answers](https://ronutz.com/en/learn/authoritative-vs-non-authoritative-answers.md): An answer is authoritative when the server that sent it holds the zone for the name you asked about, and it says so with one bit of the DNS header, the AA bit, which nslookup reports as the Non-authoritative answer marker and dig as the aa flag. After reading, you can tell a cached answer from a referral, explain why a recursive lookup is non-authoritative by design, ask a zone's own server with recursion turned off and read aa in the reply, and say what the bit still does not prove.
- [dig Query Options and Output Control](https://ronutz.com/en/learn/dig-query-options.md): dig's real power is its options: choosing the server to ask, the record type, and exactly how much of the answer to print. This covers the handful you will actually use every day, from @server and -t to +short and the +noall +answer combination that trims dig down to just the records.
- [DNSSEC end to end: from the root's key to a validated answer](https://ronutz.com/en/learn/dnssec-end-to-end.md): After reading, you can follow a DNSSEC validation from the root's trust anchor down to a signed answer, name the record that carries each link, and say why a resolver returned SERVFAIL, an ad flag, or nothing special at all. You will also know which root key is signing today, which algorithms the IANA registry still allows, and how to check a validation yourself with dig and delv.
- [DoT, DoH and DoQ compared: encrypting the question](https://ronutz.com/en/learn/encrypted-dns-dot-doh-doq.md): Classic DNS sends every question in the clear, and the leg between the stub resolver and the recursive resolver is where an eavesdropper learns the most. DoT, DoH and DoQ encrypt that leg in three different ways. After reading you can say what each one hides and what none of them hides, read their ports and framing, tell a Strict profile from an Opportunistic one, explain how a client discovers an encrypted resolver, and choose a transport for a given network with the standards' own reasons.
- [Private IPv4 address space and RFC 1918](https://ronutz.com/en/learn/private-address-space.md): RFC 1918, Best Current Practice 5 since February 1996, reserves 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 for addresses any enterprise may use internally: unique only inside it, and kept out of the internet's routing and its DNS. After reading, you can give each block's exact bounds and size, apply RFC 1918's rules for border routers and DNS, explain why merging two private networks forces renumbering, tell a reverse lookup answered locally from one that leaked to the AS112 sink, and check each point with ip, dig and Python.
- [Public DNS resolvers: what you are actually choosing](https://ronutz.com/en/learn/choosing-a-public-dns-resolver.md): A public resolver is a recursive resolver anyone may use, and switching to one hands the operator every name your device looks up. What separates 1.1.1.1, 8.8.8.8, 9.9.9.9 and 208.67.222.222 is policy, not speed: what is logged and for how long, which addresses filter and how a block answers, whether DNSSEC is validated, whether your subnet is passed to authoritative servers, and which encrypted transports are offered. After reading, you can read an operator's pages against the list RFC 8932 asks it to publish, choose by those criteria, and test each one with dig and curl.
- [Reading a DNS answer: the line you skipped is the diagnosis](https://ronutz.com/en/learn/reading-a-dns-answer.md): A DNS answer printed by dig or nslookup is the whole reply message: a header with flags and a response code, the question, an OPT pseudo-record and up to three sections of records, of which the address is one line. After reading, you can tell who answered and with what authority, read the flags, the OPT line, the TTLs and the failure codes, ask the authoritative server directly, follow a delegation with +trace, and find the part of this series that goes deeper on each line.
- [Reading dig Output From Top to Bottom](https://ronutz.com/en/learn/reading-dig-output.md): dig prints every DNS answer in the same fixed shape: the version and options lines, the header line, the flags and counts line, the OPT pseudosection, the sections that have records, and four statistics lines. After reading, you can walk any dig answer block by block, name what each line reports, recognise NODATA, NXDOMAIN, SERVFAIL and a truncated answer from the shape alone, and choose the shorter forms a script needs.
- [Reading the Records in a dig Answer](https://ronutz.com/en/learn/dns-record-types-in-answers.md): Every record dig prints is one resource record in five columns: owner name, TTL, class, type and the type-specific data, with the wire's length field left out. After reading, you can name each column, decode the data of A, AAAA, CNAME, NS, SOA, MX, TXT, PTR, SRV and CAA records, tell a counting-down cache TTL from a zone TTL, follow a CNAME chain to the name that owns the status code, and spot the aliases, timers and quoting mistakes that make a correct-looking answer fail.
- [Running IPv6 and IPv4 together: dual-stack and translation](https://ronutz.com/en/learn/ipv6-transition.md): IPv4 and IPv6 cannot exchange packets, so networks run both side by side, carry IPv6 inside IPv4, or translate one protocol into the other. After reading, you can predict which family a dual-stack host tries first, build 6to4, Teredo, 6rd and NAT64 addresses by hand, follow a NAT64 and DNS64 session step by step, explain why 464XLAT translates rather than tunnels, and recognise the failures these mechanisms cause with IPv4 literals, signed DNS answers and packet sizes.
- [The DNS Header: Opcode, Status, and Flags](https://ronutz.com/en/learn/dns-message-header-and-flags.md): Every DNS message opens with the same 12-byte header: a 16-bit ID, a flags word that holds the opcode, seven named flags, a reserved bit and the response code, and four section counts, which dig prints as its header and flags lines. After reading, you can decode a header from its hexadecimal bytes, say what each flag, opcode and status tells a diagnosis, recognise a truncated answer and test the TCP retry it needs, and explain why the ID and the source port must be unpredictable.
- [Zone transfers and NOTIFY: how secondary name servers stay in step](https://ronutz.com/en/learn/dns-zone-transfers-and-notify.md): Every DNS zone has to be served by at least two authoritative servers, and their copies have to agree. After reading you will be able to read the timers in a zone's SOA record and predict when a secondary polls, recognise an AXFR, IXFR or NOTIFY exchange in a packet capture, explain why transfers are restricted and encrypted, and check with dig whether a zone's servers carry the same serial.