Intended Status: Standard Track O. Gudmundsson Network Working Group Shinkuro, Inc. Internet-Draft June 2009 Updates: 4035 (if approved) Intended status: Standards Track Expires: December 3, 2009 DNSSEC OK buffer minimum size requirement and error handling draft-gudmundsson-dnsext-setting-ends0-do-bit-01 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 3, 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 3, 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. UDP vs TCP for DNS messages . . . . . . . . . . . . . . . 4 2.3. EDNS0 and large UDP messages . . . . . . . . . . . . . . . 4 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 3, 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 3, 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. UDP vs TCP for DNS messages TCP requires more/longer-living state on both parties of a transaction. For high volume DNS servers even small states per each query that need to be kept for "long" time is a potential DoS vector. Number of DNS servers are answering 50-100 Kq/s thus any state will consume significant memory resources. UDP requires no state past the lifetime of the query. 2.3. 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 Gudmundsson Expires December 3, 2009 [Page 4] Internet-Draft DNSSEC OK min bufsize June 2009 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 3, 2009 [Page 5] Internet-Draft DNSSEC OK min bufsize June 2009 3. Protocol changes: This document updates [RFC4035] A DNSSEC compliant resolver MUST NOT set the DO bit on queries where the buffer size is less than 1220. A DNSSEC compliant severs upon receiving a queries with DO bit set and the buffer size set to less 1220 MAY either: treat it as the DO bit is not set. If a server ignores the DO bit it MUST clear the DO bit in the response. DNSSEC compliant servers MAY alternativly refuse to answer such query by sending back: FORMERR and including an OPT record in the response (to signal the server actually supports ENDS0). The hope hope is that never resolver versions will not drop from 4K buffer to 512 but try something between 1220 and 1500 bytes. DNS resolvers that keep data in the cache based on the setting of the DO bit MUST do so based on the presence of the DO bit in the answer not the query. Gudmundsson Expires December 3, 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. Number of people have provided usefull feeback on this document, Joe Abley, Mark Andrews, George Barwood, Ray Bellis, David Conrad, Michael Graff, Peter Koch, Ted Lemmon, Wouter Wjingaads, Paul Vixie, Florian Weimer and Nichola Weaver. Gudmundsson Expires December 3, 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 3, 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 3, 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. [MATT] Larson, M. and D. Blacka, "Port and Message ID Analysis of Resolvers Querying .com/.net Name Servers", Sept 2008. Gudmundsson Expires December 3, 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 3, 2009 [Page 11]