idnits 2.17.1 draft-ietf-add-dnr-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 : ---------------------------------------------------------------------------- == There are 1 instance 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 (February 22, 2021) is 1157 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: 'ThisDocument' is mentioned on line 979, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-01 == Outdated reference: A later version (-04) exists of draft-schwartz-svcb-dns-01 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADD M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track T. Reddy 5 Expires: August 26, 2021 McAfee 6 D. Wing 7 Citrix 8 N. Cook 9 Open-Xchange 10 T. Jensen 11 Microsoft 12 February 22, 2021 14 DHCP and Router Advertisement Options for the Discovery of Network- 15 designated Resolvers (DNR) 16 draft-ietf-add-dnr-00 18 Abstract 20 The document specifies new DHCP and IPv6 Router Advertisement options 21 to discover encrypted DNS servers (e.g., DNS-over-HTTPS, DNS-over- 22 TLS, DNS-over-QUIC). Particularly, it allows to learn an 23 authentication domain name together with a list of IP addresses and a 24 port number to reach such encrypted DNS servers. The discovery of 25 DNS-over-HTTPS URI Templates is also discussed. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 26, 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Overview and Rationale . . . . . . . . . . . . . . . . . . . 4 64 4. DHCPv6 Encrypted DNS Options . . . . . . . . . . . . . . . . 6 65 4.1. Encrypted DNS ADN Option . . . . . . . . . . . . . . . . 6 66 4.2. Encrypted DNS Address Option . . . . . . . . . . . . . . 7 67 4.3. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 9 68 5. DHCPv4 Encrypted DNS Option . . . . . . . . . . . . . . . . . 9 69 5.1. Encrypted DNS Option . . . . . . . . . . . . . . . . . . 9 70 5.2. DHCPv4 Client Behavior . . . . . . . . . . . . . . . . . 11 71 6. IPv6 RA Encrypted DNS Options . . . . . . . . . . . . . . . . 11 72 6.1. Encrypted DNS ADN Option . . . . . . . . . . . . . . . . 12 73 6.2. Encrypted DNS Address Option . . . . . . . . . . . . . . 13 74 7. DoH URI Templates . . . . . . . . . . . . . . . . . . . . . . 14 75 8. Hosting Encrypted DNS Forwarder in Local Networks . . . . . . 16 76 8.1. Managed CPEs . . . . . . . . . . . . . . . . . . . . . . 16 77 8.1.1. DNS Forwarders . . . . . . . . . . . . . . . . . . . 16 78 8.1.2. ACME . . . . . . . . . . . . . . . . . . . . . . . . 16 79 8.1.3. Auto-Upgrade Based on Domains and their Subdomains . 16 80 8.2. Unmanaged CPEs . . . . . . . . . . . . . . . . . . . . . 17 81 9. Legacy CPEs . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 10.1. Spoofing Attacks . . . . . . . . . . . . . . . . . . . . 18 84 10.2. Deletion Attacks . . . . . . . . . . . . . . . . . . . . 19 85 10.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . 19 86 10.4. Wireless Security - Authentication Attacks . . . . . . . 20 87 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 88 11.1. Encrypted DNS Flag Bits . . . . . . . . . . . . . . . . 20 89 11.2. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 21 90 11.3. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . 21 91 11.4. Neighbor Discovery Options . . . . . . . . . . . . . . . 21 92 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 93 13. Contributing Authors . . . . . . . . . . . . . . . . . . . . 22 94 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 95 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 96 14.2. Informative References . . . . . . . . . . . . . . . . . 23 98 Appendix A. Sample Target Deployment Scenarios . . . . . . . . . 26 99 A.1. Managed CPEs . . . . . . . . . . . . . . . . . . . . . . 28 100 A.1.1. Direct DNS . . . . . . . . . . . . . . . . . . . . . 28 101 A.1.2. Proxied DNS . . . . . . . . . . . . . . . . . . . . . 30 102 A.2. Unmanaged CPEs . . . . . . . . . . . . . . . . . . . . . 31 103 A.2.1. ISP-facing Unmanaged CPEs . . . . . . . . . . . . . . 31 104 A.2.2. Internal Unmanaged CPEs . . . . . . . . . . . . . . . 31 105 Appendix B. Make Use of Discovered Encrypted DNS Servers . . . . 32 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 108 1. Introduction 110 This document focuses on the support of encrypted DNS such as DNS- 111 over-HTTPS (DoH) [RFC8484], DNS-over-TLS (DoT) [RFC7858], or DNS- 112 over-QUIC (DoQ) [I-D.ietf-dprive-dnsoquic] in local networks. 114 In particular, the document specifies how a local encrypted DNS 115 server can be discovered and used by connected hosts by means of DHCP 116 [RFC2132], DHCPv6 [RFC8415], and IPv6 Router Advertisement (RA) 117 [RFC4861] options. These options are designed to convey the 118 following information: the DNS Authentication Domain Name (ADN), a 119 list of IP addresses, and optionally a port number. The discovery of 120 DoH URI Templates is discussed in Section 7. 122 Sample target deployment scenarios are discussed in Appendix A; both 123 managed and unmanaged Customer Premises Equipment (CPEs) are covered. 124 It is out of the scope of this document to provide an exhaustive 125 inventory of deployments where Encrypted DNS Options (Sections 4, 5, 126 and 6) can be used. 128 Considerations related to hosting a DNS forwarder in a local network 129 are described in Section 8. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 This document makes use of the terms defined in [RFC8499]. The 140 following additional terms are used: 142 Do53: refers to unencrypted DNS. 144 Encrypted DNS: refers to a scheme where DNS exchanges are 145 transported over an encrypted channel. Examples of encrypted DNS 146 are DNS-over-TLS (DoT) [RFC7858], DNS-over-HTTPS (DoH) [RFC8484], 147 or DNS-over-QUIC (DoQ) [I-D.ietf-dprive-dnsoquic]. 149 Managed CPE: refers to a CPE that is managed by an Internet Service 150 Providers (ISP). 152 Unmanaged CPE: refers to a CPE that is not managed by an ISP. 154 DHCP: refers to both DHCPv4 and DHCPv6. 156 3. Overview and Rationale 158 This document describes how a DNS client can discover a local 159 encrypted DNS server(s) using DHCP (Sections 4 and 5) and Neighbor 160 Discovery protocol (Section 6). 162 As reported in Section 1.7.2 of [RFC6125]: 164 | Some certification authorities issue server certificates based on 165 | IP addresses, but preliminary evidence indicates that such 166 | certificates are a very small percentage (less than 1%) of issued 167 | certificates. 169 In order to allow for PKIX-based authentication between a DNS client 170 and an encrypted DNS server while accommodating the current best 171 practices for issuing certificates, this document allows for 172 configuring an authentication domain name to be presented as a 173 reference identifier for DNS authentication purposes. 175 To avoid adding a dependency on another server to resolve the ADN, 176 the options return a list of IP addresses to locate the encrypted DNS 177 server. In the various scenarios sketched in Appendix A, encrypted 178 DNS servers may terminate on the same IP address or distinct IP 179 addresses. Terminating encrypted DNS servers on the same or distinct 180 IP addresses is deployment specific. It is RECOMMENDED to return 181 both the ADN and a list of IP addresses to a requesting host. 183 Note that in order to optimize the size of discovery messages when 184 all servers terminate on the same IP address, a host may rely upon 185 the discovery mechanisms specified in [RFC2132][RFC3646][RFC8106] to 186 retrieve a list of IP addresses to reach their DNS servers. 187 Nevertheless, this approach requires a client that supports more than 188 one encrypted DNS to probe that list of IP addresses. To avoid such 189 probing, the options defined in the following sections associate an 190 IP address with an encrypted DNS type. No probing is required in 191 such design. 193 A list of IP addresses to reach an encrypted DNS server can be 194 returned in the option to accommodate current deployments relying 195 upon primary and backup servers. Whether one IP address or more are 196 returned in an option is deployment specific. For example, a router 197 embedding a recursive server or forwarder has to include one single 198 IP address pointing to one of its LAN-facing interfaces. This 199 address can be a private IPv4 address, a link-local address, a Unique 200 Local IPv6 unicast Address (ULA), or a Global Unicast Address (GUA). 202 If more than one IP address are to be returned in an Encrypted DNS 203 server option, these addresses are ordered in the preference for use 204 by the client. 206 Because DoT and DoQ may make use of customized port numbers instead 207 of default ones, the Encrypted DNS server options are designed to 208 return alternate port numbers. 210 Some ISPs rely upon external resolvers (e.g., outsourced service or 211 public resolvers); these ISPs provide their customers with the IP 212 addresses of these resolvers. These addresses are typically 213 configured on CPEs using dedicated management tools. Likewise, users 214 can modify the default DNS configuration of their CPEs (e.g., 215 supplied by their ISP) to configure their favorite DNS servers. This 216 document permits such deployments. 218 If the encrypted DNS is discovered by a host using both RA and DHCP, 219 the rules discussed in Section 5.3.1 of [RFC8106] MUST be followed. 221 The DNS client establishes an encrypted DNS session with the 222 discovered DNS IP address(es) and port number, and uses the mechanism 223 discussed in Section 8 of [RFC8310] to authenticate the DNS server 224 certificate using the authentication domain name conveyed in the 225 encrypted DNS options. 227 Devices may be connected to multiple networks; each providing their 228 own DNS configuration using the discovery mechanisms specified in 229 this document. Nevertheless, it is out of the scope of this 230 specification to discuss DNS selection of multi-interface devices. 231 The reader may refer to [RFC6731] for a discussion of issues and an 232 example of DNS server selection for multi-interfaced devices. 234 DHCP/RA options to discover encrypted DNS servers (including, DoH URI 235 Templates should the WG pursue that approach pending feedback) takes 236 precedence over DEER [I-D.pauly-add-deer] since DEER uses unencrypted 237 DNS to an external DNS resolver, which is susceptible to both 238 internal and external attacks whereas DHCP/RA is only vulnerable to 239 internal attacks. 241 4. DHCPv6 Encrypted DNS Options 243 This section defines two DHCPv6 options: DHCPv6 Encrypted DNS ADN 244 option (Section 4.1) and DHCPv6 Encrypted DNS Address option 245 (Section 4.2). 247 4.1. Encrypted DNS ADN Option 249 The DHCPv6 Encrypted DNS ADN option is used to configure an 250 authentication domain name of the encrypted DNS server. The format 251 of this option is shown in Figure 1. 253 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | OPTION_V6_DNR_ADN | Option-length | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Enc DNS Flags | | 258 +---------------+ + 259 | | 260 ~ authentication-domain-name ~ 261 | | 262 +---------------------------------------------------------------+ 264 Figure 1: DHCPv6 Encrypted DNS ADN Option 266 The fields of the option shown in Figure 1 are as follows: 268 Option-code: OPTION_V6_DNR_ADN (TBA1, see Section 11.2) 270 Option-length: Length of the enclosed data in octets. 272 Enc DNS Flags (Encrypted DNS Flags): Indicates the type(s) of the 273 encrypted DNS server conveyed in this attribute. The format of 274 this 8-bit field is shown in Figure 2. 276 +-+-+-+-+-+-+-+-+ 277 |U|U|U|U|U|Q|H|T| 278 +-+-+-+-+-+-+-+-+ 280 Figure 2: Encrypted DNS Flags Field 282 T: If set, this bit indicates that the server supports DoT 283 [RFC7858]. 285 H: If set, this bit indicates that the server supports DoH 286 [RFC8484]. 288 Q: If set, this bit indicates that the server supports DoQ 289 [I-D.ietf-dprive-dnsoquic]. 291 U: Unassigned bits. These bits MUST be unset by the sender. 292 Associating a meaning with an unassigned bit can be done as per 293 Section 11.1. 295 In a request, these bits are assigned to indicate the requested 296 encrypted DNS server type(s) by the client. In a response, these 297 bits are set as a function of the encrypted DNS supported by the 298 server and the requested encrypted DNS server type(s). 300 To keep the packet small, if more than one encrypted DNS type 301 (e.g., both DoH and DoT) are to be returned to a requesting client 302 and the same ADN is used for these types, the corresponding bits 303 must be set in the 'Encrypted DNS Types' field of the same option 304 instance in a response. For example, if the client requested DoH 305 and DoT and the server supports both with the same ADN, then both 306 T and H bits must be set. 308 authentication-domain-name: A fully qualified domain name of the 309 encrypted DNS server. This field is formatted as specified in 310 Section 10 of [RFC8415]. 312 An example of the authentication-domain-name encoding is shown in 313 Figure 3. This example conveys the FQDN "doh1.example.com.", and 314 the resulting Option-length field is 18. 316 +------+------+------+------+------+------+------+------+------+ 317 | 0x04 | d | o | h | 1 | 0x07 | e | x | a | 318 +------+------+------+------+------+------+------+------+------+ 319 | m | p | l | e | 0x03 | c | o | m | 0x00 | 320 +------+------+------+------+------+------+------+------+------+ 322 Figure 3: An Example of the DNS authentication-domain-name Encoding 324 4.2. Encrypted DNS Address Option 326 The DHCPv6 Encrypted DNS Address option is used to configure a list 327 of IP addresses and a port number of the encrypted DNS server. The 328 format of this option is shown in Figure 4. 330 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | OPTION_V6_DNR_ADD | Option-length | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Enc DNS Flags | Unassigned | Port Number | 335 +---------------+---------------+-------------------------------+ 336 | | 337 | ipv6-address | 338 | | 339 | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | | 342 | ipv6-address | 343 | | 344 | | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | ... | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Figure 4: DHCPv6 Encrypted DNS Address Option 351 The fields of the option shown in Figure 4 are as follows: 353 Option-code: OPTION_V6_DNR_ADD (TBA2, see Section 11.2) 355 Option-length: Length of the enclosed data in octets. 357 Enc DNS Flags (Encrypted DNS Flags): Indicates the type(s) of the 358 encrypted DNS server conveyed in this attribute. The format of 359 this 8-bit field is shown in Figure 2. In a request, these bits 360 are set to indicate the requested encrypted DNS server type(s) by 361 the client. In a response, these bits are set as a function of 362 the encrypted DNS supported by the server and the requested 363 encrypted DNS server type(s). 365 Unassigned: These bits MUST be unset by the sender. Associating a 366 meaning with an unassigned bit can be done via Standards Action 367 [RFC8126]. 369 Port Number: If not null, it indicates the port number to be used 370 for the encrypted DNS. If this field is set to zero, this 371 indicates that default port numbers should be used. As a 372 reminder, the default port number is 853 for DoT and 443 for DoH. 374 ipv6-address(es): Indicates one or more IPv6 addresses to reach the 375 encrypted DNS server. An address can be link-local, ULA, or GUA. 377 Multiple instances of OPTION_V6_DNR_ADN (or OPTION_V6_DNR_ADD) may be 378 returned to a DHCPv6 client; each pointing to a distinct encrypted 379 DNS server type. 381 If more than one encrypted DNS server types is supported on the same 382 IP address and default port numbers are used, one instance of 383 OPTION_V6_DNR_ADD option with the appropriate bits set in "Encr DNS 384 Types" field should be returned by the DHCP server. 386 4.3. DHCPv6 Client Behavior 388 To discover an encrypted DNS server, the DHCPv6 client MUST include 389 OPTION_V6_DNR_ADN and OPTION_V6_DNR_ADD in an Option Request Option 390 (ORO), as in Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 391 21.7 of [RFC8415]. The DHCPv6 client sets the Encrypted DNS Types 392 field to the requested encrypted DNS server type(s). 394 If the DHCPv6 client requested more than one encrypted DNS server 395 type, the DHCP client MUST be prepared to receive multiple 396 OPTION_V6_DNR_ADN (or OPTION_V6_DNR_ADD) options; each option is to 397 be treated as a separate encrypted DNS server. 399 The DHCPv6 client MUST silently discard multicast and host loopback 400 addresses conveyed in OPTION_V6_DNR_ADD. 402 5. DHCPv4 Encrypted DNS Option 404 5.1. Encrypted DNS Option 406 The DHCPv4 Encrypted DNS option is used to configure an 407 authentication domain name, a list of IP addresses, and a port number 408 of the encrypted DNS server. The format of this option is 409 illustrated in Figure 5. 411 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | TBA3 | Length | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Enc DNS Flags | Num Addresses | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Port Number | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | | 420 ~ IPv4 Address(es) ~ 421 | | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | | 424 ~ authentication-domain-name ~ 425 | | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Figure 5: DHCPv4 Encrypted DNS Option 430 The fields of the option shown in Figure 5 are as follows: 432 Code: OPTION_V4_DNR_DNS (TBA3, see Section 11.3). 434 Length: Length of the enclosed data in octets. 436 Enc DNS Flags (Encrypted DNS Flags): Indicates the type(s) of the 437 encrypted DNS server conveyed in this attribute. The format of 438 this field is shown in Figure 2. 440 Num Addresses: Indicates the number of included IPv4 addresses. 442 Port Number: If not null, it indicates the port number to be used 443 for the encrypted DNS. A null value indicates that default port 444 numbers are used. As a reminder, the default port number is 853 445 for DoT and 443 for DoH. 447 IPv4 Address(es): Indicates one or more IPv4 addresses to reach the 448 encrypted DNS server. Both private and public IPv4 addresses can 449 be included in this field. The format of this field is shown in 450 Figure 6. This format assumes that an IPv4 address is encoded as 451 a1.a2.a3.a4. 453 0 8 16 24 32 40 48 454 +-----+-----+-----+-----+-----+-----+-- 455 | a1 | a2 | a3 | a4 | a1 | a2 | ... 456 +-----+-----+-----+-----+-----+-----+-- 457 IPv4 Address 1 IPv4 Address 2 ... 459 Figure 6: Format of the IPv4 Addresses Field 461 authentication-domain-name: The domain name of the encrypted DNS 462 server. This field is formatted as specified in Section 10 of 463 [RFC8415]. The format of this field is shown in Figure 7. The 464 values s1, s2, s3, etc. represent the domain name labels in the 465 domain name encoding. 467 +-----+-----+-----+-----+-----+-- 468 | s1 | s2 | s3 | s4 | s5 | ... 469 +-----+-----+-----+-----+-----+-- 470 authentication-domain-name 472 Figure 7: Format of the Authentication Domain Name Field 474 OPTION_V4_DNR_DNS is a concatenation-requiring option. As such, the 475 mechanism specified in [RFC3396] MUST be used if OPTION_V4_DNR_DNS 476 exceeds the maximum DHCPv4 option size of 255 octets. 478 5.2. DHCPv4 Client Behavior 480 To discover an encrypted DNS server, the DHCPv4 client requests the 481 Encrypted DNS server by including OPTION_V4_DNR_DNS in a Parameter 482 Request List option [RFC2132]. The DHCPv4 client sets the Encrypted 483 DNS Types field to the requested encrypted DNS server. 485 If the DHCPv4 client requested more than one encrypted DNS server 486 type, the DHCPv4 client MUST be prepared to receive multiple DHCP 487 OPTION_V4_DNR_DNS options; each option is to be treated as a separate 488 encrypted DNS server. 490 The DHCPv4 client MUST silently discard multicast and host loopback 491 addresses conveyed in OPTION_V4_DNR_DNS. 493 6. IPv6 RA Encrypted DNS Options 495 This section defines two Neighbor Discovery [RFC4861]: IPv6 Router 496 Advertisement (RA) Encrypted DNS ADN option (Section 6.1) and IPv6 RA 497 Encrypted DNS Address option (Section 6.2). These options are useful 498 in contexts similar to those discussed in Section 1.1 of [RFC8106]. 500 6.1. Encrypted DNS ADN Option 502 The IPv6 RA Encrypted DNS ADN option is used to configure an 503 authentication domain name of the encrypted DNS server. The format 504 of this option is illustrated in Figure 8. 506 0 1 2 3 507 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | TBA4 | Length | Enc DNS Flags | Unassigned | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Lifetime | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | | 514 ~ authentication-domain-name ~ 515 | | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 Figure 8: RA Encrypted DNS ADN Option 520 The fields of the option shown in Figure 8 are as follows: 522 Type: 8-bit identifier of the Encrypted DNS Option as assigned by 523 IANA (TBA4, see Section 11.4). 525 Length: 8-bit unsigned integer. The length of the option (including 526 the Type and Length fields) is in units of 8 octets. 528 Enc DNS Flags (Encrypted DNS Flags): Indicates the type(s) of the 529 encrypted DNS server conveyed in this attribute. The format of 530 this field is shown in Figure 2. 532 Unassigned: This field is unused. It MUST be initialized to zero by 533 the sender and MUST be ignored by the receiver. 535 Lifetime: 32-bit unsigned integer. The maximum time in seconds 536 (relative to the time the packet is received) over which the 537 discovered Authentication Domain Name is valid. 539 The value of Lifetime SHOULD by default be at least 3 * 540 MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA 541 interval as defined in [RFC4861]. 543 A value of all one bits (0xffffffff) represents infinity. 545 A value of zero means that this Authentication Domain Name MUST no 546 longer be used. 548 authentication Domain Name: The domain name of the encrypted DNS 549 server. This field is formatted as specified in Section 10 of 550 [RFC8415]. 552 This field MUST be padded with zeros so that its size is a 553 multiple of 8 octets. 555 6.2. Encrypted DNS Address Option 557 The IPv6 RA Encrypted DNS Address option is used to configure a port 558 number and a list of IPv6 addresses of the encrypted DNS server. The 559 format of this option is illustrated in Figure 9. All of the 560 addresses share the same Lifetime value. Similar to [RFC8106], if it 561 is desirable to have different Lifetime values per IP address, 562 multiple Encrypted DNS Address options may be used. 564 0 1 2 3 565 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | TBA5 | Length | Unassigned | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Lifetime | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Enc DNS Flags | Unassigned | Port Number | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | | 574 | ipv6-address | 575 | | 576 | | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | | 579 | ipv6-address | 580 | | 581 | | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | ... | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Figure 9: RA Encrypted DNS Address Option 588 The fields of the RA Encrypted DNS Address option shown in Figure 9 589 are as follows: 591 Type: 8-bit identifier of the Encrypted DNS Address Option as 592 assigned by IANA (TBA5, see Section 11.4). 594 Length: 8-bit unsigned integer. The length of the option (including 595 the Type and Length fields) is in units of 8 octets. 597 Unassigned: This field is unused. It MUST be initialized to zero by 598 the sender and MUST be ignored by the receiver. 600 Lifetime: 32-bit unsigned integer. The maximum time in seconds 601 (relative to the time the packet is received) over which the 602 discovered encrypted DNS IPv6 addresses are valid. 604 The value of Lifetime SHOULD by default be at least 3 * 605 MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA 606 interval as defined in [RFC4861]. 608 A value of all one bits (0xffffffff) represents infinity. 610 A value of zero means that these IPv6 addresses MUST no longer be 611 used. 613 Enc DNS Flags (Encrypted DNS Flags): Indicates the type(s) of the 614 encrypted DNS server conveyed in this attribute. The format of 615 this field is shown in Figure 2. 617 Port Number: If not null, it indicates the port number to be used 618 for the encrypted DNS. A null value indicates that default port 619 numbers must be used. As a reminder, the default port number is 620 853 for DoT and 443 for DoH. 622 ipv6-address(es): One or more IPv6 addresses of the encrypted DNS 623 server. An address can be link-local, ULA, or GUA. 625 7. DoH URI Templates 627 DoH servers may support more than one URI Template [RFC8484]. Also, 628 if the resolver hosts several DoH services (e.g., no-filtering, 629 blocking adult content, blocking malware), these services can be 630 discovered as templates. The following discusses a mechanism for a 631 DoH client to retrieve the list of supported templates by a DoH 632 server. 634 Upon discovery of a DoH resolver (Sections 4, 5, and 6), the DoH 635 client may contact that DoH resolver to retrieve the list of 636 supported DoH services using DEER [I-D.pauly-add-deer]. This will 637 allow the client to discover the resolver's supported DoH templates 638 or DoH resolvers that the discovered resolver designates using DNS 639 SVCB queries [I-D.schwartz-svcb-dns]. The designated DoH resolvers 640 and DoH resolver discovered using DHCP/RA may be hosted on the same 641 or distinct IP addresses. 643 Let's suppose that a host has discovered an encrypted DNS server that 644 is DoH-capable. The host has also discovered the following 645 information: 647 o ADN: doh.example.com 649 o Locator: 2001:db8:1::1 651 The client will use DEER [I-D.pauly-add-deer] to discover the DoH 652 templates supported by the DNS server at the Locator (2001:db8:1::1). 653 In addition to the checks included in DEER, clients should verify the 654 ADN (doh.example.com) is valid for the certificate provided by the 655 DoH resolver. However, the IP address of the DEER-discovered 656 resolver may differ from the Locator field value. This will allow 657 the ISP to offer different DoH services to the endpoints attached to 658 local networks. 660 Alternatively, dedicated DHCP/RA options may be defined to convey an 661 URI template in order to avoid additional network traffic to 662 bootstrap DoH configuration. An example of the format of such an 663 option is depicted in Figure 10. 665 0 1 2 3 666 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | OPTION_V6_DOH_TEMPLATE | Option-length | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | | 671 ~ uri-template-data ~ 672 | . . . | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 Each instance of the uri-template-data is formatted as follows: 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 678 | uri-template-len | URI Template | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 681 Figure 10: Example of a DHCPv6 URI Template Option 683 Note: More feedback from the WG is needed to decide which 684 approach(es) to follow. 686 How a DoH client makes use of the configured DoH services is out of 687 the scope of this document. 689 8. Hosting Encrypted DNS Forwarder in Local Networks 691 This section discusses some deployment considerations (not 692 recommendations) to host an encrypted DNS forwarder within a local 693 network. 695 8.1. Managed CPEs 697 The section discusses mechanisms that can be used to host an 698 encrypted DNS forwarder in a managed CPE (Appendix A.1). 700 8.1.1. DNS Forwarders 702 The managed CPE should support a configuration parameter to instruct 703 the CPE whether it has to relay the encrypted DNS server received 704 from the ISP's network or has to announce itself as a forwarder 705 within the local network. The default behavior of the CPE is to 706 supply the encrypted DNS server received from the ISP's network. 708 8.1.2. ACME 710 The ISP can assign a unique FQDN (e.g., "cpe1.example.com") and a 711 domain-validated public certificate to the encrypted DNS forwarder 712 hosted on the CPE. Automatic Certificate Management Environment 713 (ACME) [RFC8555] can be used by the ISP to automate certificate 714 management functions such as domain validation procedure, certificate 715 issuance and certificate revocation. 717 8.1.3. Auto-Upgrade Based on Domains and their Subdomains 719 If the ADN conveyed in DHCP/RA (Sections 4, 5, and 6) is 720 preconfigured in popular OSes or browsers as a verified resolver and 721 the auto-upgrade (Appendix B) is allowed for both the preconfigured 722 ADN and its sub-domains, the encrypted DNS client will learn the 723 local encrypted DNS forwarder using DHCP/RA and auto-upgrade because 724 the preconfigured ADN would match the subjectAltName value in the 725 server certificate. For example, if the preconfigured ADN is 726 "*.example.com" and the discovered encrypted DNS forwarder is 727 "cpe1.example.com", auto-upgrade will take place. 729 In this case, the CPE can communicate the ADN of the local DoH 730 forwarder (Section 8.1.2) to internal hosts using DHCP/RA (Sections 731 4, 5, and 6). 733 Let's suppose that "*.example.net" is preconfigured as a verified 734 resolved in the browser or OS. If the encrypted DNS client discovers 735 a local forwarder "cpe1-internal.example.net", the encrypted DNS 736 client will auto-upgrade because the preconfigured ADN would match 737 subjectAltName value "cpe1-internal.example.net" of type dNSName. As 738 shown in Figure 11, the auto-upgrade to a rogue server advertising 739 "rs.example.org" will fail because it does not match "*.example.net". 741 Encrypted DNS CPE 742 capable client (@i) 743 | | 744 |<=================DHCP===============| 745 | {ADN=cpe1-internal.example.net, @i} | 746 | | 747 | Rogue Server | 748 | (@rs) | 749 | | | 750 X<===========DHCP=========| | 751 |{ADN=rs.example.org, @rs}| | 752 | | | 753 | | 754 |<=================DoH===============>| 755 | | 757 Legend: 758 * @i: internal IP address of the CPE 759 * @rs: IP address of a rogue server 761 Figure 11: A Simplified Example of Auto-upgrade based on Subdomains 763 8.2. Unmanaged CPEs 765 The approach specified in Section 8.1 does not apply for hosting a 766 DNS forwarder in an unmanaged CPE. 768 The unmanaged CPE administrator (referred to as administrator) can 769 host an encrypted DNS forwarder on the unmanaged CPE. This assumes 770 the following: 772 o The encrypted DNS server certificate is managed by the entity in- 773 charge of hosting the encrypted DNS forwarder. 775 Alternatively, a security service provider can assign a unique 776 FQDN to the CPE. The encrypted DNS forwarder will act like a 777 private encrypted DNS server only be accessible from within the 778 the local network. 780 o The encrypted DNS forwarder will either be configured to use the 781 ISP's or a 3rd party encrypted DNS server. 783 o The unmanaged CPE will advertise the encrypted DNS forwarder ADN 784 using DHCP/RA to internal hosts. 786 Figure 12 illustrates an example of an unmanaged CPE hosting a 787 forwarder which connects to a 3rd party encrypted DNS server. In 788 this example, the DNS information received from the managed CPE (and 789 therefore from the ISP) is ignored by the Internal CPE hosting the 790 forwarder. 792 ,--,--,--. ,--, 793 ,' Internal Managed ,-' '- 3rd Party 794 Host--( Network#A CPE--------CPE------( ISP )--- DNS Server 795 | `. ,-'| | `-. -' | 796 | `-'--'--' | |<==DHCP==>|`--' | 797 | |<==DHCP==>| | | 798 |<======DHCP=======>| | | 799 | {RI, @i} | | 800 |<==Encrypted DNS==>|<==========Encrypted DNS==========>| 802 Legend: 803 * @i: IP address of the DNS forwarder hosted in the Internal 804 CPE. 806 Figure 12: Example of an Internal CPE Hosting a Forwarder 808 9. Legacy CPEs 810 Hosts serviced by legacy CPEs that can't be upgraded to support the 811 options defined in Sections 4, 5, and 6 won't be able to learn the 812 encrypted DNS server hosted by the ISP, in particular. If the ADN is 813 not discovered using DHCP/RA, such hosts will have to fallback to use 814 DEER as defined in [I-D.pauly-add-deer] to discover the encrypted DNS 815 server and to retrieve the list of supported DoH services using the 816 SVCB RRtype [I-D.schwartz-svcb-dns] without verifying the hostname of 817 discovered templates with the ADN. Other guidance in DEER relating 818 to resolver verification must be followed in this case. This will 819 prevent an unencrypted resolver on a local address from referring to 820 an encrypted resolver at a different address without an out-of-band 821 configuration in the client beyond the scope of this document or 822 DEER. 824 10. Security Considerations 826 10.1. Spoofing Attacks 828 DHCP/RA messages are not encrypted or protected against modification 829 within the LAN. Unless mitigated (described below), the content of 830 DHCP and RA messages can be spoofed or modified by active attackers, 831 such as compromised devices within the local network. An active 832 attacker (Section 3.3 of [RFC3552]) can spoof the DHCP/RA response to 833 provide the attacker's Encrypted DNS server. Note that such an 834 attacker can launch other attacks as discussed in Section 22 of 835 [RFC8415]. The attacker can get a domain name with a domain- 836 validated public certificate from a CA and host an Encrypted DNS 837 server. Also, an attacker can use a public IP address and get an 'IP 838 address'-validated public certificate from a CA to host an Encrypted 839 DNS server. 841 Attacks of spoofed or modified DHCP responses and RA messages by 842 attackers within the local network may be mitigated by making use of 843 the following mechanisms: 845 o DHCPv6-Shield described in [RFC7610], the CPEs discards DHCP 846 response messages received from any local endpoint. 848 o RA-Guard described in [RFC7113], the CPE discards RAs messages 849 received from any local endpoint. 851 o Source Address Validation Improvement (SAVI) solution for DHCP 852 described in [RFC7513], the CPE filters packets with forged source 853 IP addresses. 855 Encrypted DNS sessions with rogue servers that spoof the IP address 856 of a DNS server will fail because the DNS client will fail to 857 authenticate that rogue server based upon PKIX authentication 858 [RFC6125], particularly the authentication domain name in the 859 Encrypted DNS Option. DNS clients that ignore authentication 860 failures and accept spoofed certificates will be subject to attacks 861 (e.g., redirect to malicious servers, intercept sensitive data). 863 Encrypted DNS connections received from outside the local network 864 MUST be discarded by the encrypted DNS forwarder in the CPE. This 865 behavior adheres to REQ#8 in [RFC6092]; it MUST apply for both IPv4 866 and IPv6. 868 10.2. Deletion Attacks 870 If the DHCP responses or RAs are dropped by the attacker, the client 871 can fallback to use a preconfigured encrypted DNS server. However, 872 the use of policies to select servers is out of the scope of this 873 document. 875 Note that deletion attack is not specific to DHCP/RA. 877 10.3. Passive Attacks 879 A passive attacker (Section 3.2 of [RFC3552]) can identify a host is 880 using DHCP/RA to discover an encrypted DNS server and can infer that 881 host is capable of using DoH/DoT/DoQ to encrypt DNS messages. 882 However, a passive attacker cannot spoof or modify DHCP/RA messages. 884 10.4. Wireless Security - Authentication Attacks 886 Wireless LAN (WLAN) as frequently deployed in local networks (e.g., 887 home networks) is vulnerable to various attacks (e.g., [Evil-Twin], 888 [Krack], [Dragonblood]). Because of these attacks, only 889 cryptographically authenticated communications are trusted on WLANs. 890 This means information provided by such networks via DHCP, DHCPv6, or 891 RA (e.g., NTP server, DNS server, default domain) are untrusted 892 because DHCP and RA are not authenticated. 894 If the pre-shared-key is the same for all clients that connect to the 895 same WLAN, the shared key will be available to all nodes, including 896 attackers, so it is possible to mount an active on-path attack. Man- 897 in-the-middle attacks are possible within local networks because such 898 WLAN authentication lacks peer entity authentication. 900 This leads to the need for provisioning unique credentials for 901 different clients. Endpoints can be provisioned with unique 902 credentials (username and password, typically) provided by the local 903 network administrator to mutually authenticate to the local WLAN 904 Access Point (e.g., 802.1x Wireless User Authentication on OpenWRT 905 [dot1x], EAP-pwd [RFC8146]). Not all of endpoint devices (e.g., IoT 906 devices) support 802.1x supplicant and need an alternate mechanism to 907 connect to the local network. To address this limitation, unique 908 pre-shared keys can be created for each such device and WPA-PSK is 909 used (e.g., [PSK]). 911 11. IANA Considerations 913 11.1. Encrypted DNS Flag Bits 915 1 2 3 4 5 6 7 8 916 +-+-+-+-+-+-+-+-+ 917 Encrypted DNS Types is a set of 8 flags: |U|U|U|U|U|Q|H|T| 918 +-+-+-+-+-+-+-+-+ 920 where flag bits in positions 1-5 are for future assignment as 921 additional flag bits. 923 This document requests IANA to create a new registry called 924 "Encrypted DNS Types". The initial values of the registry are as 925 follows: 927 +--------------+-------+---------------------+----------------+ 928 | Bit Position | Label | Description | Reference | 929 +--------------+-------+---------------------+----------------+ 930 | 1 | U | Unassigned | | 931 | 2 | U | Unassigned | | 932 | 3 | U | Unassigned | | 933 | 4 | U | Unassigned | | 934 | 5 | U | Unassigned | | 935 | 6 | Q | DNS-over-QUIC (DoQ) | [ThisDocument] | 936 | 7 | H | DNS-over-HTTP (DoH) | [ThisDocument] | 937 | 8 | T | DNS-over-TLS (DoT) | [ThisDocument] | 938 +--------------+-------+---------------------+----------------+ 940 New flag bits are assigned via Standards Action [RFC8126]. 942 11.2. DHCPv6 Options 944 IANA is requested to assign the following new DHCPv6 Option Code in 945 the registry maintained in [DHCPV6]. 947 +-------+-------------------+---------+------------+----------------+ 948 | Value | Description | Client | Singleton | Reference | 949 | | | ORO | Option | | 950 +-------+-------------------+---------+------------+----------------+ 951 | TBA1 | OPTION_V6_DNR_ADN | Yes | No | [ThisDocument] | 952 | TBA2 | OPTION_V6_DNR_ADD | Yes | No | [ThisDocument] | 953 +-------+-------------------+---------+------------+----------------+ 955 11.3. DHCPv4 Option 957 IANA is requested to assign the following new DHCP Option Code in the 958 registry maintained in [BOOTP]. 960 +------+------------------+-------+----------------+----------------+ 961 | Tag | Name | Data | Meaning | Reference | 962 | | | Length| | | 963 +------+------------------+-------+----------------+----------------+ 964 | TBA3 | OPTION_V4_DNR_DNS| N | Encrypted DNS | [ThisDocument] | 965 | | | | Server | | 966 +------+------------------+-------+----------------+----------------+ 968 11.4. Neighbor Discovery Options 970 IANA is requested to assign the following new IPv6 Neighbor Discovery 971 Option type in the "IPv6 Neighbor Discovery Option Formats" sub- 972 registry under the "Internet Control Message Protocol version 6 973 (ICMPv6) Parameters" registry maintained in [ND]. 975 +------+----------------------------------+----------------+ 976 | Type | Description | Reference | 977 +------+----------------------------------+----------------+ 978 | TBA4 | DNS Encrypted DNS ADN Option | [ThisDocument] | 979 | TBA5 | DNS Encrypted DNS Address Option | [ThisDocument] | 980 +------+----------------------------------+----------------+ 982 12. Acknowledgements 984 Many thanks to Christian Jacquenet and Michael Richardson for the 985 review. 987 Thanks to Stephen Farrell, Martin Thomson, Vittorio Bertola, Stephane 988 Bortzmeyer, Ben Schwartz, and Iain Sharp for the comments. 990 Thanks to Mark Nottingham for the feedback on HTTP redirection. 992 The use of DHCP to retrieve an authentication domain name was 993 discussed in Section 7.3.1 of [RFC8310] and 994 [I-D.pusateri-dhc-dns-driu]. 996 13. Contributing Authors 998 Nicolai Leymann 999 Deutsche Telekom 1000 Germany 1002 Email: n.leymann@telekom.de 1004 Zhiwei Yan 1005 CNNIC 1006 No.4 South 4th Street, Zhongguancun 1007 Beijing 100190 1008 China 1010 EMail: yan@cnnic.cn 1012 14. References 1014 14.1. Normative References 1016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1017 Requirement Levels", BCP 14, RFC 2119, 1018 DOI 10.17487/RFC2119, March 1997, 1019 . 1021 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1022 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 1023 . 1025 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 1026 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 1027 DOI 10.17487/RFC3396, November 2002, 1028 . 1030 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1031 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1032 DOI 10.17487/RFC4861, September 2007, 1033 . 1035 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1036 "IPv6 Router Advertisement Options for DNS Configuration", 1037 RFC 8106, DOI 10.17487/RFC8106, March 2017, 1038 . 1040 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1041 Writing an IANA Considerations Section in RFCs", BCP 26, 1042 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1043 . 1045 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1046 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1047 May 2017, . 1049 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1050 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1051 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1052 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1053 . 1055 14.2. Informative References 1057 [Auto-upgrade] 1058 The Unicode Consortium, "DoH providers: criteria, process 1059 for Chrome", . 1062 [BOOTP] "BOOTP Vendor Extensions and DHCP Options", 1063 . 1066 [DHCPV6] "DHCPv6 Option Codes", . 1070 [dot1x] Cisco, "Basic 802.1x Wireless User Authentication", 1071 . 1074 [Dragonblood] 1075 The Unicode Consortium, "Dragonblood: Analyzing the 1076 Dragonfly Handshake of WPA3 and EAP-pwd", 1077 . 1079 [Evil-Twin] 1080 The Unicode Consortium, "Evil twin (wireless networks)", 1081 . 1084 [I-D.ietf-dprive-dnsoquic] 1085 Huitema, C., Mankin, A., and S. Dickinson, "Specification 1086 of DNS over Dedicated QUIC Connections", draft-ietf- 1087 dprive-dnsoquic-01 (work in progress), October 2020. 1089 [I-D.ietf-v6ops-rfc7084-bis] 1090 Palet, J., "Basic Requirements for IPv6 Customer Edge 1091 Routers", draft-ietf-v6ops-rfc7084-bis-04 (work in 1092 progress), June 2017. 1094 [I-D.pauly-add-deer] 1095 Pauly, T., Kinnear, E., Wood, C., McManus, P., and T. 1096 Jensen, "Discovery of Equivalent Encrypted Resolvers", 1097 draft-pauly-add-deer-00 (work in progress), November 2020. 1099 [I-D.pusateri-dhc-dns-driu] 1100 Pusateri, T. and W. Toorop, "DHCPv6 Options for private 1101 DNS Discovery", draft-pusateri-dhc-dns-driu-00 (work in 1102 progress), July 2018. 1104 [I-D.schwartz-svcb-dns] 1105 Schwartz, B., "Service Binding Mapping for DNS Servers", 1106 draft-schwartz-svcb-dns-01 (work in progress), August 1107 2020. 1109 [Krack] The Unicode Consortium, "Key Reinstallation Attacks", 1110 2017, . 1112 [ND] "IPv6 Neighbor Discovery Option Formats", 1113 . 1116 [PSK] Cisco, "Identity PSK Feature Deployment Guide", 1117 . 1121 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1122 Text on Security Considerations", BCP 72, RFC 3552, 1123 DOI 10.17487/RFC3552, July 2003, 1124 . 1126 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 1127 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1128 DOI 10.17487/RFC3646, December 2003, 1129 . 1131 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1132 Capabilities in Customer Premises Equipment (CPE) for 1133 Providing Residential IPv6 Internet Service", RFC 6092, 1134 DOI 10.17487/RFC6092, January 2011, 1135 . 1137 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1138 Verification of Domain-Based Application Service Identity 1139 within Internet Public Key Infrastructure Using X.509 1140 (PKIX) Certificates in the Context of Transport Layer 1141 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1142 2011, . 1144 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 1145 Recursive DNS Server Selection for Multi-Interfaced 1146 Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, 1147 . 1149 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 1150 Advertisement Guard (RA-Guard)", RFC 7113, 1151 DOI 10.17487/RFC7113, February 2014, 1152 . 1154 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 1155 Validation Improvement (SAVI) Solution for DHCP", 1156 RFC 7513, DOI 10.17487/RFC7513, May 2015, 1157 . 1159 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 1160 Protecting against Rogue DHCPv6 Servers", BCP 199, 1161 RFC 7610, DOI 10.17487/RFC7610, August 2015, 1162 . 1164 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1165 and P. Hoffman, "Specification for DNS over Transport 1166 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1167 2016, . 1169 [RFC8146] Harkins, D., "Adding Support for Salted Password Databases 1170 to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017, 1171 . 1173 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1174 for DNS over TLS and DNS over DTLS", RFC 8310, 1175 DOI 10.17487/RFC8310, March 2018, 1176 . 1178 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1179 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1180 . 1182 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1183 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1184 January 2019, . 1186 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 1187 Description Specification", RFC 8520, 1188 DOI 10.17487/RFC8520, March 2019, 1189 . 1191 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1192 Kasten, "Automatic Certificate Management Environment 1193 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 1194 . 1196 [TR-069] The Broadband Forum, "CPE WAN Management Protocol", 1197 December 2018, . 1200 [TS.24008] 1201 3GPP, "Mobile radio interface Layer 3 specification; Core 1202 network protocols; Stage 3 (Release 16)", December 2019, 1203 . 1205 Appendix A. Sample Target Deployment Scenarios 1207 Internet Service Providers (ISPs) traditionally provide DNS resolvers 1208 to their customers. To that aim, ISPs deploy the following 1209 mechanisms to advertise a list of DNS Recursive DNS server(s) to 1210 their customers: 1212 o Protocol Configuration Options in cellular networks [TS.24008]. 1214 o DHCPv4 [RFC2132] (Domain Name Server Option) or DHCPv6 1215 [RFC8415][RFC3646] (OPTION_DNS_SERVERS). 1217 o IPv6 Router Advertisement [RFC4861][RFC8106] (Type 25 (Recursive 1218 DNS Server Option)). 1220 The communication between a customer's device (possibly via Customer 1221 Premises Equipment (CPE)) and an ISP-supplied DNS resolver takes 1222 place by using cleartext DNS messages (Do53). Some examples are 1223 depicted in Figure 13. In the case of cellular networks, the 1224 cellular network will provide connectivity directly to a host (e.g., 1225 smartphone, tablet) or via a CPE. Do53 mechanisms used within the 1226 Local Area Network (LAN) are similar in both fixed and cellular CPE- 1227 based broadband service offerings. 1229 (a) Fixed Networks 1230 ,--,--,--. 1231 +-+ LAN +---+ ,-' `-. 1232 |H+--------------+CPE+---+ ISP ) 1233 +-+ +---+ `-. ,-' 1234 | `--'--'--' 1235 | | 1236 |<=============Do53============>| 1237 | | 1239 (b) Cellular Networks 1241 | | 1242 |<=============Do53============>| 1243 | | 1244 | ,--,--,-. 1245 +-+ LAN +---+ ,-' . 1246 |H+--------------+CPE+---+ \ 1247 +-+ +---+ ,' ISP `-. 1248 ( ) 1249 +-----+-. ,-' 1250 +-+ | `--'--'--' 1251 |H+----------------+ | 1252 +-+ | 1253 | | 1254 |<=============Do53============>| 1255 | | 1257 Legend: 1258 * H: refers to a host. 1260 Figure 13: Sample Legacy Deployments 1262 A.1. Managed CPEs 1264 This section focuses on CPEs that are managed by ISPs. 1266 A.1.1. Direct DNS 1268 ISPs have developed an expertise in managing service-specific 1269 configuration information (e.g., CPE WAN Management Protocol 1270 [TR-069]). For example, these tools may be used to provision the DNS 1271 server's ADN to managed CPEs if an encrypted DNS is supported by a 1272 local network similar to what is depicted in Figure 14. 1274 For example, DoH-capable (or DoT) clients establish the DoH (or DoT) 1275 session with the discovered DoH (or DoT) server. 1277 The DNS client discovers whether the DNS server in the local network 1278 supports DoH/DoT/DoQ by using a dedicated field in the discovery 1279 message: Encrypted DNS Types (Sections 4, 5, and 6) . 1281 (a) Fixed Networks 1283 ,--,--,--. 1284 +-+ LAN +---+ ,-' `-. 1285 |H+--------------+CPE+---+ ISP ) 1286 +-+ +---+ `-. ,-' 1287 | `--'--'--' 1288 | | 1289 |<========Encrypted DNS========>| 1290 | | 1292 (b) Cellular Networks 1294 | | 1295 |<========Encrypted DNS========>| 1296 | | 1297 | ,--,--,-. 1298 +-+ LAN +---+ ,-' . 1299 |H+--------------+CPE+---+ \ 1300 +-+ +---+ ,' ISP `-. 1301 ( ) 1302 +-----+-. ,-' 1303 +-+ | `--'--'--' 1304 |H+----------------+ | 1305 +-+ | 1306 | | 1307 |<========Encrypted DNS========>| 1308 | | 1310 Figure 14: Encrypted DNS in the WAN 1312 Figure 14 shows the scenario where the CPE relays the list of 1313 encrypted DNS servers it learns for the network by using mechanisms 1314 like DHCP or a specific Router Advertisement message. In such 1315 context, direct encrypted DNS sessions will be established between a 1316 host serviced by a CPE and an ISP-supplied encrypted DNS server (see 1317 the example depicted in Figure 15 for a DoH/DoT-capable host). 1319 ,--,--,--. ,--,--,--. 1320 ,-' `-. ,-' ISP `-. 1321 Host---( LAN CPE----( DNS Server ) 1322 | `-. ,-' `-. ,-' 1323 | `--'--'--' `--'--'--' 1324 | | 1325 |<=========Encrypted DNS===========>| 1327 Figure 15: Direct Encrypted DNS Sessions 1329 A.1.2. Proxied DNS 1331 Figure 16 shows a deployment where the CPE embeds a caching DNS 1332 forwarder. The CPE advertises itself as the default DNS server to 1333 the hosts it serves. The CPE relies upon DHCP or RA to advertise 1334 itself to internal hosts as the default DoT/DoH/Do53 server. When 1335 receiving a DNS request it cannot handle locally, the CPE forwards 1336 the request to an upstream DoH/DoT/Do53 resolver. Such deployment is 1337 required for IPv4 service continuity purposes (e.g., Section 5.4.1 of 1338 [I-D.ietf-v6ops-rfc7084-bis]) or for supporting advanced services 1339 within a local network (e.g., malware filtering, parental control, 1340 Manufacturer Usage Description (MUD) [RFC8520] to only allow intended 1341 communications to and from an IoT device). When the CPE behaves as a 1342 DNS forwarder, DNS communications can be decomposed into two legs: 1344 o The leg between an internal host and the CPE. 1346 o The leg between the CPE and an upstream DNS resolver. 1348 An ISP that offers encrypted DNS to its customers may enable 1349 encrypted DNS in one or both legs as shown in Figure 16. Additional 1350 considerations related to this deployment are discussed in Section 8. 1352 (a) 1353 ,--,--,--. ,--,--,--. 1354 ,-' `-. ,-' ISP `-. 1355 Host---( LAN CPE----( DNS Server ) 1356 | `-. ,-'| `-. ,-' 1357 | `--'--'--' | `--'--'--' 1358 | | | 1359 |<=====Encrypted=====>|<=Encrypted=>| 1360 | DNS | DNS | 1362 (b) 1363 ,--,--,--. ,--,--,--. 1364 Legacy ,-' `-. ,-' ISP `-. 1365 Host---( LAN CPE----( DNS Server ) 1366 | `-. ,-'| `-. ,-' 1367 | `--'--'--' | `--'--'--' 1368 | | | 1369 |<=======Do53========>|<=Encrypted=>| 1370 | | DNS | 1372 Figure 16: Proxied Encrypted DNS Sessions 1374 A.2. Unmanaged CPEs 1376 A.2.1. ISP-facing Unmanaged CPEs 1378 Customers may decide to deploy unmanaged CPEs (assuming the CPE is 1379 compliant with the network access technical specification that is 1380 usually published by ISPs). Upon attachment to the network, an 1381 unmanaged CPE receives from the network its service configuration 1382 (including the DNS information) by means of, e.g., DHCP. That DNS 1383 information is shared within the LAN following the same mechanisms as 1384 those discussed in Appendix A.1. A host can thus establish DoH/DoT 1385 session with a DoH/DoT server similar to what is depicted in 1386 Figure 15 or Figure 16. 1388 A.2.2. Internal Unmanaged CPEs 1390 Customers may also decide to deploy internal routers (called 1391 hereafter, Internal CPEs) for a variety of reasons that are not 1392 detailed here. Absent any explicit configuration on the internal CPE 1393 to override the DNS configuration it receives from the ISP-supplied 1394 CPE, an Internal CPE relays the DNS information it receives via DHCP/ 1395 RA from the ISP-supplied CPE to connected hosts. Encrypted DNS 1396 sessions can be established by a host with the DNS servers of the ISP 1397 (see Figure 17). 1399 ,--,--,--. ,--,--,--. 1400 ,-' Internal ,-' ISP `-. 1401 Host--( Network#A CPE----CPE---( DNS Server ) 1402 | `-. ,-' `-. ,-' 1403 | `--'--'--' `--'--'--' 1404 | | 1405 |<==============Encrypted DNS=============>| 1407 Figure 17: Direct Encrypted DNS Sessions with the ISP DNS Resolver 1408 (Internal CPE) 1410 Similar to managed CPEs, a user may modify the default DNS 1411 configuration of an unmanaged CPE to use his/her favorite DNS servers 1412 instead. Encrypted DNS sessions can be established directly between 1413 a host and a 3rd Party DNS server (see Figure 18). 1415 ,--,--,--. ,--, 1416 ,' Internal ,-' '- 3rd Party 1417 Host--( Network#A CPE----CPE---( ISP )--- DNS Server 1418 | `. ,-' `-. -' | 1419 | `-'--'--' `--' | 1420 | | 1421 |<=================Encrypted DNS==================>| 1423 Figure 18: Direct Encrypted DNS Sessions with a Third Party DNS 1424 Resolver 1426 Section 8.2 discusses considerations related to hosting a forwarder 1427 in the Internal CPE. 1429 Appendix B. Make Use of Discovered Encrypted DNS Servers 1431 Even if the use of a discovered encrypted DNS server is beyond the 1432 discovery process and falls under encrypted server selection, the 1433 following discusses typical conditions under which discovered 1434 encrypted DNS server can be used. 1436 o If the DNS server's IP address discovered by using DHCP/RA is 1437 preconfigured in the OS or Browser as a verified resolver (e.g., 1438 part of an auto-upgrade program such as [Auto-upgrade]), the DNS 1439 client auto-upgrades to use the preconfigured encrypted DNS server 1440 tied to the discovered DNS server IP address. In such a case the 1441 DNS client will perform additional checks out of band, such as 1442 confirming that the Do53 IP address and the encrypted DNS server 1443 are owned and operated by the same organisation. 1445 o Similarly, if the ADN conveyed in DHCP/RA (Sections 4, 5, and 6) 1446 is preconfigured in the OS or browser as a verified resolver, the 1447 DNS client auto-upgrades to establish an encrypted a DoH/DoT/DoQ 1448 session with the ADN. 1450 In such case, the DNS client matches the domain name in the 1451 Encrypted DNS DHCP/RA option with the 'DNS-ID' identifier type 1452 within subjectAltName entry in the server certificate conveyed in 1453 the TLS handshake. 1455 Authors' Addresses 1457 Mohamed Boucadair 1458 Orange 1459 Rennes 35000 1460 France 1462 Email: mohamed.boucadair@orange.com 1464 Tirumaleswar Reddy 1465 McAfee, Inc. 1466 Embassy Golf Link Business Park 1467 Bangalore, Karnataka 560071 1468 India 1470 Email: TirumaleswarReddy_Konda@McAfee.com 1472 Dan Wing 1473 Citrix Systems, Inc. 1474 USA 1476 Email: dwing-ietf@fuggles.com 1478 Neil Cook 1479 Open-Xchange 1480 UK 1482 Email: neil.cook@noware.co.uk 1484 Tommy Jensen 1485 Microsoft 1486 USA 1488 Email: tojens@microsoft.com