1 Internet Engineering Task Force (IETF) J. Dickinson
2 Request for Comments: 7766 S. Dickinson
3 Obsoletes: 5966 Sinodun
4 Updates: 1035, 1123 R. Bellis
5 Category: Standards Track ISC
6 ISSN: 2070-1721 A. Mankin
7 D. Wessels
8 Verisign Labs
9 March 2016
10
11
12 DNS Transport over TCP - Implementation Requirements
13
14 Abstract
15
16 This document specifies the requirement for support of TCP as a
17 transport protocol for DNS implementations and provides guidelines
18 towards DNS-over-TCP performance on par with that of DNS-over-UDP.
19 This document obsoletes RFC 5966 and therefore updates RFC 1035 and
20 RFC 1123.
21
22 Status of This Memo
23
24 This is an Internet Standards Track document.
25
26 This document is a product of the Internet Engineering Task Force
27 (IETF). It represents the consensus of the IETF community. It has
28 received public review and has been approved for publication by the
29 Internet Engineering Steering Group (IESG). Further information on
30 Internet Standards is available in Section 2 of RFC 5741.
31
32 Information about the current status of this document, any errata,
33 and how to provide feedback on it may be obtained at
34 http://www.rfc-editor.org/info/rfc7766.
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Dickinson, et al. Standards Track [Page 1]
53 RFC 7766 DNS over TCP March 2016
54
55
56 Copyright Notice
57
58 Copyright (c) 2016 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 Table of Contents
72
73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
74 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 4
75 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
76 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4
77 5. Transport Protocol Selection . . . . . . . . . . . . . . . . 5
78 6. Connection Handling . . . . . . . . . . . . . . . . . . . . . 6
79 6.1. Current Practices . . . . . . . . . . . . . . . . . . . . 6
80 6.1.1. Clients . . . . . . . . . . . . . . . . . . . . . . . 7
81 6.1.2. Servers . . . . . . . . . . . . . . . . . . . . . . . 7
82 6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 8
83 6.2.1. Connection Reuse . . . . . . . . . . . . . . . . . . 8
84 6.2.1.1. Query Pipelining . . . . . . . . . . . . . . . . 8
85 6.2.2. Concurrent Connections . . . . . . . . . . . . . . . 9
86 6.2.3. Idle Timeouts . . . . . . . . . . . . . . . . . . . . 9
87 6.2.4. Teardown . . . . . . . . . . . . . . . . . . . . . . 10
88 7. Response Reordering . . . . . . . . . . . . . . . . . . . . . 10
89 8. TCP Message Length Field . . . . . . . . . . . . . . . . . . 11
90 9. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . . . 11
91 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
93 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
94 11.2. Informative References . . . . . . . . . . . . . . . . . 14
95 Appendix A. Summary of Advantages and Disadvantages to Using TCP
96 for DNS . . . . . . . . . . . . . . . . . . . . . . 16
97 Appendix B. Changes to RFC 5966 . . . . . . . . . . . . . . . . 16
98 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
100
101
102
103
104
105
106
107 Dickinson, et al. Standards Track [Page 2]
108 RFC 7766 DNS over TCP March 2016
109
110
111 1. Introduction
112
113 Most DNS [RFC1034] transactions take place over UDP [RFC768]. TCP
114 [RFC793] is always used for full zone transfers (using AXFR) and is
115 often used for messages whose sizes exceed the DNS protocol's
116 original 512-byte limit. The growing deployment of DNS Security
117 (DNSSEC) and IPv6 has increased response sizes and therefore the use
118 of TCP. The need for increased TCP use has also been driven by the
119 protection it provides against address spoofing and therefore
120 exploitation of DNS in reflection/amplification attacks. It is now
121 widely used in Response Rate Limiting [RRL1] [RRL2]. Additionally,
122 recent work on DNS privacy solutions such as [DNS-over-TLS] is
123 another motivation to revisit DNS-over-TCP requirements.
124
125 Section 6.1.3.2 of [RFC1123] states:
126
127 DNS resolvers and recursive servers MUST support UDP, and SHOULD
128 support TCP, for sending (non-zone-transfer) queries.
129
130 However, some implementors have taken the text quoted above to mean
131 that TCP support is an optional feature of the DNS protocol.
132
133 The majority of DNS server operators already support TCP, and the
134 default configuration for most software implementations is to support
135 TCP. The primary audience for this document is those implementors
136 whose limited support for TCP restricts interoperability and hinders
137 deployment of new DNS features.
138
139 This document therefore updates the core DNS protocol specifications
140 such that support for TCP is henceforth a REQUIRED part of a full DNS
141 protocol implementation.
142
143 There are several advantages and disadvantages to the increased use
144 of TCP (see Appendix A) as well as implementation details that need
145 to be considered. This document addresses these issues and presents
146 TCP as a valid transport alternative for DNS. It extends the content
147 of [RFC5966], with additional considerations and lessons learned from
148 research, developments, and implementation of TCP in DNS and in other
149 Internet protocols.
150
151 Whilst this document makes no specific requirements for operators of
152 DNS servers to meet, it does offer some suggestions to operators to
153 help ensure that support for TCP on their servers and network is
154 optimal. It should be noted that failure to support TCP (or the
155 blocking of DNS over TCP at the network layer) will probably result
156 in resolution failure and/or application-level timeouts.
157
158
159
160
161
162 Dickinson, et al. Standards Track [Page 3]
163 RFC 7766 DNS over TCP March 2016
164
165
166 2. Requirements Terminology
167
168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
170 document are to be interpreted as described in [RFC2119].
171
172 3. Terminology
173
174 o Persistent connection: a TCP connection that is not closed either
175 by the server after sending the first response nor by the client
176 after receiving the first response.
177
178 o Connection Reuse: the sending of multiple queries and responses
179 over a single TCP connection.
180
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.
This RFC is implemented in BIND 9.18 (all versions).
181 o Idle DNS-over-TCP session: Clients and servers view application-
182 level idleness differently. A DNS client considers an established
183 DNS-over-TCP session to be idle when it has no pending queries to
184 send and there are no outstanding responses. A DNS server
185 considers an established DNS-over-TCP session to be idle when it
186 has sent responses to all the queries it has received on that
187 connection.
188
189 o Pipelining: the sending of multiple queries and responses over a
190 single TCP connection but not waiting for any outstanding replies
191 before sending another query.
192
193 o Out-of-Order Processing: The processing of queries concurrently
194 and the returning of individual responses as soon as they are
195 available, possibly out of order. This will most likely occur in
196 recursive servers; however, it is possible in authoritative
197 servers that, for example, have different backend data stores.
198
199 4. Discussion
200
201 In the absence of EDNS0 (Extension Mechanisms for DNS 0 [RFC6891];
202 see below), the normal behaviour of any DNS server that needs to send
203 a UDP response that would exceed the 512-byte limit is for the server
204 to truncate the response so that it fits within that limit and then
205 set the TC flag in the response header. When the client receives
206 such a response, it takes the TC flag as an indication that it should
207 retry over TCP instead.
208
209
210
211
212
213
214
215
216
217 Dickinson, et al. Standards Track [Page 4]
218 RFC 7766 DNS over TCP March 2016
219
220
221 RFC 1123 also says:
222
223 ... it is also clear that some new DNS record types defined in the
224 future will contain information exceeding the 512 byte limit that
225 applies to UDP, and hence will require TCP. Thus, resolvers and
226 name servers should implement TCP services as a backup to UDP
227 today, with the knowledge that they will require the TCP service
228 in the future.
229
230 Existing deployments of DNSSEC [RFC4033] have shown that truncation
231 at the 512-byte boundary is now commonplace. For example, a Non-
232 Existent Domain (NXDOMAIN) (RCODE == 3) response from a DNSSEC-signed
233 zone using NextSECure 3 (NSEC3) [RFC5155] is almost invariably larger
234 than 512 bytes.
235
236 Since the original core specifications for DNS were written, the
237 extension mechanisms for DNS have been introduced. These extensions
238 can be used to indicate that the client is prepared to receive UDP
239 responses larger than 512 bytes. An EDNS0-compatible server
240 receiving a request from an EDNS0-compatible client may send UDP
241 packets up to that client's announced buffer size without truncation.
242
243 However, transport of UDP packets that exceed the size of the path
244 MTU causes IP packet fragmentation, which has been found to be
245 unreliable in many circumstances. Many firewalls routinely block
246 fragmented IP packets, and some do not implement the algorithms
247 necessary to reassemble fragmented packets. Worse still, some
248 network devices deliberately refuse to handle DNS packets containing
249 EDNS0 options. Other issues relating to UDP transport and packet
250 size are discussed in [RFC5625].
251
252 The MTU most commonly found in the core of the Internet is around
253 1500 bytes, and even that limit is routinely exceeded by DNSSEC-
254 signed responses.
255
256 The future that was anticipated in RFC 1123 has arrived, and the only
257 standardised UDP-based mechanism that may have resolved the packet
258 size issue has been found inadequate.
259
260 5. Transport Protocol Selection
261
262 Section 6.1.3.2 of [RFC1123] is updated: All general-purpose DNS
263 implementations MUST support both UDP and TCP transport.
264
265 o Authoritative server implementations MUST support TCP so that they
266 do not limit the size of responses to what fits in a single UDP
267 packet.
268
269
270
271
272 Dickinson, et al. Standards Track [Page 5]
273 RFC 7766 DNS over TCP March 2016
274
275
276 o Recursive server (or forwarder) implementations MUST support TCP
277 so that they do not prevent large responses from a TCP-capable
278 server from reaching its TCP-capable clients.
279
280 o Stub resolver implementations (e.g., an operating system's DNS
281 resolution library) MUST support TCP since to do otherwise would
282 limit the interoperability between their own clients and upstream
283 servers.
284
285 Regarding the choice of when to use UDP or TCP, Section 6.1.3.2 of
286 RFC 1123 also says:
287
288 ... a DNS resolver or server that is sending a non-zone-transfer
289 query MUST send a UDP query first.
290
291 This requirement is hereby relaxed. Stub resolvers and recursive
292 resolvers MAY elect to send either TCP or UDP queries depending on
293 local operational reasons. TCP MAY be used before sending any UDP
294 queries. If the resolver already has an open TCP connection to the
295 server, it SHOULD reuse this connection. In essence, TCP ought to be
296 considered a valid alternative transport to UDP, not purely a retry
297 option.
298
299 In addition, it is noted that all recursive and authoritative servers
300 MUST send responses using the same transport as the query arrived on.
301 In the case of TCP, this MUST also be the same connection.
302
303 6. Connection Handling
304
305 6.1. Current Practices
306
307 Section 4.2.2 of [RFC1035] says:
308
309 - The server should assume that the client will initiate connection
310 closing, and should delay closing its end of the connection until
311 all outstanding client requests have been satisfied.
312
313 - If the server needs to close a dormant connection to reclaim
314 resources, it should wait until the connection has been idle for a
315 period on the order of two minutes. In particular, the server
316 should allow the SOA and AXFR request sequence (which begins a
317 refresh operation) to be made on a single connection. Since the
318 server would be unable to answer queries anyway, a unilateral
319 close or reset may be used instead of graceful close.
320
321
322
323
324
325
326
327 Dickinson, et al. Standards Track [Page 6]
328 RFC 7766 DNS over TCP March 2016
329
330
331 Other more modern protocols (e.g., HTTP/1.1 [RFC7230], HTTP/2
332 [RFC7540]) have support by default for persistent TCP connections for
333 all requests. Connections are then normally closed via a 'connection
334 close' signal from one party.
335
336 The description in [RFC1035] is clear that servers should view
337 connections as persistent (particularly after receiving an SOA), but
338 unfortunately does not provide enough detail for an unambiguous
339 interpretation of client behaviour for queries other than a SOA.
340 Additionally, DNS does not yet have a signalling mechanism for
341 connection timeout or close, although some have been proposed.
342
343 6.1.1. Clients
344
345 There is no clear guidance today in any RFC as to when a DNS client
346 should close a TCP connection, and there are no specific
347 recommendations with regard to DNS client idle timeouts. However, at
348 the time of writing, it is common practice for clients to close the
349 TCP connection after sending a single request (apart from the SOA/
350 AXFR case).
351
352 6.1.2. Servers
353
354 Many DNS server implementations use a long fixed idle timeout and
355 default to a small number of TCP connections. They also offer little
356 in the way of TCP connection management options. The disadvantages
357 of this include:
358
359 o Operational experience has shown that long server timeouts can
360 easily cause resource exhaustion and poor response under heavy
361 load.
362
363 o Intentionally opening many connections and leaving them idle can
364 trivially create a TCP denial of service (DoS) attack as many DNS
365 servers are poorly equipped to defend against this by modifying
366 their idle timeouts or other connection management policies.
367
368 o A modest number of clients that all concurrently attempt to use
369 persistent connections with non-zero idle timeouts to such a
370 server could unintentionally cause the same DoS problem.
371
372 Note that this DoS is only on the TCP service. However, in these
373 cases, it affects not only clients that wish to use TCP for their
374 queries for operational reasons, but all clients that choose to fall
375 back to TCP from UDP after receiving a TC=1 flag.
376
377
378
379
380
381
382 Dickinson, et al. Standards Track [Page 7]
383 RFC 7766 DNS over TCP March 2016
384
385
386 6.2. Recommendations
387
388 The following sections include recommendations that are intended to
389 result in more consistent and scalable implementations of DNS-over-
390 TCP.
391
392 6.2.1. Connection Reuse
393
394 One perceived disadvantage to DNS over TCP is the added connection
395 setup latency, generally equal to one RTT. To amortise connection
396 setup costs, both clients and servers SHOULD support connection reuse
397 by sending multiple queries and responses over a single persistent
398 TCP connection.
399
400 When sending multiple queries over a TCP connection, clients MUST NOT
401 reuse the DNS Message ID of an in-flight query on that connection in
402 order to avoid Message ID collisions. This is especially important
403 if the server could be performing out-of-order processing (see
404 Section 7).
405
406 6.2.1.1. Query Pipelining
407
408 Due to the historical use of TCP primarily for zone transfer and
409 truncated responses, no existing RFC discusses the idea of pipelining
410 DNS queries over a TCP connection.
411
412 In order to achieve performance on par with UDP, DNS clients SHOULD
413 pipeline their queries. When a DNS client sends multiple queries to
414 a server, it SHOULD NOT wait for an outstanding reply before sending
415 the next query. Clients SHOULD treat TCP and UDP equivalently when
416 considering the time at which to send a particular query.
417
418 It is likely that DNS servers need to process pipelined queries
419 concurrently and also send out-of-order responses over TCP in order
420 to provide the level of performance possible with UDP transport. If
421 TCP performance is of importance, clients might find it useful to use
422 server processing times as input to server and transport selection
423 algorithms.
424
425 DNS servers (especially recursive) MUST expect to receive pipelined
426 queries. The server SHOULD process TCP queries concurrently, just as
427 it would for UDP. The server SHOULD answer all pipelined queries,
428 even if they are received in quick succession. The handling of
429 responses to pipelined queries is covered in Section 7.
430
431
432
433
434
435
436
437 Dickinson, et al. Standards Track [Page 8]
438 RFC 7766 DNS over TCP March 2016
439
440
The abstract of RFC8490 says:
This document updates RFC 7766 by redefining a session, providing new guidance on connection reuse, and providing a new mechanism for handling session idle timeouts.It changes the inactivity timeout handling and connection sharing from this RFC.
Note that the changes from RFC8490 are only required when performing DNS stateful operations, which is signalled by using the DSO opcode (value 6).
441 6.2.2. Concurrent Connections
442
443 To mitigate the risk of unintentional server overload, DNS clients
444 MUST take care to minimize the number of concurrent TCP connections
445 made to any individual server. It is RECOMMENDED that for any given
446 client/server interaction there SHOULD be no more than one connection
447 for regular queries, one for zone transfers, and one for each
448 protocol that is being used on top of TCP (for example, if the
449 resolver was using TLS). However, it is noted that certain primary/
450 secondary configurations with many busy zones might need to use more
451 than one TCP connection for zone transfers for operational reasons
452 (for example, to support concurrent transfers of multiple zones).
453
454 Similarly, servers MAY impose limits on the number of concurrent TCP
455 connections being handled for any particular client IP address or
456 subnet. These limits SHOULD be much looser than the client
457 guidelines above, because the server does not know, for example, if a
458 client IP address belongs to a single client, is multiple resolvers
459 on a single machine, or is multiple clients behind a device
460 performing Network Address Translation (NAT).
461
462 6.2.3. Idle Timeouts
463
464 To mitigate the risk of unintentional server overload, DNS clients
465 MUST take care to minimise the idle time of established DNS-over-TCP
466 sessions made to any individual server. DNS clients SHOULD close the
467 TCP connection of an idle session, unless an idle timeout has been
468 established using some other signalling mechanism, for example,
469 [edns-tcp-keepalive].
470
471 To mitigate the risk of unintentional server overload, it is
472 RECOMMENDED that the default server application-level idle period be
473 on the order of seconds, but no particular value is specified. In
474 practice, the idle period can vary dynamically, and servers MAY allow
475 idle connections to remain open for longer periods as resources
476 permit. A timeout of at least a few seconds is advisable for normal
477 operations to support those clients that expect the SOA and AXFR
478 request sequence to be made on a single connection as originally
479 specified in [RFC1035]. Servers MAY use zero timeouts when they are
480 experiencing heavy load or are under attack.
481
482 DNS messages delivered over TCP might arrive in multiple segments. A
483 DNS server that resets its idle timeout after receiving a single
484 segment might be vulnerable to a "slow-read attack". For this
485 reason, servers SHOULD reset the idle timeout on the receipt of a
486 full DNS message, rather than on receipt of any part of a DNS
487 message.
488
489
490
491
492 Dickinson, et al. Standards Track [Page 9]
493 RFC 7766 DNS over TCP March 2016
494
495
496 6.2.4. Teardown
497
498 Under normal operation DNS clients typically initiate connection
499 closing on idle connections; however, DNS servers can close the
500 connection if the idle timeout set by local policy is exceeded.
501 Also, connections can be closed by either end under unusual
502 conditions such as defending against an attack or system failure/
503 reboot.
504
505 DNS clients SHOULD retry unanswered queries if the connection closes
506 before receiving all outstanding responses. No specific retry
507 algorithm is specified in this document.
508
509 If a DNS server finds that a DNS client has closed a TCP session (or
510 if the session has been otherwise interrupted) before all pending
511 responses have been sent, then the server MUST NOT attempt to send
512 those responses. Of course, the DNS server MAY cache those
513 responses.
514
515 7. Response Reordering
516
517 RFC 1035 is ambiguous on the question of whether TCP responses may be
518 reordered -- the only relevant text is in Section 4.2.1, which
519 relates to UDP:
520
521 Queries or their responses may be reordered by the network, or by
522 processing in name servers, so resolvers should not depend on them
523 being returned in order.
524
525 For the avoidance of future doubt, this requirement is clarified.
526 Authoritative servers and recursive resolvers are RECOMMENDED to
527 support the preparing of responses in parallel and sending them out
528 of order, regardless of the transport protocol in use. Stub and
529 recursive resolvers MUST be able to process responses that arrive in
530 a different order than that in which the requests were sent,
531 regardless of the transport protocol in use.
532
533 In order to achieve performance on par with UDP, recursive resolvers
534 SHOULD process TCP queries in parallel and return individual
535 responses as soon as they are available, possibly out of order.
536
537 Since pipelined responses can arrive out of order, clients MUST match
538 responses to outstanding queries on the same TCP connection using the
539 Message ID. If the response contains a question section, the client
540 MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients
541 to properly match responses to outstanding queries can have serious
542 consequences for interoperability.
543
544
545
546
547 Dickinson, et al. Standards Track [Page 10]
548 RFC 7766 DNS over TCP March 2016
549
550
551 8. TCP Message Length Field
552
553 DNS clients and servers SHOULD pass the two-octet length field, and
554 the message described by that length field, to the TCP layer at the
555 same time (e.g., in a single "write" system call) to make it more
556 likely that all the data will be transmitted in a single TCP segment.
557 This is for reasons of both efficiency and to avoid problems due to
558 some DNS server implementations behaving undesirably when reading
559 data from the TCP layer (due to a lack of clarity in previous
560 documents). For example, some DNS server implementations might abort
561 a TCP session if the first "read" from the TCP layer does not contain
562 both the length field and the entire message.
563
564 To clarify, DNS servers MUST NOT close a connection simply because
565 the first "read" from the TCP layer does not contain the entire DNS
566 message, and servers SHOULD apply the connection timeouts as
567 specified in Section 6.2.3.
568
569 9. TCP Fast Open
570
571 This section is non-normative.
572
573 TCP Fast Open (TFO) [RFC7413] allows data to be carried in the SYN
574 packet, reducing the cost of reopening TCP connections. It also
575 saves up to one RTT compared to standard TCP.
576
577 TFO mitigates the security vulnerabilities inherent in sending data
578 in the SYN, especially on a system like DNS where amplification
579 attacks are possible, by use of a server-supplied cookie. TFO
580 clients request a server cookie in the initial SYN packet at the
581 start of a new connection. The server returns a cookie in its SYN-
582 ACK. The client caches the cookie and reuses it when opening
583 subsequent connections to the same server.
584
585 The cookie is stored by the client's TCP stack (kernel) and persists
586 if either the client or server processes are restarted. TFO also
587 falls back to a regular TCP handshake gracefully.
588
589 DNS services taking advantage of IP anycast [RFC4786] might need to
590 take additional steps when enabling TFO. From [RFC7413]:
591
592 Servers behind load balancers that accept connection requests to
593 the same server IP address should use the same key such that they
594 generate identical Fast Open cookies for a particular client IP
595 address. Otherwise, a client may get different cookies across
596 connections; its Fast Open attempts would fall back to the regular
597 3WHS.
598
599
600
601
602 Dickinson, et al. Standards Track [Page 11]
603 RFC 7766 DNS over TCP March 2016
604
605
606 When DNS-over-TCP is a transport for DNS private exchange, as in
607 [DNS-over-TLS], the implementor needs to be aware of TFO and to
608 ensure that data requiring protection (e.g. data for a DNS query) is
609 not accidentally transported in the clear. See [DNS-over-TLS] for
610 discussion.
611
612 10. Security Considerations
613
614 Some DNS server operators have expressed concern that wider promotion
615 and use of DNS over TCP will expose them to a higher risk of DoS
616 attacks on TCP (both accidental and deliberate).
617
618 Although there is a higher risk of some specific attacks against TCP-
619 enabled servers, techniques for the mitigation of DoS attacks at the
620 network level have improved substantially since DNS was first
621 designed.
622
623 Readers are advised to familiarise themselves with [CPNI-TCP], a
624 security assessment of TCP that details known TCP attacks and
625 countermeasures and that references most of the relevant RFCs on this
626 topic.
627
628 To mitigate the risk of DoS attacks, DNS servers are advised to
629 engage in TCP connection management. This could include maintaining
630 state on existing connections, reusing existing connections, and
631 controlling request queues to enable fair use. It is likely to be
632 advantageous to provide configurable connection management options,
633 for example:
634
635 o total number of TCP connections
636
637 o maximum TCP connections per source IP address or subnet
638
639 o TCP connection idle timeout
640
641 o maximum DNS transactions per TCP connection
642
643 o maximum TCP connection duration
644
645 No specific values are recommended for these parameters.
646
647 Operators are advised to familiarise themselves with the
648 configuration and tuning parameters available in the TCP stack of the
649 operating system. However, detailed advice on this is outside the
650 scope of this document.
651
652
653
654
655
656
657 Dickinson, et al. Standards Track [Page 12]
658 RFC 7766 DNS over TCP March 2016
659
660
661 Operators of recursive servers are advised to ensure that they only
662 accept connections from expected clients (for example, by the use of
663 an Access Control List (ACL)) and do not accept them from unknown
664 sources. In the case of UDP traffic, this will help protect against
665 reflection attacks [RFC5358]; and in the case of TCP traffic, it will
666 prevent an unknown client from exhausting the server's limits on the
667 number of concurrent connections.
668
669 11. References
670
671 11.1. Normative References
672
673 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
674 DOI 10.17487/RFC0768, August 1980,
675 <http://www.rfc-editor.org/info/rfc768>.
676
677 [RFC793] Postel, J., "Transmission Control Protocol", STD 7,
678 RFC 793, DOI 10.17487/RFC0793, September 1981,
679 <http://www.rfc-editor.org/info/rfc793>.
680
681 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
682 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
683 <http://www.rfc-editor.org/info/rfc1034>.
684
685 [RFC1035] Mockapetris, P., "Domain names - implementation and
686 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
687 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
688
689 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
690 Application and Support", STD 3, RFC 1123,
691 DOI 10.17487/RFC1123, October 1989,
692 <http://www.rfc-editor.org/info/rfc1123>.
693
694 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
695 Requirement Levels", BCP 14, RFC 2119,
696 DOI 10.17487/RFC2119, March 1997,
697 <http://www.rfc-editor.org/info/rfc2119>.
698
699 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
700 Rose, "DNS Security Introduction and Requirements",
701 RFC 4033, DOI 10.17487/RFC4033, March 2005,
702 <http://www.rfc-editor.org/info/rfc4033>.
703
704 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
705 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
706 December 2006, <http://www.rfc-editor.org/info/rfc4786>.
707
708
709
710
711
712 Dickinson, et al. Standards Track [Page 13]
713 RFC 7766 DNS over TCP March 2016
714
715
716 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
717 Security (DNSSEC) Hashed Authenticated Denial of
718 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
719 <http://www.rfc-editor.org/info/rfc5155>.
720
721 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
722 Nameservers in Reflector Attacks", BCP 140, RFC 5358,
723 DOI 10.17487/RFC5358, October 2008,
724 <http://www.rfc-editor.org/info/rfc5358>.
725
726 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
727 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
728 <http://www.rfc-editor.org/info/rfc5625>.
729
730 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation
731 Requirements", RFC 5966, DOI 10.17487/RFC5966, August
732 2010, <http://www.rfc-editor.org/info/rfc5966>.
733
734 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
735 for DNS (EDNS(0))", STD 75, RFC 6891,
736 DOI 10.17487/RFC6891, April 2013,
737 <http://www.rfc-editor.org/info/rfc6891>.
738
739 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
740 Protocol (HTTP/1.1): Message Syntax and Routing",
741 RFC 7230, DOI 10.17487/RFC7230, June 2014,
742 <http://www.rfc-editor.org/info/rfc7230>.
743
744 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
745 Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
746 DOI 10.17487/RFC7540, May 2015,
747 <http://www.rfc-editor.org/info/rfc7540>.
748
749 11.2. Informative References
750
751 [Connection-Oriented-DNS]
752 Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A.,
753 and N. Somaiya, "Connection-Oriented DNS to Improve
754 Privacy and Security", 2015 IEEE Symposium on Security and
755 Privacy (SP), DOI 10.1109/SP.2015.18,
756 <http://ieeexplore.ieee.org/xpl/
757 articleDetails.jsp?arnumber=7163025>.
758
759 [CPNI-TCP]
760 CPNI, "Security Assessment of the Transmission Control
761 Protocol (TCP)", 2009, <http://www.gont.com.ar/papers/
762 tn-03-09-security-assessment-TCP.pdf>.
763
764
765
766
767 Dickinson, et al. Standards Track [Page 14]
768 RFC 7766 DNS over TCP March 2016
769
770
771 [DNS-over-TLS]
772 Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
773 and P. Hoffman, "Specification for DNS over TLS", Work in
774 Progress, draft-ietf-dprive-dns-over-tls-06, February
775 2016.
776
777 [edns-tcp-keepalive]
778 Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
779 edns-tcp-keepalive EDNS0 Option", Work in Progress,
780 draft-ietf-dnsop-edns-tcp-keepalive-03, September 2015.
781
782 [fragmentation-considered-poisonous]
783 Herzberg, A. and H. Shulman, "Fragmentation Considered
784 Poisonous", May 2012, <http://arxiv.org/abs/1205.4011>.
785
786 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
787 for Application Designers", BCP 145, RFC 5405,
788 DOI 10.17487/RFC5405, November 2008,
789 <http://www.rfc-editor.org/info/rfc5405>.
790
791 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
792 "TCP Extensions for Multipath Operation with Multiple
793 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
794 <http://www.rfc-editor.org/info/rfc6824>.
795
796 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
797 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
798 <http://www.rfc-editor.org/info/rfc7413>.
799
800 [RRL1] Vixie, P. and V. Schryver, "DNS Response Rate Limiting
801 (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012,
802 <https://ftp.isc.org/isc/pubs/tn/isc-tn-2012-1.txt>.
803
804 [RRL2] ISC Support, "Using the Response Rate Limiting Feature in
805 BIND 9.10", ISC Knowledge Base AA-00994, June 2013,
806 <https://kb.isc.org/article/AA-00994/>.
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822 Dickinson, et al. Standards Track [Page 15]
823 RFC 7766 DNS over TCP March 2016
824
825
826 Appendix A. Summary of Advantages and Disadvantages to Using TCP for
827 DNS
828
829 The TCP handshake generally prevents address spoofing and, therefore,
830 the reflection/amplification attacks that plague UDP.
831
832 IP fragmentation is less of a problem for TCP than it is for UDP.
833 TCP stacks generally implement Path MTU Discovery so they can avoid
834 IP fragmentation of TCP segments. UDP, on the other hand, does not
835 provide reassembly; this means datagrams that exceed the path MTU
836 size must experience fragmentation [RFC5405]. Middleboxes are known
837 to block IP fragments, leading to timeouts and forcing client
838 implementations to "hunt" for EDNS0 reply size values supported by
839 the network path. Additionally, fragmentation may lead to cache
840 poisoning [fragmentation-considered-poisonous].
841
842 TCP setup costs an additional RTT compared to UDP queries. Setup
843 costs can be amortised by reusing connections, pipelining queries,
844 and enabling TCP Fast Open.
845
846 TCP imposes additional state-keeping requirements on clients and
847 servers. The use of TCP Fast Open reduces the cost of closing and
848 reopening TCP connections.
849
850 Long-lived TCP connections to anycast servers might be disrupted due
851 to routing changes. Clients utilizing TCP for DNS need to always be
852 prepared to re-establish connections or otherwise retry outstanding
853 queries. It might also be possible for Multipath TCP [RFC6824] to
854 allow a server to hand a connection over from the anycast address to
855 a unicast address.
856
857 There are many "middleboxes" in use today that interfere with TCP
858 over port 53 [RFC5625]. This document does not propose any
859 solutions, other than to make it absolutely clear that TCP is a valid
860 transport for DNS and support for it is a requirement for all
861 implementations.
862
863 A more in-depth discussion of connection-oriented DNS can be found
864 elsewhere [Connection-Oriented-DNS].
865
866 Appendix B. Changes to RFC 5966
867
868 This document obsoletes [RFC5966] and differs from it in several
869 respects. An overview of the most substantial changes/updates that
870 implementors should take note of is given below.
871
872 1. A Terminology section (Section 3) is added defining several new
873 concepts.
874
875
876
877 Dickinson, et al. Standards Track [Page 16]
878 RFC 7766 DNS over TCP March 2016
879
880
881 2. Paragraph 3 of Section 5 puts TCP on a more equal footing with
882 UDP than RFC 5966 does. For example, it states:
883
884 1. TCP MAY be used before sending any UDP queries.
885
886 2. TCP ought to be considered a valid alternative transport to
887 UDP, not purely a fallback option.
888
889 3. Section 6.2.1 adds a new recommendation that TCP connection
890 reuse SHOULD be supported.
891
892 4. Section 6.2.1.1 adds a new recommendation that DNS clients
893 SHOULD pipeline their queries and DNS servers SHOULD process
894 pipelined queries concurrently.
895
896 5. Section 6.2.2 adds new recommendations on the number and usage
897 of TCP connections for client/server interactions.
898
899 6. Section 6.2.3 adds a new recommendation that DNS clients SHOULD
900 close idle sessions unless using a signalling mechanism.
901
902 7. Section 7 clarifies that servers are RECOMMENDED to prepare TCP
903 responses in parallel and send answers out of order. It also
904 clarifies how TCP queries and responses should be matched by
905 clients.
906
907 8. Section 8 adds a new recommendation about how DNS clients and
908 servers should handle the 2-byte message length field for TCP
909 messages.
910
911 9. Section 9 adds a non-normative discussion of the use of TCP Fast
912 Open.
913
914 10. Section 10 adds new advice regarding DoS mitigation techniques.
915
916 Acknowledgements
917
918 The authors would like to thank Francis Dupont and Paul Vixie for
919 their detailed reviews, as well as Andrew Sullivan, Tony Finch,
920 Stephane Bortzmeyer, Joe Abley, Tatuya Jinmei, and the many others
921 who contributed to the mailing list discussion. Also, the authors
922 thank Liang Zhu, Zi Hu, and John Heidemann for extensive DNS-over-TCP
923 discussions and code, and Lucie Guiraud and Danny McPherson for
924 reviewing early draft versions of this document. We would also like
925 to thank all those who contributed to RFC 5966.
926
927
928
929
930
931
932 Dickinson, et al. Standards Track [Page 17]
933 RFC 7766 DNS over TCP March 2016
934
935
936 Authors' Addresses
937
938 John Dickinson
939 Sinodun Internet Technologies
940 Magdalen Centre
941 Oxford Science Park
942 Oxford OX4 4GA
943 United Kingdom
944
945 Email: jad@sinodun.com
946 URI: http://sinodun.com
947
948
949 Sara Dickinson
950 Sinodun Internet Technologies
951 Magdalen Centre
952 Oxford Science Park
953 Oxford OX4 4GA
954 United Kingdom
955
956 Email: sara@sinodun.com
957 URI: http://sinodun.com
958
959
960 Ray Bellis
961 Internet Systems Consortium, Inc
962 950 Charter Street
963 Redwood City, CA 94063
964 United States
965
966 Phone: +1 650 423 1200
967 Email: ray@isc.org
968 URI: http://www.isc.org
969
970
971 Allison Mankin
972 Verisign Labs
973 12061 Bluemont Way
974 Reston, VA 20190
975 United States
976
977 Phone: +1 301 728 7198
978 Email: allison.mankin@gmail.com
979
980
981
982
983
984
985
986
987 Dickinson, et al. Standards Track [Page 18]
988 RFC 7766 DNS over TCP March 2016
989
990
991 Duane Wessels
992 Verisign Labs
993 12061 Bluemont Way
994 Reston, VA 20190
995 United States
996
997 Phone: +1 703 948 3200
998 Email: dwessels@verisign.com
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042 Dickinson, et al. Standards Track [Page 19]
1043