idnits 2.17.1 draft-ietf-dnsop-dns-tcp-requirements-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document updates RFC1123, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1123, updated by this document, for RFC5378 checks: 1989-10-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 6, 2020) is 1443 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Appendix A' is mentioned on line 324, but not defined == Missing Reference: 'Section 9' is mentioned on line 325, but not defined == Missing Reference: 'RFC768' is mentioned on line 1108, but not defined == Missing Reference: 'RFC793' is mentioned on line 1108, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2541 (Obsoleted by RFC 4641) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5966 (Obsoleted by RFC 7766) -- Obsolete informational reference (is this intentional?): RFC 6304 (Obsoleted by RFC 7534) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations J. Kristoff 3 Internet-Draft DePaul University 4 Updates: 1123 (if approved) D. Wessels 5 Intended status: Best Current Practice Verisign 6 Expires: November 7, 2020 May 6, 2020 8 DNS Transport over TCP - Operational Requirements 9 draft-ietf-dnsop-dns-tcp-requirements-06 11 Abstract 13 This document encourages the practice of permitting DNS messages to 14 be carried over TCP on the Internet. This includes both DNS over 15 unencrypted TCP, as well as over an encrypted TLS session. The 16 document also considers the consequences with this form of DNS 17 communication and the potential operational issues that can arise 18 when this best common practice is not upheld. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 7, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 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 Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 56 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Uneven Transport Usage and Preference . . . . . . . . . . 4 58 2.2. Waiting for Large Messages and Reliability . . . . . . . 5 59 2.3. EDNS0 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.4. Fragmentation and Truncation . . . . . . . . . . . . . . 6 61 2.5. "Only Zone Transfers Use TCP" . . . . . . . . . . . . . . 7 62 3. DNS over TCP Requirements . . . . . . . . . . . . . . . . . . 7 63 4. Network and System Considerations . . . . . . . . . . . . . . 8 64 4.1. Connection Establishment and Admission . . . . . . . . . 8 65 4.2. Connection Management . . . . . . . . . . . . . . . . . . 9 66 4.3. Connection Termination . . . . . . . . . . . . . . . . . 10 67 4.4. DNS-over-TLS . . . . . . . . . . . . . . . . . . . . . . 11 68 5. DNS over TCP Filtering Risks . . . . . . . . . . . . . . . . 11 69 5.1. DNS Wedgie . . . . . . . . . . . . . . . . . . . . . . . 11 70 5.2. DNS Root Zone KSK Rollover . . . . . . . . . . . . . . . 12 71 6. Logging and Monitoring . . . . . . . . . . . . . . . . . . . 12 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 78 11.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Appendix A. Standards Related to DNS Transport over TCP . . . . 20 80 A.1. IETF RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND 81 SPECIFICATION . . . . . . . . . . . . . . . . . . . . . . 20 82 A.2. IETF RFC 1536 - Common DNS Implementation Errors and 83 Suggested Fixes . . . . . . . . . . . . . . . . . . . . . 21 84 A.3. IETF RFC 1995 - Incremental Zone Transfer in DNS . . . . 21 85 A.4. IETF RFC 1996 - A Mechanism for Prompt Notification of 86 Zone Changes (DNS NOTIFY) . . . . . . . . . . . . . . . . 21 87 A.5. IETF RFC 2181 - Clarifications to the DNS Specification . 21 88 A.6. IETF RFC 2694 - DNS extensions to Network Address 89 Translators (DNS_ALG) . . . . . . . . . . . . . . . . . . 21 90 A.7. IETF RFC 3225 - Indicating Resolver Support of DNSSEC . . 21 91 A.8. IETF RFC 3326 - DNSSEC and IPv6 A6 aware server/resolver 92 message size requirements . . . . . . . . . . . . . . . . 22 93 A.9. IETF RFC 4472 - Operational Considerations and Issues 94 with IPv6 DNS . . . . . . . . . . . . . . . . . . . . . . 22 95 A.10. IETF RFC 5452 - Measures for Making DNS More Resilient 96 against Forged Answers . . . . . . . . . . . . . . . . . 22 98 A.11. IETF RFC 5507 - Design Choices When Expanding the DNS . . 22 99 A.12. IETF RFC 5625 - DNS Proxy Implementation Guidelines . . . 22 100 A.13. IETF RFC 5936 - DNS Zone Transfer Protocol (AXFR) . . . . 23 101 A.14. IETF RFC 5966 - DNS Transport over TCP - Implementation 102 Requirements . . . . . . . . . . . . . . . . . . . . . . 23 103 A.15. IETF RFC 6304 - AS112 Nameserver Operations . . . . . . . 23 104 A.16. IETF RFC 6762 - Multicast DNS . . . . . . . . . . . . . . 23 105 A.17. IETF RFC 6891 - Extension Mechanisms for DNS (EDNS(0)) . 23 106 A.18. IETF RFC 6950 - Architectural Considerations on 107 Application Features in the DNS . . . . . . . . . . . . . 23 108 A.19. IETF RFC 7477 - Child-to-Parent Synchronization in DNS . 24 109 A.20. IETF RFC 7720 - DNS Root Name Service Protocol and 110 Deployment Requirements . . . . . . . . . . . . . . . . . 24 111 A.21. IETF RFC 7766 - DNS Transport over TCP - Implementation 112 Requirements . . . . . . . . . . . . . . . . . . . . . . 24 113 A.22. IETF RFC 7828 - The edns-tcp-keepalive EDNS0 Option . . . 24 114 A.23. IETF RFC 7858 - Specification for DNS over Transport 115 Layer Security (TLS) . . . . . . . . . . . . . . . . . . 24 116 A.24. IETF RFC 7873 - Domain Name System (DNS) Cookies . . . . 24 117 A.25. IETF RFC 7901 - CHAIN Query Requests in DNS . . . . . . . 25 118 A.26. IETF RFC 8027 - DNSSEC Roadblock Avoidance . . . . . . . 25 119 A.27. IETF RFC 8094 - DNS over Datagram Transport Layer 120 Security (DTLS) . . . . . . . . . . . . . . . . . . . . . 25 121 A.28. IETF RFC 8162 - Using Secure DNS to Associate 122 Certificates with Domain Names for S/MIME . . . . . . . . 25 123 A.29. IETF RFC 8324 - DNS Privacy, Authorization, Special Uses, 124 Encoding, Characters, Matching, and Root Structure: Time 125 for Another Look? . . . . . . . . . . . . . . . . . . . . 26 126 A.30. IETF RFC 8467 - Padding Policies for Extension Mechanisms 127 for DNS (EDNS(0)) . . . . . . . . . . . . . . . . . . . . 26 128 A.31. IETF RFC 8483 - Yeti DNS Testbed . . . . . . . . . . . . 26 129 A.32. IETF RFC 8484 - DNS Queries over HTTPS (DoH) . . . . . . 26 130 A.33. IETF RFC 8490 - DNS Stateful Operations . . . . . . . . . 26 131 A.34. IETF RFC 8501 - Reverse DNS in IPv6 for Internet Service 132 Providers . . . . . . . . . . . . . . . . . . . . . . . . 26 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 135 1. Introduction 137 DNS messages may be delivered using UDP or TCP communications. While 138 most DNS transactions are carried over UDP, some operators have been 139 led to believe that any DNS over TCP traffic is unwanted or 140 unnecessary for general DNS operation. When DNS over TCP has been 141 restricted, a variety of communication failures and debugging 142 challenges often arise. As DNS and new naming system features have 143 evolved, TCP as a transport has become increasingly important for the 144 correct and safe operation of an Internet DNS. Reflecting modern 145 usage, the DNS standards were recently updated to declare support for 146 TCP is now a required part of the DNS implementation specifications 147 [RFC7766]. This document is the formal requirements equivalent for 148 the operational community, encouraging system administrators, network 149 engineers, and security staff to ensure DNS over TCP communications 150 support is on par with DNS over UDP communications. 152 1.1. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [RFC2119]. 158 2. Background 160 The curious state of disagreement in operational best practices and 161 guidance for DNS transport protocols derives from conflicting 162 messages operators have gotten from other operators, implementors, 163 and even the IETF. Sometimes these mixed signals have been explicit, 164 on other occasions they have suspiciously implicit. This section 165 presents an interpretation of the storied and conflicting history 166 that led to this document. 168 2.1. Uneven Transport Usage and Preference 170 In the original suite of DNS specifications, [RFC1034] and [RFC1035] 171 clearly specified that DNS messages could be carried in either UDP or 172 TCP, but they also stated a preference for UDP as the best transport 173 for queries in the general case. As stated in [RFC1035]: 175 "While virtual circuits can be used for any DNS activity, 176 datagrams are preferred for queries due to their lower overhead 177 and better performance." 179 Another early, important, and influential document, [RFC1123], marked 180 the preference for a transport protocol more explicitly: 182 "DNS resolvers and recursive servers MUST support UDP, and SHOULD 183 support TCP, for sending (non-zone-transfer) queries." 185 and further stipulated: 187 "A name server MAY limit the resources it devotes to TCP queries, 188 but it SHOULD NOT refuse to service a TCP query just because it 189 would have succeeded with UDP." 191 Culminating in [RFC1536], DNS over TCP came to be associated 192 primarily with the zone transfer mechanism, while most DNS queries 193 and responses were seen as the dominion of UDP. 195 2.2. Waiting for Large Messages and Reliability 197 In the original specifications, the maximum DNS over UDP message size 198 was enshrined at 512 bytes. However, even while [RFC1123] preferred 199 UDP for non-zone transfer queries, it foresaw DNS over TCP becoming 200 more popular in the future to overcome this limitation: 202 "[...] it is also clear that some new DNS record types defined in 203 the future will contain information exceeding the 512 byte limit 204 that applies to UDP, and hence will require TCP. 206 At least two new, widely anticipated developments were set to elevate 207 the need for DNS over TCP transactions. The first was dynamic 208 updates defined in [RFC2136] and the second was the set of extensions 209 collectively known as DNSSEC originally specified in [RFC2541]. The 210 former suggested "requestors who require an accurate response code 211 must use TCP," while the latter warned "... larger keys increase the 212 size of KEY and SIG RRs. This increases the chance of DNS UDP packet 213 overflow and the possible necessity for using higher overhead TCP in 214 responses." 216 Yet, defying some expectations, DNS over TCP remained little-used in 217 real traffic across the Internet around this time. Dynamic updates 218 saw little deployment between autonomous networks. Around the time 219 DNSSEC was first defined, another new feature helped solidify UDP 220 transport dominance for message transactions. 222 2.3. EDNS0 224 In 1999 the IETF published the Extension Mechanisms for DNS (EDNS0) 225 in [RFC2671] (superseded in 2013 by an update in [RFC6891]). This 226 document standardized a way for communicating DNS nodes to perform 227 rudimentary capabilities negotiation. One such capability written 228 into the base specification and present in every EDNS0-compatible 229 message is the value of the maximum UDP payload size the sender can 230 support. This unsigned 16-bit field specifies, in bytes, the maximum 231 (possibly fragmented) DNS message size a node is capable of 232 receiving. In practice, typical values are a subset of the 512- to 233 4096-byte range. EDNS0 became widely deployed over the next several 234 years and numerous surveys ([CASTRO2010], [NETALYZR]) have shown many 235 systems currently support larger UDP MTUs with EDNS0. 237 The natural effect of EDNS0 deployment meant DNS messages larger than 238 512 bytes would be less reliant on TCP than they might otherwise have 239 been. While a non-negligible population of DNS systems lacked EDNS0 240 or fell back to TCP when necessary, DNS over TCP transactions 241 remained a very small fraction of overall DNS traffic [VERISIGN]. 243 2.4. Fragmentation and Truncation 245 Although EDNS0 provides a way for endpoints to signal support for DNS 246 messages exceeding 512 bytes, the realities of a diverse and 247 inconsistently deployed Internet may result in some large messages 248 being unable to reach their destination. Any IP datagram whose size 249 exceeds the MTU of a link it transits will be fragmented and then 250 reassembled by the receiving host. Unfortunately, it is not uncommon 251 for middleboxes and firewalls to block IP fragments. If one or more 252 fragments do not arrive, the application does not receive the message 253 and the request times out. 255 For IPv4-connected hosts, the de-facto MTU is often the Ethernet 256 payload size of 1500 bytes. This means that the largest unfragmented 257 UDP DNS message that can be sent over IPv4 is likely 1472 bytes. For 258 IPv6, the situation is a little more complicated. First, IPv6 259 headers are 40 bytes (versus 20 without options in IPv4). Second, it 260 seems as though some people have mis-interpreted IPv6's required 261 minimum MTU of 1280 as a required maximum. Third, fragmentation in 262 IPv6 can only be done by the host originating the datagram. The need 263 to fragment is conveyed in an ICMPv6 "packet too big" message. The 264 originating host indicates a fragmented datagram with IPv6 extension 265 headers. Unfortunately, it is quite common for both ICMPv6 and IPv6 266 extension headers to be blocked by middleboxes. According to 267 [HUSTON] some 35% of IPv6-capable recursive resolvers were unable to 268 receive a fragmented IPv6 packet. 270 The practical consequence of all this is that DNS requestors must be 271 prepared to retry queries with different EDNS0 maximum message size 272 values. Administrators of BIND are likely to be familiar with seeing 273 "success resolving ... after reducing the advertised EDNS0 UDP packet 274 size to 512 octets" messages in their system logs. 276 Often, reducing the EDNS0 UDP packet size leads to a successful 277 response. That is, the necessary data fits within the smaller 278 message size. However, when the data does not fit, the server sets 279 the truncated flag in its response, indicating the client should 280 retry over TCP to receive the whole response. This is undesirable 281 from the client's point of view because it adds more latency and 282 potentially undesirable from the server's point of view due to the 283 increased resource requirements of TCP. 285 The issues around fragmentation, truncation, and TCP are driving 286 certain implementation and policy decisions in the DNS. Notably, 287 Cloudflare implemented what it calls "DNSSEC black lies" [CLOUDFLARE] 288 and uses ECDSA algorithms, such that their signed responses fit 289 easily in 512 bytes. The KSK Rollover design team [DESIGNTEAM] spent 290 a lot of time thinking and worrying about response sizes. There is 291 growing sentiment in the DNSSEC community that RSA key sizes beyond 292 2048-bits are impractical and that critical infrastructure zones 293 should transition to elliptic curve algorithms to keep response sizes 294 manageable. 296 More recently, renewed security concerns about fragmented DNS 297 messages ([AVOID_FRAGS], [FRAG_POISON]) are leading implementors to 298 consider lower default EDNS0 UDP payload size values for both 299 queriers and responders. 301 2.5. "Only Zone Transfers Use TCP" 303 Today, the majority of the DNS community expects, or at least has a 304 desire, to see DNS over TCP transactions occur without interference. 305 However there has also been a long-held belief by some operators, 306 particularly for security-related reasons, that DNS over TCP services 307 should be purposely limited or not provided at all [CHES94], 308 [DJBDNS]. A popular meme has also held the imagination of some: that 309 DNS over TCP is only ever used for zone transfers and is generally 310 unnecessary otherwise, with filtering all DNS over TCP traffic even 311 described as a best practice. 313 The position on restricting DNS over TCP had some justification given 314 that historic implementations of DNS nameservers provided very little 315 in the way of TCP connection management (for example see 316 Section 6.1.2 of [RFC7766] for more details). However modern 317 standards and implementations are nearing parity with the more 318 sophisticated TCP management techniques employed by, for example, 319 HTTP(S) servers and load balancers. 321 3. DNS over TCP Requirements 323 An average increase in DNS message size (e.g., due to DNSSEC), the 324 continued development of new DNS features [Appendix A], and a denial 325 of service mitigation technique [Section 9] have suggested that DNS 326 over TCP transactions are as important to the correct and safe 327 operation of the Internet DNS as ever, if not more so. Furthermore, 328 there has been serious research that argues connection-oriented DNS 329 transactions may provide security and privacy advantages over UDP 330 transport. [TDNS] In fact [RFC7858], a Standards Track document, is 331 just this sort of specification. Therefore, this document makes 332 explicit that it is undesirable for network operators to artificially 333 inhibit DNS over TCP transport. 335 Section 6.1.3.2 in [RFC1123] is updated: All DNS resolvers and 336 servers MUST support and service both UDP and TCP queries. 338 o Authoritative servers MUST support and service all TCP queries so 339 that they do not limit the size of responses to what fits in a 340 single UDP packet. 342 o Recursive servers (or forwarders) MUST support and service all TCP 343 queries so that they do not prevent large responses from a TCP- 344 capable server from reaching its TCP-capable clients. 346 Regarding the choice of limiting the resources a server devotes to 347 queries, Section 6.1.3.2 in [RFC1123] also says: 349 "A name server MAY limit the resources it devotes to TCP queries, 350 but it SHOULD NOT refuse to service a TCP query just because it 351 would have succeeded with UDP." 353 This requirement is hereby updated: A name server MAY limit the 354 resources it devotes to queries, but it MUST NOT refuse to service a 355 query just because it would have succeeded with another transport 356 protocol. 358 Filtering of DNS over TCP is considered harmful in the general case. 359 DNS resolver and server operators MUST support and provide DNS 360 service over both UDP and TCP transports. Likewise, network 361 operators MUST allow DNS service over both UDP and TCP transports. 362 It is acknowledged that DNS over TCP service can pose operational 363 challenges that are not present when running DNS over UDP alone, and 364 vice-versa. However, it is the aim of this document to argue that 365 the potential damage incurred by prohibiting DNS over TCP service is 366 more detrimental to the continued utility and success of the DNS than 367 when its usage is allowed. 369 4. Network and System Considerations 371 This section describes measures that systems and applications can 372 take to optimize performance over TCP and to protect themselves from 373 TCP-based resource exhaustion and attacks. 375 4.1. Connection Establishment and Admission 377 Resolvers and other DNS clients should be aware that some servers 378 might not be reachable over TCP. For this reason, clients MAY want 379 to track and limit the number of TCP connections and connection 380 attempts to a single server. Additionally, DNS clients MAY want to 381 enforce a short timeout on unestablished connections, rather than 382 rely on the host operating system's TCP connection timeout, which is 383 often around 60-120 seconds. 385 The SYN flooding attack is a denial-of-service method affecting hosts 386 that run TCP server processes [RFC4987]. This attack can be very 387 effective if not mitigated. One of the most effective mitigation 388 techniques is SYN cookies, which allows the server to avoid 389 allocating any state until the successful completion of the three-way 390 handshake. 392 Services not intended for use by the public Internet, such as most 393 recursive name servers, SHOULD be protected with access controls. 394 Ideally these controls are placed in the network, well before before 395 any unwanted TCP packets can reach the DNS server host or 396 application. If this is not possible, the controls can be placed in 397 the application itself. In some situations (e.g. attacks) it may be 398 necessary to deploy access controls for DNS services that should 399 otherwise be globally reachable. 401 The FreeBSD, OpenBSD, and NetBSD operating systems have an "accept 402 filter" feature ([accept_filter]) that postpones delivery of TCP 403 connections to applications until a complete, valid request has been 404 received. The dns_accf(9) filter ensures that a valid DNS message is 405 received. If not, the bogus connection never reaches the 406 application. Applications must be coded and configured to make use 407 of this filter. 409 Per [RFC7766], applications and administrators are advised to 410 remember that TCP MAY be used before sending any UDP queries. 411 Networks and applications MUST NOT be configured to refuse TCP 412 queries that were not preceded by a UDP query. 414 TCP Fast Open [RFC7413] (TFO) allows TCP clients to shorten the 415 handshake for subsequent connections to the same server. TFO saves 416 one round-trip time in the connection setup. DNS servers SHOULD 417 enable TFO when possible. Furthermore, DNS servers clustered behind 418 a single service address (e.g., anycast or load-balancing), SHOULD 419 use the same TFO server key on all instances. 421 DNS clients MAY also enable TFO when possible. Currently, on some 422 operating systems it is not implemented or disabled by default. 423 [WIKIPEDIA_TFO] describes applications and operating systems that 424 support TFO. 426 4.2. Connection Management 428 Since host memory for TCP state is a finite resource, DNS clients and 429 servers MUST actively manage their connections. Applications that do 430 not actively manage their connections can encounter resource 431 exhaustion leading to denial of service. For DNS, as in other 432 protocols, there is a tradeoff between keeping connections open for 433 potential future use and the need to free up resources for new 434 connections that will arrive. 436 DNS server software SHOULD provide a configurable limit on the total 437 number of established TCP connections. If the limit is reached, the 438 application is expected to either close existing (idle) connections 439 or refuse new connections. Operators SHOULD ensure the limit is 440 configured appropriately for their particular situation. 442 DNS server software MAY provide a configurable limit on the number of 443 established connections per source IP address or subnet. This can be 444 used to ensure that a single or small set of users can not consume 445 all TCP resources and deny service to other users. Operators SHOULD 446 ensure this limit is configured appropriately, based on their number 447 of diversity of users. 449 DNS server software SHOULD provide a configurable timeout for idle 450 TCP connections. For very busy name servers this might be set to a 451 low value, such as a few seconds. For less busy servers it might be 452 set to a higher value, such as tens of seconds. DNS clients and 453 servers SHOULD signal their timeout values using the edns-tcp- 454 keepalive option [RFC7828]. 456 DNS server software MAY provide a configurable limit on the number of 457 transactions per TCP connection. This document does not offer advice 458 on particular values for such a limit. 460 Similarly, DNS server software MAY provide a configurable limit on 461 the total duration of a TCP connection. This document does not offer 462 advice on particular values for such a limit. 464 Since clients may not be aware of server-imposed limits, clients 465 utilizing TCP for DNS need to always be prepared to re-establish 466 connections or otherwise retry outstanding queries. 468 4.3. Connection Termination 470 In general, it is preferable for clients to initiate the close of a 471 TCP connection. The TCP peer that initiates a connection close 472 retains the socket in the TIME_WAIT state for some amount of time, 473 possibly a few minutes. On a busy server, the accumulation of many 474 sockets in TIME_WAIT can cause performance problems or even denial of 475 service. 477 On systems where large numbers of sockets in TIME_WAIT are observed, 478 it may be beneficial to tune the local TCP parameters. For example, 479 the Linux kernel provides a number of "sysctl" parameters related to 480 TIME_WAIT, such as net.ipv4.tcp_fin_timeout, net.ipv4.tcp_tw_recycle, 481 and net.ipv4.tcp_tw_reuse. In extreme cases, implementors and 482 operators of very busy servers may find it necessary to utilize the 483 SO_LINGER socket option ([Stevens] Section 7.5) with a value of zero 484 so that the server doesn't accumulate TIME_WAIT sockets. 486 4.4. DNS-over-TLS 488 DNS messages may be sent over TLS to provide privacy between stubs 489 and recursive resolvers. [RFC7858] is a standards track document 490 describing how this works. Although DNS-over-TLS utilizes TCP port 491 853 instead of port 53, this document applies equally well to DNS- 492 over-TLS. Note, however, DNS-over-TLS is currently only defined 493 between stubs and recursives. 495 The use of TLS places even stronger operational burdens on DNS 496 clients and servers. Cryptographic functions for authentication and 497 encryption require additional processing. Unoptimized connection 498 setup takes two additional round-trips compared to TCP, but can be 499 reduced with Fast TLS connection resumption [RFC5077] and TLS False 500 Start [RFC7918]. 502 5. DNS over TCP Filtering Risks 504 Networks that filter DNS over TCP risk losing access to significant 505 or important pieces of the DNS namespace. For a variety of reasons a 506 DNS answer may require a DNS over TCP query. This may include large 507 message sizes, lack of EDNS0 support, DDoS mitigation techniques, or 508 perhaps some future capability that is as yet unforeseen will also 509 demand TCP transport. 511 For example, [RFC7901] describes a latency-avoiding technique that 512 sends extra data in DNS responses. This makes responses larger and 513 potentially increases the effectiveness of DDoS reflection attacks. 514 The specification mandates the use of TCP or DNS Cookies [RFC7873]. 516 Even if any or all particular answers have consistently been returned 517 successfully with UDP in the past, this continued behavior cannot be 518 guaranteed when DNS messages are exchanged between autonomous 519 systems. Therefore, filtering of DNS over TCP is considered harmful 520 and contrary to the safe and successful operation of the Internet. 521 This section enumerates some of the known risks known at the time of 522 this writing when networks filter DNS over TCP. 524 5.1. DNS Wedgie 526 Networks that filter DNS over TCP may inadvertently cause problems 527 for third-party resolvers as experienced by [TOYAMA]. If, for 528 instance, a resolver receives a truncated answer from a server, but 529 when the resolver resends the query using TCP and the TCP response 530 never arrives, not only will a complete answer be unavailable, but 531 the resolver will incur the full extent of TCP retransmissions and 532 timeouts. This situation might place extreme strain on resolver 533 resources. If the number and frequency of these truncated answers 534 are sufficiently high, the steady-state of lost resources as a result 535 is a "DNS wedgie." A DNS wedgie is generally not easily or 536 completely mitigated by the affected DNS resolver operator. 538 5.2. DNS Root Zone KSK Rollover 540 The plans for deploying a new root zone DNSSEC KSK highlighted a 541 potential problem in retrieving the root zone key set [LEWIS]. 542 During some phases of the KSK rollover process, root zone DNSKEY 543 responses were larger than 1280 bytes, the IPv6 minimum MTU for links 544 carrying IPv6 traffic [RFC2460]. There was some concern that any DNS 545 server unable to receive large DNS messages over UDP, or any DNS 546 message over TCP, would experience disruption while performing DNSSEC 547 validation. 549 However, during the year-long postponement of the KSK rollover there 550 were no reported problems that could be attributed to the 1414 octet 551 DNSKEY response when both the old and new keys were published in the 552 zone. Additionally, there were no reported problems during the two 553 month period when the old key was published as revoked and the DNSKEY 554 response was 1425 octets in size [ROLL_YOUR_ROOT]. 556 6. Logging and Monitoring 558 Developers of applications that log or monitor DNS SHOULD NOT ignore 559 TCP due to the perception that it is rarely used or is hard to 560 process. Operators SHOULD ensure that their monitoring and logging 561 applications properly capture DNS message over TCP. Otherwise, 562 attacks, exfiltration attempts, and normal traffic may go undetected. 564 DNS messages over TCP are in no way guaranteed to arrive in single 565 segments. In fact, a clever attacker might attempt to hide certain 566 messages by forcing them over very small TCP segments. Applications 567 that capture network packets (e.g., with libpcap [libpcap]) SHOULD be 568 prepared to implement and perform full TCP segment reassembly. 569 dnscap [dnscap] is an open-source example of a DNS logging program 570 that implements TCP reassembly. 572 Developers SHOULD also keep in mind connection reuse, query 573 pipelining, and out-of-order responses when building and testing DNS 574 monitoring applications. 576 As an alternative to packet capture, some DNS server software 577 supports dnstap [dnstap] as an integrated monitoring protocol 578 intended to facilitate wide-scale DNS monitoring. 580 7. Acknowledgments 582 This document was initially motivated by feedback from students who 583 pointed out that they were hearing contradictory information about 584 filtering DNS over TCP messages. Thanks in particular to a teaching 585 colleague, JPL, who perhaps unknowingly encouraged the initial 586 research into the differences between what the community has 587 historically said and did. Thanks to all the NANOG 63 attendees who 588 provided feedback to an early talk on this subject. 590 The following individuals provided an array of feedback to help 591 improve this document: Piet Barber, Sara Dickinson, Bob Harold, 592 Tatuya Jinmei, and Paul Hoffman, Puneet Sood, Richard Wilhelm. The 593 authors are also indebted to the contributions stemming from 594 discussion in the tcpm working group meeting at IETF 104. Any 595 remaining errors or imperfections are the sole responsibility of the 596 document authors. 598 8. IANA Considerations 600 This memo includes no request to IANA. 602 9. Security Considerations 604 Ironically, returning truncated DNS over UDP answers in order to 605 induce a client query to switch to DNS over TCP has become a common 606 response to source address spoofed, DNS denial-of-service attacks 607 [RRL]. Historically, operators have been wary of TCP-based attacks, 608 but in recent years, UDP-based flooding attacks have proven to be the 609 most common protocol attack on the DNS. Nevertheless, a high rate of 610 short-lived DNS transactions over TCP may pose challenges. While 611 many operators have provided DNS over TCP service for many years 612 without duress, past experience is no guarantee of future success. 614 DNS over TCP is not unlike many other Internet TCP services. TCP 615 threats and many mitigation strategies have been well-documented in a 616 series of documents such as [RFC4953], [RFC4987], [RFC5927], and 617 [RFC5961]. 619 10. Privacy Considerations 621 Since DNS over both UDP and TCP use the same underlying message 622 format, the use of one transport instead of the other does change the 623 privacy characteristics of the message content (i.e., the name being 624 queried). DNS over TLS or DTLS is the recommended way to achieve DNS 625 privacy. 627 Because TCP is somewhat more complex than UDP, some characteristics 628 of a TCP conversation may enable fingerprinting and tracking that is 629 not possible with UDP. For example, the choice of initial sequence 630 numbers, window size, and options might be able to identify a 631 particular TCP implementation, or even individual hosts behind shared 632 resources such as network address translators (NATs). 634 11. References 636 11.1. Normative References 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, 640 DOI 10.17487/RFC2119, March 1997, 641 . 643 11.2. Informative References 645 [accept_filter] 646 FreeBSD, "FreeBSD accept_filter(9)", May 2018, 647 . 649 [AVOID_FRAGS] 650 Fujiwara, K., "It's time to consider avoiding IP 651 fragmentation in the DNS", Jul 2019, 652 . 655 [CASTRO2010] 656 Castro, S., Zhang, M., John, W., Wessels, D., and k. 657 claffy, "Understanding and preparing for DNS evolution", 658 2010. 660 [CHES94] Cheswick, W. and S. Bellovin, "Firewalls and Internet 661 Security: Repelling the Wily Hacker", 1994. 663 [CLOUDFLARE] 664 Grant, D., "Economical With The Truth: Making DNSSEC 665 Answers Cheap", June 2016, 666 . 668 [DESIGNTEAM] 669 Design Team Report, "Root Zone KSK Rollover Plan", 670 December 2015, . 673 [DJBDNS] D.J. Bernstein, "When are TCP queries sent?", 2002, 674 . 676 [dnscap] DNS-OARC, "DNSCAP", May 2018, 677 . 679 [dnstap] Edmonds, R. and P. Vixie, "dnstap", May 2018, 680 . 682 [FRAG_POISON] 683 Herzberg, A. and H. Shulman, "Fragmentation Considered 684 Poisonous", May 2012, 685 . 687 [HUSTON] Huston, G., "Dealing with IPv6 fragmentation in the DNS", 688 August 2017, . 691 [LEWIS] Lewis, E., "2017 DNSSEC KSK Rollover", RIPE 74 Budapest, 692 Hungary, May 2017, . 695 [libpcap] Tcpdump/Libpcap, "Tcpdump and Libpcap", May 2018, 696 . 698 [NETALYZR] 699 Kreibich, C., Weaver, N., Nechaev, B., and V. Paxson, 700 "Netalyzr: Illuminating The Edge Network", 2010. 702 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 703 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 704 . 706 [RFC1035] Mockapetris, P., "Domain names - implementation and 707 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 708 November 1987, . 710 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 711 Application and Support", STD 3, RFC 1123, 712 DOI 10.17487/RFC1123, October 1989, 713 . 715 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 716 Miller, "Common DNS Implementation Errors and Suggested 717 Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993, 718 . 720 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 721 DOI 10.17487/RFC1995, August 1996, 722 . 724 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 725 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 726 August 1996, . 728 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 729 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 730 RFC 2136, DOI 10.17487/RFC2136, April 1997, 731 . 733 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 734 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 735 . 737 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 738 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 739 December 1998, . 741 [RFC2541] Eastlake 3rd, D., "DNS Security Operational 742 Considerations", RFC 2541, DOI 10.17487/RFC2541, March 743 1999, . 745 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 746 RFC 2671, DOI 10.17487/RFC2671, August 1999, 747 . 749 [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. 750 Heffernan, "DNS extensions to Network Address Translators 751 (DNS_ALG)", RFC 2694, DOI 10.17487/RFC2694, September 752 1999, . 754 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 755 RFC 3225, DOI 10.17487/RFC3225, December 2001, 756 . 758 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver 759 message size requirements", RFC 3226, 760 DOI 10.17487/RFC3226, December 2001, 761 . 763 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 764 Considerations and Issues with IPv6 DNS", RFC 4472, 765 DOI 10.17487/RFC4472, April 2006, 766 . 768 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 769 RFC 4953, DOI 10.17487/RFC4953, July 2007, 770 . 772 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 773 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 774 . 776 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 777 "Transport Layer Security (TLS) Session Resumption without 778 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 779 January 2008, . 781 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 782 Resilient against Forged Answers", RFC 5452, 783 DOI 10.17487/RFC5452, January 2009, 784 . 786 [RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, 787 Ed., "Design Choices When Expanding the DNS", RFC 5507, 788 DOI 10.17487/RFC5507, April 2009, 789 . 791 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 792 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 793 . 795 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 796 DOI 10.17487/RFC5927, July 2010, 797 . 799 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 800 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 801 . 803 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 804 Robustness to Blind In-Window Attacks", RFC 5961, 805 DOI 10.17487/RFC5961, August 2010, 806 . 808 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation 809 Requirements", RFC 5966, DOI 10.17487/RFC5966, August 810 2010, . 812 [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", 813 RFC 6304, DOI 10.17487/RFC6304, July 2011, 814 . 816 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 817 DOI 10.17487/RFC6762, February 2013, 818 . 820 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 821 for DNS (EDNS(0))", STD 75, RFC 6891, 822 DOI 10.17487/RFC6891, April 2013, 823 . 825 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 826 "Architectural Considerations on Application Features in 827 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, 828 . 830 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 831 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 832 . 834 [RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS", 835 RFC 7477, DOI 10.17487/RFC7477, March 2015, 836 . 838 [RFC7720] Blanchet, M. and L-J. Liman, "DNS Root Name Service 839 Protocol and Deployment Requirements", BCP 40, RFC 7720, 840 DOI 10.17487/RFC7720, December 2015, 841 . 843 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 844 D. Wessels, "DNS Transport over TCP - Implementation 845 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 846 . 848 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 849 edns-tcp-keepalive EDNS0 Option", RFC 7828, 850 DOI 10.17487/RFC7828, April 2016, 851 . 853 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 854 and P. Hoffman, "Specification for DNS over Transport 855 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 856 2016, . 858 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 859 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 860 . 862 [RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, 863 DOI 10.17487/RFC7901, June 2016, 864 . 866 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 867 Layer Security (TLS) False Start", RFC 7918, 868 DOI 10.17487/RFC7918, August 2016, 869 . 871 [RFC8027] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy, 872 "DNSSEC Roadblock Avoidance", BCP 207, RFC 8027, 873 DOI 10.17487/RFC8027, November 2016, 874 . 876 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 877 Transport Layer Security (DTLS)", RFC 8094, 878 DOI 10.17487/RFC8094, February 2017, 879 . 881 [RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to 882 Associate Certificates with Domain Names for S/MIME", 883 RFC 8162, DOI 10.17487/RFC8162, May 2017, 884 . 886 [RFC8324] Klensin, J., "DNS Privacy, Authorization, Special Uses, 887 Encoding, Characters, Matching, and Root Structure: Time 888 for Another Look?", RFC 8324, DOI 10.17487/RFC8324, 889 February 2018, . 891 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 892 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 893 October 2018, . 895 [RFC8483] Song, L., Ed., Liu, D., Vixie, P., Kato, A., and S. Kerr, 896 "Yeti DNS Testbed", RFC 8483, DOI 10.17487/RFC8483, 897 October 2018, . 899 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 900 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 901 . 903 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 904 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 905 RFC 8490, DOI 10.17487/RFC8490, March 2019, 906 . 908 [RFC8501] Howard, L., "Reverse DNS in IPv6 for Internet Service 909 Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018, 910 . 912 [ROLL_YOUR_ROOT] 913 Mueller, M., Thomas, M., Wessels, D., Hardaker, W., Chung, 914 T., Toorop, W., and R. Rijswijk-Deij, "Roll, Roll, Roll 915 Your Root: A Comprehensive Analysis of the First Ever 916 DNSSEC Root KSK Rollover", Oct 2019, . 918 [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting 919 (DNS RRL)", ISC-TN 2012-1 Draft1, April 2012. 921 [Stevens] Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network 922 Programming Volume 1, Third Edition: The Sockets 923 Networking API", November 2003. 925 [TDNS] Zhu, L., Heidemann, J., Wessels, D., Mankin, A., and N. 926 Somaiya, "Connection-oriented DNS to Improve Privacy and 927 Security", 2015. 929 [TOYAMA] Toyama, K., Ishibashi, K., Ishino, M., Yoshimura, C., and 930 K. Fujiwara, "DNS Anomalies and Their Impacts on DNS Cache 931 Servers", NANOG 32 Reston, VA USA, 2004. 933 [VERISIGN] 934 Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in 935 Root Server DITL Data", DNS-OARC 2014 Fall Workshop Los 936 Angeles, 2014. 938 [WIKIPEDIA_TFO] 939 Wikipedia, "TCP Fast Open", May 2018, 940 . 942 Appendix A. Standards Related to DNS Transport over TCP 944 This section enumerates all known IETF RFC documents that are 945 currently of status standard, informational, best common practice, or 946 experimental and either implicitly or explicitly make assumptions or 947 statements about the use of TCP as a transport for the DNS germane to 948 this document. 950 A.1. IETF RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION 952 The internet standard [RFC1035] is the base DNS specification that 953 explicitly defines support for DNS over TCP. 955 A.2. IETF RFC 1536 - Common DNS Implementation Errors and Suggested 956 Fixes 958 The informational document [RFC1536] states UDP is the "chosen 959 protocol for communication though TCP is used for zone transfers." 960 That statement should now be considered in its historical context and 961 is no longer a proper reflection of modern expectations. 963 A.3. IETF RFC 1995 - Incremental Zone Transfer in DNS 965 The [RFC1995] standards track document documents the use of TCP as 966 the fallback transport when IXFR responses do not fit into a single 967 UDP response. As with AXFR, IXFR messages are typically delivered 968 over TCP by default in practice. 970 A.4. IETF RFC 1996 - A Mechanism for Prompt Notification of Zone 971 Changes (DNS NOTIFY) 973 The [RFC1996] standards track document suggests a master server may 974 decide to issue NOTIFY messages over TCP. In practice, NOTIFY 975 messages are generally sent over UDP, but this specification leaves 976 open the possibility that the choice of transport protocol is up to 977 the master server, and therefore a slave server ought to be able to 978 operate over both UDP and TCP. 980 A.5. IETF RFC 2181 - Clarifications to the DNS Specification 982 The [RFC2181] standards track document includes clarifying text on 983 how a client should react to the TC bit set on responses. It is 984 advised that the response should be discarded and the query resent 985 using TCP. 987 A.6. IETF RFC 2694 - DNS extensions to Network Address Translators 988 (DNS_ALG) 990 The informational document [RFC2694] enumerates considerations for 991 network address translation (NAT) devices to properly handle DNS 992 traffic. This document is noteworthy in its suggestion that 993 "[t]ypically, TCP is used for AXFR requests," as further evidence 994 that helps explain why DNS over TCP may often have been treated very 995 differently than DNS over UDP in operational networks. 997 A.7. IETF RFC 3225 - Indicating Resolver Support of DNSSEC 999 The [RFC3225] standards track document makes statements indicating 1000 DNS over TCP is "detrimental" as a result of increased traffic, 1001 latency, and server load. This document is a companion to the next 1002 document in the RFC series expressing the requirement for EDNS0 1003 support for DNSSEC. 1005 A.8. IETF RFC 3326 - DNSSEC and IPv6 A6 aware server/resolver message 1006 size requirements 1008 Although updated by later DNSSEC RFCs, the standards track document 1009 [RFC3226] strongly argued in favor of UDP messages over TCP largely 1010 for performance reasons. The document declares EDNS0 a requirement 1011 for DNSSEC servers and advocated packet fragmentation may be 1012 preferable to TCP in certain situations. 1014 A.9. IETF RFC 4472 - Operational Considerations and Issues with IPv6 1015 DNS 1017 This informational document [RFC4472] notes that IPv6 data may 1018 increase DNS responses beyond what would fit in a UDP message. 1019 Particularly noteworthy, perhaps less common today then when this 1020 document was written, it refers to implementations that truncate data 1021 without setting the TC bit to encourage the client to resend the 1022 query using TCP. 1024 A.10. IETF RFC 5452 - Measures for Making DNS More Resilient against 1025 Forged Answers 1027 This informational document [RFC5452] arose as public DNS systems 1028 began to experience widespread abuse from spoofed queries, resulting 1029 in amplification and reflection attacks against unwitting victims. 1030 One of the leading justifications for supporting DNS over TCP to 1031 thwart these attacks is briefly described in this document's 9.3 1032 Spoof Detection and Countermeasure section. 1034 A.11. IETF RFC 5507 - Design Choices When Expanding the DNS 1036 This informational document [RFC5507] was largely an attempt to 1037 dissuade new DNS data types from overloading the TXT resource record 1038 type. In so doing it summarizes the conventional wisdom of DNS 1039 design and implementation practices. The authors suggest TCP 1040 overhead and stateful properties pose challenges compared to UDP, and 1041 imply that UDP is generally preferred for performance and robustness. 1043 A.12. IETF RFC 5625 - DNS Proxy Implementation Guidelines 1045 This best current practice document [RFC5625] provides DNS proxy 1046 implementation guidance including the mandate that a proxy "MUST 1047 [...] be prepared to receive and forward queries over TCP" even 1048 though it suggests historically TCP transport has not been strictly 1049 mandatory in stub resolvers or recursive servers. 1051 A.13. IETF RFC 5936 - DNS Zone Transfer Protocol (AXFR) 1053 The [RFC5936] standards track document provides a detailed 1054 specification for the zone transfer protocol, as originally outlined 1055 in the early DNS standards. AXFR operation is limited to TCP and not 1056 specified for UDP. This document discusses TCP usage at length. 1058 A.14. IETF RFC 5966 - DNS Transport over TCP - Implementation 1059 Requirements 1061 This standards track document [RFC5966] instructs DNS implementers to 1062 provide support for carrying DNS over TCP messages in their software. 1063 The authors explicitly make no recommendations to operators, which we 1064 seek to address here. 1066 A.15. IETF RFC 6304 - AS112 Nameserver Operations 1068 [RFC6304] is an informational document enumerating the requirements 1069 for operation of AS112 project DNS servers. New AS112 nodes are 1070 tested for their ability to provide service on both UDP and TCP 1071 transports, with the implication that TCP service is an expected part 1072 of normal operations. 1074 A.16. IETF RFC 6762 - Multicast DNS 1076 In this standards track document [RFC6762], the TC bit is deemed to 1077 have essentially the same meaning as described in the original DNS 1078 specifications. That is, if a response with the TCP bit set is 1079 received, "[...] the querier SHOULD reissue its query using TCP in 1080 order to receive the larger response." 1082 A.17. IETF RFC 6891 - Extension Mechanisms for DNS (EDNS(0)) 1084 This standards track document [RFC6891] helped slow the use of and 1085 need for DNS over TCP messages. This document highlights concerns 1086 over server load and scalability in widespread use of DNS over TCP. 1088 A.18. IETF RFC 6950 - Architectural Considerations on Application 1089 Features in the DNS 1091 An informational document [RFC6950] that draws attention to large 1092 data in the DNS. TCP is referenced in the context as a common 1093 fallback mechanism and counter to some spoofing attacks. 1095 A.19. IETF RFC 7477 - Child-to-Parent Synchronization in DNS 1097 This standards track document [RFC7477] specifies a RRType and 1098 protocol to signal and synchronize NS, A, and AAAA resource record 1099 changes from a child to parent zone. Since this protocol may require 1100 multiple requests and responses, it recommends utilizing DNS over TCP 1101 to ensure the conversation takes place between a consistent pair of 1102 end nodes. 1104 A.20. IETF RFC 7720 - DNS Root Name Service Protocol and Deployment 1105 Requirements 1107 This best current practice [RFC7720] declares root name service "MUST 1108 support UDP [RFC768] and TCP [RFC793] transport of DNS queries and 1109 responses." 1111 A.21. IETF RFC 7766 - DNS Transport over TCP - Implementation 1112 Requirements 1114 The standards track document [RFC7766] might be considered the direct 1115 ancestor of this operational requirements document. The 1116 implementation requirements document codifies mandatory support for 1117 DNS over TCP in compliant DNS software. 1119 A.22. IETF RFC 7828 - The edns-tcp-keepalive EDNS0 Option 1121 This standards track document [RFC7828] defines an EDNS0 option to 1122 negotiate an idle timeout value for long-lived DNS over TCP 1123 connections. Consequently, this document is only applicable and 1124 relevant to DNS over TCP sessions and between implementations that 1125 support this option. 1127 A.23. IETF RFC 7858 - Specification for DNS over Transport Layer 1128 Security (TLS) 1130 This standards track document [RFC7858] defines a method for putting 1131 DNS messages into a TCP-based encrypted channel using TLS. This 1132 specification is noteworthy for explicitly targeting the stub-to- 1133 recursive traffic, but does not preclude its application from 1134 recursive-to-authoritative traffic. 1136 A.24. IETF RFC 7873 - Domain Name System (DNS) Cookies 1138 This standards track document [RFC7873] describes an EDNS0 option to 1139 provide additional protection against query and answer forgery. This 1140 specification mentions DNS over TCP as a reasonable fallback 1141 mechanism when DNS Cookies are not available. The specification does 1142 make mention of DNS over TCP processing in two specific situations. 1144 In one, when a server receives only a client cookie in a request, the 1145 server should consider whether the request arrived over TCP and if 1146 so, it should consider accepting TCP as sufficient to authenticate 1147 the request and respond accordingly. In another, when a client 1148 receives a BADCOOKIE reply using a fresh server cookie, the client 1149 should retry using TCP as the transport. 1151 A.25. IETF RFC 7901 - CHAIN Query Requests in DNS 1153 This experimental specification [RFC7901] describes an EDNS0 option 1154 that can be used by a security-aware validating resolver to request 1155 and obtain a complete DNSSEC validation path for any single query. 1156 This document requires the use of DNS over TCP or a source IP address 1157 verified transport mechanism such as EDNS-COOKIE [RFC7873]. 1159 A.26. IETF RFC 8027 - DNSSEC Roadblock Avoidance 1161 This document [RFC8027] details observed problems with DNSSEC 1162 deployment and mitigation techniques. Network traffic blocking and 1163 restrictions, including DNS over TCP messages, are highlighted as one 1164 reason for DNSSEC deployment issues. While this document suggests 1165 these sorts of problems are due to "non-compliant infrastructure" and 1166 is of type BCP, the scope of the document is limited to detection and 1167 mitigation techniques to avoid so-called DNSSEC roadblocks. 1169 A.27. IETF RFC 8094 - DNS over Datagram Transport Layer Security (DTLS) 1171 This experimental specification [RFC8094] details a protocol that 1172 uses a datagram transport (UDP), but stipulates that "DNS clients and 1173 servers that implement DNS over DTLS MUST also implement DNS over TLS 1174 in order to provide privacy for clients that desire Strict Privacy 1175 [...]." This requirement implies DNS over TCP must be supported in 1176 case the message size is larger than the path MTU. 1178 A.28. IETF RFC 8162 - Using Secure DNS to Associate Certificates with 1179 Domain Names for S/MIME 1181 This experimental specification [RFC8162] describes a technique to 1182 authenticate user X.509 certificates in an S/MIME system via the DNS. 1183 The document points out that the new experimental resource record 1184 types are expected to carry large payloads, resulting in the 1185 suggestion that "applications SHOULD use TCP -- not UDP -- to perform 1186 queries for the SMIMEA resource record." 1188 A.29. IETF RFC 8324 - DNS Privacy, Authorization, Special Uses, 1189 Encoding, Characters, Matching, and Root Structure: Time for 1190 Another Look? 1192 An informational document [RFC8324] that briefly discusses the common 1193 role and challenges of DNS over TCP throughout the history of DNS. 1195 A.30. IETF RFC 8467 - Padding Policies for Extension Mechanisms for DNS 1196 (EDNS(0)) 1198 An experimental document [RFC8467] reminds implementers to consider 1199 the underlying transport protocol (e.g. TCP) when calculating the 1200 padding length when artificially increasing the DNS message size with 1201 an EDNS(0) padding option. 1203 A.31. IETF RFC 8483 - Yeti DNS Testbed 1205 This informational document [RFC8483] describes a testbed environment 1206 that highlights some DNS over TCP behaviors, including issues 1207 involving packet fragmentation and operational requirements for TCP 1208 stream assembly in order to conduct DNS measurement and analysis. 1210 A.32. IETF RFC 8484 - DNS Queries over HTTPS (DoH) 1212 This standards track document [RFC8484] defines a protocol for 1213 sending DNS queries and responses over HTTPS. This specification 1214 assumes TLS and TCP for the underlying security and transport layers, 1215 respectively. Self-described as a a technique that more closely 1216 resembles a tunneling mechanism, DoH nevertheless likely implies DNS 1217 over TCP in some sense, if not directly. 1219 A.33. IETF RFC 8490 - DNS Stateful Operations 1221 This standards track document [RFC8490] updates the base protocol 1222 specification with a new OPCODE to help manage stateful operations in 1223 persistent sessions, such as those that might be used by DNS over 1224 TCP. 1226 A.34. IETF RFC 8501 - Reverse DNS in IPv6 for Internet Service 1227 Providers 1229 This informational document [RFC8501] identifies potential 1230 operational challenges with Dynamic DNS including denial-of-service 1231 threats. The document suggests TCP may provide some advantages, but 1232 that updating hosts would need to be explicitly configured to use TCP 1233 instead of UDP. 1235 Authors' Addresses 1237 John Kristoff 1238 DePaul University 1239 Chicago, IL 60604 1240 US 1242 Phone: +1 312 493 0305 1243 Email: jtk@depaul.edu 1244 URI: https://aharp.iorc.depaul.edu 1246 Duane Wessels 1247 Verisign 1248 12061 Bluemont Way 1249 Reston, VA 20190 1250 US 1252 Phone: +1 703 948 3200 1253 Email: dwessels@verisign.com 1254 URI: http://verisigninc.com