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

Versions: 00 01 02 03 04 05 06 07 draft-ietf-doh-resolver-associated-doh

Network Working Group                                         P. Hoffman
Internet-Draft                                                     ICANN
Intended status: Standards Track                       November 05, 2018
Expires: May 9, 2019


                Associating a DoH Server with a Resolver
                draft-hoffman-resolver-associated-doh-05

Abstract

   Browsers and web applications may want to know if there are one or
   more DoH servers associated with the DNS recursive resolver that the
   operating system is already using.  This would allow them to get DNS
   responses from a resolver that the user (or, more likely, the user's
   network administrator) has already chosen.  This document describes
   two protocols for a resolver to tell a client what its associated DoH
   servers are.

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."

   This Internet-Draft will expire on May 9, 2019.

Copyright Notice

   Copyright (c) 2018 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



Hoffman                    Expires May 9, 2019                  [Page 1]


Internet-Draft           Resolver Associated DoH           November 2018


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Finding the URI Templates of the DoH Servers Associated with
       a Resolver  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  DoH Servers by TXT  . . . . . . . . . . . . . . . . . . .   4
     2.2.  DoH Servers by Addresses  . . . . . . . . . . . . . . . .   4
       2.2.1.  Finding the IP Addresses of a Resolver  . . . . . . .   5
       2.2.2.  Finding the DoH Servers Associated with a Resolver  .   5
     2.3.  Issues Common to "DoH Servers by TXT" and "DoH Servers by
           Addresses"  . . . . . . . . . . . . . . . . . . . . . . .   6
     2.4.  Choosing Between "DoH Servers by TXT" and "DoH Servers by
           Addresses"  . . . . . . . . . . . . . . . . . . . . . . .   6
     2.5.  User Interface  . . . . . . . . . . . . . . . . . . . . .   6
   3.  Design Choices  . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   DoH [RFC8484] requires that one or more DoH servers be configured for
   the DoH client.  That document does not say how the DoH servers are
   found, nor how to select from a list of possible DoH servers, nor
   what the user interface (UI) for the configuration should be.

   There is a use case for browsers and web applications who have one or
   more currently-configured DNS recursive resolvers wanting to use DoH
   for DNS resolution instead.  For example, the recursive resolver
   knows how to give correct answers to DNS queries that contain names
   that are only resolvable in the local context.  Users typically
   configure their DNS recursive resolvers with through manual
   configuration (such as manually editing a /etc/named.conf file) or
   through automatic configuration from a protocol such as DHCP.

   The client that wants to change from its currently-configured Do53
   recursive resolver(s) to one or more DoH servers might be the stub
   resolver in an operating system, although at this time it is rare
   that such stub resolvers can use DoH.  A much more likely use case is



Hoffman                    Expires May 9, 2019                  [Page 2]


Internet-Draft           Resolver Associated DoH           November 2018


   a browser or web application that is getting name resolution through
   the stub resolver on the computer on which it is running.  The user
   of the browser might have a preference for using a DoH server, and
   they might need to use a DoH server that is associated with the
   resolver that the computer is currently using so that its queries for
   non-global names are answered correctly.  They may also be required
   to use only resolvers that are approved by their organization's
   network operators.

   To address these use cases, this document defines two different
   protocols to get the list of URI templates [RFC6570] associated for
   the DoH servers associated with at least one of the resolvers being
   used by the operating system on the system on which the application
   is being run.  Each uses its onw special use domain name (SUDN);
   SUDNs aredescribed in [RFC6761].

   o  The first, called "DoH servers by TXT" and described in
      Section 2.1, is a new SUDN that can be queried for a TXT RRset.
      This protocol is most likely useful only to browsers that can call
      operating system functions that in turn query the DNS for text
      records; web applications can only query for IP addresses.

   o  The second, called "DoH servers by Addresses" and described in
      Section 2.2 is combination of a new SUDN that that can be queried
      for IP addresses, and a well-known URI [I-D.nottingham-rfc5785bis]
      that can be resolved to return the URI templates.  This protocol
      is useful for a browser or web application that can query for the
      addressess associated with a domain name (such as using the POSIX
      "getaddrinfo()" function) and resolve HTTP and HTTPS URLs.

   The design choices for this protocol, particularly earlier designs
   that were deemed unusable, are described in Section 3.

1.1.  Terminology

   In this document, "DoT" is used to indicate DNS over TLS as defined
   in [RFC7858].

   In this document, "Do53" is used to indicate DNS over UDP or TCP as
   defined in [RFC1035].

   "DoH client" and "DoH server" are defined in [RFC8484].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.



