idnits 2.17.1 draft-hoffman-resolver-associated-doh-07.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 (December 14, 2018) is 1960 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 December 14, 2018 5 Expires: June 17, 2019 7 Associating a DoH Server with a Resolver 8 draft-hoffman-resolver-associated-doh-07 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 June 17, 2019. 39 Copyright Notice 41 Copyright (c) 2018 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. Finding the URI Templates of the DoH Servers Associated with 59 a Resolver . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. DoH Servers by TXT . . . . . . . . . . . . . . . . . . . 4 61 2.2. DoH Servers by Addresses . . . . . . . . . . . . . . . . 5 62 2.3. Issues Common to "DoH Servers by TXT" and "Resolver 63 Addresses by SUDN" . . . . . . . . . . . . . . . . . . . 6 64 3. Finding the Resolver Addresses Without Operating System APIs 6 65 4. User Interface . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 7 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 9.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 DoH [RFC8484] requires that one or more DoH servers be configured for 79 the DoH client. That document does not say how the DoH servers are 80 found, nor how to select from a list of possible DoH servers, nor 81 what the user interface (UI) for the configuration should be. 83 There is a use case for browsers and web applications to want the DNS 84 recursive resolver(s) configured in the operating system to use DoH 85 for DNS resolution instead of normal DNS, but to do so to at a DoH 86 server specified by the configured resolver. For example, a 87 recursive resolver configured by the operating system may know how to 88 give correct answers to DNS queries that contain names that are only 89 resolvable in the local context, or resolve differently in the local 90 context. Similarly, the recursive resolver configured in the 91 operating system may implement security policies such as malware 92 prevention that are not implemented in the same way in DoH servers 93 not affiliated with the user's organization. Users typically 94 configure their DNS recursive resolvers with through automatic 95 configuration from a protocol such as DHCP; much less often, they use 96 manual configuration (such as manually editing a /etc/named.conf 97 file). 99 The expected use cases for DoH are browsers and web applications that 100 would otherwise get their DNS service from the resolver configured by 101 the operating system. The user of the client might have a preference 102 for using a DoH server for the benefits that DoH brings, and they 103 might need to use a DoH server that is associated with the resolver 104 that the computer is currently using for the reasons listed above. 105 In a common scenario, user may be required to use only resolvers that 106 are approved by their organization's network operators. 108 To address these use cases, this document defines two protocols to 109 get the list of URI templates [RFC6570] for the DoH servers 110 associated with at least one of the resolvers being used by the 111 operating system on the system on which the application is being run. 113 o The first, called "DoH servers by TXT" and described in 114 Section 2.1, is a new special use domain name (SUDN) [RFC6761] 115 that can be queried for a TXT RRset. This protocol is most likely 116 useful only to browsers that can call operating system functions 117 that in turn query the DNS for text records; web applications can 118 only query for IP addresses. 120 o The second, called "DoH servers by addresses" and described in 121 Section 2.2, is a well-known URI [I-D.nottingham-rfc5785bis] that 122 can be resolved to return the URI templates. This is useful if a 123 browser can call operating system functions that will return the 124 address of the recursive DNS resolver that the operating system is 125 currently using. 127 This document also defines a third protocol, called "resolver 128 addresses by SUDN" and described in Section 3, that is a new SUDN 129 that that can be queried for the IP address(es) of a resolver. This 130 protocol is useful for a client that can query for the addresses 131 associated with a domain name (such as using the POSIX 132 "getaddrinfo()" function) but cannot use an operating system function 133 to find those addresses. For browsers, it is only needed if the 134 browser cannot use an API to determine the configured resolver IP 135 address(es). 137 The design choices for this protocol, particularly earlier designs 138 that were deemed unusable, are described in Section 5. 140 1.1. Terminology 142 In this document, "client" means either a web browser or application. 143 When one or the other is named explicitly, 145 In this document, "DoT" is used to indicate DNS over TLS as defined 146 in [RFC7858]. 148 In this document, "Do53" is used to indicate DNS over UDP or TCP as 149 defined in [RFC1035]. 151 "DoH client" and "DoH server" are defined in [RFC8484]. 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 2. Finding the URI Templates of the DoH Servers Associated with a 160 Resolver 162 A client (a browser or web application) uses either the protocol in 163 Section 2.1 or Section 2.2 to get a list of URI templates for the DoH 164 servers associated with a resolver. The following sub-sections 165 describe the protocols and have notes that are common to both 166 protocols. 168 2.1. DoH Servers by TXT 170 To find the DoH Servers associated with a resolver, an application 171 sends that resolver a query for "resolver-associated-doh.arpa" in 172 class IN with the RRtype of TXT [RFC1035] (that is, the query is 173 resolver-associated-doh.arpa/IN/TXT). 175 As described in Section 6, the zone resolver-associated-doh.arpa is 176 not actually delegated and never will be. The resolver acts as if it 177 is delegated, and adds its own TXT records to the answer. The 178 resolver replies with its associated DoH servers as URI templates in 179 the TXT RRset in the Answer section. The resolver can generate this 180 reply with special code to capture queries for "resolver-associated- 181 doh.arpa"; if the resolver can be configured to also be authoritative 182 for some zones, it can use that configuration to actually be 183 authoritative for "resolver-associated-doh.arpa". 185 A resolver that understands this protocol MUST send a TXT RRset in 186 the Answer section. Each TXT record contains one URI template. If a 187 resolver that understands this protocol has no associated DoH 188 servers, the TXT RRset contains exactly one record that has an empty 189 string as the RDATA; that is, the RDLENGTH in that record is 1, and 190 the RDATA contains just the byte 0x00. 192 The client uses the TXT records in the response to the resolver- 193 associated-doh.arpa/IN/TXT query as a list of the URI templates of 194 the DoH servers associated with the resolver. Note that TXT records 195 can contain multiple "character-strings" [RFC1035]; for this 196 protocol, all characters-strings in a TXT record are concatenated to 197 form a single URI template. 199 The URI templates of the DoH servers associated with a resolver might 200 be hosted on the resolver itself, or a resolver hosted by the same 201 operator, or even hosted somewhere else. The latter could be used by 202 resolver operators who don't want to host DoH servers but trust 203 another operator to do so. 205 2.2. DoH Servers by Addresses 207 To find the DoH servers associated with a resolver, a browser or web 208 application uses either an operating system function (if such a 209 function is available to it) or the process described in Section 3 to 210 find one or more IP addresses for the resolver. It uses one or more 211 of those IP addresses as part of a well-known URI to find out the URI 212 templates [RFC6570] to use for the DoH server(s) associated with the 213 resolver. 215 To find the DoH servers associated with a resolver, the client sends 216 a query to 218 https://IPADDRESSGOESHERE/.well-known/doh-servers-associated/ 220 The resolver replies with its associated DoH servers as URI templates 221 [RFC6570]. 223 [[ Need to describe the media types; likely JSON ]] 225 [[ Need to talk about what a response with an empty list means ]] 227 [[ Need to talk about what happens if authentication fails. This is 228 complicated by the fact that the application doesn't know if the OS- 229 to-resolver communication is authenticated. ]] 231 [[ Need to talk about HTTP caching ]] 233 A client MUST try to establish a new list of DoH servers associated 234 with a resolver every time the configured resolver in the operating 235 system changes. 237 The result of sending this query can be an HTTP redirect to a 238 different server, such as when a resolver operator doesn't want to 239 run its own DoH server. 241 2.3. Issues Common to "DoH Servers by TXT" and "Resolver Addresses by 242 SUDN" 244 See Section 8 for warnings about sending the DNS queries over a 245 transport that does not assure data integrity (such as Do53), and 246 over a transport that does assure data integrity (such as DoT) but in 247 circumstances where the browser or web application doesn't know the 248 type of DNS transport being used. 250 A client MUST re-issue the queries in {#doh_by_txt} and 251 {#resolver_by_sudn} every time the configured resolver in the 252 operating system changes. 254 [[ What if there is a list of DoH servers? Pick one (how?) or jump 255 around? ]] 257 3. Finding the Resolver Addresses Without Operating System APIs 259 Browsers can often, but not always, get the IP address(es) of the 260 resolver configured by the operating system using APIs. Browsers 261 which cannot are still able to use an operating system function such 262 as gethostbyname() or its equivalents to convert host names into IP 263 addresses through the stub resolver in the operating system on which 264 they are running. Web applications also can convert host names to IP 265 addresses. Either can use a new protocol to find the address(es) of 266 the resolvers configured by the operating system. 268 In this protocol, the browser or web application uses it normal 269 interface for getting addresses for a hostname, and uses the SUDN 270 "resolver-addresses.arpa" as the hostname. As described in 271 Section 6, the zone resolver-addresses.arpa is not actually delegated 272 and never will be. The resolver acts as if that name is delegated, 273 and returns its own A or AAAA addresses in the records in the answer. 274 The resolver can generate this reply with special code to capture 275 queries for "resolver-addresses.arpa"; if the resolver can be 276 configured to also be authoritative for some zones, it can use that 277 configuration to actually be authoritative for "resolver- 278 addresses.arpa". 280 4. User Interface 282 For this protocol to be useful in a browser, the browser needs to 283 have an entry in its configuration interface where the allowed DoH 284 servers are listed that indicates that a DoH server from the 285 configured Do53 or DoT resolver is allowed. That wording might say 286 something like "DoH server associated with my current resolver" (or 287 "servidor DoH asociado con mi resolucion actual" or "serveur DoH 288 associe a mon resolveur actuel"). 290 5. Design Choices 292 The primary use case for this protocol is a browser or web 293 application that is getting name resolution through the stub resolver 294 on the computer on which it is running wanting to switch its name 295 resolution to DoH. A secondary use case is an operating system that 296 wants to make a similar switch. 298 An earlier design suggestion was to use a new RRtype with a query to 299 ./IN/NEWRRTYPE. However, it was pointed out that this would not work 300 going through stub resolvers that validate DNSSEC. 302 An earlier design suggestion was to use DHCP to tell the operating 303 system the DoH servers that the stub resolver might use. That 304 protocol is orthogonal to the one in this document in that it 305 addresses a different use case. If both the protocol in this 306 document and a DHCP-based protocol are standardized, they could co- 307 exist. However, there is no current mechanism for a stub resolver to 308 tell a browser, or a web application, what DoH server the stub 309 resolver is using, so DoH configuration in the stub resolver would 310 not prevent the browser from trying to find a DoH server on its own. 312 An earlier design suggestion was to use an EDNS0 [RFC6891] extension. 313 The design chosen in this document meets the use case better because 314 applications cannot communicate EDNS0 extensions to the stub 315 resolver. 317 6. IANA Considerations 319 IANA will record the domain name "resolver-associated-doh.arpa" in 320 the "Special-Use Domain Names" registry [SUDN]. IANA MUST NOT 321 delegate resolver-associated-doh.arpa in the .arpa zone. 323 IANA will record the domain name "resolver-addresses.arpa" in the 324 "Special-Use Domain Names" registry [SUDN]. IANA MUST NOT delegate 325 resolver-addresses.arpa in the .arpa zone. 327 Before this draft is complete, mail will be sent to wellknown-uri- 328 review@ietf.org in order to be registered in the "Well-Known URIs" 329 registry at IANA. The mail will contain the following: 331 URI suffix: doh-servers-associated 332 Change controller: IETF 333 Specification document(s): draft-hoffman-resolver-associated-doh 334 (or its successor, if it is adopted in a WG) 335 Status: permanent 337 7. Privacy Considerations 339 Allowing a user to use DoH instead of Do53 increases communication 340 privacy because of the TLS protection. 342 When a Do53 or DoT server indicates that a particular DoH server is 343 associated with it, the client might assume that the DoH server has 344 the same information privacy policies as the Do53 or DoT server. 345 Therefore, a Do53 or DoT server SHOULD NOT recommend a DoH server 346 unless that DoH server has the same (or better) information privacy 347 policy as the Do53 or DoT server. 349 A browser that has both a stub resolver stack and a TLS stack that is 350 independent of HTTP could make a DOT connection to the resolver being 351 used by the operating system. 353 8. Security Considerations 355 There is currently no way for an application to know whether the 356 operating system's stub resolver is using a transport that assures 357 data integrity such as DoT. 359 Even is an application could determine the use of a transport like 360 DoT, the application would also need to know whether the transport 361 was authenticated or was simply chosen opportunistically. 363 9. References 365 9.1. Normative References 367 [I-D.nottingham-rfc5785bis] 368 Nottingham, M., "Well-Known Uniform Resource Identifiers 369 (URIs)", draft-nottingham-rfc5785bis-08 (work in 370 progress), October 2018. 372 [RFC1035] Mockapetris, P., "Domain names - implementation and 373 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 374 November 1987, . 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, 378 DOI 10.17487/RFC2119, March 1997, 379 . 381 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 382 and D. Orchard, "URI Template", RFC 6570, 383 DOI 10.17487/RFC6570, March 2012, 384 . 386 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 387 and P. Hoffman, "Specification for DNS over Transport 388 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 389 2016, . 391 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 392 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 393 May 2017, . 395 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 396 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 397 . 399 [SUDN] "Special-Use Domain Names", n.d., 400 . 403 9.2. Informative References 405 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 406 RFC 6761, DOI 10.17487/RFC6761, February 2013, 407 . 409 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 410 for DNS (EDNS(0))", STD 75, RFC 6891, 411 DOI 10.17487/RFC6891, April 2013, 412 . 414 Acknowledgments 416 The use case in this document was inspired by discussions and the 417 DRIU BoF at IETF 102 and later in the DNSOP Working Group. Vladimir 418 Cunat, Philip Homburg, Shumon Huque, Martin Thomson, Eric Rescorla, 419 and Tony Finch offered useful advice to improve early versions of the 420 protocol. 422 Author's Address 424 Paul Hoffman 425 ICANN 427 Email: paul.hoffman@icann.org