Code change:
4.1. <ins> When a client discovers Designated Resolvers from an Unencrypted Resolver IP address, it can choose to use these Designated Resolvers either automatically, or based on some other policy, heuristic, or user choice. This document defines two preferred methods to automatically use Designated Resolvers: Authenticated Discovery authenticated, for when a TLS certificate can be used to validate the resolver's identity. Opportunistic Discovery opportunistic, for when a resolver is accessed using a non-public IP address. A client MAY additionally use a discovered Designated Resolver without either of these methods, based on implementation-specific policy or user input.  Details of such policy are out of scope of this document.  Clients SHOULD NOT automatically use a Designated Resolver without some sort of validation, such as the two methods defined in this document or a future mechanism. 4.2. Authenticated Discovery is a mechanism that allows automatic use of a Designated Resolver that supports DNS encryption that performs a TLS handshake. </ins> In order to be considered an authenticated Designated Resolver, the <del> TLS certificate presented by the Encrypted Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of the </del> <ins> TLS certificate presented by the Designated Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of the </ins> designating Unencrypted Resolver within the SubjectAlternativeName certificate field.  The client MUST check the SubjectAlternativeName field for both the Unencrypted Resolver's IP address and the

Related discussion:
text: Right now, we only allow authenticated and matching-IP opportunistic use of the DDR record. While use of the record in a case where authentication fails isn't safe to use automatically, we should clarify that implementations MAY choose to use the information anyhow by policy, and possibly with user control.
For authentication to matter, it generally has to operate without fallback. Currently the text is not very clear on this point, but it sure seems like IP-authenticated mode is expected to fall back to cleartext if no upgrade is possible. I think we need to clarify the use case for an authenticated mode, or abandon the distinction between opportunistic and authenticated. In my view, authenticated mode only makes sense if (1) the resolver is identified by its IP address AND (2) the system knows a priori that this resolver supports encrypted DNS, so that it can refuse to fall back to cleartext if the upgrade information is stripped by a network attacker. This is a sufficiently narrow use case that I lean toward dropping it entirely and recommending Discovery Using Resolver Names (Section 5) or opportunistic instead.
Currently, this is what we say (which I now see a grammatical error in, but there it is): We don't say anything else because that would be out of WG scope. The point of the document is to help a stub resolver configured with a recursive resolver known only by IP address to bootstrap into encrypted DNS. The stub resolver's posture on whether to fall back to unencrypted DNS or simply refuse to use the resolver is its own business. Look at this through a common OS scenario: the OS stub resolver learns an IP address from DHCP, and it's a public IP address (my old ISP did this). It knows of no other resolvers because the user doesn't know what DNS is and that's the default configuration (use network recommendation). If I try to use DDR and I get no answer back, then I'm in the same position as I was before DDR: I know of no other resolver, so I either have to use this one or have no DNS resolutions. DDR did not introduce that conundrum; it offers clients a way out of it when DNR is not present and there is no plain-text DNS attack present. The authenticated DDR mode allows such a client to be confident in the authenticity of the bootstrap even though it started over plain text.