idnits 2.17.1 draft-hoffman-resolver-associated-doh-06.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 (November 21, 2018) is 1982 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 November 21, 2018 5 Expires: May 25, 2019 7 Associating a DoH Server with a Resolver 8 draft-hoffman-resolver-associated-doh-06 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. 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 May 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Finding the URI Templates of the DoH Servers Associated with 57 a Resolver . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. DoH Servers by TXT . . . . . . . . . . . . . . . . . . . 4 59 2.2. DoH Servers by Addresses . . . . . . . . . . . . . . . . 5 60 2.3. Resolver Addresses by SUDN . . . . . . . . . . . . . . . 5 61 2.4. Issues Common to "DoH Servers by TXT" and "Resolver 62 Addresses by SUDN" . . . . . . . . . . . . . . . . . . . 6 63 3. User Interface . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 8.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 DoH [RFC8484] requires that one or more DoH servers be configured for 77 the DoH client. That document does not say how the DoH servers are 78 found, nor how to select from a list of possible DoH servers, nor 79 what the user interface (UI) for the configuration should be. 81 There is a use case for browsers and web applications who have one or 82 more currently-configured DNS recursive resolvers wanting to use DoH 83 for DNS resolution instead. For example, the recursive resolver 84 knows how to give correct answers to DNS queries that contain names 85 that are only resolvable in the local context. Users typically 86 configure their DNS recursive resolvers with through manual 87 configuration (such as manually editing a /etc/named.conf file) or 88 through automatic configuration from a protocol such as DHCP. 90 The client that wants to change from its currently-configured Do53 91 recursive resolver(s) to one or more DoH servers might be the stub 92 resolver in an operating system, although at this time it is rare 93 that such stub resolvers can use DoH. A much more likely use case is 94 a browser or web application that is getting name resolution through 95 the stub resolver on the computer on which it is running. The user 96 of the browser might have a preference for using a DoH server, and 97 they might need to use a DoH server that is associated with the 98 resolver that the computer is currently using so that its queries for 99 non-global names are answered correctly. They may also be required 100 to use only resolvers that are approved by their organization's 101 network operators. 103 To address these use cases, this document defines three different 104 protocols to get the list of URI templates [RFC6570] for the DoH 105 servers associated with at least one of the resolvers being used by 106 the operating system on the system on which the application is being 107 run. 109 o The first, called "DoH servers by TXT" and described in 110 Section 2.1, is a new special use domain name (SUDN) [RFC6761] 111 that can be queried for a TXT RRset. This protocol is most likely 112 useful only to browsers that can call operating system functions 113 that in turn query the DNS for text records; web applications can 114 only query for IP addresses. 116 o The second, called "DoH servers by addresses" and described in 117 Section 2.2, is a well-known URI [I-D.nottingham-rfc5785bis] that 118 can be resolved to return the URI templates. This is useful if 119 the browser can call operating system functions that will return 120 the address of the recursive DNS resolver that the operating 121 system is currently using. 123 o The third, called "resolver addresses by SUDN" and descrbed in 124 Section 2.3, is a new SUDN that that can be queried for the IP 125 address(es) of a resolver. This protocol is useful for a browser 126 or web application that can query for the addressess associated 127 with a domain name (such as using the POSIX "getaddrinfo()" 128 function) but cannot use an operating system function to find 129 those addresses. 131 The design choices for this protocol, particularly earlier designs 132 that were deemed unusable, are described in Section 4. 134 1.1. Terminology 136 In this document, "DoT" is used to indicate DNS over TLS as defined 137 in [RFC7858]. 139 In this document, "Do53" is used to indicate DNS over UDP or TCP as 140 defined in [RFC1035]. 142 "DoH client" and "DoH server" are defined in [RFC8484]. 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in BCP 147 14 [RFC2119] [RFC8174] when, and only when, they appear in all 148 capitals, as shown here. 150 2. Finding the URI Templates of the DoH Servers Associated with a 151 Resolver 153 A client (a browser or web application) uses either the protocol in 154 Section 2.1 or Section 2.2 to get a list of URI templates for the DoH 155 servers associated with a resolver. The following sub-sections 156 describe the protocols and have notes that are common to both 157 protocols. 159 2.1. DoH Servers by TXT 161 To find the DoH Servers associated with a resolver, an application 162 sends that resolver a query for "resolver-associated-doh.arpa" in 163 class IN with the RRtype of TXT [RFC1035] (that is, the query is 164 resolver-associated-doh.arpa/IN/TXT). 166 As described in Section 5, the zone resolver-associated-doh.arpa is 167 not actually delegated and never will be. The resolver acts as if it 168 is delegated, and adds its own TXT records to the answer. The 169 resolver replies with its associated DoH servers as URI templates in 170 the TXT RRset in the Answer section. 172 A resolver that understands this protocol MUST send a TXT RRset in 173 the Answer section. Each TXT record contains one URI template. If a 174 resolver that understands this protocol has no associated DoH 175 servers, the TXT RRset contains exactly one record that has an empty 176 string as the RDATA; that is, the RDLENGTH in that record is 1, and 177 the RDATA contains just the byte 0x00. 179 The client uses the TXT records in the response to the resolver- 180 associated-doh.arpa/IN/TXT query as a list of the URI templates of 181 the DoH servers associated with the resolver. Note that TXT records 182 can contain multiple "character-strings" [RFC1035]; for this 183 protocol, all characters-strings in a TXT record are concatenated to 184 form a single URI template. 186 The URI templates of the DoH servers associated with a resolver might 187 be hosted on the resolver itself, or a resolver hosted by the same 188 operator, or even hosted somewhere else. The latter could be used by 189 resolver operators who don't want to host DoH servers but trust 190 another operator to do so. 192 2.2. DoH Servers by Addresses 194 To find the DoH servers associated with a resolver, a browser or web 195 application uses either an operating system function (if such a 196 function is available to it) or the process described in Section 2.3 197 to find one or more IP addreses for the resolver. It uses one or 198 more of those IP addresses as part of a well-known URI to find out 199 the URI templates [RFC6570] to use for the DoH server(s) associated 200 with the resolver. 202 To find the DoH servers associated with a resolver, the client sends 203 a query to 205 https://IPADDRESSGOESHERE/.well-known/doh-servers-associated/ 207 The resolver replies with its associated DoH servers as URI templates 208 [RFC6570]. 210 [[ Need to describe the media types; likely JSON ]] 212 [[ Need to talk about what a response with an empty list means ]] 214 [[ Need to talk about what happens if authentication fails. This is 215 complicated by the fact that the application doesn't know if the OS- 216 to-resolver communication is authenticated. ]] 218 [[ Need to talk about HTTP caching ]] 220 A client MUST try to establish a new list of DoH servers associated 221 with a resolver every time the configured resolver in the operating 222 system changes. 224 The result of sending this query can be an HTTP redirect to a 225 different server, such as when a resolver operator doesn't want to 226 run its own DoH server. 228 2.3. Resolver Addresses by SUDN 230 Browsers and web applications are able to use an operating system 231 function such as gethostbyname() or its equivalents to convert host 232 names into IP addresses through the stub resolver in the operating 233 system on which they are running. 235 For this protocol, the browser or web application uses the SUDN 236 "resolver-addresses.arpa". As described in Section 5, the zone 237 resolver-addresses.arpa is not actually delegated and never will be. 238 The resolver acts as if it is delegated, and returns its own A or 239 AAAA records in the answer. 241 2.4. Issues Common to "DoH Servers by TXT" and "Resolver Addresses by 242 SUDN" 244 See Section 7 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 arond? ]] 257 3. User Interface 259 For this protocol to be useful in a browser, the browser needs to 260 have an entry in its configuration interface where the allowed DoH 261 servers are listed that indicates that a DoH server from the 262 configured Do53 or DoT resolver is allowed. That wording might say 263 something like "DoH server associated with my current resolver" (or 264 "servidor DoH asociado con mi resolucion actual" or "serveur DoH 265 associe a mon resolveur actuel"). 267 4. Design Choices 269 The primary use case for this protocol is a browser or web 270 application that is getting name resolution through the stub resolver 271 on the computer on which it is running wanting to switch its name 272 resolution to DoH. A secondary use case is an operating system that 273 wants to make a similar switch. 275 An earlier design suggestion was to use a new RRtype with a query to 276 ./IN/NEWRRTYPE. However, it was pointed out that this would not work 277 going through stub resolvers that validate DNSSEC. 279 An earlier design suggestion was to use DHCP to tell the operating 280 system the DoH servers that the stub resolver might use. That 281 protocol is orthogonal to the one in this document in that it 282 addresses a different use case. If both the protocol in this 283 document and a DHCP-based protocol are standardized, they could co- 284 exist. However, there is no current mechanism for a stub resolver to 285 tell a browser, or a web application, what DoH server the stub 286 resolver is using, so DoH configuration in the stub resolver would 287 not prevent the browser from trying to find a DoH server on its own. 289 An earlier design suggestion was to use an EDNS0 [RFC6891] extension. 290 The design chosen in this document meets the use case better because 291 applications cannot communicate EDNS0 extensions to the stub 292 resolver. 294 5. IANA Considerations 296 IANA will record the domain name "resolver-associated-doh.arpa" in 297 the "Special-Use Domain Names" registry [SUDN]. IANA MUST NOT 298 delegate resolver-associated-doh.arpa in the .arpa zone. 300 IANA will record the domain name "resolver-addresses.arpa" in the 301 "Special-Use Domain Names" registry [SUDN]. IANA MUST NOT delegate 302 resolver-addresses.arpa in the .arpa zone. 304 [[ When this document settles down, need to register ".well-known/ 305 doh-servers-associated" as specified in [I-D.nottingham-rfc5785bis]. 306 ]] 308 6. Privacy Considerations 310 Allowing a user to use DoH instead of Do53 increases communication 311 privacy because of the TLS protection. 313 When a Do53 or DoT server indicates that a particular DoH server is 314 associated with it, the client might assume that the DoH server has 315 the same information privacy policies as the Do53 or DoT server. 316 Therefore, a Do53 or DoT server SHOULD NOT recommend a DoH server 317 unless that DoH server has the same (or better) information privacy 318 policy as the Do53 or DoT server. 320 A browser that has both a stub resolver stack and a TLS stack that is 321 independent of HTTP could make a DOT connection to the resolver being 322 used by the operating system. 324 7. Security Considerations 326 There is currently no way for an application to know whether the 327 operating system's stub resolver is using a transport that assures 328 data integrity such as DoT. 330 Even is an application could determine the use of a transport like 331 DoT, the application would also need to know whether the transport 332 was authenticated or was simply chosen opportunistically. 334 8. References 336 8.1. Normative References 338 [I-D.nottingham-rfc5785bis] 339 Nottingham, M., "Well-Known Uniform Resource Identifiers 340 (URIs)", draft-nottingham-rfc5785bis-08 (work in 341 progress), October 2018. 343 [RFC1035] Mockapetris, P., "Domain names - implementation and 344 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 345 November 1987, . 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, 349 DOI 10.17487/RFC2119, March 1997, 350 . 352 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 353 and D. Orchard, "URI Template", RFC 6570, 354 DOI 10.17487/RFC6570, March 2012, 355 . 357 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 358 and P. Hoffman, "Specification for DNS over Transport 359 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 360 2016, . 362 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 363 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 364 May 2017, . 366 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 367 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 368 . 370 [SUDN] "Special-Use Domain Names", n.d., 371 . 374 8.2. Informative References 376 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 377 RFC 6761, DOI 10.17487/RFC6761, February 2013, 378 . 380 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 381 for DNS (EDNS(0))", STD 75, RFC 6891, 382 DOI 10.17487/RFC6891, April 2013, 383 . 385 Acknowledgments 387 The use case in this document was inspired by discussions and the 388 DRIU BoF at IETF 102 and later in the DNSOP Working Group. Vladimir 389 Cunat, Philip Homburg, Shumon Huque, Martin Thomson, Eric Rescorla, 390 and Tony Finch offered useful advice to improve early versions of the 391 protocol. 393 Author's Address 395 Paul Hoffman 396 ICANN 398 Email: paul.hoffman@icann.org