Extension Mechanisms for DNS (EDNS(0))
obsoletes
also
- std-75
Extracted elements (31)
A starting EDNS UDP payload size of 4096 octets is recommended as a good compromise. Even on stacks capable of reassembling 64 KB datagrams, advertising the architectural limit is not recommended due to memory usage concerns at low system levels.
Binary Labels (RFC 2673) were moved to Experimental and are now deprecated because introducing a new label type was found to be extremely difficult due to lack of support in clients and intermediate gateways. Extended label types remain defined but their use is discouraged.
EDNS is defined as a hop-by-hop extension, meaning use of EDNS is negotiated between each pair of hosts in a DNS resolution process (e.g., stub resolver↔recursive, recursive↔authoritative) rather than end-to-end. This allows incremental deployment.
Implementation experience led to the recommendation that adding new RCODEs should be avoided due to the difficulty in upgrading the installed base; EDNS flags and option codes are preferred extension mechanisms.
The OPT RR reuses the TTL field (normally a 32-bit time value) to carry the extended RCODE (upper 8 bits), VERSION, DO flag, and reserved Z bits. This avoids adding new fixed fields to the DNS message header while extending its capabilities.
Extended agents MUST be prepared to handle interactions with unextended clients and fall back gracefully to unextended DNS. If a requestor detects that the remote end does not support EDNS(0), it MAY issue queries without an OPT record and MAY cache this knowledge briefly.
The requestor SHOULD place a UDP payload size value it can actually receive, taking into account firewalls that block fragmented IP packets. A fallback strategy starting at 4096, then 1280–1410 bytes (fits single Ethernet frame), then 512 bytes is recommended.
Any OPTION-CODE values not understood by a responder or requestor MUST be ignored. Unknown options must be silently discarded rather than causing an error.
Conformant middleboxes MUST NOT limit DNS messages over UDP to 512 bytes. Middleboxes that simply forward requests MUST NOT modify and MUST NOT delete the OPT record contents in either direction.
Extended label types SHOULD only be considered after careful evaluation of deployment hindrances. Proposals contemplating extended labels SHOULD weigh deployment cost against implementing functionality in other ways.
IETF Standards Action is required for assignments of new EDNS(0) flags. Flags SHOULD be used only when necessary for DNS resolution to function; for many uses, an EDNS Option Code MAY be preferred.
If a responder does not implement the VERSION level of the request, it MUST respond with RCODE=BADVERS. All responses MUST be limited in format to the VERSION level of the request, but the VERSION of each response SHOULD be the highest implementation level of the responder.
If an OPT record is present in a received request, compliant responders MUST include an OPT record in their respective responses.
Implementations MUST NOT generate or pass Binary Labels in their communications, as Binary Labels (RFC 2673) are now deprecated.
Lack of an OPT record in a request MUST be taken as an indication that the requestor does not implement any part of this specification, and the responder MUST NOT include an OPT record in its response.
OPT RRs MUST NOT be cached, forwarded, or stored in or loaded from master files. The OPT record MUST NOT be cached (repeated in Section 6.2.1 for clarity).
Requestor UDP payload size values lower than 512 MUST be treated as equal to 512. Similarly, values less than 512 bytes in payload size selection MUST be treated as equal to 512.
Responders that choose not to implement EDNS MUST respond with RCODE=FORMERR to messages containing an OPT record and MUST NOT include an OPT record in the response. If there is a problem processing the OPT record itself, a FORMERR MUST be returned and the response MUST include an OPT record.
The minimal error response MUST be the DNS header, question section, and an OPT record. This MUST also occur when a truncated response (TC bit set) is returned.
The requestor's maximum payload size MUST NOT be cached for use beyond the transaction in which it is advertised.
When an OPT RR is included in any DNS message, it MUST be the only OPT RR in that message. If a query message with more than one OPT RR is received, a FORMERR (RCODE=1) MUST be returned.
The OPT pseudo-RR (meta-RR) has RR type 41 and MAY be added to the additional data section of a DNS request. It carries no DNS data but conveys control information (extended RCODE, flags, payload size, and options) scoped to a single transaction.
IANA assigns EDNS Extended RCODE 16 to 'BADVERS' in the DNS RCODES registry. The RCODE space is expanded from 4 bits (RFC 1035) to 12 bits by EDNS, and adding new RCODEs requires IETF Review.
IANA maintains the DNS EDNS(0) Options registry (OPT Option Code space): codes 0–4 assigned, 5–65000 available for assignment, 65001–65534 for local/experimental use, 65535 reserved. New option code assignments require Expert Review; code 65535 is assigned to 'Reserved for future expansion'.
IANA maintains the EDNS Header Flags registry. New flags require IETF Standards Action. OPT RR type code 41 is assigned by IANA. The DNS Label Types registry remains open; registration procedure requires Standards Action. Binary Labels entry is now Historic.
IANA maintains the EDNS Version Number registry. New entries require IETF Standards Action. Version 0 indicates full conformance with this specification.
Announcing UDP buffer sizes that are too small may result in fallback to TCP with a corresponding load impact on DNS servers, which is especially significant with DNSSEC where answers are much larger than traditional DNS responses.
Requestor-side specification of very large maximum UDP buffer sizes may enable a DNS denial-of-service attack: responders can be made to send messages too large for intermediate gateways to forward, potentially causing ICMP storms between gateways and responders. Announcing very large sizes may also cause middleboxes to drop DNS messages, leading to retransmissions with no hope of success.
Each EDNS option in OPT RDATA is encoded as: OPTION-CODE (16-bit, assigned by Expert Review), OPTION-LENGTH (16-bit, size in octets of OPTION-DATA), and OPTION-DATA (variable, MUST be treated as a bit field). Order of options is undefined.
The OPT RR fixed part encodes: NAME (must be 0/root, domain name), TYPE (u_int16_t, value 41), CLASS (u_int16_t, requestor's UDP payload size), TTL (u_int32_t, extended RCODE and flags), RDLEN (u_int16_t, length of RDATA), RDATA (octet stream of {attribute,value} option pairs).
The OPT TTL field (32 bits) encodes: EXTENDED-RCODE (bits 0–7, upper 8 bits of the 12-bit RCODE), VERSION (bits 8–15, EDNS implementation level), DO flag (bit 16, DNSSEC OK), and Z (bits 17–31, reserved, must be zero).