Change:
4.1.1. <del> Narrative required. </del> <ins> Accessing locally-hosted content can require the use of a specific resolver.  For example, captive networks or networks with walled- garden content like media on airplane Wi-Fi networks can rely on using a resolver hosted on the local network. In cases where a client is using an encrypted resolver provisioned by a network, and that encrypted resolver is able to resolve names of local content, this can fall into the use case described in local- network.  However, it might be necessary to discover a local encrypted resolver along with specific domains if: the network-provisioned encrypted resolver is not able to resolve local-only names, or the client has a more-preferred encrypted resolver for generic traffic, and would otherwise not be able to access local content The first point can occur in a hybrid deployment, e.g. when the local resolver is unencrypted but a central one is encrypted.  Clients choosing the encrypted resolver for most queries will need to be advised to refer to the local one for some names. This case also include accessing content specific to a home network. </ins> 4.1.2.

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.