idnits 2.17.00 (12 Aug 2021) /tmp/idnits4326/draft-kristoff-dnsop-dns-tcp-requirements-00.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 (March 11, 2016) is 2261 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 Team Cymru 4 Intended status: Best Current Practice March 11, 2016 5 Expires: September 12, 2016 7 DNS Transport over TCP - Operational Requirements 8 draft-kristoff-dnsop-dns-tcp-requirements-00 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 September 12, 2016. 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 63 7.2. Informative References . . . . . . . . . . . . . . . . . 5 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 DNS messages may be delivered using UDP or TCP communications. While 69 most DNS transactions are carried over UDP, some operators have been 70 led to believe that any DNS over TCP traffic is unwanted or 71 unnecessary for general DNS operation. As DNS usage has evolved, DNS 72 over TCP has become increasingly important for correct and safe 73 operation of the Internet DNS. Reflecting modern usage, the DNS 74 standards were recently updated to declare support for TCP is now a 75 required part of the DNS implementation specifications in [RFC7766]. 76 This document is the formal requirements equivalent for the 77 operational community, encouraging operators to ensure DNS over TCP 78 communications support in on par with DNS over UDP communications. 80 1.1. Requirements Language 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 2. Background 88 2.1. Uneven Transport Usage and Preference 90 In the original suite of DNS specifications, [RFC1034] and [RFC1035] 91 clearly specified that DNS messages could be carried in either UDP or 92 TCP, but they also made clear a preference for UDP as the transport 93 for queries in the general case. As stated in [RFC1035]: 95 "While virtual circuits can be used for any DNS activity, 96 datagrams are preferred for queries due to their lower overhead 97 and better performance." 99 Another early, important and influential document, [RFC1123], 100 detailed the preference for UDP more explicitly: 102 "DNS resolvers and recursive servers MUST support UDP, and SHOULD 103 support TCP, for sending (non-zone-transfer) queries." 105 and further stipulated: 107 A name server MAY limit the resources it devotes to TCP queries, 108 but it SHOULD NOT refuse to service a TCP query just because it 109 would have succeeded with UDP. 111 Culminating in [RFC1536], DNS over TCP came to be associated 112 primarily with the zone transfer mechanism, while most DNS queries 113 and responses were seen as the dominion of UDP. 115 2.2. Waiting for Large Messages and Reliability 117 As stipulated in the original specifications, DNS messages over UDP 118 were restricted to a 512-byte message size. However, even while 119 [RFC1123] made a clear preference for UDP, it foresaw DNS over TCP 120 becoming more popular in the future: 122 "[...] it is also clear that some new DNS record types defined in 123 the future will contain information exceeding the 512 byte limit 124 that applies to UDP, and hence will require TCP. 126 At least two new, widely anticipated developments were set to elevate 127 the need for DNS over TCP transactions. The first was dynamic 128 updates defined in [RFC2136] and the second was the set of extensions 129 collectively known as DNSSEC originally specified in [RFC2541]. The 130 former suggested "requestors who require an accurate response code 131 must use TCP", while the later warned "[...] larger keys increase the 132 size of KEY and SIG RRs. This increases the chance of DNS UDP packet 133 overflow and the possible necessity for using higher overhead TCP in 134 responses." 136 Yet defying some expectations, DNS over TCP remained little used in 137 real traffic across the Internet. Dynamic updates saw little 138 deployment between autonomous networks. Around the time DNSSEC was 139 first defined, another new feature affecting DNS over UDP helped 140 solidify its dominance for message transactions. 142 2.3. EDNS0 144 In 1999 the IETF published the Extension Mechanisms for DNS (EDNS0) 145 in [RFC2671]. This document standardized a way for communicating DNS 146 nodes to perform rudimentary capabilities negotiation. One such 147 capability written into the base specification and present in every 148 ENDS0 compatible message is the value of the maximum UDP payload size 149 the sender can support. This unsigned 16-bit field specifies in 150 bytes the maximum DNS MTU. In practice, typical values are from a 151 subset of ranges between 512 to 4096 bytes inclusive. EDNS0 was 152 rapidly and widely deployed over the next several years and numerous 153 surveys have shown many systems currently support larger UDP MTUs 154 [CASTRO2010], [NETALYZR] with EDNS0. 156 The natural effect of EDNS0 deployment meant large DNS messages would 157 be less reliant on TCP than they might otherwise have been. While a 158 nonneglible population of DNS systems lack EDNS0 or may still fall 159 back to TCP for some transactions, DNS over TCP transactions remain a 160 very small fraction of overall DNS traffic [VERISIGN]. Nevertheless, 161 some average increase in DNS message size, the continued development 162 of new DNS features and a denial of service mitigation technique (see 163 Section 6) have suggested that DNS over TCP transactions are as 164 important to the correct and safe operation of the Internet DNS as 165 ever, if not more so. Furthermore, there has been serious research 166 that has suggested connection-oriented DNS transactions may provide 167 security and privacy advantages over UDP transport [TDNS]. It might 168 be desirable for network operators to avoid artificially inhibiting 169 potential utility and advances in the DNS such as these. 171 3. DNS over TCP Requirements 173 Even while many in the DNS community expect DNS over TCP transactions 174 to occur without interference, in practice there has been a long held 175 belief by some operators, particularly for security-related reasons, 176 to the contrary [CHES94], [DJBDNS]. A popular meme has also held the 177 imagination of some that DNS over TCP is only ever used for zone 178 transfers and is generally unnecessary otherwise, with filtering any 179 DNS over TCP traffic even described as a best practice. Arguably any 180 exposed Internet service poses some risk, but these beliefs are often 181 invalid. DNS over TCP filtering is considered harmful in the general 182 case. DNS resolver and server operators MUST provide DNS service 183 over both UDP and TCP transports. 185 4. Acknowledgements 187 This document was initially motivated by feedback from students who 188 pointed out that they were hearing contradictory information about 189 filtering DNS over TCP messages. Thanks in particular to my teaching 190 colleague, JPL, who perhaps unknowingly encouraged the initial 191 research into to differences of what the IETF community has 192 historically said and did. Thanks to all the NANOG 63 attendees who 193 provided feedback to an early talk on this subject. 195 5. IANA Considerations 197 This memo includes no request to IANA. 199 6. Security Considerations 201 Ironically, returning truncated DNS over UDP answers in order to 202 induce a client query to switch to DNS over TCP has become a common 203 response to source address spoofed, DNS denial-of-service attacks 204 [RRL]. Historically, operators have been wary of TCP-based attacks, 205 but in recent years, UDP-based flooding attacks have proven to be the 206 most common protocol attack on the DNS. Nevertheless, a high rate of 207 short-lived DNS transactions over TCP may pose challenges. While 208 many operators have provided DNS over TCP service for many years 209 without duress, past experience is no guarantee of future success. 211 DNS over TCP is not unlike many other Internet TCP services. TCP 212 threats and many mitigation strategies have been well documented in 213 series of documents such as [RFC4953], [RFC4987], [RFC5927], and 214 [RFC5961]. 216 Networks that filter DNS over TCP may inadvertently cause problems 217 for third party resolvers as experienced by [TOYAMA]. If for 218 instance a resolver receives a truncated answer from a server, but if 219 when the resolver resends the query using TCP and the TCP response 220 never arrives, the resolver will incur the full extent of TCP 221 retransmissions and time outs. 223 7. References 225 7.1. Normative References 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, 229 DOI 10.17487/RFC2119, March 1997, 230 . 232 7.2. Informative References 234 [CASTRO2010] 235 Castro, S., Zhang, M., John, W., Wessels, D., and k. 236 claffy, "Understanding and preparing for DNS evolution", 237 2010. 239 [CHES94] Cheswick, W. and S. Bellovin, "Firewalls and Internet 240 Security: Repelling the Wily Hacker", 1994. 242 [DJBDNS] D.J. Bernstein, "When are TCP queries sent?", 2002, 243 . 245 [NETALYZR] 246 Kreibich, C., Weaver, N., Nechaev, B., and V. Paxson, 247 "Netalyzr: Illuminating The Edge Network", 2010. 249 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 250 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 251 . 253 [RFC1035] Mockapetris, P., "Domain names - implementation and 254 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 255 November 1987, . 257 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 258 Application and Support", STD 3, RFC 1123, 259 DOI 10.17487/RFC1123, October 1989, 260 . 262 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 263 Miller, "Common DNS Implementation Errors and Suggested 264 Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993, 265 . 267 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 268 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 269 RFC 2136, DOI 10.17487/RFC2136, April 1997, 270 . 272 [RFC2541] Eastlake 3rd, D., "DNS Security Operational 273 Considerations", RFC 2541, DOI 10.17487/RFC2541, March 274 1999, . 276 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 277 RFC 2671, DOI 10.17487/RFC2671, August 1999, 278 . 280 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 281 RFC 4953, DOI 10.17487/RFC4953, July 2007, 282 . 284 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 285 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 286 . 288 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 289 DOI 10.17487/RFC5927, July 2010, 290 . 292 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 293 Robustness to Blind In-Window Attacks", RFC 5961, 294 DOI 10.17487/RFC5961, August 2010, 295 . 297 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 298 D. Wessels, "DNS Transport over TCP - Implementation 299 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 300 . 302 [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting 303 (DNS RRL)", ISC-TN 2012-1 Draft1, April 2012. 305 [TDNS] Zhu, L., Heidemann, J., Wessels, D., Mankin, A., and N. 306 Somaiya, "Connection-oriented DNS to Improve Privacy and 307 Security", 2015. 309 [TOYAMA] Toyama, K., Ishibashi, K., Ishino, M., Yoshimura, C., and 310 K. Fujiwara, "DNS Anomalies and Their Impacts on DNS Cache 311 Servers", NANOG 32 Reston, VA USA, 2004. 313 [VERISIGN] 314 Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in 315 Root Server DITL Data", DNS-OARC 2014 Fall Workshop Los 316 Angeles, 2014. 318 Author's Address 320 John Kristoff 321 Team Cymru 322 Chicago, IL 323 US 325 Phone: +1 312 493 0305 326 Email: jtk@cymru.com