idnits 2.17.00 (12 Aug 2021) /tmp/idnits37775/draft-ietf-add-ddr-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 (10 February 2021) is 464 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 (-09) exists of draft-ietf-dnsop-svcb-https-02 == Outdated reference: A later version (-14) exists of draft-ietf-tls-esni-09 == Outdated reference: A later version (-04) exists of draft-schwartz-svcb-dns-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADD T. Pauly 3 Internet-Draft E. Kinnear 4 Intended status: Standards Track Apple Inc. 5 Expires: 14 August 2021 C.A. Wood 6 Cloudflare 7 P. McManus 8 Fastly 9 T. Jensen 10 Microsoft 11 10 February 2021 13 Discovery of Designated Resolvers 14 draft-ietf-add-ddr-00 16 Abstract 18 This document defines Discovery of Designated Resolvers (DDR), a 19 mechanism for DNS clients to use DNS records to discover a resolver's 20 encrypted DNS configuration. This mechanism can be used to move from 21 unencrypted DNS to encrypted DNS when only the IP address of an 22 encrypted resolver is known. It can also be used to discover support 23 for encrypted DNS protocols when the name of an encrypted resolver is 24 known. This mechanism is designed to be limited to cases where 25 unencrypted resolvers and their designated resolvers are operated by 26 the same entity. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 14 August 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. DNS Service Binding Records . . . . . . . . . . . . . . . . . 3 65 4. Discovery Using Resolver IP Addresses . . . . . . . . . . . . 4 66 4.1. Authenticated Discovery . . . . . . . . . . . . . . . . . 5 67 4.2. Opportunistic Discovery . . . . . . . . . . . . . . . . . 5 68 5. Discovery Using Resolver Names . . . . . . . . . . . . . . . 6 69 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 6 70 6.1. Caching Forwarders . . . . . . . . . . . . . . . . . . . 7 71 6.2. Certificate Management . . . . . . . . . . . . . . . . . 7 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8.1. Special Use Domain Name "resolver.arpa" . . . . . . . . . 8 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 9.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Appendix A. Rationale for using SVCB records . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 When DNS clients wish to use encrypted DNS protocols such as DNS- 84 over-TLS (DoT) [RFC7858] or DNS-over-HTTPS (DoH) [RFC8484], they 85 require additional information beyond the IP address of the DNS 86 server, such as the resolver's hostname, non-standard ports, or URL 87 paths. However, common configuration mechanisms only provide the 88 resolver's IP address during configuration. Such mechanisms include 89 network provisioning protocols like DHCP [RFC2132] and IPv6 Router 90 Advertisement (RA) options [RFC8106], as well as manual 91 configuration. 93 This document defines two mechanisms for clients to discover 94 designated resolvers using DNS server Service Binding (SVCB, 95 [I-D.ietf-dnsop-svcb-https]) records: 97 1. When only an IP address of an Unencrypted Resolver is known, the 98 client queries a special use domain name to discover DNS SVCB 99 records associated with the Unencrypted Resolver (Section 4). 101 2. When the hostname of an encrypted DNS server is known, the client 102 requests details by sending a query for a DNS SVCB record. This 103 can be used to discover alternate encrypted DNS protocols 104 supported by a known server, or to provide details if a resolver 105 name is provisioned by a network (Section 5). 107 Both of these approaches allow clients to confirm that a discovered 108 Encrypted Resolver is designated by the originally provisioned 109 resolver. "Equivalence" in this context means that the resolvers are 110 operated by the same entity; for example, the resolvers are 111 accessible on the same IP address, or there is a certificate that 112 claims ownership over both resolvers. 114 1.1. Specification of Requirements 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 2. Terminology 124 This document defines the following terms: 126 DDR: Discovery of Designated Resolvers. Refers to the mechanisms 127 defined in this document. 129 Designated Resolver: A resolver, presumably an Encrypted Resolver, 130 designated by another resolver for use in its own place. This 131 designation can be authenticated with TLS certificates. 133 Encrypted Resolver: A DNS resolver using any encrypted DNS 134 transport. This includes current mechanisms such as DoH and DoT 135 as well as future mechanisms. 137 Unencrypted Resolver: A DNS resolver using TCP or UDP port 53. 139 3. DNS Service Binding Records 141 DNS resolvers can advertise one or more Designated Resolvers that may 142 offer support over encrypted channels and are controlled by the same 143 entity. 145 When a client discovers Designated Resolvers, it learns information 146 such as the supported protocols, ports, and server name to use in 147 certificate validation. This information is provided in Service 148 Binding (SVCB) records for DNS Servers, defined by 149 [I-D.schwartz-svcb-dns]. 151 The following is an example of an SVCB record describing a DoH 152 server: 154 _dns.example.net 7200 IN SVCB 1 . ( 155 alpn=h2 dohpath=/dns-query{?dns} ipv4hint=x.y.z.w ) 157 The following is an example of an SVCB record describing a DoT 158 server: 160 _dns.example.net 7200 IN SVCB 1 dot.example.net ( 161 alpn=dot port=8530 ipv4hint=x.y.z.w ) 163 If multiple Designated Resolvers are available, using one or more 164 encrypted DNS protocols, the resolver deployment can indicate a 165 preference using the priority fields in each SVCB record 166 [I-D.ietf-dnsop-svcb-https]. 168 This document focuses on discovering DoH and DoT Designated 169 Resolvers. Other protocols can also use the format defined by 170 [I-D.schwartz-svcb-dns]. However, if any protocol does not involve 171 some form of certificate validation, new validation mechanisms will 172 need to be defined to support validating equivalence as defined in 173 Section 4.1. 175 4. Discovery Using Resolver IP Addresses 177 When a DNS client is configured with an Unencrypted Resolver IP 178 address, it SHOULD query the resolver for SVCB records for 179 "dns://resolver.arpa" before making other queries. Specifically, the 180 client issues a query for "_dns.resolver.arpa" with the SVCB resource 181 record type (64) [I-D.ietf-dnsop-svcb-https]. 183 If the recursive resolver that receives this query has one or more 184 Designated Resolvers, it will return the corresponding SVCB records. 185 When responding to these special queries for "dns://resolver.arpa", 186 the SVCB records SHOULD contain at least one "ipv4hint" and/or 187 "ipv6hint" keys. These address hints indicate the address on which 188 the corresponding Encrypted Resolver can be reached and avoid 189 additional DNS lookup for the A and AAAA records of the Encrypted 190 Resolver name. 192 4.1. Authenticated Discovery 194 In order to be considered an authenticated Designated Resolver, the 195 TLS certificate presented by the Encrypted Resolver MUST contain both 196 the domain name (from the SVCB answer) and the IP address of the 197 designating Unencrypted Resolver within the SubjectAlternativeName 198 certificate field. The client MUST check the SubjectAlternativeName 199 field for both the Unencrypted Resolver's IP address and the 200 advertised name of the Designated Resolver. If the certificate can 201 be validated, the client SHOULD use the discovered Designated 202 Resolver for any cases in which it would have otherwise used the 203 Unencrypted Resolver. If the Designated Resolver has a different IP 204 address than the Unencrypted Resolver and the TLS certificate does 205 not cover the Unencrypted Resolver address, the client MUST NOT use 206 the discovered Encrypted Resolver. Additionally, the client SHOULD 207 suppress any further queries for Designated Resolvers using this 208 Unencrypted Resolver for the length of time indicated by the SVCB 209 record's Time to Live (TTL). 211 If the Designated Resolver and the Unencrypted Resolver share an IP 212 address, clients MAY choose to opportunistically use the Encrypted 213 Resolver even without this certificate check (Section 4.2). 215 4.2. Opportunistic Discovery 217 There are situations where authenticated discovery of encrypted DNS 218 configuration over unencrypted DNS is not possible. This includes 219 Unencrypted Resolvers on non-public IP addresses whose identity 220 cannot be confirmed using TLS certificates. 222 Opportunistic Privacy is defined for DoT in Section 4.1 of [RFC7858] 223 as a mode in which clients do not validate the name of the resolver 224 presented in the certificate. A client MAY use information from the 225 SVCB record for "dns://resolver.arpa" with this "opportunistic" 226 approach (not validating the names presented in the 227 SubjectAlternativeName field of the certificate) as long as the IP 228 address of the Encrypted Resolver does not differ from the IP address 229 of the Unencrypted Resolver, and that IP address is a private address 230 (such as those defined in [RFC1918]). This approach can be used for 231 DoT or DoH. 233 If the IP addresses of the Encrypted and Unencrypted Resolvers are 234 not the same, or the shared IP address is not a private IP address, 235 the client MUST NOT use the Encrypted Resolver opportunistically. 237 5. Discovery Using Resolver Names 239 A DNS client that already knows the name of an Encrypted Resolver can 240 use DEER to discover details about all supported encrypted DNS 241 protocols. This situation can arise if a client has been configured 242 to use a given Encrypted Resolver, or if a network provisioning 243 protocol (such as DHCP or IPv6 Router Advertisements) provides a name 244 for an Encrypted Resolver alongside the resolver IP address. 246 For these cases, the client simply sends a DNS SVCB query using the 247 known name of the resolver. This query can be issued to the named 248 Encrypted Resolver itself or to any other resolver. Unlike the case 249 of bootstrapping from an Unencrypted Resolver (Section 4), these 250 records SHOULD be available in the public DNS. 252 For example, if the client already knows about a DoT server 253 "resolver.example.com", it can issue an SVCB query for 254 "_dns.resolver.example.com" to discover if there are other encrypted 255 DNS protocols available. In the following example, the SVCB answers 256 indicate that "resolver.example.com" supports both DoH and DoT, and 257 that the DoH server indicates a higher priority than the DoT server. 259 _dns.resolver.example.com 7200 IN SVCB 1 . ( 260 alpn=h2 dohpath=/dns-query{?dns} ) 261 _dns.resolver.example.com 7200 IN SVCB 2 . ( 262 alpn=dot ) 264 Often, the various supported encrypted DNS protocols will be 265 accessible using the same hostname. In the example above, both DoH 266 and DoT use the name "resolver.example.com" for their TLS 267 certficates. If a deployment uses a different hostname for one 268 protocol, but still wants clients to treat both DNS servers as 269 designated, the TLS certificates MUST include both names in the 270 SubjectAlternativeName fields. Note that this name verification is 271 not related to the DNS resolver that provided the SVCB answer. 273 For example, being able to discover a Designated Resolver for a known 274 Encrypted Resolver is useful when a client has a DoT configuration 275 for "foo.resolver.example.com" but is on a network that blocks DoT 276 traffic. The client can still send a query to any other accessible 277 resolver (either the local network resolver or an accessible DoH 278 server) to discover if there is a designated DoH server for 279 "foo.resolver.example.com". 281 6. Deployment Considerations 283 Resolver deployments that support DEER are advised to consider the 284 following points. 286 6.1. Caching Forwarders 288 If a caching forwarder consults multiple resolvers, it may be 289 possible for it to cache records for the "resolver.arpa" Special Use 290 Domain Name (SUDN) for multiple resolvers. This may result in 291 clients sending queries intended to discover Designated Resolvers for 292 resolver "foo" and receiving answers for resolvers "foo" and "bar". 294 A client will successfully reject unintended connections because the 295 authenticated discovery will fail or the resolver addresses do not 296 match. Clients that attempt unauthenticated connections to resolvers 297 discovered through SVCB queries run the risk of connecting to the 298 wrong server in this scenario. 300 To prevent unnecessary traffic from clients to incorrect resolvers, 301 DNS caching resolvers SHOULD NOT cache results for the 302 "resolver.arpa" SUDN other than for Designated Resolvers under their 303 control. 305 6.2. Certificate Management 307 Resolver owners that support authenticated discovery will need to 308 list valid referring IP addresses in their TLS certificates. This 309 may pose challenges for resolvers with a large number of referring IP 310 addresses. 312 7. Security Considerations 314 Since client can receive DNS SVCB answers over unencrypted DNS, on- 315 path attackers can prevent successful discovery by dropping SVCB 316 packets. Clients should be aware that it might not be possible to 317 distinguish between resolvers that do not have any Designated 318 Resolver and such an active attack. 320 While the IP address of the Unencrypted Resolver is often provisioned 321 over insecure mechanisms, it can also be provisioned securely, such 322 as via manual configuration, a VPN, or on a network with protections 323 like RA guard [RFC6105]. An attacker might try to direct Encrypted 324 DNS traffic to itself by causing the client to think that a 325 discovered Designated Resolver uses a different IP address from the 326 Unencrypted Resolver. Such an Encrypted Resolver might have a valid 327 certificate, but be operated by an attacker that is trying to observe 328 or modify user queries without the knowledge of the client or 329 network. 331 If the IP address of a Designated Resolver differs from that of an 332 Unencrypted Resolver, clients MUST validate that the IP address of 333 the Unencrypted Resolver is covered by the SubjectAlternativeName of 334 the Encrypted Resolver's TLS certificate (Section 4.1). 336 Opportunistic use of Encrypted Resolvers MUST be limited to cases 337 where the Unencrypted Resolver and Designated Resolver have the same 338 IP address (Section 4.2). 340 8. IANA Considerations 342 8.1. Special Use Domain Name "resolver.arpa" 344 This document calls for the creation of the "resolver.arpa" SUDN. 345 This will allow resolvers to respond to queries directed at 346 themselves rather than a specific domain name. While this document 347 uses "resolver.arpa" to return SVCB records indicating designated 348 encrypted capability, the name is generic enough to allow future 349 reuse for other purposes where the resolver wishes to provide 350 information about itself to the client. 352 9. References 354 9.1. Normative References 356 [I-D.ietf-dnsop-svcb-https] 357 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 358 and parameter specification via the DNS (DNS SVCB and 359 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 360 dnsop-svcb-https-02, 2 November 2020, 361 . 364 [I-D.ietf-tls-esni] 365 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 366 Encrypted Client Hello", Work in Progress, Internet-Draft, 367 draft-ietf-tls-esni-09, 16 December 2020, 368 . 371 [I-D.schwartz-svcb-dns] 372 Schwartz, B., "Service Binding Mapping for DNS Servers", 373 Work in Progress, Internet-Draft, draft-schwartz-svcb-dns- 374 01, 10 August 2020, . 377 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 378 J., and E. Lear, "Address Allocation for Private 379 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 380 February 1996, . 382 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 383 and P. Hoffman, "Specification for DNS over Transport 384 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 385 2016, . 387 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 388 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 389 . 391 9.2. Informative References 393 [I-D.schinazi-httpbis-doh-preference-hints] 394 Schinazi, D., Sullivan, N., and J. Kipp, "DoH Preference 395 Hints for HTTP", Work in Progress, Internet-Draft, draft- 396 schinazi-httpbis-doh-preference-hints-02, 13 July 2020, 397 . 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, 402 DOI 10.17487/RFC2119, March 1997, 403 . 405 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 406 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 407 . 409 [RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, 410 Ed., "Design Choices When Expanding the DNS", RFC 5507, 411 DOI 10.17487/RFC5507, April 2009, 412 . 414 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 415 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 416 DOI 10.17487/RFC6105, February 2011, 417 . 419 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 420 "IPv6 Router Advertisement Options for DNS Configuration", 421 RFC 8106, DOI 10.17487/RFC8106, March 2017, 422 . 424 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 425 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 426 May 2017, . 428 Appendix A. Rationale for using SVCB records 430 This mechanism uses SVCB/HTTPS resource records 431 [I-D.ietf-dnsop-svcb-https] to communicate that a given domain 432 designates a particular Designated Resolver for clients to use in 433 place of an Unencrypted Resolver (using a SUDN) or another Encrypted 434 Resolver (using its domain name). 436 There are various other proposals for how to provide similar 437 functionality. There are several reasons that this mechanism has 438 chosen SVCB records: 440 * Discovering encrypted resolver using DNS records keeps client 441 logic for DNS self-contained and allows a DNS resolver operator to 442 define which resolver names and IP addresses are related to one 443 another. 445 * Using DNS records also does not rely on bootstrapping with higher- 446 level application operations (such as 447 [I-D.schinazi-httpbis-doh-preference-hints]). 449 * SVCB records are extensible and allow definition of parameter 450 keys. This makes them a superior mechanism for extensibility as 451 compared to approaches such as overloading TXT records. The same 452 keys can be used for discovering Designated Resolvers of different 453 transport types as well as those advertised by Unencrypted 454 Resolvers or another Encrypted Resolver. 456 * Clients and servers that are interested in privacy of names will 457 already need to support SVCB records in order to use Encrypted TLS 458 Client Hello [I-D.ietf-tls-esni]. Without encrypting names in 459 TLS, the value of encrypting DNS is reduced, so pairing the 460 solutions provides the largest benefit. 462 * Clients that support SVCB will generally send out three queries 463 when accessing web content on a dual-stack network: A, AAAA, and 464 HTTPS queries. Discovering a Designated Resolver as part of one 465 of these queries, without having to add yet another query, 466 minimizes the total number of queries clients send. While 467 [RFC5507] recommends adding new RRTypes for new functionality, 468 SVCB provides an extension mechanism that simplifies client 469 behavior. 471 Authors' Addresses 473 Tommy Pauly 474 Apple Inc. 475 One Apple Park Way 476 Cupertino, California 95014, 477 United States of America 479 Email: tpauly@apple.com 481 Eric Kinnear 482 Apple Inc. 483 One Apple Park Way 484 Cupertino, California 95014, 485 United States of America 487 Email: ekinnear@apple.com 489 Christopher A. Wood 490 Cloudflare 491 101 Townsend St 492 San Francisco, 493 United States of America 495 Email: caw@heapingbits.net 497 Patrick McManus 498 Fastly 500 Email: mcmanus@ducksong.com 502 Tommy Jensen 503 Microsoft 505 Email: tojens@microsoft.com