idnits 2.17.00 (12 Aug 2021) /tmp/idnits38579/draft-reddy-add-enterprise-split-dns-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 9 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (13 April 2022) is 31 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-add-dnr-06 == Outdated reference: A later version (-02) exists of draft-ietf-ipsecme-add-ike-01 -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADD T. Reddy 3 Internet-Draft Akamai 4 Intended status: Standards Track D. Wing 5 Expires: 15 October 2022 Citrix 6 K. Smith 7 Vodafone 8 B. Schwartz 9 Google 10 13 April 2022 12 Establishing Local DNS Authority in Split-Horizon Environments 13 draft-reddy-add-enterprise-split-dns-10 15 Abstract 17 When split-horizon DNS is deployed by a network, certain domains can 18 be resolved authoritatively by the network-provided DNS resolver. 19 DNS clients that don't always use this resolver might wish to do so 20 for these domains. This specification describes how clients can 21 confirm the local resolver's authority over these domains. 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 15 October 2022. 40 Copyright Notice 42 Copyright (c) 2022 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 (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Validated Split-Horizon . . . . . . . . . . . . . . . . . 4 59 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Local Domain Hint Mechanisms . . . . . . . . . . . . . . . . 4 61 4.1. DHCP Options . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. Host Configuration . . . . . . . . . . . . . . . . . . . 5 63 4.3. Provisioning Domains dnsZones . . . . . . . . . . . . . . 6 64 4.4. Split DNS Configuration for IKEv2 . . . . . . . . . . . . 6 65 5. Establishing Local DNS Authority . . . . . . . . . . . . . . 6 66 6. Validating Authority over Local Domain Hints . . . . . . . . 6 67 6.1. Using Pre-configured Public Resolver . . . . . . . . . . 7 68 6.2. Using DNSSEC . . . . . . . . . . . . . . . . . . . . . . 7 69 7. Examples of Split-Horizon DNS Configuration . . . . . . . . . 7 70 7.1. Split-Horizon Entire Zone . . . . . . . . . . . . . . . . 8 71 7.1.1. Verification using Public Resolver . . . . . . . . . 9 72 7.1.2. Verification using DNSSEC . . . . . . . . . . . . . . 10 73 7.2. Split-Horizon Only Subdomain of Zone . . . . . . . . . . 12 74 8. Validation with IKEv2 . . . . . . . . . . . . . . . . . . . . 12 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 80 12.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 To resolve a DNS query, there are three essential behaviors that an 86 implementation can apply: (1) answer from a local database, (2) query 87 the relevant authorities and their parents, or (3) ask a server to 88 query those authorities and return the final answer. Implementations 89 that use these behaviors are called "authoritative nameservers", 90 "full resolvers", and "forwarders" (or "stub resolvers"). However, 91 an implementation can also implement a mixture of these behaviors, 92 depending on a local policy, for each query. We term such an 93 implementation a "hybrid resolver". 95 Most DNS resolvers are hybrids of some kind. For example, stub 96 resolvers frequently support a local "hosts file" that preempts query 97 forwarding, and most DNS forwarders and full resolvers can also serve 98 responses from a local zone file. Other standardized hybrid 99 resolution behaviors include Local Root [RFC8806], mDNS [RFC6762], 100 and NXDOMAIN synthesis for .onion [RFC7686]. 102 In many network environments, the network offers clients a DNS server 103 (e.g. DHCP OFFER, IPv6 Router Advertisement). Although this server 104 is formally specified as a recursive resolver (e.g. Section 5.1 of 105 [RFC6106]), some networks provide a hybrid resolver instead. If this 106 resolver acts as an authoritative server for some names, we say that 107 the network has "split-horizon DNS", because those names resolve in 108 this way only from inside the network. 110 Network clients that use pure stub resolution, sending all queries to 111 the network-provided resolver, will always receive the split-horizon 112 results. Conversely, clients that send all queries to a different 113 resolver or implement pure full resolution locally will never receive 114 them. Clients with either pure resolution behavior are out of scope 115 for this specification. Instead, this specification enables hybrid 116 clients to access split-horizon results from a network-provided 117 hybrid resolver, while using a different resolution method for some 118 or all other names. 120 There are several existing mechanisms for a network to provide 121 clients with "local domain hints", listing domain names that have 122 special treatment in this network (Section 4). However, none of the 123 local domain hint mechanisms enable clients to determine whether this 124 special treatment is authorized by the domain owner. Instead, these 125 specifications require clients to make their own determinations about 126 whether to trust and rely on these hints. 128 This specification describes a protocol between domains, networks, 129 and clients that allows the network to establish its authority over a 130 domain to a client (Section 5). Clients can use this protocol to 131 confirm that a local domain hint was authorized by the domain 132 (Section 6), which might influence its processing of that hint. 134 This specification relies on securely identified local DNS servers 135 and globally valid NS records. Use of this specification is 136 therefore limited to servers that support authenticated encryption 137 and split-horizon DNS names that are properly rooted in the global 138 DNS. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119][RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 This document makes use of the terms defined in [RFC8499]. The term 149 "Global DNS" is defined in [RFC8499]. 151 'Encrypted DNS' refers to a DNS protocol that provides an encrypted 152 channel between a DNS client and server (e.g., DoT, DoH, or DoQ). 154 The term 'Validated Split-Horizon' is also defined. 156 2.1. Validated Split-Horizon 158 A split horizon configuration for some name is considered "validated" 159 if the network client has confirmed that a parent of that name has 160 authorized the local network to serve its own responses for that 161 name. Such authorization generally extends to the entire subtree of 162 names below the authorization point. 164 3. Scope 166 The protocol in this document allows the domain owner to create a 167 split-horizon DNS. Other entities which do not own the domain are 168 detected by the client. Thus, DNS filtering is not enabled by this 169 protocol. 171 4. Local Domain Hint Mechanisms 173 There are various mechanisms by which a network client might learn 174 "local domain hints", which indicate a special treatment for 175 particular domain names upon joining a network. This section 176 provides a review of some common and standardized mechanisms for 177 receiving domain hints. 179 4.1. DHCP Options 181 There are several DHCP options that convey local domain hints of 182 different kinds. The most directly relevant is "RDNSS Selection" 183 [RFC6731], which provides "a list of domains ... about which the 184 RDNSS has special knowledge", along with a "High", "Medium", or "Low" 185 preference for each name. The specification notes the difficulty of 186 relying on these hints without validation: 188 Trustworthiness of an interface and configuration information 189 received over the interface is implementation and/or node 190 deployment dependent, and the details of determining that trust 191 are beyond the scope of this specification. 193 Other local domain hints in DHCP include the "Domain Name" [RFC2132], 194 "Access Network Domain Name" [RFC5986], "Client FQDN" 195 [RFC4702][RFC4704], and "Name Service Search" [RFC2937] options. 196 This specification may help clients to interpret these hints. For 197 example, a rogue DHCP server could use the "Client FQDN" option to 198 assign a client the name "www.example.com" in order to prevent the 199 client from reaching the true "www.example.com". A client could use 200 this specification to check the network's authority over this name, 201 and adjust its behavior to avoid this attack if authority is not 202 established. 204 The Domain Search option [RFC3397] [RFC3646], which offers clients a 205 way to expand short names into Fully Qualified Domain Names, is not a 206 "local domain hint" by this definition, because it does not modify 207 the processing of any specific domain. (The specification notes that 208 this option can be a "fruitful avenue of attack for a rogue DHCP 209 server", and provides a number of cautions against accepting it 210 unconditionally.) 212 4.2. Host Configuration 214 A host can be configured with DNS information when it joins a 215 network, including when it brings up VPN (which is also considered 216 joining a(n additional) network, detailed in Section 8). Existing 217 implementations determine the host has joined a certain network via 218 SSID, IP subnet assigned, DNS server IP address or name, and other 219 similar mechanisms. For example, one existing implementation 220 determines the host has joined an internal network because the DHCP- 221 assigned IP address belongs to the company's IP address (as assigned 222 by the regional IP addressing authority) and the DHCP-advertised DNS 223 IP address is one used by IT at that network. Other mechanisms exist 224 in other products but are not interesting to this specification; 225 rather what is interesting is this step to determine "we have joined 226 the internal corporate network" occurred and the DNS server is 227 configured as authoritative for certain DNS zones (e.g., 228 *.example.com). 230 Because a rogue network can simulate all or most of the above 231 characteristics this specification details how to validate these 232 claims in Section 6. 234 4.3. Provisioning Domains dnsZones 236 Provisioning Domains (PvDs) are defined in [RFC7556] as sets of 237 network configuration information that clients can use to access 238 networks, including rules for DNS resolution and proxy configuration. 239 The PvD Key "dnsZones" is defined in [RFC8801] as a list of "DNS 240 zones searchable and accessible" in this provisioning domain. 241 Attempting to resolve these names via another resolver might fail or 242 return results that are not correct for this network. 244 4.4. Split DNS Configuration for IKEv2 246 In IKEv2 VPNs, the INTERNAL_DNS_DOMAIN configuration attribute can be 247 used to indicate that a domain is "internal" to the VPN [RFC8598]. 248 To prevent abuse, the specification notes various possible 249 restrictions on the use of this attribute: 251 "If a client is configured by local policy to only accept a 252 limited set of INTERNAL_DNS_DOMAIN values, the client MUST ignore 253 any other INTERNAL_DNS_DOMAIN values." 255 "IKE clients MAY want to require whitelisted domains for Top-Level 256 Domains (TLDs) and Second-Level Domains (SLDs) to further prevent 257 malicious DNS redirections for well-known domains." 259 Within these guidelines, a client could adopt a local policy of 260 accepting INTERNAL_DNS_DOMAIN values only when it can validate the 261 local DNS server's authority over those names as described in this 262 specification. 264 5. Establishing Local DNS Authority 266 To establish its authority over some DNS zone, a participating 267 network MUST offer one or more encrypted resolvers via DNR 268 [I-D.ietf-add-dnr] or an equivalent mechanism (see Section 8). At 269 least one of these resolvers' Authentication Domain Names (ADNs) MUST 270 appear in an NS record for that zone. This arrangement establishes 271 this resolver's authority over the zone. 273 6. Validating Authority over Local Domain Hints 275 To validate the network's authority over a domain name, participating 276 clients MUST resolve the NS record for that name. If the resolution 277 result is NODATA, the client MUST remove the last label and repeat 278 the query until a response other than NODATA is received. 280 Once the NS record has been resolved, the client MUST check if each 281 local encrypted resolver's Authentication Domain Name appears in the 282 NS record. The client SHALL regard each such resolver as 283 authoritative for the zone of this NS record. 285 Each validation of authority applies only to the specific resolvers 286 whose names appear in the NS RRSet. If a network offers multiple 287 encrypted resolvers, each DNS entry may be authorized for a distinct 288 subset of the network-provided resolvers. 290 A zone is termed a "Validated Split-Horizon zone" after successful 291 validation using a "tamperproof" NS resolution method, i.e. a method 292 that is not subject to interference by the local network operator. 293 Two possible tamperproof resolution methods are presented below. 295 6.1. Using Pre-configured Public Resolver 297 The client sends the NS query to a pre-configured resolver that is 298 external to the network, over a secure transport. Clients SHOULD 299 apply whatever acceptance rules they would otherwise apply when using 300 this resolver (e.g. checking the AD bit, validating RRSIGs). 302 6.2. Using DNSSEC 304 The client resolves the NS record using any resolution method of its 305 choice (e.g. querying one of the network-provided resolvers, 306 performing iterative resolution locally), and performs full DNSSEC 307 validation locally [RFC6698]. The result is processed based on its 308 DNSSEC validation state (Section 4.3 of [RFC4035]): 310 Secure: the response is used for validation. 312 Bogus or Indeterminate: the response is rejected and validation is 313 considered to have failed. 315 Insecure: the client SHOULD retry the validation process using a 316 different method, such as the one in Section 6.1, to ensure 317 compatibility with unsigned names. 319 7. Examples of Split-Horizon DNS Configuration 321 Two examples are shown below. The first example showing an company 322 with an internal-only DNS server resolving the entire zone for that 323 company (e.g., *.example.com) the second example resolving only a 324 subdomain of the company's zone (e.g., *.internal.example.com). 326 7.1. Split-Horizon Entire Zone 328 Consider an organization that operates "example.com", and runs a 329 different version of its global domain on its internal network. 330 Today, on the Internet it publishes two NS records, "ns1.example.com" 331 and "ns2.example.com". 333 The host and network first need mutual support one of the mechanisms 334 described in learning (Section 4). Shown in Figure 1 is learning 335 using DNR and PvD. 337 Validation is then perfomed using either Public DNS (Section 7.1.1) 338 or DNSSEC (Section 7.1.2). 340 steps 1-2: The client determines the network's DNS server 341 (ns1.example.com) and Provisioning Domain (pvd.example.com) using 342 DNR [I-D.ietf-add-dnr] and PvD [RFC8801], using one of DNR Router 343 Solicitation, DHCPv4, or DHCPv6. 345 step 3-5: The client connects to the DNR-learned DNS server 346 (ns1.example.com), validates its certificate, and queries for 347 pvd.example.com. 349 steps 6-7: The client connects to the PvD server, validates its 350 certificate, and retrieves the provisioning domain JSON 351 information indicated by the associated PvD. The PvD contains: 353 { 354 "identifier": "pvd.example.com", 355 "expires": "2020-05-23T06:00:00Z", 356 "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], 357 "dnsZones:": ["example.com"] 358 } 360 The JSON keys "identifier", "expires", and "prefixes" are defined 361 in [RFC8801]. 363 +---------+ +--------------------+ +------------+ +--------+ 364 | client | | Network | | Network | | Router | 365 | | | encrypted resolver | | PvD server | | | 366 +---------+ +--------------------+ +------------+ +--------+ 367 | | | | 368 | Router Solicitation or | | | 369 | DHCPv4/DHCPv6 (1) | | | 370 |----------------------------------------------------------->| 371 | | | | 372 | Response with DNR hostnames & | | | 373 | PvD FQDN (2) | | | 374 |<-----------------------------------------------------------| 375 | ----------------------------\ | | | 376 |-| now knows DNR hostnames & | | | | 377 | | PvD FQDN | | | | 378 | |---------------------------/ | | | 379 | | | | 380 | TLS connection to ns1.example.com (3) | | 381 |------------------------------------>| | | 382 | ---------------------------\ | | | 383 |-| validate TLS certificate | | | | 384 | |--------------------------| | | | 385 | | | | 386 | resolve pvd.example.com (4) | | | 387 |------------------------------------>| | | 388 | | | | 389 | A or AAAA records (5) | | | 390 |<------------------------------------| | | 391 | | | | 392 | https://pvd.example.com/.well-known/pvd (6) | | 393 |---------------------------------------------->| | 394 | | | | 395 | 200 OK (JSON Additional Information) (7) | | 396 |<----------------------------------------------| | 397 | -----------------------\ | | | 398 |-| dnsZones=example.com | | | | 399 | |----------------------| | | | 401 Figure 1: Learning Local Claims of DNS Authority 403 7.1.1. Verification using Public Resolver 405 The figure below shows the steps performed to verify the local claims 406 of DNS authority using a public resolver. 408 Steps 1-2: The client uses an encrypted DNS connection to a public 409 resolver (e.g., 1.1.1.1) to issue NS queries for the domains in 410 dnsZones. The NS lookup for "example.com" will return 411 "ns1.example.com" and "ns2.example.com". 413 Step 3: As the network-provided nameservers are the same as the 414 names retrieved from the public resolver and the network- 415 designated resolver's certificate includes at least one of the 416 names retrieved from the public resolver, the client has finished 417 validation that the nameservers signaled in [I-D.ietf-add-dnr] and 418 [RFC8801] are owned and managed by the same entity that published 419 the NS records on the Internet. The endpoint will then use that 420 information from [I-D.ietf-add-dnr] and [RFC8801] to resolve names 421 within dnsZones. 423 +---------+ +--------------------+ +----------+ 424 | client | | Network | | public | 425 | | | encrypted resolver | | resolver | 426 +---------+ +--------------------+ +----------+ 427 | | | 428 | TLS connection | | 429 |--------------------------------------------------->| 430 | ---------------------------\ | | 431 |-| validate TLS certificate | | | 432 | |--------------------------| | | 433 | | | 434 | NS? example.com (1) | | 435 |--------------------------------------------------->| 436 | | | 437 | NS=ns1.example.com, ns2.example.com (2) | | 438 |<---------------------------------------------------| 439 | -------------------------------\ | | 440 |-| both DNR ADNs are authorized | | | 441 | ----------------------\--------| | | 442 |-| finished validation | | | 443 | |---------------------| | | 444 | | | 445 | use network-designated resolver | | 446 | for example.com (3) | | 447 |----------------------------------------->| | 448 | | | 450 Figure 2: Verifying Claims using Public Resolver 452 7.1.2. Verification using DNSSEC 454 The figure below shows the steps performed to verify the local claims 455 of DNS authority using DNSSEC. 457 Steps 1-2: The DNSSEC-validating client queries the network 458 encrypted resolver to issue NS queries for the domains in 459 dnsZones. The NS lookup for "example.com" will return a signed 460 response containing "ns1.example.com" and "ns2.example.com". The 461 client then performs full DNSSEC validation locally. 463 Step 3: As the DNSSEC validation is successful and the network- 464 provided nameservers are the same as the names in the DNSSEC 465 response, and the network-designated resolver's certificate 466 includes at least one of the names returned in the DNSSEC 467 response, the client has finished validation that the nameservers 468 signaled in [I-D.ietf-add-dnr] and [RFC8801] are owned and managed 469 by the same entity that published the NS records on the Internet. 470 The endpoint will then use that information from 471 [I-D.ietf-add-dnr] and [RFC8801] to resolve names within dnsZones. 473 +---------+ +--------------------+ 474 | client | | Network | 475 | | | encrypted resolver | 476 +---------+ +--------------------+ 477 | | 478 | DNSSEC OK (DO), NS? example.com (1) | 479 |--------------------------------------------------------------->| 480 | | 481 | NS=ns1.example.com,ns2.example.com, Signed Answer (RRSIG) (2) | 482 |<---------------------------------------------------------------| 483 | -----------------------------------\ | 484 |-| DNSKEY+NS matches RRSIG, use NS | | 485 | |----------------------------------| | 486 | -------------------------------\ | 487 |-| both DNR ADNs are authorized | | 488 | |------------------------------| | 489 | ----------------------\ | 490 |-| finished validation | | 491 | |---------------------| | 492 | | 493 | use encrypted network-designated resolver for example.com (3) | 494 |--------------------------------------------------------------->| 495 | | 497 Figure 3: Verifying Claims using DNSSEC 499 7.2. Split-Horizon Only Subdomain of Zone 501 A subdomain can also be used for all internal DNS names (e.g., the 502 zone internal.example.com exists only on the internal DNS server). 503 For successful validation described in this document the the internal 504 DNS server will need a certificate signed by a CA trusted by the 505 client. 507 For such a name internal.example.com the message flow is similar to 508 Section 7.1 the difference is that queries for hosts not within the 509 subdomain (www.example.com) are sent to the public resolver rather 510 than resolver for internal.example.com. 512 8. Validation with IKEv2 514 When the VPN tunnel is IPsec, the encrypted DNS resolver hosted by 515 the VPN service provider can be securely discovered by the endpoint 516 using the ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Types 517 defined in [I-D.ietf-ipsecme-add-ike]. 519 Other VPN tunnel types have similar configuration capabilities, not 520 detailed here. 522 9. Security Considerations 524 This specification does not alter DNSSEC validation behaviour. To 525 ensure compatibility with validating clients, network operators MUST 526 ensure that names under the split-horizon are correctly signed or 527 place them in an unsigned zone. 529 If an internal zone name (e.g., internal.example.com) is used with in 530 conjunction with this specification and a public certificate is 531 obtained for validation, that internal zone name will exist in 532 Certificate Transparency [RFC9162] logs. It should be noted, 533 however, that this specification does not leak individual host names 534 (e.g., www.internal.example.com) into the Certificate Transparancy 535 logs or to public DNS resolvers. 537 10. IANA Considerations 539 This document has no IANA actions. 541 11. Acknowledgements 543 Thanks to Mohamed Boucadair, Jim Reid, Tommy Pauly, Paul Vixie, Paul 544 Wouters and Vinny Parla for the discussion and comments. 546 12. References 547 12.1. Normative References 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, 551 DOI 10.17487/RFC2119, March 1997, 552 . 554 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 555 Rose, "Protocol Modifications for the DNS Security 556 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 557 . 559 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 560 of Named Entities (DANE) Transport Layer Security (TLS) 561 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 562 2012, . 564 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 565 DOI 10.17487/RFC6762, February 2013, 566 . 568 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 569 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 570 May 2017, . 572 [RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. 573 Shao, "Discovering Provisioning Domain Names and Data", 574 RFC 8801, DOI 10.17487/RFC8801, July 2020, 575 . 577 12.2. Informative References 579 [I-D.ietf-add-dnr] 580 Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. 581 Jensen, "DHCP and Router Advertisement Options for the 582 Discovery of Network-designated Resolvers (DNR)", Work in 583 Progress, Internet-Draft, draft-ietf-add-dnr-06, 22 March 584 2022, . 587 [I-D.ietf-ipsecme-add-ike] 588 Boucadair, M., Reddy, T., Wing, D., and V. Smyslov, 589 "Internet Key Exchange Protocol Version 2 (IKEv2) 590 Configuration for Encrypted DNS", Work in Progress, 591 Internet-Draft, draft-ietf-ipsecme-add-ike-01, 22 March 592 2022, . 595 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 596 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 597 . 599 [RFC2937] Smith, C., "The Name Service Search Option for DHCP", 600 RFC 2937, DOI 10.17487/RFC2937, September 2000, 601 . 603 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 604 Protocol (DHCP) Domain Search Option", RFC 3397, 605 DOI 10.17487/RFC3397, November 2002, 606 . 608 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 609 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 610 DOI 10.17487/RFC3646, December 2003, 611 . 613 [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host 614 Configuration Protocol (DHCP) Client Fully Qualified 615 Domain Name (FQDN) Option", RFC 4702, 616 DOI 10.17487/RFC4702, October 2006, 617 . 619 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 620 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 621 Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, 622 . 624 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 625 Location Information Server (LIS)", RFC 5986, 626 DOI 10.17487/RFC5986, September 2010, 627 . 629 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 630 "IPv6 Router Advertisement Options for DNS Configuration", 631 RFC 6106, DOI 10.17487/RFC6106, November 2010, 632 . 634 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 635 Recursive DNS Server Selection for Multi-Interfaced 636 Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, 637 . 639 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 640 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 641 . 643 [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 644 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 645 2015, . 647 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 648 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 649 January 2019, . 651 [RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the 652 Internet Key Exchange Protocol Version 2 (IKEv2)", 653 RFC 8598, DOI 10.17487/RFC8598, May 2019, 654 . 656 [RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to 657 a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020, 658 . 660 [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate 661 Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, 662 December 2021, . 664 Authors' Addresses 666 Tirumaleswar Reddy 667 Akamai 668 Embassy Golf Link Business Park 669 Bangalore 560071 670 Karnataka 671 India 672 Email: kondtir@gmail.com 674 Dan Wing 675 Citrix Systems, Inc. 676 4988 Great America Pkwy 677 Santa Clara, CA 95054 678 United States of America 679 Email: danwing@gmail.com 681 Kevin Smith 682 Vodafone Group 683 One Kingdom Street 684 London 685 United Kingdom 686 Email: kevin.smith@vodafone.com 687 Benjamin Schwartz 688 Google LLC 689 Email: bemasc@google.com