Change:
14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> 2. This document makes use of the following terms. Encrypted DNS: DNS-over-HTTPS RFC8484, DNS-over-TLS RFC7858, or any other encrypted DNS technology that the IETF may publish, such as DNS-over-QUIC I-D.ietf-dprive-dnsoquic. Associated resolver: A resolver operated by the same entity that provides the resolver the client started with.  See associated. Equivalent associated resolver: An associated resolver that provides DNS responses that are identical to the ones served by the original unencrypted resolver. Alternative associated resolver: An associated resolver that serves different responses to some queries; see associated for examples. </ins> 3. <del> A client may begin with information from the attached networks, and/ or resolvers known from configuration.  This information may be used to then discover one or more associated or equivalent encrypted resolvers.  These are expected to be operated by the same entity that provides the resolver the client started with, but may not have identical behaviour.  For example one entity may offer a set of encrypted resolvers with different levels of filtering or proximity. </del> <ins> A client may begin with information about unencrypted resolvers from the attached networks (local-network), and/or unencrypted resolvers known from configuration (client-selected).  This information may be used to then discover one or more associated encrypted resolvers. Associated resolvers are defined as resolvers operated by the same entity that provides the resolver the client started with.  Such associated resolvers may come in two forms: Equivalent - these provide DNS responses that are identical to the ones served by the unencrypted resolver. Alternative - these serve different responses to some queries. For example one entity may offer a set of encrypted resolvers with different levels of filtering (none, just malware, or malware & adult content), or different proximity (local or central). The client may wish to select an equivalent associated resolver, or select one of the alternatives. Designs for resolver upgrade mechanisms can either add new parameters to existing provisioning mechanisms (for example, adding necessary information to use DoT or DoH to options in DHCP, RAs, or IKEv2) or else provide a way to communicate with a provisioned unencrypted DNS resolver and discover the associated encrypted DNS resolvers. </ins> 3.1. <del> During network attach, networks frequently announce a resolver that they recommend clients should use.  This could be through DHCP, RA, PPP, PCO, or another mechanism.  Historically this is usually a Do53 resolver, declared simply by its IP address.  However it could also be a richer set of information. </del> <ins> DNS servers are often provisioned by a network as part of DHCP options RFC2132, IPv6 Router Advertisement (RA) options RFC8106, Point-to-Point Protocol (PPP) RFC1877, 3GPP Protocol Configuration Options, or another mechanism.  Historically this is usually one or more DNS resolver IP addresses, to be used for traditional unencrypted DNS.  However it could also be a richer set of information. Using an encrypted and authenticated resolver that is associated to the one provisioned by the network can provide several benefits that are not possible if only unencrypted DNS is used: Prevent other devices on the network from observing client DNS messages Verify that answers come from the selected DNS resolver Authenticate that the DNS resolver is the one provisioned by the network Frequently, network-provisioned resolvers are forwarders running on a local router.  The discovered encrypted resolvers in these cases may either be local forwarders themselves, or an associated resolver that is in the network (thus bypassing the router's DNS forwarder). </ins> 3.1.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.