Change:
4.1.3. <del> Narrative required. </del> <ins> As stated above, an enterprise-managed Wi-Fi network might be able to access both the Internet and a private intranet.  The private domains managed by the enterprise might only be resolvable using a specific DNS resolver, hence use of that resolver is essential for such domains.  However it does not necessarily mean that all queries for all domains have to flow through that resolver. Only sending the necessary queries through the enterprise resolver, and not generic Internet queries, has the privacy benefit of only exposing traffic to the enterprise that fall within a limited set of domains. Using encrypted DNS for private names also opens up the possibility of doing private name resolution outside of the content of a VPN or managed network.  If the DNS resolver authenticates clients, it can offer its resolver for private names on a publicly accessible server, while still limiting the visibility of the DNS traffic. </ins> 4.2. <del> Narrative required. </del> <ins> Content Delivery Networks (CDNs), and content-providers more broadly, can also provide encrypted DNS resolvers that can be used by clients over the public Internet.  These resolvers can either allow resolution of all public names (like normal recursive resolvers), or be designed to serve a subset of names managed by the content provider (like an authoritative resolver).  Using these resolvers can allow the content provider to directly control how DNS answers are used for load balancing and address selection, which could improve performance of connections to the content provider. Using a content-provider's encrypted resolver can also provide several privacy and security benefits: Prevent devices along the network path to the content-provider's resolver from observing client DNS messages Verify that answers come from the entity that manages the domains being resolved Reduce the number of entities able to monitor the specific names accessed by a client to only the client and the content provider, assuming that the content provider would already see the names upon a secure connection later being made based on the DNS answers (e.g., in the TLS SNI extension) </ins> 5. <ins> Encrypted (and authenticated) DNS improves the privacy and security of DNS queries and answers in the presence of malicious attackers. Such attackers are assumed to interfere with or otherwise impede DNS traffic and corresponding discovery mechanisms.  They may be on-path or off-path between the client and entities with which the client communicates RFC3552.  These attackers can inject, tamper, or otherwise interfere with traffic as needed.  Given these capabilities, an attacker may have a variety of goals, including, though not limited to: Monitor and profile clients by observing unencrypted DNS traffic Modify unencrypted DNS traffic to filter or augment the user experience Block encrypted DNS Clients cannot assume that their network does not have such an attacker unless given some means of authenticating or otherwise trusting the communication with their DNS resolver. Given this type of attacker, resolver discovery mechanisms must be designed carefully to not worsen a client's security or privacy posture.  In particular, attackers must not be able to: Redirect secure DNS traffic to themselves when they would not otherwise handle DNS traffic. Override or interfere with the resolver preferences of a user or administrator. Cause clients to use a discovered resolver which has no authenticated delegation from a client-known entity. Influence automatic discovery mechanisms such that a client uses one or more resolvers that are not otherwise involved with providing service to the client, such as: a network provider, a VPN server, a content provider being accessed, or a server that the client has manually configured. Beyond these requirements, standards describing resolver discovery mechanisms must not place any requirements on clients to select particular resolvers over others. When discovering DNS resolvers on a local network, clients have no mechanism to distinguish between cases where an active attacker with the above capabilities is interfering with discovery, and situations wherein the network has no encrypted resolver.  Absent such a mechanism, an attacker can always succeed in these goals.  Therefore, in such circumstances, viable solutions for local DNS resolver discovery should consider weaker attackers, such as those with only passive eavesdropping capabilities.  It is unknown whether such relaxations represent a realistic attacker in practice.  Thus, local discovery solutions designed around this threat model may have limited value. 5.1. Opportunistic encrypted DNS, when the client cannot authenticate the entity that provides encrypted DNS, does not meet the requirements laid out here for resolver discovery.  While opportunistic encryption can provide some benefits, specifically in reducing the ability for other entities to observe traffic, it is not a viable solution against an on-path attacker. Performing opportunistic encrypted DNS does not require specific discovery mechanisms.  Section 4.1 of RFC7858 already describes how to use DNS-over-TLS opportunistically. 5.2. Even with encrypted DNS resolver discovery in place, clients must be prepared to handle certain scenarios where encrypted DNS cannot be used.  In these scenarios, clients must consider if it is appropriate to fail open by sending the DNS queries without encryption, fail closed by not doing so, or presenting a choice to a user or administrator.  The exact behavior is a local client policy decision. Some networks that use Captive Portals will not allow any Internet connectivity until a client has interacted with the portal I-D.ietf- capport-architecture.  If these networks do not use encrypted DNS for their own resolution, a client will need to perform unencrypted DNS queries in order to get out of captivity.  Many operating systems have specific client code responsible for detecting and interacting with Captive Portals; these system components may be good candidates for failing open, since they do not generally represent user traffic. Other networks may not allow any use of encrypted DNS, or any use of encrypted DNS to resolvers other than a network-provisioned resolver. Clients should not silently fail open in these cases, but if these networks are trusted by or administered by the user, the user may want to specifically follow the network's DNS policy instead of what the client would do on an unknown or untrusted network. 6. </ins> This sections lists the complete set of requirements described above, for ease of reference. <del> 6. </del> <ins> 7. </ins> All security considerations relevant to a particular use case are <del> described under that section.  Additional consideration common to all of them are described here. </del> <ins> described under that section.  Additional considerations common to all of them are described in priv-sec. </ins> <del> 7. </del> <ins> 8. </ins> This document has no IANA actions.

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.