Internet DRAFT - draft-gudmundsson-dnsext-setting-ends0-do-bit
draft-gudmundsson-dnsext-setting-ends0-do-bit
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]
