A DNS message, byte by byte

When your laptop asks for www.example.com, the bytes that leave it are not text. There is no "GET", no colon, no line break. There is a binary structure that Paul Mockapetris laid out in RFC 1035 in November 1987, and that every DNS server and client since has had to read the same way. The design has aged remarkably well: the extensions that came later (DNSSEC, EDNS, extended errors) all fit inside the original frame instead of replacing it.

The single most useful fact about that frame is that queries and responses have the same layout. A response is the query handed back with the header changed and answers appended. A server copies your question into its reply word for word, so a client can check that the answer is for the question it asked. One parser reads both directions.

Every message has five parts, always in this order. The header is fixed at 12 bytes. Then come four sections of variable length: the question (what is being asked), the answer (records that answer it), the authority (records that point toward the servers responsible for the name, or prove that it does not exist) and the additional section (records that might save the client another lookup, and, since EDNS, a special pseudo-record carrying options). The header says how many entries each section holds; the sections themselves carry no markers or separators. A parser simply reads that many entries, one after another.

The header is six 16-bit numbers. Four of them are counts, one is an identifier, and one, the second word, is packed with eleven separate fields. Here they are in order.

ID (16 bits) is a number the client picks. The server copies it into the reply, and the client uses it to pair replies with outstanding queries. A modern client picks it at random for every query, because a predictable ID makes forged replies easier to land.

QR (1 bit) is 0 in a query and 1 in a response. OPCODE (4 bits) says what kind of message this is: 0 is an ordinary query, and almost everything you will ever see is opcode 0. NOTIFY (4) and UPDATE (5) are used between servers and by tools that edit zones; Chapter 6 covers them.

Then four one-bit flags. AA, authoritative answer, is set by a server that owns the zone the name lives in; a resolver answering from its cache leaves it clear. TC, truncated, means the message was cut short because it did not fit; you will meet it again below. RD, recursion desired, is set by a client that wants the server to chase the answer through the tree on its behalf; your laptop sets it, and a resolver talking to authoritative servers usually clears it. RA, recursion available, is the server saying it offers that service.

The next three bits were a single 3-bit "Z, reserved, must be zero" field in 1987. Two of them were later claimed by DNSSEC (RFC 4035). AD, authentic data, is set by a validating resolver when every record in the answer checked out cryptographically. CD, checking disabled, is set by a client that wants the resolver to hand over the data without validating it, usually because the client will validate it itself. One bit, still called Z, remains reserved and must be zero.

The last four bits are the RCODE, the response code: 0 NOERROR, 1 FORMERR (the server could not parse your query), 2 SERVFAIL (the server tried and failed), 3 NXDOMAIN (the name does not exist), 4 NOTIMP (not implemented) and 5 REFUSED (the server will not answer you). Four bits only allow 16 values, which turned out to be too few; EDNS extends the field, as you will see.

A question has three fields. QNAME is the name being asked about. QTYPE is a 16-bit number for the record type (1 for A, 28 for AAAA, 15 for MX; IANA keeps the list). QCLASS is a 16-bit class, which in practice is always 1, IN, for internet. (Class 3, CH for Chaosnet, survives mostly as a way to ask a server which software it runs.)

Names are not stored with dots. Each label is written as a length byte followed by that many bytes of characters, and the name ends with a zero-length label: a single 0 byte, which stands for the root of the tree from Chapter 1. So www.example.com becomes 3 www 7 example 3 com 0: 17 bytes for a 15-character name. Because the length byte comes first, a parser never searches for a terminator, and a dot inside a label is just another byte. The rules that fall out of this: a label holds at most 63 bytes, and a whole name, length bytes included, at most 255.

Every record in the answer, authority and additional sections uses one layout, the resource record. Its owner NAME comes first, encoded the same way. Then TYPE and CLASS (2 bytes each), then a 32-bit TTL in seconds (how long a cache may keep it; Chapter 4), then RDLENGTH, a 16-bit count of the bytes that follow, and then the RDATA itself, whose shape depends on the type: four bytes for an A record, sixteen for AAAA, a name for CNAME or NS, a 2-byte preference plus a name for MX. RDLENGTH means a parser can skip any record it does not understand, which is how new record types could be added for decades without breaking old software.

Here is a complete worked example: the query a stub sends for the A record of www.example.com, with ID 0x2A7F, recursion desired, and no EDNS. It is 33 bytes.

A typical response repeats the same names over and over. The question names www.example.com; the answer's owner is www.example.com again; its CNAME target is web.example.com; the authority section lists example.com and ns1.example.com. With only 512 bytes to play with in 1987, writing each one out in full was a waste. So RFC 1035 added name compression: anywhere a name, or the tail end of a name, has already appeared in the message, the encoder can write a 2-byte pointer to the earlier copy instead.

The trick fits in the length byte. A label length is at most 63, which in binary is 00111111: the top two bits of a real length byte are always 00. If they are 11 instead, the byte is the start of a pointer, and the remaining 14 bits, across this byte and the next, are an offset counted from the first byte of the message. In the response to our query, the question's www.example.com starts at offset 12, so a later copy of it becomes C0 0C: binary 11000000 00001100, "pointer, offset 12". And because example.com starts four bytes later, at offset 16, the CNAME target web.example.com can be written as the label 03 web followed by C0 10. A name is a sequence of labels that may end in a pointer, so whole names and shared suffixes both compress.

Compression saves a lot. In the simulated response in Instrument 2, the six names after the question would take 98 bytes written out; compressed, they take 20, and the whole response shrinks from 190 bytes to 112. But it also hands a parser a hazard. A pointer is an instruction to jump, and nothing in the format stops a malicious or broken message from pointing a name at itself, or two pointers at each other. A naive parser that just follows pointers will loop forever, or build a name until memory runs out. Such a message is a cheap denial-of-service against any server or client that reads it.

