Network Working Group P. Hoffman Internet-Draft ICANN Intended status: Standards Track October 22, 2018 Expires: April 25, 2019 Associating a DoH Server with a Resolver draft-hoffman-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 a protocol 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 April 25, 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 April 25, 2019 [Page 1] Internet-Draft Resolver Associated DoH October 2018 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Finding the DoH Servers Associated with a Resolver . . . . . 3 3.1. Finding the IP Addresses of a Resolver . . . . . . . . . 3 3.2. Finding the DoH Servers Associated with a Resolver . . . 4 4. User Interface . . . . . . . . . . . . . . . . . . . . . . . 4 5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 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 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 Hoffman Expires April 25, 2019 [Page 2] Internet-Draft Resolver Associated DoH October 2018 to use only resolvers that are approved by their organization's network operators. To address these use cases, this document defines a new special use domain name (described in [RFC6761]) and a well-known URI [I-D.nottingham-rfc5785bis]. When combined, they allow an application that can use the POSIX "getaddrinfo()" function and resolve HTTP and HTTPS URLs to get a list of 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. The design choices for this protocol, particularly earlier designs that were deemed unusable, are described in Section 5. 2. 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. 3. Finding the DoH Servers Associated with a Resolver To find the DoH Servers associated with a resolver, an application uses a special use domain name 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. 3.1. Finding the IP Addresses of a Resolver A browser is able to use the POSIX "getaddrinfo()" function to convert host names into IP addresses through the stub resolver in the operating system on which it is running. It can also send queries to a resolver, but it would need to have the address of that resolver first. The same is true for web applications. In order for a browser (or other application) to find the address of the resolver that the operating system is using, it uses the POSIX Hoffman Expires April 25, 2019 [Page 3] Internet-Draft Resolver Associated DoH October 2018 "getaddrinfo()" function (or some equivalent) with the special use name "resolver-addresses.arpa". When a resolver that understands this special use domain name 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. 3.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. 4. 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". 5. 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. Hoffman Expires April 25, 2019 [Page 4] Internet-Draft Resolver Associated DoH October 2018 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 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. An earlier design suggestion used a special use domain name of resolver-associated-doh.arpa with an RRtype of TXT. The design chosen in this document meets the use case better because applications cannot query the stub resolver for types other than address records. 6. IANA Considerations 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]. ]] 7. 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. Hoffman Expires April 25, 2019 [Page 5] Internet-Draft Resolver Associated DoH October 2018 8. 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. 9. References 9.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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . Hoffman Expires April 25, 2019 [Page 6] Internet-Draft Resolver Associated DoH October 2018 [SUDN] "Special-Use Domain Names", n.d., . 9.2. Informative References [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . 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, and Shumon Huque offered useful advice to greatly improve an early version of the protocol. Author's Address Paul Hoffman ICANN Email: paul.hoffman@icann.org Hoffman Expires April 25, 2019 [Page 7]