diff --git a/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-01.txt b/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-01.txt deleted file mode 100644 index 41ae72ec2e..0000000000 --- a/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-01.txt +++ /dev/null @@ -1,448 +0,0 @@ - - - -DNSEXT R. Bellis -Internet-Draft Nominet UK -Updates: 1035, 1123 October 26, 2009 -(if approved) -Intended status: Standards Track -Expires: April 29, 2010 - - - DNS Transport over TCP - draft-ietf-dnsext-dns-tcp-requirements-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 April 29, 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 29, 2010 [Page 1] - -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 29, 2010 [Page 2] - -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 many 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. - - However, some implementors have taken the text quoted above to mean - that TCP support is truly optional for typical DNS operation. - - 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 - - In the absence of EDNS0 (see below) the normal behaviour of any DNS - server needing to send a UDP response that exceeds that 512 byte - 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: - - ... 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 - - - -Bellis Expires April 29, 2010 [Page 3] - -Internet-Draft DNS Transport over TCP October 2009 - - - (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 has arrived, and the only - standardised mechanism which may have resolved the packet size issue - has been found inadequate. - - -4. Transport Protocol Selection - - All DNS implementations MUST support both UDP and TCP transport - protocols, except as set out below. - - On a case by case basis, authoritative DNS server operators MAY elect - to disable DNS transport over TCP if all of the following conditions - are satisfied: - - o the server is authoritative only - o the server does not support AXFR - 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 - - - -Bellis Expires April 29, 2010 [Page 4] - -Internet-Draft DNS Transport over TCP October 2009 - - - if it is operating in an environment where truncation can never - 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. - - 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. - - That requirement is hereby relaxed. 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 (with or without EDNS0) or for other operational reasons. - - -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. - - Servers MAY allow dormant 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. - - Further recommendations for the tuning of TCP parameters to allow - higher throughput or improved resiliency against denial of service - attacks are (currently) outside the scope of this document. - - - - - -Bellis Expires April 29, 2010 [Page 5] - -Internet-Draft DNS Transport over TCP October 2009 - - -6. Response re-ordering - - RFC 1035 is ambiguous on the question of whether TCP queries may be - re-ordered - the only relevant text is in Section 4.2.1 which relates - to UDP: - - Queries or their responses may be reordered by the network, or by - processing in name servers, so resolvers should not depend on them - being returned in order. - - For the avoidance of future doubt, this requirement is clarified. - Client resolvers MUST be able to process responses which arrive in a - different order to that in which the requests were sent, regardless - of the transport protocol in use. - - -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, - RFC 793, September 1981. - - - -Bellis Expires April 29, 2010 [Page 6] - -Internet-Draft DNS Transport over TCP October 2009 - - - [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-01 - Addition of response ordering section - Various minor editorial changes from WG reviewers - - draft-ietf-dnsext-dns-tcp-requirements-00 - Initial draft - - - - - - - -Bellis Expires April 29, 2010 [Page 7] - -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 29, 2010 [Page 8] -