Hoffman                    Expires May 9, 2019                  [Page 3]


Internet-Draft           Resolver Associated DoH           November 2018


2.  Finding the URI Templates of the DoH Servers Associated with a
    Resolver

   A client (a browser or web application) uses either the protocol in
   Section 2.1 or Section 2.2 to get a list of URI templates for the DoH
   servers associated with a resolver.  The following sub-sections
   describe the protocols and have notes that are common to both
   protocols.

2.1.  DoH Servers by TXT

   To find the DoH Servers associated with a resolver, an application
   sends that resolver a query for "resolver-associated-doh.arpa" in
   class IN with the RRtype of TXT [RFC1035] (that is, the query is
   resolver-associated-doh.arpa/IN/TXT).

   The resolver replies with its associated DoH servers as URI templates
   in the TXT RRset in the Answer section.

   A resolver that understands this protocol MUST send a TXT RRset in
   the Answer section.  Each TXT record contains one URI template.  If a
   resolver that understands this protocol has no associated DoH
   servers, the TXT RRset contains exactly one record that has an empty
   string as the RDATA; that is, the RDLENGTH in that record is 1, and
   the RDATA contains just the byte 0x00.

   As described in Section 4, the zone resolver-associated-doh.arpa is
   not delegated.  The resolver acts as if it is and adds its own TXT
   records to the answer.

   The client uses the TXT records in the response to the resolver-
   associated-doh.arpa/IN/TXT query as a list of the URI templates of
   the DoH servers associated with the resolver.  Note that TXT records
   can contain multiple "character-strings" [RFC1035]; for this
   protocol, all characters-strings in a TXT record are concatenated to
   form a single URI template.

2.2.  DoH Servers by Addresses

   To find the DoH Servers associated with a resolver, an application
   uses a SUDN that causes a resolver to return its IP addresses.  It
   uses those IP addresses as part of a well-known URI to find out the
   URI templates [RFC6570] to use for the DoH server(s) associated with
   the resolver.







Hoffman                    Expires May 9, 2019                  [Page 4]


Internet-Draft           Resolver Associated DoH           November 2018


2.2.1.  Finding the IP Addresses of a Resolver

   A browser is able to use an operating system function such as
   gethostbyname() to convert host names into IP addresses through the
   stub resolver in the operating system on which it is running.  It can
   also send HTTPS queries to a resolver, but it would need to have the
   address of that resolver first.  Web applications can do the same.

   For this protocol, the browser or web application uses the SUDN
   "resolver-addresses.arpa".  When a resolver that understands this
   SUDN receives a query for either resolver-addresses.arpa/IN/A or
   resolver-addresses.arpa/IN/AAAA, it returns its own IP addresses in
   the answer.

   As described in Section 4, the zone resolver-addresses.arpa is not
   delegated.The resolver acts as if it is and adds its own A or AAAA
   records to the answer.

2.2.2.  Finding the DoH Servers Associated with a Resolver

   To find the DoH servers associated with a resolver, the client uses
   the addresses returned from the query to resolver-addresses.arpa and
   sends a query to

   https://IPADDRESSGOESHERE/.well-known/doh-servers-associated/

   The resolver replies with its associated DoH servers as URI templates
   [RFC6570].

   [[ Need to describe the media types; likely JSON ]]

   [[ Need to talk about what a response with an empty list means ]]

   [[ Need to talk about what happens if authentication fails.  This is
   complicated by the fact that the application doesn't know if the OS-
   to-resolver communication is authenticated. ]]

   [[ Need to talk about HTTP caching ]]

   A client MUST try to establish a new list of DoH servers associated
   with a resolver every time the configured resolver in the operating
   system changes.









Hoffman                    Expires May 9, 2019                  [Page 5]


Internet-Draft           Resolver Associated DoH           November 2018


