Change:
This review does NOT close the issue; it only addresses the "easier" items. The harder, normative challenging comments may be tackled together with overlapping feedback from other reviewers such as Ben.
Summary: Has issues to address before publication as a Proposed Standard RFC (Note: I reviewed -07, and noticed -08 while entering this review. I've read the diffs, and believe all the below to still be relevant). Issues: RFC 6761 requires explicit discussion of seven categories of consumers of a new SUDN. This document does not yet provide that discussion. There's a lack of discussion of issues around certificate revocation throughout the document. The end of section 4.1.1, for example, cuts off an mitigation opportunity should control of a certificate used by the Designated Resolver be lost. Please add an explanation for why the requirement in the last sentence of the first paragraph of 4.2 exists. As written, it seems out of context, and underspecified (which SVBC result, obtained when, should the client consider the TTL from?). The discussion of providing differentiated behavior over unencrypted DNS is good to call out, but needs more depth. There are many other fields an attacker might modify, even outside the DNS part of the datagram (say, the source IP address) that could give the attacker an advantage if the returned results varied. Nits: In the introduction, please reconsider "claims ownership over the IP addresses". It would be better to simply say "contains the IP addresses in the SubjectAltName. There is tension between the normative SHOULD NOT and SHOULD in the first paragraph of 4.1.1 and the SHOULD in the first paragraph of 4.2. Please clarify the wording in one place or the other so that an implementer isn't forced to violate one of those normative requirements to satisfy the other. The last sentence of the first paragraph of 4.3 is imprecise. It would address my discomfort to replace "cannot be confirmed" with "cannot be safely confirmed", or add a pointer to a description somewhere else about why trying to include such addresses in a certificate is an unworkable idea. At the end of the second paragraph of 4.3, consider future protocols that might use something other than TLS as the security layer. The sentence as is takes a shortcut past the point your are really trying to make. The use of SHOULD in the second paragraph of section 5 is strange. Do you mean "are expected to be"? The other side of this coin (that records are NOT expected to be present) isn't obvious to find in section 4. Consider explicitly calling out what the implementation MUST do if the validation in the 4th paragraph of section 7 fails. (Feel free to ignore this, but): At the 5th paragraph of section 7, consider discussing the risks of an operator running an Unencrypted Resolver at a given IP and not running a Designated Resolver there. This adds an attack point for an adversary to gain enough access to run their own Designated Resolver there, even if they can't gain enough privilege to affect the Unencrypted Resolver. Micro-Nits: Section 3 3rd to last paragraph: s/use others records/use other records/
Major issues already addressed in other PRs, and nits addressed in

Discussion:
resolver.  "Designated" in this context means that the resolvers are operated by the same entity or cooperating entities; for example, the resolvers are accessible on the same IP address, or there is a <del> certificate that claims ownership over the IP address for the original designating resolver. </del> <ins> certificate that contains the IP address for the original designating resolver. </ins> 1.1.

configuration over unencrypted DNS is not possible.  This includes Unencrypted Resolvers on private IP addresses RFC1918, Unique Local Addresses (ULAs) RFC4193, and Link Local Addresses RFC3927 RFC4291, <del> whose identity cannot be confirmed using TLS certificates under most conditions. </del> <ins> whose identity cannot be safely confirmed using TLS certificates under most conditions. </ins> Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as a mode in which clients do not validate the name of the resolver

the certificate) as long as the IP address of the Encrypted Resolver does not differ from the IP address of the Unencrypted Resolver. Clients SHOULD use this mode only for resolvers using private or <del> local IP addresses.  This approach can be used for any encrypted DNS protocol that uses TLS. </del> <ins> local IP addresses. </ins> 5.

Unencrypted Resolver, clients applying Verified Discovery (verified) MUST validate that the IP address of the Unencrypted Resolver is covered by the SubjectAlternativeName of the Designated Resolver's <del> TLS certificate. </del> <ins> TLS certificate.  If that validation fails, the client MUST NOT automatically use the discovered Designated Resolver. </ins> Clients using Opportunistic Discovery (opportunistic) MUST be limited to cases where the Unencrypted Resolver and Designated Resolver have <del> the same IP address. </del> <ins> the same IP address.  Clients which do not follow Opportunistic Discovery (opportunistic) and instead try to connect without first checking for a designation run the possible risk of being intercepted by an attacker hosting an Encrypted DNS Resolver on an IP address of an Unencrypted DNS Resolver where the attacker has failed to gain control of the Unencrypted DNS Resolver. </ins> The constraints on the use of Designated Resolvers specified here apply specifically to the automatic discovery mechanisms defined in