Original text:
Resolver for any cases in which it would have otherwise used the Unencrypted Resolver.  If the Designated Resolver has a different IP address than the Unencrypted Resolver and the TLS certificate does <del> not cover the Unencrypted Resolver address, the client MUST NOT use the discovered Encrypted Resolver.  Additionally, the client SHOULD suppress any further queries for Designated Resolvers using this Unencrypted Resolver for the length of time indicated by the SVCB record's Time to Live (TTL). </del>  If the Designated Resolver and the Unencrypted Resolver share an IP <del> address, clients MAY choose to opportunistically use the Encrypted </del>  Resolver even without this certificate check (opportunistic). <del> If resolving the name of an Encrypted Resolver from an SVCB record </del>  yields an IP address that was not presented in the Additional Answers section or ipv4hint or ipv6hint fields of the original SVCB query, the connection made to that IP address MUST pass the same TLS certificate checks before being allowed to replace a previously known <del> and validated IP address for the same Encrypted Resolver name. </del>  <del> 4.2. </del>  There are situations where authenticated discovery of encrypted DNS configuration over unencrypted DNS is not possible.  This includes

Reviewer comments:
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. I do not agree this scenario is sufficiently narrow to drop. Is your concern over the usefulness of the scenario, or over naming it "authenticated"? I am open to suggestions on the latter; I strongly disagree with the former.
Both. How is this information useful to the client? I have not heard of any proposal for any client to behave differently on the basis of whether its encrypted connection is authenticated, when the resolver is identified by IP address. As for the name, RFC 7435 is the reference. I find it a bit confusing, but here's some of the relevant text: The "authenticated" section does not seem to describe an "authenticated" protocol by this definition, because it does not provide a downgrade-resistant method to determine that authentication is expected to work.
Please suggest a more accurate name then please. I do agree behavior naming should be consistent with other documents. Your bar for useful is apparently different from mine. Before DDR, a client configured only with an IP address had only unencrypted DNS as an option. With DDR, the client can possibly encrypt that connection. A transient attacker would have to have been present for the initial SVCB discovery to prevent that; an attacker arriving after DDR has taken place will be kept out of the loop. In the worst case, a client is returned to square one. I do not agree that just because a mechanism can be prevented means the mechanism provides no value. It doesn't have to. In the common case, the client is forced by lack of knowledge to use unencrypted DNS. If it can from that default configuration divine encrypted DNS configuration, that's a net positive. Resolver selection is out of scope and has nothing to do with it.
I've updated to address this question by reformulating the concept of authentication, and being much more explicit about the threat model. Yes, that's a good step, but it doesn't rely on authentication. This is a very helpful observation. I've incorporated it in .
I believe this particular issue is largely overtaken by events. Particularly, I think we've added some clarity and escape hatches with , and protections with .
Same comment for line 337/360 about referring to the resolver as Designated versus Encrypted (it's unmodified in this PR but based on your agreement with the other in-line comment it may need modified as well) I think we will need to add some text to the Security Considerations section to mention the security promise difference between following the MAY or not (for optional use of the unverifiable designation). However, we can close this PR without it and handle that in a new PR if that's preferable.

Revised text:
Resolver for any cases in which it would have otherwise used the Unencrypted Resolver.  If the Designated Resolver has a different IP address than the Unencrypted Resolver and the TLS certificate does  <ins> not cover the Unencrypted Resolver address, the client MUST NOT automatically use the discovered Designated Resolver.  Additionally, the client SHOULD suppress any further queries for Designated Resolvers using this Unencrypted Resolver for the length of time indicated by the SVCB record's Time to Live (TTL). </ins> If the Designated Resolver and the Unencrypted Resolver share an IP  <ins> address, clients MAY choose to opportunistically use the Designated </ins> Resolver even without this certificate check (opportunistic).  <ins> If resolving the name of a Designated Resolver from an SVCB record </ins> yields an IP address that was not presented in the Additional Answers section or ipv4hint or ipv6hint fields of the original SVCB query, the connection made to that IP address MUST pass the same TLS certificate checks before being allowed to replace a previously known  <ins> and validated IP address for the same Designated Resolver name. </ins>  <ins> 4.3. </ins> There are situations where authenticated discovery of encrypted DNS configuration over unencrypted DNS is not possible.  This includes