idnits 2.17.1 draft-box-add-requirements-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 4, 2020) is 1330 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-capport-architecture-09 == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-00 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 C. Box 3 Internet-Draft BT 4 Intended status: Informational T. Pauly 5 Expires: March 8, 2021 Apple 6 C.A. Wood 7 Cloudflare 8 T. Reddy 9 McAfee 10 September 4, 2020 12 Requirements for Adaptive DNS Discovery 13 draft-box-add-requirements-00 15 Abstract 17 Adaptive DNS Discovery is chartered to define mechanisms that allow 18 clients to discover and select encrypted DNS resolvers. This 19 document describes several use cases for discovering DNS resolvers 20 that support encrypted transports, and lists requirements that any 21 proposed discovery and selection mechanisms should address. 23 Discussion Venues 25 This note is to be removed before publishing as an RFC. 27 Source for this draft and an issue tracker can be found at 28 https://github.com/ietf-wg-add/draft-add-requirements. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 8, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Discovery of associated resolvers . . . . . . . . . . . . . . 4 67 3.1. Network-provisioned resolvers . . . . . . . . . . . . . . 5 68 3.1.1. Unencrypted forwarder . . . . . . . . . . . . . . . . 6 69 3.1.2. Encrypted forwarder . . . . . . . . . . . . . . . . . 6 70 3.2. Client-selected resolvers . . . . . . . . . . . . . . . . 7 71 3.3. VPN resolvers . . . . . . . . . . . . . . . . . . . . . . 7 72 4. Discovery of limited domain resolvers . . . . . . . . . . . . 8 73 4.1. Discover a mapping between a locally-hosted domain and a 74 resolver . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1.1. Encrypted resolvers for local or home content . . . . 9 76 4.1.2. Locally-cached content . . . . . . . . . . . . . . . 9 77 4.1.3. Private enterprise names . . . . . . . . . . . . . . 10 78 4.2. Encrypted resolvers for content providers . . . . . . . . 10 79 5. Privacy and security requirements . . . . . . . . . . . . . . 11 80 5.1. On opportunistic encryption . . . . . . . . . . . . . . . 12 81 5.2. Handling exceptions and failures . . . . . . . . . . . . 13 82 6. Requirements Summary . . . . . . . . . . . . . . . . . . . . 13 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 87 9.2. Informative References . . . . . . . . . . . . . . . . . 14 88 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 Several protocols for protecting DNS traffic with encrypted 94 transports have been defined, such as DNS-over-TLS (DoT) [RFC7858] 95 and DNS-over-HTTPS (DoH) [RFC8484]. Encrypted DNS can provide many 96 security and privacy benefits for network clients. 98 While it is possible for clients to hard-code encrypted DNS resolvers 99 to use, dynamic discovery and provisioning of encrypted resolvers can 100 expand the usefulness and applicability of encrypted DNS to many more 101 use cases. 103 The Adaptive DNS Discovery (ADD) Working Group is chartered to define 104 mechanisms that allow clients to automatically discover and select 105 encrypted DNS resolvers in a wide variety of network environments. 106 This document describes several use cases for discovering DNS 107 resolvers that support encrypted transports, and lists requirements 108 that any proposed discovery and selection mechanisms should address. 109 They can do this either by providing a solution, or by explicitly 110 stating why it is not in scope. 112 Use cases are described between Section 3 and Section 4.2. Each use 113 case contains a narrative and a set of requirements that apply in 114 that case. There are additional common requirements in Section 5. 115 Each requirement is identified as "Ra.b" where a is the group number 116 and b is the number within that group. Both a and b are integers 117 starting with 1. 119 A summary of all requirements in listed in Section 6. 121 1.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 2. Terminology 131 This document makes use of the following terms. 133 Encrypted DNS: DNS-over-HTTPS [RFC8484], DNS-over-TLS [RFC7858], or 134 any other encrypted DNS technology that the IETF may publish, such as 135 DNS-over-QUIC [I-D.ietf-dprive-dnsoquic]. 137 Associated resolver: A resolver operated by the same entity that 138 provides the resolver the client started with. See Section 3. 140 Equivalent associated resolver: An associated resolver that provides 141 DNS responses that are identical to the ones served by the original 142 unencrypted resolver. 144 Alternative associated resolver: An associated resolver that serves 145 different responses to some queries; see Section 3 for examples. 147 3. Discovery of associated resolvers 149 A client may begin with information about unencrypted resolvers from 150 the attached networks (Section 3.1), and/or unencrypted resolvers 151 known from configuration (Section 3.2). This information may be used 152 to then discover one or more associated encrypted resolvers. 154 Associated resolvers are defined as resolvers operated by the same 155 entity that provides the resolver the client started with. Such 156 associated resolvers may come in two forms: 158 1. Equivalent - these provide DNS responses that are identical to 159 the ones served by the unencrypted resolver. 161 2. Alternative - these serve different responses to some queries. 162 For example one entity may offer a set of encrypted resolvers 163 with different levels of filtering (none, just malware, or 164 malware & adult content), or different proximity (local or 165 central). 167 The client may wish to select an equivalent associated resolver, or 168 select one of the alternatives. 170 Designs for resolver upgrade mechanisms can either add new parameters 171 to existing provisioning mechanisms (for example, adding necessary 172 information to use DoT or DoH to options in DHCP, RAs, or IKEv2) or 173 else provide a way to communicate with a provisioned unencrypted DNS 174 resolver and discover the associated encrypted DNS resolvers. 176 +=============+==============================================+ 177 | Requirement | Description | 178 +=============+==============================================+ 179 | R1.1 | There must be a mechanism for a client to | 180 | | learn the set of encrypted resolvers that | 181 | | are associated with an unencrypted resolver. | 182 +-------------+----------------------------------------------+ 183 | R1.2 | Discovery must be possible even when the IP | 184 | | address of the encrypted resolver is only | 185 | | valid locally. | 186 +-------------+----------------------------------------------+ 188 Table 1 190 3.1. Network-provisioned resolvers 192 DNS servers are often provisioned by a network as part of DHCP 193 options [RFC2132], IPv6 Router Advertisement (RA) options [RFC8106], 194 Point-to-Point Protocol (PPP) [RFC1877], 3GPP Protocol Configuration 195 Options, or another mechanism. Historically this is usually one or 196 more DNS resolver IP addresses, to be used for traditional 197 unencrypted DNS. However it could also be a richer set of 198 information. 200 Using an encrypted and authenticated resolver that is associated to 201 the one provisioned by the network can provide several benefits that 202 are not possible if only unencrypted DNS is used: 204 * Prevent other devices on the network from observing client DNS 205 messages 207 * Verify that answers come from the selected DNS resolver 209 * Authenticate that the DNS resolver is the one provisioned by the 210 network 212 Frequently, network-provisioned resolvers are forwarders running on a 213 local router. The discovered encrypted resolvers in these cases may 214 either be local forwarders themselves, or an associated resolver that 215 is in the network (thus bypassing the router's DNS forwarder). 217 +=============+=====================+ 218 | Requirement | Description | 219 +=============+=====================+ 220 | R2.1 | Example requirement | 221 +-------------+---------------------+ 223 Table 2 225 3.1.1. Unencrypted forwarder 227 If the resolver announced by the network is a classic unencrypted 228 forwarder, it is frequently the case that such forwarders are 229 difficult to upgrade to support encrypted operation. In such cases 230 it is useful for the resolver provider to be able to declare which 231 encrypted resolvers they provide, and for the client to be able to 232 discover them. If the client wishes to, it can then use one of those 233 resolvers and bypass the local forwarder. 235 +=============+=====================+ 236 | Requirement | Description | 237 +=============+=====================+ 238 | R3.1 | Example requirement | 239 +-------------+---------------------+ 241 Table 3 243 3.1.2. Encrypted forwarder 245 If a subset of local resolvers supports encrypted DNS, the client may 246 not initially be aware that its local resolver supports it. 247 Discovering this may require communication with the local resolver, 248 or an upstream resolver, over an unencrypted transport. Once 249 discovered, the local encrypted forwarder may be selected by the 250 client, gaining the benefits of encryption while retaining the 251 benefits of a local caching forwarder with knowledge of the local 252 topology. 254 Another benefit occurs with IoT devices. A common usage pattern for 255 such devices is for it to "call home" to a service that resides on 256 the public Internet, where that service is referenced through a 257 domain name (A or AAAA record). As discussed in Manufacturer Usage 258 Description Specification [RFC8520], because these devices tend to 259 require access to very few sites, all other access should be 260 considered suspect. However, if the query is not accessible for 261 inspection, it becomes quite difficult for the infrastructure to 262 suspect anything. 264 +=============+=====================+ 265 | Requirement | Description | 266 +=============+=====================+ 267 | R4.1 | Example requirement | 268 +-------------+---------------------+ 270 Table 4 272 3.2. Client-selected resolvers 274 Client devices often allow the device administrator to select a 275 specific DNS resolver to use on certain networks, or on all networks. 276 Historically, this selection was specified only with an IP address. 278 Discovering which equivalent encrypted resolvers are offered by the 279 same entity allows the client to "upgrade" connections to use 280 encrypted DNS. This can provide several benefits: 282 * Prevent devices along the network path to the selected resolver 283 from observing client DNS messages 285 * Verify that answers come from the selected DNS resolver 287 * Authenticate that the DNS resolver is the one selected by the 288 client 290 In doing so it is critical that the new resolver is an equivalent 291 resolver. Switching to a non-equivalent alternative resolver would 292 break the expectation of the user who previously selected that 293 resolver. 295 +=============+=====================+ 296 | Requirement | Description | 297 +=============+=====================+ 298 | R5.1 | Example requirement | 299 +-------------+---------------------+ 301 Table 5 303 3.3. VPN resolvers 305 Virtual Private Networks (VPNs) also can provision DNS resolvers. In 306 addition to being able to use DHCP or RAs, VPNs can provision DNS 307 information in an explicit configuration message. For example, IKEv2 308 can provision DNS servers using Configuration Attributes [RFC7296]. 310 VPNs can also configure Split DNS rules to limit the use of the 311 configured resolvers to specific domain names [RFC8598]. 313 Discovering an encrypted resolver that is provisioned by a VPN can 314 provide the same benefits as doing so for a local network, but 315 applied to the private network. When using Split DNS, it becomes 316 possible to use one encrypted resolver for private domains, and 317 another for other domains. 319 +=============+=====================+ 320 | Requirement | Description | 321 +=============+=====================+ 322 | R6.1 | Example requirement | 323 +-------------+---------------------+ 325 Table 6 327 4. Discovery of limited domain resolvers 329 Similar to how VPN DNS configurations can use Split DNS for private 330 names, other network environments can support resolution of names 331 that are specific to the local environment. For example, an 332 enterprise-managed Wi-Fi network might be able to access both the 333 Internet and a private intranet. In such a scenario, the private 334 domains managed by the enterprise might only be resolvable using a 335 specific DNS resolver. 337 Discovering an encrypted resolver for a subset of names allows a 338 client to perform Split DNS while maintaining the benefits of 339 encrypted DNS. For example, a client could use a client-selected 340 encrypted resolver for public domains, but use a different encrypted 341 resolver for enterprise-private domains. 343 Such domain-specific resolver discovery mechanisms additionally need 344 to provide some information about the applicability and capabilities 345 of encrypted resolvers. This information can either be provisioned 346 or can be discovered based on clients actively trying to access 347 content. 349 +=============+=====================+ 350 | Requirement | Description | 351 +=============+=====================+ 352 | R7.1 | Example requirement | 353 +-------------+---------------------+ 355 Table 7 357 4.1. Discover a mapping between a locally-hosted domain and a resolver 359 Narrative required. 361 +=============+=====================+ 362 | Requirement | Description | 363 +=============+=====================+ 364 | R8.1 | Example requirement | 365 +-------------+---------------------+ 367 Table 8 369 4.1.1. Encrypted resolvers for local or home content 371 Accessing locally-hosted content can require the use of a specific 372 resolver. For example, captive networks or networks with walled- 373 garden content like media on airplane Wi-Fi networks can rely on 374 using a resolver hosted on the local network. 376 In cases where a client is using an encrypted resolver provisioned by 377 a network, and that encrypted resolver is able to resolve names of 378 local content, this can fall into the use case described in 379 Section 3.1. However, it might be necessary to discover a local 380 encrypted resolver along with specific domains if: 382 * the network-provisioned encrypted resolver is not able to resolve 383 local-only names, or 385 * the client has a more-preferred encrypted resolver for generic 386 traffic, and would otherwise not be able to access local content 388 The first point can occur in a hybrid deployment, e.g. when the local 389 resolver is unencrypted but a central one is encrypted. Clients 390 choosing the encrypted resolver for most queries will need to be 391 advised to refer to the local one for some names. 393 This case also include accessing content specific to a home network. 395 +=============+=====================+ 396 | Requirement | Description | 397 +=============+=====================+ 398 | R9.1 | Example requirement | 399 +-------------+---------------------+ 401 Table 9 403 4.1.2. Locally-cached content 405 Narrative required. 407 +=============+=====================+ 408 | Requirement | Description | 409 +=============+=====================+ 410 | R10.1 | Example requirement | 411 +-------------+---------------------+ 413 Table 10 415 4.1.3. Private enterprise names 417 As stated above, an enterprise-managed Wi-Fi network might be able to 418 access both the Internet and a private intranet. The private domains 419 managed by the enterprise might only be resolvable using a specific 420 DNS resolver, hence use of that resolver is essential for such 421 domains. However it does not necessarily mean that all queries for 422 all domains have to flow through that resolver. 424 Only sending the necessary queries through the enterprise resolver, 425 and not generic Internet queries, has the privacy benefit of only 426 exposing traffic to the enterprise that fall within a limited set of 427 domains. 429 Using encrypted DNS for private names also opens up the possibility 430 of doing private name resolution outside of the content of a VPN or 431 managed network. If the DNS resolver authenticates clients, it can 432 offer its resolver for private names on a publicly accessible server, 433 while still limiting the visibility of the DNS traffic. 435 +=============+=====================+ 436 | Requirement | Description | 437 +=============+=====================+ 438 | R11.1 | Example requirement | 439 +-------------+---------------------+ 441 Table 11 443 4.2. Encrypted resolvers for content providers 445 Content Delivery Networks (CDNs), and content-providers more broadly, 446 can also provide encrypted DNS resolvers that can be used by clients 447 over the public Internet. These resolvers can either allow 448 resolution of all public names (like normal recursive resolvers), or 449 be designed to serve a subset of names managed by the content 450 provider (like an authoritative resolver). Using these resolvers can 451 allow the content provider to directly control how DNS answers are 452 used for load balancing and address selection, which could improve 453 performance of connections to the content provider. 455 Using a content-provider's encrypted resolver can also provide 456 several privacy and security benefits: 458 * Prevent devices along the network path to the content-provider's 459 resolver from observing client DNS messages 461 * Verify that answers come from the entity that manages the domains 462 being resolved 464 * Reduce the number of entities able to monitor the specific names 465 accessed by a client to only the client and the content provider, 466 assuming that the content provider would already see the names 467 upon a secure connection later being made based on the DNS answers 468 (e.g., in the TLS SNI extension) 470 +=============+=====================+ 471 | Requirement | Description | 472 +=============+=====================+ 473 | R12.1 | Example requirement | 474 +-------------+---------------------+ 476 Table 12 478 5. Privacy and security requirements 480 Encrypted (and authenticated) DNS improves the privacy and security 481 of DNS queries and answers in the presence of malicious attackers. 482 Such attackers are assumed to interfere with or otherwise impede DNS 483 traffic and corresponding discovery mechanisms. They may be on-path 484 or off-path between the client and entities with which the client 485 communicates [RFC3552]. These attackers can inject, tamper, or 486 otherwise interfere with traffic as needed. Given these 487 capabilities, an attacker may have a variety of goals, including, 488 though not limited to: 490 * Monitor and profile clients by observing unencrypted DNS traffic 492 * Modify unencrypted DNS traffic to filter or augment the user 493 experience 495 * Block encrypted DNS 497 Clients cannot assume that their network does not have such an 498 attacker unless given some means of authenticating or otherwise 499 trusting the communication with their DNS resolver. 501 Given this type of attacker, resolver discovery mechanisms must be 502 designed carefully to not worsen a client's security or privacy 503 posture. In particular, attackers must not be able to: 505 * Redirect secure DNS traffic to themselves when they would not 506 otherwise handle DNS traffic. 508 * Override or interfere with the resolver preferences of a user or 509 administrator. 511 * Cause clients to use a discovered resolver which has no 512 authenticated delegation from a client-known entity. 514 * Influence automatic discovery mechanisms such that a client uses 515 one or more resolvers that are not otherwise involved with 516 providing service to the client, such as: a network provider, a 517 VPN server, a content provider being accessed, or a server that 518 the client has manually configured. 520 Beyond these requirements, standards describing resolver discovery 521 mechanisms must not place any requirements on clients to select 522 particular resolvers over others. 524 When discovering DNS resolvers on a local network, clients have no 525 mechanism to distinguish between cases where an active attacker with 526 the above capabilities is interfering with discovery, and situations 527 wherein the network has no encrypted resolver. Absent such a 528 mechanism, an attacker can always succeed in these goals. Therefore, 529 in such circumstances, viable solutions for local DNS resolver 530 discovery should consider weaker attackers, such as those with only 531 passive eavesdropping capabilities. It is unknown whether such 532 relaxations represent a realistic attacker in practice. Thus, local 533 discovery solutions designed around this threat model may have 534 limited value. 536 5.1. On opportunistic encryption 538 Opportunistic encrypted DNS, when the client cannot authenticate the 539 entity that provides encrypted DNS, does not meet the requirements 540 laid out here for resolver discovery. While opportunistic encryption 541 can provide some benefits, specifically in reducing the ability for 542 other entities to observe traffic, it is not a viable solution 543 against an on-path attacker. 545 Performing opportunistic encrypted DNS does not require specific 546 discovery mechanisms. Section 4.1 of [RFC7858] already describes how 547 to use DNS-over-TLS opportunistically. 549 5.2. Handling exceptions and failures 551 Even with encrypted DNS resolver discovery in place, clients must be 552 prepared to handle certain scenarios where encrypted DNS cannot be 553 used. In these scenarios, clients must consider if it is appropriate 554 to fail open by sending the DNS queries without encryption, fail 555 closed by not doing so, or presenting a choice to a user or 556 administrator. The exact behavior is a local client policy decision. 558 Some networks that use Captive Portals will not allow any Internet 559 connectivity until a client has interacted with the portal 560 [I-D.ietf-capport-architecture]. If these networks do not use 561 encrypted DNS for their own resolution, a client will need to perform 562 unencrypted DNS queries in order to get out of captivity. Many 563 operating systems have specific client code responsible for detecting 564 and interacting with Captive Portals; these system components may be 565 good candidates for failing open, since they do not generally 566 represent user traffic. 568 Other networks may not allow any use of encrypted DNS, or any use of 569 encrypted DNS to resolvers other than a network-provisioned resolver. 570 Clients should not silently fail open in these cases, but if these 571 networks are trusted by or administered by the user, the user may 572 want to specifically follow the network's DNS policy instead of what 573 the client would do on an unknown or untrusted network. 575 6. Requirements Summary 577 This sections lists the complete set of requirements described above, 578 for ease of reference. 580 +=============+=====================================================+ 581 | Requirement | Description | 582 +=============+=====================================================+ 583 | R1.1 | There must be a mechanism for a client | 584 | | to learn the set of encrypted resolvers | 585 | | that are associated with a resolver | 586 | | that is known only by its IP address. | 587 +-------------+-----------------------------------------------------+ 588 | R1.2 | Discovery must be possible even when | 589 | | the IP address is only valid locally. | 590 +-------------+-----------------------------------------------------+ 591 | R1.3 | More to be added | 592 +-------------+-----------------------------------------------------+ 593 | R2.1 | Example requirement | 594 +-------------+-----------------------------------------------------+ 595 | R3.1 | Example requirement | 596 +-------------+-----------------------------------------------------+ 598 Table 13 600 7. Security Considerations 602 All security considerations relevant to a particular use case are 603 described under that section. Additional considerations common to 604 all of them are described in Section 5. 606 8. IANA Considerations 608 This document has no IANA actions. 610 9. References 612 9.1. Normative References 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, 616 DOI 10.17487/RFC2119, March 1997, 617 . 619 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 620 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 621 May 2017, . 623 9.2. Informative References 625 [I-D.ietf-capport-architecture] 626 Larose, K., Dolson, D., and H. Liu, "Captive Portal 627 Architecture", Work in Progress, Internet-Draft, draft- 628 ietf-capport-architecture-09, August 8, 2020, 629 . 632 [I-D.ietf-dprive-dnsoquic] 633 Huitema, C., Mankin, A., and S. Dickinson, "Specification 634 of DNS over Dedicated QUIC Connections", Work in Progress, 635 Internet-Draft, draft-ietf-dprive-dnsoquic-00, April 27, 636 2020, . 639 [RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol 640 Extensions for Name Server Addresses", RFC 1877, 641 DOI 10.17487/RFC1877, December 1995, 642 . 644 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 645 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 646 . 648 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 649 Text on Security Considerations", BCP 72, RFC 3552, 650 DOI 10.17487/RFC3552, July 2003, 651 . 653 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 654 Kivinen, "Internet Key Exchange Protocol Version 2 655 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 656 2014, . 658 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 659 and P. Hoffman, "Specification for DNS over Transport 660 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 661 2016, . 663 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 664 "IPv6 Router Advertisement Options for DNS Configuration", 665 RFC 8106, DOI 10.17487/RFC8106, March 2017, 666 . 668 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 669 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 670 . 672 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 673 Description Specification", RFC 8520, 674 DOI 10.17487/RFC8520, March 2019, 675 . 677 [RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the 678 Internet Key Exchange Protocol Version 2 (IKEv2)", 679 RFC 8598, DOI 10.17487/RFC8598, May 2019, 680 . 682 Acknowledgments 684 This document was started based on contributions during the ADD 685 meeting of IETF108, on the list, and from draft-pauly-add- 686 requirements. 688 More contributions are required! Please consider starting a github 689 issue, submit a pull request, or simply raise the topic on the ADD 690 list. 692 Authors' Addresses 694 Chris Box 695 BT 696 2000 Park Avenue 697 Bristol 698 United Kingdom 700 Email: chris.box@bt.com 702 Tommy Pauly 703 Apple 704 One Apple Park Way 705 Cupertino, California 95014, 706 United States of America 708 Email: tpauly@apple.com 710 Christopher A. Wood 711 Cloudflare 712 101 Townsend St 713 San Francisco, 714 United States of America 716 Email: caw@heapingbits.net 717 Tirumaleswar Reddy 718 McAfee 719 Embassy Golf Link Business Park 720 Bangalore 721 India 723 Email: TirumaleswarReddy_Konda@McAfee.com