DNS, as designed in 1987, painted itself into a corner. RFC 1035 set the maximum UDP response size at 512 bytes, reserved a handful of flag bits, and used a 4-bit RCODE field — only 16 possible error codes. By the late 1990s these limits were suffocating the protocol. IPv6 needed bigger answers. DNSSEC needed much bigger answers (signatures alone can exceed 512 bytes). New features needed signaling channels that didn't exist. You couldn't even extend the header without breaking every resolver on Earth.

RFC 6891 (which obsoletes RFC 2671 from 1999) solves this with a brilliantly sneaky trick: the OPT pseudo-RR. EDNS(0) doesn't change the DNS wire format at all. Instead, it smuggles extension data inside an additional resource record that older servers, by spec, must ignore.

The OPT record hack

An EDNS-aware client appends a single OPT record to the Additional section of its query. This record looks like a normal RR but its fields are repurposed:

• CLASS field → carries the requestor's UDP payload size (e.g., 4096 bytes, blowing past the 512 limit)
• TTL field → split into extended RCODE bits, version number, and flag bits (notably the DO bit — "DNSSEC OK")
• RDATA → variable-length list of option codes (the EDNS option registry: client subnet, cookies, padding, keepalive, etc.)

Because the OPT record's TYPE is 41, ancient resolvers simply don't recognize it and pass over it. New resolvers see the OPT and unpack a whole parallel extension namespace.

Why this matters every single day

Nearly every DNS query on the modern internet carries an OPT record. Without EDNS(0):

• DNSSEC is impossible — RRSIG and DNSKEY responses routinely exceed 512 bytes
• IPv6 AAAA-heavy responses get truncated, forcing TCP fallback (slow)
• DNS Cookies (RFC 7873) — the lightweight anti-spoofing mechanism — have nowhere to live
• EDNS Client Subnet (RFC 7871), which lets CDNs geo-target answers based on the stub's network, can't be signaled
• TCP Keepalive, Padding (for DNS-over-TLS privacy), Chain Query, and dozens more options don't function

The 2019 "DNS Flag Day"

For years, broken middleboxes and firewalls would drop EDNS queries instead of responding with FORMERR. Resolvers worked around this by retrying without EDNS — a slow, painful fallback that delayed every query through a broken resolver. On February 1, 2019, the major resolver vendors (BIND, Unbound, PowerDNS, Knot, plus Google and Cloudflare's public resolvers) coordinated to remove these workarounds. Operators of broken authoritative servers suddenly went dark. It was the closest thing the DNS community has had to a flag day since the 1983 NCP-to-TCP cutover, and it forced an enormous cleanup of legacy DNS infrastructure.

Design lessons

EDNS(0) is a textbook case of extending a deployed protocol without breaking it. The "(0)" in the name reserves version negotiation — there could one day be EDNS(1), signaled via the OPT record's version field. (There never has been; the option-list model proved flexible enough.) Paul Vixie has called it "the ugliest beautiful thing in DNS," which captures the spirit: it's a hack riding on top of the additional-records section, but it's the hack that kept DNS alive into the DNSSEC, IPv6, and privacy eras.