Intended Status: Standard Track O. Gudmundsson Network Working Group Shinkuro, Inc. Internet-Draft June 13, 2009 Updates: 4035 (if approved) Intended status: Standards Track Expires: December 15, 2009 DNSSEC OK buffer minimum size requirment and error handling draft-gudmundsson-dnsext-setting-ends0-do-bit-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on December 15, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Gudmundsson Expires December 15, 2009 [Page 1] Internet-Draft DNSSEC OK min bufsize June 2009 Abstract RFC3226 mandated support for EDNS0 in DNS entities claiming to support either DNS Security Extensions or IPv6 address records. This requirement was motivated 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivating factors . . . . . . . . . . . . . . . . . . . . . . 4 2.1. DNSSEC motivations . . . . . . . . . . . . . . . . . . . . 4 2.2. Root server and TLD server motivations . . . . . . . . . . 4 2.3. UDP vs TCP for DNS messages . . . . . . . . . . . . . . . 4 2.4. EDNS0 and large UDP messages . . . . . . . . . . . . . . . 5 3. Protocol changes: . . . . . . . . . . . . . . . . . . . . . . 6 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations: . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Gudmundsson Expires December 15, 2009 [Page 2] Internet-Draft DNSSEC OK min bufsize June 2009 1. Introduction Familiarity with the DNS[RFC1034] [RFC1035], EDNS0[RFC2671] DNS Security Extensions[RFC4033], [RFC4034] [RFC4035] is assumed. STD 13 RFC 1035[RFC1035] Section 2.3.4 requires that DNS messages over UDP have a data payload of 512 octets or less. Some DNS software does not accept larger UDP data grams, some DNS "aware" middle box software is insistent on this behavior sometimes with strange side effects. Any answer that requires more than 512 octets, results in a partial and sometimes useless reply with the Truncation Bit set at the Authoritative server. If a resolver gets that reply in most cases the requester will then retry using TCP. In the case of middle box insisting on 512 limit the middle box may simply drop the reply. Because of this resolvers have implemented number of techniques to get around the middle boxes. Furthermore, server delivery of truncated responses varies widely, some contain as much data as will fit and others sending empty answers. The resolver handling of truncated responses also varies, some checking if the information asked for is in the answer and using that. Other resolvers will blindly retry the query over TCP. 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. Many DNS servers answer tens of thousands of queries per second, requiring them to use TCP will cause significant overhead and delays. 1.1. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. [RFC2119] Gudmundsson Expires December 15, 2009 [Page 3] Internet-Draft DNSSEC OK min bufsize June 2009 2. Motivating factors 2.1. DNSSEC motivations Adding DNSSEC [RFC4033] to a zone expands the size of regular answers as signatures are added to each RRset. The size of some RRsets can exceed the 512 byte limit, in particular the DNSKEY RRset can exceed this size. For example as of June 2009 the on-the wire size of the answer for qytpe=3384 with buffsize=4094, for the following TLDs .cz: 1322..3384, .gov: 1166, .org: 1334..1723, and .se 3958..4094 The wide range of answer size reflects partially what is placed in the authority and additional sections by different implementations. In particular the size of negative answers size increases. A negative answer requires a signed SOA, and at least 2 NSEC records or 3 NSEC3 records. The size of the zone signing key thus has great impact on the size of the negative answers. For the TLD mentioned above the range for the negative answers is from 660 bytes in .se to about 1500 bytes for .gov. DNSSEC DO[RFC4035] [RFC3225] specifies how a client can, using EDNS0, indicate that it is interested in receiving DNSSEC records. The DO bit does not eliminate the need for large answers for DNSSEC capable clients requiring TCP. 2.2. 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. The root servers have started adding AAAA resulting in answers with a sub-set of the address fitting into the 515 byte message. This can result in clients trying to get the missing addresses via TCP query or repeated A (or AAAA) queries. Given the fact that most of the traffic reaching the roots is "garbage" the extra UDP load is not an issue. There is concern on the other hand over the extra TCP queries, as there are millions of DNS resolvers deployed world wide and all need to periodically to prime their caches. 2.3. UDP vs TCP for DNS messages Given all these factors, it is essential that any implementation that supports DNSSEC and IPv6[RFC3596] be able to use larger DNS messages than 512 octets. Gudmundsson Expires December 15, 2009 [Page 4] Internet-Draft DNSSEC OK min bufsize June 2009 2.4. 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. [RFC3225] and [RFC3226] did not explicitly specify when to set the DO bit or how to handle when the DO bit was set in error on small messages. The documents implicitly made the assumption that DO bit was going to be set only when an resolver relay wanted DNSSEC records and the advertised buffer size was large enough to handle the specified DNSSEC answer size. Implementations have been seen to counter both of these assumptions. These two documents where obsoleted by RFC4035 where the language is stronger about support of DO bit and minimum advertised buffer size (see section 4.1). According to a study in 2008 [MATT] about 15% of EDNS queries reaching the .com/.net TLD servers have advertised buffer size less than 1220. Many/most of these have the DO bit set. What seems to be happening is that resolver implementations have discovered that ENDS0 with buffer size of 4096 is sometimes silently dropped and fall back to < 1220 in an attempt to get messages through. When the size is shrunk the DO bit is still set, even when the advertised size is 512 bytes. Gudmundsson Expires December 15, 2009 [Page 5] Internet-Draft DNSSEC OK min bufsize June 2009 3. Protocol changes: This document updates [RFC4035] All DNSSEC compliant resolver MUST NOT set the DO bit on queries where the buffer size is less than 1220 . All DNSSEC compliant severs MAY treat ENDS0 queries with DO bit set and the buffer size set to less 1220, as the DO bit is not set, if adding the RRSIG records would cause truncation bit to be set. If a server ignores the DO bit it MUST clear the bit in the response. The assumption here is that most of the resolvers setting TC bit with small buffer do not care about DNSSEC and only the ones that do will retry via TCP. Gudmundsson Expires December 15, 2009 [Page 6] Internet-Draft DNSSEC OK min bufsize June 2009 4. Acknowledgments This document was motivated by behavior observed by David Conrad at an root server. The need for this update was further motivated by the signing of ORG and the reports in sudden increase TCP connections right after that. Gudmundsson Expires December 15, 2009 [Page 7] Internet-Draft DNSSEC OK min bufsize June 2009 5. Security Considerations Ignoring the the DO bit in certain case may cause non-compliant DNSSEC aware software to experience behavior that indicates that the zone has gone insecure. This is not a bad thing as any testing of the path will reveal that the EDNS0 buffer size is the issue. Gudmundsson Expires December 15, 2009 [Page 8] Internet-Draft DNSSEC OK min bufsize June 2009 6. IANA Considerations: This document does not have any IANA actions. Gudmundsson Expires December 15, 2009 [Page 9] Internet-Draft DNSSEC OK min bufsize June 2009 7. References 7.1. Normative 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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. 7.2. Informative References [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001. [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001. [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003. [MATT] Larson, M. and D. Blacka, "Port and Message ID Analysis of Resolvers Querying .com/.net Name Servers", Sept 2008. Gudmundsson Expires December 15, 2009 [Page 10] Internet-Draft DNSSEC OK min bufsize June 2009 Author's Address Olafur Gudmundsson Shinkuro, Inc. 4922 Fairmount Av. Suite 250 Bethesda, MD 20814 USA Email: ogud@ogud.com Gudmundsson Expires December 15, 2009 [Page 11]