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 factors2.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 Authority section in one query without truncation.
Sending Additional Data in the same query is helpful when the server
is authoritative for the data, and this reduces round trips.
DNSSEC OK[OK] specifies how a client can, using EDNS0, indicate that
it is interested in receiving DNSSEC records. The OK bit does not
eliminate the need for large answers for DNSSEC capable clients.
2.1.1. Message authentication or TSIG motivation
TSIG [RFC2845] allows for the light weight authentication of DNS
messages, but increases the size of the messages by at least 70
octets. DNSSEC specifies for computationally expensive message
authentication SIG(0) using a standard public key signature. As only
one TSIG or SIG(0) can be attached to each DNS answer the size
increase of message authentication is not significant, but may still
lead to a truncation.
2.2. IPv6 Motivations
IPv6 addresses [RFC2874] are 128 bits and can be represented in the
DNS by multiple A6 records, each consisting of a domain name and a
bit field. The domain name refers to an address prefix that may
require additional A6 RRs to be included in the answer. Answers
where the queried name has multiple A6 addresses may overflow a 512-
octet UDP packet size.
Gudmundsson Standards Track [Page 2]