idnits 2.17.00 (12 Aug 2021) /tmp/idnits35500/draft-rescorla-doh-cdisco-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8484]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 June 2020) is 688 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-pauly-add-resolver-discovery-00 == Outdated reference: A later version (-02) exists of draft-pp-add-resinfo-01 == Outdated reference: A later version (-02) exists of draft-pp-add-stub-upgrade-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rescorla 3 Internet-Draft Mozilla 4 Intended status: Informational J. Livingood 5 Expires: 27 December 2020 Comcast 6 25 June 2020 8 CNAME Discovery of Local DoH Resolvers 9 draft-rescorla-doh-cdisco-00 11 Abstract 13 This note describes a simple mechanism for determining whether an 14 Internet Service Provider (ISP) network is operating a DNS over HTTPS 15 [RFC8484] server on it for users connected to that network. 17 Discussion Venues 19 This note is to be removed before publishing as an RFC. 21 Source for this draft and an issue tracker can be found at 22 https://github.com/ekr/draft-rescorla-doh-cdisco 23 (https://github.com/ekr/draft-rescorla-doh-cdisco). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 27 December 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 60 3. DoH Resolver Discovery . . . . . . . . . . . . . . . . . . . 3 61 3.1. Why DNS? . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Why a CNAME? . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 6.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 Some applications perform their own name resolution rather than using 74 the system resolver, typically using an encrypted protocol such as 75 DoH [RFC8484]. These applications have the choice of using either 76 the same recursive resolver configured into the system or of using a 77 resolver chosen out of a preconfigured list of trusted resolvers in 78 an application, such as in [DOHTRR]. 80 If all of the trusted resolvers are publicly available, then there 81 are a number of mechanisms for choosing between them, for instance 82 randomly or based on performance. 83 [I-D.arkko-abcd-distributed-resolver-selection] describes a number of 84 potential mechanisms. However, if the list of trusted resolvers 85 includes Internet Service Providers (ISPs) and the client is on a 86 network associated with such a provider, then it may be desirable to 87 preferentially select the resolver associated with that provider. 88 This provides the benefits both of using a DNS resolver with a known 89 policy and using a resolver that has high quality local information 90 about the local network topology. 92 This document describes a mechanism to address this situation. This 93 mechanism is being tested in the Firefox browser with Comcast's 94 resolvers. 96 2. Conventions and Definitions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in BCP 101 14 [RFC2119] [RFC8174] when, and only when, they appear in all 102 capitals, as shown here. 104 3. DoH Resolver Discovery 106 The basic mechanism described in this document is straightforward and 107 has been chosen for ease of implementation rather than architectural 108 correctness. 110 +--------------+ 111 Provision CNAME | | 112 doh.test -> resolver.example -> | ISP Resolver | 113 | | 114 +--------------+ 115 ^ | 116 | | 117 doh.test? | | resolver.example 118 | | 119 | v 120 +--------------+ 121 | | 122 | Client | 123 | | 124 +--------------+ 126 A network provider can publish the fact that it has an associated DoH 127 resolver on its network by configuring its own resolvers to serve a 128 CNAME record at a well known domain name which cannot be otherwise 129 registered. The current test deployment uses "doh.test" (see 130 [RFC2606] for the definition of .test). This CNAME points to the 131 domain name of the associated DoH resolver ("resolver.example" in the 132 diagram above). 134 [[OPEN ISSUE: doh.test is probably the wrong domain. We may pick 135 something else later.]] 137 A client which wishes to test for the presence of a DoH resolver on 138 the network takes the following steps: 140 1. Do any testing for whether DoH should be disabled, such as 141 looking for canary domains [I-D.grover-add-policy-detection] or 142 checking for local enterprise configuration. 144 2. Do a CNAME query for "doh.test" using either the system resolver 145 or by talking directly to the recursive resolver IP address 146 configured into the system. 148 3. If the query succeeds, then look up the CNAME record value in the 149 list of preconfigured resolvers. If an exact match is found, 150 then use the resolver address for the matching preconfigured 151 resolver. Otherwise fall back to the ordinary DoH resolver 152 selection logic. 154 4. If the query fails, then no associated resolver is present; fall 155 back to the ordinary DoH resolver selection logic. 157 As noted above, this mechanism was designed for ease of 158 implementation. 160 Comcast's resolvers and authoritative servers have been configured 161 with some additional records to support the Firefox applications and 162 potential future applications. The DNS behavior is as follows, where 163 example.com is the domain used for naming provider services: 165 1. doh.test IN CNAME doh-discovery.example.com 167 2. doh-discovery.example.com must have at least one A and/or AAAA RR 168 (address does not matter - can be 127.0.0.1) 170 3. doh-discovery.example.com IN URI https://doh.example.com/dns- 171 query (the ISP DoH URI - not currently used by Firefox as the URI 172 is preconfigured in the application) 174 The next few sections describe the reasoning for some of the design 175 choices. 177 Considering that many applications do not act as a DNS client and 178 instead use platform functions such as getaddrinfo, the domain of the 179 associated resolver SHOULD also have an A record, so the call to 180 getaddrinfo does not fail. 182 3.1. Why DNS? 184 There have been a number of discussions of using non-DNS mechanisms 185 resolver information, for instance as in Section 4 of 186 [I-D.pauly-add-resolver-discovery]. While arguably more 187 architecturally correct in terms of layering, they have a number of 188 deployment drawbacks: 190 * They require the client to have much tighter integration with the 191 operating system in order to query the data. By contrast, with 192 this mechanism, the client need only be able to do name resolution 193 via the system resolver, which it generally already is able to do 194 via standard APIs. 196 * They require new types of configuration which ISPs may not already 197 be set up to do. By contrast, configuring DNS records is 198 generally well understood. 200 * They rely on intermediate devices (e.g., NATs) being aware of the 201 configuration information and passing it onto clients. These 202 devices already do this with DNS information. 204 For these reasons, DNS seems to be the easiest solution to deploy 205 quickly. 207 3.2. Why a CNAME? 209 Most other proposed designs (e.g., [I-D.pp-add-resinfo] and 210 [I-D.pp-add-stub-upgrade], and [I-D.pauly-add-resolver-discovery]) 211 use new RRtypes. While this may be the right answer eventually, it 212 is less convenient for immediate deployment, for several reasons: 214 1. It is somewhat more difficult (though not impossible) to look up 215 new RRTypes on the client and provision them on the ISP resolver. 217 2. Some consumer-grade middleboxes (e.g., WiFI routers) may block 218 unknown RRTypes. The data here is quite old and limited, but 219 still not particularly promising. 221 The choice to use a CNAME does have one major drawback: it does not 222 let us provide the URL template but only the name of the resolver. 223 This is not a problem for our system in practice because Firefox will 224 only connect to resolvers on a preconfigured list and thus will use 225 the CNAME as a lookup key for that list. The Mozilla team is working 226 to measure the rate of new RRType interference and may revise this 227 approach depending on the results of that. 229 [[OPEN ISSUE: We are working to measure the rate of new RRType 230 interference and may revise this approach depending on the results of 231 that.]] 233 4. Security Considerations 235 Because the initial request for discovery is done over insecure DNS 236 (Do53), a local attacker or malicious local resolver can substitute 237 their own response. However, because this mechanism only selects 238 from a list of preconfigured trusted resolvers, an attacker can only 239 redirect you to a different resolver out of that list, which by 240 definition is also trusted. Note: the URI field potentially has 241 different security properties depending on how it is used. As noted 242 above; Firefox does not use it. 244 If the server which is redirected to is not publicly available, this 245 mechanism can be used as a DoS attack. Application clients should 246 test the selected server before committing to it and otherwise fall 247 back to their ordinary DoH selection logic. 249 Any local discovery mechanism has potential privacy impacts: suppose 250 that a user uses their mobile device on ISP A, which redirects it to 251 their own resolver, and ISP B which does not. In that case, the 252 user's DNS queries will be spread over both ISP A's resolver and one 253 of the public trusted resolvers, which could have an impact on the 254 user's privacy. This has to be balanced against the improvement 255 obtained by using a local resolver and the level of metadata leakage 256 that currently occurs to the ISP, but can be mitigated through 257 trusted recursive resolver policies. 259 5. IANA Considerations 261 This document has no IANA actions. 263 6. References 265 6.1. Normative References 267 [I-D.grover-add-policy-detection] 268 Grover, A. and P. Saint-Andre, "DNS Resolver-Based Policy 269 Detection Domain", Work in Progress, Internet-Draft, 270 draft-grover-add-policy-detection-00, 8 July 2019, 271 . 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, 276 DOI 10.17487/RFC2119, March 1997, 277 . 279 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 280 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 281 . 283 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 284 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 285 May 2017, . 287 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 288 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 289 . 291 6.2. Informative References 293 [DOHTRR] Mozilla, ., "Trusted Recursive Resolver", n.d., 294 . 296 [I-D.arkko-abcd-distributed-resolver-selection] 297 Arkko, J., Thomson, M., and T. Hardie, "Selecting 298 Resolvers from a Set of Distributed DNS Resolvers", Work 299 in Progress, Internet-Draft, draft-arkko-abcd-distributed- 300 resolver-selection-01, 9 March 2020, . 304 [I-D.pauly-add-resolver-discovery] 305 Pauly, T., Kinnear, E., Wood, C., McManus, P., and T. 306 Jensen, "Adaptive DNS Resolver Discovery", Work in 307 Progress, Internet-Draft, draft-pauly-add-resolver- 308 discovery-00, 20 May 2020, . 311 [I-D.pp-add-resinfo] 312 Sood, P. and P. Hoffman, "DNS Resolver Information Self- 313 publication", Work in Progress, Internet-Draft, draft-pp- 314 add-resinfo-01, 14 May 2020, . 317 [I-D.pp-add-stub-upgrade] 318 Sood, P. and P. Hoffman, "Upgrading Communication from 319 Stub Resolvers to DoT or DoH", Work in Progress, Internet- 320 Draft, draft-pp-add-stub-upgrade-01, 14 May 2020, 321 . 324 Acknowledgments 326 TODO acknowledge. 328 Authors' Addresses 330 Eric Rescorla 331 Mozilla 333 Email: ekr@rtfm.com 335 Jason Livingood 336 Comcast 338 Email: jason_livingood@comcast.com