idnits 2.17.1 draft-btw-add-home-12.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 (January 22, 2021) is 1191 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 978, 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: July 26, 2021 McAfee 6 D. Wing 7 Citrix 8 N. Cook 9 Open-Xchange 10 T. Jensen 11 Microsoft 12 January 22, 2021 14 DHCP and Router Advertisement Options for Encrypted DNS Discovery 15 draft-btw-add-home-12 17 Abstract 19 The document specifies new DHCP and IPv6 Router Advertisement options 20 to discover encrypted DNS servers (e.g., DNS-over-HTTPS, DNS-over- 21 TLS, DNS-over-QUIC). Particularly, it allows to learn an 22 authentication domain name together with a list of IP addresses and a 23 port number to reach such encrypted DNS servers. The discovery of 24 DNS-over-HTTPS URI Templates is also discussed. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 26, 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Overview and Rationale . . . . . . . . . . . . . . . . . . . 4 63 4. DHCPv6 Encrypted DNS Options . . . . . . . . . . . . . . . . 6 64 4.1. Encrypted DNS ADN Option . . . . . . . . . . . . . . . . 6 65 4.2. Encrypted DNS Address Option . . . . . . . . . . . . . . 7 66 4.3. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 9 67 5. DHCPv4 Encrypted DNS Option . . . . . . . . . . . . . . . . . 9 68 5.1. Encrypted DNS Option . . . . . . . . . . . . . . . . . . 9 69 5.2. DHCPv4 Client Behavior . . . . . . . . . . . . . . . . . 11 70 6. IPv6 RA Encrypted DNS Options . . . . . . . . . . . . . . . . 11 71 6.1. Encrypted DNS ADN Option . . . . . . . . . . . . . . . . 12 72 6.2. Encrypted DNS Address Option . . . . . . . . . . . . . . 13 73 7. DoH URI Templates . . . . . . . . . . . . . . . . . . . . . . 14 74 8. Hosting Encrypted DNS Forwarder in Local Networks . . . . . . 16 75 8.1. Managed CPEs . . . . . . . . . . . . . . . . . . . . . . 16 76 8.1.1. DNS Forwarders . . . . . . . . . . . . . . . . . . . 16 77 8.1.2. ACME . . . . . . . . . . . . . . . . . . . . . . . . 16 78 8.1.3. Auto-Upgrade Based on Domains and their Subdomains . 16 79 8.2. Unmanaged CPEs . . . . . . . . . . . . . . . . . . . . . 17 80 9. Legacy CPEs . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 82 10.1. Spoofing Attacks . . . . . . . . . . . . . . . . . . . . 18 83 10.2. Deletion Attacks . . . . . . . . . . . . . . . . . . . . 19 84 10.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . 19 85 10.4. Wireless Security - Authentication Attacks . . . . . . . 20 86 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 87 11.1. Encrypted DNS Flag Bits . . . . . . . . . . . . . . . . 20 88 11.2. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 21 89 11.3. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . 21 90 11.4. Neighbor Discovery Options . . . . . . . . . . . . . . . 21 91 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 92 13. Contributing Authors . . . . . . . . . . . . . . . . . . . . 22 93 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 94 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 95 14.2. Informative References . . . . . . . . . . . . . . . . . 23 97 Appendix A. Sample Target Deployment Scenarios . . . . . . . . . 26 98 A.1. Managed CPEs . . . . . . . . . . . . . . . . . . . . . . 27 99 A.1.1. Direct DNS . . . . . . . . . . . . . . . . . . . . . 28 100 A.1.2. Proxied DNS . . . . . . . . . . . . . . . . . . . . . 29 101 A.2. Unmanaged CPEs . . . . . . . . . . . . . . . . . . . . . 30 102 A.2.1. ISP-facing Unmanaged CPEs . . . . . . . . . . . . . . 30 103 A.2.2. Internal Unmanaged CPEs . . . . . . . . . . . . . . . 30 104 Appendix B. Make Use of Discovered Encrypted DNS Servers . . . . 31 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 107 1. Introduction 109 This document focuses on the support of encrypted DNS such as DNS- 110 over-HTTPS (DoH) [RFC8484], DNS-over-TLS (DoT) [RFC7858], or DNS- 111 over-QUIC (DoQ) [I-D.ietf-dprive-dnsoquic] in local networks. 113 In particular, the document specifies how a local encrypted DNS 114 server can be discovered and used by connected hosts by means of DHCP 115 [RFC2132], DHCPv6 [RFC8415], and IPv6 Router Advertisement (RA) 116 [RFC4861] options. These options are designed to convey the 117 following information: the DNS Authentication Domain Name (ADN), a 118 list of IP addresses, and optionally a port number. The discovery of 119 DoH URI Templates is discussed in Section 7. 121 Sample target deployment scenarios are discussed in Appendix A; both 122 managed and unmanaged Customer Premises Equipment (CPEs) are covered. 123 It is out of the scope of this document to provide an exhaustive 124 inventory of deployments where Encrypted DNS Options (Sections 4, 5, 125 and 6) can be used. 127 Considerations related to hosting a DNS forwarder in a local network 128 are described in Section 8. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in BCP 135 14 [RFC2119] [RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 This document makes use of the terms defined in [RFC8499]. The 139 following additional terms are used: 141 Do53: refers to unencrypted DNS. 143 Encrypted DNS: refers to a scheme where DNS exchanges are 144 transported over an encrypted channel. Examples of encrypted DNS 145 are DNS-over-TLS (DoT) [RFC7858], DNS-over-HTTPS (DoH) [RFC8484], 146 or DNS-over-QUIC (DoQ) [I-D.ietf-dprive-dnsoquic]. 148 Managed CPE: refers to a CPE that is managed by an Internet Service 149 Providers (ISP). 151 Unmanaged CPE: refers to a CPE that is not managed by an ISP. 153 DHCP: refers to both DHCPv4 and DHCPv6. 155 3. Overview and Rationale 157 This document describes how a DNS client can discover a local 158 encrypted DNS server(s) using DHCP (Sections 4 and 5) and Neighbor 159 Discovery protocol (Section 6). 161 As reported in Section 1.7.2 of [RFC6125]: 163 | Some certification authorities issue server certificates based on 164 | IP addresses, but preliminary evidence indicates that such 165 | certificates are a very small percentage (less than 1%) of issued 166 | certificates. 168 In order to allow for PKIX-based authentication between a DNS client 169 and an encrypted DNS server while accommodating the current best 170 practices for issuing certificates, this document allows for 171 configuring an authentication domain name to be presented as a 172 reference identifier for DNS authentication purposes. 174 To avoid adding a dependency on another server to resolve the ADN, 175 the options return a list of IP addresses to locate the encrypted DNS 176 server. In the various scenarios sketched in Appendix A, encrypted 177 DNS servers may terminate on the same IP address or distinct IP 178 addresses. Terminating encrypted DNS servers on the same or distinct 179 IP addresses is deployment specific. It is RECOMMENDED to return 180 both the ADN and a list of IP addresses to a requesting host. 182 Note that in order to optimize the size of discovery messages when 183 all servers terminate on the same IP address, a host may rely upon 184 the discovery mechanisms specified in [RFC2132][RFC3646][RFC8106] to 185 retrieve a list of IP addresses to reach their DNS servers. 186 Nevertheless, this approach requires a client that supports more than 187 one encrypted DNS to probe that list of IP addresses. To avoid such 188 probing, the options defined in the following sections associate an 189 IP address with an encrypted DNS type. No probing is required in 190 such design. 192 A list of IP addresses to reach an encrypted DNS server can be 193 returned in the option to accommodate current deployments relying 194 upon primary and backup servers. Whether one IP address or more are 195 returned in an option is deployment specific. For example, a router 196 embedding a recursive server or forwarder has to include one single 197 IP address pointing to one of its LAN-facing interfaces. This 198 address can be a private IPv4 address, a link-local address, a Unique 199 Local IPv6 unicast Address (ULA), or a Global Unicast Address (GUA). 201 If more than one IP address are to be returned in an Encrypted DNS 202 server option, these addresses are ordered in the preference for use 203 by the client. 205 Because DoT and DoQ may make use of customized port numbers instead 206 of default ones, the Encrypted DNS server options are designed to 207 return alternate port numbers. 209 Some ISPs rely upon external resolvers (e.g., outsourced service or 210 public resolvers); these ISPs provide their customers with the IP 211 addresses of these resolvers. These addresses are typically 212 configured on CPEs using dedicated management tools. Likewise, users 213 can modify the default DNS configuration of their CPEs (e.g., 214 supplied by their ISP) to configure their favorite DNS servers. This 215 document permits such deployments. 217 If the encrypted DNS is discovered by a host using both RA and DHCP, 218 the rules discussed in Section 5.3.1 of [RFC8106] MUST be followed. 220 The DNS client establishes an encrypted DNS session with the 221 discovered DNS IP address(es) and port number, and uses the mechanism 222 discussed in Section 8 of [RFC8310] to authenticate the DNS server 223 certificate using the authentication domain name conveyed in the 224 encrypted DNS options. 226 Devices may be connected to multiple networks; each providing their 227 own DNS configuration using the discovery mechanisms specified in 228 this document. Nevertheless, it is out of the scope of this 229 specification to discuss DNS selection of multi-interface devices. 230 The reader may refer to [RFC6731] for a discussion of issues and an 231 example of DNS server selection for multi-interfaced devices. 233 DHCP/RA options to discover encrypted DNS servers (including, DoH URI 234 Templates should the WG pursue that approach pending feedback) takes 235 precedence over DEER [I-D.pauly-add-deer] since DEER uses unencrypted 236 DNS to an external DNS resolver, which is susceptible to both 237 internal and external attacks whereas DHCP/RA is only vulnerable to 238 internal attacks. 240 4. DHCPv6 Encrypted DNS Options 242 This section defines two DHCPv6 options: DHCPv6 Encrypted DNS ADN 243 option (Section 4.1) and DHCPv6 Encrypted DNS Address option 244 (Section 4.2). 246 4.1. Encrypted DNS ADN Option 248 The DHCPv6 Encrypted DNS ADN option is used to configure an 249 authentication domain name of the encrypted DNS server. The format 250 of this option is shown in Figure 1. 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | OPTION_V6_ENC_ADN | Option-length | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Enc DNS Flags | | 257 +---------------+ + 258 | | 259 ~ authentication-domain-name ~ 260 | | 261 +---------------------------------------------------------------+ 263 Figure 1: DHCPv6 Encrypted DNS ADN Option 265 The fields of the option shown in Figure 1 are as follows: 267 Option-code: OPTION_V6_ENC_ADN (TBA1, see Section 11.2) 269 Option-length: Length of the enclosed data in octets. 271 Enc DNS Flags (Encrypted DNS Flags): Indicates the type(s) of the 272 encrypted DNS server conveyed in this attribute. The format of 273 this 8-bit field is shown in Figure 2. 275 +-+-+-+-+-+-+-+-+ 276 |U|U|U|U|U|Q|H|T| 277 +-+-+-+-+-+-+-+-+ 279 Figure 2: Encrypted DNS Flags Field 281 T: If set, this bit indicates that the server supports DoT 282 [RFC7858]. 284 H: If set, this bit indicates that the server supports DoH 285 [RFC8484]. 287 Q: If set, this bit indicates that the server supports DoQ 288 [I-D.ietf-dprive-dnsoquic]. 290 U: Unassigned bits. These bits MUST be unset by the sender. 291 Associating a meaning with an unassigned bit can be done as per 292 Section 11.1. 294 In a request, these bits are assigned to indicate the requested 295 encrypted DNS server type(s) by the client. In a response, these 296 bits are set as a function of the encrypted DNS supported by the 297 server and the requested encrypted DNS server type(s). 299 To keep the packet small, if more than one encrypted DNS type 300 (e.g., both DoH and DoT) are to be returned to a requesting client 301 and the same ADN is used for these types, the corresponding bits 302 must be set in the 'Encrypted DNS Types' field of the same option 303 instance in a response. For example, if the client requested DoH 304 and DoT and the server supports both with the same ADN, then both 305 T and H bits must be set. 307 authentication-domain-name: A fully qualified domain name of the 308 encrypted DNS server. This field is formatted as specified in 309 Section 10 of [RFC8415]. 311 An example of the authentication-domain-name encoding is shown in 312 Figure 3. This example conveys the FQDN "doh1.example.com.", and 313 the resulting Option-length field is 18. 315 +------+------+------+------+------+------+------+------+------+ 316 | 0x04 | d | o | h | 1 | 0x07 | e | x | a | 317 +------+------+------+------+------+------+------+------+------+ 318 | m | p | l | e | 0x03 | c | o | m | 0x00 | 319 +------+------+------+------+------+------+------+------+------+ 321 Figure 3: An Example of the DNS authentication-domain-name Encoding 323 4.2. Encrypted DNS Address Option 325 The DHCPv6 Encrypted DNS Address option is used to configure a list 326 of IP addresses and a port number of the encrypted DNS server. The 327 format of this option is shown in Figure 4. 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | OPTION_V6_ENC_ADD | Option-length | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Enc DNS Flags | Unassigned | Port Number | 334 +---------------+---------------+-------------------------------+ 335 | | 336 | ipv6-address | 337 | | 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | | 341 | ipv6-address | 342 | | 343 | | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | ... | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Figure 4: DHCPv6 Encrypted DNS Address Option 350 The fields of the option shown in Figure 4 are as follows: 352 Option-code: OPTION_V6_ENC_ADD (TBA2, see Section 11.2) 354 Option-length: Length of the enclosed data in octets. 356 Enc DNS Flags (Encrypted DNS Flags): Indicates the type(s) of the 357 encrypted DNS server conveyed in this attribute. The format of 358 this 8-bit field is shown in Figure 2. In a request, these bits 359 are set to indicate the requested encrypted DNS server type(s) by 360 the client. In a response, these bits are set as a function of 361 the encrypted DNS supported by the server and the requested 362 encrypted DNS server type(s). 364 Unassigned: These bits MUST be unset by the sender. Associating a 365 meaning with an unassigned bit can be done via Standards Action 366 [RFC8126]. 368 Port Number: If not null, it indicates the port number to be used 369 for the encrypted DNS. If this field is set to zero, this 370 indicates that default port numbers should be used. As a 371 reminder, the default port number is 853 for DoT and 443 for DoH. 373 ipv6-address(es): Indicates one or more IPv6 addresses to reach the 374 encrypted DNS server. An address can be link-local, ULA, or GUA. 376 Multiple instances of OPTION_V6_ENC_ADN (or OPTION_V6_ENC_ADD) may be 377 returned to a DHCPv6 client; each pointing to a distinct encrypted 378 DNS server type. 380 If more than one encrypted DNS server types is supported on the same 381 IP address and default port numbers are used, one instance of 382 OPTION_V6_ENC_ADD option with the appropriate bits set in "Encr DNS 383 Types" field should be returned by the DHCP server. 385 4.3. DHCPv6 Client Behavior 387 To discover an encrypted DNS server, the DHCPv6 client MUST include 388 OPTION_V6_ENC_ADN and OPTION_V6_ENC_ADD in an Option Request Option 389 (ORO), as in Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 390 21.7 of [RFC8415]. The DHCPv6 client sets the Encrypted DNS Types 391 field to the requested encrypted DNS server type(s). 393 If the DHCPv6 client requested more than one encrypted DNS server 394 type, the DHCP client MUST be prepared to receive multiple 395 OPTION_V6_ENC_ADN (or OPTION_V6_ENC_ADD) options; each option is to 396 be treated as a separate encrypted DNS server. 398 The DHCPv6 client MUST silently discard multicast and host loopback 399 addresses conveyed in OPTION_V6_ENC_ADD. 401 5. DHCPv4 Encrypted DNS Option 403 5.1. Encrypted DNS Option 405 The DHCPv4 Encrypted DNS option is used to configure an 406 authentication domain name, a list of IP addresses, and a port number 407 of the encrypted DNS server. The format of this option is 408 illustrated in Figure 5. 410 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | TBA3 | Length | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Enc DNS Flags | Num Addresses | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Port Number | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | | 419 ~ IPv4 Address(es) ~ 420 | | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | | 423 ~ authentication-domain-name ~ 424 | | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Figure 5: DHCPv4 Encrypted DNS Option 429 The fields of the option shown in Figure 5 are as follows: 431 Code: OPTION_V4_ENC_DNS (TBA3, see Section 11.3). 433 Length: Length of the enclosed data in octets. 435 Enc DNS Flags (Encrypted DNS Flags): Indicates the type(s) of the 436 encrypted DNS server conveyed in this attribute. The format of 437 this field is shown in Figure 2. 439 Num Addresses: Indicates the number of included IPv4 addresses. 441 Port Number: If not null, it indicates the port number to be used 442 for the encrypted DNS. A null value indicates that default port 443 numbers are used. As a reminder, the default port number is 853 444 for DoT and 443 for DoH. 446 IPv4 Address(es): Indicates one or more IPv4 addresses to reach the 447 encrypted DNS server. Both private and public IPv4 addresses can 448 be included in this field. The format of this field is shown in 449 Figure 6. This format assumes that an IPv4 address is encoded as 450 a1.a2.a3.a4. 452 0 8 16 24 32 40 48 453 +-----+-----+-----+-----+-----+-----+-- 454 | a1 | a2 | a3 | a4 | a1 | a2 | ... 455 +-----+-----+-----+-----+-----+-----+-- 456 IPv4 Address 1 IPv4 Address 2 ... 458 Figure 6: Format of the IPv4 Addresses Field 460 authentication-domain-name: The domain name of the encrypted DNS 461 server. This field is formatted as specified in Section 10 of 462 [RFC8415]. The format of this field is shown in Figure 7. The 463 values s1, s2, s3, etc. represent the domain name labels in the 464 domain name encoding. 466 +-----+-----+-----+-----+-----+-- 467 | s1 | s2 | s3 | s4 | s5 | ... 468 +-----+-----+-----+-----+-----+-- 469 authentication-domain-name 471 Figure 7: Format of the Authentication Domain Name Field 473 OPTION_V4_ENC_DNS is a concatenation-requiring option. As such, the 474 mechanism specified in [RFC3396] MUST be used if OPTION_V4_ENC_DNS 475 exceeds the maximum DHCPv4 option size of 255 octets. 477 5.2. DHCPv4 Client Behavior 479 To discover an encrypted DNS server, the DHCPv4 client requests the 480 Encrypted DNS server by including OPTION_V4_ENC_DNS in a Parameter 481 Request List option [RFC2132]. The DHCPv4 client sets the Encrypted 482 DNS Types field to the requested encrypted DNS server. 484 If the DHCPv4 client requested more than one encrypted DNS server 485 type, the DHCPv4 client MUST be prepared to receive multiple DHCP 486 OPTION_V4_ENC_DNS options; each option is to be treated as a separate 487 encrypted DNS server. 489 The DHCPv4 client MUST silently discard multicast and host loopback 490 addresses conveyed in OPTION_V4_ENC_DNS. 492 6. IPv6 RA Encrypted DNS Options 494 This section defines two Neighbor Discovery [RFC4861]: IPv6 Router 495 Advertisement (RA) Encrypted DNS ADN option (Section 6.1) and IPv6 RA 496 Encrypted DNS Address option (Section 6.2). These options are useful 497 in contexts similar to those discussed in Section 1.1 of [RFC8106]. 499 6.1. Encrypted DNS ADN Option 501 The IPv6 RA Encrypted DNS ADN option is used to configure an 502 authentication domain name of the encrypted DNS server. The format 503 of this option is illustrated in Figure 8. 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | TBA4 | Length | Enc DNS Flags | Unassigned | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Lifetime | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | | 513 ~ authentication-domain-name ~ 514 | | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 Figure 8: RA Encrypted DNS ADN Option 519 The fields of the option shown in Figure 8 are as follows: 521 Type: 8-bit identifier of the Encrypted DNS Option as assigned by 522 IANA (TBA4, see Section 11.4). 524 Length: 8-bit unsigned integer. The length of the option (including 525 the Type and Length fields) is in units of 8 octets. 527 Enc DNS Flags (Encrypted DNS Flags): Indicates the type(s) of the 528 encrypted DNS server conveyed in this attribute. The format of 529 this field is shown in Figure 2. 531 Unassigned: This field is unused. It MUST be initialized to zero by 532 the sender and MUST be ignored by the receiver. 534 Lifetime: 32-bit unsigned integer. The maximum time in seconds 535 (relative to the time the packet is received) over which the 536 discovered Authentication Domain Name is valid. 538 The value of Lifetime SHOULD by default be at least 3 * 539 MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA 540 interval as defined in [RFC4861]. 542 A value of all one bits (0xffffffff) represents infinity. 544 A value of zero means that this Authentication Domain Name MUST no 545 longer be used. 547 authentication Domain Name: The domain name of the encrypted DNS 548 server. This field is formatted as specified in Section 10 of 549 [RFC8415]. 551 This field MUST be padded with zeros so that its size is a 552 multiple of 8 octets. 554 6.2. Encrypted DNS Address Option 556 The IPv6 RA Encrypted DNS Address option is used to configure a port 557 number and a list of IPv6 addresses of the encrypted DNS server. The 558 format of this option is illustrated in Figure 9. All of the 559 addresses share the same Lifetime value. Similar to [RFC8106], if it 560 is desirable to have different Lifetime values per IP address, 561 multiple Encrypted DNS Address options may be used. 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | TBA5 | Length | Unassigned | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Lifetime | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Enc DNS Flags | Unassigned | Port Number | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | | 573 | ipv6-address | 574 | | 575 | | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | | 578 | ipv6-address | 579 | | 580 | | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | ... | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 Figure 9: RA Encrypted DNS Address Option 587 The fields of the RA Encrypted DNS Address option shown in Figure 9 588 are as follows: 590 Type: 8-bit identifier of the Encrypted DNS Address Option as 591 assigned by IANA (TBA5, see Section 11.4). 593 Length: 8-bit unsigned integer. The length of the option (including 594 the Type and Length fields) is in units of 8 octets. 596 Unassigned: This field is unused. It MUST be initialized to zero by 597 the sender and MUST be ignored by the receiver. 599 Lifetime: 32-bit unsigned integer. The maximum time in seconds 600 (relative to the time the packet is received) over which the 601 discovered encrypted DNS IPv6 addresses are valid. 603 The value of Lifetime SHOULD by default be at least 3 * 604 MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA 605 interval as defined in [RFC4861]. 607 A value of all one bits (0xffffffff) represents infinity. 609 A value of zero means that these IPv6 addresses MUST no longer be 610 used. 612 Enc DNS Flags (Encrypted DNS Flags): Indicates the type(s) of the 613 encrypted DNS server conveyed in this attribute. The format of 614 this field is shown in Figure 2. 616 Port Number: If not null, it indicates the port number to be used 617 for the encrypted DNS. A null value indicates that default port 618 numbers must be used. As a reminder, the default port number is 619 853 for DoT and 443 for DoH. 621 ipv6-address(es): One or more IPv6 addresses of the encrypted DNS 622 server. An address can be link-local, ULA, or GUA. 624 7. DoH URI Templates 626 DoH servers may support more than one URI Template [RFC8484]. Also, 627 if the resolver hosts several DoH services (e.g., no-filtering, 628 blocking adult content, blocking malware), these services can be 629 discovered as templates. The following discusses a mechanism for a 630 DoH client to retrieve the list of supported templates by a DoH 631 server. 633 Upon discovery of a DoH resolver (Sections 4, 5, and 6), the DoH 634 client may contact that DoH resolver to retrieve the list of 635 supported DoH services using DEER [I-D.pauly-add-deer]. This will 636 allow the client to discover the resolver's supported DoH templates 637 or DoH resolvers that the discovered resolver designates using DNS 638 SVCB queries [I-D.schwartz-svcb-dns]. The designated DoH resolvers 639 and DoH resolver discovered using DHCP/RA may be hosted on the same 640 or distinct IP addresses. 642 Let's suppose that a host has discovered an encrypted DNS server that 643 is DoH-capable. The host has also discovered the following 644 information: 646 o ADN: doh.example.com 648 o Locator: 2001:db8:1::1 650 The client will use DEER [I-D.pauly-add-deer] to discover the DoH 651 templates supported by the DNS server at the Locator (2001:db8:1::1). 652 In addition to the checks included in DEER, clients should verify the 653 ADN (doh.example.com) is valid for the certificate provided by the 654 DoH resolver. However, the IP address of the DEER-discovered 655 resolver may differ from the Locator field value. This will allow 656 the ISP to offer different DoH services to the endpoints attached to 657 local networks. 659 Alternatively, dedicated DHCP/RA options may be defined to convey an 660 URI template in order to avoid additional network traffic to 661 bootstrap DoH configuration. An example of the format of such an 662 option is depicted in Figure 10. 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | OPTION_V6_DOH_TEMPLATE | Option-length | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | | 670 ~ uri-template-data ~ 671 | . . . | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Each instance of the uri-template-data is formatted as follows: 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 677 | uri-template-len | URI Template | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 680 Figure 10: Example of a DHCPv6 URI Template Option 682 Note: More feedback from the WG is needed to decide which 683 approach(es) to follow. 685 How a DoH client makes use of the configured DoH services is out of 686 the scope of this document. 688 8. Hosting Encrypted DNS Forwarder in Local Networks 690 This section discusses some deployment considerations (not 691 recommendations) to host an encrypted DNS forwarder within a local 692 network. 694 8.1. Managed CPEs 696 The section discusses mechanisms that can be used to host an 697 encrypted DNS forwarder in a managed CPE (Appendix A.1). 699 8.1.1. DNS Forwarders 701 The managed CPE should support a configuration parameter to instruct 702 the CPE whether it has to relay the encrypted DNS server received 703 from the ISP's network or has to announce itself as a forwarder 704 within the local network. The default behavior of the CPE is to 705 supply the encrypted DNS server received from the ISP's network. 707 8.1.2. ACME 709 The ISP can assign a unique FQDN (e.g., "cpe1.example.com") and a 710 domain-validated public certificate to the encrypted DNS forwarder 711 hosted on the CPE. Automatic Certificate Management Environment 712 (ACME) [RFC8555] can be used by the ISP to automate certificate 713 management functions such as domain validation procedure, certificate 714 issuance and certificate revocation. 716 8.1.3. Auto-Upgrade Based on Domains and their Subdomains 718 If the ADN conveyed in DHCP/RA (Sections 4, 5, and 6) is 719 preconfigured in popular OSes or browsers as a verified resolver and 720 the auto-upgrade (Appendix B) is allowed for both the preconfigured 721 ADN and its sub-domains, the encrypted DNS client will learn the 722 local encrypted DNS forwarder using DHCP/RA and auto-upgrade because 723 the preconfigured ADN would match the subjectAltName value in the 724 server certificate. For example, if the preconfigured ADN is 725 "*.example.com" and the discovered encrypted DNS forwarder is 726 "cpe1.example.com", auto-upgrade will take place. 728 In this case, the CPE can communicate the ADN of the local DoH 729 forwarder (Section 8.1.2) to internal hosts using DHCP/RA (Sections 730 4, 5, and 6). 732 Let's suppose that "*.example.net" is preconfigured as a verified 733 resolved in the browser or OS. If the encrypted DNS client discovers 734 a local forwarder "cpe1-internal.example.net", the encrypted DNS 735 client will auto-upgrade because the preconfigured ADN would match 736 subjectAltName value "cpe1-internal.example.net" of type dNSName. As 737 shown in Figure 11, the auto-upgrade to a rogue server advertising 738 "rs.example.org" will fail because it does not match "*.example.net". 740 Encrypted DNS CPE 741 capable client (@i) 742 | | 743 |<=================DHCP===============| 744 | {ADN=cpe1-internal.example.net, @i} | 745 | | 746 | Rogue Server | 747 | (@rs) | 748 | | | 749 X<===========DHCP=========| | 750 |{ADN=rs.example.org, @rs}| | 751 | | | 752 | | 753 |<=================DoH===============>| 754 | | 756 Legend: 757 * @i: internal IP address of the CPE 758 * @rs: IP address of a rogue server 760 Figure 11: A Simplified Example of Auto-upgrade based on Subdomains 762 8.2. Unmanaged CPEs 764 The approach specified in Section 8.1 does not apply for hosting a 765 DNS forwarder in an unmanaged CPE. 767 The unmanaged CPE administrator (referred to as administrator) can 768 host an encrypted DNS forwarder on the unmanaged CPE. This assumes 769 the following: 771 o The encrypted DNS server certificate is managed by the entity in- 772 charge of hosting the encrypted DNS forwarder. 774 Alternatively, a security service provider can assign a unique 775 FQDN to the CPE. The encrypted DNS forwarder will act like a 776 private encrypted DNS server only be accessible from within the 777 the local network. 779 o The encrypted DNS forwarder will either be configured to use the 780 ISP's or a 3rd party encrypted DNS server. 782 o The unmanaged CPE will advertise the encrypted DNS forwarder ADN 783 using DHCP/RA to internal hosts. 785 Figure 12 illustrates an example of an unmanaged CPE hosting a 786 forwarder which connects to a 3rd party encrypted DNS server. In 787 this example, the DNS information received from the managed CPE (and 788 therefore from the ISP) is ignored by the Internal CPE hosting the 789 forwarder. 791 ,--,--,--. ,--, 792 ,' Internal Managed ,-' '- 3rd Party 793 Host--( Network#A CPE--------CPE------( ISP )--- DNS Server 794 | `. ,-'| | `-. -' | 795 | `-'--'--' | |<==DHCP==>|`--' | 796 | |<==DHCP==>| | | 797 |<======DHCP=======>| | | 798 | {RI, @i} | | 799 |<==Encrypted DNS==>|<==========Encrypted DNS==========>| 801 Legend: 802 * @i: IP address of the DNS forwarder hosted in the Internal 803 CPE. 805 Figure 12: Example of an Internal CPE Hosting a Forwarder 807 9. Legacy CPEs 809 Hosts serviced by legacy CPEs that can't be upgraded to support the 810 options defined in Sections 4, 5, and 6 won't be able to learn the 811 encrypted DNS server hosted by the ISP, in particular. If the ADN is 812 not discovered using DHCP/RA, such hosts will have to fallback to use 813 DEER as defined in [I-D.pauly-add-deer] to discover the encrypted DNS 814 server and to retrieve the list of supported DoH services using the 815 SVCB RRtype [I-D.schwartz-svcb-dns] without verifying the hostname of 816 discovered templates with the ADN. Other guidance in DEER relating 817 to resolver verification must be followed in this case. This will 818 prevent an unencrypted resolver on a local address from referring to 819 an encrypted resolver at a different address without an out-of-band 820 configuration in the client beyond the scope of this document or 821 DEER. 823 10. Security Considerations 825 10.1. Spoofing Attacks 827 DHCP/RA messages are not encrypted or protected against modification 828 within the LAN. Unless mitigated (described below), the content of 829 DHCP and RA messages can be spoofed or modified by active attackers, 830 such as compromised devices within the local network. An active 831 attacker (Section 3.3 of [RFC3552]) can spoof the DHCP/RA response to 832 provide the attacker's Encrypted DNS server. Note that such an 833 attacker can launch other attacks as discussed in Section 22 of 834 [RFC8415]. The attacker can get a domain name with a domain- 835 validated public certificate from a CA and host an Encrypted DNS 836 server. Also, an attacker can use a public IP address and get an 'IP 837 address'-validated public certificate from a CA to host an Encrypted 838 DNS server. 840 Attacks of spoofed or modified DHCP responses and RA messages by 841 attackers within the local network may be mitigated by making use of 842 the following mechanisms: 844 o DHCPv6-Shield described in [RFC7610], the CPEs discards DHCP 845 response messages received from any local endpoint. 847 o RA-Guard described in [RFC7113], the CPE discards RAs messages 848 received from any local endpoint. 850 o Source Address Validation Improvement (SAVI) solution for DHCP 851 described in [RFC7513], the CPE filters packets with forged source 852 IP addresses. 854 Encrypted DNS sessions with rogue servers that spoof the IP address 855 of a DNS server will fail because the DNS client will fail to 856 authenticate that rogue server based upon PKIX authentication 857 [RFC6125], particularly the authentication domain name in the 858 Encrypted DNS Option. DNS clients that ignore authentication 859 failures and accept spoofed certificates will be subject to attacks 860 (e.g., redirect to malicious servers, intercept sensitive data). 862 Encrypted DNS connections received from outside the local network 863 MUST be discarded by the encrypted DNS forwarder in the CPE. This 864 behavior adheres to REQ#8 in [RFC6092]; it MUST apply for both IPv4 865 and IPv6. 867 10.2. Deletion Attacks 869 If the DHCP responses or RAs are dropped by the attacker, the client 870 can fallback to use a preconfigured encrypted DNS server. However, 871 the use of policies to select servers is out of the scope of this 872 document. 874 Note that deletion attack is not specific to DHCP/RA. 876 10.3. Passive Attacks 878 A passive attacker (Section 3.2 of [RFC3552]) can identify a host is 879 using DHCP/RA to discover an encrypted DNS server and can infer that 880 host is capable of using DoH/DoT/DoQ to encrypt DNS messages. 881 However, a passive attacker cannot spoof or modify DHCP/RA messages. 883 10.4. Wireless Security - Authentication Attacks 885 Wireless LAN (WLAN) as frequently deployed in local networks (e.g., 886 home networks) is vulnerable to various attacks (e.g., [Evil-Twin], 887 [Krack], [Dragonblood]). Because of these attacks, only 888 cryptographically authenticated communications are trusted on WLANs. 889 This means information provided by such networks via DHCP, DHCPv6, or 890 RA (e.g., NTP server, DNS server, default domain) are untrusted 891 because DHCP and RA are not authenticated. 893 If the pre-shared-key is the same for all clients that connect to the 894 same WLAN, the shared key will be available to all nodes, including 895 attackers, so it is possible to mount an active on-path attack. Man- 896 in-the-middle attacks are possible within local networks because such 897 WLAN authentication lacks peer entity authentication. 899 This leads to the need for provisioning unique credentials for 900 different clients. Endpoints can be provisioned with unique 901 credentials (username and password, typically) provided by the local 902 network administrator to mutually authenticate to the local WLAN 903 Access Point (e.g., 802.1x Wireless User Authentication on OpenWRT 904 [dot1x], EAP-pwd [RFC8146]). Not all of endpoint devices (e.g., IoT 905 devices) support 802.1x supplicant and need an alternate mechanism to 906 connect to the local network. To address this limitation, unique 907 pre-shared keys can be created for each such device and WPA-PSK is 908 used (e.g., [PSK]). 910 11. IANA Considerations 912 11.1. Encrypted DNS Flag Bits 914 1 2 3 4 5 6 7 8 915 +-+-+-+-+-+-+-+-+ 916 Encrypted DNS Types is a set of 8 flags: |U|U|U|U|U|Q|H|T| 917 +-+-+-+-+-+-+-+-+ 919 where flag bits in positions 1-5 are for future assignment as 920 additional flag bits. 922 This document requests IANA to create a new registry called 923 "Encrypted DNS Types". The initial values of the registry are as 924 follows: 926 +--------------+-------+---------------------+----------------+ 927 | Bit Position | Label | Description | Reference | 928 +--------------+-------+---------------------+----------------+ 929 | 1 | U | Unassigned | | 930 | 2 | U | Unassigned | | 931 | 3 | U | Unassigned | | 932 | 4 | U | Unassigned | | 933 | 5 | U | Unassigned | | 934 | 6 | Q | DNS-over-QUIC (DoQ) | [ThisDocument] | 935 | 7 | H | DNS-over-HTTP (DoH) | [ThisDocument] | 936 | 8 | T | DNS-over-TLS (DoT) | [ThisDocument] | 937 +--------------+-------+---------------------+----------------+ 939 New flag bits are assigned via Standards Action [RFC8126]. 941 11.2. DHCPv6 Options 943 IANA is requested to assign the following new DHCPv6 Option Code in 944 the registry maintained in [DHCPV6]. 946 +-------+-------------------+---------+------------+----------------+ 947 | Value | Description | Client | Singleton | Reference | 948 | | | ORO | Option | | 949 +-------+-------------------+---------+------------+----------------+ 950 | TBA1 | OPTION_V6_ENC_ADN | Yes | No | [ThisDocument] | 951 | TBA2 | OPTION_V6_ENC_ADD | Yes | No | [ThisDocument] | 952 +-------+-------------------+---------+------------+----------------+ 954 11.3. DHCPv4 Option 956 IANA is requested to assign the following new DHCP Option Code in the 957 registry maintained in [BOOTP]. 959 +------+------------------+-------+----------------+----------------+ 960 | Tag | Name | Data | Meaning | Reference | 961 | | | Length| | | 962 +------+------------------+-------+----------------+----------------+ 963 | TBA3 | OPTION_V4_ENC_DNS| N | Encrypted DNS | [ThisDocument] | 964 | | | | Server | | 965 +------+------------------+-------+----------------+----------------+ 967 11.4. Neighbor Discovery Options 969 IANA is requested to assign the following new IPv6 Neighbor Discovery 970 Option type in the "IPv6 Neighbor Discovery Option Formats" sub- 971 registry under the "Internet Control Message Protocol version 6 972 (ICMPv6) Parameters" registry maintained in [ND]. 974 +------+----------------------------------+----------------+ 975 | Type | Description | Reference | 976 +------+----------------------------------+----------------+ 977 | TBA4 | DNS Encrypted DNS ADN Option | [ThisDocument] | 978 | TBA5 | DNS Encrypted DNS Address Option | [ThisDocument] | 979 +------+----------------------------------+----------------+ 981 12. Acknowledgements 983 Many thanks to Christian Jacquenet and Michael Richardson for the 984 review. 986 Thanks to Stephen Farrell, Martin Thomson, Vittorio Bertola, Stephane 987 Bortzmeyer, Ben Schwartz, and Iain Sharp for the comments. 989 Thanks to Mark Nottingham for the feedback on HTTP redirection. 991 The use of DHCP to retrieve an authentication domain name was 992 discussed in Section 7.3.1 of [RFC8310] and 993 [I-D.pusateri-dhc-dns-driu]. 995 13. Contributing Authors 997 Nicolai Leymann 998 Deutsche Telekom 999 Germany 1001 Email: n.leymann@telekom.de 1003 14. References 1005 14.1. Normative References 1007 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1008 Requirement Levels", BCP 14, RFC 2119, 1009 DOI 10.17487/RFC2119, March 1997, 1010 . 1012 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1013 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 1014 . 1016 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 1017 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 1018 DOI 10.17487/RFC3396, November 2002, 1019 . 1021 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1022 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1023 DOI 10.17487/RFC4861, September 2007, 1024 . 1026 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1027 "IPv6 Router Advertisement Options for DNS Configuration", 1028 RFC 8106, DOI 10.17487/RFC8106, March 2017, 1029 . 1031 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1032 Writing an IANA Considerations Section in RFCs", BCP 26, 1033 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1034 . 1036 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1037 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1038 May 2017, . 1040 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1041 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1042 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1043 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1044 . 1046 14.2. Informative References 1048 [Auto-upgrade] 1049 The Unicode Consortium, "DoH providers: criteria, process 1050 for Chrome", . 1053 [BOOTP] "BOOTP Vendor Extensions and DHCP Options", 1054 . 1057 [DHCPV6] "DHCPv6 Option Codes", . 1061 [dot1x] Cisco, "Basic 802.1x Wireless User Authentication", 1062 . 1065 [Dragonblood] 1066 The Unicode Consortium, "Dragonblood: Analyzing the 1067 Dragonfly Handshake of WPA3 and EAP-pwd", 1068 . 1070 [Evil-Twin] 1071 The Unicode Consortium, "Evil twin (wireless networks)", 1072 . 1075 [I-D.ietf-dprive-dnsoquic] 1076 Huitema, C., Mankin, A., and S. Dickinson, "Specification 1077 of DNS over Dedicated QUIC Connections", draft-ietf- 1078 dprive-dnsoquic-01 (work in progress), October 2020. 1080 [I-D.ietf-v6ops-rfc7084-bis] 1081 Palet, J., "Basic Requirements for IPv6 Customer Edge 1082 Routers", draft-ietf-v6ops-rfc7084-bis-04 (work in 1083 progress), June 2017. 1085 [I-D.pauly-add-deer] 1086 Pauly, T., Kinnear, E., Wood, C., McManus, P., and T. 1087 Jensen, "Discovery of Equivalent Encrypted Resolvers", 1088 draft-pauly-add-deer-00 (work in progress), November 2020. 1090 [I-D.pusateri-dhc-dns-driu] 1091 Pusateri, T. and W. Toorop, "DHCPv6 Options for private 1092 DNS Discovery", draft-pusateri-dhc-dns-driu-00 (work in 1093 progress), July 2018. 1095 [I-D.schwartz-svcb-dns] 1096 Schwartz, B., "Service Binding Mapping for DNS Servers", 1097 draft-schwartz-svcb-dns-01 (work in progress), August 1098 2020. 1100 [Krack] The Unicode Consortium, "Key Reinstallation Attacks", 1101 2017, . 1103 [ND] "IPv6 Neighbor Discovery Option Formats", 1104 . 1107 [PSK] Cisco, "Identity PSK Feature Deployment Guide", 1108 . 1112 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1113 Text on Security Considerations", BCP 72, RFC 3552, 1114 DOI 10.17487/RFC3552, July 2003, 1115 . 1117 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 1118 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1119 DOI 10.17487/RFC3646, December 2003, 1120 . 1122 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1123 Capabilities in Customer Premises Equipment (CPE) for 1124 Providing Residential IPv6 Internet Service", RFC 6092, 1125 DOI 10.17487/RFC6092, January 2011, 1126 . 1128 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1129 Verification of Domain-Based Application Service Identity 1130 within Internet Public Key Infrastructure Using X.509 1131 (PKIX) Certificates in the Context of Transport Layer 1132 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1133 2011, . 1135 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 1136 Recursive DNS Server Selection for Multi-Interfaced 1137 Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, 1138 . 1140 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 1141 Advertisement Guard (RA-Guard)", RFC 7113, 1142 DOI 10.17487/RFC7113, February 2014, 1143 . 1145 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 1146 Validation Improvement (SAVI) Solution for DHCP", 1147 RFC 7513, DOI 10.17487/RFC7513, May 2015, 1148 . 1150 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 1151 Protecting against Rogue DHCPv6 Servers", BCP 199, 1152 RFC 7610, DOI 10.17487/RFC7610, August 2015, 1153 . 1155 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1156 and P. Hoffman, "Specification for DNS over Transport 1157 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1158 2016, . 1160 [RFC8146] Harkins, D., "Adding Support for Salted Password Databases 1161 to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017, 1162 . 1164 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1165 for DNS over TLS and DNS over DTLS", RFC 8310, 1166 DOI 10.17487/RFC8310, March 2018, 1167 . 1169 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1170 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1171 . 1173 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1174 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1175 January 2019, . 1177 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 1178 Description Specification", RFC 8520, 1179 DOI 10.17487/RFC8520, March 2019, 1180 . 1182 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1183 Kasten, "Automatic Certificate Management Environment 1184 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 1185 . 1187 [TR-069] The Broadband Forum, "CPE WAN Management Protocol", 1188 December 2018, . 1191 [TS.24008] 1192 3GPP, "Mobile radio interface Layer 3 specification; Core 1193 network protocols; Stage 3 (Release 16)", December 2019, 1194 . 1196 Appendix A. Sample Target Deployment Scenarios 1198 Internet Service Providers (ISPs) traditionally provide DNS resolvers 1199 to their customers. To that aim, ISPs deploy the following 1200 mechanisms to advertise a list of DNS Recursive DNS server(s) to 1201 their customers: 1203 o Protocol Configuration Options in cellular networks [TS.24008]. 1205 o DHCPv4 [RFC2132] (Domain Name Server Option) or DHCPv6 1206 [RFC8415][RFC3646] (OPTION_DNS_SERVERS). 1208 o IPv6 Router Advertisement [RFC4861][RFC8106] (Type 25 (Recursive 1209 DNS Server Option)). 1211 The communication between a customer's device (possibly via Customer 1212 Premises Equipment (CPE)) and an ISP-supplied DNS resolver takes 1213 place by using cleartext DNS messages (Do53). Some examples are 1214 depicted in Figure 13. In the case of cellular networks, the 1215 cellular network will provide connectivity directly to a host (e.g., 1216 smartphone, tablet) or via a CPE. Do53 mechanisms used within the 1217 Local Area Network (LAN) are similar in both fixed and cellular CPE- 1218 based broadband service offerings. 1220 (a) Fixed Networks 1221 ,--,--,--. 1222 +-+ LAN +---+ ,-' `-. 1223 |H+--------------+CPE+---+ ISP ) 1224 +-+ +---+ `-. ,-' 1225 | `--'--'--' 1226 | | 1227 |<=============Do53============>| 1228 | | 1230 (b) Cellular Networks 1232 | | 1233 |<=============Do53============>| 1234 | | 1235 | ,--,--,-. 1236 +-+ LAN +---+ ,-' . 1237 |H+--------------+CPE+---+ \ 1238 +-+ +---+ ,' ISP `-. 1239 ( ) 1240 +-----+-. ,-' 1241 +-+ | `--'--'--' 1242 |H+----------------+ | 1243 +-+ | 1244 | | 1245 |<=============Do53============>| 1246 | | 1248 Legend: 1249 * H: refers to a host. 1251 Figure 13: Sample Legacy Deployments 1253 A.1. Managed CPEs 1255 This section focuses on CPEs that are managed by ISPs. 1257 A.1.1. Direct DNS 1259 ISPs have developed an expertise in managing service-specific 1260 configuration information (e.g., CPE WAN Management Protocol 1261 [TR-069]). For example, these tools may be used to provision the DNS 1262 server's ADN to managed CPEs if an encrypted DNS is supported by a 1263 local network similar to what is depicted in Figure 14. 1265 For example, DoH-capable (or DoT) clients establish the DoH (or DoT) 1266 session with the discovered DoH (or DoT) server. 1268 The DNS client discovers whether the DNS server in the local network 1269 supports DoH/DoT/DoQ by using a dedicated field in the discovery 1270 message: Encrypted DNS Types (Sections 4, 5, and 6) . 1272 (a) Fixed Networks 1274 ,--,--,--. 1275 +-+ LAN +---+ ,-' `-. 1276 |H+--------------+CPE+---+ ISP ) 1277 +-+ +---+ `-. ,-' 1278 | `--'--'--' 1279 | | 1280 |<========Encrypted DNS========>| 1281 | | 1283 (b) Cellular Networks 1285 | | 1286 |<========Encrypted DNS========>| 1287 | | 1288 | ,--,--,-. 1289 +-+ LAN +---+ ,-' . 1290 |H+--------------+CPE+---+ \ 1291 +-+ +---+ ,' ISP `-. 1292 ( ) 1293 +-----+-. ,-' 1294 +-+ | `--'--'--' 1295 |H+----------------+ | 1296 +-+ | 1297 | | 1298 |<========Encrypted DNS========>| 1299 | | 1301 Figure 14: Encrypted DNS in the WAN 1303 Figure 14 shows the scenario where the CPE relays the list of 1304 encrypted DNS servers it learns for the network by using mechanisms 1305 like DHCP or a specific Router Advertisement message. In such 1306 context, direct encrypted DNS sessions will be established between a 1307 host serviced by a CPE and an ISP-supplied encrypted DNS server (see 1308 the example depicted in Figure 15 for a DoH/DoT-capable host). 1310 ,--,--,--. ,--,--,--. 1311 ,-' `-. ,-' ISP `-. 1312 Host---( LAN CPE----( DNS Server ) 1313 | `-. ,-' `-. ,-' 1314 | `--'--'--' `--'--'--' 1315 | | 1316 |<=========Encrypted DNS===========>| 1318 Figure 15: Direct Encrypted DNS Sessions 1320 A.1.2. Proxied DNS 1322 Figure 16 shows a deployment where the CPE embeds a caching DNS 1323 forwarder. The CPE advertises itself as the default DNS server to 1324 the hosts it serves. The CPE relies upon DHCP or RA to advertise 1325 itself to internal hosts as the default DoT/DoH/Do53 server. When 1326 receiving a DNS request it cannot handle locally, the CPE forwards 1327 the request to an upstream DoH/DoT/Do53 resolver. Such deployment is 1328 required for IPv4 service continuity purposes (e.g., Section 5.4.1 of 1329 [I-D.ietf-v6ops-rfc7084-bis]) or for supporting advanced services 1330 within a local network (e.g., malware filtering, parental control, 1331 Manufacturer Usage Description (MUD) [RFC8520] to only allow intended 1332 communications to and from an IoT device). When the CPE behaves as a 1333 DNS forwarder, DNS communications can be decomposed into two legs: 1335 o The leg between an internal host and the CPE. 1337 o The leg between the CPE and an upstream DNS resolver. 1339 An ISP that offers encrypted DNS to its customers may enable 1340 encrypted DNS in one or both legs as shown in Figure 16. Additional 1341 considerations related to this deployment are discussed in Section 8. 1343 (a) 1344 ,--,--,--. ,--,--,--. 1345 ,-' `-. ,-' ISP `-. 1346 Host---( LAN CPE----( DNS Server ) 1347 | `-. ,-'| `-. ,-' 1348 | `--'--'--' | `--'--'--' 1349 | | | 1350 |<=====Encrypted=====>|<=Encrypted=>| 1351 | DNS | DNS | 1353 (b) 1354 ,--,--,--. ,--,--,--. 1355 Legacy ,-' `-. ,-' ISP `-. 1356 Host---( LAN CPE----( DNS Server ) 1357 | `-. ,-'| `-. ,-' 1358 | `--'--'--' | `--'--'--' 1359 | | | 1360 |<=======Do53========>|<=Encrypted=>| 1361 | | DNS | 1363 Figure 16: Proxied Encrypted DNS Sessions 1365 A.2. Unmanaged CPEs 1367 A.2.1. ISP-facing Unmanaged CPEs 1369 Customers may decide to deploy unmanaged CPEs (assuming the CPE is 1370 compliant with the network access technical specification that is 1371 usually published by ISPs). Upon attachment to the network, an 1372 unmanaged CPE receives from the network its service configuration 1373 (including the DNS information) by means of, e.g., DHCP. That DNS 1374 information is shared within the LAN following the same mechanisms as 1375 those discussed in Appendix A.1. A host can thus establish DoH/DoT 1376 session with a DoH/DoT server similar to what is depicted in 1377 Figure 15 or Figure 16. 1379 A.2.2. Internal Unmanaged CPEs 1381 Customers may also decide to deploy internal routers (called 1382 hereafter, Internal CPEs) for a variety of reasons that are not 1383 detailed here. Absent any explicit configuration on the internal CPE 1384 to override the DNS configuration it receives from the ISP-supplied 1385 CPE, an Internal CPE relays the DNS information it receives via DHCP/ 1386 RA from the ISP-supplied CPE to connected hosts. Encrypted DNS 1387 sessions can be established by a host with the DNS servers of the ISP 1388 (see Figure 17). 1390 ,--,--,--. ,--,--,--. 1391 ,-' Internal ,-' ISP `-. 1392 Host--( Network#A CPE----CPE---( DNS Server ) 1393 | `-. ,-' `-. ,-' 1394 | `--'--'--' `--'--'--' 1395 | | 1396 |<==============Encrypted DNS=============>| 1398 Figure 17: Direct Encrypted DNS Sessions with the ISP DNS Resolver 1399 (Internal CPE) 1401 Similar to managed CPEs, a user may modify the default DNS 1402 configuration of an unmanaged CPE to use his/her favorite DNS servers 1403 instead. Encrypted DNS sessions can be established directly between 1404 a host and a 3rd Party DNS server (see Figure 18). 1406 ,--,--,--. ,--, 1407 ,' Internal ,-' '- 3rd Party 1408 Host--( Network#A CPE----CPE---( ISP )--- DNS Server 1409 | `. ,-' `-. -' | 1410 | `-'--'--' `--' | 1411 | | 1412 |<=================Encrypted DNS==================>| 1414 Figure 18: Direct Encrypted DNS Sessions with a Third Party DNS 1415 Resolver 1417 Section 8.2 discusses considerations related to hosting a forwarder 1418 in the Internal CPE. 1420 Appendix B. Make Use of Discovered Encrypted DNS Servers 1422 Even if the use of a discovered encrypted DNS server is beyond the 1423 discovery process and falls under encrypted server selection, the 1424 following discusses typical conditions under which discovered 1425 encrypted DNS server can be used. 1427 o If the DNS server's IP address discovered by using DHCP/RA is 1428 preconfigured in the OS or Browser as a verified resolver (e.g., 1429 part of an auto-upgrade program such as [Auto-upgrade]), the DNS 1430 client auto-upgrades to use the preconfigured encrypted DNS server 1431 tied to the discovered DNS server IP address. In such a case the 1432 DNS client will perform additional checks out of band, such as 1433 confirming that the Do53 IP address and the encrypted DNS server 1434 are owned and operated by the same organisation. 1436 o Similarly, if the ADN conveyed in DHCP/RA (Sections 4, 5, and 6) 1437 is preconfigured in the OS or browser as a verified resolver, the 1438 DNS client auto-upgrades to establish an encrypted a DoH/DoT/DoQ 1439 session with the ADN. 1441 In such case, the DNS client matches the domain name in the 1442 Encrypted DNS DHCP/RA option with the 'DNS-ID' identifier type 1443 within subjectAltName entry in the server certificate conveyed in 1444 the TLS handshake. 1446 Authors' Addresses 1448 Mohamed Boucadair 1449 Orange 1450 Rennes 35000 1451 France 1453 Email: mohamed.boucadair@orange.com 1455 Tirumaleswar Reddy 1456 McAfee, Inc. 1457 Embassy Golf Link Business Park 1458 Bangalore, Karnataka 560071 1459 India 1461 Email: TirumaleswarReddy_Konda@McAfee.com 1463 Dan Wing 1464 Citrix Systems, Inc. 1465 USA 1467 Email: dwing-ietf@fuggles.com 1469 Neil Cook 1470 Open-Xchange 1471 UK 1473 Email: neil.cook@noware.co.uk 1475 Tommy Jensen 1476 Microsoft 1477 USA 1479 Email: tojens@microsoft.com