idnits 2.17.00 (12 Aug 2021) /tmp/idnits6511/draft-kristoff-dnsop-dns-tcp-requirements-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 25, 2016) is 2094 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) -- Obsolete informational reference (is this intentional?): RFC 2541 (Obsoleted by RFC 4641) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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 Intended status: Best Current Practice August 25, 2016 5 Expires: February 26, 2017 7 DNS Transport over TCP - Operational Requirements 8 draft-kristoff-dnsop-dns-tcp-requirements-01 10 Abstract 12 This document encourages the practice of permitting DNS messages to 13 be carried over TCP on the Internet. It also describes some of the 14 consequences of this behavior and the potential operational issues 15 that can arise when this best common practice is not applied. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on February 26, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2.1. Uneven Transport Usage and Preference . . . . . . . . . . 2 55 2.2. Waiting for Large Messages and Reliability . . . . . . . 3 56 2.3. EDNS0 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. DNS over TCP Requirements . . . . . . . . . . . . . . . . . . 4 58 4. DNS over TCP Filtering Risks . . . . . . . . . . . . . . . . 5 59 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 8.2. Informative References . . . . . . . . . . . . . . . . . 6 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 DNS messages may be delivered using UDP or TCP communications. While 70 most DNS transactions are carried over UDP, some operators have been 71 led to believe that any DNS over TCP traffic is unwanted or 72 unnecessary for general DNS operation. As usage and features have 73 evolved, TCP transport has become increasingly important for correct 74 and safe operation of the Internet DNS. Reflecting modern usage, the 75 DNS standards were recently updated to declare support for TCP is now 76 a required part of the DNS implementation specifications in 77 [RFC7766]. This document is the formal requirements equivalent for 78 the operational community, encouraging operators to ensure DNS over 79 TCP communications support in on par with DNS over UDP 80 communications. 82 1.1. Requirements Language 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [RFC2119]. 88 2. Background 90 2.1. Uneven Transport Usage and Preference 92 In the original suite of DNS specifications, [RFC1034] and [RFC1035] 93 clearly specified that DNS messages could be carried in either UDP or 94 TCP, but they also made clear a preference for UDP as the transport 95 for queries in the general case. As stated in [RFC1035]: 97 "While virtual circuits can be used for any DNS activity, 98 datagrams are preferred for queries due to their lower overhead 99 and better performance." 101 Another early, important, and influential document, [RFC1123], 102 detailed the preference for UDP more explicitly: 104 "DNS resolvers and recursive servers MUST support UDP, and SHOULD 105 support TCP, for sending (non-zone-transfer) queries." 107 and further stipulated: 109 A name server MAY limit the resources it devotes to TCP queries, 110 but it SHOULD NOT refuse to service a TCP query just because it 111 would have succeeded with UDP. 113 Culminating in [RFC1536], DNS over TCP came to be associated 114 primarily with the zone transfer mechanism, while most DNS queries 115 and responses were seen as the dominion of UDP. 117 2.2. Waiting for Large Messages and Reliability 119 As stipulated in the original specifications, DNS messages over UDP 120 were restricted to a 512-byte message size. However, even while 121 [RFC1123] made a clear preference for UDP, it foresaw DNS over TCP 122 becoming more popular in the future: 124 "[...] it is also clear that some new DNS record types defined in 125 the future will contain information exceeding the 512 byte limit 126 that applies to UDP, and hence will require TCP. 128 At least two new, widely anticipated developments were set to elevate 129 the need for DNS over TCP transactions. The first was dynamic 130 updates defined in [RFC2136] and the second was the set of extensions 131 collectively known as DNSSEC originally specified in [RFC2541]. The 132 former suggested "requestors who require an accurate response code 133 must use TCP", while the later warned "[...] larger keys increase the 134 size of KEY and SIG RRs. This increases the chance of DNS UDP packet 135 overflow and the possible necessity for using higher overhead TCP in 136 responses." 138 Yet defying some expectations, DNS over TCP remained little used in 139 real traffic across the Internet. Dynamic updates saw little 140 deployment between autonomous networks. Around the time DNSSEC was 141 first defined, another new feature affecting DNS over UDP helped 142 solidify its dominance for message transactions. 144 2.3. EDNS0 146 In 1999 the IETF published the Extension Mechanisms for DNS (EDNS0) 147 in [RFC2671]. This document standardized a way for communicating DNS 148 nodes to perform rudimentary capabilities negotiation. One such 149 capability written into the base specification and present in every 150 ENDS0 compatible message is the value of the maximum UDP payload size 151 the sender can support. This unsigned 16-bit field specifies in 152 bytes the maximum DNS MTU. In practice, typical values are a subset 153 of the 512 to 4096 byte range. EDNS0 was rapidly and widely deployed 154 over the next several years and numerous surveys have shown many 155 systems currently support larger UDP MTUs [CASTRO2010], [NETALYZR] 156 with EDNS0. 158 The natural effect of EDNS0 deployment meant large DNS messages would 159 be less reliant on TCP than they might otherwise have been. While a 160 nonneglible population of DNS systems lack EDNS0 or may still fall 161 back to TCP for some transactions, DNS over TCP transactions remain a 162 very small fraction of overall DNS traffic [VERISIGN]. Nevertheless, 163 some average increase in DNS message size, the continued development 164 of new DNS features and a denial of service mitigation technique (see 165 Section 7) have suggested that DNS over TCP transactions are as 166 important to the correct and safe operation of the Internet DNS as 167 ever, if not more so. Furthermore, there has been serious research 168 that has suggested connection-oriented DNS transactions may provide 169 security and privacy advantages over UDP transport [TDNS]. 170 Therefore, it might be desirable for network operators to avoid 171 artificially inhibiting the potential utility and advances in the DNS 172 such as these. 174 3. DNS over TCP Requirements 176 Even while many in the DNS community expect DNS over TCP transactions 177 to occur without interference, in practice there has been a long held 178 belief by some operators, particularly for security-related reasons, 179 to the contrary [CHES94], [DJBDNS]. A popular meme has also held the 180 imagination of some that DNS over TCP is only ever used for zone 181 transfers and is generally unnecessary otherwise, with filtering all 182 DNS over TCP traffic even described as a best practice. Arguably any 183 exposed Internet service poses some risk, but these beliefs are often 184 invalid. DNS over TCP filtering is considered harmful in the general 185 case. DNS resolver and server operators MUST provide DNS service 186 over both UDP and TCP transports. Likewise, network operators MUST 187 allow DNS service over both UDP and TCP transports. 189 4. DNS over TCP Filtering Risks 191 Networks that filter DNS over TCP may inadvertently cause problems 192 for third party resolvers as experienced by [TOYAMA]. If for 193 instance a resolver receives a truncated answer from a server, but if 194 when the resolver resends the query using TCP and the TCP response 195 never arrives, the resolver will incur the full extent of TCP 196 retransmissions and time outs. 198 Networks that filter DNS over TCP risk losing access to significant 199 or important pieces of the DNS name space. For a variety of reasons 200 a DNS answer may require a DNS over TCP query. This may include 201 large message sizes, lack of EDNS0 support, DDoS mitigation 202 techniques, or perhaps some future capability that is as yet 203 unforeseen will also demand TCP transport. 205 Even if any or all particular answers have consistently been returned 206 successfuly with UDP in the past, this continued behavior cannot be 207 guaranteed when DNS messages are exchanged between autonomous 208 systems. Therefore, filtering of DNS over TCP is considered harmful 209 and contrary to the safe and successful operation of the Internet. 211 5. Acknowledgements 213 This document was initially motivated by feedback from students who 214 pointed out that they were hearing contradictory information about 215 filtering DNS over TCP messages. Thanks in particular to my teaching 216 colleague, JPL, who perhaps unknowingly encouraged the initial 217 research into the differences of what the IETF community has 218 historically said and did. Thanks to all the NANOG 63 attendees who 219 provided feedback to an early talk on this subject. 221 6. IANA Considerations 223 This memo includes no request to IANA. 225 7. Security Considerations 227 Ironically, returning truncated DNS over UDP answers in order to 228 induce a client query to switch to DNS over TCP has become a common 229 response to source address spoofed, DNS denial-of-service attacks 230 [RRL]. Historically, operators have been wary of TCP-based attacks, 231 but in recent years, UDP-based flooding attacks have proven to be the 232 most common protocol attack on the DNS. Nevertheless, a high rate of 233 short-lived DNS transactions over TCP may pose challenges. While 234 many operators have provided DNS over TCP service for many years 235 without duress, past experience is no guarantee of future success. 237 DNS over TCP is not unlike many other Internet TCP services. TCP 238 threats and many mitigation strategies have been well documented in 239 series of documents such as [RFC4953], [RFC4987], [RFC5927], and 240 [RFC5961]. 242 8. References 244 8.1. Normative References 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, 248 DOI 10.17487/RFC2119, March 1997, 249 . 251 8.2. Informative References 253 [CASTRO2010] 254 Castro, S., Zhang, M., John, W., Wessels, D., and k. 255 claffy, "Understanding and preparing for DNS evolution", 256 2010. 258 [CHES94] Cheswick, W. and S. Bellovin, "Firewalls and Internet 259 Security: Repelling the Wily Hacker", 1994. 261 [DJBDNS] D.J. Bernstein, "When are TCP queries sent?", 2002, 262 . 264 [NETALYZR] 265 Kreibich, C., Weaver, N., Nechaev, B., and V. Paxson, 266 "Netalyzr: Illuminating The Edge Network", 2010. 268 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 269 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 270 . 272 [RFC1035] Mockapetris, P., "Domain names - implementation and 273 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 274 November 1987, . 276 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 277 Application and Support", STD 3, RFC 1123, 278 DOI 10.17487/RFC1123, October 1989, 279 . 281 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 282 Miller, "Common DNS Implementation Errors and Suggested 283 Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993, 284 . 286 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 287 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 288 RFC 2136, DOI 10.17487/RFC2136, April 1997, 289 . 291 [RFC2541] Eastlake 3rd, D., "DNS Security Operational 292 Considerations", RFC 2541, DOI 10.17487/RFC2541, March 293 1999, . 295 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 296 RFC 2671, DOI 10.17487/RFC2671, August 1999, 297 . 299 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 300 RFC 4953, DOI 10.17487/RFC4953, July 2007, 301 . 303 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 304 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 305 . 307 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 308 DOI 10.17487/RFC5927, July 2010, 309 . 311 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 312 Robustness to Blind In-Window Attacks", RFC 5961, 313 DOI 10.17487/RFC5961, August 2010, 314 . 316 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 317 D. Wessels, "DNS Transport over TCP - Implementation 318 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 319 . 321 [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting 322 (DNS RRL)", ISC-TN 2012-1 Draft1, April 2012. 324 [TDNS] Zhu, L., Heidemann, J., Wessels, D., Mankin, A., and N. 325 Somaiya, "Connection-oriented DNS to Improve Privacy and 326 Security", 2015. 328 [TOYAMA] Toyama, K., Ishibashi, K., Ishino, M., Yoshimura, C., and 329 K. Fujiwara, "DNS Anomalies and Their Impacts on DNS Cache 330 Servers", NANOG 32 Reston, VA USA, 2004. 332 [VERISIGN] 333 Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in 334 Root Server DITL Data", DNS-OARC 2014 Fall Workshop Los 335 Angeles, 2014. 337 Author's Address 339 John Kristoff 340 DePaul University 341 Chicago, IL 342 US 344 Phone: +1 312 493 0305 345 Email: jtk@depaul.edu