idnits 2.17.1 draft-ietf-dnsext-dns-tcp-requirements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC1035, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1123, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1035, updated by this document, for RFC5378 checks: 1987-11-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 22, 2010) is 5146 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT R. Bellis 3 Internet-Draft Nominet UK 4 Updates: 1035, 1123 March 22, 2010 5 (if approved) 6 Intended status: Standards Track 7 Expires: September 23, 2010 9 DNS Transport over TCP - Implementation Requirements 10 draft-ietf-dnsext-dns-tcp-requirements-03 12 Abstract 14 This document updates the requirements for the support of TCP as a 15 transport protocol for DNS implementations. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 23, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology used in this document . . . . . . . . . . . . . . . 3 61 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Transport Protocol Selection . . . . . . . . . . . . . . . . . 4 65 5. Connection Handling . . . . . . . . . . . . . . . . . . . . . . 5 67 6. Response re-ordering . . . . . . . . . . . . . . . . . . . . . 6 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 79 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 8 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 1. Introduction 85 Most DNS [RFC1035] transactions take place over UDP [RFC0768]. TCP 86 [RFC0793] is always used for zone transfers and is often used for 87 messages whose sizes exceed the DNS protocol's original 512 byte 88 limit. 90 Section 6.1.3.2 of [RFC1123] states: 92 DNS resolvers and recursive servers MUST support UDP, and SHOULD 93 support TCP, for sending (non-zone-transfer) queries. 95 However, some implementors have taken the text quoted above to mean 96 that TCP support is an optional feature of the DNS protocol. 98 The majority of DNS server operators already support TCP and the 99 default configuration for most software implementations is to support 100 TCP. The primary audience for this document is those implementors 101 whose failure to support TCP restricts interoperability and limits 102 deployment of new DNS features. 104 This document therefore updates the core DNS protocol specifications 105 such that support for TCP is henceforth a REQUIRED part of a full DNS 106 protocol implementation. 108 Whilst this document makes no specific recommendations to operators 109 of DNS servers, it should be noted that failure to support TCP (or 110 blocking of DNS over TCP at the network layer) may result in 111 resolution failure and/or application-level timeouts. 113 2. Terminology used in this document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 3. Discussion 121 In the absence of EDNS0 (see below) the normal behaviour of any DNS 122 server needing to send a UDP response that would exceed the 512 byte 123 limit is for the server to truncate the response so that it fits 124 within that limit and then set the TC flag in the response header. 125 When the client receives such a response it takes the TC flag as an 126 indication that it should retry over TCP instead. 128 RFC 1123 also says: 130 ... it is also clear that some new DNS record types defined in the 131 future will contain information exceeding the 512 byte limit that 132 applies to UDP, and hence will require TCP. Thus, resolvers and 133 name servers should implement TCP services as a backup to UDP 134 today, with the knowledge that they will require the TCP service 135 in the future. 137 Existing deployments of DNSSEC [RFC4033] have shown that truncation 138 at the 512 byte boundary is now commonplace. For example an NXDOMAIN 139 (RCODE == 3) response from a DNSSEC signed zone using NSEC3 [RFC5155] 140 is almost invariably larger than 512 bytes. 142 Since the original core specifications for DNS were written, the 143 Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced. 144 These extensions can be used to indicate that the client is prepared 145 to receive UDP responses larger than 512 bytes. An EDNS0 compatible 146 server receiving a request from an EDNS0 compatible client may send 147 UDP packets up to that client's announced buffer size without 148 truncation. 150 However, transport of UDP packets that exceed the size of the path 151 MTU causes IP packet fragmentation, which has been found to be 152 unreliable in some circumstances. Many firewalls routinely block 153 fragmented IP packets, and some do not implement the algorithms 154 necessary to reassemble fragmented packets. Worse still, some 155 network devices deliberately refuse to handle DNS packets containing 156 EDNS0 options. Other issues relating to UDP transport and packet 157 size are discussed in [RFC5625]. 159 The MTU most commonly found in the core of the Internet is around 160 1500 bytes, and even that limit is routinely exceeded by DNSSEC 161 signed responses. 163 The future that was anticipated in RFC 1123 has arrived, and the only 164 standardised UDP-based mechanism which may have resolved the packet 165 size issue has been found inadequate. 167 4. Transport Protocol Selection 169 All general purpose DNS implementations MUST support both UDP and TCP 170 transport. 172 o Authoritative server implementations MUST support TCP so that they 173 do not limit the size of responses. 175 o Recursive resolver (or forwarder) implementations MUST support TCP 176 so that the do not prevent large responses from a TCP-capable 177 server from reaching its TCP-capable clients. 178 o Stub resolver implementations (e.g. an operating system's DNS 179 resolution library) MUST support TCP since to do otherwise would 180 limit their interoperability with their own clients and with 181 upstream servers. 183 An exception may be made for proprietary stub resolver 184 implementations. These MAY omit support for TCP if operating in an 185 environment where truncation can never occur, or where DNS lookup 186 failure is acceptable should truncation occur. 188 Regarding the choice of when to use UDP or TCP, RFC 1123 says: 190 ... a DNS resolver or server that is sending a non-zone-transfer 191 query MUST send a UDP query first. 193 That requirement is hereby relaxed. A resolver SHOULD send a UDP 194 query first, but MAY elect to send a TCP query instead if it has good 195 reason to expect the response would be truncated if it were sent over 196 UDP (with or without EDNS0) or for other operational reasons, in 197 particular if it already has an open TCP connection to the server. 199 5. Connection Handling 201 Section 4.2.2 of [RFC1035] says: 203 If the server needs to close a dormant connection to reclaim 204 resources, it should wait until the connection has been idle for a 205 period on the order of two minutes. In particular, the server 206 should allow the SOA and AXFR request sequence (which begins a 207 refresh operation) to be made on a single connection. Since the 208 server would be unable to answer queries anyway, a unilateral 209 close or reset may be used instead of a graceful close. 211 Other more modern protocols (e.g. HTTP [RFC2616]) have support for 212 persistent TCP connections and operational experience has shown that 213 long timeouts can easily cause resource exhaustion and poor response 214 under heavy load. Intentionally opening many connections and leaving 215 them dormant can trivially create a "denial of service" attack. 217 This document therefore RECOMMENDS that the default application-level 218 idle period should be of the order of seconds, but does not specify 219 any particular value. In practise the idle period may vary 220 dynamically, and servers MAY allow dormant connections to remain open 221 for longer periods as resources permit. 223 To mitigate the risk of unintentional server overload, DNS clients 224 MUST take care to minimize the number of concurrent TCP connections 225 made to any individual server. Similarly servers MAY impose limits 226 on the number of concurrent TCP connections being handled for any 227 particular client. 229 Further recommendations for the tuning of TCP stacks to allow higher 230 throughput or improved resiliency against denial of service attacks 231 are outside the scope of this document. 233 6. Response re-ordering 235 RFC 1035 is ambiguous on the question of whether TCP queries may be 236 re-ordered - the only relevant text is in Section 4.2.1 which relates 237 to UDP: 239 Queries or their responses may be reordered by the network, or by 240 processing in name servers, so resolvers should not depend on them 241 being returned in order. 243 For the avoidance of future doubt, this requirement is clarified. 244 Client resolvers MUST be able to process responses which arrive in a 245 different order to that in which the requests were sent, regardless 246 of the transport protocol in use. 248 7. Security Considerations 250 Some DNS server operators have expressed concern that wider use of 251 DNS over TCP will expose them to a higher risk of denial of service 252 (DoS) attacks. 254 Although there is a higher risk of such attacks against TCP-enabled 255 servers, techniques for the mitigation of DoS attacks at the network 256 level have improved substantially since DNS was first designed. 258 At the time of writing the vast majority of TLD authority servers and 259 all of the root name servers support TCP and the author knows of no 260 evidence to suggest that TCP-based DoS attacks against existing DNS 261 infrastructure are commonplace. 263 That notwithstanding, readers are advised to familiarise themselves 264 with [CPNI-TCP]. 266 Operators of recursive servers should ensure that they only accept 267 connections from expected clients, and do not accept them from 268 unknown sources. In the case of UDP traffic this will help protect 269 against reflector attacks [RFC5358] and in the case of TCP traffic it 270 will prevent an unknown client from exhausting the server's limits on 271 the number of concurrent connections. 273 8. IANA Considerations 275 This document requests no IANA actions. 277 9. Acknowledgements 279 The author would like to thank the document reviewers from the DNSEXT 280 Working Group, and in particular George Barwood, Alex Bligh, Alfred 281 Hoenes, Fernando Gont, Jim Reid, Paul Vixie and Nicholas Weaver. 283 10. References 285 10.1. Normative References 287 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 288 August 1980. 290 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 291 RFC 793, September 1981. 293 [RFC1035] Mockapetris, P., "Domain names - implementation and 294 specification", STD 13, RFC 1035, November 1987. 296 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 297 and Support", STD 3, RFC 1123, October 1989. 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 303 RFC 2671, August 1999. 305 10.2. Informative References 307 [CPNI-TCP] 308 CPNI, "Security Assessment of the Transmission Control 309 Protocol (TCP)", 2009, . 312 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 313 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 314 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 316 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 317 Rose, "DNS Security Introduction and Requirements", 318 RFC 4033, March 2005. 320 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 321 Security (DNSSEC) Hashed Authenticated Denial of 322 Existence", RFC 5155, March 2008. 324 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 325 Nameservers in Reflector Attacks", BCP 140, RFC 5358, 326 October 2008. 328 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 329 BCP 152, RFC 5625, August 2009. 331 Appendix A. Change Log 333 NB: to be removed by the RFC Editor before publication. 335 draft-ietf-dnsext-dns-tcp-requirements-03 336 Editorial nits from WGLC 337 Clarification on "general purpose" 338 Fixed ref to UDP (RFC 768) 339 Included more S.4.2.2 text from RFC 1035 and removed some from 340 this draft relating to connection resets. 341 s/long/large/ for packet sizes 343 draft-ietf-dnsext-dns-tcp-requirements-02 344 Change of title - more focus on implementation and not operation 345 Re-write of some of the security section 346 Added recommendation for minimal concurrent connections 347 Minor editorial nits from Alfred Hoenes 349 draft-ietf-dnsext-dns-tcp-requirements-01 350 Addition of response ordering section 351 Various minor editorial changes from WG reviewers 353 draft-ietf-dnsext-dns-tcp-requirements-00 354 Initial draft 356 Author's Address 358 Ray Bellis 359 Nominet UK 360 Edmund Halley Road 361 Oxford OX4 4DQ 362 United Kingdom 364 Phone: +44 1865 332211 365 Email: ray.bellis@nominet.org.uk 366 URI: http://www.nominet.org.uk/