DNSSEC and IPv6 A6 aware server/resolver message size requirements (RFC3226)
Original Publication Date: 2001-Dec-01
Included in the Prior Art Database: 2001-Dec-27
Internet Society Requests For Comment (RFCs)
AbstractThis document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support either DNS Security Extensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. This document updates RFC 2535 and RFC 2874, by adding new requirements.
Network Working Group O. Gudmundsson
Request for Comments: 3226 December 2001
Updates: 2874, 2535
Category: Standards Track
DNSSEC and IPv6 A6 aware server/resolver message size requirements
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document mandates support for EDNS0 (Extension Mechanisms for
DNS) in DNS entities claiming to support either DNS Security
Extensions or A6 records. This requirement is necessary because
these new features increase the size of DNS messages. If EDNS0 is
not supported fall back to TCP will happen, having a detrimental
impact on query latency and DNS server load. This document updates
RFC 2535 and RFC 2874, by adding new requirements.
Familiarity with the DNS [RFC1034, RFC1035], DNS Security Extensions
[RFC2535], EDNS0 [RFC2671] and A6 [RFC2874] is helpful.
STD 13, RFC 1035 Section 2.3.4 requires that DNS messages over UDP
have a data payload of 512 octets or less. Most DNS software today
will not accept larger UDP datagrams. Any answer that requires more
than 512 octets, results in a partial and sometimes useless reply
with the Truncation Bit set; in most cases the requester will then
retry using TCP. Furthermore, server delivery of truncated responses
varies widely and resolver handling of these responses also varies,
leading to additional inefficiencies in handling truncation.
Compared to UDP, TCP is an expensive protocol to use for a simple
transaction like DNS: a TCP connection requires 5 packets for setup
and tear down, excluding data packets, thus requiring at least 3
round trips on top of the one for the original UDP query. The DNS
Gudmundsson Standards Track [Page 1]
RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
server also needs to keep a state of the connection during this
transaction. Many DNS servers answer thousands of queries per
second, requiring them to use TCP will cause significant overhead and
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in RFC 2119.
2. Motivating factors
2.1. DNSSEC motivations
DNSSEC [RFC2535] secures DNS by adding a Public Key signature on each
RR set. These signatures range in size from about 80 octets to 800
octets, most are going to be in the range of 80 to 200 octets. The
addition of signatures on each or most RR sets in an answer
significantly increases the size of DNS answers from secure zones.
For performance reasons and to reduce load on DNS servers, it is
important that security aware servers and resolvers get all the data
in Answer and Author...