+++ /dev/null
-
-
-
-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]
-\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 29, 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 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\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 29, 2010 [Page 8]
-\f
projects / thirdparty / bind9.git / commitdiff
