Original text:
like RA guard RFC6105.  An attacker might try to direct Encrypted DNS traffic to itself by causing the client to think that a discovered Designated Resolver uses a different IP address from the Unencrypted <del> Resolver.  Such an Encrypted Resolver might have a valid certificate, </del>  but be operated by an attacker that is trying to observe or modify user queries without the knowledge of the client or network. <del> If the IP address of a Designated Resolver differs from that of an Unencrypted Resolver, clients MUST validate that the IP address of the Unencrypted Resolver is covered by the SubjectAlternativeName of the Encrypted Resolver's TLS certificate (authenticated). </del>  <del> Opportunistic use of Encrypted Resolvers MUST be limited to cases where the Unencrypted Resolver and Designated Resolver have the same IP address (opportunistic). </del>  8.

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:
like RA guard RFC6105.  An attacker might try to direct Encrypted DNS traffic to itself by causing the client to think that a discovered Designated Resolver uses a different IP address from the Unencrypted  <ins> Resolver.  Such a Designated Resolver might have a valid certificate, </ins> but be operated by an attacker that is trying to observe or modify user queries without the knowledge of the client or network.  <ins> The constraints on validation of Designated Resolvers specified here apply specifically to the automatic discovery mechanisms defined in this documents, which are referred to as Authenticated Discovery and Opportunistic Discovery.  Clients MAY use some other mechanism to validate and use Designated Resolvers discovered using the DNS SVCB record.  However, use of such an alternate mechanism needs to take into account the attack scenarios detailed here. </ins>  <ins> If the IP address of a Designated Resolver differs from that of an Unencrypted Resolver, clients applying Authenicated Discovery (authenticated) MUST validate that the IP address of the Unencrypted Resolver is covered by the SubjectAlternativeName of the Designated Resolver's TLS certificate. Clients using Opportunistic Discovery (opportunistic) MUST be limited to cases where the Unencrypted Resolver and Designated Resolver have the same IP address. </ins> 8.