2.3.  Issues Common to "DoH Servers by TXT" and "DoH Servers by
      Addresses"

   See Section 6 for warnings about sending the DNS queries over a
   transport that does not assure data integrity (such as Do53), and
   over a transport that does assure data integrity (such as DoT) but in
   circumstances where the browser or web application doesn't know the
   type of DNS transport being used.

   A client MUST re-issue the queries in {#doh_by_txt} and
   {#doh_by_addresses} every time the configured resolver in the
   operating system changes.

   [[ What if there is a list of DoH servers?  Pick one (how?) or jump
   arond? ]]

2.4.  Choosing Between "DoH Servers by TXT" and "DoH Servers by
      Addresses"

   [[ by TXT only takes one step ]]

   [[ by address gives you all the addressess, which might yield more
   servers ]]

2.5.  User Interface

   For this protocol to be useful in a browser, the browser needs to
   have an entry in its configuration interface where the allowed DoH
   servers are listed that indicates that a DoH server from the
   configured Do53 or DoT resolver is allowed.  That wording might say
   something like "DoH server associated with my current resolver" (or
   "servidor DoH asociado con mi resolucion actual" or "serveur DoH
   associe a mon resolveur actuel").

3.  Design Choices

   The primary use case for this protocol is a browser or web
   application that is getting name resolution through the stub resolver
   on the computer on which it is running wanting to switch its name
   resolution to DoH.  A secondary use case is an OS that wants to make
   a similar switch.

   An earlier design suggestion was to use a new RRtype with a query to
   ./IN/NEWRRTYPE.  However, it was pointed out that this would not work
   going through stub resolvers that validate DNSSEC.

   An earlier design suggestion was to use DHCP to tell the OS the DoH
   servers that the stub resolver might use.  That protocol is



Hoffman                    Expires May 9, 2019                  [Page 6]


Internet-Draft           Resolver Associated DoH           November 2018


   orthogonal to the one in this document in that it addresses a
   different use case.  If both the protocol in this document and a
   DHCP-based protocol are standardized, they could co-exist.  However,
   there is no current mechanism for a stub resolver to tell a browser,
   or a web application, what DoH server the stub resolver is using, so
   DoH configuration in the stub resolver would not prevent the browser
   from trying to find a DoH server on its own.

   An earlier design suggestion was to use an EDNS0 [RFC6891] extension.
   The design chosen in this document meets the use case better because
   applications cannot communicate EDNS0 extensions to the stub
   resolver.

4.  IANA Considerations

   IANA will record the domain name "resolver-associated-doh.arpa" in
   the "Special-Use Domain Names" registry [SUDN].  IANA MUST NOT
   delegate resolver-associated-doh.arpa in the .arpa zone.

   IANA will record the domain name "resolver-addresses.arpa" in the
   "Special-Use Domain Names" registry [SUDN].  IANA MUST NOT delegate
   resolver-addresses.arpa in the .arpa zone.

   [[ When this document settles down, need to register ".well-known/
   doh-servers-associated" as specified in [I-D.nottingham-rfc5785bis].
   ]]

5.  Privacy Considerations

   Allowing a user to use DoH instead of Do53 increases communication
   privacy because of the TLS protection.

   When a Do53 or DoT server indicates that a particular DoH server is
   associated with it, the client might assume that the DoH server has
   the same information privacy policies as the Do53 or DoT server.
   Therefore, a Do53 or DoT server SHOULD NOT recommend a DoH server
   unless that DoH server has the same (or better) information privacy
   policy as the Do53 or DoT server.

6.  Security Considerations

   There is currently no way for an application to know whether the
   operating system's stub resolver is using a transport that assures
   data integrity such as DoT.

   Even is an application could determine the use of a transport like
   DoT, the application would also need to know whether the transport
   was authenticated or was simply chosen opportunistically.



Hoffman                    Expires May 9, 2019                  [Page 7]


Internet-Draft           Resolver Associated DoH           November 2018


7.  References

7.1.  Normative References

   [I-D.nottingham-rfc5785bis]
              Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", draft-nottingham-rfc5785bis-08 (work in
              progress), October 2018.

   [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>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", RFC 6570,
              DOI 10.17487/RFC6570, March 2012,
              <https://www.rfc-editor.org/info/rfc6570>.

   [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>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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>.

   [SUDN]     "Special-Use Domain Names", n.d.,
              <https://www.iana.org/assignments/
              special-use-domain-names/>.

7.2.  Informative References

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, DOI 10.17487/RFC6761, February 2013,
              <https://www.rfc-editor.org/info/rfc6761>.






Hoffman                    Expires May 9, 2019                  [Page 8]


Internet-Draft           Resolver Associated DoH           November 2018


   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891,
              DOI 10.17487/RFC6891, April 2013,
              <https://www.rfc-editor.org/info/rfc6891>.

Acknowledgments

   The use case in this document was inspired by discussions and the
   DRIU BoF at IETF 102 and later in the DNSOP Working Group.  Vladimir
   Cunat, Philip Homburg, Shumon Huque, Martin Thomson, Eric Rescorla,
   and Tony Finch offered useful advice to improve early versions of the
   protocol.

Author's Address

   Paul Hoffman
   ICANN

   Email: paul.hoffman@icann.org
































Hoffman                    Expires May 9, 2019                  [Page 9]


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