7Internet Engineering Task Force (IETF) J. Dickinson
8Request for Comments: 7766 S. Dickinson
10Updates: 1035, 1123 R. Bellis
11Category: Standards Track ISC
12ISSN: 2070-1721 A. Mankin
18 DNS Transport over TCP - Implementation Requirements
22 This document specifies the requirement for support of TCP as a
23 transport protocol for DNS implementations and provides guidelines
24 towards DNS-over-TCP performance on par with that of DNS-over-UDP.
25 This document obsoletes RFC 5966 and therefore updates RFC 1035 and
30 This is an Internet Standards Track document.
32 This document is a product of the Internet Engineering Task Force
33 (IETF). It represents the consensus of the IETF community. It has
34 received public review and has been approved for publication by the
35 Internet Engineering Steering Group (IESG). Further information on
36 Internet Standards is available in Section 2 of RFC 5741.
38 Information about the current status of this document, any errata,
39 and how to provide feedback on it may be obtained at
40 http://www.rfc-editor.org/info/rfc7766.
58Dickinson, et al. Standards Track [Page 1]
60RFC 7766 DNS over TCP March 2016
65 Copyright (c) 2016 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
81 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 4
82 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
83 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4
84 5. Transport Protocol Selection . . . . . . . . . . . . . . . . 5
85 6. Connection Handling . . . . . . . . . . . . . . . . . . . . . 6
86 6.1. Current Practices . . . . . . . . . . . . . . . . . . . . 6
87 6.1.1. Clients . . . . . . . . . . . . . . . . . . . . . . . 7
88 6.1.2. Servers . . . . . . . . . . . . . . . . . . . . . . . 7
89 6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 8
90 6.2.1. Connection Reuse . . . . . . . . . . . . . . . . . . 8
91 6.2.1.1. Query Pipelining . . . . . . . . . . . . . . . . 8
92 6.2.2. Concurrent Connections . . . . . . . . . . . . . . . 9
93 6.2.3. Idle Timeouts . . . . . . . . . . . . . . . . . . . . 9
94 6.2.4. Teardown . . . . . . . . . . . . . . . . . . . . . . 10
95 7. Response Reordering . . . . . . . . . . . . . . . . . . . . . 10
96 8. TCP Message Length Field . . . . . . . . . . . . . . . . . . 11
97 9. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . . . 11
98 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
100 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
101 11.2. Informative References . . . . . . . . . . . . . . . . . 14
102 Appendix A. Summary of Advantages and Disadvantages to Using TCP
103 for DNS . . . . . . . . . . . . . . . . . . . . . . 16
104 Appendix B. Changes to RFC 5966 . . . . . . . . . . . . . . . . 16
105 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
114Dickinson, et al. Standards Track [Page 2]
116RFC 7766 DNS over TCP March 2016
121 Most DNS [RFC1034] transactions take place over UDP [RFC768]. TCP
122 [RFC793] is always used for full zone transfers (using AXFR) and is
123 often used for messages whose sizes exceed the DNS protocol's
124 original 512-byte limit. The growing deployment of DNS Security
125 (DNSSEC) and IPv6 has increased response sizes and therefore the use
126 of TCP. The need for increased TCP use has also been driven by the
127 protection it provides against address spoofing and therefore
128 exploitation of DNS in reflection/amplification attacks. It is now
129 widely used in Response Rate Limiting [RRL1] [RRL2]. Additionally,
130 recent work on DNS privacy solutions such as [DNS-over-TLS] is
131 another motivation to revisit DNS-over-TCP requirements.
133 Section 6.1.3.2 of [RFC1123] states:
135 DNS resolvers and recursive servers MUST support UDP, and SHOULD
136 support TCP, for sending (non-zone-transfer) queries.
138 However, some implementors have taken the text quoted above to mean
139 that TCP support is an optional feature of the DNS protocol.
141 The majority of DNS server operators already support TCP, and the
142 default configuration for most software implementations is to support
143 TCP. The primary audience for this document is those implementors
144 whose limited support for TCP restricts interoperability and hinders
145 deployment of new DNS features.
147 This document therefore updates the core DNS protocol specifications
148 such that support for TCP is henceforth a REQUIRED part of a full DNS
149 protocol implementation.
151 There are several advantages and disadvantages to the increased use
152 of TCP (see Appendix A) as well as implementation details that need
153 to be considered. This document addresses these issues and presents
154 TCP as a valid transport alternative for DNS. It extends the content
155 of [RFC5966], with additional considerations and lessons learned from
156 research, developments, and implementation of TCP in DNS and in other
159 Whilst this document makes no specific requirements for operators of
160 DNS servers to meet, it does offer some suggestions to operators to
161 help ensure that support for TCP on their servers and network is
162 optimal. It should be noted that failure to support TCP (or the
163 blocking of DNS over TCP at the network layer) will probably result
164 in resolution failure and/or application-level timeouts.
170Dickinson, et al. Standards Track [Page 3]
172RFC 7766 DNS over TCP March 2016
1752. Requirements Terminology
177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
179 document are to be interpreted as described in [RFC2119].
183 o Persistent connection: a TCP connection that is not closed either
184 by the server after sending the first response nor by the client
185 after receiving the first response.
187 o Connection Reuse: the sending of multiple queries and responses
188 over a single TCP connection.
190 o Idle DNS-over-TCP session: Clients and servers view application-
191 level idleness differently. A DNS client considers an established
192 DNS-over-TCP session to be idle when it has no pending queries to
193 send and there are no outstanding responses. A DNS server
194 considers an established DNS-over-TCP session to be idle when it
195 has sent responses to all the queries it has received on that
198 o Pipelining: the sending of multiple queries and responses over a
199 single TCP connection but not waiting for any outstanding replies
200 before sending another query.
202 o Out-of-Order Processing: The processing of queries concurrently
203 and the returning of individual responses as soon as they are
204 available, possibly out of order. This will most likely occur in
205 recursive servers; however, it is possible in authoritative
206 servers that, for example, have different backend data stores.
210 In the absence of EDNS0 (Extension Mechanisms for DNS 0 [RFC6891];
211 see below), the normal behaviour of any DNS server that needs to send
212 a UDP response that would exceed the 512-byte limit is for the server
213 to truncate the response so that it fits within that limit and then
214 set the TC flag in the response header. When the client receives
215 such a response, it takes the TC flag as an indication that it should
216 retry over TCP instead.
226Dickinson, et al. Standards Track [Page 4]
228RFC 7766 DNS over TCP March 2016
233 ... it is also clear that some new DNS record types defined in the
234 future will contain information exceeding the 512 byte limit that
235 applies to UDP, and hence will require TCP. Thus, resolvers and
236 name servers should implement TCP services as a backup to UDP
237 today, with the knowledge that they will require the TCP service
240 Existing deployments of DNSSEC [RFC4033] have shown that truncation
241 at the 512-byte boundary is now commonplace. For example, a Non-
242 Existent Domain (NXDOMAIN) (RCODE == 3) response from a DNSSEC-signed
243 zone using NextSECure 3 (NSEC3) [RFC5155] is almost invariably larger
246 Since the original core specifications for DNS were written, the
247 extension mechanisms for DNS have been introduced. These extensions
248 can be used to indicate that the client is prepared to receive UDP
249 responses larger than 512 bytes. An EDNS0-compatible server
250 receiving a request from an EDNS0-compatible client may send UDP
251 packets up to that client's announced buffer size without truncation.
253 However, transport of UDP packets that exceed the size of the path
254 MTU causes IP packet fragmentation, which has been found to be
255 unreliable in many circumstances. Many firewalls routinely block
256 fragmented IP packets, and some do not implement the algorithms
257 necessary to reassemble fragmented packets. Worse still, some
258 network devices deliberately refuse to handle DNS packets containing
259 EDNS0 options. Other issues relating to UDP transport and packet
260 size are discussed in [RFC5625].
262 The MTU most commonly found in the core of the Internet is around
263 1500 bytes, and even that limit is routinely exceeded by DNSSEC-
266 The future that was anticipated in RFC 1123 has arrived, and the only
267 standardised UDP-based mechanism that may have resolved the packet
268 size issue has been found inadequate.
2705. Transport Protocol Selection
272 Section 6.1.3.2 of [RFC1123] is updated: All general-purpose DNS
273 implementations MUST support both UDP and TCP transport.
275 o Authoritative server implementations MUST support TCP so that they
276 do not limit the size of responses to what fits in a single UDP
282Dickinson, et al. Standards Track [Page 5]
284RFC 7766 DNS over TCP March 2016
287 o Recursive server (or forwarder) implementations MUST support TCP
288 so that they do not prevent large responses from a TCP-capable
289 server from reaching its TCP-capable clients.
291 o Stub resolver implementations (e.g., an operating system's DNS
292 resolution library) MUST support TCP since to do otherwise would
293 limit the interoperability between their own clients and upstream
296 Regarding the choice of when to use UDP or TCP, Section 6.1.3.2 of
299 ... a DNS resolver or server that is sending a non-zone-transfer
300 query MUST send a UDP query first.
302 This requirement is hereby relaxed. Stub resolvers and recursive
303 resolvers MAY elect to send either TCP or UDP queries depending on
304 local operational reasons. TCP MAY be used before sending any UDP
305 queries. If the resolver already has an open TCP connection to the
306 server, it SHOULD reuse this connection. In essence, TCP ought to be
307 considered a valid alternative transport to UDP, not purely a retry
310 In addition, it is noted that all recursive and authoritative servers
311 MUST send responses using the same transport as the query arrived on.
312 In the case of TCP, this MUST also be the same connection.
3146. Connection Handling
3166.1. Current Practices
318 Section 4.2.2 of [RFC1035] says:
320 - The server should assume that the client will initiate connection
321 closing, and should delay closing its end of the connection until
322 all outstanding client requests have been satisfied.
324 - If the server needs to close a dormant connection to reclaim
325 resources, it should wait until the connection has been idle for a
326 period on the order of two minutes. In particular, the server
327 should allow the SOA and AXFR request sequence (which begins a
328 refresh operation) to be made on a single connection. Since the
329 server would be unable to answer queries anyway, a unilateral
330 close or reset may be used instead of graceful close.
338Dickinson, et al. Standards Track [Page 6]
340RFC 7766 DNS over TCP March 2016
343 Other more modern protocols (e.g., HTTP/1.1 [RFC7230], HTTP/2
344 [RFC7540]) have support by default for persistent TCP connections for
345 all requests. Connections are then normally closed via a 'connection
346 close' signal from one party.
348 The description in [RFC1035] is clear that servers should view
349 connections as persistent (particularly after receiving an SOA), but
350 unfortunately does not provide enough detail for an unambiguous
351 interpretation of client behaviour for queries other than a SOA.
352 Additionally, DNS does not yet have a signalling mechanism for
353 connection timeout or close, although some have been proposed.
357 There is no clear guidance today in any RFC as to when a DNS client
358 should close a TCP connection, and there are no specific
359 recommendations with regard to DNS client idle timeouts. However, at
360 the time of writing, it is common practice for clients to close the
361 TCP connection after sending a single request (apart from the SOA/
366 Many DNS server implementations use a long fixed idle timeout and
367 default to a small number of TCP connections. They also offer little
368 in the way of TCP connection management options. The disadvantages
371 o Operational experience has shown that long server timeouts can
372 easily cause resource exhaustion and poor response under heavy
375 o Intentionally opening many connections and leaving them idle can
376 trivially create a TCP denial of service (DoS) attack as many DNS
377 servers are poorly equipped to defend against this by modifying
378 their idle timeouts or other connection management policies.
380 o A modest number of clients that all concurrently attempt to use
381 persistent connections with non-zero idle timeouts to such a
382 server could unintentionally cause the same DoS problem.
384 Note that this DoS is only on the TCP service. However, in these
385 cases, it affects not only clients that wish to use TCP for their
386 queries for operational reasons, but all clients that choose to fall
387 back to TCP from UDP after receiving a TC=1 flag.
394Dickinson, et al. Standards Track [Page 7]
396RFC 7766 DNS over TCP March 2016
401 The following sections include recommendations that are intended to
402 result in more consistent and scalable implementations of DNS-over-
4056.2.1. Connection Reuse
407 One perceived disadvantage to DNS over TCP is the added connection
408 setup latency, generally equal to one RTT. To amortise connection
409 setup costs, both clients and servers SHOULD support connection reuse
410 by sending multiple queries and responses over a single persistent
413 When sending multiple queries over a TCP connection, clients MUST NOT
414 reuse the DNS Message ID of an in-flight query on that connection in
415 order to avoid Message ID collisions. This is especially important
416 if the server could be performing out-of-order processing (see
4196.2.1.1. Query Pipelining
421 Due to the historical use of TCP primarily for zone transfer and
422 truncated responses, no existing RFC discusses the idea of pipelining
423 DNS queries over a TCP connection.
425 In order to achieve performance on par with UDP, DNS clients SHOULD
426 pipeline their queries. When a DNS client sends multiple queries to
427 a server, it SHOULD NOT wait for an outstanding reply before sending
428 the next query. Clients SHOULD treat TCP and UDP equivalently when
429 considering the time at which to send a particular query.
431 It is likely that DNS servers need to process pipelined queries
432 concurrently and also send out-of-order responses over TCP in order
433 to provide the level of performance possible with UDP transport. If
434 TCP performance is of importance, clients might find it useful to use
435 server processing times as input to server and transport selection
438 DNS servers (especially recursive) MUST expect to receive pipelined
439 queries. The server SHOULD process TCP queries concurrently, just as
440 it would for UDP. The server SHOULD answer all pipelined queries,
441 even if they are received in quick succession. The handling of
442 responses to pipelined queries is covered in Section 7.
450Dickinson, et al. Standards Track [Page 8]
452RFC 7766 DNS over TCP March 2016
4556.2.2. Concurrent Connections
457 To mitigate the risk of unintentional server overload, DNS clients
458 MUST take care to minimize the number of concurrent TCP connections
459 made to any individual server. It is RECOMMENDED that for any given
460 client/server interaction there SHOULD be no more than one connection
461 for regular queries, one for zone transfers, and one for each
462 protocol that is being used on top of TCP (for example, if the
463 resolver was using TLS). However, it is noted that certain primary/
464 secondary configurations with many busy zones might need to use more
465 than one TCP connection for zone transfers for operational reasons
466 (for example, to support concurrent transfers of multiple zones).
468 Similarly, servers MAY impose limits on the number of concurrent TCP
469 connections being handled for any particular client IP address or
470 subnet. These limits SHOULD be much looser than the client
471 guidelines above, because the server does not know, for example, if a
472 client IP address belongs to a single client, is multiple resolvers
473 on a single machine, or is multiple clients behind a device
474 performing Network Address Translation (NAT).
478 To mitigate the risk of unintentional server overload, DNS clients
479 MUST take care to minimise the idle time of established DNS-over-TCP
480 sessions made to any individual server. DNS clients SHOULD close the
481 TCP connection of an idle session, unless an idle timeout has been
482 established using some other signalling mechanism, for example,
483 [edns-tcp-keepalive].
485 To mitigate the risk of unintentional server overload, it is
486 RECOMMENDED that the default server application-level idle period be
487 on the order of seconds, but no particular value is specified. In
488 practice, the idle period can vary dynamically, and servers MAY allow
489 idle connections to remain open for longer periods as resources
490 permit. A timeout of at least a few seconds is advisable for normal
491 operations to support those clients that expect the SOA and AXFR
492 request sequence to be made on a single connection as originally
493 specified in [RFC1035]. Servers MAY use zero timeouts when they are
494 experiencing heavy load or are under attack.
496 DNS messages delivered over TCP might arrive in multiple segments. A
497 DNS server that resets its idle timeout after receiving a single
498 segment might be vulnerable to a "slow-read attack". For this
499 reason, servers SHOULD reset the idle timeout on the receipt of a
500 full DNS message, rather than on receipt of any part of a DNS
506Dickinson, et al. Standards Track [Page 9]
508RFC 7766 DNS over TCP March 2016
513 Under normal operation DNS clients typically initiate connection
514 closing on idle connections; however, DNS servers can close the
515 connection if the idle timeout set by local policy is exceeded.
516 Also, connections can be closed by either end under unusual
517 conditions such as defending against an attack or system failure/
520 DNS clients SHOULD retry unanswered queries if the connection closes
521 before receiving all outstanding responses. No specific retry
522 algorithm is specified in this document.
524 If a DNS server finds that a DNS client has closed a TCP session (or
525 if the session has been otherwise interrupted) before all pending
526 responses have been sent, then the server MUST NOT attempt to send
527 those responses. Of course, the DNS server MAY cache those
5307. Response Reordering
532 RFC 1035 is ambiguous on the question of whether TCP responses may be
533 reordered -- the only relevant text is in Section 4.2.1, which
536 Queries or their responses may be reordered by the network, or by
537 processing in name servers, so resolvers should not depend on them
538 being returned in order.
540 For the avoidance of future doubt, this requirement is clarified.
541 Authoritative servers and recursive resolvers are RECOMMENDED to
542 support the preparing of responses in parallel and sending them out
543 of order, regardless of the transport protocol in use. Stub and
544 recursive resolvers MUST be able to process responses that arrive in
545 a different order than that in which the requests were sent,
546 regardless of the transport protocol in use.
548 In order to achieve performance on par with UDP, recursive resolvers
549 SHOULD process TCP queries in parallel and return individual
550 responses as soon as they are available, possibly out of order.
552 Since pipelined responses can arrive out of order, clients MUST match
553 responses to outstanding queries on the same TCP connection using the
554 Message ID. If the response contains a question section, the client
555 MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients
556 to properly match responses to outstanding queries can have serious
557 consequences for interoperability.
562Dickinson, et al. Standards Track [Page 10]
564RFC 7766 DNS over TCP March 2016
5678. TCP Message Length Field
569 DNS clients and servers SHOULD pass the two-octet length field, and
570 the message described by that length field, to the TCP layer at the
571 same time (e.g., in a single "write" system call) to make it more
572 likely that all the data will be transmitted in a single TCP segment.
573 This is for reasons of both efficiency and to avoid problems due to
574 some DNS server implementations behaving undesirably when reading
575 data from the TCP layer (due to a lack of clarity in previous
576 documents). For example, some DNS server implementations might abort
577 a TCP session if the first "read" from the TCP layer does not contain
578 both the length field and the entire message.
580 To clarify, DNS servers MUST NOT close a connection simply because
581 the first "read" from the TCP layer does not contain the entire DNS
582 message, and servers SHOULD apply the connection timeouts as
583 specified in Section 6.2.3.
587 This section is non-normative.
589 TCP Fast Open (TFO) [RFC7413] allows data to be carried in the SYN
590 packet, reducing the cost of reopening TCP connections. It also
591 saves up to one RTT compared to standard TCP.
593 TFO mitigates the security vulnerabilities inherent in sending data
594 in the SYN, especially on a system like DNS where amplification
595 attacks are possible, by use of a server-supplied cookie. TFO
596 clients request a server cookie in the initial SYN packet at the
597 start of a new connection. The server returns a cookie in its SYN-
598 ACK. The client caches the cookie and reuses it when opening
599 subsequent connections to the same server.
601 The cookie is stored by the client's TCP stack (kernel) and persists
602 if either the client or server processes are restarted. TFO also
603 falls back to a regular TCP handshake gracefully.
605 DNS services taking advantage of IP anycast [RFC4786] might need to
606 take additional steps when enabling TFO. From [RFC7413]:
608 Servers behind load balancers that accept connection requests to
609 the same server IP address should use the same key such that they
610 generate identical Fast Open cookies for a particular client IP
611 address. Otherwise, a client may get different cookies across
612 connections; its Fast Open attempts would fall back to the regular
618Dickinson, et al. Standards Track [Page 11]
620RFC 7766 DNS over TCP March 2016
623 When DNS-over-TCP is a transport for DNS private exchange, as in
624 [DNS-over-TLS], the implementor needs to be aware of TFO and to
625 ensure that data requiring protection (e.g. data for a DNS query) is
626 not accidentally transported in the clear. See [DNS-over-TLS] for
62910. Security Considerations
631 Some DNS server operators have expressed concern that wider promotion
632 and use of DNS over TCP will expose them to a higher risk of DoS
633 attacks on TCP (both accidental and deliberate).
635 Although there is a higher risk of some specific attacks against TCP-
636 enabled servers, techniques for the mitigation of DoS attacks at the
637 network level have improved substantially since DNS was first
640 Readers are advised to familiarise themselves with [CPNI-TCP], a
641 security assessment of TCP that details known TCP attacks and
642 countermeasures and that references most of the relevant RFCs on this
645 To mitigate the risk of DoS attacks, DNS servers are advised to
646 engage in TCP connection management. This could include maintaining
647 state on existing connections, reusing existing connections, and
648 controlling request queues to enable fair use. It is likely to be
649 advantageous to provide configurable connection management options,
652 o total number of TCP connections
654 o maximum TCP connections per source IP address or subnet
656 o TCP connection idle timeout
658 o maximum DNS transactions per TCP connection
660 o maximum TCP connection duration
662 No specific values are recommended for these parameters.
664 Operators are advised to familiarise themselves with the
665 configuration and tuning parameters available in the TCP stack of the
666 operating system. However, detailed advice on this is outside the
667 scope of this document.
674Dickinson, et al. Standards Track [Page 12]
676RFC 7766 DNS over TCP March 2016
679 Operators of recursive servers are advised to ensure that they only
680 accept connections from expected clients (for example, by the use of
681 an Access Control List (ACL)) and do not accept them from unknown
682 sources. In the case of UDP traffic, this will help protect against
683 reflection attacks [RFC5358]; and in the case of TCP traffic, it will
684 prevent an unknown client from exhausting the server's limits on the
685 number of concurrent connections.
68911.1. Normative References
691 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
692 DOI 10.17487/RFC0768, August 1980,
693 <http://www.rfc-editor.org/info/rfc768>.
695 [RFC793] Postel, J., "Transmission Control Protocol", STD 7,
696 RFC 793, DOI 10.17487/RFC0793, September 1981,
697 <http://www.rfc-editor.org/info/rfc793>.
699 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
700 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
701 <http://www.rfc-editor.org/info/rfc1034>.
703 [RFC1035] Mockapetris, P., "Domain names - implementation and
704 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
705 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
707 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
708 Application and Support", STD 3, RFC 1123,
709 DOI 10.17487/RFC1123, October 1989,
710 <http://www.rfc-editor.org/info/rfc1123>.
712 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
713 Requirement Levels", BCP 14, RFC 2119,
714 DOI 10.17487/RFC2119, March 1997,
715 <http://www.rfc-editor.org/info/rfc2119>.
717 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
718 Rose, "DNS Security Introduction and Requirements",
719 RFC 4033, DOI 10.17487/RFC4033, March 2005,
720 <http://www.rfc-editor.org/info/rfc4033>.
722 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
723 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
724 December 2006, <http://www.rfc-editor.org/info/rfc4786>.
730Dickinson, et al. Standards Track [Page 13]
732RFC 7766 DNS over TCP March 2016
735 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
736 Security (DNSSEC) Hashed Authenticated Denial of
737 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
738 <http://www.rfc-editor.org/info/rfc5155>.
740 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
741 Nameservers in Reflector Attacks", BCP 140, RFC 5358,
742 DOI 10.17487/RFC5358, October 2008,
743 <http://www.rfc-editor.org/info/rfc5358>.
745 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
746 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
747 <http://www.rfc-editor.org/info/rfc5625>.
749 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation
750 Requirements", RFC 5966, DOI 10.17487/RFC5966, August
751 2010, <http://www.rfc-editor.org/info/rfc5966>.
753 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
754 for DNS (EDNS(0))", STD 75, RFC 6891,
755 DOI 10.17487/RFC6891, April 2013,
756 <http://www.rfc-editor.org/info/rfc6891>.
758 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
759 Protocol (HTTP/1.1): Message Syntax and Routing",
760 RFC 7230, DOI 10.17487/RFC7230, June 2014,
761 <http://www.rfc-editor.org/info/rfc7230>.
763 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
764 Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
765 DOI 10.17487/RFC7540, May 2015,
766 <http://www.rfc-editor.org/info/rfc7540>.
76811.2. Informative References
770 [Connection-Oriented-DNS]
771 Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A.,
772 and N. Somaiya, "Connection-Oriented DNS to Improve
773 Privacy and Security", 2015 IEEE Symposium on Security and
774 Privacy (SP), DOI 10.1109/SP.2015.18,
775 <http://ieeexplore.ieee.org/xpl/
776 articleDetails.jsp?arnumber=7163025>.
779 CPNI, "Security Assessment of the Transmission Control
780 Protocol (TCP)", 2009, <http://www.gont.com.ar/papers/
781 tn-03-09-security-assessment-TCP.pdf>.
786Dickinson, et al. Standards Track [Page 14]
788RFC 7766 DNS over TCP March 2016
792 Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
793 and P. Hoffman, "Specification for DNS over TLS", Work in
794 Progress, draft-ietf-dprive-dns-over-tls-06, February
798 Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
799 edns-tcp-keepalive EDNS0 Option", Work in Progress,
800 draft-ietf-dnsop-edns-tcp-keepalive-03, September 2015.
802 [fragmentation-considered-poisonous]
803 Herzberg, A. and H. Shulman, "Fragmentation Considered
804 Poisonous", May 2012, <http://arxiv.org/abs/1205.4011>.
806 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
807 for Application Designers", BCP 145, RFC 5405,
808 DOI 10.17487/RFC5405, November 2008,
809 <http://www.rfc-editor.org/info/rfc5405>.
811 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
812 "TCP Extensions for Multipath Operation with Multiple
813 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
814 <http://www.rfc-editor.org/info/rfc6824>.
816 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
817 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
818 <http://www.rfc-editor.org/info/rfc7413>.
820 [RRL1] Vixie, P. and V. Schryver, "DNS Response Rate Limiting
821 (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012,
822 <https://ftp.isc.org/isc/pubs/tn/isc-tn-2012-1.txt>.
824 [RRL2] ISC Support, "Using the Response Rate Limiting Feature in
825 BIND 9.10", ISC Knowledge Base AA-00994, June 2013,
826 <https://kb.isc.org/article/AA-00994/>.
842Dickinson, et al. Standards Track [Page 15]
844RFC 7766 DNS over TCP March 2016
847Appendix A. Summary of Advantages and Disadvantages to Using TCP for
850 The TCP handshake generally prevents address spoofing and, therefore,
851 the reflection/amplification attacks that plague UDP.
853 IP fragmentation is less of a problem for TCP than it is for UDP.
854 TCP stacks generally implement Path MTU Discovery so they can avoid
855 IP fragmentation of TCP segments. UDP, on the other hand, does not
856 provide reassembly; this means datagrams that exceed the path MTU
857 size must experience fragmentation [RFC5405]. Middleboxes are known
858 to block IP fragments, leading to timeouts and forcing client
859 implementations to "hunt" for EDNS0 reply size values supported by
860 the network path. Additionally, fragmentation may lead to cache
861 poisoning [fragmentation-considered-poisonous].
863 TCP setup costs an additional RTT compared to UDP queries. Setup
864 costs can be amortised by reusing connections, pipelining queries,
865 and enabling TCP Fast Open.
867 TCP imposes additional state-keeping requirements on clients and
868 servers. The use of TCP Fast Open reduces the cost of closing and
869 reopening TCP connections.
871 Long-lived TCP connections to anycast servers might be disrupted due
872 to routing changes. Clients utilizing TCP for DNS need to always be
873 prepared to re-establish connections or otherwise retry outstanding
874 queries. It might also be possible for Multipath TCP [RFC6824] to
875 allow a server to hand a connection over from the anycast address to
878 There are many "middleboxes" in use today that interfere with TCP
879 over port 53 [RFC5625]. This document does not propose any
880 solutions, other than to make it absolutely clear that TCP is a valid
881 transport for DNS and support for it is a requirement for all
884 A more in-depth discussion of connection-oriented DNS can be found
885 elsewhere [Connection-Oriented-DNS].
887Appendix B. Changes to RFC 5966
889 This document obsoletes [RFC5966] and differs from it in several
890 respects. An overview of the most substantial changes/updates that
891 implementors should take note of is given below.
893 1. A Terminology section (Section 3) is added defining several new
898Dickinson, et al. Standards Track [Page 16]
900RFC 7766 DNS over TCP March 2016
903 2. Paragraph 3 of Section 5 puts TCP on a more equal footing with
904 UDP than RFC 5966 does. For example, it states:
906 1. TCP MAY be used before sending any UDP queries.
908 2. TCP ought to be considered a valid alternative transport to
909 UDP, not purely a fallback option.
911 3. Section 6.2.1 adds a new recommendation that TCP connection
912 reuse SHOULD be supported.
914 4. Section 6.2.1.1 adds a new recommendation that DNS clients
915 SHOULD pipeline their queries and DNS servers SHOULD process
916 pipelined queries concurrently.
918 5. Section 6.2.2 adds new recommendations on the number and usage
919 of TCP connections for client/server interactions.
921 6. Section 6.2.3 adds a new recommendation that DNS clients SHOULD
922 close idle sessions unless using a signalling mechanism.
924 7. Section 7 clarifies that servers are RECOMMENDED to prepare TCP
925 responses in parallel and send answers out of order. It also
926 clarifies how TCP queries and responses should be matched by
929 8. Section 8 adds a new recommendation about how DNS clients and
930 servers should handle the 2-byte message length field for TCP
933 9. Section 9 adds a non-normative discussion of the use of TCP Fast
936 10. Section 10 adds new advice regarding DoS mitigation techniques.
940 The authors would like to thank Francis Dupont and Paul Vixie for
941 their detailed reviews, as well as Andrew Sullivan, Tony Finch,
942 Stephane Bortzmeyer, Joe Abley, Tatuya Jinmei, and the many others
943 who contributed to the mailing list discussion. Also, the authors
944 thank Liang Zhu, Zi Hu, and John Heidemann for extensive DNS-over-TCP
945 discussions and code, and Lucie Guiraud and Danny McPherson for
946 reviewing early draft versions of this document. We would also like
947 to thank all those who contributed to RFC 5966.
954Dickinson, et al. Standards Track [Page 17]
956RFC 7766 DNS over TCP March 2016
962 Sinodun Internet Technologies
968 Email: jad@sinodun.com
969 URI: http://sinodun.com
973 Sinodun Internet Technologies
979 Email: sara@sinodun.com
980 URI: http://sinodun.com
984 Internet Systems Consortium, Inc
986 Redwood City, CA 94063
989 Phone: +1 650 423 1200
991 URI: http://www.isc.org
1000 Phone: +1 301 728 7198
1001 Email: allison.mankin@gmail.com
1010Dickinson, et al. Standards Track [Page 18]
1012RFC 7766 DNS over TCP March 2016
1021 Phone: +1 703 948 3200
1022 Email: dwessels@verisign.com
1066Dickinson, et al. Standards Track [Page 19]