idnits 2.17.1 draft-livingood-doh-implementation-risks-issues-04.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 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 16, 2019) is 1677 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 900 -- Looks like a reference, but probably isn't: '2' on line 902 -- Looks like a reference, but probably isn't: '3' on line 905 -- Looks like a reference, but probably isn't: '4' on line 908 -- Looks like a reference, but probably isn't: '5' on line 911 -- Looks like a reference, but probably isn't: '6' on line 914 -- Looks like a reference, but probably isn't: '7' on line 917 -- Looks like a reference, but probably isn't: '8' on line 920 -- Looks like a reference, but probably isn't: '9' on line 923 -- Looks like a reference, but probably isn't: '10' on line 927 -- Looks like a reference, but probably isn't: '11' on line 930 -- Looks like a reference, but probably isn't: '12' on line 933 -- Looks like a reference, but probably isn't: '13' on line 936 -- Looks like a reference, but probably isn't: '14' on line 939 -- Looks like a reference, but probably isn't: '15' on line 942 -- Looks like a reference, but probably isn't: '16' on line 944 -- Looks like a reference, but probably isn't: '17' on line 946 -- Looks like a reference, but probably isn't: '18' on line 949 -- Looks like a reference, but probably isn't: '19' on line 951 -- Looks like a reference, but probably isn't: '20' on line 954 -- Looks like a reference, but probably isn't: '21' on line 957 -- Looks like a reference, but probably isn't: '22' on line 959 -- Looks like a reference, but probably isn't: '23' on line 962 -- Looks like a reference, but probably isn't: '24' on line 965 -- Looks like a reference, but probably isn't: '25' on line 967 -- Looks like a reference, but probably isn't: '26' on line 970 -- Looks like a reference, but probably isn't: '27' on line 972 -- Looks like a reference, but probably isn't: '28' on line 974 -- Looks like a reference, but probably isn't: '29' on line 976 -- Looks like a reference, but probably isn't: '30' on line 979 -- Looks like a reference, but probably isn't: '31' on line 982 -- Looks like a reference, but probably isn't: '32' on line 985 -- Looks like a reference, but probably isn't: '33' on line 988 -- Looks like a reference, but probably isn't: '34' on line 992 -- Looks like a reference, but probably isn't: '35' on line 995 -- Looks like a reference, but probably isn't: '36' on line 997 -- Looks like a reference, but probably isn't: '37' on line 999 -- Looks like a reference, but probably isn't: '38' on line 1001 -- Looks like a reference, but probably isn't: '39' on line 1003 == Missing Reference: 'CITATIONS NEEDED' is mentioned on line 533, but not defined -- Looks like a reference, but probably isn't: '40' on line 1005 -- Looks like a reference, but probably isn't: '41' on line 1008 -- Looks like a reference, but probably isn't: '42' on line 1011 -- Looks like a reference, but probably isn't: '43' on line 1014 -- Looks like a reference, but probably isn't: '44' on line 1016 -- Looks like a reference, but probably isn't: '45' on line 1019 -- Looks like a reference, but probably isn't: '46' on line 1021 -- Looks like a reference, but probably isn't: '47' on line 1023 -- Looks like a reference, but probably isn't: '48' on line 1026 -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 50 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOH J. Livingood 3 Internet-Draft Comcast 4 Intended status: Informational M. Antonakakis 5 Expires: March 19, 2020 Georgia Institute of Technology 6 B. Sleigh 7 BT Plc 8 A. Winfield 9 Sky 10 September 16, 2019 12 Centralized DNS over HTTPS (DoH) Implementation Issues and Risks 13 draft-livingood-doh-implementation-risks-issues-04 15 Abstract 17 The DNS over HTTPS (DoH) protocol is specified in RFC8484. This 18 document considers Centralized DoH deployment, which seems one likely 19 way that DoH may be implemented, based on recent industry discussions 20 and testing. This describes that implementation model, as well the 21 potential associated risks and issues. The document also makes 22 recommendations pertaining to the implementation of DoH, as well as 23 recommendations for further study prior to widespread adoption. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 19, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Separating the Protocol from Implementation Issues . . . . . 2 61 3. Network Operators Are Interested in Deploying DoH . . . . . . 3 62 4. Centralized DoH Defined . . . . . . . . . . . . . . . . . . . 3 63 5. Centralization vs. De-Centralization of Services . . . . . . 4 64 6. Centralized DoH Assumption: Enabled/Centralized by Default . 5 65 7. Potential for Rapid Centralized DoH Adoption . . . . . . . . 5 66 8. Potential Technical Risks . . . . . . . . . . . . . . . . . . 6 67 9. Potential Business Risks . . . . . . . . . . . . . . . . . . 14 68 10. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 15 69 11. Document Reviewer Acknowlegedments . . . . . . . . . . . . . 18 70 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 71 13. Security Considerations . . . . . . . . . . . . . . . . . . . 19 72 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 73 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 15.1. Informative References . . . . . . . . . . . . . . . . . 19 75 15.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23 77 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 23 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 80 1. Introduction 82 The DNS over HTTPS (DoH) protocol is specified in [RFC8484]. This 83 document considers Centralized DoH deployment, which seems one likely 84 way that DoH may be implemented, based on recent industry discussions 85 and testing. This describes that implementation model, as well the 86 potential associated risks and issues. The document also makes 87 recommendations pertaining to the implementation of DoH, as well as 88 recommendations for further study prior to widespread adoption. 90 2. Separating the Protocol from Implementation Issues 92 This document is not intended as a critique of the DoH protocol 93 itself, which can be a valued addition to the Internet and appears to 94 have many helpful uses. Rather, this document focuses solely on how 95 DoH is now being implemented and/or might be implemented. Thus, in 96 no way should this document be read as critical of the DoH protocol 97 itself, which can bring positive benefits to end user privacy. 99 In addition, conventional DNS generally uses UDP port 53, though in 100 some cases TCP is used. DoH is still DNS but it uses an entirely 101 different protocol to send and receive queries. This document does 102 not delve into the particulars of the DoH protocol. For those 103 details, please refer to [RFC8484]. 105 3. Network Operators Are Interested in Deploying DoH 107 Network operators, ranging from ISPs to enterprises, schools, and 108 others work hard to provide outstanding DNS and network performance, 109 as well as to protect the security and privacy of users. In 110 addition, most also provide DNS-based services such as opt-in 111 parental controls for consumers or malware/security protection in 112 enterprises, content filtering in schools, etc. These operators are 113 also interested in adding support for DoH (as well as DNS over TLS, 114 DoT). However, the current Centralized DoH implementation model does 115 not appear to make it possible for these operators to continue to 116 play a value added role in the delivery of network services, or to 117 continue to provide DNS-related services, and may even cause problems 118 beyond that. 120 In addition, the DoH resolvers that network operators might provide 121 would likely not be open recursive resolvers but would instead mirror 122 the current model whereby the resolver has an access control list 123 (ACL) so that the servers only respond to clients on that network, 124 which helps to reduce abuse (see the Open Resolver Project) [1]. 125 This does not appear to be compatible with the current Centralized 126 DoH implementation model that appears to assume that DoH resolvers 127 are openly accessible from any network. 129 Finally, network operators also typically have a direct, trusted 130 relationship with users, often bound by legal agreements including 131 Terms of Service and a Privacy Policy. Depending upon the particular 132 country/region there are laws and regulations, such as the General 133 Data Protection Regulation (GDPR), that may also govern user privacy, 134 data collection, and data handling. All of those things would apply 135 to network operator DoH services as they do to conventional DNS 136 services. 138 4. Centralized DoH Defined 140 DoH clients have been implemented in a number of platforms, including 141 in the Mozilla Firefox web browser (see Mozilla blog) [2], and Google 142 Chrome (Chromium) web browser (see Google Public DNS Developer web 143 site) [3]. In deployments thus far, Mozilla has defaulted to 144 Cloudflare (see Mozilla blog) [4], and Google's Chrome browser have 145 used Google Public DNS (see Google Public DNS Developer web site) 146 [5]. 148 Since directing DoH-based DNS traffic to a small number of commercial 149 DNS providers represents a high degree of concentration and 150 centralization of operation and control, this document describes this 151 potential implementation model as "Centralized DoH". 153 5. Centralization vs. De-Centralization of Services 155 DNS is the most highly distributed global database on the Internet, 156 with millions of people and organizations independently changing and 157 adding to this database in a loosely coupled system. The web (HTTP/ 158 HTTPS) is also highly distributed, with countless parties creating 159 and publishing content on the web. Both the DNS and HTTP protocols 160 demonstrate the key architectural tenets of the Internet, such as 161 loose coupling between systems and layers, loose coordination between 162 different entities that use a particular protocol, and broadly de- 163 centralized distribution of the protocol and associated systems. 165 But over the past decade, there has been a trend of most web traffic 166 shifting towards a small number of very large web platforms. For 167 example in 2009, Craig Labovitz described the rise of the so-called 168 hyper-giants (see Arbor Networks report) [6], with 30 companies being 169 responsible for 30% of global traffic. A subsequent paper from 170 Harvard's Berkman Center [7] highlighted the security, independent 171 media, and human rights implications of this development as a result 172 of attacks against that small number of key platforms, among other 173 issues. Many others have measured, studied, and debated this trend 174 since 2009. A recent Sandvine paper [8] noted that Google's YouTube 175 comprised 35% of mobile Internet traffic, and Netfix comprised 13.75% 176 of global Internet traffic (see Sandvine blog) [9]. 178 This trend towards centralization onto a small number of large 179 platforms has given rise to efforts to "re-decentralize the web". 180 Proponents of the effort to resist and reverse the further 181 centralization of the web and the Internet more generally include Sir 182 Tim Berners-Lee (see Ars Technica article [10], Gizmodo article [11], 183 New York Times article [12]), Vint Cerf (see Archive.org blog [13]), 184 Brewster Kahle (see IEEE Spectrum article [14]), MIT's Digital 185 Currency Initiative [15], participants in the Decentralized Web 186 summit [16], and others. 188 In addition, IETF contributors are also considering the challenges 189 posed by consolidation, which in the DoH context is analogous to 190 Centralized DoH. For example, the Internet Architecture Board (IAB) 191 posted a draft entitled "Considerations on Internet Consolidation and 192 the Internet Architecture" [17] that delves into these issues, as 193 also noted on the IETF blog [18]. The Internet Society also 194 published their 2019 Global Internet Report on the Future of the 195 Internet [19] that is primarily focused on consolidation. 197 While traffic to certain destinations is increasingly concentrated, 198 at the same time the physical destinations (e.g. servers) are often 199 highly distributed by these platforms in order to deliver good 200 performance to users around the world. But while edge servers may 201 remain relatively physically distributed, their control, 202 administration, and operation is still centralized. But even if a 203 Centralized DoH provider's physical servers are highly distributed it 204 still would not come close to wide distribution of conventional DNS 205 today, which is typically distributed down to the network level, 206 ranging from a local region of an ISP's network (e.g. metropolitan 207 London area) to a small business' local area network (LAN), 208 enterprise network, school LAN, etc. 210 There are many potential implications to increased centralization and 211 consolidation of the DNS. These can include technical, business, and 212 other implications and risks that are explored later in this document 213 in Section 8 and Section 9. 215 6. Centralized DoH Assumption: Enabled/Centralized by Default 217 This document assumes a potential Centralized DoH environment where a 218 few large scale implementers have enabled DoH by default. This means 219 that there are assumed to be a small number of Centralized DoH 220 providers, rather than a large number of distributed DoH resolver 221 providers and in stark contrast to the highly distributed nature of 222 the DNS today. This is explored further in Section 5. While each 223 implementer has so far configured DoH off by default, and users can 224 opt-in, the apparent design target of some or all key implementations 225 is to enable Centralized DoH by default at some point in the future 226 (see Internet Society blog [20]. Thus, the current opt-in model is 227 assumed to be temporary. 229 7. Potential for Rapid Centralized DoH Adoption 231 Implementation of some new protocols, such as IPv6 (see World IPv6 232 Launch site [21], Wikipedia article [22], LinkedIn blog [23]) or 233 DNSSEC (see DNSSEC deployment history [24]), depended upon broad 234 community technical coordination, extensive open measurement, 235 extensive technical discussions over several years, and gradual 236 adoption. But adoption of IPv6 and DNSSEC grew organically over time 237 in part due to the wide variety and great number of parties that 238 needed to independently take action to adopt those protocols. In 239 contrast, there are far fewer major web browsers and operating 240 systems than network operators, websites, authoritative domain name 241 server operators, and so on. 243 The result of this comparatively greater concentration is that if 244 just two organizations implement DoH, then the adoption of 245 Centralized DoH could increase quite rapidly, and quickly overtake 246 and displace conventional non-DoH DNS query traffic. It appears to 247 be unprecedented that a new protocol could be so rapidly deployed and 248 thus displace an existing, long-standing, highly distributed protocol 249 based on implementation by just two implementers. 251 This extraordinary potential for rapid Centralized DoH deployment 252 alone suggests the need for a high degree of testing, discussion, and 253 consensus in the global Internet community that is broader than the 254 much more limited consensus necessary for adoption of proposed IETF 255 standards. 257 To illustrate the potential for rapid Centralized DoH, if just two 258 organizations, Google and Mozilla, were to implement Centralized DoH 259 in Android, Chrome, and Firefox, then global adoption of DoH could 260 occur rapidly and represent the majority of DNS queries on the 261 Internet. 263 All the above being said, it is important to note that this is not 264 necessarily a criticism of the motivations of the potential 265 Centralized DoH providers and that scale and market share are neither 266 objectively good or bad attributes. Indeed, as IETF chair Alissa 267 Cooper noted in an interview about consolidation with the Internet 268 Society [25], "In some cases larger entities can have faster, 269 broader, positive impacts on end users. Today, if one or a small 270 handful of the largest web properties, content delivery networks, or 271 email service providers chooses to deploy a new security technology 272 or implement a performance-enhancing feature, those improvements can 273 benefit millions or billions of users on short order." 275 Thus, on the one hand rapid adoption of new security protocols can be 276 good and adoption can be hastened by the actions of a few key 277 players. But it is important to also acknowledge that this may 278 simultaneously be in tension with other goals for the design and 279 operation of the Internet, requiring thoughtful consideration of the 280 pros and cons and extensive discussion in the Internet community and 281 elsewhere. 283 8. Potential Technical Risks 285 There are a variety of potentially significant risks to the security, 286 stability, and performance of the Internet as a result of Centralized 287 DoH implementation, and resulting consolidation of DNS operations. 288 These include the following potential and speculative risks: 290 1. Significant Operational Shift of Global Internet Infrastructure: 291 Shifting from a large quantity of highly distributed DNS 292 resolvers to a few centralized ones will likely have significant 293 impacts on how the Internet operates, is administered, and how 294 routine troubleshooting is performed. The full implications of 295 such a significant and potentially sudden change require deep 296 study by a range of actors across the Internet ecosystem. 298 2. Decreased Stability: 299 Significant centralization can increase the fragility of a 300 technical system, because there are fewer points of failure and 301 thus the impact of any individual failure can be quite high. 302 The net effect suggests that if DNS operations become 303 significantly centralized as a result of DoH, then the stability 304 of the DNS is likely to be negatively impacted. While not 305 directly related to DoH, there are examples of widespread 306 Internet outages when large DNS-related platforms experience 307 technical faults or attacks, such as Cloudflare (see Cloudflare 308 blog [26]), DynDNS (see Dyn blog [27]), and many others. 310 Even without the advent of Centralized DoH, which appears to be 311 a potentially significant concentrator of DNS traffic, a recent 312 paper from Harvard University ( see Zittrain et. al., "Evidence 313 of Decreasing Internet Entropy, The Lack of Redundancy in DNS 314 Resolution by Major Websites and Services" [28]) raises concerns 315 that may only worsen with DoH. They write, "We find an 316 increasing concentration of DNS services in a small number of 317 dominant cloud services companies. Coupled with domains 318 apparent tendency not to employ DNS services from multiple DNS 319 providers, this concentration could pose a fundamental threat to 320 the distributed resilience of the Internet. Our results also 321 suggest ways to mitigate these issues... The Dyn attack provides 322 a vivid illustration of how DNS infrastructure vulnerabilities - 323 and DNS space concentration - can wreak havoc on the stability 324 of the Internet." 326 3. Increased Security Threats: 327 Centralization due to DoH could mean a dramatic reduction in the 328 number of recursive DNS operators. This seems likely to lead to 329 fewer points of failure on which attackers can focus, 330 potentially altering the return on investment (ROI) necessary 331 for a large scale attack, compromise, or disruption to succeed. 332 Such threats may include the outsized effect of Border Gateway 333 Protocol (BGP) hijacks (see Internet Society blog [29], Freedom 334 to Tinker blog [30], CSO Online article [31], ZDNet article 335 [32], Ars Technica article [33], Google whitepaper [34], 336 Distributed Denial of Service (DDoS) attacks (see Dyn blog 337 [35]), or regular Denial of Service (DoS) attacks made against a 338 small number of systems. 340 4. Loss of Security Threat Visibility: 341 Some users will lose or have a degraded ability to use DNS 342 blocklists, which are one of the primary and most effective ways 343 to protect a network and its users against malware, phishing, 344 spam, DDoS attacks, etc. 346 This is because there has long been a notion that as a network 347 connects to the Internet, that the network can exercise some 348 degree of local policy control, which remains local to that 349 network and does not propagate beyond the boundary of their 350 administrative domain. This includes monitoring and protecting 351 the security of the network and devices on that network. Over 352 time, one of the practices that has evolved and become 353 widespread is the use of the DNS to monitor for, remediate, and/ 354 or prevent malware infection or other security problems. This 355 functionality is deployed in many types of networks, from ISPs 356 to networks used by enterprises, small businesses, government 357 offices, schools, churches, libraries, and others. In some 358 cases the DNS server may reside inside the network, while in 359 other cases it may be external (aka cloud-based, such as 360 OpenDNS). To illustrate this, many networks monitor the FQDNs 361 of DNS queries for matches against lists of well-known malware 362 command and control hosts. In some cases when matches occur, 363 the device owner or local network administrator may be notified 364 of a potential malware infection. In other cases, the DNS is 365 configured to re-write the response for a query of a malware- 366 associated FQDN, providing an address that points of a server 367 alerting the end user of a malware risk, providing a NXDOMAIN 368 response to cause the DNS lookup to terminate in failure, or 369 other response. This functionality will fail if DNS queries 370 bypass the servers that perform this function to Centralized DoH 371 resolvers. Thus, Centralized DoH can create blind spots in this 372 critical area of security threat visibility. 374 5. Loss of Parental Controls or other Content Controls: 375 Similar to using the DNS on local networks to monitor for and 376 prevent security issues, the DNS is often used to implement 377 local content controls such as parental controls. With these 378 controls a parent can configure a service on their home network 379 to prevent children from accessing inappropriate or other 380 disallowed content. For example, a parent may configure 381 policies to bar their two children, aged 5 and 7 years, from 382 accessing any sites associated with social media, gambling, 383 illegal drug use, pornography, and so on. Such opt-in services 384 are highly popular, especially because they can work across 385 device types (e.g. PC and mobile) and device ecosystems (e.g. 386 Android and Apple), software (e.g. Mac and Windows), and 387 platform ecosystems (e.g. Google, Apple, and Amazon). 389 Similar to the malware example, this is usually implemented via 390 DNS response matching and re-writing, with the end user 391 presented with either a redirection to a content block page or 392 receiving an NXDOMAIN response. This functionality will fail if 393 DNS queries bypass the servers that perform this function to 394 Centralized DoH resolvers. And while one suggestion may be that 395 the Centralized DoH provider offer such services, this is not a 396 choice users are being permitted to make. They may be perfectly 397 satisfied with their current solution, not want to take the time 398 to setup a new service, or not want to use the Centralized DoH 399 provider for this function. In addition, mature and highly 400 customizable parental control and content control systems that 401 meet the needs of enterprises, schools, parents, and others do 402 not appear to be offered by Centralized DoH providers. To the 403 extent that similar solutions seem to exist, they appear to be 404 very basic, and lacking in the customization and functionality 405 that has developed in this marketplace over the last 20 years. 407 In addition, if users wish to configure their own independent 408 DNS resolver that provides features such as parental controls, 409 as many do today, this may become more complicated and varied 410 with Centralized DoH to the extent that some software like 411 browsers or other applications are over-riding configurations 412 set by users in their operating system. 414 6. Split DNS Problems: 415 Split DNS [RFC8499] is an implementation in which separate DNS 416 servers are provided for internal and external networks as a 417 means of security and privacy management. This is most often 418 used in enterprise, education, and government networks. In 419 practice this means that there are names that only resolve on an 420 internal network, or that resolve to special internal hosts for 421 internal network users and publicly accessible hosts for users 422 outside of the network. For example, an enterprise may have an 423 internal service named "Accounting-System" reachable on the web 424 via https://accounting-system or https://accounting- 425 system.example.com, and connected to via internal, non-routable 426 RFC1918 IPv4 addresses such as 192.168.1.77. These domains or 427 fully qualified domain names (FQDNs) are maintained only on a 428 network's local DNS resolvers, and are not resolvable using the 429 Internet's authoritative DNS infrastructure. These names will 430 no longer be resolvable based on the expected implementation of 431 DoH because the local resolvers that can provide a valid 432 response for these names is no longer in the resolution path for 433 the end user on that network - they are skipping past the local 434 resolver to a centralized resolver on the Internet. It is 435 certainly possible to criticize the use of split DNS, like 436 Network Address Translation (NAT), but whether it is a 437 supposedly good practice or not, it seems a pervasive practice 438 nonetheless and should be considered by new DNS protocol 439 implementations. 441 7. Enterprise Data Leaks: 442 When split DNS names are used, as noted in the above example for 443 a user on an enterprise network attempting to connect to a host 444 at https://accounting-system.example.com, the lookup with a 445 centralized DoH resolver will typically fail (NXDOMAIN). But 446 because the internal name was sent to the centralized DoH 447 resolver, that private name has "leaked" outside of the local / 448 enterprise network. Similarly, lookups of reverse DNS names 449 (in-addr.arpa) will leak private IP addresses as well. The leak 450 of IP address data could occur regardless of whether or not 451 split DNS is used. 453 8. Potentially Reduced Software Diversity: 454 Consolidation of recursive DNS functions to a few Centralized 455 DoH providers suggests that there will be fewer types of DNS 456 server software over time, or at least that a very small number 457 of DNS server software packages will account for the 458 overwhelming volume of DNS traffic. This leads to less software 459 diversity over time, which is in some cases considered a 460 negative in this realm (see IEEE Explore paper [36], Freedom to 461 Tinker blog [37]). This may also shift most DNS traffic away 462 from platforms using open source software to proprietary 463 software. In addition, the impact of any DNS software exploits 464 (such as the BIND "packet of death" [38]) against the software 465 used by the few key Centralized DoH operators seems likely to 466 have an outsized impact on the global Internet. 468 9. Potential for Increased Commercial Use of DNS Data: 469 As a result of the highly distributed nature of the DNS today, 470 and of recursive DNS operations specifically, there are 471 essentially no - or at least few - global data sets of end user 472 DNS queries. The possible exception to that is for large public 473 DNS operators that receive hundreds of billions of queries per 474 day. But as Centralized DoH potentially leads to consolidation 475 onto a few large platforms, very large DNS query datasets will 476 emerge, which carries the risk that organizations will be 477 tempted to or find it otherwise necessary or advantageous to 478 make commercial use of that data. This might especially be the 479 case of those operators that offer DNS services for "free". 480 Furthermore, even if data sets are in some manner "anonymized", 481 it seems likely that some organizations will possess enough 482 other datasets that the combination of the two may trivially 483 enable de-anonymization. See [Narayanan-Shmatikov-1], 484 [Narayanan-Shmatikov-2], and [Narayanan-Shmatikov-3]. In 485 addition, a user may be uncomfortable with or unhappy with 486 having their DNS traffic sent to a pre-configured Centralized 487 DoH with whom they have no relationship. As noted earlier in 488 the document, this can be particularly problematic in light of 489 the GDPR and other laws and regulations around the world. 491 10. Potentially Negative Impact on Content Delivery Network (CDN) 492 Localization: 493 It seems there is some risk that some CDNs may be less able to 494 provide good content localization with Centralized DoH, 495 equivalent to the localization that they provide today. This is 496 because CDN localization today depends upon accurately 497 estimating the rough location from which client queries 498 originate, whether derived from EDNS-Client-Subnet (EDNS0) 499 [RFC6891] [RFC7871] or some other method employed by a CDN. 500 This location information is then used to dynamically generate 501 authoritative DNS responses that provide different responses 502 based on that client location. The goal of the CDN is to 503 provide highly localized responses, such as directing a client 504 to content cached in their local city or region rather than that 505 which is further away, such as across an ocean or across many 506 networks. 508 The technical impacts of reduced CDN localization might include 509 slower access to Internet content for end users and more traffic 510 traversing backbone and sub-optimal peering points as opposed to 511 localized points of direct interconnection between networks. It 512 is difficult to estimate what, if any, the impact would be. But 513 large-scale measurement platforms such as the SamKnows system 514 that is used by many regulators around the world such as OFCOM 515 and the FCC may be useful for exploring this further, as noted 516 in Section 10. 518 11. Use of DoH for Malware Command and Control: 519 Related to the loss of security threat visibility, it seems 520 clear that DoH is also now being used as a new and undetectable 521 malware command and control channel. One example is DoHC DoHC2 522 [39]. As a result, from the perspective of a variety of 523 networks, DoH is sometimes considered a security threat given 524 its adoption as a covert malware command and control 525 communications channel and thus may be considered a new avenue 526 for abuse. 528 12. Disruption of Legally-Mandated National-Level DNS Blocks: 529 In an increasing number of countries, network operators are 530 required by law to implement DNS-based blocking of names. Some 531 democratic countries have developed laws and regulations in this 532 area, including the UK, Sweden, Switzerland, France, Italy, 533 Brazil, and others [CITATIONS NEEDED]. As a result, Centralized 534 DoH resolvers appear unlikely to comply with these local laws 535 and so legally-mandated national DNS blocks will become 536 ineffective. National regulators may take a dim view of this 537 and require that Centralized DoH resolvers comply with 538 applicable national laws mandating DNS blocking. Whether or not 539 national-level DNS blocking is either good, effective, or easily 540 circumvented matters little; organizations operating within a 541 given country are typically expected to comply with such 542 applicable laws and so Centralized DoH resolvers will need to 543 determine how to comply. (This point is not to be confused with 544 the sorts of blocks that have historically been imposed on major 545 content destinations by repressive political regimes and/or 546 those with extensive censorship in place to limit or control 547 speech.) 549 13. Potentially Negative Impact on End User Broadband Performance: 550 As noted above, it seems possible that the extent of 551 localization of CDN-based content may decline somewhat. Should 552 that be the case, this means that the performance or speed of 553 access of CDN-based content will decline. Since most web 554 content is CDN-based, this suggests the possibility that the 555 general end user performance of the Internet will decline. An 556 initial study by Mozilla [40] has suggested that the protocol 557 itself (DoH vs. UDP/53 DNS) is roughly 6ms slower. But that 558 limited study only considers how fast it takes to get *an* 559 answer, not how *local* or good that answer is from an end user 560 perspective. More measurement is certainly necessary here, 561 which can consider how local the answers are and what the end- 562 to-end performance of web-based content is for users of 563 centralized DoH vs. non-users. 565 14. Unknown Server-Side Performance and Scaling: 566 Many new protocols are implemented organically, which means the 567 growth or adoption of the protocol is relatively gradual. As a 568 result, software developers and system administrators have a 569 longer period of time to learn about performance tuning and 570 scaling, and to methodically test and deploy improvements, 571 compared to a "flash-cut" sort of migration where a significant 572 shift to the protocol or system occurs in a short period. In 573 the case of the likely DoH implementation on which this document 574 speculates, it seems a rapid shift is more likely. This raises 575 the risk of instability and reduces the ability of technical 576 personnel involved in development and deployment to learn and 577 make technical changes gradually and with relatively minimal 578 impact on systems and users due to relatively high levels of 579 usage inherent in a flash cut or rapid migration scenario. 581 15. Increase in Exploits Targeting Individual DNS Engineers and 582 Administrators: 583 Given the likely consolidation of most recursive DNS traffic to 584 a very small number of operators, it seems logical to conclude 585 that attackers will realize that a fairly small number of DNS 586 engineering and operations/administration personnel (less than 587 two dozen?) will control a key function of the Internet. As a 588 result, it seems likely that a savvy attacker would target 589 exploits such as spear-phishing [41] or advanced persistent 590 threats (APT) [42] against this small number of people in order 591 to gain access to systems that administer or control recursive 592 DNS functions. 594 16. Increased Complexity and Cost of End User Troubleshooting: 595 Today, ISPs and other network operators can guide users through 596 troubleshooting to determine, often via a simple command line 597 interface, what DNS servers they have been assigned and what 598 responses they are receiving from those resolvers. In the 599 Centralized DoH model, determining what DoH servers are being 600 used and testing responses from those servers seems likely to be 601 relatively more complicated and varied. This could increase the 602 complexity and cost of routine end user troubleshooting. 604 17. Disruption of ISP Walled Garden Functions and Other Captive 605 Portals: 606 Many ISP networks utilize a DNS-based walled garden for 607 customers to provision new service, to activate a new device, to 608 re-establish an existing service after non-payment, and so on. 609 It appears that Centralized DoH disrupts these widely used 610 functions, because the browser is over-riding the specially 611 assigned walled-garden DNS server addresses and is instead 612 attempting to use a Centralized DoH resolver. Similarly, other 613 captive portals that may be affected include those to access 614 WiFi networks on campuses, in airplanes and coffee shops, and so 615 on. While new standards in the IETF's CAPPORT Working Group 616 [43] may avoid this in the future, CAPPORT standards are still 617 developing and/or are not widely deployed. 619 9. Potential Business Risks 621 New IETF standards are not introduced in a vacuum. Rather, IETF 622 standards have real-world impacts on technologies, markets, and 623 societies. As a result, potentially rapid shifts in adoption of 624 these standards means that relevant IETF working groups cannot ignore 625 potential real-world, technical and non-technical impacts. 627 If Centralized DoH is implemented quickly based on the business 628 decisions of one or two organizations with significant operating 629 system and/or web browser market share, with the resulting effect of 630 greater centralization, then the following potential and speculative 631 business risks are worth considering: 633 1. Smaller DNS Software Marketplace: 634 The market for DNS server software may be disrupted, as default 635 DoH resolver choices override typical DNS settings that direct 636 DNS traffic today. As a result, the number of DNS server 637 software developers may dwindle. This is because if ~70% of the 638 world's DNS queries rapidly moves to two Centralized DoH resolver 639 operators, then there is a diminished need for conventional DNS 640 operators to continue to maintain their DNS infrastructure. This 641 could impact DNS server software developers in both commercial 642 and open source markets, such as Akamai, Cisco, CZ.NIC, Infoblox, 643 PowerDNS, NLnet Labs, etc. 645 2. Fewer Public DNS Operator Choices: 646 The market for public DNS resolution will likely be disrupted, as 647 default Centralized DoH resolver choices override end-user- 648 configured DNS settings. For example, an end user may configure 649 their operating system to use a "public" DNS service that 650 implements parental control functions. But when using their web 651 browser, the browser sends its DNS queries - which are likely the 652 great majority of queries from the user based on the prevalence 653 of the web as an application - to a Centralized DoH resolver 654 instead. After the adoption of these public DNS services 655 declines dramatically, these organizations may struggle to 656 continue to justify the resources necessary to maintain the 657 service. This could impact all those public DNS resolvers that 658 are not the default partner of a Centralized DoH implementer 659 (e.g. Cloudflare) or are not themselves DoH implementers (e.g. 660 Google), such as Cisco's OpenDNS and Quad9. 662 3. Reduced CDN Localization and Competition: 663 The CDN market may be disrupted, as noted above, should some or 664 most existing CDNs be less able to provide good content 665 localization. This is because content localization is one of the 666 key reasons an organization would purchase a CDN's services. So 667 if this key reason goes away or is negatively impacted, there may 668 be less demand for CDN services or the price of those services 669 may decline as a result of reduced benefits to customers. This 670 may also affect competition if some providers exit the market or 671 alter their market behavior as a result. 673 4. Smaller DNS Labor Market: 674 The labor market for DNS engineering and operations expertise may 675 also be disrupted. This is likely due to there being fewer 676 independent developers of DNS software, as well as fewer 677 recursive DNS operators, which can be expected to reduce the need 678 for DNS technical resources over time. 680 10. Recommendations 682 This document makes the following recommendations: 684 1. Develop a Standardized DoH Resolver Discovery and Selection 685 Mechanism: 686 [RFC8484] does not specify a mechanism to discover whether a DoH 687 server is available as part of the local network configuration 688 and configuration of the URI template used the construct the URL 689 for resolution is explicitly stated as being out of band from 690 the DoH protocol. Without such a discovery mechanism, there is 691 little choice for DoH clients to use any other mechanism than 692 pre-configured DoH servers, which by implication would be almost 693 certainly be outside of the network of the ISP or other network 694 operator, even if they offered a DoH service. 696 There are efforts underway to discover and automatically 697 associate a DoH server with a resolver, for example draft-ietf- 698 doh-resolver-associated-doh [44]. Such configuration 699 mechanisms, if adopted by DoH clients, would potentially 700 ameliorate many of the issues with DoH deployment expressed in 701 this document, since it would provide a way for end-users to use 702 the DoH server provided by the local network operator. 704 2. Conventional DNS Providers Should Begin Testing DoH: 705 ISPs and other network operators, as well as any other 706 conventional DNS providers should begin to test DoH as a new 707 protocol that will be added to their existing DNS services. In 708 particular, it seems critical to develop appropriate, scalable, 709 reliable, and cost effective deployment design that can deliver 710 DNS resolutions at least at the level of performance that users 711 expect of conventional DNS. 713 3. More Measurement is Needed: 714 Limited measurements collected thus far have been in some cases 715 shared publicly, but the underlying datasets remain confidential 716 and private. In the future, significantly more measurement data 717 needs to collected, shared publicly, and debated in the Internet 718 technical community. Past deployments of new protocols can be a 719 guide here, such as measurements undertaken in support of the 720 deployment of IPv6, such as World IPv6 Day and Launch [45]. 722 4. Defaults Matter - Consider Them Carefully: 723 Make opt-in by default during initial deployment. Off by 724 default is less risky for initial deployment. That should 725 likely remain so until there has been significantly more 726 technical testing, global measurement, and Internet community 727 consensus-building. 729 5. Internet Corporation for Assigned Names and Numbers (ICANN) 730 Review: 731 ICANN coordinates and/or administers key Internet functions, 732 such as the Internet Assigned Numbers Authority (IANA) and the 733 global Domain Name System (DNS). ICANN maintains a group of 734 technical experts in the SSAC [46] that advises the ICANN Board 735 and community on the security and integrity of the Internet's 736 naming and address allocation systems, including domain name 737 operations, administration, and registration. Given that SSAC 738 focused on threat assessments and risks related to the stability 739 and security of the DNS, they seem like one appropriate party to 740 assess some of the risks that have been briefly explored in this 741 document or other DoH implementation-related risks and issues. 743 6. Additional Expert Reviews: 745 In addition to the ICANN SSAC, several other organization to be 746 appropriate parties that are well situated to assess risks and 747 issues as they pertain to those organizations or their members/ 748 participants. They include, but are not limited to: 749 - DNS Operations Analysis and Research Center (DNS-OARC) 750 - Messaging Malware Mobile Anti-Abuse Working Group (M3AAWG) 751 - Network Operator Groups (NOGs), such as the African Network 752 Operators Group (AfNOG), Australian Network Operators Group 753 (AUSNOG), Caribbean Network Operators Group (CaribNOG), Latin 754 American and Caribbean Region Network Operators Group (LACNOG), 755 North American Network Operators Group (NANOG), Pacific Network 756 Operators Group (PACNOG), Reseaux IP Europeens Network 757 Coordination Centre (RIPE NCC), Slovenian Network Operators 758 Group (SiNOG), etc. 759 - DNS registries outside of ICANN, such as Council of European 760 National Top-Level Domain Registries (CENTR). 762 7. Detailed Community Assessment of Risks and Issues: 763 All of the risks in Section 8 and Section 9 should be assessed. 764 In addition, when a change needs to happen to a protocol or a 765 system, it seems important to debate a few other key things such 766 as: 767 - What is the threat model that makes this change important 768 enough to justify? 769 - What are the security and privacy implications of this change? 770 - What are the implications for stability, operations, network 771 and systems administration, software development and diversity, 772 and other key issues? 773 - Do the benefits outweigh the drawbacks? 774 - What alternatives should be considered or developed? 776 8. Continue to Focus on DNSSEC Adoption: 777 To the extent that one of the underlying concerns motivating DoH 778 adoption pertains to modification of DNS responses via man in 779 the middle attacks, it seems that DNSSEC signing of domain names 780 and DNSSEC validation (including in clients) may be able to 781 mitigate that issue. DNSSEC remains important because DoH, 782 whether centralized or distributed, only provides security for 783 the transmission of DNS queries/responses over the wire (in 784 transit, or channel security), and does not provide assurance 785 that the response itself is secure and unmodified (content 786 security). This issue is explored in more detail in an APNIC 787 blog [47] and an ICANN presentation [48]. 789 9. Conduct Enterprise, Education, and Government Network Testing: 790 This documents several issues related to these non-ISP types of 791 networks. Additional testing should be conducted by these 792 entities in order to document actual and/or potential issues, 793 including the extent or severity of those issues, and provide 794 that feedback to appropriate standards and industry groups. 796 10. DoH Client Software Developers Should Investigate Region- 797 Specific Differences: 798 DoH can improve user privacy, especially in certain countries/ 799 regions with known surveillance and/or manipulation of DNS 800 queries and other data, which can pose human rights risks in 801 these areas. But many other countries/regions have more 802 privacy-protective expectations, rules, regulations, and laws. 803 It may be worthwhile for DoH client software developers to 804 consider developing application logic that enables Centralized 805 DoH in the high risk areas, while not leveraging DoH or 806 leveraging a distributed approach to DoH in the low risk areas. 808 11. Develop Centralized DoH Data Privacy Guidelines/Frameworks: 809 Assuming Centralized DoH is a viable model for implementation of 810 DoH, what sort of measures are needed to limit the potential for 811 problematic behavior by Centralized DoH providers? Should there 812 be a code of conduct (or equivalent) and, if so, who will 813 develop/maintain that? Likely topics for some guidelines or 814 framework might include how DoH client data may be collected, 815 retained, processed, shared, monetized, and/or combined with 816 other data sets, etc., whether and what limits there may be on 817 generating unique-per-used FQDNs, whether and what limits there 818 may be on web-related cookies/tracking mechanisms, detection of 819 DoH servers that return bogus or bad/false data, policy 820 statements from DoH providers on how client data is used, 821 measures to ensure DoH client data is suitably anonymized to 822 minimize the risk of re-identification of individuals by 823 combining DoH data with other data sources, etc. 825 11. Document Reviewer Acknowlegedments 827 The authors thank the several individuals for performing a detailed 828 review of this document, noting that this acknowledgement is not 829 intended to imply that they endorse the document. We specifically 830 wish to thank: Greg Aaron, Rob Alderfer, Bill Check, Neil Cook, Joe 831 Crowe, Glenn Deen, Andy Fidler, Peter Hagopian, Paul Hoffman, Yiu 832 Lee, Adam Roach, Jim Reid, and Ralf Weber. 834 12. IANA Considerations 836 RFC Editor: Please remove this section before publication. 838 This memo includes no requests to or actions for IANA. 840 13. Security Considerations 842 This document does not introduce any new security considerations. 843 However, it does highlight a number of potential security 844 considerations related to how [RFC8484] might be implemented in the 845 future, especially Centralized DoH. For example, an attacker could 846 substantially disrupt the global Internet by targeting one or two 847 major platform providers. See Section 8 for more information. 849 14. Privacy Considerations 851 This document does not introduce any new security considerations. 852 However, it does highlight a number of potential privacy 853 considerations related to how [RFC8484] might be implemented in the 854 future, especially Centralized DoH. For example, with Centralized 855 DoH there will be a small number of large commercial platforms that 856 have an extensive business collecting and leveraging user-related 857 data that could extend and augment these data sets as a result of the 858 data they can collect by handling the majority of global DNS traffic. 859 See Section 9 for more information. 861 15. References 863 15.1. Informative References 865 [Narayanan-Shmatikov-1] 866 Narayanan, A. and V. Shmatikov, "Robust de-anonymization 867 of large sparse datasets", IEEE Security and Privacy 2008, 868 2008. 870 [Narayanan-Shmatikov-2] 871 Narayanan, A. and V. Shmatikov, "De-anonymizing social 872 networks", 2009 30th IEEE Symposium on Security and 873 Privacy 2009, 2009. 875 [Narayanan-Shmatikov-3] 876 Narayanan, A. and V. Shmatikov, "Myths and fallacies of 877 personally identifiable information", Communications of 878 the ACM 53.6, 2010. 880 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 881 for DNS (EDNS(0))", STD 75, RFC 6891, 882 DOI 10.17487/RFC6891, April 2013, 883 . 885 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 886 Kumari, "Client Subnet in DNS Queries", RFC 7871, 887 DOI 10.17487/RFC7871, May 2016, 888 . 890 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 891 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 892 . 894 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 895 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 896 January 2019, . 898 15.2. URIs 900 [1] http://openresolverproject.org/ 902 [2] https://blog.nightly.mozilla.org/2018/06/01/improving-dns- 903 privacy-in-firefox/ 905 [3] https://developers.google.com/speed/public-dns/docs/dns-over- 906 https 908 [4] https://blog.mozilla.org/futurereleases/2018/11/27/next-steps-in- 909 dns-over-https-testing/ 911 [5] https://developers.google.com/speed/public-dns/docs/dns-over- 912 https 914 [6] https://xconomy.com/boston/2009/10/20/arbor-networks-reports-on- 915 the-rise-of-the-internet-hyper-giants/ 917 [7] https://cyber.harvard.edu/sites/cyber.law.harvard.edu/ 918 files/2010_DDoS_Attacks_Human_Rights_and_Media.pdf 920 [8] https://www.sandvine.com/blog/youtube-rules-mobile-2019-mobile- 921 internet-phenomena-report-released 923 [9] https://www.sandvine.com/blog/global-internet-phenomena- 924 worldwide-and-regional-total-internet-traffic-share-video-and- 925 file-sharing-are-tops 927 [10] https://arstechnica.com/tech-policy/2014/02/tim-berners-lee-we- 928 need-to-re-decentralize-the-web/ 930 [11] https://gizmodo.com/the-web-s-creator-now-wants-to-unfuck- 931 it-1781260559 933 [12] https://www.nytimes.com/2016/06/08/technology/the-webs-creator- 934 looks-to-reinvent-it.html 936 [13] https://blog.archive.org/2016/06/16/decentralized-web-summit- 937 with-tim-berners-lee-vint-cerf-and-polyfill/ 939 [14] https://spectrum.ieee.org/view-from-the-valley/telecom/internet/ 940 brewster-kahle-on-whats-next-for-the-decentralized-web-movement 942 [15] https://dci.mit.edu/decentralizedweb/ 944 [16] https://decentralizedweb.net/ 946 [17] https://tools.ietf.org/html/draft-arkko-iab-internet- 947 consolidation-00 949 [18] https://www.ietf.org/blog/consolidation/ 951 [19] https://www.internetsociety.org/globalinternetreport/2018/ 952 concept-note/ 954 [20] https://www.internetsociety.org/blog/2018/12/dns-privacy- 955 support-in-mozilla-firefox/ 957 [21] https://www.worldipv6launch.org/ 959 [22] https://en.wikipedia.org/wiki/ 960 World_IPv6_Day_and_World_IPv6_Launch_Day 962 [23] https://engineering.linkedin.com/blog/2018/06/celebrating-ipv6- 963 launch-day 965 [24] http://www.dnssec-deployment.org/history/ 967 [25] https://www.internetsociety.org/blog/2019/02/future-thinking- 968 alissa-cooper-technical-impact-internet-consolidation/ 970 [26] https://blog.cloudflare.com/today-we-mitigated-1-1-1-1/ 972 [27] https://dyn.com/blog/dyn-statement-on-10212016-ddos-attack/ 974 [28] https://www.hbs.edu/faculty/Pages/item.aspx?num=53830 976 [29] https://www.internetsociety.org/blog/2018/05/what-is-bgp- 977 hijacking-anyway/ 979 [30] https://freedom-to-tinker.com/2018/04/11/routing-attacks-on- 980 internet-services/ 982 [31] https://www.csoonline.com/article/3320996/possible-bgp- 983 hijacking-takes-google-down.html 985 [32] https://www.zdnet.com/article/persian-stalker-grayware-targets- 986 telegram-instagram-users/ 988 [33] https://arstechnica.com/information-technology/2018/04/ 989 suspicious-event-hijacks-amazon-traffic-for-2-hours-steals- 990 cryptocurrency/ 992 [34] https://services.google.com/fh/files/ 993 blogs/3ve_google_whiteops_whitepaper_final_nov_2018.pdf 995 [35] https://dyn.com/blog/dyn-statement-on-10212016-ddos-attack/ 997 [36] https://ieeexplore.ieee.org/document/4768648 999 [37] https://freedom-to-tinker.com/2004/02/19/monoculture/ 1001 [38] https://www.nominet.uk/the-packet-of-death/ 1003 [39] https://github.com/SpiderLabs/DoHC2 1005 [40] https://blog.nightly.mozilla.org/2018/08/28/firefox-nightly- 1006 secure-dns-experimental-results/ 1008 [41] https://uk.norton.com/norton-blog/2016/12/ 1009 what_is_spear_phishi.html 1011 [42] https://www.fireeye.com/current-threats/anatomy-of-a-cyber- 1012 attack.html 1014 [43] https://datatracker.ietf.org/wg/capport/about/ 1016 [44] https://datatracker.ietf.org/doc/draft-ietf-doh-resolver- 1017 associated-doh/ 1019 [45] https://www.worldipv6launch.org/measurements/ 1021 [46] https://www.icann.org/groups/ssac 1023 [47] https://blog.apnic.net/2018/08/17/sunrise-dns-over-tls-sunset- 1024 dnssec/ 1026 [48] https://www.icann.org/en/system/files/files/presentation- 1027 sunrise-dns-tls-sunset-dnssec-13jul18-en.pdf 1029 Appendix A. Change Log 1031 RFC Editor: Please remove this appendix before publication. 1033 o -00: First version published 1035 o -01: Fixed formatting issue with title at top of each page 1037 o -02: Removal of 2 ICANN-related recommendations that don't appear 1038 applicable 1040 o -03: Corrected cited stat from Mozilla study from 5% slower to 6ms 1041 slower. 1043 o -04: Refreshed version number to keep draft active while IETF 1044 determines path forward for this work. 1046 Appendix B. Open Issues 1048 Section will be removed before final publication 1050 o Citations are needed in the legally-mandated DNS blocking section. 1052 o Improve the formatting of extended quotations. 1054 Authors' Addresses 1056 Jason Livingood 1057 Comcast 1059 Email: jason_livingood@comcast.com 1061 Manos Antonakakis 1062 Georgia Institute of Technology 1064 Email: manos@gatech.edu 1065 Bob Sleigh 1066 BT Plc 1068 Email: bob.sleigh@bt.com 1070 Alister Winfield 1071 Sky 1073 Email: Alister.Winfield@sky.uk