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 126.96.36.199 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 188.8.131.52 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 184.108.40.206 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: email@example.com 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: firstname.lastname@example.org 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.