[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

ADD                                                          A. Campling
Internet-Draft                                    419 Consulting Limited
Intended status: Informational                             N. Kowalewski
Expires: January 14, 2021                               Deutsche Telekom
                                                              G. Scalone
                                                                Vodafone
                                                                  C. Box
                                                                BT Group
                                                             A. Winfield
                                                                     Sky
                                                           July 13, 2020


    Practical Observations from Encrypted DNS Deployments by Network
                               Operators
                draft-campling-operator-observations-00

Abstract

   The following document includes observations regarding a variety of
   implementations of recursive DNS capabilities that are important to
   network operators in terms of delivering DNS services to their
   (several tens of millions of) customers.  It highlights some of the
   challenges that need to be addressed to allow the widespread adoption
   of encrypted DNS by the end-users of network operators.

   The information is intended to aid the development of discovery
   mechanisms for protocols such as DNS-over-HTTPS.  It clearly defines
   problems that need technical solutions to allow the deployment of
   encrypted DNS by the largest number of operators to the largest
   number of users in the shortest possible timeframe with little or no
   disruption to the user experience.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."




Campling, et al.        Expires January 14, 2021                [Page 1]


Internet-DraPractical Observations from Encrypted DNS Deploym  July 2020


   This Internet-Draft will expire on January 14, 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   The IETF has developed many protocols to improve the security and
   reliability of DNS over UDP or TCP (Do53) [RFC1035] including DNS
   over TLS (DoT) [RFC7858], DNS over HTTPS (DoH) [RFC8484] and DNS
   Security Extensions (DNSSEC) [RFC2535].  To enable the broadest
   adoption of these technologies, there are issues for consideration of
   any discovery solutions that are proposed to the Adaptive DNS
   Discovery [ADD] working group.

   Many network operators, including Internet Service Providers (ISPs),
   whether using fixed or mobile networks, would like to ensure that
   their encrypted DNS services can be seamlessly discovered and used by
   applications and operating systems that support encrypted DNS,
   particularly DoH, in order that encrypted DNS can be deployed to the
   widest possible community of users.  They would particularly like to
   ensure that any proposed DNS discovery mechanisms take into account
   ISP use-cases such as DNS forwarders on CPE (Customer Premises
   Equipment or routers), the use of DNS for CDNs (Content Delivery
   Networks) with local content caches and the non-public nature of most
   ISP DNS services.

   This document has taken observations and experiences from a number of
   network operators that have been actively working on adding support
   for encrypted DNS to their networks.  It is intended to make clear
   the requirements needed by any discovery mechanism developed by the
   ADD group.  It collates and succinctly describes common problems
   faced by existing stakeholders in adopting encrypted DNS mechanisms.

   This document also presents some background information that is
   relevant to describing the issues and explains concerns around



Campling, et al.        Expires January 14, 2021                [Page 2]


Internet-DraPractical Observations from Encrypted DNS Deploym  July 2020


   current proposed solutions.  It should also be noted that, in many
   European countries, some regulations are specific to ISPs.  One such
   requirement is that their customers should be able to connect to the
   Internet with any home router of their choice even if a router is
   provided by the ISP as part of its service.  Therefore new proocols
   cannot be accommodated simply by requiring ISP customers to upgrade
   their routers.

2.  Rationale

   This document is intended provide information to aid interested
   parties in developing discovery mechanisms for protocols such as DoH
   to allow their adoption with minimal disruption to the end user
   experience, maximising the number of users that can enjoy an easy
   upgrade path towards DNS encryption.

   The information provided will help interested paries develop
   discovery mechanisms that avoid the unnecessary exclusion of the
   majority of customers of a significant number of ISPs (including the
   major ones in Europe that serve several tens of millions of
   customers) from easy access to this new technology using the secure
   by design, same-provider auto-upgrade mechanisms.

   Such discovery choices will ensure that easy access to encrypted DNS
   is not dependent on the Internet access network architecture and on
   the ease of upgrade of any CPE.  In addition, it will ensure that
   users are not forced to change their DNS resolver to a third party,
   potentially via manual configuration by the user, possibly losing
   functionality in the process.

3.  The 'Same Provider Auto-Upgrade' Model

   Both Google Chrome and Microsoft Windows (and perhaps other client
   software in the future) currently deploy encrypted DNS through a
   'same provider auto-upgrade' (SPAU) model.  This approach results in
   the client not needing to prompt the user to change to a different
   resolver operator to enjoy an encrypted connection.  Instead the
   client will rather try to determine whether an encrypted channel
   exists for communication with the same resolver operator that the
   user currently employs for unencrypted DNS resolution.  If such a
   channel can be found, the client will automatically upgrade the
   connection from the original unencrypted one to the new encrypted
   one; otherwise, the client will continue sending DNS queries
   unencrypted.

   The current implementation of this model is as follows:





Campling, et al.        Expires January 14, 2021                [Page 3]


Internet-DraPractical Observations from Encrypted DNS Deploym  July 2020


   o  Out of band, the client software vendor discovers ISPs running DoH
      services (in the case of Google Chrome, ISPs will more likely
      apply for inclusion through Google's announced process).  The
      vendor records the existing (Do53) resolver IP addresses, and adds
      them to a hard-wired table that maps those existing Do53 IP
      addresses to the DoH service that the vendor discovered to be
      associated with those resolver IPs.

   o  When the client starts for the first time, and thereafter whenever
      it detects a network change, it checks the resolver configuration
      of the local host.  If the configured resolver matches one of the
      IPs listed in the above table, the client auto-upgrades to use the
      DoH service instead.

   The above method ensures that users are only upgraded to DoH when the
   vendor is sure that the DoH service is the same service as the Do53
   service already used.

4.  The Problem with Auto-Upgrade and Forwarders

   Automatic upgrades that rely upon the user device being able to know
   and compare the address of the resolver that is serving the device
   can fail in some home network environments where the CPE is acting as
   a DNS proxy.  To do this, the CPE will run software like DNSMASQ
   which acts as a proxy between the client and the DNS resolver, also
   providing DHCP services and performing DNS caching as well as
   forwarding.  This is often paired with a home network architecture
   that uses RFC1918 [RFC1918] private IP addresses.

   In circumstances where private IP addresses are used, any auto-
   upgrade on the user device that compares the IP address of the
   device's DNS resolver against a list of known public DNS resolvers
   will fail because the client DNS resolver is a RFC1918 private
   address of the CPE device and not the public address of the actual
   DNS resolver operated by the network operator.

   As can be seen, the existing SPAU model doesn't work with the DNS-
   forwarder, private IP approach commonly used by network operators.
   Given that this approach allows for the implementation of the best
   privacy practices and best latency/engineering reqirements, it
   shouldn't change, therefore the SPAU model needs to be adapted to
   work with it.

5.  Why DNS Discovery Needs to Support Forwarders







Campling, et al.        Expires January 14, 2021                [Page 4]


Internet-DraPractical Observations from Encrypted DNS Deploym  July 2020


5.1.  Loss of Functionality if CPE Doesn't Support DNS Forwarders

   If the CPE is upgraded to announce the public resolver to clients,
   the following functionality will be lost

   o  Caching/Proxy on the CPE - This leads to more load on the ISP's
      DNS platform because every client talks directly to the public
      resolvers (not only the clients which are auto-upgraded to DoH but
      also all other clients).

   o  Local DNS routing and resilience - Some deployments segment the
      user base into regions, with CPE in each region receiving a
      different IPv4 and IPv6 address for the DNS server, improving
      latency and load balancing, as well as helping with cyber
      resilience compared to a single address for a typical anycast
      implementation.

   o  Addressing local clients via their names - Often the CPE assigns
      the name configured to a client to the client's IP address on the
      CPE (for example, if the hostname is set to 'myhost' on a home
      network to reach this host on that network under that name).  This
      will not work if the clients communicate directly with a resolver
      in the carrier network nor would it for auto-upgraded clients
      because, even if they fallback to Do53, they will still ask a
      resolver in the carrier network and not the CPE - and in both
      cases private network details will be leaked.

   o  The CPE is the only network element that is aware of the local
      network topology.  If the local network information is lost it is
      not possible to differentiate devices.  The Discovery mechanism
      alone is not enough to solve this use case as additional logic is
      required on the DoH server to send back the request to the CPE.
      By using EDNS0 (Extension Mechanisms for DNS) [RFC2671] it is
      possible for a client running on the CPE to pass EDNS0 information
      to the ISP's DNS and provide, to the opted-in customers,
      information on the client that performed the request.  This in
      turn allows the execution, for example, of parental controls on
      devices belonging to children (there are various ways of doing
      this that preserves privacy, for example by providing information
      only about the required filtering profile or by providing only a
      locally generated ID to distinguish between devices without
      necessarily identifying them).

   o  Similar to the above use-case, some CPE can be configured to
      perform filtering directly, relying on a DNS forwarder's ability
      to intercept and modify DNS queries to do so.  Moving queries to
      the network DoH server removes this capability, allowing more data




Campling, et al.        Expires January 14, 2021                [Page 5]


Internet-DraPractical Observations from Encrypted DNS Deploym  July 2020


      to leave the local network, even if a resolver is available to
      perform similar filtering.

5.2.  Why Not Just Upgrade the CPE to Stop Forwarding?

   It may seem easier to simply ignore the loss of functionality
   detailed above and just upgrade the CPE to stop DNS forwarding.
   However, such a software upgrade programme, or even the wholesale
   replacement of CPE, is not without its own challenges.

   The following is based on information from various large European
   ISPs, all of which use a DNS forwarder in their CPE.  This
   configuration applies to operators in multiple countries, each of
   which has many millions of customers, so is a fair reflection of the
   envirnment in which any DNS discovery process needs to operate.

   o  Non-standard CPE - Whilst many ISPs provide their customers with
      CPE, some customers will elect to use alternative equipment which
      will not accept software upgrades

   o  Multiple hardware variants - ISPs typically endeavour to maintain
      support for legacy CPE.  Upgrading the CPE software therefore
      requires complex and lengthy quality assurance processes to
      accommodate the many device variants, with some of the larger ISPs
      having 20-30 variants of devices.

   o  Large, dispersed customer bases - Cycle times to replace CPE are
      lengthy due to the costs and numbers involved, and the outcome of
      any upgrade programme is uncertain due to the aversion of some
      customers to replace their existing equipment

   In summary, the timeframe for non-critical software updates of ISP-
   supplied CPE can be lengthy.  In addition, any such upgrades will
   only apply to the ISP-supplied CPE so will at best only ever reach
   between 60-80% of the customer base for many of the largest European
   ISPs.  A replacement programme will also take an extended period
   without a guaranteed outcome, and that is without considering the
   cost.

5.3.  The Advantage of Supporting Forwarding

   The above is intended to illustrate why it is more effective to
   ensure that DNS discovery methods, including those that support the
   SPAU model, are developed that work with the hardware and software
   environments in common use by network operators.






Campling, et al.        Expires January 14, 2021                [Page 6]


Internet-DraPractical Observations from Encrypted DNS Deploym  July 2020


6.  Alternative Solutions

   Some may be tempted to suggest that the simplest solution to address
   the issues noted in this document would be for users to connect to
   global DNS resolvers.  Aside from the loss of functionality and
   significant reduction in user choice that this would imply, it would
   also result in the further, forced, centralisation of Internet
   infrastructure, a policy outcome which is out of scope for the ADD
   working group.  It would also, of course, result in the personal data
   of very large numbers of users to shared with additional parties
   simply to provide encrypted DNS functionality.

   A better approach would be to address the underlying issues so that
   client software is able to auto-discover and connect to encrypted
   resolvers on existing network wherever these are available, giving
   users a seamless upgrade, maintaining full functionality and
   maximising choice.

7.  Extending the Use Case

   TO DO

   The information in this document is largely based on input from a
   number of large European network operators, augmented with knowledge
   of the operations of others, mainly in Europe but with some from
   North America.  It would be beneficial to extend this document with
   data from additional ISPs to complement the existing content and also
   to extend the narrative with examples of additional working practices
   relating to the operation of DNS where possible.  This would provide
   valuable information to inform the development of DNS discovery
   approaches that will benefit a far broader set of users than would
   otherwise be possible.

   To this end, additional contributions are welcomed as these would
   ensure that the document is fully representative of the significant
   use cases globally.

8.  Acknowledgements

   In addition to the authors, this document is the product of an
   informal group of experts including the following people:

      Andy Fidler, BT plc

      Neil Cook, Open-Xchange

      Nic Leymann, Deutsche Telekom




Campling, et al.        Expires January 14, 2021                [Page 7]


Internet-DraPractical Observations from Encrypted DNS Deploym  July 2020


      Ralf Weber, Akamai

      Vittorio Bertola, Open-Xchange

9.  Informative References

   [ADD]      IETF, "Adaptive DNS Discovery (ADD) Working Group",
              February 2020,
              <https://datatracker.ietf.org/wg/add/about/>.

   [EDDI]     EDDI, "Encrypted DNS Deployment Initiative", July 2020,
              <https://www.encrypted-dns.org/>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <https://www.rfc-editor.org/info/rfc1918>.

   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
              Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999,
              <https://www.rfc-editor.org/info/rfc2535>.

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, DOI 10.17487/RFC2671, August 1999,
              <https://www.rfc-editor.org/info/rfc2671>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/info/rfc7858>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

Authors' Addresses

   Andrew J Campling
   419 Consulting Limited

   Email: Andrew.Campling@419.Consulting
   URI:   https://www.419.Consulting/





Campling, et al.        Expires January 14, 2021                [Page 8]


Internet-DraPractical Observations from Encrypted DNS Deploym  July 2020


   Normen B Kowalewski
   Deutsche Telekom

   Email: Normen.Kowalewski@Telecom.DE
   URI:   https://www.Telecom.DE/


   Gianpaolo A Scalone
   Vodafone

   Email: Gianpaolo-Angelo.Scalone@Vodafone.Com
   URI:   https://www.Vodafone.Com/


   Chris Box
   BT Group

   Email: Chris.Box@BT.Com
   URI:   https://www.BT.Com/


   Alister Winfield
   Sky

   Email: Alister.Winfield@Sky.UK
   URI:   https://www.Sky.Com/

























Campling, et al.        Expires January 14, 2021                [Page 9]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/