idnits 2.17.00 (12 Aug 2021) /tmp/idnits47909/draft-campling-operator-observations-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 670 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'EDDI' is defined on line 337, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADD A. Campling 3 Internet-Draft 419 Consulting Limited 4 Intended status: Informational N. Kowalewski 5 Expires: January 14, 2021 Deutsche Telekom 6 G. Scalone 7 Vodafone 8 C. Box 9 BT Group 10 A. Winfield 11 Sky 12 July 13, 2020 14 Practical Observations from Encrypted DNS Deployments by Network 15 Operators 16 draft-campling-operator-observations-00 18 Abstract 20 The following document includes observations regarding a variety of 21 implementations of recursive DNS capabilities that are important to 22 network operators in terms of delivering DNS services to their 23 (several tens of millions of) customers. It highlights some of the 24 challenges that need to be addressed to allow the widespread adoption 25 of encrypted DNS by the end-users of network operators. 27 The information is intended to aid the development of discovery 28 mechanisms for protocols such as DNS-over-HTTPS. It clearly defines 29 problems that need technical solutions to allow the deployment of 30 encrypted DNS by the largest number of operators to the largest 31 number of users in the shortest possible timeframe with little or no 32 disruption to the user experience. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 14, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 1. Introduction 67 The IETF has developed many protocols to improve the security and 68 reliability of DNS over UDP or TCP (Do53) [RFC1035] including DNS 69 over TLS (DoT) [RFC7858], DNS over HTTPS (DoH) [RFC8484] and DNS 70 Security Extensions (DNSSEC) [RFC2535]. To enable the broadest 71 adoption of these technologies, there are issues for consideration of 72 any discovery solutions that are proposed to the Adaptive DNS 73 Discovery [ADD] working group. 75 Many network operators, including Internet Service Providers (ISPs), 76 whether using fixed or mobile networks, would like to ensure that 77 their encrypted DNS services can be seamlessly discovered and used by 78 applications and operating systems that support encrypted DNS, 79 particularly DoH, in order that encrypted DNS can be deployed to the 80 widest possible community of users. They would particularly like to 81 ensure that any proposed DNS discovery mechanisms take into account 82 ISP use-cases such as DNS forwarders on CPE (Customer Premises 83 Equipment or routers), the use of DNS for CDNs (Content Delivery 84 Networks) with local content caches and the non-public nature of most 85 ISP DNS services. 87 This document has taken observations and experiences from a number of 88 network operators that have been actively working on adding support 89 for encrypted DNS to their networks. It is intended to make clear 90 the requirements needed by any discovery mechanism developed by the 91 ADD group. It collates and succinctly describes common problems 92 faced by existing stakeholders in adopting encrypted DNS mechanisms. 94 This document also presents some background information that is 95 relevant to describing the issues and explains concerns around 96 current proposed solutions. It should also be noted that, in many 97 European countries, some regulations are specific to ISPs. One such 98 requirement is that their customers should be able to connect to the 99 Internet with any home router of their choice even if a router is 100 provided by the ISP as part of its service. Therefore new proocols 101 cannot be accommodated simply by requiring ISP customers to upgrade 102 their routers. 104 2. Rationale 106 This document is intended provide information to aid interested 107 parties in developing discovery mechanisms for protocols such as DoH 108 to allow their adoption with minimal disruption to the end user 109 experience, maximising the number of users that can enjoy an easy 110 upgrade path towards DNS encryption. 112 The information provided will help interested paries develop 113 discovery mechanisms that avoid the unnecessary exclusion of the 114 majority of customers of a significant number of ISPs (including the 115 major ones in Europe that serve several tens of millions of 116 customers) from easy access to this new technology using the secure 117 by design, same-provider auto-upgrade mechanisms. 119 Such discovery choices will ensure that easy access to encrypted DNS 120 is not dependent on the Internet access network architecture and on 121 the ease of upgrade of any CPE. In addition, it will ensure that 122 users are not forced to change their DNS resolver to a third party, 123 potentially via manual configuration by the user, possibly losing 124 functionality in the process. 126 3. The 'Same Provider Auto-Upgrade' Model 128 Both Google Chrome and Microsoft Windows (and perhaps other client 129 software in the future) currently deploy encrypted DNS through a 130 'same provider auto-upgrade' (SPAU) model. This approach results in 131 the client not needing to prompt the user to change to a different 132 resolver operator to enjoy an encrypted connection. Instead the 133 client will rather try to determine whether an encrypted channel 134 exists for communication with the same resolver operator that the 135 user currently employs for unencrypted DNS resolution. If such a 136 channel can be found, the client will automatically upgrade the 137 connection from the original unencrypted one to the new encrypted 138 one; otherwise, the client will continue sending DNS queries 139 unencrypted. 141 The current implementation of this model is as follows: 143 o Out of band, the client software vendor discovers ISPs running DoH 144 services (in the case of Google Chrome, ISPs will more likely 145 apply for inclusion through Google's announced process). The 146 vendor records the existing (Do53) resolver IP addresses, and adds 147 them to a hard-wired table that maps those existing Do53 IP 148 addresses to the DoH service that the vendor discovered to be 149 associated with those resolver IPs. 151 o When the client starts for the first time, and thereafter whenever 152 it detects a network change, it checks the resolver configuration 153 of the local host. If the configured resolver matches one of the 154 IPs listed in the above table, the client auto-upgrades to use the 155 DoH service instead. 157 The above method ensures that users are only upgraded to DoH when the 158 vendor is sure that the DoH service is the same service as the Do53 159 service already used. 161 4. The Problem with Auto-Upgrade and Forwarders 163 Automatic upgrades that rely upon the user device being able to know 164 and compare the address of the resolver that is serving the device 165 can fail in some home network environments where the CPE is acting as 166 a DNS proxy. To do this, the CPE will run software like DNSMASQ 167 which acts as a proxy between the client and the DNS resolver, also 168 providing DHCP services and performing DNS caching as well as 169 forwarding. This is often paired with a home network architecture 170 that uses RFC1918 [RFC1918] private IP addresses. 172 In circumstances where private IP addresses are used, any auto- 173 upgrade on the user device that compares the IP address of the 174 device's DNS resolver against a list of known public DNS resolvers 175 will fail because the client DNS resolver is a RFC1918 private 176 address of the CPE device and not the public address of the actual 177 DNS resolver operated by the network operator. 179 As can be seen, the existing SPAU model doesn't work with the DNS- 180 forwarder, private IP approach commonly used by network operators. 181 Given that this approach allows for the implementation of the best 182 privacy practices and best latency/engineering reqirements, it 183 shouldn't change, therefore the SPAU model needs to be adapted to 184 work with it. 186 5. Why DNS Discovery Needs to Support Forwarders 187 5.1. Loss of Functionality if CPE Doesn't Support DNS Forwarders 189 If the CPE is upgraded to announce the public resolver to clients, 190 the following functionality will be lost 192 o Caching/Proxy on the CPE - This leads to more load on the ISP's 193 DNS platform because every client talks directly to the public 194 resolvers (not only the clients which are auto-upgraded to DoH but 195 also all other clients). 197 o Local DNS routing and resilience - Some deployments segment the 198 user base into regions, with CPE in each region receiving a 199 different IPv4 and IPv6 address for the DNS server, improving 200 latency and load balancing, as well as helping with cyber 201 resilience compared to a single address for a typical anycast 202 implementation. 204 o Addressing local clients via their names - Often the CPE assigns 205 the name configured to a client to the client's IP address on the 206 CPE (for example, if the hostname is set to 'myhost' on a home 207 network to reach this host on that network under that name). This 208 will not work if the clients communicate directly with a resolver 209 in the carrier network nor would it for auto-upgraded clients 210 because, even if they fallback to Do53, they will still ask a 211 resolver in the carrier network and not the CPE - and in both 212 cases private network details will be leaked. 214 o The CPE is the only network element that is aware of the local 215 network topology. If the local network information is lost it is 216 not possible to differentiate devices. The Discovery mechanism 217 alone is not enough to solve this use case as additional logic is 218 required on the DoH server to send back the request to the CPE. 219 By using EDNS0 (Extension Mechanisms for DNS) [RFC2671] it is 220 possible for a client running on the CPE to pass EDNS0 information 221 to the ISP's DNS and provide, to the opted-in customers, 222 information on the client that performed the request. This in 223 turn allows the execution, for example, of parental controls on 224 devices belonging to children (there are various ways of doing 225 this that preserves privacy, for example by providing information 226 only about the required filtering profile or by providing only a 227 locally generated ID to distinguish between devices without 228 necessarily identifying them). 230 o Similar to the above use-case, some CPE can be configured to 231 perform filtering directly, relying on a DNS forwarder's ability 232 to intercept and modify DNS queries to do so. Moving queries to 233 the network DoH server removes this capability, allowing more data 234 to leave the local network, even if a resolver is available to 235 perform similar filtering. 237 5.2. Why Not Just Upgrade the CPE to Stop Forwarding? 239 It may seem easier to simply ignore the loss of functionality 240 detailed above and just upgrade the CPE to stop DNS forwarding. 241 However, such a software upgrade programme, or even the wholesale 242 replacement of CPE, is not without its own challenges. 244 The following is based on information from various large European 245 ISPs, all of which use a DNS forwarder in their CPE. This 246 configuration applies to operators in multiple countries, each of 247 which has many millions of customers, so is a fair reflection of the 248 envirnment in which any DNS discovery process needs to operate. 250 o Non-standard CPE - Whilst many ISPs provide their customers with 251 CPE, some customers will elect to use alternative equipment which 252 will not accept software upgrades 254 o Multiple hardware variants - ISPs typically endeavour to maintain 255 support for legacy CPE. Upgrading the CPE software therefore 256 requires complex and lengthy quality assurance processes to 257 accommodate the many device variants, with some of the larger ISPs 258 having 20-30 variants of devices. 260 o Large, dispersed customer bases - Cycle times to replace CPE are 261 lengthy due to the costs and numbers involved, and the outcome of 262 any upgrade programme is uncertain due to the aversion of some 263 customers to replace their existing equipment 265 In summary, the timeframe for non-critical software updates of ISP- 266 supplied CPE can be lengthy. In addition, any such upgrades will 267 only apply to the ISP-supplied CPE so will at best only ever reach 268 between 60-80% of the customer base for many of the largest European 269 ISPs. A replacement programme will also take an extended period 270 without a guaranteed outcome, and that is without considering the 271 cost. 273 5.3. The Advantage of Supporting Forwarding 275 The above is intended to illustrate why it is more effective to 276 ensure that DNS discovery methods, including those that support the 277 SPAU model, are developed that work with the hardware and software 278 environments in common use by network operators. 280 6. Alternative Solutions 282 Some may be tempted to suggest that the simplest solution to address 283 the issues noted in this document would be for users to connect to 284 global DNS resolvers. Aside from the loss of functionality and 285 significant reduction in user choice that this would imply, it would 286 also result in the further, forced, centralisation of Internet 287 infrastructure, a policy outcome which is out of scope for the ADD 288 working group. It would also, of course, result in the personal data 289 of very large numbers of users to shared with additional parties 290 simply to provide encrypted DNS functionality. 292 A better approach would be to address the underlying issues so that 293 client software is able to auto-discover and connect to encrypted 294 resolvers on existing network wherever these are available, giving 295 users a seamless upgrade, maintaining full functionality and 296 maximising choice. 298 7. Extending the Use Case 300 TO DO 302 The information in this document is largely based on input from a 303 number of large European network operators, augmented with knowledge 304 of the operations of others, mainly in Europe but with some from 305 North America. It would be beneficial to extend this document with 306 data from additional ISPs to complement the existing content and also 307 to extend the narrative with examples of additional working practices 308 relating to the operation of DNS where possible. This would provide 309 valuable information to inform the development of DNS discovery 310 approaches that will benefit a far broader set of users than would 311 otherwise be possible. 313 To this end, additional contributions are welcomed as these would 314 ensure that the document is fully representative of the significant 315 use cases globally. 317 8. Acknowledgements 319 In addition to the authors, this document is the product of an 320 informal group of experts including the following people: 322 Andy Fidler, BT plc 324 Neil Cook, Open-Xchange 326 Nic Leymann, Deutsche Telekom 327 Ralf Weber, Akamai 329 Vittorio Bertola, Open-Xchange 331 9. Informative References 333 [ADD] IETF, "Adaptive DNS Discovery (ADD) Working Group", 334 February 2020, 335 . 337 [EDDI] EDDI, "Encrypted DNS Deployment Initiative", July 2020, 338 . 340 [RFC1035] Mockapetris, P., "Domain names - implementation and 341 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 342 November 1987, . 344 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 345 and E. Lear, "Address Allocation for Private Internets", 346 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 347 . 349 [RFC2535] Eastlake 3rd, D., "Domain Name System Security 350 Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999, 351 . 353 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 354 RFC 2671, DOI 10.17487/RFC2671, August 1999, 355 . 357 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 358 and P. Hoffman, "Specification for DNS over Transport 359 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 360 2016, . 362 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 363 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 364 . 366 Authors' Addresses 368 Andrew J Campling 369 419 Consulting Limited 371 Email: Andrew.Campling@419.Consulting 372 URI: https://www.419.Consulting/ 373 Normen B Kowalewski 374 Deutsche Telekom 376 Email: Normen.Kowalewski@Telecom.DE 377 URI: https://www.Telecom.DE/ 379 Gianpaolo A Scalone 380 Vodafone 382 Email: Gianpaolo-Angelo.Scalone@Vodafone.Com 383 URI: https://www.Vodafone.Com/ 385 Chris Box 386 BT Group 388 Email: Chris.Box@BT.Com 389 URI: https://www.BT.Com/ 391 Alister Winfield 392 Sky 394 Email: Alister.Winfield@Sky.UK 395 URI: https://www.Sky.Com/