idnits 2.17.1 draft-hoffman-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 (September 25, 2018) is 2039 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SUDN' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 September 25, 2018 5 Expires: March 29, 2019 7 Associating a DoH Server with a Resolver 8 draft-hoffman-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 client is already using. This would allow them to get DNS responses 15 from a resolver that the user (or, more likely, the user's network 16 administrator) has already chosen. This document describes a 17 protocol 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 March 29, 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Signalling the DoH Servers Associated with a Resolver . . . . 3 57 3.1. Signalling in the Resolver . . . . . . . . . . . . . . . 3 58 3.2. Client Handling of the Signals . . . . . . . . . . . . . 4 59 4. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 65 8.2. Informative References . . . . . . . . . . . . . . . . . 7 66 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 DoH [I-D.ietf-doh-dns-over-https] requires that one or more DoH 72 servers be configured for the DoH client. That document does not say 73 how the DoH servers are found, nor how to select from a list of 74 possible DoH servers, nor what the user interface (UI) for the 75 configuration should be. 77 There is a use case for browsers and web applications who have one or 78 more currently-configured DNS recursive resolvers wanting to use DoH 79 for DNS resolution instead. For example, the recursive resolver 80 knows how to give correct answers to DNS queries that contain names 81 that are only resolvable in the local context. Users typically 82 configure their DNS recursive resolvers with through manual 83 configuration (such as manually editing a /etc/named.conf file) or 84 through automatic configuration from a protocol such as DHCP. 86 The client that wants to change from its currently-configured DNS 87 recursive resolvers might be the stub resolver in an operating 88 system, although at this time it is rare that such stub resolvers can 89 use DoH. A much more likely use case is a browser or web application 90 that is getting name resolution through the stub resolver on the 91 computer on which it is running. The user of the browser might have 92 a preference for using a DoH server, and they might need to use a DoH 93 server that is associated with the resolver that the computer is 94 currently using so that its queries for non-global names are answered 95 correctly. They may also be required to use only resolvers that are 96 approved by their organization's network operators. 98 To address this use case, this document defines a new special use 99 domain name "resolver-associated-doh.arpa." and describes how it is 100 used. The design choices made are described in Section 4. 102 2. Terminology 104 In this document, "DoT" is used to indicate DNS over TLS as defined 105 in [RFC7858]. 107 In this document, "Do53" is used to indicate DNS over UDP or TCP as 108 defined in [RFC1035]. 110 "DoH client" and "DoH server" are defined in 111 [I-D.ietf-doh-dns-over-https]. 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 3. Signalling the DoH Servers Associated with a Resolver 121 To find the DoH servers associated with a resolver, the client sends 122 that resolver a query for resolver-associated-doh.arpa in class IN 123 with the RRtype of TXT [RFC1035] (that is, the query is resolver- 124 associated-doh.arpa/IN/TXT). 126 The resolver replies with its associated DoH servers as URI Templates 127 [RFC6570] in the TXT RRset in the Answer section. 129 3.1. Signalling in the Resolver 131 A resolver that understands this protocol MUST send a TXT RRset in 132 the Answer section. Each TXT record contains one URI Template. 134 If a resolver that understands this protocol has no associated DoH 135 servers, the TXT RRset contains exactly one record that has an empty 136 string as the RDATA; that is, the RDLENGTH in that record is 1, and 137 the RDATA contains just the byte 0x00. 139 Note that the zone resolver-associated-doh.arpa, as it is delegated 140 in Section 5, has no TXT records of its own. The resolver adds its 141 own TXT records to the answer. 143 3.2. Client Handling of the Signals 145 The client uses the TXT records in the response to the resolver- 146 associated-doh.arpa/IN/TXT query as a list of the URI Templates of 147 the DoH servers associated with the resolver. Note that TXT records 148 can contain multiple "character-strings" [RFC1035]; for this 149 protocol, all characters-strings in a TXT record are concatenated to 150 form a single URI Template. 152 If a client sends the resolver-associated-doh.arpa/IN/TXT query over 153 a transport that assures data integrity (such as DoT), and it 154 receives a response that has the RCODE set to NOERROR and no relevant 155 answers in the Answer section (also called a "NODATA" response in 156 [RFC2308]), the client can assume that the resolver does not know 157 this protocol. 159 See Section 7 for warnings about sending the resolver-associated- 160 doh.arpa/IN/TXT query over a transport that does not assure data 161 integrity (such as Do53). 163 The client SHOULD only use a DoH server listed in the response to 164 resolver-associated-doh.arpa/IN/TXT for the length of time listed as 165 the TXT RRset's TTL field. Using an associated DoH server beyond the 166 TTL can expose the client to problems such as loss of DNS service. 167 The client SHOULD send a resolver-associated-doh.arpa/IN/TXT query 168 before the expiration of the TTL in a previous response in order to 169 allow the client to continue to use an associated DoH server without 170 interruption. 172 A client MUST issue a new resolver-associated-doh.arpa/IN/TXT query 173 every time the configured resolver in the operating system changes. 175 4. Design Choices 177 The primary use case for this protocol is a browser or web 178 application that is getting name resolution through the stub resolver 179 on the computer on which it is running wanting to switch its name 180 resolution to DoH. A secondary use case is an OS that wants to make 181 a similar switch. 183 An earlier design suggestion was to use a new RRtype with a query to 184 ./IN/NEWRRTYPE. However, it was pointed out that this would not work 185 going through stub resolvers that validate DNSSEC. 187 An earlier design suggestion was to use DHCP to tell the OS the DoH 188 servers that the stub resolver might use. That protocol is 189 orthogonal to the one in this document in that it addresses a 190 different use case. If both the protocol in this document and a 191 DHCP-based protocol are standardized, they could co-exist. However, 192 there is no current mechanism for a stub resolver to tell a browser, 193 or a web application, what DoH server the stub resolver is using, so 194 DoH configuration in the stub resolver would not prevent the browser 195 from trying to find a DoH server on its own. 197 An earlier design suggestion was to use an EDNS0 [RFC6891] extension. 198 The design chosen (the new RRtype and resolver-associated- 199 doh.arpa/IN/TXT query) meets the use case better because if the stub 200 resolver does not understand EDNS0, or there is a middlebox that 201 mishandles EDNS extensions between the computer and the resolver, the 202 information about associated DoH servers will not make it back to the 203 browser or web application. 205 For this protocol to be useful in a browser, the browser needs to 206 have an entry in its configuration interface where the allowed DoH 207 servers are listed that indicates that a DoH server from the 208 configured Do53 or DoT resolver is allowed. That wording might say 209 something like "DoH server associated with my current resolver". 211 5. IANA Considerations 213 IANA will record the domain name "resolver-associated-doh.arpa." in 214 the "Special-Use Domain Names" registry [SUDN]. 216 IANA, with the approval of the IAB, will delegate "resolver- 217 associated-doh.arpa." in the ".arpa." zone. 219 The delegation for "resolver-associated-doh.arpa." MUST NOT include 220 a DS record. 222 The delegation for "resolver-associated-doh.arpa." MUST point to one 223 or more black hole servers, for example, "blackhole-1.iana.org." and 224 "blackhole-2.iana.org.". 226 The delegation for "resolver-associated-doh.arpa." MUST NOT ever 227 have a resource record with the RRtype "TXT". 229 6. Privacy Considerations 231 Allowing a user to use DoH instead of Do53 increases communication 232 privacy because of the TLS protection. 234 When a Do53 or DoT server indicates that a particular DoH server is 235 associated with it, the client might assume that the DoH server has 236 the same information privacy policies as the Do53 or DoT server. 237 Therefore, a Do53 or DoT server SHOULD NOT recommend a DoH server 238 unless that DoH server has the same (or better) information privacy 239 policy as the Do53 or DoT server. 241 7. Security Considerations 243 If a client sends the resolver-associated-doh.arpa/IN/TXT query over 244 a transport that does not assure data integrity (such as Do53), an 245 attacker between the client and the resolver can change the response. 247 o A client that sends a query over such a transport and begins to 248 use a DoH server based on the response MUST NOT assign a level of 249 trust to that DoH server greater than to the trust it gave to the 250 resolver itself. 252 o A client that sends a query over such a transport and receives a 253 response that has an NXDOMAIN response code cannot be sure that 254 the response comes from a resolver that does not know this 255 protocol. Instead, the client SHOULD assume that there could be 256 an on-path attack where the attacker does not want the client to 257 use DoH. 259 8. References 261 8.1. Normative References 263 [I-D.ietf-doh-dns-over-https] 264 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 265 (DoH)", draft-ietf-doh-dns-over-https-14 (work in 266 progress), August 2018. 268 [RFC1035] Mockapetris, P., "Domain names - implementation and 269 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 270 November 1987, . 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, 274 DOI 10.17487/RFC2119, March 1997, 275 . 277 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 278 and D. Orchard, "URI Template", RFC 6570, 279 DOI 10.17487/RFC6570, March 2012, 280 . 282 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 283 and P. Hoffman, "Specification for DNS over Transport 284 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 285 2016, . 287 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 288 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 289 May 2017, . 291 [SUDN] "Special-Use Domain Names", n.d., 292 . 295 8.2. Informative References 297 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 298 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 299 . 301 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 302 for DNS (EDNS(0))", STD 75, RFC 6891, 303 DOI 10.17487/RFC6891, April 2013, 304 . 306 Acknowledgments 308 The use case in this document was inspired by discussions and the 309 DRIU BoF at IETF 102 and later in the DNSOP Working Group. Vladimir 310 Cunat, Philip Homburg, and Shumon Huque offered useful advice to 311 greatly improve the protocol. 313 Author's Address 315 Paul Hoffman 316 ICANN 318 Email: paul.hoffman@icann.org