diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc3226.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc3226.txt | 339 |
1 files changed, 0 insertions, 339 deletions
diff --git a/contrib/bind9/doc/rfc/rfc3226.txt b/contrib/bind9/doc/rfc/rfc3226.txt deleted file mode 100644 index dac0e11c1575..000000000000 --- a/contrib/bind9/doc/rfc/rfc3226.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -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] - |