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