Change:
Verify that answers come from the selected DNS resolver To meet this case there should be a means by which the client can <del> learn how to contact an encrypted DNS resolver that provides equivalent responses as the ones served by the network's recommended unencrypted resolver.  It is not a requirement that these two resolvers are the same physical or logical machine.  Often they will be, but they could equally be separated, perhaps by hundreds of miles.  However it is deployed, the key is that they are equivalent. </del> <ins> learn how to contact a set of encrypted DNS resolvers that are designated by the network it has joined. </ins> 3.1. <del> Given two resolvers A and B, equivalence is the claim that A and B can provide the same upper-layer DNS function to the client.  This does not include the DNS transport protocol (e.g.  Do53 or DNS-over- HTTPS) which can differ between equivalent resolvers.  To provide equivalence it is frequently likely to be the case that A and B are operated by the same administrative domain, but this document does not require that. </del> <ins> Designation is the process by which a local network or a resolver can point clients towards a particular set of resolvers.  This is not a new concept, as networks have been able to dynamically designate Do53 resolvers for decades (see network).  However here we extend the concept in two ways: </ins> <del> There are two possible ways to claim equivalence. </del> <ins> To allow resolvers to designate other resolvers </ins> <del> The local network can claim that one or more encrypted DNS resolvers (B, C, etc) are equivalent to the Do53 resolver (A) it has offered.  This is known as network-identified. </del> <ins> The inclusion of support for encrypted DNS </ins> <del> During communication with the (often unencrypted) resolver (A), this resolver can claim that one or more encrypted DNS resolvers (B, C, etc) are equivalent.  This is known as resolver-identified. </del> <ins> The designated set could be empty, or it could list the contact details (such as DoH URI Template) of DNS resolvers that it recommends.  It is not required that there be any relationship between the resolvers in the set, simply that all of them are options that the designator asserts are safe and appropriate for the client to use without user intervention. There are two possible sources of designation. The local network can designate one or more encrypted DNS resolvers (B, C, etc) in addition to any Do53 resolver (A) it may offer.  This is known as network-identified. </ins> <del> Network-identified is preferred since it comes from the same source of information, and removes the need to talk to the Do53 resolver at all.  However it cannot be the sole mechanism, at least for several years, since there is a large installed base of local network equipment that is difficult to upgrade with new features.  Hence the second mechanism must support being able to announce an equivalent resolver using only existing widely-deployed DNS features. </del> <ins> During communication with the (often unencrypted) resolver (A), this resolver can designate one or more encrypted DNS resolvers (B, C, etc).  This is known as resolver-identified. Network-identified has the advantages that it derives from the same source of information as the network's Do53 announcement, and removes the need to talk to the Do53 resolver at all.  However it cannot be the sole mechanism, at least for several years, since there is a large installed base of local network equipment that is difficult to upgrade with new features.  Hence the second mechanism should support being able to designate resolvers using only existing widely-deployed DNS features. </ins> 3.2. Many networks offer a Do53 resolver on an address that is not globally meaningful, e.g.  RFC1918, link-local or unique local <del> addresses.  To support the discovery of Encrypted DNS in these </del> <ins> addresses.  To support the discovery of encrypted DNS in these </ins> environments, a means is needed for the discovery process to work <del> from a locally-addressed Do53 resolver to an Encrypted DNS resolver </del> <ins> from a locally-addressed Do53 resolver to an encrypted DNS resolver </ins> that is accessible either at the same (local) address, or at a different global address.  Both options need to be supported. <del> 4. </del> <ins> 3.3. After the client receives designation information, it must come to a decision on whether and when to use any of the designated resolvers. In the case of resolver-identified designation, it would be advantageous for a solution to enable the client to validate the source of the assertion in some way.  For example it may be possible to verify that the designation comes from an entity who already has full control of the client's Do53 queries.  Network-identified designation should not require this, unless the network-identified resolver in turn initiated a new resolver-identified designation.  It would be beneficial to extend such a verification process to defend against attackers that have only transient control of such queries. Clients may also seek to validate the identity of the designated resolver, beyond what is required by the relevant protocol.  Authors of solution specifications should be aware that clients may impose arbitrary additional requirements and heuristics as they see fit. 3.4. </ins> DNS servers are often provisioned by a network as part of DHCP options RFC2132, IPv6 Router Advertisement (RA) options RFC8106,

Discussion:
This PR simplifies further by removing any mention of properties of the encrypted resolvers, or properties of the relationship between the Do53 and the encrypted resolver. It now purely focusses on the ability of an untrusted network or resolver to designate other encrypted resolvers. This is an assertion that the encrypted resolver is safe and appropriate to use, but little else. Clients will of course make their own decisions about whether to use designated resolvers or not. Other drafts will look at trusted networks, and communicating information that can be useful to clients as part of the untrusted decision-making.
comments
comments on the draft02
It was pointed out that this should be limited to IETF-standardised encrypted DNS protocols rather than potentially including DNSCrypt and being very open-ended.