Change:
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

Discussion:
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