5Internet Engineering Task Force (IETF) J. Kristoff
6Request for Comments: 9210 Dataplane.org
8Updates: 1123, 1536 Verisign
9Category: Best Current Practice March 2022
13 DNS Transport over TCP - Operational Requirements
17 This document updates RFCs 1123 and 1536. This document requires the
18 operational practice of permitting DNS messages to be carried over
19 TCP on the Internet as a Best Current Practice. This operational
20 requirement is aligned with the implementation requirements in RFC
21 7766. The use of TCP includes both DNS over unencrypted TCP as well
22 as over an encrypted TLS session. The document also considers the
23 consequences of this form of DNS communication and the potential
24 operational issues that can arise when this Best Current Practice is
29 This memo documents an Internet Best Current Practice.
31 This document is a product of the Internet Engineering Task Force
32 (IETF). It represents the consensus of the IETF community. It has
33 received public review and has been approved for publication by the
34 Internet Engineering Steering Group (IESG). Further information on
35 BCPs is available in Section 2 of RFC 7841.
37 Information about the current status of this document, any errata,
38 and how to provide feedback on it may be obtained at
39 https://www.rfc-editor.org/info/rfc9210.
43 Copyright (c) 2022 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (https://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Revised BSD License text as described in Section 4.e of the
53 Trust Legal Provisions and are provided without warranty as described
54 in the Revised BSD License.
59 1.1. Requirements Language
60 2. History of DNS over TCP
61 2.1. Uneven Transport Usage and Preference
62 2.2. Waiting for Large Messages and Reliability
64 2.4. Fragmentation and Truncation
65 2.5. "Only Zone Transfers Use TCP"
66 2.6. Reuse, Pipelining, and Out-of-Order Processing
67 3. DNS-over-TCP Requirements
68 4. Network and System Considerations
69 4.1. Connection Establishment and Admission
70 4.2. Connection Management
71 4.3. Connection Termination
73 4.5. Defaults and Recommended Limits
74 5. DNS-over-TCP Filtering Risks
75 5.1. Truncation, Retries, and Timeouts
76 5.2. DNS Root Zone KSK Rollover
77 6. Logging and Monitoring
78 7. IANA Considerations
79 8. Security Considerations
80 9. Privacy Considerations
82 10.1. Normative References
83 10.2. Informative References
84 Appendix A. RFCs Related to DNS Transport over TCP
85 A.1. RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
86 A.2. RFC 1536 - Common DNS Implementation Errors and Suggested
88 A.3. RFC 1995 - Incremental Zone Transfer in DNS
89 A.4. RFC 1996 - A Mechanism for Prompt Notification of Zone
91 A.5. RFC 2181 - Clarifications to the DNS Specification
92 A.6. RFC 2694 - DNS extensions to Network Address Translators
94 A.7. RFC 3225 - Indicating Resolver Support of DNSSEC
95 A.8. RFC 3226 - DNSSEC and IPv6 A6 aware server/resolver message
97 A.9. RFC 4472 - Operational Considerations and Issues with IPv6
99 A.10. RFC 5452 - Measures for Making DNS More Resilient against
101 A.11. RFC 5507 - Design Choices When Expanding the DNS
102 A.12. RFC 5625 - DNS Proxy Implementation Guidelines
103 A.13. RFC 5936 - DNS Zone Transfer Protocol (AXFR)
104 A.14. RFC 7534 - AS112 Nameserver Operations
105 A.15. RFC 6762 - Multicast DNS
106 A.16. RFC 6891 - Extension Mechanisms for DNS (EDNS(0))
107 A.17. IAB RFC 6950 - Architectural Considerations on Application
109 A.18. RFC 7477 - Child-to-Parent Synchronization in DNS
110 A.19. RFC 7720 - DNS Root Name Service Protocol and Deployment
112 A.20. RFC 7766 - DNS Transport over TCP - Implementation
114 A.21. RFC 7828 - The edns-tcp-keepalive EDNS(0) Option
115 A.22. RFC 7858 - Specification for DNS over Transport Layer
117 A.23. RFC 7873 - Domain Name System (DNS) Cookies
118 A.24. RFC 7901 - CHAIN Query Requests in DNS
119 A.25. RFC 8027 - DNSSEC Roadblock Avoidance
120 A.26. RFC 8094 - DNS over Datagram Transport Layer Security
122 A.27. RFC 8162 - Using Secure DNS to Associate Certificates with
123 Domain Names for S/MIME
124 A.28. RFC 8324 - DNS Privacy, Authorization, Special Uses,
125 Encoding, Characters, Matching, and Root Structure: Time for
127 A.29. RFC 8467 - Padding Policies for Extension Mechanisms for
129 A.30. RFC 8482 - Providing Minimal-Sized Responses to DNS Queries
131 A.31. RFC 8483 - Yeti DNS Testbed
132 A.32. RFC 8484 - DNS Queries over HTTPS (DoH)
133 A.33. RFC 8490 - DNS Stateful Operations
134 A.34. RFC 8501 - Reverse DNS in IPv6 for Internet Service
136 A.35. RFC 8806 - Running a Root Server Local to a Resolver
137 A.36. RFC 8906 - A Common Operational Problem in DNS Servers:
138 Failure to Communicate
139 A.37. RFC 8932 - Recommendations for DNS Privacy Service
141 A.38. RFC 8945 - Secret Key Transaction Authentication for DNS
148 DNS messages are delivered using UDP or TCP communications. While
149 most DNS transactions are carried over UDP, some operators have been
150 led to believe that any DNS-over-TCP traffic is unwanted or
151 unnecessary for general DNS operation. When DNS over TCP has been
152 restricted, a variety of communication failures and debugging
153 challenges often arise. As DNS and new naming system features have
154 evolved, TCP as a transport has become increasingly important for the
155 correct and safe operation of an Internet DNS. Reflecting modern
156 usage, the DNS standards declare that support for TCP is a required
157 part of the DNS implementation specifications [RFC7766]. This
158 document is the equivalent of formal requirements for the operational
159 community, encouraging system administrators, network engineers, and
160 security staff to ensure DNS-over-TCP communications support is on
161 par with DNS-over-UDP communications. It updates [RFC1123],
162 Section 6.1.3.2 to clarify that all DNS resolvers and recursive
163 servers MUST support and service both TCP and UDP queries and also
164 updates [RFC1536] to remove the misconception that TCP is only useful
1671.1. Requirements Language
169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
171 "OPTIONAL" in this document are to be interpreted as described in
172 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
173 capitals, as shown here.
1752. History of DNS over TCP
177 The curious state of disagreement between operational best practices
178 and guidance for DNS transport protocols derives from conflicting
179 messages operators have received from other operators, implementors,
180 and even the IETF. Sometimes these mixed signals have been explicit;
181 on other occasions, conflicting messages have been implicit. This
182 section presents an interpretation of the storied and conflicting
183 history that led to this document. This section is included for
184 informational purposes only.
1862.1. Uneven Transport Usage and Preference
188 In the original suite of DNS specifications, [RFC1034] and [RFC1035]
189 clearly specify that DNS messages could be carried in either UDP or
190 TCP, but they also state that there is a preference for UDP as the
191 best transport for queries in the general case. As stated in
194 | While virtual circuits can be used for any DNS activity, datagrams
195 | are preferred for queries due to their lower overhead and better
198 Another early, important, and influential document, [RFC1123], marks
199 the preference for a transport protocol more explicitly:
201 | DNS resolvers and recursive servers MUST support UDP, and SHOULD
202 | support TCP, for sending (non-zone-transfer) queries.
204 and it further stipulates that:
206 | A name server MAY limit the resources it devotes to TCP queries,
207 | but it SHOULD NOT refuse to service a TCP query just because it
208 | would have succeeded with UDP.
210 Culminating in [RFC1536], DNS over TCP came to be associated
211 primarily with the zone transfer mechanism, while most DNS queries
212 and responses were seen as the dominion of UDP.
2142.2. Waiting for Large Messages and Reliability
216 In the original specifications, the maximum DNS-over-UDP message size
217 was enshrined at 512 bytes. However, even while [RFC1123] prefers
218 UDP for non-zone transfer queries, it foresaw that DNS over TCP would
219 become more popular in the future to overcome this limitation:
221 | [...] it is also clear that some new DNS record types defined in
222 | the future will contain information exceeding the 512 byte limit
223 | that applies to UDP, and hence will require TCP.
225 At least two new, widely anticipated developments were set to elevate
226 the need for DNS-over-TCP transactions. The first was dynamic
227 updates defined in [RFC2136], and the second was the set of
228 extensions collectively known as "DNSSEC", whose operational
229 considerations were originally given in [RFC2541] (note that
230 [RFC2541] has been obsoleted by [RFC6781]). The former suggests that
232 | ...requestors who require an accurate response code must use TCP.
234 while the latter warns that
236 | ... larger keys increase the size of the KEY and SIG RRs. This
237 | increases the chance of DNS UDP packet overflow and the possible
238 | necessity for using higher overhead TCP in responses.
240 Yet, defying some expectations, DNS over TCP remained little used in
241 real traffic across the Internet in the late 1990s. Dynamic updates
242 saw little deployment between autonomous networks. Around the time
243 DNSSEC was first defined, another new feature helped solidify UDP
244 transport dominance for message transactions.
248 In 1999, the IETF published the Extension Mechanisms for DNS
249 (EDNS(0)) in [RFC2671] (which was obsoleted by [RFC6891] in 2013).
250 That document standardized a way for communicating DNS nodes to
251 perform rudimentary capabilities negotiation. One such capability
252 written into the base specification and present in every EDNS(0)-
253 compatible message is the value of the maximum UDP payload size the
254 sender can support. This unsigned 16-bit field specifies, in bytes,
255 the maximum (possibly fragmented) DNS message size a node is capable
256 of receiving over UDP. In practice, typical values are a subset of
257 the 512- to 4096-byte range. EDNS(0) became widely deployed over the
258 next several years, and numerous surveys (see [CASTRO2010] and
259 [NETALYZR]) have shown that many systems support larger UDP MTUs with
262 The natural effect of EDNS(0) deployment meant DNS messages larger
263 than 512 bytes would be less reliant on TCP than they might otherwise
264 have been. While a non-negligible population of DNS systems lacked
265 EDNS(0) or fell back to TCP when necessary, DNS clients still
266 strongly prefer UDP to TCP. For example, as of 2014, DNS-over-TCP
267 transactions remained a very small fraction of overall DNS traffic
268 received by root name servers [VERISIGN].
2702.4. Fragmentation and Truncation
272 Although EDNS(0) provides a way for endpoints to signal support for
273 DNS messages exceeding 512 bytes, the realities of a diverse and
274 inconsistently deployed Internet may result in some large messages
275 being unable to reach their destination. Any IP datagram whose size
276 exceeds the MTU of a link it transits will be fragmented and then
277 reassembled by the receiving host. Unfortunately, it is not uncommon
278 for middleboxes and firewalls to block IP fragments. If one or more
279 fragments do not arrive, the application does not receive the
280 message, and the request times out.
282 For IPv4-connected hosts, the MTU is often an Ethernet payload size
283 of 1500 bytes. This means that the largest unfragmented UDP DNS
284 message that can be sent over IPv4 is likely 1472 bytes, although
285 tunnel encapsulation may reduce that maximum message size in some
288 For IPv6, the situation is a little more complicated. First, IPv6
289 headers are 40 bytes (versus 20 without options in IPv4). Second,
290 approximately one-third of DNS recursive resolvers use the minimum
291 MTU of 1280 bytes [APNIC]. Third, fragmentation in IPv6 can only be
292 done by the host originating the datagram. The need to fragment is
293 conveyed in an ICMPv6 "Packet Too Big" message. The originating host
294 indicates a fragmented datagram with IPv6 extension headers.
295 Unfortunately, it is quite common for both ICMPv6 and IPv6 extension
296 headers to be blocked by middleboxes. According to [HUSTON], some
297 35% of IPv6-capable recursive resolvers were unable to receive a
298 fragmented IPv6 packet. When the originating host receives a signal
299 that fragmentation is required, it is expected to populate its path
300 MTU cache for that destination. The application will then retry the
301 query after a timeout since the host does not generally retain copies
302 of messages sent over UDP for potential retransmission.
304 The practical consequence of all this is that DNS requestors must be
305 prepared to retry queries with different EDNS(0) maximum message size
306 values. Administrators of [BIND] are likely to be familiar with
307 seeing the following message in their system logs: "success resolving
308 ... after reducing the advertised EDNS(0) UDP packet size to 512
311 Often, reducing the EDNS(0) UDP packet size leads to a successful
312 response. That is, the necessary data fits within the smaller
313 message size. However, when the data does not fit, the server sets
314 the truncated flag in its response, indicating the client should
315 retry over TCP to receive the whole response. This is undesirable
316 from the client's point of view because it adds more latency and is
317 potentially undesirable from the server's point of view due to the
318 increased resource requirements of TCP.
320 Note that a receiver is unable to differentiate between packets lost
321 due to congestion and packets (fragments) intentionally dropped by
322 firewalls or middleboxes. Over network paths with non-trivial
323 amounts of packet loss, larger, fragmented DNS responses are more
324 likely to never arrive and time out compared to smaller, unfragmented
325 responses. Clients might be misled into retrying queries with
326 different EDNS(0) UDP packet size values for the wrong reason.
328 The issues around fragmentation, truncation, and TCP are driving
329 certain implementation and policy decisions in the DNS. Notably,
330 Cloudflare implemented a technique that minimizes the number of
331 DNSSEC denial-of-existence records (for its online signing platform)
332 [CLOUDFLARE] and uses an Elliptic Curve Digital Signature Algorithm
333 (ECDSA) such that its signed responses fit easily in 512 bytes. The
334 Key Signing Key (KSK) Rollover Design Team [DESIGNTEAM] spent a lot
335 of time thinking and worrying about response sizes. There is growing
336 sentiment in the DNSSEC community that RSA key sizes beyond 2048 bits
337 are impractical and that critical infrastructure zones should
338 transition to elliptic curve algorithms to keep response sizes
341 More recently, renewed security concerns about fragmented DNS
342 messages (see [AVOID_FRAGS] and [FRAG_POISON]) are leading
343 implementors to consider smaller responses and lower default EDNS(0)
344 UDP payload size values for both queriers and responders
3472.5. "Only Zone Transfers Use TCP"
349 Today, the majority of the DNS community expects, or at least has a
350 desire, to see DNS-over-TCP transactions occur without interference
351 [FLAGDAY2020]. However, there has also been a long-held belief by
352 some operators, particularly for security-related reasons, that DNS-
353 over-TCP services should be purposely limited or not provided at all
354 [CHES94] [DJBDNS]. A popular meme is that DNS over TCP is only ever
355 used for zone transfers and is generally unnecessary otherwise, with
356 filtering all DNS-over-TCP traffic even described as a best practice.
358 The position on restricting DNS over TCP had some justification given
359 that historical implementations of DNS name servers provided very
360 little in the way of TCP connection management (for example, see
361 Section 6.1.2 of [RFC7766] for more details). However, modern
362 standards and implementations are nearing parity with the more
363 sophisticated TCP management techniques employed by, for example,
364 HTTP(S) servers and load balancers.
3662.6. Reuse, Pipelining, and Out-of-Order Processing
368 The idea that a TCP connection can support multiple transactions goes
369 back as far as [RFC0883], which states: "Multiple messages may be
370 sent over a virtual circuit." Although [RFC1035], which updates the
371 former, omits this particular detail, it has been generally accepted
372 that a TCP connection can be used for more than one query and
375 [RFC5966] clarifies that servers are not required to preserve the
376 order of queries and responses over any transport. [RFC7766], which
377 updates the former, further encourages query pipelining over TCP to
378 achieve performance on par with UDP. A server that sends out-of-
379 order responses to pipelined queries avoids head-of-line blocking
380 when the response for a later query is ready before the response to
383 However, TCP can potentially suffer from a different head-of-line
384 blocking problem due to packet loss. Since TCP itself enforces
385 ordering, a single lost segment delays delivery of data in any
386 following segments until the lost segment is retransmitted and
387 successfully received.
3893. DNS-over-TCP Requirements
391 An average increase in DNS message size (e.g., due to DNSSEC), the
392 continued development of new DNS features (Appendix A), and a denial-
393 of-service mitigation technique (Section 8) all show that DNS-over-
394 TCP transactions are as important to the correct and safe operation
395 of the Internet DNS as ever, if not more so. Furthermore, there has
396 been research that argues connection-oriented DNS transactions may
397 provide security and privacy advantages over UDP transport [TDNS].
398 In fact, the standard for DNS over TLS [RFC7858] is just this sort of
399 specification. Therefore, this document makes explicit that it is
400 undesirable for network operators to artificially inhibit DNS-over-
403 Section 6.1.3.2 of [RFC1123] is updated as follows:
407 | DNS resolvers and recursive servers MUST support UDP, and SHOULD
408 | support TCP, for sending (non-zone-transfer) queries.
412 | All DNS resolvers and servers MUST support and service both UDP
417 * DNS servers (including forwarders) MUST support and service TCP
418 for receiving queries so that clients can reliably receive
419 responses that are larger than what either side considers too
422 * DNS clients MUST support TCP for sending queries so that they can
423 retry truncated UDP responses as necessary.
425 Furthermore, the requirement in Section 6.1.3.2 of [RFC1123] around
426 limiting the resources a server devotes to queries is hereby updated:
430 | A name server MAY limit the resources it devotes to TCP queries,
431 | but it SHOULD NOT refuse to service a TCP query just because it
432 | would have succeeded with UDP.
436 | A name server MAY limit the resources it devotes to queries, but
437 | it MUST NOT refuse to service a query just because it would have
438 | succeeded with another transport protocol.
440 Lastly, Section 1 of [RFC1536] is updated to eliminate the
441 misconception that TCP is only useful for zone transfers:
445 | DNS implements the classic request-response scheme of client-
446 | server interaction. UDP is, therefore, the chosen protocol for
447 | communication though TCP is used for zone transfers.
451 | DNS implements the classic request-response scheme of client-
452 | server interaction.
454 The filtering of DNS over TCP is harmful in the general case. DNS
455 resolver and server operators MUST support and provide DNS service
456 over both UDP and TCP transports. Likewise, network operators MUST
457 allow DNS service over both UDP and TCP transports. It is
458 acknowledged that DNS-over-TCP service can pose operational
459 challenges that are not present when running DNS over UDP alone, and
460 vice versa. However, the potential damage incurred by prohibiting
461 DNS-over-TCP service is more detrimental to the continued utility and
462 success of the DNS than when its usage is allowed.
4644. Network and System Considerations
466 This section describes measures that systems and applications can
467 take to optimize performance over TCP and to protect themselves from
468 TCP-based resource exhaustion and attacks.
4704.1. Connection Establishment and Admission
472 Resolvers and other DNS clients should be aware that some servers
473 might not be reachable over TCP. For this reason, clients MAY track
474 and limit the number of TCP connections and connection attempts to a
475 single server. Reachability problems can be caused by network
476 elements close to the server, close to the client, or anywhere along
477 the path between them. Mobile clients that cache connection failures
478 MAY do so on a per-network basis or MAY clear such a cache upon
481 Additionally, DNS clients MAY enforce a short timeout on
482 unestablished connections rather than rely on the host operating
483 system's TCP connection timeout, which is often around 60-120 seconds
484 (i.e., due to an initial retransmission timeout of 1 second, the
485 exponential back-off rules of [RFC6298], and a limit of six retries
486 as is the default in Linux).
488 The SYN flooding attack is a denial-of-service method affecting hosts
489 that run TCP server processes [RFC4987]. This attack can be very
490 effective if not mitigated. One of the most effective mitigation
491 techniques is SYN cookies, described in Section 3.6 of [RFC4987],
492 which allows the server to avoid allocating any state until the
493 successful completion of the three-way handshake.
495 Services not intended for use by the public Internet, such as most
496 recursive name servers, SHOULD be protected with access controls.
497 Ideally, these controls are placed in the network, well before any
498 unwanted TCP packets can reach the DNS server host or application.
499 If this is not possible, the controls can be placed in the
500 application itself. In some situations (e.g., attacks), it may be
501 necessary to deploy access controls for DNS services that should
502 otherwise be globally reachable. See also [RFC5358].
504 The FreeBSD and NetBSD operating systems have an "accept filter"
505 feature ([accept_filter]) that postpones delivery of TCP connections
506 to applications until a complete, valid request has been received.
507 The dns_accf(9) filter ensures that a valid DNS message is received.
508 If not, the bogus connection never reaches the application. The
509 Linux TCP_DEFER_ACCEPT feature, while more limited in scope, can
510 provide some of the same benefits as the BSD accept filter feature.
511 These features are implemented as low-level socket options and are
512 not activated automatically. If applications wish to use these
513 features, they need to make specific calls to set the right options,
514 and administrators may also need to configure the applications to
515 appropriately use the features.
517 Per [RFC7766], applications and administrators are advised to
518 remember that TCP MAY be used before sending any UDP queries.
519 Networks and applications MUST NOT be configured to refuse TCP
520 queries that were not preceded by a UDP query.
522 TCP Fast Open (TFO) [RFC7413] allows TCP clients to shorten the
523 handshake for subsequent connections to the same server. TFO saves
524 one round-trip time in the connection setup. DNS servers SHOULD
525 enable TFO when possible. Furthermore, DNS servers clustered behind
526 a single service address (e.g., anycast or load balancing) SHOULD
527 either use the same TFO server key on all instances or disable TFO
528 for all members of the cluster.
530 DNS clients MAY also enable TFO. At the time of this writing, it is
531 not implemented or is disabled by default on some operating systems.
532 [WIKIPEDIA_TFO] describes applications and operating systems that
5354.2. Connection Management
537 Since host memory for TCP state is a finite resource, DNS clients and
538 servers SHOULD actively manage their connections. Applications that
539 do not actively manage their connections can encounter resource
540 exhaustion leading to denial of service. For DNS, as in other
541 protocols, there is a trade-off between keeping connections open for
542 potential future use and the need to free up resources for new
543 connections that will arrive.
545 Operators of DNS server software SHOULD be aware that operating
546 system and application vendors MAY impose a limit on the total number
547 of established connections. These limits may be designed to protect
548 against DDoS attacks or performance degradation. Operators SHOULD
549 understand how to increase these limits if necessary and the
550 consequences of doing so. Limits imposed by the application SHOULD
551 be lower than limits imposed by the operating system so that the
552 application can apply its own policy to connection management, such
553 as closing the oldest idle connections first.
555 DNS server software MAY provide a configurable limit on the number of
556 established connections per source IP address or subnet. This can be
557 used to ensure that a single or small set of users cannot consume all
558 TCP resources and deny service to other users. Note, however, that
559 if this limit is enabled, it possibly limits client performance while
560 leaving some TCP resources unutilized. Operators SHOULD be aware of
561 these trade-offs and ensure this limit, if configured, is set
562 appropriately based on the number and diversity of their users and
563 whether users connect from unique IP addresses or through a shared
564 Network Address Translator (NAT) [RFC3022].
566 DNS server software SHOULD provide a configurable timeout for idle
567 TCP connections. This can be used to free up resources for new
568 connections and to ensure that idle connections are eventually
569 closed. At the same time, it possibly limits client performance
570 while leaving some TCP resources unutilized. For very busy name
571 servers, this might be set to a low value, such as a few seconds.
572 For less busy servers, it might be set to a higher value, such as
573 tens of seconds. DNS clients and servers SHOULD signal their timeout
574 values using the edns-tcp-keepalive EDNS(0) option [RFC7828].
576 DNS server software MAY provide a configurable limit on the number of
577 transactions per TCP connection. This can help protect against
578 unfair connection use (e.g., not releasing connection slots to other
579 clients) and network evasion attacks.
581 Similarly, DNS server software MAY provide a configurable limit on
582 the total duration of a TCP connection. This can help protect
583 against unfair connection use, slow read attacks, and network evasion
586 Since clients may not be aware of server-imposed limits, clients
587 utilizing TCP for DNS need to always be prepared to re-establish
588 connections or otherwise retry outstanding queries.
5904.3. Connection Termination
592 The TCP peer that initiates a connection close retains the socket in
593 the TIME_WAIT state for some amount of time, possibly a few minutes.
594 It is generally preferable for clients to initiate the close of a TCP
595 connection so that busy servers do not accumulate many sockets in the
596 TIME_WAIT state, which can cause performance problems or even denial
597 of service. The edns-tcp-keepalive EDNS(0) option [RFC7828] can be
598 used to encourage clients to close connections.
600 On systems where large numbers of sockets in TIME_WAIT are observed
601 (as either a client or a server) and are affecting an application's
602 performance, it may be tempting to tune local TCP parameters. For
603 example, the Linux kernel has a "sysctl" parameter named
604 net.ipv4.tcp_tw_reuse, which allows connections in the TIME_WAIT
605 state to be reused in specific circumstances. Note, however, that
606 this affects only outgoing (client) connections and has no impact on
607 servers. In most cases, it is NOT RECOMMENDED to change parameters
608 related to the TIME_WAIT state. It should only be done by those with
609 detailed knowledge of both TCP and the affected application.
613 DNS messages may be sent over TLS to provide privacy between stubs
614 and recursive resolvers. [RFC7858] is a Standards Track document
615 describing how this works. Although DNS over TLS utilizes TCP port
616 853 instead of port 53, this document applies equally well to DNS
617 over TLS. Note, however, that DNS over TLS is only defined between
618 stubs and recursives at the time of this writing.
620 The use of TLS places even stronger operational burdens on DNS
621 clients and servers. Cryptographic functions for authentication and
622 encryption require additional processing. Unoptimized connection
623 setup with TLS 1.3 [RFC8446] takes one additional round trip compared
624 to TCP. Connection setup times can be reduced with TCP Fast Open and
625 TLS False Start [RFC7918] for TLS 1.2. TLS 1.3 session resumption
626 does not reduce round-trip latency because no application profile for
627 use of TLS 0-RTT data with DNS has been published at the time of this
628 writing. However, TLS session resumption can reduce the number of
629 cryptographic operations, and in TLS 1.2, session resumption does
630 reduce the number of additional round trips from two to one.
6324.5. Defaults and Recommended Limits
634 A survey of features and defaults was conducted for popular open-
635 source DNS server implementations at the time of writing. This
636 section documents those defaults and makes recommendations for
637 configurable limits that can be used in the absence of any other
638 information. Any recommended values in this document are only
639 intended as a starting point for administrators that are unsure of
640 what sorts of limits might be reasonable. Operators SHOULD use
641 application-specific monitoring, system logs, and system monitoring
642 tools to gauge whether their service is operating within or exceeding
643 these limits and adjust accordingly.
645 Most open-source DNS server implementations provide a configurable
646 limit on the total number of established connections. Default values
647 range from 20 to 150. In most cases, where the majority of queries
648 take place over UDP, 150 is a reasonable limit. For services or
649 environments where most queries take place over TCP or TLS, 5000 is a
650 more appropriate limit.
652 Only some open-source implementations provide a way to limit the
653 number of connections per source IP address or subnet, but the
654 default is to have no limit. For environments or situations where it
655 may be necessary to enable this limit, 25 connections per source IP
656 address is a reasonable starting point. The limit should be
657 increased when aggregated by subnet or for services where most
658 queries take place over TCP or TLS.
660 Most open-source implementations provide a configurable idle timeout
661 on connections. Default values range from 2 to 30 seconds. In most
662 cases, 10 seconds is a reasonable default for this limit. Longer
663 timeouts improve connection reuse, but busy servers may need to use a
666 Only some open-source implementations provide a way to limit the
667 number of transactions per connection, but the default is to have no
668 limit. This document does not offer advice on particular values for
671 Only some open-source implementations provide a way to limit the
672 duration of connection, but the default is to have no limit. This
673 document does not offer advice on particular values for such a limit.
6755. DNS-over-TCP Filtering Risks
677 Networks that filter DNS over TCP risk losing access to significant
678 or important pieces of the DNS namespace. For a variety of reasons,
679 a DNS answer may require a DNS-over-TCP query. This may include
680 large message sizes, lack of EDNS(0) support, or DDoS mitigation
681 techniques (including Response Rate Limiting [RRL]); additionally,
682 perhaps some future capability that is as yet unforeseen will also
683 demand TCP transport.
685 For example, [RFC7901] describes a latency-avoiding technique that
686 sends extra data in DNS responses. This makes responses larger and
687 potentially increases the effectiveness of DDoS reflection attacks.
688 The specification mandates the use of TCP or DNS cookies [RFC7873].
690 Even if any or all particular answers have consistently been returned
691 successfully with UDP in the past, this continued behavior cannot be
692 guaranteed when DNS messages are exchanged between autonomous
693 systems. Therefore, filtering of DNS over TCP is considered harmful
694 and contrary to the safe and successful operation of the Internet.
695 This section enumerates some of the known risks at the time of this
696 writing when networks filter DNS over TCP.
6985.1. Truncation, Retries, and Timeouts
700 Networks that filter DNS over TCP may inadvertently cause problems
701 for third-party resolvers as experienced by [TOYAMA]. For example, a
702 resolver receives queries for a moderately popular domain. The
703 resolver forwards the queries to the domain's authoritative name
704 servers, but those servers respond with the TC bit set. The resolver
705 retries over TCP, but the authoritative server blocks DNS over TCP.
706 The pending connections consume resources on the resolver until they
707 time out. If the number and frequency of these truncated-and-then-
708 blocked queries are sufficiently high, the resolver wastes valuable
709 resources on queries that can never be answered. This condition is
710 generally not easily or completely mitigated by the affected DNS
7135.2. DNS Root Zone KSK Rollover
715 The plans for deploying DNSSEC KSK for the root zone highlighted a
716 potential problem in retrieving the root zone key set [LEWIS].
717 During some phases of the KSK rollover process, root zone DNSKEY
718 responses were larger than 1280 bytes, the IPv6 minimum MTU for links
719 carrying IPv6 traffic [RFC8200]. There was some concern that any DNS
720 server unable to receive large DNS messages over UDP, or any DNS
721 message over TCP, would experience disruption while performing DNSSEC
722 validation [KSK_ROLLOVER_ARCHIVES].
724 However, during the year-long postponement of the KSK rollover, there
725 were no reported problems that could be attributed to the 1414 octet
726 DNSKEY response when both the old and new keys were published in the
727 zone. Additionally, there were no reported problems during the two-
728 month period when the old key was published as revoked and the DNSKEY
729 response was 1425 octets in size [ROLL_YOUR_ROOT].
7316. Logging and Monitoring
733 Developers of applications that log or monitor DNS SHOULD NOT ignore
734 TCP due to the perception that it is rarely used or is hard to
735 process. Operators SHOULD ensure that their monitoring and logging
736 applications properly capture DNS messages over TCP. Otherwise,
737 attacks, exfiltration attempts, and normal traffic may go undetected.
739 DNS messages over TCP are in no way guaranteed to arrive in single
740 segments. In fact, a clever attacker might attempt to hide certain
741 messages by forcing them over very small TCP segments. Applications
742 that capture network packets (e.g., with libpcap [libpcap]) SHOULD
743 implement and perform full TCP stream reassembly and analyze the
744 reassembled stream instead of the individual packets. Otherwise,
745 they are vulnerable to network evasion attacks [phrack].
746 Furthermore, such applications need to protect themselves from
747 resource exhaustion attacks by limiting the amount of memory
748 allocated to tracking unacknowledged connection state data. dnscap
749 [dnscap] is an open-source example of a DNS logging program that
750 implements TCP stream reassembly.
752 Developers SHOULD also keep in mind connection reuse, query
753 pipelining, and out-of-order responses when building and testing DNS
754 monitoring applications.
756 As an alternative to packet capture, some DNS server software
757 supports dnstap [dnstap] as an integrated monitoring protocol
758 intended to facilitate wide-scale DNS monitoring.
7607. IANA Considerations
762 This document has no IANA actions.
7648. Security Considerations
766 This document, providing operational requirements, is the companion
767 to the implementation requirements of DNS over TCP provided in
768 [RFC7766]. The security considerations from [RFC7766] still apply.
770 Ironically, returning truncated DNS-over-UDP answers in order to
771 induce a client query to switch to DNS over TCP has become a common
772 response to source-address-spoofed, DNS denial-of-service attacks
773 [RRL]. Historically, operators have been wary of TCP-based attacks,
774 but in recent years, UDP-based flooding attacks have proven to be the
775 most common protocol attack on the DNS. Nevertheless, a high rate of
776 short-lived DNS transactions over TCP may pose challenges. In fact,
777 [DAI21] details a class of IP fragmentation attacks on DNS
778 transactions if the IP Identifier field (16 bits in IPv4 and 32 bits
779 in IPv6) can be predicted and a system is coerced to fragment rather
780 than retransmit messages. While many operators have provided DNS-
781 over-TCP service for many years without duress, past experience is no
782 guarantee of future success.
784 DNS over TCP is similar to many other Internet TCP services. TCP
785 threats and many mitigation strategies have been well documented in a
786 series of documents such as [RFC4953], [RFC4987], [RFC5927], and
789 As mentioned in Section 6, applications that implement TCP stream
790 reassembly need to limit the amount of memory allocated to connection
791 tracking. A failure to do so could lead to a total failure of the
792 logging or monitoring application. Imposition of resource limits
793 creates a trade-off between allowing some stream reassembly to
794 continue and allowing some evasion attacks to succeed.
796 This document recommends that DNS servers enable TFO when possible.
797 [RFC7413] recommends that a pool of servers behind a load balancer
798 with a shared server IP address also share the key used to generate
799 Fast Open cookies to prevent inordinate fallback to the three-way
800 handshake (3WHS). This guidance remains accurate but comes with a
801 caveat: compromise of one server would reveal this group-shared key
802 and allow for attacks involving the other servers in the pool by
803 forging invalid Fast Open cookies.
8059. Privacy Considerations
807 Since DNS over both UDP and TCP uses the same underlying message
808 format, the use of one transport instead of the other does not change
809 the privacy characteristics of the message content (i.e., the name
810 being queried). A number of protocols have recently been developed
811 to provide DNS privacy, including DNS over TLS [RFC7858], DNS over
812 DTLS [RFC8094], DNS over HTTPS [RFC8484], with even more on the way.
814 Because TCP is somewhat more complex than UDP, some characteristics
815 of a TCP conversation may enable DNS client fingerprinting and
816 tracking that is not possible with UDP. For example, the choice of
817 initial sequence numbers, window size, and options might be able to
818 identify a particular TCP implementation or even individual hosts
819 behind shared resources such as NATs.
82310.1. Normative References
825 [RFC1035] Mockapetris, P., "Domain names - implementation and
826 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
827 November 1987, <https://www.rfc-editor.org/info/rfc1035>.
829 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
830 Requirement Levels", BCP 14, RFC 2119,
831 DOI 10.17487/RFC2119, March 1997,
832 <https://www.rfc-editor.org/info/rfc2119>.
834 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
835 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
836 <https://www.rfc-editor.org/info/rfc2181>.
838 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
839 for DNS (EDNS(0))", STD 75, RFC 6891,
840 DOI 10.17487/RFC6891, April 2013,
841 <https://www.rfc-editor.org/info/rfc6891>.
843 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
844 D. Wessels, "DNS Transport over TCP - Implementation
845 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
846 <https://www.rfc-editor.org/info/rfc7766>.
848 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
849 edns-tcp-keepalive EDNS0 Option", RFC 7828,
850 DOI 10.17487/RFC7828, April 2016,
851 <https://www.rfc-editor.org/info/rfc7828>.
853 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
854 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
855 <https://www.rfc-editor.org/info/rfc7873>.
857 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
858 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
859 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
86110.2. Informative References
864 FreeBSD, "FreeBSD accept_filter(9)", June 2000,
865 <https://www.freebsd.org/cgi/man.cgi?query=accept_filter>.
867 [APNIC] Huston, G., "DNS XL", October 2020,
868 <https://labs.apnic.net/?p=1380>.
871 Fujiwara, K. and P. Vixie, "Fragmentation Avoidance in
872 DNS", Work in Progress, Internet-Draft, draft-ietf-dnsop-
873 avoid-fragmentation-06, 23 December 2021,
874 <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
875 avoid-fragmentation-06>.
877 [BIND] Internet Systems Consortium, "BIND 9",
878 <https://www.isc.org/bind/>.
881 Castro, S., Zhang, M., John, W., Wessels, D., and K.
882 claffy, "Understanding and Preparing for DNS Evolution",
883 DOI 10.1007/978-3-642-12365-8_1, April 2010,
884 <https://doi.org/10.1007/978-3-642-12365-8_1>.
886 [CHES94] Cheswick, W. and S. Bellovin, "Firewalls and Internet
887 Security: Repelling the Wily Hacker", First Edition, 1994.
890 Grant, D., "Economical With The Truth: Making DNSSEC
891 Answers Cheap", June 2016,
892 <https://blog.cloudflare.com/black-lies/>.
894 [DAI21] Dai, T., Shulman, H., and M. Waidner, "DNS-over-TCP
895 Considered Vulnerable", DOI 10.1145/3472305.3472884, July
896 2021, <https://doi.org/10.1145/3472305.3472884>.
899 ICANN, "Root Zone KSK Rollover Plan", March 2016,
900 <https://www.iana.org/reports/2016/root-ksk-rollover-
901 design-20160307.pdf>.
903 [DJBDNS] Bernstein, D., "When are TCP queries sent?", November
904 2002, <https://cr.yp.to/djbdns/tcp.html#why>.
906 [dnscap] DNS-OARC, "DNSCAP", February 2014,
907 <https://www.dns-oarc.net/tools/dnscap>.
909 [dnstap] "dnstap", <https://dnstap.info>.
911 [ECDSA] van Rijswijk-Deij, R., Sperotto, A., and A. Pras, "Making
912 the Case for Elliptic Curves in DNSSEC",
913 DOI 10.1145/2831347.2831350, October 2015,
914 <https://dl.acm.org/doi/10.1145/2831347.2831350>.
917 DNS Software and Service Providers, "DNS Flag Day 2020",
918 October 2020, <https://dnsflagday.net/2020/>.
921 Herzberg, A. and H. Shulman, "Fragmentation Considered
922 Poisonous", May 2012,
923 <https://arxiv.org/pdf/1205.4011.pdf>.
925 [HUSTON] Huston, G., "Dealing with IPv6 fragmentation in the DNS",
926 August 2017, <https://blog.apnic.net/2017/08/22/dealing-
927 ipv6-fragmentation-dns/>.
929 [KSK_ROLLOVER_ARCHIVES]
930 ICANN, "KSK Rollover List Archives", January 2019,
931 <https://mm.icann.org/pipermail/ksk-rollover/2019-January/
934 [LEWIS] Lewis, E., "2017 DNSSEC KSK Rollover", RIPE 74, May 2017,
935 <https://ripe74.ripe.net/presentations/25-RIPE74-lewis-
938 [libpcap] The Tcpdump Group, "Tcpdump and Libpcap",
939 <https://www.tcpdump.org>.
941 [NETALYZR] Kreibich, C., Weaver, N., Nechaev, B., and V. Paxson,
942 "Netalyzr: Illuminating The Edge Network",
943 DOI 10.1145/1879141.1879173, November 2010,
944 <https://doi.org/10.1145/1879141.1879173>.
946 [phrack] horizon, "Defeating Sniffers and Intrusion Detection
947 Systems", Phrack Magazine, December 1998,
948 <http://phrack.org/issues/54/10.html>.
950 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
951 DOI 10.17487/RFC0768, August 1980,
952 <https://www.rfc-editor.org/info/rfc768>.
954 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
955 RFC 793, DOI 10.17487/RFC0793, September 1981,
956 <https://www.rfc-editor.org/info/rfc793>.
958 [RFC0883] Mockapetris, P., "Domain names: Implementation
959 specification", RFC 883, DOI 10.17487/RFC0883, November
960 1983, <https://www.rfc-editor.org/info/rfc883>.
962 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
963 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
964 <https://www.rfc-editor.org/info/rfc1034>.
966 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
967 Application and Support", STD 3, RFC 1123,
968 DOI 10.17487/RFC1123, October 1989,
969 <https://www.rfc-editor.org/info/rfc1123>.
971 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
972 Miller, "Common DNS Implementation Errors and Suggested
973 Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993,
974 <https://www.rfc-editor.org/info/rfc1536>.
976 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
977 DOI 10.17487/RFC1995, August 1996,
978 <https://www.rfc-editor.org/info/rfc1995>.
980 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
981 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
982 August 1996, <https://www.rfc-editor.org/info/rfc1996>.
984 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
985 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
986 RFC 2136, DOI 10.17487/RFC2136, April 1997,
987 <https://www.rfc-editor.org/info/rfc2136>.
989 [RFC2541] Eastlake 3rd, D., "DNS Security Operational
990 Considerations", RFC 2541, DOI 10.17487/RFC2541, March
991 1999, <https://www.rfc-editor.org/info/rfc2541>.
993 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
994 RFC 2671, DOI 10.17487/RFC2671, August 1999,
995 <https://www.rfc-editor.org/info/rfc2671>.
997 [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A.
998 Heffernan, "DNS extensions to Network Address Translators
999 (DNS_ALG)", RFC 2694, DOI 10.17487/RFC2694, September
1000 1999, <https://www.rfc-editor.org/info/rfc2694>.
1002 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
1003 Address Translator (Traditional NAT)", RFC 3022,
1004 DOI 10.17487/RFC3022, January 2001,
1005 <https://www.rfc-editor.org/info/rfc3022>.
1007 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
1008 RFC 3225, DOI 10.17487/RFC3225, December 2001,
1009 <https://www.rfc-editor.org/info/rfc3225>.
1011 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
1012 message size requirements", RFC 3226,
1013 DOI 10.17487/RFC3226, December 2001,
1014 <https://www.rfc-editor.org/info/rfc3226>.
1016 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
1017 Considerations and Issues with IPv6 DNS", RFC 4472,
1018 DOI 10.17487/RFC4472, April 2006,
1019 <https://www.rfc-editor.org/info/rfc4472>.
1021 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
1022 RFC 4953, DOI 10.17487/RFC4953, July 2007,
1023 <https://www.rfc-editor.org/info/rfc4953>.
1025 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
1026 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
1027 <https://www.rfc-editor.org/info/rfc4987>.
1029 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
1030 Nameservers in Reflector Attacks", BCP 140, RFC 5358,
1031 DOI 10.17487/RFC5358, October 2008,
1032 <https://www.rfc-editor.org/info/rfc5358>.
1034 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
1035 Resilient against Forged Answers", RFC 5452,
1036 DOI 10.17487/RFC5452, January 2009,
1037 <https://www.rfc-editor.org/info/rfc5452>.
1039 [RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch,
1040 Ed., "Design Choices When Expanding the DNS", RFC 5507,
1041 DOI 10.17487/RFC5507, April 2009,
1042 <https://www.rfc-editor.org/info/rfc5507>.
1044 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
1045 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
1046 <https://www.rfc-editor.org/info/rfc5625>.
1048 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,
1049 DOI 10.17487/RFC5927, July 2010,
1050 <https://www.rfc-editor.org/info/rfc5927>.
1052 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
1053 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
1054 <https://www.rfc-editor.org/info/rfc5936>.
1056 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
1057 Robustness to Blind In-Window Attacks", RFC 5961,
1058 DOI 10.17487/RFC5961, August 2010,
1059 <https://www.rfc-editor.org/info/rfc5961>.
1061 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation
1062 Requirements", RFC 5966, DOI 10.17487/RFC5966, August
1063 2010, <https://www.rfc-editor.org/info/rfc5966>.
1065 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
1066 "Computing TCP's Retransmission Timer", RFC 6298,
1067 DOI 10.17487/RFC6298, June 2011,
1068 <https://www.rfc-editor.org/info/rfc6298>.
1070 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
1071 DOI 10.17487/RFC6762, February 2013,
1072 <https://www.rfc-editor.org/info/rfc6762>.
1074 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
1075 Operational Practices, Version 2", RFC 6781,
1076 DOI 10.17487/RFC6781, December 2012,
1077 <https://www.rfc-editor.org/info/rfc6781>.
1079 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
1080 "Architectural Considerations on Application Features in
1081 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013,
1082 <https://www.rfc-editor.org/info/rfc6950>.
1084 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
1085 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
1086 <https://www.rfc-editor.org/info/rfc7413>.
1088 [RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS",
1089 RFC 7477, DOI 10.17487/RFC7477, March 2015,
1090 <https://www.rfc-editor.org/info/rfc7477>.
1092 [RFC7534] Abley, J. and W. Sotomayor, "AS112 Nameserver Operations",
1093 RFC 7534, DOI 10.17487/RFC7534, May 2015,
1094 <https://www.rfc-editor.org/info/rfc7534>.
1096 [RFC7720] Blanchet, M. and L-J. Liman, "DNS Root Name Service
1097 Protocol and Deployment Requirements", BCP 40, RFC 7720,
1098 DOI 10.17487/RFC7720, December 2015,
1099 <https://www.rfc-editor.org/info/rfc7720>.
1101 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
1102 and P. Hoffman, "Specification for DNS over Transport
1103 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
1104 2016, <https://www.rfc-editor.org/info/rfc7858>.
1106 [RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901,
1107 DOI 10.17487/RFC7901, June 2016,
1108 <https://www.rfc-editor.org/info/rfc7901>.
1110 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport
1111 Layer Security (TLS) False Start", RFC 7918,
1112 DOI 10.17487/RFC7918, August 2016,
1113 <https://www.rfc-editor.org/info/rfc7918>.
1115 [RFC8027] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy,
1116 "DNSSEC Roadblock Avoidance", BCP 207, RFC 8027,
1117 DOI 10.17487/RFC8027, November 2016,
1118 <https://www.rfc-editor.org/info/rfc8027>.
1120 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
1121 Transport Layer Security (DTLS)", RFC 8094,
1122 DOI 10.17487/RFC8094, February 2017,
1123 <https://www.rfc-editor.org/info/rfc8094>.
1125 [RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to
1126 Associate Certificates with Domain Names for S/MIME",
1127 RFC 8162, DOI 10.17487/RFC8162, May 2017,
1128 <https://www.rfc-editor.org/info/rfc8162>.
1130 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
1131 (IPv6) Specification", STD 86, RFC 8200,
1132 DOI 10.17487/RFC8200, July 2017,
1133 <https://www.rfc-editor.org/info/rfc8200>.
1135 [RFC8324] Klensin, J., "DNS Privacy, Authorization, Special Uses,
1136 Encoding, Characters, Matching, and Root Structure: Time
1137 for Another Look?", RFC 8324, DOI 10.17487/RFC8324,
1138 February 2018, <https://www.rfc-editor.org/info/rfc8324>.
1140 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1141 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1142 <https://www.rfc-editor.org/info/rfc8446>.
1144 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
1145 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
1146 October 2018, <https://www.rfc-editor.org/info/rfc8467>.
1148 [RFC8482] Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt,
1149 "Providing Minimal-Sized Responses to DNS Queries That
1150 Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January
1151 2019, <https://www.rfc-editor.org/info/rfc8482>.
1153 [RFC8483] Song, L., Ed., Liu, D., Vixie, P., Kato, A., and S. Kerr,
1154 "Yeti DNS Testbed", RFC 8483, DOI 10.17487/RFC8483,
1155 October 2018, <https://www.rfc-editor.org/info/rfc8483>.
1157 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
1158 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
1159 <https://www.rfc-editor.org/info/rfc8484>.
1161 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
1162 Lemon, T., and T. Pusateri, "DNS Stateful Operations",
1163 RFC 8490, DOI 10.17487/RFC8490, March 2019,
1164 <https://www.rfc-editor.org/info/rfc8490>.
1166 [RFC8501] Howard, L., "Reverse DNS in IPv6 for Internet Service
1167 Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018,
1168 <https://www.rfc-editor.org/info/rfc8501>.
1170 [RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to
1171 a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
1172 <https://www.rfc-editor.org/info/rfc8806>.
1174 [RFC8906] Andrews, M. and R. Bellis, "A Common Operational Problem
1175 in DNS Servers: Failure to Communicate", BCP 231,
1176 RFC 8906, DOI 10.17487/RFC8906, September 2020,
1177 <https://www.rfc-editor.org/info/rfc8906>.
1179 [RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and
1180 A. Mankin, "Recommendations for DNS Privacy Service
1181 Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932,
1182 October 2020, <https://www.rfc-editor.org/info/rfc8932>.
1184 [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
1185 Gudmundsson, O., and B. Wellington, "Secret Key
1186 Transaction Authentication for DNS (TSIG)", STD 93,
1187 RFC 8945, DOI 10.17487/RFC8945, November 2020,
1188 <https://www.rfc-editor.org/info/rfc8945>.
1191 Müller, M., Thomas, M., Wessels, D., Hardaker, W., Chung,
1192 T., Toorop, W., and R. van Rijswijk-Deij, "Roll, Roll,
1193 Roll Your Root: A Comprehensive Analysis of the First Ever
1194 DNSSEC Root KSK Rollover", DOI 10.1145/3355369.3355570,
1196 <https://dl.acm.org/doi/10.1145/3355369.3355570>.
1198 [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting
1199 (DNS RRL)", ISC-TN-2012-1-Draft1, April 2012.
1201 [TDNS] Zhu, L., Heidemann, J., Wessels, D., Mankin, A., and N.
1202 Somaiya, "Connection-Oriented DNS to Improve Privacy and
1203 Security", DOI 10.1109/SP.2015.18, May 2015,
1204 <https://doi.org/10.1109/SP.2015.18>.
1206 [TOYAMA] Toyama, K., Ishibashi, K., Toyono, T., Ishino, M.,
1207 Yoshimura, C., and K. Fujiwara, "DNS Anomalies and Their
1208 Impacts on DNS Cache Servers", NANOG 32, October 2004.
1210 [VERISIGN] Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in
1211 Root Server DITL Data", DNS-OARC 2014 Fall Workshop,
1215 Wikipedia, "TCP Fast Open", February 2022,
1216 <https://en.wikipedia.org/w/
1217 index.php?title=TCP_Fast_Open&oldid=1071397204>.
1219Appendix A. RFCs Related to DNS Transport over TCP
1221 This section enumerates all known RFCs with a status of Internet
1222 Standard, Proposed Standard, Informational, Best Current Practice, or
1223 Experimental that either implicitly or explicitly make assumptions or
1224 statements about the use of TCP as a transport for the DNS germane to
1227A.1. RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
1229 The Internet Standard [RFC1035] is the base DNS specification that
1230 explicitly defines support for DNS over TCP.
1232A.2. RFC 1536 - Common DNS Implementation Errors and Suggested Fixes
1234 The Informational document [RFC1536] states that UDP is "the chosen
1235 protocol for communication though TCP is used for zone transfers."
1236 That statement should now be considered in its historical context and
1237 is no longer a proper reflection of modern expectations.
1239A.3. RFC 1995 - Incremental Zone Transfer in DNS
1241 The Proposed Standard [RFC1995] documents the use of TCP as the
1242 fallback transport when Incremental Zone Transfer (IXFR) responses do
1243 not fit into a single UDP response. As with Authoritative Transfer
1244 (AXFR), IXFR messages are typically delivered over TCP by default in
1247A.4. RFC 1996 - A Mechanism for Prompt Notification of Zone Changes
1250 The Proposed Standard [RFC1996] suggests that a primary server may
1251 decide to issue NOTIFY messages over TCP. In practice, NOTIFY
1252 messages are generally sent over UDP, but this specification leaves
1253 open the possibility that the choice of transport protocol is up to
1254 the primary server; therefore, a secondary server ought to be able to
1255 operate over both UDP and TCP.
1257A.5. RFC 2181 - Clarifications to the DNS Specification
1259 The Proposed Standard [RFC2181] includes clarifying text on how a
1260 client should react to the TC bit set on responses. It is advised
1261 that the response be discarded and the query resent using TCP.
1263A.6. RFC 2694 - DNS extensions to Network Address Translators (DNS_ALG)
1265 The Informational document [RFC2694] enumerates considerations for
1266 NAT devices to properly handle DNS traffic. This document is
1267 noteworthy in its suggestion that "[t]ypically, TCP is used for AXFR
1268 requests," as further evidence that helps explain why DNS over TCP
1269 may have often been treated very differently than DNS over UDP in
1270 operational networks.
1272A.7. RFC 3225 - Indicating Resolver Support of DNSSEC
1274 The Proposed Standard [RFC3225] makes statements indicating that DNS
1275 over TCP is "detrimental" as a result of increased traffic, latency,
1276 and server load. This document is a companion to the next document
1277 in the RFC Series that describes the requirement for EDNS(0) support
1280A.8. RFC 3226 - DNSSEC and IPv6 A6 aware server/resolver message size
1283 Although updated by later DNSSEC RFCs, the Proposed Standard
1284 [RFC3226] strongly argues in favor of UDP messages instead of TCP,
1285 largely for performance reasons. The document declares EDNS(0) a
1286 requirement for DNSSEC servers and advocates that packet
1287 fragmentation may be preferable to TCP in certain situations.
1289A.9. RFC 4472 - Operational Considerations and Issues with IPv6 DNS
1291 The Informational document [RFC4472] notes that IPv6 data may
1292 increase DNS responses beyond what would fit in a UDP message. What
1293 is particularly noteworthy, but perhaps less common today than when
1294 this document was written, is that it refers to implementations that
1295 truncate data without setting the TC bit to encourage the client to
1296 resend the query using TCP.
1298A.10. RFC 5452 - Measures for Making DNS More Resilient against Forged
1301 The Proposed Standard [RFC5452] arose as public DNS systems began to
1302 experience widespread abuse from spoofed queries, resulting in
1303 amplification and reflection attacks against unwitting victims. One
1304 of the leading justifications for supporting DNS over TCP to thwart
1305 these attacks is briefly described in Section 9.3 of [RFC5452]
1306 ("Spoof Detection and Countermeasure").
1308A.11. RFC 5507 - Design Choices When Expanding the DNS
1310 The Informational document [RFC5507] was largely an attempt to
1311 dissuade new DNS data types from overloading the TXT resource record
1312 type. In so doing, it summarizes the conventional wisdom of DNS
1313 design and implementation practices. The authors suggest TCP
1314 overhead and stateful properties pose challenges compared to UDP and
1315 imply that UDP is generally preferred for performance and robustness.
1317A.12. RFC 5625 - DNS Proxy Implementation Guidelines
1319 The Best Current Practice document [RFC5625] provides DNS proxy
1320 implementation guidance including the mandate that a proxy "MUST
1321 [...] be prepared to receive and forward queries over TCP" even
1322 though it suggests that, historically, TCP transport has not been
1323 strictly mandatory in stub resolvers or recursive servers.
1325A.13. RFC 5936 - DNS Zone Transfer Protocol (AXFR)
1327 The Proposed Standard [RFC5936] provides a detailed specification for
1328 the zone transfer protocol, as originally outlined in the early DNS
1329 standards. AXFR operation is limited to TCP and not specified for
1330 UDP. This document discusses TCP usage at length.
1332A.14. RFC 7534 - AS112 Nameserver Operations
1334 The Informational document [RFC7534] enumerates the requirements for
1335 operation of AS112 project DNS servers. New AS112 nodes are tested
1336 for their ability to provide service on both UDP and TCP transports,
1337 with the implication that TCP service is an expected part of normal
1340A.15. RFC 6762 - Multicast DNS
1342 In the Proposed Standard [RFC6762], the TC bit is deemed to have
1343 essentially the same meaning as described in the original DNS
1344 specifications. That is, if a response with the TC bit set is
1345 received, "[...] the querier SHOULD reissue its query using TCP in
1346 order to receive the larger response."
1348A.16. RFC 6891 - Extension Mechanisms for DNS (EDNS(0))
1350 The Internet Standard [RFC6891] helped slow the use of and need for
1351 DNS-over-TCP messages. This document highlights concerns over server
1352 load and scalability in widespread use of DNS over TCP.
1354A.17. IAB RFC 6950 - Architectural Considerations on Application
1357 The Informational document [RFC6950] draws attention to large data in
1358 the DNS. TCP is referenced in the context as a common fallback
1359 mechanism and counter to some spoofing attacks.
1361A.18. RFC 7477 - Child-to-Parent Synchronization in DNS
1363 The Proposed Standard [RFC7477] specifies an RRType and a protocol to
1364 signal and synchronize NS, A, and AAAA resource record changes from a
1365 child-to-parent zone. Since this protocol may require multiple
1366 requests and responses, it recommends utilizing DNS over TCP to
1367 ensure the conversation takes place between a consistent pair of end
1370A.19. RFC 7720 - DNS Root Name Service Protocol and Deployment
1373 The Best Current Practice document [RFC7720] declares that root name
1374 service "MUST support UDP [RFC0768] and TCP [RFC0793] transport of
1375 DNS queries and responses."
1377A.20. RFC 7766 - DNS Transport over TCP - Implementation Requirements
1379 The Proposed Standard [RFC7766] instructs DNS implementors to provide
1380 support for carrying DNS-over-TCP messages in their software and
1381 might be considered the direct ancestor of this operational
1382 requirements document. The implementation requirements document
1383 codifies mandatory support for DNS-over-TCP in compliant DNS software
1384 but makes no recommendations to operators, which we seek to address
1387A.21. RFC 7828 - The edns-tcp-keepalive EDNS(0) Option
1389 The Proposed Standard [RFC7828] defines an EDNS(0) option to
1390 negotiate an idle timeout value for long-lived DNS-over-TCP
1391 connections. Consequently, this document is only applicable and
1392 relevant to DNS-over-TCP sessions and between implementations that
1393 support this option.
1395A.22. RFC 7858 - Specification for DNS over Transport Layer Security
1398 The Proposed Standard [RFC7858] defines a method for putting DNS
1399 messages into a TCP-based encrypted channel using TLS. This
1400 specification is noteworthy for explicitly targeting the stub-to-
1401 recursive traffic but does not preclude its application from
1402 recursive-to-authoritative traffic.
1404A.23. RFC 7873 - Domain Name System (DNS) Cookies
1406 The Proposed Standard [RFC7873] describes an EDNS(0) option to
1407 provide additional protection against query and answer forgery. This
1408 specification mentions DNS over TCP as an alternative mechanism when
1409 DNS cookies are not available. The specification does make mention
1410 of DNS-over-TCP processing in two specific situations. In one, when
1411 a server receives only a client cookie in a request, the server
1412 should consider whether the request arrived over TCP, and if so, it
1413 should consider accepting TCP as sufficient to authenticate the
1414 request and respond accordingly. In another, when a client receives
1415 a BADCOOKIE reply using a fresh server cookie, the client should
1416 retry using TCP as the transport.
1418A.24. RFC 7901 - CHAIN Query Requests in DNS
1420 The Experimental specification [RFC7901] describes an EDNS(0) option
1421 that can be used by a security-aware validating resolver to request
1422 and obtain a complete DNSSEC validation path for any single query.
1423 This document requires the use of DNS over TCP or a transport
1424 mechanism verified by a source IP address such as EDNS-COOKIE
1427A.25. RFC 8027 - DNSSEC Roadblock Avoidance
1429 The Best Current Practice document [RFC8027] details observed
1430 problems with DNSSEC deployment and mitigation techniques. Network
1431 traffic blocking and restrictions, including DNS-over-TCP messages,
1432 are highlighted as one reason for DNSSEC deployment issues. While
1433 this document suggests these sorts of problems are due to "non-
1434 compliant infrastructure", the scope of the document is limited to
1435 detection and mitigation techniques to avoid so-called DNSSEC
1438A.26. RFC 8094 - DNS over Datagram Transport Layer Security (DTLS)
1440 The Experimental specification [RFC8094] details a protocol that uses
1441 a datagram transport (UDP) but stipulates that "DNS clients and
1442 servers that implement DNS over DTLS MUST also implement DNS over TLS
1443 in order to provide privacy for clients that desire Strict Privacy
1444 [...]." This requirement implies DNS over TCP must be supported in
1445 case the message size is larger than the path MTU.
1447A.27. RFC 8162 - Using Secure DNS to Associate Certificates with Domain
1450 The Experimental specification [RFC8162] describes a technique to
1451 authenticate user X.509 certificates in an S/MIME system via the DNS.
1452 The document points out that the new experimental resource record
1453 types are expected to carry large payloads, resulting in the
1454 suggestion that "applications SHOULD use TCP -- not UDP -- to perform
1455 queries for the SMIMEA resource record."
1457A.28. RFC 8324 - DNS Privacy, Authorization, Special Uses, Encoding,
1458 Characters, Matching, and Root Structure: Time for Another Look?
1460 The Informational document [RFC8324] briefly discusses the common
1461 role and challenges of DNS over TCP throughout the history of DNS.
1463A.29. RFC 8467 - Padding Policies for Extension Mechanisms for DNS
1466 The Experimental document [RFC8467] reminds implementors to consider
1467 the underlying transport protocol (e.g., TCP) when calculating the
1468 padding length when artificially increasing the DNS message size with
1469 an EDNS(0) padding option.
1471A.30. RFC 8482 - Providing Minimal-Sized Responses to DNS Queries That
1474 The Proposed Standard [RFC8482] describes alternative ways that DNS
1475 servers can respond to queries of type ANY, which are sometimes used
1476 to provide amplification in DDoS attacks. The specification notes
1477 that responders may behave differently, depending on the transport.
1478 For example, minimal-sized responses may be used over UDP transport,
1479 while full responses may be given over TCP.
1481A.31. RFC 8483 - Yeti DNS Testbed
1483 The Informational document [RFC8483] describes a testbed environment
1484 that highlights some DNS-over-TCP behaviors, including issues
1485 involving packet fragmentation and operational requirements for TCP
1486 stream assembly in order to conduct DNS measurement and analysis.
1488A.32. RFC 8484 - DNS Queries over HTTPS (DoH)
1490 The Proposed Standard [RFC8484] defines a protocol for sending DNS
1491 queries and responses over HTTPS. This specification assumes TLS and
1492 TCP for the underlying security and transport layers, respectively.
1493 Self-described as a technique that more closely resembles a tunneling
1494 mechanism, DoH nevertheless likely implies DNS over TCP in some
1495 sense, if not directly.
1497A.33. RFC 8490 - DNS Stateful Operations
1499 The Proposed Standard [RFC8490] updates the base protocol
1500 specification with a new OPCODE to help manage stateful operations in
1501 persistent sessions, such as those that might be used by DNS over
1504A.34. RFC 8501 - Reverse DNS in IPv6 for Internet Service Providers
1506 The Informational document [RFC8501] identifies potential operational
1507 challenges with dynamic DNS, including denial-of-service threats.
1508 The document suggests TCP may provide some advantages but that
1509 updating hosts would need to be explicitly configured to use TCP
1512A.35. RFC 8806 - Running a Root Server Local to a Resolver
1514 The Informational document [RFC8806] describes how to obtain and
1515 operate a local copy of the root zone with examples showing how to
1516 pull from authoritative sources using a DNS-over-TCP zone transfer.
1518A.36. RFC 8906 - A Common Operational Problem in DNS Servers: Failure
1521 The Best Current Practice document [RFC8906] discusses a number of
1522 DNS operational failure scenarios and how to avoid them. This
1523 includes discussions involving DNS-over-TCP queries, EDNS over TCP,
1524 and a testing methodology that includes a section on verifying DNS-
1525 over-TCP functionality.
1527A.37. RFC 8932 - Recommendations for DNS Privacy Service Operators
1529 The Best Current Practice document [RFC8932] presents privacy
1530 considerations to DNS privacy service operators. These mechanisms
1531 sometimes include the use of TCP and are therefore susceptible to
1532 information leakage such as TCP-based fingerprinting. This document
1533 also references an earlier draft version of this document.
1535A.38. RFC 8945 - Secret Key Transaction Authentication for DNS (TSIG)
1537 The Internet Standard [RFC8945] recommends that a client use TCP if
1538 truncated TSIG messages are received.
1542 This document was initially motivated by feedback from students who
1543 pointed out that they were hearing contradictory information about
1544 filtering DNS-over-TCP messages. Thanks in particular to a teaching
1545 colleague, JPL, who perhaps unknowingly encouraged the initial
1546 research into the differences between what the community has
1547 historically said and did. Thanks to all the NANOG 63 attendees who
1548 provided feedback for an early talk on this subject.
1550 The following individuals provided an array of feedback to help
1551 improve this document: Joe Abley, Piet Barber, Sara Dickinson, Tony
1552 Finch, Bob Harold, Paul Hoffman, Geoff Huston, Tatuya Jinmei, Puneet
1553 Sood, and Richard Wilhelm. The authors are also indebted to the
1554 contributions stemming from discussion in the TCPM Working Group
1555 meeting at IETF 104. Any remaining errors or imperfections are the
1556 sole responsibility of the document authors.
1563 United States of America
1564 Phone: +1 312 493 0305
1565 Email: jtk@dataplane.org
1566 URI: https://dataplane.org/jtk/
1573 United States of America
1574 Phone: +1 703 948 3200
1575 Email: dwessels@verisign.com
1576 URI: https://verisign.com