idnits 2.17.00 (12 Aug 2021) /tmp/idnits39251/draft-boucadair-add-deployment-considerations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 17, 2021) is 362 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-add-dnr-00 == Outdated reference: A later version (-06) exists of draft-ietf-add-ddr-00 == Outdated reference: draft-ietf-dprive-dnsoquic has been published as RFC 9250 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADD M. Boucadair, Ed. 3 Internet-Draft Orange 4 Intended status: Informational T. Reddy, Ed. 5 Expires: November 18, 2021 McAfee 6 D. Wing 7 Citrix 8 N. Cook 9 Open-Xchange 10 T. Jensen 11 Microsoft 12 May 17, 2021 14 Discovery of Encrypted DNS Resolvers: Deployment Considerations 15 draft-boucadair-add-deployment-considerations-00 17 Abstract 19 The document discusses some deployment considerations of the various 20 options to discover encrypted DNS servers (e.g., DNS-over-HTTPS, DNS- 21 over-TLS, DNS-over-QUIC). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 18, 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Sample Target Deployment Scenarios . . . . . . . . . . . . . 3 60 3.1. Managed CPEs . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1.1. Direct DNS . . . . . . . . . . . . . . . . . . . . . 5 62 3.1.2. Proxied DNS . . . . . . . . . . . . . . . . . . . . . 6 63 3.2. Unmanaged CPEs . . . . . . . . . . . . . . . . . . . . . 7 64 3.2.1. ISP-facing Unmanaged CPEs . . . . . . . . . . . . . . 7 65 3.2.2. Internal Unmanaged CPEs . . . . . . . . . . . . . . . 7 66 4. Hosting Encrypted DNS Forwarder in Local Networks . . . . . . 8 67 4.1. Managed CPEs . . . . . . . . . . . . . . . . . . . . . . 8 68 4.1.1. DNS Forwarders . . . . . . . . . . . . . . . . . . . 8 69 4.1.2. ACME . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.2. Unmanaged CPEs . . . . . . . . . . . . . . . . . . . . . 9 71 5. Legacy CPEs . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 9.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 [I-D.ietf-add-dnr] specifies how a local encrypted DNS server can be 83 discovered by connected hosts by means of DHCP [RFC2132], DHCPv6 84 [RFC8415], and IPv6 Router Advertisement (RA) [RFC4861] options. 85 These options are designed to convey the following information: the 86 DNS Authentication Domain Name (ADN), a list of IP addresses, and a 87 set of service parameters. 89 This document discusses deployment considerations for the discovery 90 of encrypted DNS servers such as DNS-over-HTTPS (DoH) [RFC8484], DNS- 91 over-TLS (DoT) [RFC7858], or DNS-over-QUIC (DoQ) 92 [I-D.ietf-dprive-dnsoquic] in local networks. 94 Sample target deployment scenarios are discussed in Section 3; both 95 managed and unmanaged Customer Premises Equipment (CPEs) are covered. 97 It is out of the scope of this document to provide an exhaustive 98 inventory of deployments where Encrypted DNS options can be used. 100 Considerations related to hosting a DNS forwarder in a local network 101 are described in Section 4. 103 2. Terminology 105 This document makes use of the terms defined in [RFC8499]. The 106 following additional terms are used: 108 Do53: refers to unencrypted DNS. 110 Encrypted DNS: refers to a scheme where DNS exchanges are 111 transported over an encrypted channel. Examples of encrypted DNS 112 are DNS-over-TLS (DoT) [RFC7858], DNS-over-HTTPS (DoH) [RFC8484], 113 or DNS-over-QUIC (DoQ) [I-D.ietf-dprive-dnsoquic]. 115 Encrypted DNS options: refers to the options defined in 116 [I-D.ietf-add-dnr]. 118 Managed CPE: refers to a CPE that is managed by an Internet Service 119 Provider (ISP). 121 Unmanaged CPE: refers to a CPE that is not managed by an ISP. 123 DHCP: refers to both DHCPv4 and DHCPv6. 125 3. Sample Target Deployment Scenarios 127 ISPs traditionally provide DNS resolvers to their customers. To that 128 aim, ISPs deploy the following mechanisms to advertise a list of DNS 129 Recursive DNS server(s) to their customers: 131 o Protocol Configuration Options in cellular networks [TS.24008]. 133 o DHCPv4 [RFC2132] (Domain Name Server Option) or DHCPv6 134 [RFC8415][RFC3646] (OPTION_DNS_SERVERS). 136 o IPv6 Router Advertisement [RFC4861][RFC8106] (Type 25 (Recursive 137 DNS Server Option)). 139 The communication between a customer's device (possibly via Customer 140 Premises Equipment (CPE)) and an ISP-supplied DNS resolver takes 141 place by using cleartext DNS messages (Do53). Some examples are 142 depicted in Figure 1. In the case of cellular networks, the cellular 143 network will provide connectivity directly to a host (e.g., 144 smartphone, tablet) or via a CPE. Do53 mechanisms used within the 145 Local Area Network (LAN) are similar in both fixed and cellular CPE- 146 based broadband service offerings. 148 Some ISPs rely upon external resolvers (e.g., outsourced service or 149 public resolvers); these ISPs provide their customers with the IP 150 addresses of these resolvers. These addresses are typically 151 configured on CPEs using dedicated management tools. Likewise, users 152 can modify the default DNS configuration of their CPEs (e.g., 153 supplied by their ISP) to configure their favorite DNS servers. This 154 document permits such deployments. 156 (a) Fixed Networks 157 ,--,--,--. 158 +-+ LAN +---+ ,-' `-. 159 |H+--------------+CPE+---+ ISP ) 160 +-+ +---+ `-. ,-' 161 | `--'--'--' 162 | | 163 |<=============Do53============>| 164 | | 166 (b) Cellular Networks 168 | | 169 |<=============Do53============>| 170 | | 171 | ,--,--,-. 172 +-+ LAN +---+ ,-' . 173 |H+--------------+CPE+---+ \ 174 +-+ +---+ ,' ISP `-. 175 ( ) 176 +-----+-. ,-' 177 +-+ | `--'--'--' 178 |H+----------------+ | 179 +-+ | 180 | | 181 |<=============Do53============>| 182 | | 184 Legend: 185 * H: refers to a host. 187 Figure 1: Sample Legacy Deployments 189 3.1. Managed CPEs 191 This section focuses on CPEs that are managed by ISPs. 193 3.1.1. Direct DNS 195 ISPs have developed an expertise in managing service-specific 196 configuration information (e.g., CPE WAN Management Protocol 197 [TR-069]). For example, these tools may be used to provision the DNS 198 server's ADN to managed CPEs if an encrypted DNS is supported by a 199 local network similar to what is depicted in Figure 2. 201 For example, DoH-capable (or DoT) clients establish the DoH (or DoT) 202 session with the discovered DoH (or DoT) server. 204 The DNS client discovers whether the DNS server in the local network 205 supports DoH/DoT/DoQ by using the service paramters (ALPN). 207 (a) Fixed Networks 209 ,--,--,--. 210 +-+ LAN +---+ ,-' `-. 211 |H+--------------+CPE+---+ ISP ) 212 +-+ +---+ `-. ,-' 213 | `--'--'--' 214 | | 215 |<========Encrypted DNS========>| 216 | | 218 (b) Cellular Networks 220 | | 221 |<========Encrypted DNS========>| 222 | | 223 | ,--,--,-. 224 +-+ LAN +---+ ,-' . 225 |H+--------------+CPE+---+ \ 226 +-+ +---+ ,' ISP `-. 227 ( ) 228 +-----+-. ,-' 229 +-+ | `--'--'--' 230 |H+----------------+ | 231 +-+ | 232 | | 233 |<========Encrypted DNS========>| 234 | | 236 Figure 2: Encrypted DNS in the WAN 238 Figure 2 shows the scenario where the CPE relays the list of 239 encrypted DNS servers it learns for the network by using mechanisms 240 like DHCP or a specific Router Advertisement message. In such 241 context, direct encrypted DNS sessions will be established between a 242 host serviced by a CPE and an ISP-supplied encrypted DNS server (see 243 the example depicted in Figure 3 for a DoH/DoT-capable host). 245 ,--,--,--. ,--,--,--. 246 ,-' `-. ,-' ISP `-. 247 Host---( LAN CPE----( DNS Server ) 248 | `-. ,-' `-. ,-' 249 | `--'--'--' `--'--'--' 250 | | 251 |<=========Encrypted DNS===========>| 253 Figure 3: Direct Encrypted DNS Sessions 255 3.1.2. Proxied DNS 257 Figure 4 shows a deployment where the CPE embeds a caching DNS 258 forwarder. The CPE advertises itself as the default DNS server to 259 the hosts it serves. The CPE relies upon DHCP or RA to advertise 260 itself to internal hosts as the default DoT/DoH/Do53 server. When 261 receiving a DNS request it cannot handle locally, the CPE forwards 262 the request to an upstream DoH/DoT/Do53 resolver. Such deployment is 263 required for IPv4 service continuity purposes (e.g., Section 5.4.1 of 264 [I-D.ietf-v6ops-rfc7084-bis]) or for supporting advanced services 265 within a local network (e.g., malware filtering, parental control, 266 Manufacturer Usage Description (MUD) [RFC8520] to only allow intended 267 communications to and from an IoT device). When the CPE behaves as a 268 DNS forwarder, DNS communications can be decomposed into two legs: 270 o The leg between an internal host and the CPE. 272 o The leg between the CPE and an upstream DNS resolver. 274 An ISP that offers encrypted DNS to its customers may enable 275 encrypted DNS in one or both legs as shown in Figure 4. Additional 276 considerations related to this deployment are discussed in Section 4. 278 (a) 279 ,--,--,--. ,--,--,--. 280 ,-' `-. ,-' ISP `-. 281 Host---( LAN CPE----( DNS Server ) 282 | `-. ,-'| `-. ,-' 283 | `--'--'--' | `--'--'--' 284 | | | 285 |<=====Encrypted=====>|<=Encrypted=>| 286 | DNS | DNS | 288 (b) 289 ,--,--,--. ,--,--,--. 290 Legacy ,-' `-. ,-' ISP `-. 291 Host---( LAN CPE----( DNS Server ) 292 | `-. ,-'| `-. ,-' 293 | `--'--'--' | `--'--'--' 294 | | | 295 |<=======Do53========>|<=Encrypted=>| 296 | | DNS | 298 Figure 4: Proxied Encrypted DNS Sessions 300 3.2. Unmanaged CPEs 302 3.2.1. ISP-facing Unmanaged CPEs 304 Customers may decide to deploy unmanaged CPEs (assuming the CPE is 305 compliant with the network access technical specification that is 306 usually published by ISPs). Upon attachment to the network, an 307 unmanaged CPE receives from the network its service configuration 308 (including the DNS information) by means of, e.g., DHCP. That DNS 309 information is shared within the LAN following the same mechanisms as 310 those discussed in Section 3.1. A host can thus establish DoH/DoT 311 session with a DoH/DoT server similar to what is depicted in Figure 3 312 or Figure 4. 314 3.2.2. Internal Unmanaged CPEs 316 Customers may also decide to deploy internal routers (called 317 hereafter, Internal CPEs) for a variety of reasons that are not 318 detailed here. Absent any explicit configuration on the internal CPE 319 to override the DNS configuration it receives from the ISP-supplied 320 CPE, an Internal CPE relays the DNS information it receives via DHCP/ 321 RA from the ISP-supplied CPE to connected hosts. Encrypted DNS 322 sessions can be established by a host with the DNS servers of the ISP 323 (see Figure 5). 325 ,--,--,--. ,--,--,--. 326 ,-' Internal ,-' ISP `-. 327 Host--( Network#A CPE----CPE---( DNS Server ) 328 | `-. ,-' `-. ,-' 329 | `--'--'--' `--'--'--' 330 | | 331 |<==============Encrypted DNS=============>| 333 Figure 5: Direct Encrypted DNS Sessions with the ISP DNS Resolver 334 (Internal CPE) 336 Similar to managed CPEs, a user may modify the default DNS 337 configuration of an unmanaged CPE to use his/her favorite DNS servers 338 instead. Encrypted DNS sessions can be established directly between 339 a host and a 3rd Party DNS server (see Figure 6). 341 ,--,--,--. ,--, 342 ,' Internal ,-' '- 3rd Party 343 Host--( Network#A CPE----CPE---( ISP )--- DNS Server 344 | `. ,-' `-. -' | 345 | `-'--'--' `--' | 346 | | 347 |<=================Encrypted DNS==================>| 349 Figure 6: Direct Encrypted DNS Sessions with a Third Party DNS 350 Resolver 352 Section 4.2 discusses considerations related to hosting a forwarder 353 in the Internal CPE. 355 4. Hosting Encrypted DNS Forwarder in Local Networks 357 This section discusses some deployment considerations to host an 358 encrypted DNS forwarder within a local network. 360 4.1. Managed CPEs 362 The section discusses mechanisms that can be used to host an 363 encrypted DNS forwarder in a managed CPE (Section 3.1). 365 4.1.1. DNS Forwarders 367 The managed CPE should support a configuration parameter to instruct 368 the CPE whether it has to relay the encrypted DNS server received 369 from the ISP's network or has to announce itself as a forwarder 370 within the local network. The default behavior of the CPE is to 371 supply the encrypted DNS server received from the ISP's network. 373 4.1.2. ACME 375 The ISP can assign a unique FQDN (e.g., "cpe1.example.com") and a 376 domain-validated public certificate to the encrypted DNS forwarder 377 hosted on the CPE. Automatic Certificate Management Environment 378 (ACME) [RFC8555] can be used by the ISP to automate certificate 379 management functions such as domain validation procedure, certificate 380 issuance and certificate revocation. 382 4.2. Unmanaged CPEs 384 The approach specified in Section 4.1 does not apply for hosting a 385 DNS forwarder in an unmanaged CPE. 387 The unmanaged CPE administrator can host an encrypted DNS forwarder 388 on the unmanaged CPE. This assumes the following: 390 o The encrypted DNS server certificate is managed by the entity in- 391 charge of hosting the encrypted DNS forwarder. 393 Alternatively, a security service provider can assign a unique 394 FQDN to the CPE. The encrypted DNS forwarder will act like a 395 private encrypted DNS server only be accessible from within the 396 local network. 398 o The encrypted DNS forwarder will either be configured to use the 399 ISP's or a 3rd party encrypted DNS server. 401 o The unmanaged CPE will advertise the encrypted DNS forwarder ADN 402 using DHCP/RA to internal hosts. 404 Figure 7 illustrates an example of an unmanaged CPE hosting a 405 forwarder which connects to a 3rd party encrypted DNS server. In 406 this example, the DNS information received from the managed CPE (and 407 therefore from the ISP) is ignored by the Internal CPE hosting the 408 forwarder. 410 ,--,--,--. ,--, 411 ,' Internal Managed ,-' '- 3rd Party 412 Host--( Network#A CPE--------CPE------( ISP )--- DNS Server 413 | `. ,-'| | `-. -' | 414 | `-'--'--' | |<==DHCP==>|`--' | 415 | |<==DHCP==>| | | 416 |<======DHCP=======>| | | 417 | {RI, @i} | | 418 |<==Encrypted DNS==>|<==========Encrypted DNS==========>| 420 Legend: 421 * @i: IP address of the DNS forwarder hosted in the Internal 422 CPE. 424 Figure 7: Example of an Internal CPE Hosting a Forwarder 426 5. Legacy CPEs 428 Hosts serviced by legacy CPEs that can't be upgraded to support the 429 options defined in Sections 4, 5, and 6 of [I-D.ietf-add-dnr] won't 430 be able to learn the encrypted DNS server hosted by the ISP, in 431 particular. If the ADN is not discovered using DHCP/RA, such hosts 432 will have to fallback to use discovery using the resolver IP address 433 as defined in Section 4 of [I-D.ietf-add-ddr] to discover the 434 designated resolvers. 436 The guidance in Sections 4.1 and 4.2 of [I-D.ietf-add-ddr] related to 437 the designated resolver verification has to be followed in such case. 439 6. Security Considerations 441 DNR-related security considerations are discussed in Section 7 of 442 [I-D.ietf-add-dnr]. 444 7. IANA Considerations 446 This document does not require any IANA action. 448 8. Acknowledgements 450 This text was initially part of [I-D.ietf-add-dnr]. 452 9. References 453 9.1. Normative References 455 [I-D.ietf-add-dnr] 456 Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. 457 Jensen, "DHCP and Router Advertisement Options for the 458 Discovery of Network-designated Resolvers (DNR)", draft- 459 ietf-add-dnr-00 (work in progress), February 2021. 461 9.2. Informative References 463 [I-D.ietf-add-ddr] 464 Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. 465 Jensen, "Discovery of Designated Resolvers", draft-ietf- 466 add-ddr-00 (work in progress), February 2021. 468 [I-D.ietf-dprive-dnsoquic] 469 Huitema, C., Mankin, A., and S. Dickinson, "Specification 470 of DNS over Dedicated QUIC Connections", draft-ietf- 471 dprive-dnsoquic-02 (work in progress), February 2021. 473 [I-D.ietf-v6ops-rfc7084-bis] 474 Martinez, J. P., "Basic Requirements for IPv6 Customer 475 Edge Routers", draft-ietf-v6ops-rfc7084-bis-04 (work in 476 progress), June 2017. 478 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 479 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 480 . 482 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 483 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 484 DOI 10.17487/RFC3646, December 2003, 485 . 487 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 488 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 489 DOI 10.17487/RFC4861, September 2007, 490 . 492 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 493 and P. Hoffman, "Specification for DNS over Transport 494 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 495 2016, . 497 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 498 "IPv6 Router Advertisement Options for DNS Configuration", 499 RFC 8106, DOI 10.17487/RFC8106, March 2017, 500 . 502 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 503 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 504 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 505 RFC 8415, DOI 10.17487/RFC8415, November 2018, 506 . 508 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 509 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 510 . 512 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 513 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 514 January 2019, . 516 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 517 Description Specification", RFC 8520, 518 DOI 10.17487/RFC8520, March 2019, 519 . 521 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 522 Kasten, "Automatic Certificate Management Environment 523 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 524 . 526 [TR-069] The Broadband Forum, "CPE WAN Management Protocol", 527 December 2018, . 530 [TS.24008] 531 3GPP, "Mobile radio interface Layer 3 specification; Core 532 network protocols; Stage 3 (Release 16)", December 2019, 533 . 535 Authors' Addresses 537 Mohamed Boucadair (editor) 538 Orange 539 Rennes 35000 540 France 542 Email: mohamed.boucadair@orange.com 543 Tirumaleswar Reddy (editor) 544 McAfee, Inc. 545 Embassy Golf Link Business Park 546 Bangalore, Karnataka 560071 547 India 549 Email: TirumaleswarReddy_Konda@McAfee.com 551 Dan Wing 552 Citrix Systems, Inc. 553 USA 555 Email: dwing-ietf@fuggles.com 557 Neil Cook 558 Open-Xchange 559 UK 561 Email: neil.cook@noware.co.uk 563 Tommy Jensen 564 Microsoft 565 USA 567 Email: tojens@microsoft.com