Code change:
If the Designated Resolver and the Unencrypted DNS Resolver share an IP address, clients MAY choose to opportunistically use the Designated Resolver even without this certificate check <del> (opportunistic). </del> <ins> (opportunistic).  If the IP address is not shared, opportunistic use allows for attackers to redirect queries to an unrelated Encrypted Resolver, as described in security. </ins> <del> If resolving the name of a Designated Resolver from an SVCB record 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 and validated IP address for the same Designated Resolver name. </del> <ins> Connections to a Designated Resolver can use a different IP address than the IP address of the Unencrypted DNS Resolver, such as if the process of resolving the SVCB service yields additional addresses. Even when a different IP address is used for the connection, the TLS certificate checks described in this section still apply for the original IP address of the Unencrypted DNS Resolver. </ins> 4.3.

Related discussion:
text: To avoid name lookup deadlock, Designated Resolvers SHOULD follow the guidance in Section 10 of [RFC8484] regarding the avoidance of DNS- based references that block the completion of the TLS handshake. I find that reference to list more the issues than solutions that can be followed. The solution to use another DoH server is not really appropriate in most cases The client's other interface likely resides on other networks where its private DoH server cannot resolve the name of another network's private DoH server. It is also not easy to get an IP based certificate (eg SAN=ip) that is accepted by general webpki root stores. And things like OCSP stapling doesn't help if the target is malicious - they just would omit the stapling that proves against its malicious use. The only real advise usable from RFC8484 is "use the local unencrypted resolver to resolve the encrypted resolver". Might as well say that and remove the 8484 reference. as the protocol is mentioned throughout the document as interacting with this protocol. when accessing web content on a dual-stack network: A, AAAA, and HTTPS queries. Discovering a Designated Resolver as part of one of these queries, without having to add yet another query, minimizes the total number of queries clients send. I don't understand this paragraph. Once clients can send SVCB queries for web content, they already have had to do all the DDR/DNR related queries, so I don't understand the argument of "saving queries" ? Also, it is adding queries for a specific target, eg URL, and this cannot be "saved" either? What am I misunderstanding here? provides provides -> provides
We should reference Security Considerations, because if you don't have any validation, an attacker can point you to any server they want (someone other than the server you were configured with by DHCP, etc).
We can probably just remove this, not using it in implementations right now.
It's already done by the major public resolvers, and there is an RFC to support this (RFC 8738). The IP address validation is clearly important and a matter of WG consensus. Hopefully, this will push adoption of RFC 8738 by more ACME services.
We can reference the DNR section. The MUST NOT should only apply to DDR, but doesn't invalidate other ways of using the resolver.