Inside a DNS Message: Header Flags, Sections and Wire Format

Every DNS lookup, from a browser asking for an address to a resolver chasing a delegation, is a short binary message in one common format. You rarely see the bytes, but tools such as dig print the header fields as text, and knowing what they mean turns that output from noise into evidence. The format has been specified by RFC 1035 since 1987, refining RFC 883 of 1983, and has been extended since, not replaced.

The 12-byte header

Every message begins with the same 12 bytes: a 16-bit ID, a 16-bit word of flags and codes, and four 16-bit counts.

After the header come the four sections, in that order. The question section echoes what was asked, the answer section holds the records that answer it, the authority section points to the nameservers responsible for the zone, and the additional section carries extra records the server expects the client to want next, such as the addresses of those nameservers.

Take AA with care. A recursive resolver answering from its cache is not an authority for that data and does not set it. In the original design, a server marks an answer authoritative when it answers from zone data it holds, as opposed to cached data (Mockapetris and Dunlap, 1988). Seeing aa in a reply from one of a zone's own nameservers is the normal case, except for a referral to a child zone, which does not carry it even from an authoritative server.

Reading dig's header line

dig prints the header on two lines. A typical response looks like this:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6891
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

opcode and status are the Opcode and RCODE fields. The flags line lists the bits that are set, here qr, rd and ra, which together mean: a response, to a query that asked for recursion, from a server that offers it. The four counts are the section sizes. The ADDITIONAL: 1 is usually the server's EDNS pseudo-record, returned because dig includes one in its query; it is not an extra address.

The status is the quickest thing to read. RFC 1035 defines six response codes.

One common result has no code of its own. A name that exists but has no record of the type you asked for returns NOERROR with no records of that type in the answer section (a CNAME may still appear), which RFC 2308 names NODATA. The difference matters when you are diagnosing; see NXDOMAIN explained and DNS timeout vs SERVFAIL for what to do with each.

A query, byte by byte

This is a complete query for the A record of example.com in its classic form, without EDNS, as a client would send it with recursion requested. It is 29 bytes long.

1a 2b 01 00 00 01 00 00 00 00 00 00 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01

The same bytes travel inside encrypted transports. In DNS over HTTPS (RFC 8484), for instance, the same message travels either as the raw body of an HTTP POST or, in a GET request, base64url-encoded into a dns parameter, and clients are advised to set the ID to 0; see DNS over HTTPS and DNS over TLS explained.

Names, limits and compression

A name is a sequence of labels, each preceded by its length, ending in a zero byte. RFC 1035 limits a label to 63 octets and a whole name to 255. Because a label's length byte never exceeds 63, its top two bits are always zero, and that left room for compression: when the top two bits are both one, that byte and the next form a pointer, and the remaining 14 bits give an offset from the start of the message. In a response, the answer's name is very commonly the two bytes c0 0c, a pointer to offset 12, where the question's name begins right after the header. Every DNS program must understand pointers in the messages it receives, though it may choose not to produce them.

Why 512 bytes mattered, and what replaced it

RFC 1035 restricts UDP messages to 512 bytes, not counting the IP and UDP headers. A longer message is truncated and the TC bit is set, which tells the client to retry over TCP. The original designers judged the datagram limit a success rather than a problem: performance was much better than over TCP circuits and operating-system resources were not tied up, although the choice demanded careful retransmission strategies (Mockapetris and Dunlap, 1988).

As responses grew with IPv6 and DNSSEC, the limit became tight. EDNS(0), defined in RFC 6891, lets a client advertise a larger UDP payload size in an OPT pseudo-record. The RFC suggests 4096 octets as a starting point and a fallback to a range around 1280 to 1410 bytes if that fails. Since RFC 7766 in 2016, support for TCP has been a required part of a complete DNS implementation. Larger UDP responses also have a security cost, because they make reflection attacks more profitable; DNS amplification attacks and open resolvers covers that.

Sources and further reading

• RFC 1035: Domain Names - Implementation and Specification (Mockapetris, 1987)
• RFC 2308: Negative Caching of DNS Queries (DNS NCACHE) (Andrews, 1998)
• RFC 2535: Domain Name System Security Extensions (Eastlake, 1999)
• RFC 4035: Protocol Modifications for the DNS Security Extensions (Arends et al., 2005)
• RFC 6891: Extension Mechanisms for DNS (EDNS(0)) (Damas, Graff and Vixie, 2013)
• RFC 7766: DNS Transport over TCP - Implementation Requirements (Dickinson et al., 2016)
• Paul V. Mockapetris and Kevin J. Dunlap, Development of the Domain Name System, Proceedings of SIGCOMM '88, Computer Communication Review 18(4), 1988, pp. 123-133
• Paul Albitz and Cricket Liu, DNS and BIND, 5th edition (O'Reilly, 2006)
• Kevin R. Fall and W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols, 2nd edition (Addison-Wesley, 2011)