340 lines
12 KiB
Plaintext
340 lines
12 KiB
Plaintext
|
|
|
|
|
|
|
|
|
|
|
|
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 Notice
|
|
|
|
Copyright (C) The Internet Society (2001). All Rights Reserved.
|
|
|
|
Abstract
|
|
|
|
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.
|
|
|
|
1. Introduction
|
|
|
|
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
|
|
delays.
|
|
|
|
1.1. Requirements
|
|
|
|
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 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]
|
|
|
|
RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
|
|
|
|
|
|
2.3. Root server and TLD server motivations
|
|
|
|
The current number of root servers is limited to 13 as that is the
|
|
maximum number of name servers and their address records that fit in
|
|
one 512-octet answer for a SOA record. If root servers start
|
|
advertising A6 or KEY records then the answer for the root NS records
|
|
will not fit in a single 512-octet DNS message, resulting in a large
|
|
number of TCP query connections to the root servers. Even if all
|
|
client resolver query their local name server for information, there
|
|
are millions of these servers. Each name server must periodically
|
|
update its information about the high level servers.
|
|
|
|
For redundancy, latency and load balancing reasons, large numbers of
|
|
DNS servers are required for some zones. Since the root zone is used
|
|
by the entire net, it is important to have as many servers as
|
|
possible. Large TLDs (and many high-visibility SLDs) often have
|
|
enough servers that either A6 or KEY records would cause the NS
|
|
response to overflow the 512 byte limit. Note that these zones with
|
|
large numbers of servers are often exactly those zones that are
|
|
critical to network operation and that already sustain fairly high
|
|
loads.
|
|
|
|
2.4. UDP vs TCP for DNS messages
|
|
|
|
Given all these factors, it is essential that any implementation that
|
|
supports DNSSEC and or A6 be able to use larger DNS messages than 512
|
|
octets.
|
|
|
|
The original 512 restriction was put in place to reduce the
|
|
probability of fragmentation of DNS responses. A fragmented UDP
|
|
message that suffers a loss of one of the fragments renders the
|
|
answer useless and the query must be retried. A TCP connection
|
|
requires a larger number of round trips for establishment, data
|
|
transfer and tear down, but only the lost data segments are
|
|
retransmitted.
|
|
|
|
In the early days a number of IP implementations did not handle
|
|
fragmentation well, but all modern operating systems have overcome
|
|
that issue thus sending fragmented messages is fine from that
|
|
standpoint. The open issue is the effect of losses on fragmented
|
|
messages. If connection has high loss ratio only TCP will allow
|
|
reliable transfer of DNS data, most links have low loss ratios thus
|
|
sending fragmented UDP packet in one round trip is better than
|
|
establishing a TCP connection to transfer a few thousand octets.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Gudmundsson Standards Track [Page 3]
|
|
|
|
RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
|
|
|
|
|
|
2.5. EDNS0 and large UDP messages
|
|
|
|
EDNS0 [RFC2671] allows clients to declare the maximum size of UDP
|
|
message they are willing to handle. Thus, if the expected answer is
|
|
between 512 octets and the maximum size that the client can accept,
|
|
the additional overhead of a TCP connection can be avoided.
|
|
|
|
3. Protocol changes:
|
|
|
|
This document updates RFC 2535 and RFC 2874, by adding new
|
|
requirements.
|
|
|
|
All RFC 2535 compliant servers and resolvers MUST support EDNS0 and
|
|
advertise message size of at least 1220 octets, but SHOULD advertise
|
|
message size of 4000. This value might be too low to get full
|
|
answers for high level servers and successor of this document may
|
|
require a larger value.
|
|
|
|
All RFC 2874 compliant servers and resolver MUST support EDNS0 and
|
|
advertise message size of at least 1024 octets, but SHOULD advertise
|
|
message size of 2048. The IPv6 datagrams should be 1024 octets,
|
|
unless the MTU of the path is known. (Note that this is smaller than
|
|
the minimum IPv6 MTU to allow for some extension headers and/or
|
|
encapsulation without exceeding the minimum MTU.)
|
|
|
|
All RFC 2535 and RFC 2874 compliant entities MUST be able to handle
|
|
fragmented IPv4 and IPv6 UDP packets.
|
|
|
|
All hosts supporting both RFC 2535 and RFC 2874 MUST use the larger
|
|
required value in EDNS0 advertisements.
|
|
|
|
4. Acknowledgments
|
|
|
|
Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas
|
|
Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis
|
|
Michael Patton and Kazu Yamamoto were instrumental in motivating and
|
|
shaping this document.
|
|
|
|
5. Security Considerations:
|
|
|
|
There are no additional security considerations other than those in
|
|
RFC 2671.
|
|
|
|
6. IANA Considerations:
|
|
|
|
None
|
|
|
|
|
|
|
|
|
|
|
|
Gudmundsson Standards Track [Page 4]
|
|
|
|
RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
|
|
|
|
|
|
7. References
|
|
|
|
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
|
|
STD 13, RFC 1034, November 1987.
|
|
|
|
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
|
|
Specification", STD 13, RFC 1035, November 1987.
|
|
|
|
[RFC2535] Eastlake, D. "Domain Name System Security Extensions", RFC
|
|
2535, March 1999.
|
|
|
|
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
|
|
2671, August 1999.
|
|
|
|
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
|
|
Wellington, "Secret Key Transaction Authentication for DNS
|
|
(TSIG)", RFC 2845, May 2000.
|
|
|
|
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
|
|
IPv6 Address Aggregation and Renumbering", RFC 2874, July
|
|
2000.
|
|
|
|
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
|
|
3225, December 2001.
|
|
|
|
8. Author Address
|
|
|
|
Olafur Gudmundsson
|
|
3826 Legation Street, NW
|
|
Washington, DC 20015
|
|
USA
|
|
|
|
EMail: ogud@ogud.com
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Gudmundsson Standards Track [Page 5]
|
|
|
|
RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
|
|
|
|
|
|
9. Full Copyright Statement
|
|
|
|
Copyright (C) The Internet Society (2001). All Rights Reserved.
|
|
|
|
This document and translations of it may be copied and furnished to
|
|
others, and derivative works that comment on or otherwise explain it
|
|
or assist in its implementation may be prepared, copied, published
|
|
and distributed, in whole or in part, without restriction of any
|
|
kind, provided that the above copyright notice and this paragraph are
|
|
included on all such copies and derivative works. However, this
|
|
document itself may not be modified in any way, such as by removing
|
|
the copyright notice or references to the Internet Society or other
|
|
Internet organizations, except as needed for the purpose of
|
|
developing Internet standards in which case the procedures for
|
|
copyrights defined in the Internet Standards process must be
|
|
followed, or as required to translate it into languages other than
|
|
English.
|
|
|
|
The limited permissions granted above are perpetual and will not be
|
|
revoked by the Internet Society or its successors or assigns.
|
|
|
|
This document and the information contained herein is provided on an
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
|
|
Acknowledgement
|
|
|
|
Funding for the RFC Editor function is currently provided by the
|
|
Internet Society.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Gudmundsson Standards Track [Page 6]
|
|
|