--- /dev/null
+
+
+
+DNSEXT R. Bellis
+Internet-Draft Nominet UK
+Updates: 1123, 1035 October 6, 2009
+(if approved)
+Intended status: Standards Track
+Expires: April 9, 2010
+
+
+ DNS Transport over TCP
+ draft-ietf-dnsext-dns-tcp-requirements-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 April 9, 2010.
+
+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.
+
+Abstract
+
+ This document updates the requirements for the support of the TCP
+
+
+
+Bellis Expires April 9, 2010 [Page 1]
+\f
+Internet-Draft DNS Transport over TCP October 2009
+
+
+ protocol for the transport of DNS traffic.
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+
+ 2. Terminology used in this document . . . . . . . . . . . . . . . 3
+
+ 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+
+ 4. Transport Protocol Selection . . . . . . . . . . . . . . . . . 4
+
+ 5. Dormant Connection Handling . . . . . . . . . . . . . . . . . . 5
+
+ 6. Response re-ordering . . . . . . . . . . . . . . . . . . . . . 6
+
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
+
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 7
+
+ Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 7
+
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis Expires April 9, 2010 [Page 2]
+\f
+Internet-Draft DNS Transport over TCP October 2009
+
+
+1. Introduction
+
+ Most DNS [RFC1035] transactions take place over the UDP [RFC0792]
+ protocol. The TCP [RFC0793] protocol is used for zone transfers and
+ is supported by some implementations for the transfer of other
+ packets which exceed the protocol's original 512 byte packet-size
+ limit.
+
+ Section 6.1.3.2 of [RFC1123] states:
+
+ DNS resolvers and recursive servers MUST support UDP, and SHOULD
+ support TCP, for sending (non-zone-transfer) queries.
+
+ This document normatively updates the core DNS protocol
+ specifications such that (except in very limited circumstances)
+ support for the TCP protocol is henceforth REQUIRED.
+
+
+2. Terminology used in this document
+
+ 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 [RFC2119].
+
+
+3. Discussion
+
+ Some implementors have taken the [RFC1123] text quoted above to mean
+ that TCP support is truly optional for typical DNS operation.
+
+ However, whilst RFC 1123 predates the current RFC 2119 terminology
+ document it uses exactly the same text:
+
+ SHOULD - This word, or the adjective "RECOMMENDED", mean that
+ there may exist valid reasons in particular circumstances to
+ ignore a particular item, but the full implications must be
+ understood and carefully weighed before choosing a different
+ course.
+
+ In the absence of EDNS0 (see below) the normal behaviour of any DNS
+ server needing to send a UDP response that exceeds that 512 limit is
+ for the server to truncate the response at the 512 byte limit and set
+ the TC flag in the response header. When the client receives such a
+ response it takes the TC flag as notice that it should retry over TCP
+ instead.
+
+ RFC 1123 also says:
+
+
+
+
+Bellis Expires April 9, 2010 [Page 3]
+\f
+Internet-Draft DNS Transport over TCP October 2009
+
+
+
+ ... it is also clear that some new DNS record types defined in the
+ future will contain information exceeding the 512 byte limit that
+ applies to UDP, and hence will require TCP. Thus, resolvers and
+ name servers should implement TCP services as a backup to UDP
+ today, with the knowledge that they will require the TCP service
+ in the future.
+
+ Existing deployments of DNSSEC [RFC4033] have shown that truncation
+ at the 512 byte boundary is now commonplace. For example an NXDOMAIN
+ (RCODE == 3) response from a DNSSEC signed zone using NSEC3 [RFC5155]
+ is almost invariably longer than 512 bytes.
+
+ Since the original core specifications for DNS were written the
+ Extension Mechanisms for DNS EDNS0 [RFC2671] have been introduced.
+ These extensions can be used to indicate that the client is prepared
+ to receive UDP responses longer than 512 bytes. An EDNS0 compatible
+ server receiving a request from an EDNS0 compatible client may send
+ UDP packets up to that client's announced buffer size without
+ truncation.
+
+ However, transport of UDP packets which exceed the size of the path
+ MTU has been found to be unreliable in some circumstances because of
+ IP packet fragmentation. Many firewalls routinely block fragmented
+ IP packets, and some implementations lack the software logic
+ necessary to reassemble a fragmented datagram. Worse still, some
+ devices deliberately refuse to handle DNS packets containing EDNS0
+ options. Other issues relating to UDP transport and packet size are
+ discussed in [RFC5625].
+
+ The MTU most commonly found in the core of the Internet is around
+ 1500 bytes, and even that limit is routinely exceeded by DNSSEC
+ signed responses.
+
+ The future that was anticipated in RFC 1123 is now here, and the only
+ standardised mechanism which may have resolved the packet size issue
+ has been found inadequate.
+
+
+4. Transport Protocol Selection
+
+ On a case by case basis, authoritative DNS server operators MAY elect
+ to disable DNS transport over TCP if all of the conditions below are
+ satisfied:
+
+ o the server is authoritative
+
+
+
+
+
+Bellis Expires April 9, 2010 [Page 4]
+\f
+Internet-Draft DNS Transport over TCP October 2009
+
+
+ o the server does not support AXFR
+ o the server does not support DNSSEC
+ o all requests and responses are guaranteed to be <= 512 bytes
+
+ A general purpose stub resolver implementation (e.g. an operating
+ system's DNS resolution library) MUST support TCP since to do
+ otherwise would limit its interoperability with its own clients and
+ with upstream servers.
+
+ A proprietary stub resolver implementation MAY omit support for TCP
+ if it is operating in an environment where truncation will not occur,
+ or if it is prepared to accept a DNS lookup failure should truncation
+ occur.
+
+ A recursive resolver or forwarder MUST support TCP so that it does
+ not prevent long responses from a TCP-capable server from reaching
+ its TCP-capable clients.
+
+ Otherwise, all DNS implementations MUST support TCP transport.
+
+ Regarding the choice of when to use UDP or TCP, RFC 1123 says:
+
+ ... a DNS resolver or server that is sending a non-zone-transfer
+ query MUST send a UDP query first.
+
+ This requirement is no longer mandatory. A resolver SHOULD send a
+ UDP query first, but MAY elect to send a TCP query instead if it has
+ good reason to expect the response would be truncated if it were sent
+ over UDP, or other operational considerations suggest otherwise.
+
+
+5. Dormant Connection Handling
+
+ Section 4.2.2 of [RFC1035] says:
+
+ If the server needs to close a dormant connection to reclaim
+ resources, it should wait until the connection has been idle for a
+ period on the order of two minutes.
+
+ Other more modern protocols (e.g. HTTP [RFC2616]) have support for
+ persistent TCP connections and operational experience has shown that
+ long timeouts can easily cause resource exhaustion and poor response
+ under heavy load. Intentionally opening many connections and leaving
+ them dormant can trivially create a "denial of service" attack.
+
+ This document therefore RECOMMENDS that the idle period should be of
+ the order of TBD seconds. With modern high performance networks 2 to
+ 4 seconds should be sufficient to allow significant numbers (i.e.
+
+
+
+Bellis Expires April 9, 2010 [Page 5]
+\f
+Internet-Draft DNS Transport over TCP October 2009
+
+
+ thousands) of concurrent dormant connections without impacting
+ service performance.
+
+ Servers MAY allow idle connections to remain open for longer periods,
+ but for the avoidance of doubt persistent DNS connections should
+ generally be considered to be as much for the server's benefit as for
+ the client's. Therefore if the server needs to unilaterally close a
+ dormant TCP connection it MUST be free to do so whenever required.
+
+
+6. Response re-ordering
+
+ [Potential text to be added regarding whether TCP responses can come
+ back in a different order to requests. I'm not aware whether this is
+ specified anywhere]
+
+
+7. Security Considerations
+
+ Some DNS server operators have expressed concern that wider use of
+ DNS over TCP will expose them to a higher risk of "denial of service"
+ attacks.
+
+ Many large authoritative DNS operators including all but one of the
+ root servers and the vast majority of TLDs already support TCP and
+ attacks against them are infrequent and very rarely successful.
+
+ Operators of recursive servers should ensure that they only accept
+ connections from expected clients, and do not accept them from
+ unknown sources. In the case of UDP traffic this will protect
+ against reflector attacks [RFC5358] and in the case of TCP traffic it
+ will prevent an unknown client from exhausting the server's limits on
+ the number of concurrent connections.
+
+
+8. IANA Considerations
+
+ This document requests no IANA actions.
+
+
+9. References
+
+9.1. Normative References
+
+ [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
+ RFC 792, September 1981.
+
+ [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
+
+
+
+Bellis Expires April 9, 2010 [Page 6]
+\f
+Internet-Draft DNS Transport over TCP October 2009
+
+
+ RFC 793, September 1981.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
+ and Support", STD 3, RFC 1123, October 1989.
+
+ [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.
+
+9.2. Informative References
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, March 2005.
+
+ [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+ Security (DNSSEC) Hashed Authenticated Denial of
+ Existence", RFC 5155, March 2008.
+
+ [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
+ Nameservers in Reflector Attacks", BCP 140, RFC 5358,
+ October 2008.
+
+ [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
+ BCP 152, RFC 5625, August 2009.
+
+
+Appendix A. Change Log
+
+ NB: to be removed by the RFC Editor before publication.
+
+ draft-ietf-dnsext-dns-tcp-requirements-00
+ Initial draft
+
+
+
+
+
+
+
+
+
+Bellis Expires April 9, 2010 [Page 7]
+\f
+Internet-Draft DNS Transport over TCP October 2009
+
+
+Author's Address
+
+ Ray Bellis
+ Nominet UK
+ Edmund Halley Road
+ Oxford OX4 4DQ
+ United Kingdom
+
+ Phone: +44 1865 332211
+ Email: ray.bellis@nominet.org.uk
+ URI: http://www.nominet.org.uk/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis Expires April 9, 2010 [Page 8]
+\f
projects / thirdparty / bind9.git / commitdiff
