idnits 2.17.1 draft-ietf-doh-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 (March 24, 2019) is 1860 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 24, 2019 5 Expires: September 25, 2019 7 Associating a DoH Server with a Resolver 8 draft-ietf-doh-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 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 25, 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 . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. DoH Servers from HTTPS . . . . . . . . . . . . . . . . . . . 4 59 3. DoH Servers from DNS . . . . . . . . . . . . . . . . . . . . 5 60 4. Resolver Addresses from DNS . . . . . . . . . . . . . . . . . 6 61 5. Lists of DoH Servers . . . . . . . . . . . . . . . . . . . . 7 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 9.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Appendix A. Earlier Design Choices . . . . . . . . . . . . . . . 10 69 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 DoH [RFC8484] requires that one or more DoH servers be configured for 75 the DoH client. That document does not say how the DoH servers are 76 found, nor how to select from a list of possible DoH servers, nor 77 what the user interface (UI) for the configuration should be. 79 There is a use case for browsers and web applications to want the DNS 80 recursive resolver(s) configured in the operating system to use DoH 81 for DNS resolution instead of normal DNS, but to do so to at a DoH 82 server specified by the configured resolver. For example, a 83 recursive resolver configured by the operating system may know how to 84 give correct answers to DNS queries that contain names that are only 85 resolvable in the local context, or resolve differently in the local 86 context. Similarly, the recursive resolver configured in the 87 operating system may implement security policies such as malware 88 prevention that are not implemented in the same way in DoH servers 89 not affiliated with the user's organization. Users typically 90 configure their DNS recursive resolvers with through automatic 91 configuration from a protocol such as DHCP; much less often, they use 92 manual configuration (such as manually editing a /etc/resolv.conf 93 file). 95 The expected use cases for DoH are browsers and web applications that 96 would otherwise get their DNS service from the resolver configured by 97 the operating system. The user of the client might have a preference 98 for using a DoH server for the benefits that DoH brings, and they 99 might need to use a DoH server that is associated with the resolver 100 that the computer is currently using for the reasons listed above. 101 In a common scenario, user may be required to use only resolvers that 102 are approved by their organization's network operators. 104 The URI templates of the DoH servers associated with a resolver might 105 be hosted on the resolver itself, or a resolver hosted by the same 106 operator, or even hosted somewhere else. The latter could be used by 107 resolver operators who don't want to host DoH servers but trust 108 another operator to do so. 110 To address these use cases, this document defines protocols to get 111 the list of URI templates [RFC6570] or addresses for the DoH servers 112 associated with at least one of the resolvers being used by the 113 operating system on the system on which the application is being run. 115 o "DoH servers from HTTPS", described in Section 2, is a well-known 116 URI [I-D.nottingham-rfc5785bis] that can be resolved to return the 117 URI templates in an HTTP response. 119 o "DoH servers from DNS", described in Section 3, is a new special 120 use domain name (SUDN) [RFC6761] that can be queried to return the 121 URI templates as a TXT RRset. 123 o "resolver addresses from DNS", described in Section 4, is a new 124 SUDN that that can be queried to return the addresses as A and 125 AAAA RRsets. 127 For these protocols to be useful in a browser, the browser needs to 128 have an entry in its configuration interface where the allowed DoH 129 servers are listed that indicates that a DoH server from the 130 configured Do53 or DoT resolver is allowed. That wording might say 131 something like "DoH server associated with my current resolver" (or 132 "servidor DoH asociado con mi resolucion actual" or "serveur DoH 133 associe a mon resolveur actuel"). Alternatively, these protocols 134 might be the default for a browser, and naming specific other DoH 135 servers might be done with a UI. 137 The protocols described here are meant for a browser to be able to 138 start using DoH based on its current interactions with the resolver 139 from the operating system on which the browser is running: they are 140 not expected to work without being able to do DNS resolution. Even 141 "DoH servers from HTTPS", which ostensibly only needs an IP address, 142 is likely to need DNS resolution for things like OCSP servers during 143 the setup of TLS. 145 1.1. Terminology 147 In this document, "client" means either a browser or web application. 148 When one or the other is named explicitly, 150 In this document, "browser" means any application that can open ports 151 in the operating system. This odd usage of the term "browser" is 152 adopted from [RFC8484]. 154 In this document, "DoT" is used to indicate DNS over TLS as defined 155 in [RFC7858]. 157 In this document, "Do53" is used to indicate DNS over UDP or TCP as 158 defined in [RFC1035]. 160 "DoH client" and "DoH server" are defined in [RFC8484]. 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in BCP 165 14 [RFC2119] [RFC8174] when, and only when, they appear in all 166 capitals, as shown here. 168 2. DoH Servers from HTTPS 170 To find the URI templates for DoH servers associated with a resolver 171 whose address is already known, a browser or web application can use 172 the well-known URI described in this section. To find the IP address 173 of the resolver used by the operating system on which a browser is 174 running, a browser can use either an operating system function (if 175 such a function is available to it) or the process described in 176 Section 4. (A web application can also use the process described in 177 Section 4, and thus use this well-known URI.) 179 To find the DoH servers associated with a resolver, the client MUST 180 use the following query: 182 https://IPADDRESSGOESHERE/.well-known/doh-servers-associated/ 184 The resolver replies with its associated DoH servers as URI templates 185 [RFC6570]. The HTTP response header MUST contain an appropriate HTTP 186 status code as defined in [RFC7231]. Successful responses MUST set 187 the Content-Type set to "application/json". 189 The returned JSON object [RFC8259] MUST contain a member whose name 190 is "associated-resolvers" and whose value is a JSON array. The array 191 contains zero or more JSON strings, each of which is a single URI 192 template. 194 If the array of URI templates returned is empty, that indicates that 195 the resolver does not have any DoH servers associated with it. 197 For example, the returned object might look like: 199 { "associated-resolvers": 200 [ "https://dnsserver.example.net/dns-query{?dns}", 201 "https://webhost.example.net/a/b/c/dns-query{?dns}" ] 202 } 204 If there are no associated DoH servers, the returned object would 205 look like: 207 { "associated-resolvers": [ ] } 209 If the TLS authentication for the query fails, the browser MUST abort 210 the connection without sending the HTTP request, and it cannot assume 211 anything about whether the resolver has any DoH servers associated 212 with it. 214 A client using this protocol MUST try to establish a new list of DoH 215 servers associated with a resolver every time the configured resolver 216 in the operating system changes. 218 The HTTP query follows all the normal rules for HTTP. Thus, the 219 result of sending this query can be an HTTP redirect to a different 220 server. Also, the result of the query might be served from an HTTP 221 cache. 223 3. DoH Servers from DNS 225 To find the URI templates for DoH servers associated with a resolver, 226 a browser sends that resolver a query for "resolver-associated- 227 doh.arpa" in class IN with the RRtype of TXT [RFC1035] (that is, the 228 query is resolver-associated-doh.arpa/IN/TXT). This protocol is most 229 likely useful only to browsers that can call operating system 230 functions that in turn query the DNS for text records. Web 231 applications cannot currently call such operating system functions. 233 As described in Section 6, the zone resolver-associated-doh.arpa is 234 not actually delegated and never will be. The resolver that receives 235 this query acts as if it is delegated, and adds its own TXT records 236 to the answer. The resolver replies with its associated DoH servers 237 as URI templates in the TXT RRset in the Answer section. The 238 resolver can generate this reply with special code to capture queries 239 for "resolver-associated-doh.arpa"; if the resolver can be configured 240 to also be authoritative for some zones, it can use that 241 configuration to actually be authoritative for "resolver-associated- 242 doh.arpa". 244 A resolver that understands this protocol MUST send a TXT RRset in 245 the Answer section. Each TXT record contains one URI template. If a 246 resolver that understands this protocol has no associated DoH 247 servers, the TXT RRset contains exactly one record that has an empty 248 string as the RDATA; that is, the RDLENGTH in that record is 1, and 249 the RDATA contains just the byte 0x00. 251 An example of the TXT RRset (in DNS master file format) might be: 253 $ORIGIN resolver-associated-doh.arpa. 254 IN TXT "https://dnsserver.example.net/dns-query{?dns}" 255 IN TXT "https://webhost.example.net/a/b/c/dns-query{?dns}" 257 If there are no associated DoH servers, an example of the the TXT 258 RRset (in DNS master file format) might be: 260 $ORIGIN resolver-associated-doh.arpa. 261 IN TXT "" 263 The client uses the TXT records in the response to the resolver- 264 associated-doh.arpa/IN/TXT query as a list of the URI templates of 265 the DoH servers associated with the resolver. Note that TXT records 266 can contain multiple "character-strings" [RFC1035]; for this 267 protocol, all characters-strings in a TXT record are concatenated to 268 form a single URI template. 270 A client using this protocol MUST try to establish a new list of DoH 271 servers associated with a resolver every time the configured resolver 272 in the operating system changes. 274 4. Resolver Addresses from DNS 276 Browsers which cannot get the IP address(es) of the resolver 277 configured by the operating system using APIs are still able to use 278 an operating system function such as gethostbyname() or its 279 equivalents to convert host names into IP addresses through the stub 280 resolver in the operating system on which they are running. Web 281 applications also can convert host names to IP addresses. Either can 282 use a new SUDN to find the address(es) of the resolvers configured by 283 the operating system. 285 A browser or web application uses it normal interface for getting IP 286 addresses for a hostname, and uses the SUDN "resolver-addresses.arpa" 287 as the hostname. 289 As described in Section 6, the zone resolver-addresses.arpa is not 290 actually delegated and never will be. The resolver acts as if that 291 name is delegated, and returns its own A or AAAA addresses in the 292 records in the answer. The resolver can generate this reply with 293 special code to capture queries for "resolver-addresses.arpa"; if the 294 resolver can be configured to also be authoritative for some zones, 295 it can use that configuration to actually be authoritative for 296 "resolver-addresses.arpa". 298 A client using this protocol MUST try to establish a new list of DoH 299 servers associated with a resolver every time the configured resolver 300 in the operating system changes. 302 5. Lists of DoH Servers 304 The "DoH servers from HTTPS" "DoH servers from DNS" return lists of 305 DoH servers, and those lists can have more than one element. The DoH 306 client can choose any of the servers in the list; that is, there is 307 no inherent "preference" for any of the serers returned. From a 308 mathematical viewpoint, the lists can better be considered as sets. 310 6. IANA Considerations 312 IANA will record the domain name "resolver-associated-doh.arpa" in 313 the "Special-Use Domain Names" registry [SUDN]. IANA MUST NOT 314 delegate resolver-associated-doh.arpa in the .arpa zone. 316 IANA will record the domain name "resolver-addresses.arpa" in the 317 "Special-Use Domain Names" registry [SUDN]. IANA MUST NOT delegate 318 resolver-addresses.arpa in the .arpa zone. 320 Before this draft is complete, mail will be sent to wellknown-uri- 321 review@ietf.org in order to be registered in the "Well-Known URIs" 322 registry at IANA. The mail will contain the following: 324 URI suffix: doh-servers-associated 325 Change controller: IETF 326 Specification document(s): draft-ietf-doh-resolver-associated-doh 327 Status: permanent 329 7. Privacy Considerations 331 Allowing a user to use DoH to a server associated with the resolver 332 in use by the operating system on the user's machine, instead of 333 using Do53 to to the resolver in use by the operating system on the 334 user's machine, can increase communication privacy because of the TLS 335 protection. However, using a DoH server can also reduce overall 336 privacy because both TLS and HTTPS allow for user identification in 337 ways that plain Do53 does not. 339 When a Do53 or DoT server indicates that a particular DoH server is 340 associated with it, the client might assume that the DoH server has 341 the same information privacy policies as the Do53 or DoT server. 342 Therefore, a Do53 or DoT server SHOULD NOT recommend a DoH server 343 unless that DoH server has the same (or better) information privacy 344 policy as the Do53 or DoT server. 346 A browser that has both a stub resolver stack and a TLS stack that is 347 independent of HTTP could make a DoT connection to the resolver being 348 used by the operating system. 350 8. Security Considerations 352 If DNS queries sent from stub resolvers to recursive resolvers are 353 not sent over transports that assure data integrity and server 354 authentication, the "DoH servers from DNS" and "Resolver addresses 355 from DNS" protocols are susceptible to on-path attackers directing a 356 user to a DoH server that is not actually associated with their 357 resolver. Do53 is not a secure transport, and neither is DoT using 358 the opportunistic profile. 360 The DNS responses used in "DoH servers from DNS" and "Resolver 361 addresses from DNS" cannot be validated with DNSSEC [RFC4033], and 362 thus even a validating stub resolver would treat them the same as any 363 other DNS responses in unsigned zones. 365 There is currently no way for an application to know whether the 366 operating system's stub resolver is using a transport that assures 367 data integrity such as DoT. Even if an application could determine 368 the use of a transport like DoT, the application would also need to 369 know whether the transport was authenticated or was simply chosen 370 opportunistically. 372 9. References 374 9.1. Normative References 376 [I-D.nottingham-rfc5785bis] 377 Nottingham, M., "Well-Known Uniform Resource Identifiers 378 (URIs)", draft-nottingham-rfc5785bis-09 (work in 379 progress), February 2019. 381 [RFC1035] Mockapetris, P., "Domain names - implementation and 382 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 383 November 1987, . 385 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 386 Requirement Levels", BCP 14, RFC 2119, 387 DOI 10.17487/RFC2119, March 1997, 388 . 390 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 391 and D. Orchard, "URI Template", RFC 6570, 392 DOI 10.17487/RFC6570, March 2012, 393 . 395 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 396 and P. Hoffman, "Specification for DNS over Transport 397 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 398 2016, . 400 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 401 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 402 May 2017, . 404 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 405 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 406 . 408 [SUDN] "Special-Use Domain Names", n.d., 409 . 412 9.2. Informative References 414 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 415 Rose, "DNS Security Introduction and Requirements", 416 RFC 4033, DOI 10.17487/RFC4033, March 2005, 417 . 419 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 420 RFC 6761, DOI 10.17487/RFC6761, February 2013, 421 . 423 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 424 for DNS (EDNS(0))", STD 75, RFC 6891, 425 DOI 10.17487/RFC6891, April 2013, 426 . 428 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 429 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 430 DOI 10.17487/RFC7231, June 2014, 431 . 433 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 434 Interchange Format", STD 90, RFC 8259, 435 DOI 10.17487/RFC8259, December 2017, 436 . 438 Appendix A. Earlier Design Choices 440 The primary use case for these protocols is a browser or web 441 application that is getting name resolution through the stub resolver 442 on the computer on which it is running wanting to switch its name 443 resolution to DoH. 445 An earlier design suggestion was to use a new RRtype with a query to 446 ./IN/NEWRRTYPE. However, it was pointed out that this would not work 447 going through stub resolvers that validate DNSSEC. 449 An earlier design suggestion was to use DHCP to tell the operating 450 system the DoH servers that the stub resolver might use. That 451 protocol is orthogonal to the one in this document in that it 452 addresses a different use case. If both the protocol in this 453 document and a DHCP-based protocol are standardized, they could co- 454 exist. However, there is no current mechanism for a stub resolver to 455 tell a browser, or a web application, what DoH server the stub 456 resolver is using, so DoH configuration in the stub resolver would 457 not prevent the browser from trying to find a DoH server on its own. 459 An earlier design suggestion was to use an EDNS0 [RFC6891] extension. 460 The design chosen in this document meets the use case better because 461 applications cannot communicate EDNS0 extensions to the stub 462 resolver. 464 Acknowledgments 466 The use case in this document was inspired by discussions and the 467 DRIU BoF at IETF 102 and later in the DNSOP Working Group. Vladimir 468 Cunat, Philip Homburg, Shumon Huque, Martin Thomson, Eric Rescorla, 469 and Tony Finch offered useful advice to improve versions of the 470 protocol before it came to the DOH Working Group. 472 Author's Address 474 Paul Hoffman 475 ICANN 477 Email: paul.hoffman@icann.org