idnits 2.17.1 draft-hoffman-resolver-associated-doh-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2011 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-nottingham-rfc5785bis-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'SUDN' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft ICANN 4 Intended status: Standards Track October 22, 2018 5 Expires: April 25, 2019 7 Associating a DoH Server with a Resolver 8 draft-hoffman-resolver-associated-doh-03 10 Abstract 12 Browsers and web applications may want to know if there are one or 13 more DoH servers associated with the DNS recursive resolver that the 14 operating system is already using. This would allow them to get DNS 15 responses from a resolver that the user (or, more likely, the user's 16 network administrator) has already chosen. This document describes a 17 protocol for a resolver to tell a client what its associated DoH 18 servers are. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 25, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Finding the DoH Servers Associated with a Resolver . . . . . 3 57 3.1. Finding the IP Addresses of a Resolver . . . . . . . . . 3 58 3.2. Finding the DoH Servers Associated with a Resolver . . . 4 59 4. User Interface . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 4 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 9.2. Informative References . . . . . . . . . . . . . . . . . 7 67 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 DoH [RFC8484] requires that one or more DoH servers be configured for 73 the DoH client. That document does not say how the DoH servers are 74 found, nor how to select from a list of possible DoH servers, nor 75 what the user interface (UI) for the configuration should be. 77 There is a use case for browsers and web applications who have one or 78 more currently-configured DNS recursive resolvers wanting to use DoH 79 for DNS resolution instead. For example, the recursive resolver 80 knows how to give correct answers to DNS queries that contain names 81 that are only resolvable in the local context. Users typically 82 configure their DNS recursive resolvers with through manual 83 configuration (such as manually editing a /etc/named.conf file) or 84 through automatic configuration from a protocol such as DHCP. 86 The client that wants to change from its currently-configured Do53 87 recursive resolver(s) to one or more DoH servers might be the stub 88 resolver in an operating system, although at this time it is rare 89 that such stub resolvers can use DoH. A much more likely use case is 90 a browser or web application that is getting name resolution through 91 the stub resolver on the computer on which it is running. The user 92 of the browser might have a preference for using a DoH server, and 93 they might need to use a DoH server that is associated with the 94 resolver that the computer is currently using so that its queries for 95 non-global names are answered correctly. They may also be required 96 to use only resolvers that are approved by their organization's 97 network operators. 99 To address these use cases, this document defines a new special use 100 domain name (described in [RFC6761]) and a well-known URI 101 [I-D.nottingham-rfc5785bis]. When combined, they allow an 102 application that can use the POSIX "getaddrinfo()" function and 103 resolve HTTP and HTTPS URLs to get a list of the DoH servers 104 associated with at least one of the resolvers being used by the 105 operating system on the system on which the application is being run. 107 The design choices for this protocol, particularly earlier designs 108 that were deemed unusable, are described in Section 5. 110 2. Terminology 112 In this document, "DoT" is used to indicate DNS over TLS as defined 113 in [RFC7858]. 115 In this document, "Do53" is used to indicate DNS over UDP or TCP as 116 defined in [RFC1035]. 118 "DoH client" and "DoH server" are defined in [RFC8484]. 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 3. Finding the DoH Servers Associated with a Resolver 128 To find the DoH Servers associated with a resolver, an application 129 uses a special use domain name that causes a resolver to return its 130 IP addresses. It uses those IP addresses as part of a well-known URI 131 to find out the URI templates [RFC6570] to use for the DoH server(s) 132 associated with the resolver. 134 3.1. Finding the IP Addresses of a Resolver 136 A browser is able to use the POSIX "getaddrinfo()" function to 137 convert host names into IP addresses through the stub resolver in the 138 operating system on which it is running. It can also send queries to 139 a resolver, but it would need to have the address of that resolver 140 first. The same is true for web applications. 142 In order for a browser (or other application) to find the address of 143 the resolver that the operating system is using, it uses the POSIX 144 "getaddrinfo()" function (or some equivalent) with the special use 145 name "resolver-addresses.arpa". When a resolver that understands 146 this special use domain name receives a query for either resolver- 147 addresses.arpa/IN/A or resolver-addresses.arpa/IN/AAAA, it returns 148 its own IP addresses in the answer. 150 3.2. Finding the DoH Servers Associated with a Resolver 152 To find the DoH servers associated with a resolver, the client uses 153 the addresses returned from the query to resolver-addresses.arpa and 154 sends a query to 156 https://IPADDRESSGOESHERE/.well-known/doh-servers-associated/ 158 The resolver replies with its associated DoH servers as URI Templates 159 [RFC6570]. 161 [[ Need to describe the media types; likely JSON ]] 163 [[ Need to talk about what a response with an empty list means ]] 165 [[ Need to talk about what happens if authentication fails. This is 166 complicated by the fact that the application doesn't know if the OS- 167 to-resolver communication is authenticated. ]] 169 [[ Need to talk about HTTP caching ]] 171 A client MUST try to establish a new list of DoH servers associated 172 with a resolver every time the configured resolver in the operating 173 system changes. 175 4. User Interface 177 For this protocol to be useful in a browser, the browser needs to 178 have an entry in its configuration interface where the allowed DoH 179 servers are listed that indicates that a DoH server from the 180 configured Do53 or DoT resolver is allowed. That wording might say 181 something like "DoH server associated with my current resolver". 183 5. Design Choices 185 The primary use case for this protocol is a browser or web 186 application that is getting name resolution through the stub resolver 187 on the computer on which it is running wanting to switch its name 188 resolution to DoH. A secondary use case is an OS that wants to make 189 a similar switch. 191 An earlier design suggestion was to use a new RRtype with a query to 192 ./IN/NEWRRTYPE. However, it was pointed out that this would not work 193 going through stub resolvers that validate DNSSEC. 195 An earlier design suggestion was to use DHCP to tell the OS the DoH 196 servers that the stub resolver might use. That protocol is 197 orthogonal to the one in this document in that it addresses a 198 different use case. If both the protocol in this document and a 199 DHCP-based protocol are standardized, they could co-exist. However, 200 there is no current mechanism for a stub resolver to tell a browser, 201 or a web application, what DoH server the stub resolver is using, so 202 DoH configuration in the stub resolver would not prevent the browser 203 from trying to find a DoH server on its own. 205 An earlier design suggestion was to use an EDNS0 [RFC6891] extension. 206 The design chosen in this document meets the use case better because 207 applications cannot communicate EDNS0 extensions to the stub 208 resolver. 210 An earlier design suggestion used a special use domain name of 211 resolver-associated-doh.arpa with an RRtype of TXT. The design 212 chosen in this document meets the use case better because 213 applications cannot query the stub resolver for types other than 214 address records. 216 6. IANA Considerations 218 IANA will record the domain name "resolver-addresses.arpa." in the 219 "Special-Use Domain Names" registry [SUDN]. IANA MUST NOT delegate 220 resolver-addresses.arpa in the .arpa zone. 222 [[ When this document settles down, need to register ".well-known/ 223 doh-servers-associated" as specified in [I-D.nottingham-rfc5785bis]. 224 ]] 226 7. Privacy Considerations 228 Allowing a user to use DoH instead of Do53 increases communication 229 privacy because of the TLS protection. 231 When a Do53 or DoT server indicates that a particular DoH server is 232 associated with it, the client might assume that the DoH server has 233 the same information privacy policies as the Do53 or DoT server. 234 Therefore, a Do53 or DoT server SHOULD NOT recommend a DoH server 235 unless that DoH server has the same (or better) information privacy 236 policy as the Do53 or DoT server. 238 8. Security Considerations 240 There is currently no way for an application to know whether the 241 operating system's stub resolver is using a transport that assures 242 data integrity such as DoT. 244 Even is an application could determine the use of a transport like 245 DoT, the application would also need to know whether the transport 246 was authenticated or was simply chosen opportunistically. 248 9. References 250 9.1. Normative References 252 [I-D.nottingham-rfc5785bis] 253 Nottingham, M., "Well-Known Uniform Resource Identifiers 254 (URIs)", draft-nottingham-rfc5785bis-08 (work in 255 progress), October 2018. 257 [RFC1035] Mockapetris, P., "Domain names - implementation and 258 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 259 November 1987, . 261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", BCP 14, RFC 2119, 263 DOI 10.17487/RFC2119, March 1997, 264 . 266 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 267 and D. Orchard, "URI Template", RFC 6570, 268 DOI 10.17487/RFC6570, March 2012, 269 . 271 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 272 and P. Hoffman, "Specification for DNS over Transport 273 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 274 2016, . 276 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 277 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 278 May 2017, . 280 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 281 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 282 . 284 [SUDN] "Special-Use Domain Names", n.d., 285 . 288 9.2. Informative References 290 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 291 RFC 6761, DOI 10.17487/RFC6761, February 2013, 292 . 294 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 295 for DNS (EDNS(0))", STD 75, RFC 6891, 296 DOI 10.17487/RFC6891, April 2013, 297 . 299 Acknowledgments 301 The use case in this document was inspired by discussions and the 302 DRIU BoF at IETF 102 and later in the DNSOP Working Group. Vladimir 303 Cunat, Philip Homburg, and Shumon Huque offered useful advice to 304 greatly improve an early version of the protocol. 306 Author's Address 308 Paul Hoffman 309 ICANN 311 Email: paul.hoffman@icann.org