1 Internet Engineering Task Force (IETF) R. Bellis
2 Request for Comments: 5966 Nominet UK
3 Updates: 1035, 1123 August 2010
4 Category: Standards Track
5 ISSN: 2070-1721
6
7
8 DNS Transport over TCP - Implementation Requirements
9
10 Abstract
11
12 This document updates the requirements for the support of TCP as a
13 transport protocol for DNS implementations.
14
15 Status of This Memo
16
17 This is an Internet Standards Track document.
18
19 This document is a product of the Internet Engineering Task Force
20 (IETF). It represents the consensus of the IETF community. It has
21 received public review and has been approved for publication by the
22 Internet Engineering Steering Group (IESG). Further information on
23 Internet Standards is available in Section 2 of RFC 5741.
24
25 Information about the current status of this document, any errata,
26 and how to provide feedback on it may be obtained at
27 http://www.rfc-editor.org/info/rfc5966.
28
29 Copyright Notice
30
31 Copyright (c) 2010 IETF Trust and the persons identified as the
32 document authors. All rights reserved.
33
34 This document is subject to BCP 78 and the IETF Trust's Legal
35 Provisions Relating to IETF Documents
36 (http://trustee.ietf.org/license-info) in effect on the date of
37 publication of this document. Please review these documents
38 carefully, as they describe your rights and restrictions with respect
39 to this document. Code Components extracted from this document must
40 include Simplified BSD License text as described in Section 4.e of
41 the Trust Legal Provisions and are provided without warranty as
42 described in the Simplified BSD License.
43
44
45
46
47
48
49
50
51
52 Bellis Standards Track [Page 1]
53 RFC 5966 DNS over TCP August 2010
54
55
56 Table of Contents
57
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Terminology Used in This Document . . . . . . . . . . . . . . . 3
60 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 4. Transport Protocol Selection . . . . . . . . . . . . . . . . . 4
62 5. Connection Handling . . . . . . . . . . . . . . . . . . . . . . 5
63 6. Response Reordering . . . . . . . . . . . . . . . . . . . . . . 6
64 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
68 9.2. Informative References . . . . . . . . . . . . . . . . . . 7
69
70 1. Introduction
71
72 Most DNS [RFC1034] transactions take place over UDP [RFC0768]. TCP
73 [RFC0793] is always used for zone transfers and is often used for
74 messages whose sizes exceed the DNS protocol's original 512-byte
75 limit.
76
77 Section 6.1.3.2 of [RFC1123] states:
78
79 DNS resolvers and recursive servers MUST support UDP, and SHOULD
80 support TCP, for sending (non-zone-transfer) queries.
81
82 However, some implementors have taken the text quoted above to mean
83 that TCP support is an optional feature of the DNS protocol.
84
85 The majority of DNS server operators already support TCP and the
86 default configuration for most software implementations is to support
87 TCP. The primary audience for this document is those implementors
88 whose failure to support TCP restricts interoperability and limits
89 deployment of new DNS features.
90
91 This document therefore updates the core DNS protocol specifications
92 such that support for TCP is henceforth a REQUIRED part of a full DNS
93 protocol implementation.
94
95 Whilst this document makes no specific recommendations to operators
96 of DNS servers, it should be noted that failure to support TCP (or
97 the blocking of DNS over TCP at the network layer) may result in
98 resolution failure and/or application-level timeouts.
99
100
101
102
103
104
105
106
107 Bellis Standards Track [Page 2]
108 RFC 5966 DNS over TCP August 2010
109
110
111 2. Terminology Used in This Document
112
113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
115 document are to be interpreted as described in [RFC2119].
116
117 3. Discussion
118
119 In the absence of EDNS0 (Extension Mechanisms for DNS 0) (see below),
120 the normal behaviour of any DNS server needing to send a UDP response
121 that would exceed the 512-byte limit is for the server to truncate
122 the response so that it fits within that limit and then set the TC
123 flag in the response header. When the client receives such a
124 response, it takes the TC flag as an indication that it should retry
125 over TCP instead.
126
127 RFC 1123 also says:
128
129 ... it is also clear that some new DNS record types defined in the
130 future will contain information exceeding the 512 byte limit that
131 applies to UDP, and hence will require TCP. Thus, resolvers and
132 name servers should implement TCP services as a backup to UDP
133 today, with the knowledge that they will require the TCP service
134 in the future.
135
136 Existing deployments of DNS Security (DNSSEC) [RFC4033] have shown
137 that truncation at the 512-byte boundary is now commonplace. For
138 example, a Non-Existent Domain (NXDOMAIN) (RCODE == 3) response from
139 a DNSSEC-signed zone using NextSECure 3 (NSEC3) [RFC5155] is almost
140 invariably larger than 512 bytes.
141
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.
149
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].
158
159
160
161
162 Bellis Standards Track [Page 3]
163 RFC 5966 DNS over TCP August 2010
164
165
166 The MTU most commonly found in the core of the Internet is around
167 1500 bytes, and even that limit is routinely exceeded by DNSSEC-
168 signed responses.
169
170 The future that was anticipated in RFC 1123 has arrived, and the only
171 standardised UDP-based mechanism that may have resolved the packet
172 size issue has been found inadequate.
173
174 4. Transport Protocol Selection
175
176 All general-purpose DNS implementations MUST support both UDP and TCP
177 transport.
178
179 o Authoritative server implementations MUST support TCP so that they
180 do not limit the size of responses to what fits in a single UDP
181 packet.
182
183 o Recursive server (or forwarder) implementations MUST support TCP
184 so that they do not prevent large responses from a TCP-capable
185 server from reaching its TCP-capable clients.
186
187 o Stub resolver implementations (e.g., an operating system's DNS
188 resolution library) MUST support TCP since to do otherwise would
189 limit their interoperability with their own clients and with
190 upstream servers.
191
192 Stub resolver implementations MAY omit support for TCP when
193 specifically designed for deployment in restricted environments where
194 truncation can never occur or where truncated DNS responses are
195 acceptable.
196
197 Regarding the choice of when to use UDP or TCP, Section 6.1.3.2 of
198 RFC 1123 also says:
199
200 ... a DNS resolver or server that is sending a non-zone-transfer
201 query MUST send a UDP query first.
202
203 That requirement is hereby relaxed. A resolver SHOULD send a UDP
204 query first, but MAY elect to send a TCP query instead if it has good
205 reason to expect the response would be truncated if it were sent over
206 UDP (with or without EDNS0) or for other operational reasons, in
207 particular, if it already has an open TCP connection to the server.
208
209
210
211
212
213
214
215
216
217 Bellis Standards Track [Page 4]
218 RFC 5966 DNS over TCP August 2010
219
220
221 5. Connection Handling
222
223 Section 4.2.2 of [RFC1035] says:
224
225 If the server needs to close a dormant connection to reclaim
226 resources, it should wait until the connection has been idle for a
227 period on the order of two minutes. In particular, the server
228 should allow the SOA and AXFR request sequence (which begins a
229 refresh operation) to be made on a single connection. Since the
230 server would be unable to answer queries anyway, a unilateral
231 close or reset may be used instead of a graceful close.
232
233 Other more modern protocols (e.g., HTTP [RFC2616]) have support for
234 persistent TCP connections and operational experience has shown that
235 long timeouts can easily cause resource exhaustion and poor response
236 under heavy load. Intentionally opening many connections and leaving
237 them dormant can trivially create a "denial-of-service" attack.
238
239 It is therefore RECOMMENDED that the default application-level idle
240 period should be of the order of seconds, but no particular value is
241 specified. In practise, the idle period may vary dynamically, and
242 servers MAY allow dormant connections to remain open for longer
243 periods as resources permit.
244
245 To mitigate the risk of unintentional server overload, DNS clients
246 MUST take care to minimize the number of concurrent TCP connections
247 made to any individual server. Similarly, servers MAY impose limits
248 on the number of concurrent TCP connections being handled for any
249 particular client.
250
251 Further recommendations for the tuning of TCP stacks to allow higher
252 throughput or improved resiliency against denial-of-service attacks
253 are outside the scope of this document.
254
255 6. Response Reordering
256
257 RFC 1035 is ambiguous on the question of whether TCP queries may be
258 reordered -- the only relevant text is in Section 4.2.1, which
259 relates to UDP:
260
261 Queries or their responses may be reordered by the network, or by
262 processing in name servers, so resolvers should not depend on them
263 being returned in order.
264
265 For the avoidance of future doubt, this requirement is clarified.
266 Client resolvers MUST be able to process responses that arrive in a
267 different order to that in which the requests were sent, regardless
268 of the transport protocol in use.
269
270
271
272 Bellis Standards Track [Page 5]
273 RFC 5966 DNS over TCP August 2010
274
275
276 7. Security Considerations
277
278 Some DNS server operators have expressed concern that wider use of
279 DNS over TCP will expose them to a higher risk of denial-of-service
280 (DoS) attacks.
281
282 Although there is a higher risk of such attacks against TCP-enabled
283 servers, techniques for the mitigation of DoS attacks at the network
284 level have improved substantially since DNS was first designed.
285
286 At the time of writing, the vast majority of Top Level Domain (TLD)
287 authority servers and all of the root name servers support TCP and
288 the author knows of no evidence to suggest that TCP-based DoS attacks
289 against existing DNS infrastructure are commonplace.
290
291 That notwithstanding, readers are advised to familiarise themselves
292 with [CPNI-TCP].
293
294 Operators of recursive servers should ensure that they only accept
295 connections from expected clients, and do not accept them from
296 unknown sources. In the case of UDP traffic, this will help protect
297 against reflector attacks [RFC5358] and in the case of TCP traffic it
298 will prevent an unknown client from exhausting the server's limits on
299 the number of concurrent connections.
300
301 8. Acknowledgements
302
303 The author would like to thank the document reviewers from the DNSEXT
304 Working Group, and in particular, George Barwood, Alex Bligh, Alfred
305 Hoenes, Fernando Gont, Olafur Gudmondsson, Jim Reid, Paul Vixie, and
306 Nicholas Weaver.
307
308 9. References
309
310 9.1. Normative References
311
312 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
313 August 1980.
314
315 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
316 RFC 793, September 1981.
317
318 [RFC1034] Mockapetris, P., "Domain names - concepts and
319 facilities", STD 13, RFC 1034, November 1987.
320
321 [RFC1035] Mockapetris, P., "Domain names - implementation and
322 specification", STD 13, RFC 1035, November 1987.
323
324
325
326
327 Bellis Standards Track [Page 6]
328 RFC 5966 DNS over TCP August 2010
329
330
331 [RFC1123] Braden, R., "Requirements for Internet Hosts -
332 Application and Support", STD 3, RFC 1123, October 1989.
333
334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
335 Requirement Levels", BCP 14, RFC 2119, March 1997.
336
337 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
338 RFC 2671, August 1999.
339
340 9.2. Informative References
341
342 [CPNI-TCP] CPNI, "Security Assessment of the Transmission Control
343 Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/
344 tn-03-09-security-assessment-TCP.pdf>.
345
346 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
347 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
348 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
349
350 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
351 Rose, "DNS Security Introduction and Requirements",
352 RFC 4033, March 2005.
353
354 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
355 Security (DNSSEC) Hashed Authenticated Denial of
356 Existence", RFC 5155, March 2008.
357
358 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
359 Nameservers in Reflector Attacks", BCP 140, RFC 5358,
360 October 2008.
361
362 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
363 BCP 152, RFC 5625, August 2009.
364
365 Author's Address
366
367 Ray Bellis
368 Nominet UK
369 Edmund Halley Road
370 Oxford OX4 4DQ
371 United Kingdom
372
373 Phone: +44 1865 332211
374 EMail: ray.bellis@nominet.org.uk
375 URI: http://www.nominet.org.uk/
376
377
378
379
380
381
382 Bellis Standards Track [Page 7]
383
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.