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/