From c58088e3a0fd9e553db750cd4b08d3e621d0ded4 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 31 Dec 2001 02:32:50 +0000 Subject: [PATCH] draft-ietf-dnsext-message-size has been replace by rfc3226 --- .../draft-ietf-dnsext-message-size-01.txt | 338 ----------------- doc/rfc/index | 1 + doc/rfc/rfc3226.txt | 339 ++++++++++++++++++ 3 files changed, 340 insertions(+), 338 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsext-message-size-01.txt create mode 100644 doc/rfc/rfc3226.txt diff --git a/doc/draft/draft-ietf-dnsext-message-size-01.txt b/doc/draft/draft-ietf-dnsext-message-size-01.txt deleted file mode 100644 index d0948dcfdc..0000000000 --- a/doc/draft/draft-ietf-dnsext-message-size-01.txt +++ /dev/null @@ -1,338 +0,0 @@ - - - - - - -DNSEXT Working Group Olafur Gudmundsson (NAI Labs) -INTERNET-DRAFT October 2000 - - - -Updates: RFC 2535, RFC 2874 - - - - DNSSEC and IPv6 A6 aware server/resolver message size requirements - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - Comments should be sent to the authors or the DNSEXT WG mailing list - namedroppers@ops.ietf.org - - This draft expires on March 29, 2001. - - Copyright Notice - - Copyright (C) The Internet Society (2000). All rights reserved. - - - - - - - - - - -Expires March 2001 [Page 1] - -INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000 - - -Abstract - - This document mandates support for EDNS0 in DNS entities claiming to - support DNS Security Extensions and 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. - - - - -1 - Introduction - - Familiarity with the DNS[RFC1034, RFC1035], DNS Security - Extensions[RFC2535], EDNS0[RFC2671] and A6[RFC2874] is helpful. - - RFC 1035[RFC1035] 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 size UDP datagrams. Thus, any answer that - requires more than 512 octets will result in a partial and probably - useless reply with the Truncation Bit set; in most cases the - requester will then retry using TCP. Some DNS servers send back an - answer truncating the message at the last RR boundary before - truncation, other servers truncate at the previous set, some send - back empty answer with TC bit set. - - 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 - server also needs to keep a state of the connection during this - transaction. As many DNS servers answer thousands of queries per - second, requiring them to use TCP will cause significant overhead and - delays. - - -1.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..200 octets. The - addition of these signatures on each or most RR sets in an answer - will significantly increase the size of DNS answers from secure - zones. - - It is important that security aware servers and resolvers get all the - data in Answer and Authority section in one query without truncation. - In some cases it is important that some Additional Data be sent - - - -Expires March 2001 [Page 2] - -INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000 - - - along, mainly in delegation cases. - - TSIG[RFC2845] allows for the light weight authentication of DNS - messages, but increases the size of the messages by at least 70 - octets. DNSSEC allows for computationally expensive message - authentication with 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. - - -1.2 - IPv6 Motivations - - IPv6 addresses[RFC2874] are 128 bits and are 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 - queried name has multiple A6 addresses may overflow a 512-octet UDP - packet size. - - -1.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 DNS message. If root servers start advertising A6 or - KEY records then the root zone answer for NS records will not fit in - an single 512-octet DNS message. Resulting in a large number of TCP - connections to the root servers. - - It is important that a high level domains have a high number of - domain name servers for redundancy, latency and load balancing - reasons. - - -1.4 UDP vs TCP for DNS messages - - Given all these factors, it is essential that any implementations - 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 avoid fragmentation - of DNS responses. A fragmented UDP message that suffers a loss off - one of the fragments renders the answer useless and DNS must - retransmit the query. TCP connection requires number of round trips - for establishment, data transfer and tear down, but only the lost - data segments are retransmitted. - - - - -Expires March 2001 [Page 3] - -INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000 - - - In the early days 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 few thousand octets. - - -1.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. - -1.7 - Requirements - - The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" - in this document are to be interpreted as described in RFC 2119. - - -2 - Protocol changes: - - This document updates [RFC2535] and [RFC2874], by adding new - requirements. - - All RFC2535-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 RFC2874-compliant servers and resolver MUST support EDNS0 and - advertise message size of at least 1024 octets, but SHOULD advertise - message size of 2048. - - All RFC2535 and RFC2874 compliant entities MUST be able to handle - fragmented IP and IPv6 UDP packets. - - All hosts supporting both RFC2535 and RFC2874 MUST use the larger - required value in EDNS0 advertisements. - - - - - - - - -Expires March 2001 [Page 4] - -INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000 - - -3 Acknowledgments - - Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas - Gustafsson, Bob Halley, Edward Lewis and Kazu Yamamoto where - instrumental in motivating and shaping this document. - -4 - Security Considerations: - - There are no additional security considerations other than those in - RFC2671. - - -5 - IANA Considerations: - - None - -References: - - -[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities'' - STD 13, RFC 1034, November 1987. - -[RFC1035] P. Mockapetris, ``Domain Names - Implementation and - Specification'', STD 13, RFC 1035, November 1987. - - -[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC - 2535, March 1999. - - -[RFC2671] P. Vixie, ``Extension Mechanisms for DNS (EDNS0)'', RFC - 2671, August 1999. - - -[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, - ``Secret Key Transaction Authentication for DNS (TSIG)'', RFC - 2845, May 2000. - - -[RFC2874] M. Crawford, C. Huitema, S. Thompson, ``DNS Extensions to - Support IPv6 Address Aggregation and Renumbering'', RFC2874, - Sometime 2000. - - - - - - - - - -Expires March 2001 [Page 5] - -INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000 - - -Author Address - - - Olafur Gudmundsson - NAI Labs - Network Associates - 3060 Washington Road (Rt. 97) - Glenwood, MD 21738 - USA - +1 443 259 2389 - - - -Full Copyright Statement - - Copyright (C) The Internet Society (2000). 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." - - - - - - - - - - - -Expires March 2001 [Page 6] diff --git a/doc/rfc/index b/doc/rfc/index index 16c6f5729c..dbbdd20761 100644 --- a/doc/rfc/index +++ b/doc/rfc/index @@ -65,3 +65,4 @@ 3090: DNS Security Extension Clarification on Zone Status 3110: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) 3225: Indicating Resolver Support of DNSSEC +3226: DNSSEC and IPv6 A6 aware server/resolver message size requirements diff --git a/doc/rfc/rfc3226.txt b/doc/rfc/rfc3226.txt new file mode 100644 index 0000000000..dac0e11c15 --- /dev/null +++ b/doc/rfc/rfc3226.txt @@ -0,0 +1,339 @@ + + + + + + +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] +