Change:
benefits of a local caching forwarder with knowledge of the local topology. <ins> Another benefit occurs with IoT devices.  A common usage pattern for such devices is for it to "call home" to a service that resides on the public Internet, where that service is referenced through a domain name (A or AAAA record).  As discussed in Manufacturer Usage Description Specification RFC8520, because these devices tend to require access to very few sites, all other access should be considered suspect.  However, if the query is not accessible for inspection, it becomes quite difficult for the infrastructure to suspect anything. </ins> 3.2. <del> A client with manual configuration directing it to use a particular resolver will generally use that resolver.  However if that communication is unencrypted, it is beneficial for the client to learn which associated resolvers are offered by the same entity and provide the same semantics. </del> <ins> Client devices often allow the device administrator to select a specific DNS resolver to use on certain networks, or on all networks. Historically, this selection was specified only with an IP address. Discovering which equivalent encrypted resolvers are offered by the same entity allows the client to "upgrade" connections to use encrypted DNS.  This can provide several benefits: Prevent devices along the network path to the selected resolver from observing client DNS messages Verify that answers come from the selected DNS resolver Authenticate that the DNS resolver is the one selected by the client In doing so it is critical that the new resolver is an equivalent resolver.  Switching to a non-equivalent alternative resolver would break the expectation of the user who previously selected that resolver. </ins> 3.3. <del> Narrative required. </del> <ins> Virtual Private Networks (VPNs) also can provision DNS resolvers.  In addition to being able to use DHCP or RAs, VPNs can provision DNS information in an explicit configuration message.  For example, IKEv2 can provision DNS servers using Configuration Attributes RFC7296. VPNs can also configure Split DNS rules to limit the use of the configured resolvers to specific domain names RFC8598. Discovering an encrypted resolver that is provisioned by a VPN can provide the same benefits as doing so for a local network, but applied to the private network.  When using Split DNS, it becomes possible to use one encrypted resolver for private domains, and another for other domains. </ins> 4. <del> Narrative required. </del> <ins> Similar to how VPN DNS configurations can use Split DNS for private names, other network environments can support resolution of names that are specific to the local environment.  For example, an enterprise-managed Wi-Fi network might be able to access both the Internet and a private intranet.  In such a scenario, the private domains managed by the enterprise might only be resolvable using a specific DNS resolver. Discovering an encrypted resolver for a subset of names allows a client to perform Split DNS while maintaining the benefits of encrypted DNS.  For example, a client could use a client-selected encrypted resolver for public domains, but use a different encrypted resolver for enterprise-private domains. Such domain-specific resolver discovery mechanisms additionally need to provide some information about the applicability and capabilities of encrypted resolvers.  This information can either be provisioned or can be discovered based on clients actively trying to access content. </ins> 4.1.

Discussion:
Authors, please comment.
I’m not sure adding authenticated here is something the group has consensus on as yet. I know this is still in early draft mode, so while I don’t object to including it, we should mark is as an item to be discussed. If we do include it, then some words should be added somewhere in the draft about what “authenticated” in such a context is being proposed to mean as that’s what will be a key discussion item in determining if it get consensus.
Glenn I merged "authenticated" before I read this comment. I added it because it made sense to me; without authentication any encryption is highly weakened. But I take your point that it needs explaining.
Ok, perhaps it can be added in the next rev. Basically I’m suggesting that the aspect of “authenticated” be expanded, discussed, and explained as it does potentially have different notions in different readers perspectives. For example some may say doing a DNSSEC validation of some sort is what is needed, or perhaps some form of PKI, or is it a TLS certificate validation, or mutual exchange? It might even be something as basic as asking special DNS queries and validating the answers received against expectations. Another slice would be authenticating the actual resolver chosen or is it authenticated at the more abstract “service” provided by the operator of the resolver? There is also the consideration of does the authentication means/level vary depending on different environmental threat levels? The bottom line is there is a lot of meanings behind “authentication” and what is being authenticated to declare and discuss as a requirement.
Several possible ways of authenticating the encrypted DNS server are already discussed in our spec URL I don't think the requirements draft should discuss the possible modes of authenticating the server.
How does the client learn the encrypted and unencrypted DNS servers are operated by the same administrative domain ? The client can authenticate the encrypted DNS servers but cannot authenticate the unencrypted DNS server ! Originally posted by NAME in URL
If it is genuinely impossible to prove association between two resolvers when one resolver is unencrypted, then perhaps we should not have the concept at all. But I'm hoping it is not impossible.
draft-pauly-add-deer-00 does this (at least in some circumstances), so it's not impossible.