idnits 2.17.1 draft-hoffman-resolver-associated-doh-05.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 05, 2018) is 1970 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 05, 2018 5 Expires: May 9, 2019 7 Associating a DoH Server with a Resolver 8 draft-hoffman-resolver-associated-doh-05 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 9, 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 . . . . . . . . . . . . . . . . 4 60 2.2.1. Finding the IP Addresses of a Resolver . . . . . . . 5 61 2.2.2. Finding the DoH Servers Associated with a Resolver . 5 62 2.3. Issues Common to "DoH Servers by TXT" and "DoH Servers by 63 Addresses" . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.4. Choosing Between "DoH Servers by TXT" and "DoH Servers by 65 Addresses" . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.5. User Interface . . . . . . . . . . . . . . . . . . . . . 6 67 3. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 6 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 7.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 DoH [RFC8484] requires that one or more DoH servers be configured for 80 the DoH client. That document does not say how the DoH servers are 81 found, nor how to select from a list of possible DoH servers, nor 82 what the user interface (UI) for the configuration should be. 84 There is a use case for browsers and web applications who have one or 85 more currently-configured DNS recursive resolvers wanting to use DoH 86 for DNS resolution instead. For example, the recursive resolver 87 knows how to give correct answers to DNS queries that contain names 88 that are only resolvable in the local context. Users typically 89 configure their DNS recursive resolvers with through manual 90 configuration (such as manually editing a /etc/named.conf file) or 91 through automatic configuration from a protocol such as DHCP. 93 The client that wants to change from its currently-configured Do53 94 recursive resolver(s) to one or more DoH servers might be the stub 95 resolver in an operating system, although at this time it is rare 96 that such stub resolvers can use DoH. A much more likely use case is 97 a browser or web application that is getting name resolution through 98 the stub resolver on the computer on which it is running. The user 99 of the browser might have a preference for using a DoH server, and 100 they might need to use a DoH server that is associated with the 101 resolver that the computer is currently using so that its queries for 102 non-global names are answered correctly. They may also be required 103 to use only resolvers that are approved by their organization's 104 network operators. 106 To address these use cases, this document defines two different 107 protocols to get the list of URI templates [RFC6570] associated for 108 the DoH servers associated with at least one of the resolvers being 109 used by the operating system on the system on which the application 110 is being run. Each uses its onw special use domain name (SUDN); 111 SUDNs aredescribed in [RFC6761]. 113 o The first, called "DoH servers by TXT" and described in 114 Section 2.1, is a new SUDN that can be queried for a TXT RRset. 115 This protocol is most likely useful only to browsers that can call 116 operating system functions that in turn query the DNS for text 117 records; web applications can only query for IP addresses. 119 o The second, called "DoH servers by Addresses" and described in 120 Section 2.2 is combination of a new SUDN that that can be queried 121 for IP addresses, and a well-known URI [I-D.nottingham-rfc5785bis] 122 that can be resolved to return the URI templates. This protocol 123 is useful for a browser or web application that can query for the 124 addressess associated with a domain name (such as using the POSIX 125 "getaddrinfo()" function) and resolve HTTP and HTTPS URLs. 127 The design choices for this protocol, particularly earlier designs 128 that were deemed unusable, are described in Section 3. 130 1.1. Terminology 132 In this document, "DoT" is used to indicate DNS over TLS as defined 133 in [RFC7858]. 135 In this document, "Do53" is used to indicate DNS over UDP or TCP as 136 defined in [RFC1035]. 138 "DoH client" and "DoH server" are defined in [RFC8484]. 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 2. Finding the URI Templates of the DoH Servers Associated with a 147 Resolver 149 A client (a browser or web application) uses either the protocol in 150 Section 2.1 or Section 2.2 to get a list of URI templates for the DoH 151 servers associated with a resolver. The following sub-sections 152 describe the protocols and have notes that are common to both 153 protocols. 155 2.1. DoH Servers by TXT 157 To find the DoH Servers associated with a resolver, an application 158 sends that resolver a query for "resolver-associated-doh.arpa" in 159 class IN with the RRtype of TXT [RFC1035] (that is, the query is 160 resolver-associated-doh.arpa/IN/TXT). 162 The resolver replies with its associated DoH servers as URI templates 163 in the TXT RRset in the Answer section. 165 A resolver that understands this protocol MUST send a TXT RRset in 166 the Answer section. Each TXT record contains one URI template. If a 167 resolver that understands this protocol has no associated DoH 168 servers, the TXT RRset contains exactly one record that has an empty 169 string as the RDATA; that is, the RDLENGTH in that record is 1, and 170 the RDATA contains just the byte 0x00. 172 As described in Section 4, the zone resolver-associated-doh.arpa is 173 not delegated. The resolver acts as if it is and adds its own TXT 174 records to the answer. 176 The client uses the TXT records in the response to the resolver- 177 associated-doh.arpa/IN/TXT query as a list of the URI templates of 178 the DoH servers associated with the resolver. Note that TXT records 179 can contain multiple "character-strings" [RFC1035]; for this 180 protocol, all characters-strings in a TXT record are concatenated to 181 form a single URI template. 183 2.2. DoH Servers by Addresses 185 To find the DoH Servers associated with a resolver, an application 186 uses a SUDN that causes a resolver to return its IP addresses. It 187 uses those IP addresses as part of a well-known URI to find out the 188 URI templates [RFC6570] to use for the DoH server(s) associated with 189 the resolver. 191 2.2.1. Finding the IP Addresses of a Resolver 193 A browser is able to use an operating system function such as 194 gethostbyname() to convert host names into IP addresses through the 195 stub resolver in the operating system on which it is running. It can 196 also send HTTPS queries to a resolver, but it would need to have the 197 address of that resolver first. Web applications can do the same. 199 For this protocol, the browser or web application uses the SUDN 200 "resolver-addresses.arpa". When a resolver that understands this 201 SUDN receives a query for either resolver-addresses.arpa/IN/A or 202 resolver-addresses.arpa/IN/AAAA, it returns its own IP addresses in 203 the answer. 205 As described in Section 4, the zone resolver-addresses.arpa is not 206 delegated.The resolver acts as if it is and adds its own A or AAAA 207 records to the answer. 209 2.2.2. Finding the DoH Servers Associated with a Resolver 211 To find the DoH servers associated with a resolver, the client uses 212 the addresses returned from the query to resolver-addresses.arpa and 213 sends a query to 215 https://IPADDRESSGOESHERE/.well-known/doh-servers-associated/ 217 The resolver replies with its associated DoH servers as URI templates 218 [RFC6570]. 220 [[ Need to describe the media types; likely JSON ]] 222 [[ Need to talk about what a response with an empty list means ]] 224 [[ Need to talk about what happens if authentication fails. This is 225 complicated by the fact that the application doesn't know if the OS- 226 to-resolver communication is authenticated. ]] 228 [[ Need to talk about HTTP caching ]] 230 A client MUST try to establish a new list of DoH servers associated 231 with a resolver every time the configured resolver in the operating 232 system changes. 234 2.3. Issues Common to "DoH Servers by TXT" and "DoH Servers by 235 Addresses" 237 See Section 6 for warnings about sending the DNS queries over a 238 transport that does not assure data integrity (such as Do53), and 239 over a transport that does assure data integrity (such as DoT) but in 240 circumstances where the browser or web application doesn't know the 241 type of DNS transport being used. 243 A client MUST re-issue the queries in {#doh_by_txt} and 244 {#doh_by_addresses} every time the configured resolver in the 245 operating system changes. 247 [[ What if there is a list of DoH servers? Pick one (how?) or jump 248 arond? ]] 250 2.4. Choosing Between "DoH Servers by TXT" and "DoH Servers by 251 Addresses" 253 [[ by TXT only takes one step ]] 255 [[ by address gives you all the addressess, which might yield more 256 servers ]] 258 2.5. User Interface 260 For this protocol to be useful in a browser, the browser needs to 261 have an entry in its configuration interface where the allowed DoH 262 servers are listed that indicates that a DoH server from the 263 configured Do53 or DoT resolver is allowed. That wording might say 264 something like "DoH server associated with my current resolver" (or 265 "servidor DoH asociado con mi resolucion actual" or "serveur DoH 266 associe a mon resolveur actuel"). 268 3. Design Choices 270 The primary use case for this protocol is a browser or web 271 application that is getting name resolution through the stub resolver 272 on the computer on which it is running wanting to switch its name 273 resolution to DoH. A secondary use case is an OS that wants to make 274 a similar switch. 276 An earlier design suggestion was to use a new RRtype with a query to 277 ./IN/NEWRRTYPE. However, it was pointed out that this would not work 278 going through stub resolvers that validate DNSSEC. 280 An earlier design suggestion was to use DHCP to tell the OS the DoH 281 servers that the stub resolver might use. That protocol is 282 orthogonal to the one in this document in that it addresses a 283 different use case. If both the protocol in this document and a 284 DHCP-based protocol are standardized, they could co-exist. However, 285 there is no current mechanism for a stub resolver to tell a browser, 286 or a web application, what DoH server the stub resolver is using, so 287 DoH configuration in the stub resolver would not prevent the browser 288 from trying to find a DoH server on its own. 290 An earlier design suggestion was to use an EDNS0 [RFC6891] extension. 291 The design chosen in this document meets the use case better because 292 applications cannot communicate EDNS0 extensions to the stub 293 resolver. 295 4. IANA Considerations 297 IANA will record the domain name "resolver-associated-doh.arpa" in 298 the "Special-Use Domain Names" registry [SUDN]. IANA MUST NOT 299 delegate resolver-associated-doh.arpa in the .arpa zone. 301 IANA will record the domain name "resolver-addresses.arpa" in the 302 "Special-Use Domain Names" registry [SUDN]. IANA MUST NOT delegate 303 resolver-addresses.arpa in the .arpa zone. 305 [[ When this document settles down, need to register ".well-known/ 306 doh-servers-associated" as specified in [I-D.nottingham-rfc5785bis]. 307 ]] 309 5. Privacy Considerations 311 Allowing a user to use DoH instead of Do53 increases communication 312 privacy because of the TLS protection. 314 When a Do53 or DoT server indicates that a particular DoH server is 315 associated with it, the client might assume that the DoH server has 316 the same information privacy policies as the Do53 or DoT server. 317 Therefore, a Do53 or DoT server SHOULD NOT recommend a DoH server 318 unless that DoH server has the same (or better) information privacy 319 policy as the Do53 or DoT server. 321 6. Security Considerations 323 There is currently no way for an application to know whether the 324 operating system's stub resolver is using a transport that assures 325 data integrity such as DoT. 327 Even is an application could determine the use of a transport like 328 DoT, the application would also need to know whether the transport 329 was authenticated or was simply chosen opportunistically. 331 7. References 333 7.1. Normative References 335 [I-D.nottingham-rfc5785bis] 336 Nottingham, M., "Well-Known Uniform Resource Identifiers 337 (URIs)", draft-nottingham-rfc5785bis-08 (work in 338 progress), October 2018. 340 [RFC1035] Mockapetris, P., "Domain names - implementation and 341 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 342 November 1987, . 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, 346 DOI 10.17487/RFC2119, March 1997, 347 . 349 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 350 and D. Orchard, "URI Template", RFC 6570, 351 DOI 10.17487/RFC6570, March 2012, 352 . 354 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 355 and P. Hoffman, "Specification for DNS over Transport 356 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 357 2016, . 359 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 360 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 361 May 2017, . 363 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 364 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 365 . 367 [SUDN] "Special-Use Domain Names", n.d., 368 . 371 7.2. Informative References 373 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 374 RFC 6761, DOI 10.17487/RFC6761, February 2013, 375 . 377 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 378 for DNS (EDNS(0))", STD 75, RFC 6891, 379 DOI 10.17487/RFC6891, April 2013, 380 . 382 Acknowledgments 384 The use case in this document was inspired by discussions and the 385 DRIU BoF at IETF 102 and later in the DNSOP Working Group. Vladimir 386 Cunat, Philip Homburg, Shumon Huque, Martin Thomson, Eric Rescorla, 387 and Tony Finch offered useful advice to improve early versions of the 388 protocol. 390 Author's Address 392 Paul Hoffman 393 ICANN 395 Email: paul.hoffman@icann.org