idnits 2.17.1 draft-ietf-doh-resolver-associated-doh-02.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 (March 06, 2019) is 1877 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-09 -- Possible downref: Non-RFC (?) normative reference: ref. 'SUDN' -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 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 March 06, 2019 5 Expires: September 7, 2019 7 Associating a DoH Server with a Resolver 8 draft-ietf-doh-resolver-associated-doh-02 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 17 two protocols for a resolver to tell a client what its associated DoH 18 servers are. It also describes a protocol for a client to find out 19 the address of the resolver it is using, if it cannot find that 20 address by an operating system API or some other means. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 7, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. DoH Servers from HTTPS . . . . . . . . . . . . . . . . . . . 4 59 3. DoH Servers from DNS . . . . . . . . . . . . . . . . . . . . 5 60 4. Resolver Addresses from DNS . . . . . . . . . . . . . . . . . 6 61 5. Issues Common to "DoH Servers from DNS" and "Resolver 62 Addresses from DNS" . . . . . . . . . . . . . . . . . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 9.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Appendix A. Earlier Design Choices . . . . . . . . . . . . . . . 9 70 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 DoH [RFC8484] requires that one or more DoH servers be configured for 76 the DoH client. That document does not say how the DoH servers are 77 found, nor how to select from a list of possible DoH servers, nor 78 what the user interface (UI) for the configuration should be. 80 There is a use case for browsers and web applications to want the DNS 81 recursive resolver(s) configured in the operating system to use DoH 82 for DNS resolution instead of normal DNS, but to do so to at a DoH 83 server specified by the configured resolver. For example, a 84 recursive resolver configured by the operating system may know how to 85 give correct answers to DNS queries that contain names that are only 86 resolvable in the local context, or resolve differently in the local 87 context. Similarly, the recursive resolver configured in the 88 operating system may implement security policies such as malware 89 prevention that are not implemented in the same way in DoH servers 90 not affiliated with the user's organization. Users typically 91 configure their DNS recursive resolvers with through automatic 92 configuration from a protocol such as DHCP; much less often, they use 93 manual configuration (such as manually editing a /etc/resolv.conf 94 file). 96 The expected use cases for DoH are browsers and web applications that 97 would otherwise get their DNS service from the resolver configured by 98 the operating system. The user of the client might have a preference 99 for using a DoH server for the benefits that DoH brings, and they 100 might need to use a DoH server that is associated with the resolver 101 that the computer is currently using for the reasons listed above. 102 In a common scenario, user may be required to use only resolvers that 103 are approved by their organization's network operators. 105 The URI templates of the DoH servers associated with a resolver might 106 be hosted on the resolver itself, or a resolver hosted by the same 107 operator, or even hosted somewhere else. The latter could be used by 108 resolver operators who don't want to host DoH servers but trust 109 another operator to do so. 111 To address these use cases, this document defines protocols to get 112 the list of URI templates [RFC6570] or addresses for the DoH servers 113 associated with at least one of the resolvers being used by the 114 operating system on the system on which the application is being run. 116 o "DoH servers from HTTPS", described in Section 2, is a well-known 117 URI [I-D.nottingham-rfc5785bis] that can be resolved to return the 118 URI templates in an HTTP response. 120 o "DoH servers from DNS", described in Section 3, is a new special 121 use domain name (SUDN) [RFC6761] that can be queried to return the 122 URI templates as a TXT RRset. 124 o "resolver addresses from DNS", described in Section 4, is a new 125 SUDN that that can be queried to return the addresses as A and 126 AAAA RRsets. 128 For these protocols to be useful in a browser, the browser needs to 129 have an entry in its configuration interface where the allowed DoH 130 servers are listed that indicates that a DoH server from the 131 configured Do53 or DoT resolver is allowed. That wording might say 132 something like "DoH server associated with my current resolver" (or 133 "servidor DoH asociado con mi resolucion actual" or "serveur DoH 134 associe a mon resolveur actuel"). Alternatively, these protocols 135 might be the default for a browser, and naming specific other DoH 136 servers might be done with a UI. 138 1.1. Terminology 140 In this document, "client" means either a web browser or application. 141 When one or the other is named explicitly, 142 In this document, "DoT" is used to indicate DNS over TLS as defined 143 in [RFC7858]. 145 In this document, "Do53" is used to indicate DNS over UDP or TCP as 146 defined in [RFC1035]. 148 "DoH client" and "DoH server" are defined in [RFC8484]. 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in BCP 153 14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 2. DoH Servers from HTTPS 158 To find the URI templates for DoH servers associated with a resolver 159 whose address is already known, a browser or web application can use 160 the well-known URI described in this section. To find the IP address 161 of the resolver used by the operating system on which a browser is 162 running, a browser can use either an operating system function (if 163 such a function is available to it) or the process described in 164 Section 4. (A web application can also use the process described in 165 Section 4, and thus use this well-known URI.) 167 To find the DoH servers associated with a resolver, the client MUST 168 use the following query: 170 https://IPADDRESSGOESHERE/.well-known/doh-servers-associated/ 172 The resolver replies with its associated DoH servers as URI templates 173 [RFC6570]. The HTTP response header MUST contain an appropriate HTTP 174 status code as defined in [RFC7231]. Successful responses MUST set 175 the Content-Type set to "application/json". 177 The returned JSON object [RFC8259] MUST contain a member whose name 178 is "associated-resolvers" and whose value is a JSON array. The array 179 contains zero or more JSON strings, each of which is a single URI 180 template. 182 If the array of URI templates returned is empty, that indicates that 183 the resolver does not have any DoH servers associated with it. 185 If the TLS authentication for the query fails, the browser MUST abort 186 the connection without sending the HTTP request, and it cannot assume 187 anything about whether the resolver has any DoH servers associated 188 with it. 190 A client using this protocol MUST try to establish a new list of DoH 191 servers associated with a resolver every time the configured resolver 192 in the operating system changes. 194 The HTTP query follows all the normal rules for HTTP. Thus, the 195 result of sending this query can be an HTTP redirect to a different 196 server. Also, the result of the query might be served from an HTTP 197 cache. 199 3. DoH Servers from DNS 201 To find the URI templates for DoH servers associated with a resolver, 202 a browser sends that resolver a query for "resolver-associated- 203 doh.arpa" in class IN with the RRtype of TXT [RFC1035] (that is, the 204 query is resolver-associated-doh.arpa/IN/TXT). This protocol is most 205 likely useful only to browsers that can call operating system 206 functions that in turn query the DNS for text records. Web 207 applications cannot currently call such operating system functions. 209 As described in Section 6, the zone resolver-associated-doh.arpa is 210 not actually delegated and never will be. The resolver that receives 211 this query acts as if it is delegated, and adds its own TXT records 212 to the answer. The resolver replies with its associated DoH servers 213 as URI templates in the TXT RRset in the Answer section. The 214 resolver can generate this reply with special code to capture queries 215 for "resolver-associated-doh.arpa"; if the resolver can be configured 216 to also be authoritative for some zones, it can use that 217 configuration to actually be authoritative for "resolver-associated- 218 doh.arpa". 220 A resolver that understands this protocol MUST send a TXT RRset in 221 the Answer section. Each TXT record contains one URI template. If a 222 resolver that understands this protocol has no associated DoH 223 servers, the TXT RRset contains exactly one record that has an empty 224 string as the RDATA; that is, the RDLENGTH in that record is 1, and 225 the RDATA contains just the byte 0x00. 227 The client uses the TXT records in the response to the resolver- 228 associated-doh.arpa/IN/TXT query as a list of the URI templates of 229 the DoH servers associated with the resolver. Note that TXT records 230 can contain multiple "character-strings" [RFC1035]; for this 231 protocol, all characters-strings in a TXT record are concatenated to 232 form a single URI template. 234 4. Resolver Addresses from DNS 236 Browsers which cannot get the IP address(es) of the resolver 237 configured by the operating system using APIs are still able to use 238 an operating system function such as gethostbyname() or its 239 equivalents to convert host names into IP addresses through the stub 240 resolver in the operating system on which they are running. Web 241 applications also can convert host names to IP addresses. Either can 242 use a new SUDN to find the address(es) of the resolvers configured by 243 the operating system. 245 A browser or web application uses it normal interface for getting IP 246 addresses for a hostname, and uses the SUDN "resolver-addresses.arpa" 247 as the hostname. 249 As described in Section 6, the zone resolver-addresses.arpa is not 250 actually delegated and never will be. The resolver acts as if that 251 name is delegated, and returns its own A or AAAA addresses in the 252 records in the answer. The resolver can generate this reply with 253 special code to capture queries for "resolver-addresses.arpa"; if the 254 resolver can be configured to also be authoritative for some zones, 255 it can use that configuration to actually be authoritative for 256 "resolver-addresses.arpa". 258 5. Issues Common to "DoH Servers from DNS" and "Resolver Addresses from 259 DNS" 261 See Section 8 for warnings about sending the DNS queries over a 262 transport that does not assure data integrity (such as Do53), and 263 over a transport that does assure data integrity (such as DoT) but in 264 circumstances where the browser doesn't know the type of DNS 265 transport being used. 267 A client MUST re-issue the queries in "DoH Servers from DNS" and 268 "Resolver Addresses from DNS" every time the configured resolver in 269 the operating system changes. 271 6. IANA Considerations 273 IANA will record the domain name "resolver-associated-doh.arpa" in 274 the "Special-Use Domain Names" registry [SUDN]. IANA MUST NOT 275 delegate resolver-associated-doh.arpa in the .arpa zone. 277 IANA will record the domain name "resolver-addresses.arpa" in the 278 "Special-Use Domain Names" registry [SUDN]. IANA MUST NOT delegate 279 resolver-addresses.arpa in the .arpa zone. 281 Before this draft is complete, mail will be sent to wellknown-uri- 282 review@ietf.org in order to be registered in the "Well-Known URIs" 283 registry at IANA. The mail will contain the following: 285 URI suffix: doh-servers-associated 286 Change controller: IETF 287 Specification document(s): draft-ietf-doh-resolver-associated-doh 288 Status: permanent 290 7. Privacy Considerations 292 Allowing a user to use DoH instead of Do53 increases communication 293 privacy because of the TLS protection. 295 When a Do53 or DoT server indicates that a particular DoH server is 296 associated with it, the client might assume that the DoH server has 297 the same information privacy policies as the Do53 or DoT server. 298 Therefore, a Do53 or DoT server SHOULD NOT recommend a DoH server 299 unless that DoH server has the same (or better) information privacy 300 policy as the Do53 or DoT server. 302 A browser that has both a stub resolver stack and a TLS stack that is 303 independent of HTTP could make a DOT connection to the resolver being 304 used by the operating system. 306 8. Security Considerations 308 There is currently no way for an application to know whether the 309 operating system's stub resolver is using a transport that assures 310 data integrity such as DoT. 312 Even is an application could determine the use of a transport like 313 DoT, the application would also need to know whether the transport 314 was authenticated or was simply chosen opportunistically. 316 9. References 318 9.1. Normative References 320 [I-D.nottingham-rfc5785bis] 321 Nottingham, M., "Well-Known Uniform Resource Identifiers 322 (URIs)", draft-nottingham-rfc5785bis-09 (work in 323 progress), February 2019. 325 [RFC1035] Mockapetris, P., "Domain names - implementation and 326 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 327 November 1987, . 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, 331 DOI 10.17487/RFC2119, March 1997, 332 . 334 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 335 and D. Orchard, "URI Template", RFC 6570, 336 DOI 10.17487/RFC6570, March 2012, 337 . 339 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 340 and P. Hoffman, "Specification for DNS over Transport 341 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 342 2016, . 344 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 345 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 346 May 2017, . 348 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 349 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 350 . 352 [SUDN] "Special-Use Domain Names", n.d., 353 . 356 9.2. Informative References 358 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 359 RFC 6761, DOI 10.17487/RFC6761, February 2013, 360 . 362 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 363 for DNS (EDNS(0))", STD 75, RFC 6891, 364 DOI 10.17487/RFC6891, April 2013, 365 . 367 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 368 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 369 DOI 10.17487/RFC7231, June 2014, 370 . 372 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 373 Interchange Format", STD 90, RFC 8259, 374 DOI 10.17487/RFC8259, December 2017, 375 . 377 Appendix A. Earlier Design Choices 379 The primary use case for these protocols is a browser or web 380 application that is getting name resolution through the stub resolver 381 on the computer on which it is running wanting to switch its name 382 resolution to DoH. 384 An earlier design suggestion was to use a new RRtype with a query to 385 ./IN/NEWRRTYPE. However, it was pointed out that this would not work 386 going through stub resolvers that validate DNSSEC. 388 An earlier design suggestion was to use DHCP to tell the operating 389 system the DoH servers that the stub resolver might use. That 390 protocol is orthogonal to the one in this document in that it 391 addresses a different use case. If both the protocol in this 392 document and a DHCP-based protocol are standardized, they could co- 393 exist. However, there is no current mechanism for a stub resolver to 394 tell a browser, or a web application, what DoH server the stub 395 resolver is using, so DoH configuration in the stub resolver would 396 not prevent the browser from trying to find a DoH server on its own. 398 An earlier design suggestion was to use an EDNS0 [RFC6891] extension. 399 The design chosen in this document meets the use case better because 400 applications cannot communicate EDNS0 extensions to the stub 401 resolver. 403 Acknowledgments 405 The use case in this document was inspired by discussions and the 406 DRIU BoF at IETF 102 and later in the DNSOP Working Group. Vladimir 407 Cunat, Philip Homburg, Shumon Huque, Martin Thomson, Eric Rescorla, 408 and Tony Finch offered useful advice to improve versions of the 409 protocol before it came to the DOH Working Group. 411 Author's Address 413 Paul Hoffman 414 ICANN 416 Email: paul.hoffman@icann.org