DNSSEC and IPv6 A6 aware server/resolver message size requirements
updated by
- rfc-4033 — DNS Security Introduction and Requirements
- rfc-4034 — Resource Records for the DNS Security Extensions
- rfc-4035 — Protocol Modifications for the DNS Security Extensions
updates
Extracted elements (15)
EDNS0 allows clients to declare the maximum UDP message size they can accept, avoiding TCP fallback overhead when expected answers fall between 512 octets and the client's maximum size.
Fragmented UDP is preferable to TCP on low-loss links because it completes in one round trip; TCP is only advantageous on high-loss connections where retransmitting only lost segments matters.
TCP is considered expensive for DNS because a connection requires 5 packets for setup and teardown (at least 3 round trips in addition to the original UDP query), placing significant overhead and delay on servers handling thousands of queries per second.
The number of root servers is limited to 13 because that is the maximum number of NS records and their addresses that fit in a single 512-octet DNS answer; A6 or KEY records in the root zone would overflow this limit and force TCP connections to root servers at scale.
The original 512-octet UDP limit was set to reduce the probability of fragmentation of DNS responses, since a fragmented UDP message with a lost fragment renders the answer useless and requires a retry.
DNSSEC signatures added per RR set range from approximately 80 to 800 octets (most 80–200 octets), significantly increasing DNS answer sizes from secure zones and making the 512-octet UDP limit problematic.
IPv6 A6 records (RFC 2874) represent 128-bit addresses as multiple records each containing a domain name and bit field; answers for names with multiple A6 addresses can overflow a 512-octet UDP packet.
The DNSSEC OK bit (specified in RFC 3225) signals client interest in DNSSEC records but does not eliminate the need for large UDP messages; EDNS0 support remains separately required.
TSIG authentication increases DNS message size by at least 70 octets; SIG(0) may also contribute to answer size, and even a single TSIG or SIG(0) record can push a response past the 512-octet limit.
All hosts supporting both RFC 2535 and RFC 2874 MUST use the larger of the two required EDNS0 advertisement values (i.e., at least 1220 octets).
All RFC 2535 and RFC 2874 compliant entities MUST be able to handle fragmented IPv4 and IPv6 UDP packets.
All RFC 2535 compliant servers and resolvers MUST support EDNS0 and advertise a message size of at least 1220 octets, but SHOULD advertise 4000 octets.
All RFC 2874 compliant servers and resolvers MUST support EDNS0 and advertise a message size of at least 1024 octets, but SHOULD advertise 2048 octets.
IPv6 datagrams SHOULD be 1024 octets unless the MTU of the path is known; this is intentionally smaller than the minimum IPv6 MTU to allow for extension headers and encapsulation.
There are no additional security considerations beyond those in RFC 2671 (EDNS0); the document's security properties derive entirely from that specification.