EDNS(0) and Extensions

The extension mechanism DNS needed

By the late 1990s, DNS was stuck. The 512-byte UDP limit was too small for DNSSEC signatures, large delegations, and growing TXT records. Adding new features to the protocol required changing the fixed 12-byte header — a header that was hardcoded into every DNS implementation on earth. Any change to the header format would break backward compatibility with millions of deployed servers.

EDNS (Extension Mechanisms for DNS), defined in RFC 2671 (1999) and revised in RFC 6891 (2013), solved this with an elegant hack: instead of changing the header, it adds a pseudo-record to the Additional section of the DNS message. This OPT record carries extension data without altering the existing message format. Servers that understand EDNS process the OPT record; servers that don’t simply ignore the unknown record type.

The “(0)” in EDNS(0) is the version number. Only version 0 has ever been defined. The extension mechanism was designed to support future versions, but two decades later, version 0 has proven sufficient for every extension the protocol has needed.

The OPT pseudo-record

The OPT record repurposes the standard resource record fields with new meanings:

Standard Field	EDNS Meaning	Typical Value
NAME	Must be root (.)	0x00
TYPE	OPT (41)	0x0029
CLASS	Requestor’s UDP payload size	1232 (post-Flag Day 2020)
TTL	Extended RCODE + version + flags	Contains DO bit for DNSSEC
RDATA	Option code/length/data tuples	Variable

The CLASS field is repurposed to advertise the maximum UDP payload size the sender can handle. Instead of being limited to 512 bytes, a client can signal “I can accept responses up to 1232 bytes” — or up to 65,535 bytes in theory.

The TTL field is reinterpreted as four subfields:

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|         Extended RCODE          |            Version            |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|DO |                          Z (reserved)                      |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

The DO (DNSSEC OK) bit is the most important flag. When set, the client is asking the server to include DNSSEC records (RRSIG, NSEC, DNSKEY) in the response. Without the DO bit, a DNSSEC-signed zone returns only the requested records without signatures.

EDNS options

The RDATA field of the OPT record carries zero or more options, each as a code/length/data tuple. Several options have become important to how DNS operates today.

EDNS Client Subnet (ECS) — RFC 7871

When you query Google’s 8.8.8.8 for a CDN-hosted domain, the authoritative server needs to know your approximate location to return the nearest CDN edge. But the authoritative server only sees the resolver’s IP address, not yours. If the resolver is in Virginia and you’re in Tokyo, you might be directed to a Virginia CDN node.

ECS solves this by letting the resolver include a truncated version of your IP address in the query:

Field	Description
FAMILY	Address family (1=IPv4, 2=IPv6)
SOURCE PREFIX-LENGTH	How many bits of the client address are included (e.g., /24)
SCOPE PREFIX-LENGTH	How many bits the server used for its decision (in the response)
ADDRESS	The truncated client IP prefix

The privacy tradeoff is significant. ECS reveals your approximate network location to every authoritative server the resolver contacts — information it would not otherwise have. This enables CDN optimization but also enables surveillance and fingerprinting. Approximately 12% of internet users send queries through ECS-enabled resolvers.

Cloudflare and Quad9 refuse to implement ECS, citing privacy concerns. Google and OpenDNS support it. The philosophical divide reflects a fundamental tension in DNS: performance optimization versus user privacy.

DNS Cookies — RFC 7873

DNS Cookies provide lightweight transaction authentication without the computational overhead of TSIG or DNSSEC:

• Client cookie (8 bytes): Generated using a secret, the server IP, and other data. Sent with every query.
• Server cookie (8–32 bytes): Generated using the server’s secret and the client cookie. Returned in responses.

On subsequent queries, the client includes both cookies. The server verifies the server cookie matches what it previously issued. This provides three defenses:

1. Off-path spoofing protection. An attacker who can’t observe traffic can’t forge the cookie.
2. Amplification attack mitigation. Servers can require valid cookies before sending large responses.
3. Cache poisoning resistance. Adds a second identity layer beyond the 16-bit transaction ID.

