idnits 2.17.1 draft-ietf-add-ddr-10.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 : ---------------------------------------------------------------------------- == There are 10 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (5 August 2022) is 637 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 (-16) exists of draft-ietf-add-dnr-12 == Outdated reference: A later version (-09) exists of draft-ietf-add-svcb-dns-06 == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-10 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-14 Summary: 0 errors (**), 0 flaws (~~), 6 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: 6 February 2023 C. A. Wood 6 Cloudflare 7 P. McManus 8 Fastly 9 T. Jensen 10 Microsoft 11 5 August 2022 13 Discovery of Designated Resolvers 14 draft-ietf-add-ddr-10 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. An encrypted DNS resolver discovered in 21 this manner is referred to as a "Designated Resolver". This 22 mechanism can be used to move from unencrypted DNS to encrypted DNS 23 when only the IP address of a resolver is known. This mechanism is 24 designed to be limited to cases where unencrypted DNS resolvers and 25 their designated resolvers are operated by the same entity or 26 cooperating entities. It can also be used to discover support for 27 encrypted DNS protocols when the name of an encrypted DNS resolver is 28 known. 30 Discussion Venues 32 This note is to be removed before publishing as an RFC. 34 Discussion of this document takes place on the Adaptive DNS Discovery 35 Working Group mailing list (add@ietf.org), which is archived at 36 https://mailarchive.ietf.org/arch/browse/add/. 38 Source for this draft and an issue tracker can be found at 39 https://github.com/ietf-wg-add/draft-ietf-add-ddr. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on 6 February 2023. 58 Copyright Notice 60 Copyright (c) 2022 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Revised BSD License text as 69 described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Revised BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. DNS Service Binding Records . . . . . . . . . . . . . . . . . 4 78 4. Discovery Using Resolver IP Addresses . . . . . . . . . . . . 6 79 4.1. Use of Designated Resolvers . . . . . . . . . . . . . . . 7 80 4.1.1. Use of Designated Resolvers across network changes . 8 81 4.2. Verified Discovery . . . . . . . . . . . . . . . . . . . 8 82 4.3. Opportunistic Discovery . . . . . . . . . . . . . . . . . 9 83 5. Discovery Using Resolver Names . . . . . . . . . . . . . . . 10 84 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 11 85 6.1. Caching Forwarders . . . . . . . . . . . . . . . . . . . 11 86 6.2. Certificate Management . . . . . . . . . . . . . . . . . 11 87 6.3. Server Name Handling . . . . . . . . . . . . . . . . . . 11 88 6.4. Handling non-DDR queries for resolver.arpa . . . . . . . 12 89 6.5. Interaction with Network-Designated Resolvers . . . . . . 12 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 92 8.1. Special Use Domain Name "resolver.arpa" . . . . . . . . . 14 93 8.2. Domain Name Reservation Considerations . . . . . . . . . 14 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 97 9.2. Informative References . . . . . . . . . . . . . . . . . 17 98 Appendix A. Rationale for using a Special Use Domain Name . . . 18 99 Appendix B. Rationale for using SVCB records . . . . . . . . . . 18 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 102 1. Introduction 104 When DNS clients wish to use encrypted DNS protocols such as DNS- 105 over-TLS (DoT) [RFC7858], DNS-over-QUIC (DoQ) [RFC9250], or DNS-over- 106 HTTPS (DoH) [RFC8484], they can require additional information beyond 107 the IP address of the DNS server, such as the resolver's hostname, 108 alternate IP addresses, non-standard ports, or URI templates. 109 However, common configuration mechanisms only provide the resolver's 110 IP address during configuration. Such mechanisms include network 111 provisioning protocols like DHCP [RFC2132] [RFC8415] and IPv6 Router 112 Advertisement (RA) options [RFC8106], as well as manual 113 configuration. 115 This document defines two mechanisms for clients to discover 116 designated resolvers that support these encrypted protocols using DNS 117 server Service Binding (SVCB, [I-D.ietf-dnsop-svcb-https]) records: 119 1. When only an IP address of an Unencrypted DNS Resolver is known, 120 the client queries a special use domain name (SUDN) [RFC6761] to 121 discover DNS SVCB records associated with one or more Encrypted 122 DNS Resolvers the Unencrypted DNS Resolver has designated for use 123 when support for DNS encryption is requested (Section 4). 125 2. When the hostname of an Encrypted DNS Resolver is known, the 126 client requests details by sending a query for a DNS SVCB record. 127 This can be used to discover alternate encrypted DNS protocols 128 supported by a known server, or to provide details if a resolver 129 name is provisioned by a network (Section 5). 131 Both of these approaches allow clients to confirm that a discovered 132 Encrypted DNS Resolver is designated by the originally provisioned 133 resolver. "Designated" in this context means that the resolvers are 134 operated by the same entity or cooperating entities; for example, the 135 resolvers are accessible on the same IP address, or there is a 136 certificate that contains the IP address for the original designating 137 resolver. 139 1.1. Specification of Requirements 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 2. Terminology 149 This document defines the following terms: 151 DDR: Discovery of Designated Resolvers. Refers to the mechanisms 152 defined in this document. 154 Designated Resolver: A resolver, presumably an Encrypted DNS 155 Resolver, designated by another resolver for use in its own place. 156 This designation can be verified with TLS certificates. 158 Encrypted DNS Resolver: A DNS resolver using any encrypted DNS 159 transport. This includes current mechanisms such as DoH, DoT, and 160 DoQ, as well as future mechanisms. 162 Unencrypted DNS Resolver: A DNS resolver using a transport without 163 encryption, historically TCP or UDP port 53. 165 3. DNS Service Binding Records 167 DNS resolvers can advertise one or more Designated Resolvers that may 168 offer support over encrypted channels and are controlled by the same 169 entity. 171 When a client discovers Designated Resolvers, it learns information 172 such as the supported protocols and ports. This information is 173 provided in ServiceMode Service Binding (SVCB) records for DNS 174 Servers, although AliasMode SVCB records can be used to direct 175 clients to the needed ServiceMode SVCB record per 176 [I-D.ietf-dnsop-svcb-https]. The formatting of these records, 177 including the DNS-unique parameters such as "dohpath", are defined by 178 [I-D.ietf-add-svcb-dns]. 180 The following is an example of an SVCB record describing a DoH server 181 discovered by querying for _dns.example.net: 183 _dns.example.net. 7200 IN SVCB 1 example.net. ( 184 alpn=h2 dohpath=/dns-query{?dns} ) 186 The following is an example of an SVCB record describing a DoT server 187 discovered by querying for _dns.example.net: 189 _dns.example.net. 7200 IN SVCB 1 dot.example.net ( 190 alpn=dot port=8530 ) 192 The following is an example of an SVCB record describing a DoQ server 193 discovered by querying for _dns.example.net: 195 _dns.example.net. 7200 IN SVCB 1 doq.example.net ( 196 alpn=doq port=8530 ) 198 If multiple Designated Resolvers are available, using one or more 199 encrypted DNS protocols, the resolver deployment can indicate a 200 preference using the priority fields in each SVCB record 201 [I-D.ietf-dnsop-svcb-https]. 203 If the client encounters a mandatory parameter in an SVCB record it 204 does not understand, it MUST NOT use that record to discover a 205 Designated Resolver, in accordance with Section 8 of 206 [I-D.ietf-dnsop-svcb-https]. The client can still use other records 207 in the same response if the client can understand all of their 208 mandatory parameters. This allows future encrypted deployments to 209 simultaneously support protocols even if a given client is not aware 210 of all those protocols. For example, if the Unencrypted DNS Resolver 211 returns three SVCB records, one for DoH, one for DoT, and one for a 212 yet-to-exist protocol, a client which only supports DoH and DoT 213 should be able to use those records while safely ignoring the third 214 record. 216 To avoid name lookup deadlock, clients that use Designated Resolvers 217 need to ensure that a specific Encrypted Resolver is not used for any 218 queries that are needed to resolve the name of the resolver itself or 219 to perform certificate revocation checks for the resolver, as 220 described in Section 10 of [RFC8484]. Designated Resolvers need to 221 ensure this deadlock is avoidable as described in Section 10 of 222 [RFC8484]. 224 This document focuses on discovering DoH, DoT, and DoQ Designated 225 Resolvers. Other protocols can also use the format defined by 226 [I-D.ietf-add-svcb-dns]. However, if any such protocol does not 227 involve some form of certificate validation, new validation 228 mechanisms will need to be defined to support validating designation 229 as defined in Section 4.2. 231 4. Discovery Using Resolver IP Addresses 233 When a DNS client is configured with an Unencrypted DNS Resolver IP 234 address, it SHOULD query the resolver for SVCB records of a service 235 with a scheme of "dns" and an Authority of "resolver.arpa" before 236 making other queries. This allows the client to switch to using 237 Encrypted DNS for all other queries, if possible. Specifically, the 238 client issues a query for _dns.resolver.arpa. with the SVCB resource 239 record type (64) [I-D.ietf-dnsop-svcb-https]. 241 Responses to the SVCB query for the "resolver.arpa" SUDN describe 242 Designated Resolvers. To ensure that different Designated Resolver 243 configurations can be correctly distinguished and associated with A 244 and AAAA records for the resolver, ServiceMode SVCB responses to 245 these queries MUST NOT use the "." or "resolver.arpa" value for the 246 TargetName. Similarly, clients MUST NOT perform A or AAAA queries 247 for "resolver.arpa". 249 The following is an example of an SVCB record describing a DoH server 250 discovered by querying for _dns.resolver.arpa: 252 _dns.resolver.arpa. 7200 IN SVCB 1 doh.example.net ( 253 alpn=h2 dohpath=/dns-query{?dns} ) 255 The following is an example of an SVCB record describing a DoT server 256 discovered by querying for _dns.resolver.arpa: 258 _dns.resolver.arpa. 7200 IN SVCB 1 dot.example.net ( 259 alpn=dot port=8530 ) 261 The following is an example of an SVCB record describing a DoQ server 262 discovered by querying for _dns.resolver.arpa: 264 _dns.resolver.arpa. 7200 IN SVCB 1 doq.example.net ( 265 alpn=doq port=8530 ) 267 If the recursive resolver that receives this query has one or more 268 Designated Resolvers, it will return the corresponding SVCB records. 269 When responding to these special queries for "resolver.arpa", the 270 recursive resolver SHOULD include the A and AAAA records for the name 271 of the Designated Resolver in the Additional Answers section. This 272 will save the DNS client an additional round trip to retrieve the 273 address of the designated resolver; see Section 5 of 274 [I-D.ietf-dnsop-svcb-https]. 276 Designated Resolvers SHOULD be accessible using the IP address 277 families that are supported by their associated Unencrypted DNS 278 Resolvers. If an Unencrypted DNS Resolver is accessible using an 279 IPv4 address, it ought to provide an A record for an IPv4 address of 280 the Designated Resolver; similarly, if it is accessible using an IPv6 281 address, it ought to provide a AAAA record for an IPv6 address of the 282 Designated Resolver. The Designated Resolver MAY support more 283 address families than the Unencrypted DNS Resolver, but it SHOULD NOT 284 support fewer. If this is not done, clients that only have 285 connectivity over one address family might not be able to access the 286 Designated Resolver. 288 If the recursive resolver that receives this query has no Designated 289 Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa" 290 zone, to provide a consistent and accurate signal to clients that it 291 does not have a Designated Resolver. 293 4.1. Use of Designated Resolvers 295 When a client discovers Designated Resolvers from an Unencrypted DNS 296 Resolver IP address, it can choose to use these Designated Resolvers 297 either automatically, or based on some other policy, heuristic, or 298 user choice. 300 This document defines two preferred methods to automatically use 301 Designated Resolvers: 303 * Verified Discovery (Section 4.2), for when a TLS certificate can 304 be used to validate the resolver's identity. 306 * Opportunistic Discovery (Section 4.3), for when a resolver's IP 307 address is a private or local address. 309 A client MAY additionally use a discovered Designated Resolver 310 without either of these methods, based on implementation-specific 311 policy or user input. Details of such policy are out of scope of 312 this document. Clients MUST NOT automatically use a Designated 313 Resolver without some sort of validation, such as the two methods 314 defined in this document or a future mechanism. Use without 315 validation can allow an attacker to direct traffic to an Encrypted 316 Resolver that is unrelated to the original Unencrypted DNS Resolver, 317 as described in Section 7. 319 A client MUST NOT re-use a designation discovered using the IP 320 address of one Unencrypted DNS Resolver in place of any other 321 Unencrypted DNS Resolver. Instead, the client needs to repeat the 322 discovery process to discover the Designated Resolver of the other 323 Unencrypted DNS Resolver. In other words, designations are per- 324 resolver and MUST NOT be used to configure the client's universal DNS 325 behavior. This ensures in all cases that queries are being sent to a 326 party designated by the resolver originally being used. 328 4.1.1. Use of Designated Resolvers across network changes 330 If a client is configured with the same Unencrypted DNS Resolver IP 331 address on multiple different networks, a Designated Resolver that 332 has been discovered on one network SHOULD NOT be reused on any of the 333 other networks without repeating the discovery process for each 334 network, since the same IP address may be used for different servers 335 on the different networks. 337 4.2. Verified Discovery 339 Verified Discovery is a mechanism that allows automatic use of a 340 Designated Resolver that supports DNS encryption that performs a TLS 341 handshake. 343 In order to be considered a verified Designated Resolver, the TLS 344 certificate presented by the Designated Resolver needs to pass the 345 following checks made by the client: 347 1. The client MUST verify the chain of certificates up to a trust 348 anchor as described in Section 6 of [RFC5280]. This SHOULD use 349 the default system or application trust anchors, unless otherwise 350 configured. 352 2. The client MUST verify that the certificate contains the IP 353 address of the designating Unencrypted DNS Resolver in an 354 iPAddress entry of the subjectAltName extension as described in 355 Section 4.2.1.6 of [RFC5280]. 357 If these checks pass, the client SHOULD use the discovered Designated 358 Resolver for any cases in which it would have otherwise used the 359 Unencrypted DNS Resolver, so as to prefer Encrypted DNS whenever 360 possible. 362 If these checks fail, the client MUST NOT automatically use the 363 discovered Designated Resolver if this designation was only 364 discovered via a _dns.resolver.arpa. query (if the designation was 365 advertised directly by the network as described in Section 6.5, the 366 server can still be used). Additionally, the client SHOULD suppress 367 any further queries for Designated Resolvers using this Unencrypted 368 DNS Resolver for the length of time indicated by the SVCB record's 369 Time to Live (TTL) in order to avoid excessive queries that will lead 370 to further failed validations. The client MAY issue new queries if 371 the SVCB record's TTL is excessively long (as determined by client 372 policy) to minimize the length of time an intermittent attacker can 373 prevent use of encrypted DNS. 375 If the Designated Resolver and the Unencrypted DNS Resolver share an 376 IP address, clients MAY choose to opportunistically use the 377 Designated Resolver even without this certificate check 378 (Section 4.3). If the IP address is not shared, opportunistic use 379 allows for attackers to redirect queries to an unrelated Encrypted 380 Resolver, as described in Section 7. 382 Connections to a Designated Resolver can use a different IP address 383 than the IP address of the Unencrypted DNS Resolver, such as if the 384 process of resolving the SVCB service yields additional addresses. 385 Even when a different IP address is used for the connection, the TLS 386 certificate checks described in this section still apply for the 387 original IP address of the Unencrypted DNS Resolver. 389 4.3. Opportunistic Discovery 391 There are situations where Verified Discovery of encrypted DNS 392 configuration over unencrypted DNS is not possible. This includes 393 Unencrypted DNS Resolvers on private IP addresses [RFC1918], Unique 394 Local Addresses (ULAs) [RFC4193], and Link Local Addresses [RFC3927] 395 [RFC4291], whose identity cannot be safely confirmed using TLS 396 certificates under most conditions. 398 An Opportunistic Privacy Profile is defined for DoT in Section 4.1 of 399 [RFC7858] as a mode in which clients do not validate the name of the 400 resolver presented in the certificate. This Opportunistic Privacy 401 Profile similarly applies to DoQ [RFC9250]. For this profile, 402 Section 4.1 of [RFC7858] explains that clients might or might not 403 validate the resolver; however, even if clients choose to perform 404 some certificate validation checks, they will not be able to validate 405 the names presented in the SubjectAlternativeName field of the 406 certificate for private and local IP addresses. 408 A client MAY use information from the SVCB record for 409 "_dns.resolver.arpa" with this Opportunistic Privacy Profile as long 410 as the IP address of the Encrypted DNS Resolver does not differ from 411 the IP address of the Unencrypted DNS Resolver. Clients SHOULD use 412 this mode only for resolvers using private or local IP addresses, 413 since resolvers that use other addresses are able to provision TLS 414 certificates for their addresses. 416 5. Discovery Using Resolver Names 418 A DNS client that already knows the name of an Encrypted DNS Resolver 419 can use DDR to discover details about all supported encrypted DNS 420 protocols. This situation can arise if a client has been configured 421 to use a given Encrypted DNS Resolver, or if a network provisioning 422 protocol (such as DHCP or IPv6 Router Advertisements) provides a name 423 for an Encrypted DNS Resolver alongside the resolver IP address, such 424 as by using Discovery of Network Resolvers (DNR) [I-D.ietf-add-dnr]. 426 For these cases, the client simply sends a DNS SVCB query using the 427 known name of the resolver. This query can be issued to the named 428 Encrypted DNS Resolver itself or to any other resolver. Unlike the 429 case of bootstrapping from an Unencrypted DNS Resolver (Section 4), 430 these records SHOULD be available in the public DNS if the same 431 domain name's A or AAAA records are available in the public DNS to 432 allow using any resolver to discover another resolver's Designated 433 Resolvers. When the name can only be resolved in private namespaces, 434 these records SHOULD be available to the same audience as the A and 435 AAAA records. 437 For example, if the client already knows about a DoT server 438 resolver.example.com, it can issue an SVCB query for 439 _dns.resolver.example.com to discover if there are other encrypted 440 DNS protocols available. In the following example, the SVCB answers 441 indicate that resolver.example.com supports both DoH and DoT, and 442 that the DoH server indicates a higher priority than the DoT server. 444 _dns.resolver.example.com. 7200 IN SVCB 1 resolver.example.com. ( 445 alpn=h2 dohpath=/dns-query{?dns} ) 446 _dns.resolver.example.com. 7200 IN SVCB 2 resolver.example.com. ( 447 alpn=dot ) 449 Clients MUST validate that for any Encrypted DNS Resolver discovered 450 using a known resolver name, the TLS certificate of the resolver 451 contains the known name in a subjectAltName extension. In the 452 example above, this means that both servers need to have certificates 453 that cover the name resolver.example.com. Often, the various 454 supported encrypted DNS protocols will be specified such that the 455 SVCB TargetName matches the known name, as is true in the example 456 above. However, even when the TargetName is different (for example, 457 if the DoH server had a TargetName of doh.example.com), the clients 458 still check for the original known resolver name in the certificate. 460 Note that this resolver validation is not related to the DNS resolver 461 that provided the SVCB answer. 463 As another example, being able to discover a Designated Resolver for 464 a known Encrypted DNS Resolver is useful when a client has a DoT 465 configuration for foo.resolver.example.com but is on a network that 466 blocks DoT traffic. The client can still send a query to any other 467 accessible resolver (either the local network resolver or an 468 accessible DoH server) to discover if there is a designated DoH 469 server for foo.resolver.example.com. 471 6. Deployment Considerations 473 Resolver deployments that support DDR are advised to consider the 474 following points. 476 6.1. Caching Forwarders 478 A DNS forwarder SHOULD NOT forward queries for "resolver.arpa" (or 479 any subdomains) upstream. This prevents a client from receiving an 480 SVCB record that will fail to authenticate because the forwarder's IP 481 address is not in the upstream resolver's Designated Resolver's TLS 482 certificate SAN field. A DNS forwarder which already acts as a 483 completely transparent forwarder MAY choose to forward these queries 484 when the operator expects that this does not apply, either because 485 the operator knows that the upstream resolver does have the 486 forwarder's IP address in its TLS certificate's SAN field or that the 487 operator expects clients to validate the connection via some future 488 mechanism. 490 Operators who choose to forward queries for "resolver.arpa" upstream 491 should note that client behavior is never guaranteed and use of DDR 492 by a resolver does not communicate a requirement for clients to use 493 the SVCB record when it cannot be verified. 495 6.2. Certificate Management 497 Resolver owners that support Verified Discovery will need to list 498 valid referring IP addresses in their TLS certificates. This may 499 pose challenges for resolvers with a large number of referring IP 500 addresses. 502 6.3. Server Name Handling 504 Clients MUST NOT use "resolver.arpa" as the server name either in the 505 TLS Server Name Indication (SNI) ([RFC8446]) for DoT, DoQ, or DoH 506 connections, or in the URI host for DoH requests. 508 When performing discovery using resolver IP addresses, clients MUST 509 use the original IP address of the Unencrypted DNS Resolver as the 510 URI host for DoH requests. 512 Note that since IP addresses are not supported by default in the TLS 513 SNI, resolvers that support discovery using IP addresses will need to 514 be configured to present the appropriate TLS certificate when no SNI 515 is present for DoT, DoQ, and DoH. 517 6.4. Handling non-DDR queries for resolver.arpa 519 DNS resolvers that support DDR by responding to queries for 520 _dns.resolver.arpa MUST treat resolver.arpa as a locally served zone 521 per [RFC6303]. In practice, this means that resolvers SHOULD respond 522 to queries of any type other than SVCB for _dns.resolver.arpa with 523 NODATA and queries of any type for any domain name under 524 resolver.arpa with NODATA. 526 6.5. Interaction with Network-Designated Resolvers 528 Discovery of network-designated resolvers (DNR, [I-D.ietf-add-dnr]) 529 allows a network to provide designation of resolvers directly through 530 DHCP [RFC2132] [RFC8415] and IPv6 Router Advertisement (RA) [RFC4861] 531 options. When such indications are present, clients can suppress 532 queries for "resolver.arpa" to the unencrypted DNS server indicated 533 by the network over DHCP or RAs, and the DNR indications SHOULD take 534 precedence over those discovered using "resolver.arpa" for the same 535 resolver if there is a conflict, since DNR is considered a more 536 reliable source. 538 The designated resolver information in DNR might not contain a full 539 set of SvcParams needed to connect to an encrypted DNS resolver. In 540 such a case, the client can use an SVCB query using a resolver name, 541 as described in Section 5, to the authentication-domain-name (ADN). 543 7. Security Considerations 545 Since clients can receive DNS SVCB answers over unencrypted DNS, on- 546 path attackers can prevent successful discovery by dropping SVCB 547 queries or answers, and thus prevent clients from switching to use 548 encrypted DNS. Clients should be aware that it might not be possible 549 to distinguish between resolvers that do not have any Designated 550 Resolver and such an active attack. To limit the impact of discovery 551 queries being dropped either maliciously or unintentionally, clients 552 can re-send their SVCB queries periodically. 554 Section 8.2 of [I-D.ietf-add-svcb-dns] describes a second downgrade 555 attack where an attacker can block connections to the encrypted DNS 556 server. For DDR, clients need to validate a Designated Resolver 557 using a connection to the server before trusting it, so attackers 558 that can block these connections can prevent clients from switching 559 to use encrypted DNS. 561 Encrypted DNS Resolvers that allow discovery using DNS SVCB answers 562 over unencrypted DNS MUST NOT provide differentiated behavior based 563 solely on metadata in the SVCB record, such as the HTTP path or 564 alternate port number, which are parameters that an attacker could 565 modify. For example, if a DoH resolver provides a filtering service 566 for one URI path, and a non-filtered service for another URI path, an 567 attacker could select which of these services is used by modifying 568 the "dohpath" parameter. These attacks can be mitigated by providing 569 separate resolver IP addresses or hostnames. 571 While the IP address of the Unencrypted DNS Resolver is often 572 provisioned over insecure mechanisms, it can also be provisioned 573 securely, such as via manual configuration, a VPN, or on a network 574 with protections like RA-Guard [RFC6105]. An attacker might try to 575 direct Encrypted DNS traffic to itself by causing the client to think 576 that a discovered Designated Resolver uses a different IP address 577 from the Unencrypted DNS Resolver. Such a Designated Resolver might 578 have a valid certificate, but be operated by an attacker that is 579 trying to observe or modify user queries without the knowledge of the 580 client or network. 582 If the IP address of a Designated Resolver differs from that of an 583 Unencrypted DNS Resolver, clients applying Verified Discovery 584 (Section 4.2) MUST validate that the IP address of the Unencrypted 585 DNS Resolver is covered by the SubjectAlternativeName of the 586 Designated Resolver's TLS certificate. If that validation fails, the 587 client MUST NOT automatically use the discovered Designated Resolver. 589 Clients using Opportunistic Discovery (Section 4.3) MUST be limited 590 to cases where the Unencrypted DNS Resolver and Designated Resolver 591 have the same IP address, which SHOULD be a private or local IP 592 address. Clients which do not follow Opportunistic Discovery 593 (Section 4.3) and instead try to connect without first checking for a 594 designation run the possible risk of being intercepted by an attacker 595 hosting an Encrypted DNS Resolver on an IP address of an Unencrypted 596 DNS Resolver where the attacker has failed to gain control of the 597 Unencrypted DNS Resolver. 599 The constraints on the use of Designated Resolvers specified here 600 apply specifically to the automatic discovery mechanisms defined in 601 this document, which are referred to as Verified Discovery and 602 Opportunistic Discovery. Clients MAY use some other mechanism to 603 verify and use Designated Resolvers discovered using the DNS SVCB 604 record. However, use of such an alternate mechanism needs to take 605 into account the attack scenarios detailed here. 607 8. IANA Considerations 608 8.1. Special Use Domain Name "resolver.arpa" 610 This document calls for the addition of "resolver.arpa" to the 611 Special-Use Domain Names (SUDN) registry established by [RFC6761]. 613 IANA is requested to add an entry in "Transport-Independent Locally- 614 Served DNS Zones" registry for 'resolver.arpa.' with the description 615 "DNS Resolver Special-Use Domain", listing this document as the 616 reference. 618 8.2. Domain Name Reservation Considerations 620 In accordance with Section 5 of [RFC6761], the answers to the 621 following questions are provided relative to this document: 623 1) Are human users expected to recognize these names as special and 624 use them differently? In what way? 626 No. This name is used automatically by DNS stub resolvers running on 627 client devices on behalf of users, and users will never see this name 628 directly. 630 2) Are writers of application software expected to make their 631 software recognize these names as special and treat them differently? 632 In what way? 634 No. There is no use case where a non-DNS application (covered by the 635 next question) would need to use this name. 637 3) Are writers of name resolution APIs and libraries expected to make 638 their software recognize these names as special and treat them 639 differently? If so, how? 641 Yes. DNS client implementors are expected to use this name when 642 querying for a resolver's properties instead of records for the name 643 itself. DNS servers are expected to respond to queries for this name 644 with their own properties instead of checking the matching zone as it 645 would for normal domain names. 647 4) Are developers of caching domain name servers expected to make 648 their implementations recognize these names as special and treat them 649 differently? If so, how? 651 Yes. Caching domain name servers should not forward queries for this 652 name to avoid causing validation failures due to IP address mismatch. 654 5) Are developers of authoritative domain name servers expected to 655 make their implementations recognize these names as special and treat 656 them differently? If so, how? 658 No. DDR is designed for use by recursive resolvers. Theoretically, 659 an authoritative server could choose to support this name if it wants 660 to advertise support for encrypted DNS protocols over plain-text DNS, 661 but that scenario is covered by other work in the IETF DNSOP working 662 group. 664 6) Does this reserved Special-Use Domain Name have any potential 665 impact on DNS server operators? If they try to configure their 666 authoritative DNS server as authoritative for this reserved name, 667 will compliant name server software reject it as invalid? Do DNS 668 server operators need to know about that and understand why? Even if 669 the name server software doesn't prevent them from using this 670 reserved name, are there other ways that it may not work as expected, 671 of which the DNS server operator should be aware? 673 This name is locally served, and any resolver which supports this 674 name should never forward the query. DNS server operators should be 675 aware that records for this name will be used by clients to modify 676 the way they connect to their resolvers. 678 7) How should DNS Registries/Registrars treat requests to register 679 this reserved domain name? Should such requests be denied? Should 680 such requests be allowed, but only to a specially-designated entity? 682 IANA should hold the registration for this name. Non-IANA requests 683 to register this name should always be denied by DNS Registries/ 684 Registrars. 686 9. References 688 9.1. Normative References 690 [I-D.ietf-add-dnr] 691 Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. 692 Jensen, "DHCP and Router Advertisement Options for the 693 Discovery of Network-designated Resolvers (DNR)", Work in 694 Progress, Internet-Draft, draft-ietf-add-dnr-12, 24 July 695 2022, . 698 [I-D.ietf-add-svcb-dns] 699 Schwartz, B., "Service Binding Mapping for DNS Servers", 700 Work in Progress, Internet-Draft, draft-ietf-add-svcb-dns- 701 06, 5 July 2022, . 704 [I-D.ietf-dnsop-svcb-https] 705 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 706 and parameter specification via the DNS (DNS SVCB and 707 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 708 dnsop-svcb-https-10, 24 May 2022, 709 . 712 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 713 J., and E. Lear, "Address Allocation for Private 714 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 715 February 1996, . 717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 718 Requirement Levels", BCP 14, RFC 2119, 719 DOI 10.17487/RFC2119, March 1997, 720 . 722 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 723 Configuration of IPv4 Link-Local Addresses", RFC 3927, 724 DOI 10.17487/RFC3927, May 2005, 725 . 727 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 728 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 729 . 731 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 732 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 733 2006, . 735 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 736 Housley, R., and W. Polk, "Internet X.509 Public Key 737 Infrastructure Certificate and Certificate Revocation List 738 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 739 . 741 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 742 RFC 6303, DOI 10.17487/RFC6303, July 2011, 743 . 745 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 746 RFC 6761, DOI 10.17487/RFC6761, February 2013, 747 . 749 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 750 and P. Hoffman, "Specification for DNS over Transport 751 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 752 2016, . 754 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 755 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 756 May 2017, . 758 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 759 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 760 . 762 [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over 763 Dedicated QUIC Connections", RFC 9250, 764 DOI 10.17487/RFC9250, May 2022, 765 . 767 9.2. Informative References 769 [I-D.ietf-tls-esni] 770 Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 771 Encrypted Client Hello", Work in Progress, Internet-Draft, 772 draft-ietf-tls-esni-14, 13 February 2022, 773 . 776 [I-D.schinazi-httpbis-doh-preference-hints] 777 Schinazi, D., Sullivan, N., and J. Kipp, "DoH Preference 778 Hints for HTTP", Work in Progress, Internet-Draft, draft- 779 schinazi-httpbis-doh-preference-hints-02, 13 July 2020, 780 . 783 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 784 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 785 . 787 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 788 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 789 DOI 10.17487/RFC4861, September 2007, 790 . 792 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 793 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 794 DOI 10.17487/RFC6105, February 2011, 795 . 797 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 798 "IPv6 Router Advertisement Options for DNS Configuration", 799 RFC 8106, DOI 10.17487/RFC8106, March 2017, 800 . 802 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 803 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 804 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 805 RFC 8415, DOI 10.17487/RFC8415, November 2018, 806 . 808 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 809 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 810 . 812 [RFC8880] Cheshire, S. and D. Schinazi, "Special Use Domain Name 813 'ipv4only.arpa'", RFC 8880, DOI 10.17487/RFC8880, August 814 2020, . 816 Appendix A. Rationale for using a Special Use Domain Name 818 The "resolver.arpa" SUDN is similar to "ipv4only.arpa" in that the 819 querying client is not interested in an answer from the authoritative 820 "arpa" name servers. The intent of the SUDN is to allow clients to 821 communicate with the Unencrypted DNS Resolver much like 822 "ipv4only.arpa" allows for client-to-middlebox communication. For 823 more context, see the rationale behind "ipv4only.arpa" in [RFC8880]. 825 Appendix B. Rationale for using SVCB records 827 This mechanism uses SVCB/HTTPS resource records 828 [I-D.ietf-dnsop-svcb-https] to communicate that a given domain 829 designates a particular Designated Resolver for clients to use in 830 place of an Unencrypted DNS Resolver (using a SUDN) or another 831 Encrypted DNS Resolver (using its domain name). 833 There are various other proposals for how to provide similar 834 functionality. There are several reasons that this mechanism has 835 chosen SVCB records: 837 * Discovering encrypted DNS resolvers using DNS records keeps client 838 logic for DNS self-contained and allows a DNS resolver operator to 839 define which resolver names and IP addresses are related to one 840 another. 842 * Using DNS records also does not rely on bootstrapping with higher- 843 level application operations (such as 844 [I-D.schinazi-httpbis-doh-preference-hints]). 846 * SVCB records are extensible and allow definition of parameter 847 keys. This makes them a superior mechanism for extensibility as 848 compared to approaches such as overloading TXT records. The same 849 keys can be used for discovering Designated Resolvers of different 850 transport types as well as those advertised by Unencrypted DNS 851 Resolvers or another Encrypted DNS Resolver. 853 * Clients and servers that are interested in privacy of names will 854 already need to support SVCB records in order to use Encrypted TLS 855 Client Hello [I-D.ietf-tls-esni]. Without encrypting names in 856 TLS, the value of encrypting DNS is reduced, so pairing the 857 solutions provides the largest benefit. 859 Authors' Addresses 861 Tommy Pauly 862 Apple Inc. 863 One Apple Park Way 864 Cupertino, California 95014, 865 United States of America 866 Email: tpauly@apple.com 868 Eric Kinnear 869 Apple Inc. 870 One Apple Park Way 871 Cupertino, California 95014, 872 United States of America 873 Email: ekinnear@apple.com 875 Christopher A. Wood 876 Cloudflare 877 101 Townsend St 878 San Francisco, 879 United States of America 880 Email: caw@heapingbits.net 881 Patrick McManus 882 Fastly 883 Email: mcmanus@ducksong.com 885 Tommy Jensen 886 Microsoft 887 Email: tojens@microsoft.com