Internet DRAFT - draft-ietf-doh-resolver-associated-doh

draft-ietf-doh-resolver-associated-doh







Network Working Group                                         P. Hoffman
Internet-Draft                                                     ICANN
Intended status: Standards Track                          March 24, 2019
Expires: September 25, 2019


                Associating a DoH Server with a Resolver
                draft-ietf-doh-resolver-associated-doh-03

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.  It also describes a protocol for a client to find out
   the address of the resolver it is using, if it cannot find that
   address by an operating system API or some other means.

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 September 25, 2019.

Copyright Notice

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



Hoffman                Expires September 25, 2019               [Page 1]

Internet-Draft           Resolver Associated DoH              March 2019


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  DoH Servers from HTTPS  . . . . . . . . . . . . . . . . . . .   4
   3.  DoH Servers from DNS  . . . . . . . . . . . . . . . . . . . .   5
   4.  Resolver Addresses from DNS . . . . . . . . . . . . . . . . .   6
   5.  Lists of DoH Servers  . . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Earlier Design Choices . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

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 to want the DNS
   recursive resolver(s) configured in the operating system to use DoH
   for DNS resolution instead of normal DNS, but to do so to at a DoH
   server specified by the configured resolver.  For example, a
   recursive resolver configured by the operating system may know how to
   give correct answers to DNS queries that contain names that are only
   resolvable in the local context, or resolve differently in the local
   context.  Similarly, the recursive resolver configured in the
   operating system may implement security policies such as malware
   prevention that are not implemented in the same way in DoH servers
   not affiliated with the user's organization.  Users typically
   configure their DNS recursive resolvers with through automatic
   configuration from a protocol such as DHCP; much less often, they use
   manual configuration (such as manually editing a /etc/resolv.conf
   file).

   The expected use cases for DoH are browsers and web applications that
   would otherwise get their DNS service from the resolver configured by



Hoffman                Expires September 25, 2019               [Page 2]

Internet-Draft           Resolver Associated DoH              March 2019


   the operating system.  The user of the client might have a preference
   for using a DoH server for the benefits that DoH brings, and they
   might need to use a DoH server that is associated with the resolver
   that the computer is currently using for the reasons listed above.
   In a common scenario, user may be required to use only resolvers that
   are approved by their organization's network operators.

   The URI templates of the DoH servers associated with a resolver might
   be hosted on the resolver itself, or a resolver hosted by the same
   operator, or even hosted somewhere else.  The latter could be used by
   resolver operators who don't want to host DoH servers but trust
   another operator to do so.

   To address these use cases, this document defines protocols to get
   the list of URI templates [RFC6570] or addresses 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.

   o  "DoH servers from HTTPS", described in Section 2, is a well-known
      URI [I-D.nottingham-rfc5785bis] that can be resolved to return the
      URI templates in an HTTP response.

   o  "DoH servers from DNS", described in Section 3, is a new special
      use domain name (SUDN) [RFC6761] that can be queried to return the
      URI templates as a TXT RRset.

   o  "resolver addresses from DNS", described in Section 4, is a new
      SUDN that that can be queried to return the addresses as A and
      AAAA RRsets.

   For these protocols 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").  Alternatively, these protocols
   might be the default for a browser, and naming specific other DoH
   servers might be done with a UI.

   The protocols described here are meant for a browser to be able to
   start using DoH based on its current interactions with the resolver
   from the operating system on which the browser is running: they are
   not expected to work without being able to do DNS resolution.  Even
   "DoH servers from HTTPS", which ostensibly only needs an IP address,
   is likely to need DNS resolution for things like OCSP servers during
   the setup of TLS.




Hoffman                Expires September 25, 2019               [Page 3]

Internet-Draft           Resolver Associated DoH              March 2019


1.1.  Terminology

   In this document, "client" means either a browser or web application.
   When one or the other is named explicitly,

   In this document, "browser" means any application that can open ports
   in the operating system.  This odd usage of the term "browser" is
   adopted from [RFC8484].

   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.

2.  DoH Servers from HTTPS

   To find the URI templates for DoH servers associated with a resolver
   whose address is already known, a browser or web application can use
   the well-known URI described in this section.  To find the IP address
   of the resolver used by the operating system on which a browser is
   running, a browser can use either an operating system function (if
   such a function is available to it) or the process described in
   Section 4.  (A web application can also use the process described in
   Section 4, and thus use this well-known URI.)

   To find the DoH servers associated with a resolver, the client MUST
   use the following query:

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

   The resolver replies with its associated DoH servers as URI templates
   [RFC6570].  The HTTP response header MUST contain an appropriate HTTP
   status code as defined in [RFC7231].  Successful responses MUST set
   the Content-Type set to "application/json".

   The returned JSON object [RFC8259] MUST contain a member whose name
   is "associated-resolvers" and whose value is a JSON array.  The array
   contains zero or more JSON strings, each of which is a single URI
   template.



Hoffman                Expires September 25, 2019               [Page 4]

Internet-Draft           Resolver Associated DoH              March 2019


   If the array of URI templates returned is empty, that indicates that
   the resolver does not have any DoH servers associated with it.

   For example, the returned object might look like:

   { "associated-resolvers":
      [ "https://dnsserver.example.net/dns-query{?dns}",
        "https://webhost.example.net/a/b/c/dns-query{?dns}" ]
   }

   If there are no associated DoH servers, the returned object would
   look like:

   { "associated-resolvers": [ ] }

   If the TLS authentication for the query fails, the browser MUST abort
   the connection without sending the HTTP request, and it cannot assume
   anything about whether the resolver has any DoH servers associated
   with it.

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

   The HTTP query follows all the normal rules for HTTP.  Thus, the
   result of sending this query can be an HTTP redirect to a different
   server.  Also, the result of the query might be served from an HTTP
   cache.