Cookies are carried as EDNS option code 10.

Padding — RFC 7830

Even when DNS traffic is encrypted via DoH, DoT, or DoQ, message sizes can leak information. An observer can correlate encrypted query sizes with known domain names — since google.com produces a different-sized query than my-embarrassing-medical-condition.example.com.

The EDNS Padding option (code 12) adds arbitrary zero bytes to pad messages to a uniform size. RFC 8467 recommends block-length padding — pad to the next multiple of 128 bytes. This creates a fixed set of possible message sizes, making individual queries indistinguishable from others padded to the same block.

The DNS Flag Days

EDNS was specified in 1999, but nearly two decades later, a significant number of authoritative servers still could not handle EDNS queries correctly. Some ignored EDNS entirely. Some returned errors. Some sent responses without the OPT record when one was included in the query. Resolvers worked around these broken servers with complex fallback logic — retry without EDNS, retry with smaller buffers, retry with TCP — adding latency and code complexity.

The DNS community decided to rip the bandage off.

Flag Day 2019 (February 1)

Eight major DNS software vendors — ISC (BIND), CZ.NIC (Knot Resolver), NLnet Labs (Unbound), PowerDNS, Cloudflare, Google, Quad9, and Cisco — simultaneously removed their EDNS workaround code. After this date, authoritative servers that could not handle EDNS queries properly appeared “dead” to major resolvers.

Who was affected: Approximately 3–5% of authoritative servers had some level of EDNS non-compliance. Domains served by non-compliant software became unreachable through major resolvers.

Standard enforced: RFC 6891 and its baseline behavior requirements.

Flag Day 2020 (October 1)

The second flag day addressed IP fragmentation. Previously, many implementations defaulted to a 4096-byte EDNS buffer size, which frequently caused IP fragmentation. Fragmented DNS responses are:

• Dropped by some firewalls and middleboxes
• Vulnerable to off-path injection attacks (an attacker can forge the second fragment)
• Unreliable across paths with varying MTUs

Two changes took effect:

Default buffer size reduced to 1232 bytes. The value was chosen based on precise math:

IPv6 minimum MTU:           1,280 bytes
- IPv6 header:                 40 bytes
- UDP header:                   8 bytes
= Maximum safe payload:     1,232 bytes

This ensures no fragmentation on any IPv6-compliant link. The value also works safely for IPv4 paths.

TCP fallback must work. Authoritative servers must handle TCP connections. When a response doesn’t fit in the UDP buffer, the server sets the TC flag and the client retries over TCP. Servers that couldn’t handle TCP or that depended on large UDP responses needed to update.

Coordination

DNS Flag Days are coordinated through the dns-violations GitHub organization and announced at DNS-OARC workshops, RIPE meetings, and IETF sessions. The project website provides compliance-testing tools that operators can use to check their servers before each flag day.

The flag days demonstrated something important: the DNS community can coordinate protocol enforcement across competing implementations when the benefits are clear enough. The complex workaround code that resolvers had accumulated over 20 years was removed in a single coordinated cut.

Why EDNS matters beyond size

EDNS is easy to think of as “the thing that made DNS messages bigger.” But its real significance is as a general extension mechanism. Without EDNS:

• DNSSEC would be impractical (signatures don’t fit in 512 bytes)
• Client Subnet optimization for CDNs wouldn’t exist
• DNS Cookies for spoofing protection wouldn’t exist
• Padding for encrypted DNS privacy wouldn’t exist
• Future protocol extensions would require changing the header format — effectively impossible

The OPT record turned DNS from a frozen protocol into an extensible one. Every major DNS improvement since 1999 has been delivered through EDNS options rather than header changes. That single design decision — hiding extensions in a pseudo-record — is what allowed a protocol designed in 1987 to keep evolving without breaking backward compatibility.