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