3.  DoH Servers from DNS

   To find the URI templates for DoH servers associated with a resolver,
   a browser 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).  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 cannot currently call such operating system functions.

   As described in Section 6, the zone resolver-associated-doh.arpa is
   not actually delegated and never will be.  The resolver that receives
   this query acts as if it is delegated, and adds its own TXT records
   to the answer.  The resolver replies with its associated DoH servers
   as URI templates in the TXT RRset in the Answer section.  The
   resolver can generate this reply with special code to capture queries
   for "resolver-associated-doh.arpa"; if the resolver can be configured
   to also be authoritative for some zones, it can use that




Hoffman                Expires September 25, 2019               [Page 5]

Internet-Draft           Resolver Associated DoH              March 2019


   configuration to actually be authoritative for "resolver-associated-
   doh.arpa".

   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.

   An example of the TXT RRset (in DNS master file format) might be:

   $ORIGIN resolver-associated-doh.arpa.
    IN TXT "https://dnsserver.example.net/dns-query{?dns}"
    IN TXT "https://webhost.example.net/a/b/c/dns-query{?dns}"

   If there are no associated DoH servers, an example of the the TXT
   RRset (in DNS master file format) might be:

   $ORIGIN resolver-associated-doh.arpa.
    IN TXT ""

   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.

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

4.  Resolver Addresses from DNS

   Browsers which cannot get the IP address(es) of the resolver
   configured by the operating system using APIs are still able to use
   an operating system function such as gethostbyname() or its
   equivalents to convert host names into IP addresses through the stub
   resolver in the operating system on which they are running.  Web
   applications also can convert host names to IP addresses.  Either can
   use a new SUDN to find the address(es) of the resolvers configured by
   the operating system.

   A browser or web application uses it normal interface for getting IP
   addresses for a hostname, and uses the SUDN "resolver-addresses.arpa"
   as the hostname.




Hoffman                Expires September 25, 2019               [Page 6]

Internet-Draft           Resolver Associated DoH              March 2019


   As described in Section 6, the zone resolver-addresses.arpa is not
   actually delegated and never will be.  The resolver acts as if that
   name is delegated, and returns its own A or AAAA addresses in the
   records in the answer.  The resolver can generate this reply with
   special code to capture queries for "resolver-addresses.arpa"; if the
   resolver can be configured to also be authoritative for some zones,
   it can use that configuration to actually be authoritative for
   "resolver-addresses.arpa".

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

5.  Lists of DoH Servers

   The "DoH servers from HTTPS" "DoH servers from DNS" return lists of
   DoH servers, and those lists can have more than one element.  The DoH
   client can choose any of the servers in the list; that is, there is
   no inherent "preference" for any of the serers returned.  From a
   mathematical viewpoint, the lists can better be considered as sets.

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

   Before this draft is complete, mail will be sent to wellknown-uri-
   review@ietf.org in order to be registered in the "Well-Known URIs"
   registry at IANA.  The mail will contain the following:

   URI suffix:  doh-servers-associated
   Change controller:  IETF
   Specification document(s):  draft-ietf-doh-resolver-associated-doh
   Status:  permanent

7.  Privacy Considerations

   Allowing a user to use DoH to a server associated with the resolver
   in use by the operating system on the user's machine, instead of
   using Do53 to to the resolver in use by the operating system on the
   user's machine, can increase communication privacy because of the TLS
   protection.  However, using a DoH server can also reduce overall




Hoffman                Expires September 25, 2019               [Page 7]

Internet-Draft           Resolver Associated DoH              March 2019


   privacy because both TLS and HTTPS allow for user identification in
   ways that plain Do53 does not.

   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.

   A browser that has both a stub resolver stack and a TLS stack that is
   independent of HTTP could make a DoT connection to the resolver being
   used by the operating system.

8.  Security Considerations

   If DNS queries sent from stub resolvers to recursive resolvers are
   not sent over transports that assure data integrity and server
   authentication, the "DoH servers from DNS" and "Resolver addresses
   from DNS" protocols are susceptible to on-path attackers directing a
   user to a DoH server that is not actually associated with their
   resolver.  Do53 is not a secure transport, and neither is DoT using
   the opportunistic profile.

   The DNS responses used in "DoH servers from DNS" and "Resolver
   addresses from DNS" cannot be validated with DNSSEC [RFC4033], and
   thus even a validating stub resolver would treat them the same as any
   other DNS responses in unsigned zones.

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

9.  References

9.1.  Normative References

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

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



Hoffman                Expires September 25, 2019               [Page 8]

Internet-Draft           Resolver Associated DoH              March 2019


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

9.2.  Informative References

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/info/rfc4033>.

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

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

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <https://www.rfc-editor.org/info/rfc7231>.




Hoffman                Expires September 25, 2019               [Page 9]

Internet-Draft           Resolver Associated DoH              March 2019


   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

Appendix A.  Earlier Design Choices

   The primary use case for these protocols 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.

   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 operating
   system the DoH servers that the stub resolver might use.  That
   protocol is 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.

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 versions of the
   protocol before it came to the DOH Working Group.

Author's Address

   Paul Hoffman
   ICANN

   Email: paul.hoffman@icann.org






Hoffman                Expires September 25, 2019              [Page 10]