Extension Mechanisms for DNS (EDNS0)
obsoleted by
- rfc-6891 — Extension Mechanisms for DNS (EDNS(0))
Extracted elements (23)
Advertising an architectural limit (e.g., 64 KB) as a maximum UDP payload size is unwise due to transaction state overhead. A practical ceiling of around 4 KB per ongoing transaction is suggested. Choosing 1280 on Ethernet-connected requestors is given as a reasonable example.
DNS wire protocol has exhausted or is near exhausting several fixed fields: the 4-bit RCODE space, the two reserved label type bits, and the 512-octet UDP message size limit. EDNS0 provides backward-compatible extension mechanisms to allow the protocol to grow without breaking existing clients.
TCP is acknowledged as an alternative for oversized requests, but using EDNS to discover and exploit a responder's larger UDP payload size is preferred over outright TCP when there is reason to believe the responder supports EDNS and the request would not fit in 512 bytes.
The first two bits of a wire-format domain label denote the label type. RFC 1035 allocated two of the four possible types. EDNS0 assigns bit pattern '01' to indicate an 'extended label type,' whose actual type value is encoded in the lower six bits of the first octet, allowing many new label types without consuming additional high-bit patterns.
Consulting the path's discovered MTU when selecting the advertised UDP payload size is advised for both requestors and responders. Choosing a size too large may result in an ICMP message from an intermediate gateway or a silent drop of the response.
Responders that do not understand EDNS extensions are expected to reply with RCODE NOTIMPL, FORMERR, or SERVFAIL. Requestors must therefore probe EDNS support and retry with no extensions on such responses. Cached capability information should be reproved periodically.
If a responder does not implement the VERSION level of a request, it MUST answer with RCODE=BADVERS (extended RCODE 16). All responses must be limited in format to the VERSION level of the request, but the VERSION field of each response reflects the responder's highest implemented level.
The presence of an OPT RR in a request indicates that the requestor fully implements the given EDNS version. Absence of an OPT RR MUST be taken as indication that the requestor does not implement any part of EDNS, and the responder may make no use of any extension in its response.
The quantity of OPT pseudo-RRs per DNS message SHALL be either zero or one. OPT RRs shall never be cached, forwarded, or stored in or loaded from master files.
The requestor's maximum UDP payload size SHOULD NOT be cached for use beyond the transaction in which it is advertised, as it can change over time.
The Z bits in the OPT TTL field must be set to zero by senders and ignored by receivers, unless a subsequent specification modifies this behavior.
Label type bit pattern '01' now indicates an EDNS Extended Label Type; the specific extended type is in the low 6 bits of the first label octet. Extended label type value '111111' (0x3F) is reserved for future expansion of the extended label type code space.
The CLASS field of the OPT RR carries the sender's UDP payload size — the maximum number of octets of UDP payload the sender can reassemble and deliver. This value is per-transaction and must not be cached across transactions.
The EDNS VERSION field in the OPT TTL indicates the implementation level of the sender. Version 0 means full conformance with RFC 2671. Requestors should set VERSION to the lowest implemented level capable of expressing the transaction to minimize negotiation overhead.
The OPT pseudo-RR (type 41) is a special resource record that can appear in the additional data section of a DNS request or response. It is not a real DNS record — it carries per-transaction transport metadata and is never cached, forwarded, or stored in zone files.
EDNS Extended Label Type 0b01xxxxxx is assigned as 'EDNS Extended Label Type.' Extended label type 0bxx111111 is reserved for future expansion. New entries in the EDNS Extended Label Type or EDNS Version Number registries require IESG approval.
EDNS Option Code 65535 is reserved for future expansion. Any published RFC (including Informational, Experimental, or BCP) is sufficient grounds for allocation of an EDNS Option Code.
IANA has assigned RR type code 41 to the OPT pseudo-RR. This document requests IANA create registries for EDNS Extended Label Types, EDNS Option Codes, and EDNS Version Numbers.
The RCODE space is expanded from 4 bits to 12 bits by combining the original 4-bit RCODE with the 8-bit EXTENDED-RCODE in the OPT TTL field. IANA may now assign more than the original 16 RCODE values. Extended RCODE 16 is assigned to 'BADVERS'.
Requestor-side specification of a large maximum UDP buffer size may enable a DNS denial-of-service attack: if responders are induced to send oversized messages that intermediate gateways cannot forward, ICMP storms may result between gateways and responders.
Each EDNS option in the OPT RDATA is encoded as a 2-octet OPTION-CODE (assigned by IANA), followed by a 2-octet OPTION-LENGTH giving the size of OPTION-DATA in octets, followed by OPTION-DATA of that length. Multiple options are concatenated.
The OPT RR fixed part reuses standard RR fields with new semantics: NAME is empty (root domain); TYPE is 41 (OPT); CLASS carries the sender's maximum UDP payload size (u_int16_t); TTL carries the extended RCODE and flags (u_int32_t); RDLEN and RDATA carry zero or more option {code, length, data} tuples.
The OPT TTL field encodes a 4-octet structure: byte 0 is EXTENDED-RCODE (upper 8 bits of the 12-bit RCODE, value 0 means unextended RCODE is in use); byte 1 is VERSION (EDNS version, 0 for this spec); bytes 2-3 are Z (reserved, must be zero).