idnits 2.17.1 draft-hoffman-resolver-associated-doh-00.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 (August 23, 2018) is 2066 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) == Missing Reference: 'RFC3597' is mentioned on line 269, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 August 23, 2018 5 Expires: February 24, 2019 7 Associating a DoH Server with a Resolver 8 draft-hoffman-resolver-associated-doh-00 10 Abstract 12 Some clients will want to know if there are one or more DoH servers 13 associated with the DNS recursive resolver that the client is already 14 using. This document describes a protocol for a resolver to tell a 15 client what its associated DoH servers are. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on February 24, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. RAD RRtype Description . . . . . . . . . . . . . . . . . . . 3 54 4. Use of RAD . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4.1. Server Use of RAD . . . . . . . . . . . . . . . . . . . . 4 56 4.2. Client Use of RAD . . . . . . . . . . . . . . . . . . . . 4 57 5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 4 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 6.1. Root Zone . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6.2. Registration for RAD RRtype . . . . . . . . . . . . . . . 5 61 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 9.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 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 clients who have one or more currently- 78 configured DNS recursive resolvers wanting to use DoH for DNS 79 resolution instead. Clients typically configure their DNS recursive 80 resolvers with through manual configuration (such as manually editing 81 a /etc/named.conf file) or through automatic configuration from a 82 protocol such as DHCP. 84 The client that wants to change from its currently-configured DNS 85 recursive resolvers might be the stub resolver in an operating 86 system, although at this time it is rare that such stub resolvers can 87 use DoH. A much more likely use case is a web browser that is 88 getting name resolution through the stub resolver on the computer on 89 which it is running. The user of the browser might have a preference 90 for using a DoH server, and it might want a DoH server that is 91 associated with the resolver that the computer is currently using. 93 To address this use case, this document defines a new RRtype and 94 describes how it is used. The design choices made are described in 95 Section 5. 97 2. Terminology 99 In this document, "DoT" is used to indicate DNS over TLS as defined 100 in [RFC7858]. 102 In this document, "Do53" is used to indicate DNS over UDP or TCP as 103 defined in [RFC1035]. 105 "DoH client" and "DoH server" are defined in 106 [I-D.ietf-doh-dns-over-https]. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 3. RAD RRtype Description 116 The mnemonic for the new RRtype is RAD (for "router associated DoH"). 117 The Type value for the RAD RR is TBD; see Section 6. 119 The RDATA of the resource record consists of one field: a URI 120 Template [RFC6570] that is enclosed in ASCII quotation marks. 122 The display format of the RDATA is simply the value of the RDATA. 123 For example, here is an example RAD RRset in the display format: 125 . 3600 IN RAD "https://dnsserver.example.net/dns-query{?dns}" 126 . 3600 IN RAD "https://192.0.2.78/doh{?dns}" 128 The wire format of the RDATA is simply the bytes that represent the 129 RDATA, including the required enclosing quotation marks. For 130 example, the above RRset is encoded as follows (with the example 131 value for TBD being 42424 decimal, or 0xA5B3): 133 00 A5B3 0001 00000E10 002F 134 2268747470733A2F2F646E737365727665722E6578616D706C652E6E6574 135 2F646E732D71756572797B3F646E737D22 136 00 A5B3 0001 00000E10 001E 137 2268747470733A2F2F3139322E302E322E37382F646F687B3F646E737D22 139 4. Use of RAD 141 To find the DoH servers associated with a resolver, the client sends 142 that resolver a query for the root zone in class IN with the RRtype 143 of RAD (that is, the query is ./IN/RAD). The server replies with its 144 associated DoH servers in the RAD RRset in the Answer section. 146 4.1. Server Use of RAD 148 A resolver that understands this protocol MUST send a RAD RRset in 149 the Answer section. If a resolver that understands this protocol has 150 no associated DoH servers, the RRset contains exactly one record that 151 has just "" as the RDATA; that is, the RDLENGTH in that record is 2, 152 and the RDATA contains just the two bytes 0x2222. 154 4.2. Client Use of RAD 156 If a client sends the ./IN/RAD query over a transport that assures 157 data integrity (such as DoT), and it receives a response that has an 158 NXDOMAIN response code, the client can assume that the resolver does 159 not know this protocol. 161 See Section 8 for warnings about sending the ./IN/RAD query over a 162 transport that does not assure data integrity (such as Do53). 164 This protocol only defines the use of the RAD RRtype in queries that 165 are exactly ./IN/RAD. Clients MUST NOT send DNS queries using the 166 RAD RRtype with any QNAME other than that of the root and any QCLASS 167 other than IN. 169 The client SHOULD only use a DoH server listed in the RAD response 170 for the length of time listed as the RAD RRset's TTL. Using an 171 associated DoH server beyond the TTL can expose the client to 172 problems such as loss of DNS service. The client SHOULD send a ./IN/ 173 RAD query before the expiration of the TTL in a previous response in 174 order to allow the client to continue to use an associated DoH server 175 without interruption. 177 A client MUST issue a new ./IN/RAD query every time the configured 178 resolver changes. 180 5. Design Choices 182 The primary use case for this protocol is a web browser that is 183 getting name resolution through the stub resolver on the computer on 184 which it is running wanting to switch its name resolution to DoH. A 185 secondary use case is an OS that wants to make a similar switch. 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 come into existence, they could co-exist. 192 However, there is no current mechanism for a stub resolver to tell a 193 web browser what DoH server the stub resolver is using, so DoH 194 configuration in the stub resolver would not prevent the browser from 195 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 ./IN/RAD query) meets the use 199 case better because if the stub resolver does not understand EDNS0, 200 or there is a middlebox between the computer and the resolver that 201 mishandles EDNS extensions, the information will not make it back to 202 the web browser. 204 An earlier design suggestion was to use a new special-use TLD 205 [RFC6761] instead of the root in the query. However, [RFC6761] 206 continues to be contentious and using such a TLD has pretty much all 207 of the problems as using the root itself. 209 For this protocol to be useful in a browser, the browser needs to 210 have an entry in its configuration interface where the allowed DoH 211 servers are listed that indicates that a DoH server from the 212 configured Do53 or DoT resolver is allowed. That wording might say 213 something like "DoH server associated with my current resolver". 215 6. IANA Considerations 217 6.1. Root Zone 219 IANA MUST NOT ever include an RRset for the RAD RRtype in the root 220 zone. 222 6.2. Registration for RAD RRtype 224 @@@ This will actually be a submission to the RRtypes expert sometime 225 during the progress of this draft (if this draft progresses), and 226 then will turn into a stub section just saying "IANA assigned Type 227 value X to RAD in the RRtypes registry". @@@ 229 A. Submission Date: (sometime in the future) 231 B.1 Submission Type: 233 New RRTYPE 235 B.2 Kind of RR: 237 Data RR 239 C. Contact Information for submitter (will be publicly posted): 241 Paul Hoffman, paul.hoffman@icann.org 242 D. Motivation for the new RRTYPE application 244 To support recursive resolvers who want to associate DoH servers with 245 the resolvers 247 E. Description of the proposed RR type. 249 See Section 3 251 F. What existing RRTYPE or RRTYPEs come closest to filling that need 252 and why are they unsatisfactory? 254 URI, but it is unsatisfactory because the semantics are different 255 (This is not associating the URI with a hostname) and because it has 256 a priority and weight. 258 G. What mnemonic is requested for the new RRTYPE (optional)? 260 RAD 262 H. Does the requested RRTYPE make use of any existing IANA registry 263 or require the creation of a new IANA subregistry in DNS Parameters? 265 No 267 I. Does the proposal require/expect any changes in DNS servers/ 268 resolvers that prevent the new type from being processed as an 269 unknown RRTYPE (see [RFC3597])? 271 No 273 J. Comments: 275 None 277 7. Privacy Considerations 279 Allowing a user to use DoH instead of Do53 increases communication 280 privacy because of the TLS protection. 282 When a Do53 or DoT server indicates that a particular DoH server is 283 associated with it, the client might assume that the DoH server has 284 the same information privacy policies as the Do53 or DoT server. 285 Therefore, a Do53 or DoT server SHOULD NOT recommend a DoH server 286 unless that DoH server has the same (or better) information privacy 287 policy as the Do53 or DoT server. 289 8. Security Considerations 291 If a client sends the ./IN/RAD query over a transport that does not 292 assure data integrity (such as Do53), an attacker between the client 293 and the resolver can change the response. 295 o A client who sends a query over such a transport and begins to use 296 a DoH server based on the response MUST NOT assign a level of 297 trust to that DoH server greater than to the trust it gave to the 298 resolver itself. 300 o A client who sends a query over such a transport and receives a 301 response that has an NXDOMAIN response code cannot be sure that 302 the response comes from a resolver that does not know this 303 protocol. Instead, the client SHOULD assume that there could be 304 an on-path attack where the attacker does not want the client to 305 use DoH. 307 9. References 309 9.1. Normative References 311 [I-D.ietf-doh-dns-over-https] 312 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 313 (DoH)", draft-ietf-doh-dns-over-https-14 (work in 314 progress), August 2018. 316 [RFC1035] Mockapetris, P., "Domain names - implementation and 317 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 318 November 1987, . 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, 322 DOI 10.17487/RFC2119, March 1997, 323 . 325 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 326 and D. Orchard, "URI Template", RFC 6570, 327 DOI 10.17487/RFC6570, March 2012, 328 . 330 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 331 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 332 May 2017, . 334 9.2. Informative References 336 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 337 RFC 6761, DOI 10.17487/RFC6761, February 2013, 338 . 340 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 341 for DNS (EDNS(0))", STD 75, RFC 6891, 342 DOI 10.17487/RFC6891, April 2013, 343 . 345 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 346 and P. Hoffman, "Specification for DNS over Transport 347 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 348 2016, . 350 Acknowledgments 352 The use case in this document was inspired by discussions and the 353 DRIU BoF at IETF 102 and later in the DNSOP Working Group. 355 Author's Address 357 Paul Hoffman 358 ICANN 360 Email: paul.hoffman@icann.org