DNS notes

The main RFCs to consider are RFC1034 and RFC1035, concepts and implementation respectively. The difference of the two RFCs can be illustrated with an example: RFC1034 will tell you about the kind of content RDATA has depending on the QTYPE/QCLASS, such as a 32-bit address (A query), a domain name (CNAME query) and so on, while RFC1035 will talk about what bits will appear on the wire when this happens, i.e. the actual format of the packets.

One good RFC to start with is RFC9499, "DNS Terminology", which brings the reader to contemporary usage of terminology surrounding DNS. The totality of DNS parameters registered with the IANA are documented in the IANA DNS page. A network analyzer like Wireshark is a must when poking around with DNS tools to learn the wire format..

I briefly made the following categorization of some RFCs based on the map above and their abstracts, although it should not be considered comprehensive:

• Extension mechanisms, EDNS
  • RFC6891, defines EDNS.
• DNS-over-TLS (DoT)
  • RFC7858 and RFC8310.
• DNSSEC
  • RFC4033, introduction of DNSSEC.
  • RFC4034, resource records for DNSSEC.
  • RFC4035, protocol modifications for DNSSEC.
  • RFC6014, IANA regisistry allocation for algoriththms.
  • RFC8624, algorithm guidance.
• Session related
  • RFC8490, DSO opcode for long-lived sessions.
• Zone related
  • RFC1996, NOTIFY opcode.
  • RFC2136, on dynamic updates.
  • RFC2930, key distribution for authentication.
  • RFC3007, on secure communication for dynamic updates.
  • RFC8945, the protocol for TSIG RRTYPE, transaction level authentication for DNS.
  • RFC9103, zone transfer over TLS.
  • RFC9471, on glue records.
• Miscellaneous updates
  • RFC1982, on SERIAL field from SOA.
  • RFC2181, various clarifications.
  • RFC4470, minimally covering NSEC records.
  • RFC4592, on wildcards.
  • RFC6604, RCODE clarifications for redirections.
  • RFC6672, DNAME resource record (subtree redirection).
  • RFC6895, IANA assignment of field values.
  • RFC8020, on NXDOMAIN.
  • RFC8482, on QTYPE=ANY.
  • RFC9077, aggressive NSEC/NSEC3.

First appears in RFC1035 §4:

Table 1: DNS header format

Field	Bits	Description
ID	16	unique ID
QR	1	query or response
OPCODE	4	query type
AA	1	authoritative answer
TC	1	truncation
RD	1	recursion desired
RA	1	recursion available
Z	1	reserved
RCODE	4	response code
QDCOUNT	16	number of question RRs
ANCOUNT	16	number of answer RRs
NSCOUNT	16	number of NS RRs
ARCOUNT	16	number of additional RRs

After the header follow the optional sections of questions, answers, authority records, and additional records. RFC1035 describes only the question section format in detail, and as for the rest it says:

The last three sections have the same format: a possibly empty list of concatenated resource records (RRs). — RFC1035 §4.1

The question format is described in RFC1035 §4.1.2:

Table 2: DNS query section format

Field	Bits	Description
QNAME	8×N	domain name in sequenced-label format
QTYPE	16	type of query
QCLASS	16	class of query (IN for internet)

After this, the list of resource records follows (RFC1035 §4.1.3):

Table 3: DNS resource record format

Field	Bits	Description
NAME		domain name for this RR
TYPE	16	type of RDATA
CLASS	16	class of RDATA
TTL	32	cache time to live (seconds)
RDLENGTH	16	length of RDATA
RDATA	8×RDLENGTH	format according to TYPE and CLASS

Domain names are compressed according to a a compression scheme detailed in RFC1035 §4.1.4. When there are multiple subdomains of a domain, it allows each to use a pointer to the domain and only specify the subdomain part:

The compression algorithm can be tricky to get right, examples and details about vulnerabilities in RFC9267.

A master file is a text file containing RRs in textual form, described in RFC1035 §5.

A zone can be represented as a set of RRs, and master files can be used to define zones. In this RFC it was assumed that the master files would be, infrequently and solely, edited by hand.

Adds the UPDATE (5) opcode to update RRs in a zone's database. The four last fields of the DNS header become ZOCOUNT, PRCOUNT, UPCOUNT, ADCOUNT.

Also adds the RCODEs 6-10, and CLASS 254, see RFC2136 §1.3.

The updates of RFC2136 are authenticated via the TSIG (250) type code, first specified in RFC2845. RCODE is expanded to 16 bits inside a TSIG. The current specification of TSIG is in RFC8945.

RFC2930 describes the TKEY mechanism for key exchange for RFC2845, which did not specify any key exchange mechanisms other than manual exchange.

TKEY is a RR of type code 249.

The fixed-width fields of the DNS header were soon exhausted, and EDNS was invented to extend them in a backwards compatible way, first specified in RFC2671 and obsoleted by RFC6891. It adds the OPT (41) type code, and inside it more RCODE and other fields may be specified. The format of OPT is specified in RFC6891 §6.1.2 and has two parts, a fixed and a variable one (specified in RDATA):

Table 4: Fixed part of OPT RR

Field	Type	Description
NAME	domain name	MUST be 0 (root domain)
TYPE	uint16_t	OPT (41)
CLASS	uint16_t	requestor's UDP payload size
TTL	uint32_t	extended RCODE and flags
RDLEN	uint16_t	length of all RDATA
RDATA	octet stream	{attribute,value} pairs

In particular note that the extended RCODE and flags are specified in the TTL field. There are 8 bits added to RCODE for a total of 12.

Adds the RCODE=BADVERS (16).