The defense is simple and every serious implementation has it: count. Refuse to follow more pointers than a name could legitimately need, refuse any name whose expanded length passes 255 bytes, and refuse a pointer that lands outside the message. Many parsers also insist that a pointer points backwards, to an offset earlier than itself; RFC 1035 describes pointers as referring to a "prior occurrence" of the name, and a backwards-only rule makes loops impossible by construction. The bug class has a name in MITRE's catalog: CWE-835, "Loop with Unreachable Exit Condition". It is a classic trap for anyone writing a DNS parser by hand, and a pointer chain is one of the first things a fuzzer will try.

RFC 1035 capped a DNS message over UDP at 512 bytes. The figure sits neatly inside a rule IPv4 already had: every host must be able to accept a datagram of at least 576 bytes, and 512 bytes of DNS plus the IP and UDP headers fits within it (RFC 6891 spells out the pairing). It was plenty for an A record or two. It is not plenty for a signed answer with DNSSEC signatures, a TXT record full of email policy, or an IPv6-heavy list of name servers.

When an answer will not fit, the server does not fragment it or give up. It sends what fits (often just the header and the question) with the TC bit set to 1. TC=1 is not an error. It means "this is incomplete; ask me again over TCP". The client opens a TCP connection to the same server on port 53 and sends the same query. Because TCP is a byte stream with no message boundaries, each DNS message on it is preceded by a 2-byte length prefix, so the reader knows where one message ends and the next begins. That prefix is the only difference in the bytes; the message itself is identical. The two bytes also set the ceiling: 65,535 bytes per message.

The cost is time. A UDP lookup is one round trip. A truncated lookup is that round trip, plus one for TCP's handshake, plus one for the query and answer over TCP: three in all, before counting any TLS. How TCP's handshake works is covered on networks · TCP, UDP & ports; what matters here is that the fallback must work. For years, firewalls were configured on the folk belief that "DNS is UDP", and blocked TCP port 53. RFC 7766 (2016) put that to rest: every DNS implementation, authoritative and recursive, MUST support TCP. A server that cannot be reached over TCP will fail for exactly the large answers that need it.

By the late 1990s the header had run out of room: no free flag bits, a 4-bit RCODE, and a 512-byte ceiling. Changing the header would have broken every parser on earth. EDNS, the Extension Mechanisms for DNS (first RFC 2671 in 1999, now RFC 6891 from 2013), found a cleverer way in: a fake record. A client that speaks EDNS adds one OPT pseudo-record to the additional section of its query. Old servers that do not understand type 41 ignore it or answer FORMERR, and the client then knows to fall back. New servers read it, and put an OPT record in their reply too.

The OPT record reuses the ordinary record fields for new purposes. Its NAME is the root, a single 0 byte. Its TYPE is 41. Its CLASS field carries the sender's UDP payload size: "I can receive a DNS message this big over UDP". Its 32-bit TTL field is split into an 8-bit extension of the RCODE (giving 12 bits in all), an 8-bit EDNS version (0 is the only one in use, hence "EDNS(0)"), and 16 flag bits, of which only the top one is assigned: DO, "DNSSEC OK", meaning "please include signatures". Its RDATA holds a list of options, each a 2-byte code, a 2-byte length and the data.

The options are where EDNS keeps growing. DNS Cookies (option 10, RFC 7873) let a client and server recognize each other's later messages, which makes spoofed replies and reflection floods harder. Padding (option 12, RFC 7830) rounds encrypted messages up to fixed sizes so their length does not give away the name. Client Subnet (option 8, RFC 7871) lets a resolver tell a content network roughly where its client is, a privacy trade-off covered in Chapter 9. And Extended DNS Errors (option 15) explain failures, below.

EDNS let clients advertise big buffers, and for years 4096 bytes was the common default. That created a new problem. Every network link has a maximum transmission unit (MTU), typically 1500 bytes on Ethernet and often less through tunnels and VPNs. A 3000-byte UDP answer does not fit one packet, so IP fragments it, and fragments behave badly. Many firewalls and middleboxes drop them. If any fragment is lost the whole datagram is lost, and the client sees nothing at all: no reply, no TC bit, just a timeout. Worse, fragments carry no UDP port and no DNS ID after the first one, so an attacker can try to splice a forged second fragment into a real reply, a cache-poisoning route that the usual ID and port randomization does not protect.

The fix agreed by DNS software vendors and operators on DNS Flag Day 2020 was to stop asking for big UDP answers. They recommended a default EDNS buffer of 1232 bytes: IPv6 requires every link to carry at least 1280 bytes, and 1280 minus a 40-byte IPv6 header and an 8-byte UDP header leaves 1232. An answer that size fits nearly every path without fragmenting. Anything bigger is truncated and fetched over TCP, which handles large messages properly. RFC 9715 (2025) wrote the same advice into an RFC, with a recommended maximum of 1400 bytes and a firm preference for avoiding fragmentation altogether.

For most of DNS's life, a failure was a four-bit shrug. SERVFAIL means "something went wrong while I was trying", and it covers an enormous range of causes: an expired DNSSEC signature, every authoritative server timing out, a broken delegation, a resolver policy blocking the name. Operators debugging an outage had to guess, or reproduce the lookup by hand.

Extended DNS Errors (RFC 8914, 2020) put the reason in the message. An EDE is an EDNS option, code 15, carrying a 16-bit INFO-CODE and an optional line of text. It rides alongside the ordinary RCODE rather than replacing it, so old clients see the same SERVFAIL as ever while new tools can print the cause. It can also accompany a successful answer: code 3, "Stale Answer", says the resolver served an expired cache entry because the authoritative servers could not be reached.