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: And section 6.5 states DNR trumps DDR. address, clients MAY choose to opportunistically use the Designated Resolver even without this certificate check (Section 4.3). Why only when the IP is the same? Why not for when the IP is different? What's to lose, since the only fallback option is stick to using the unencrypted resolver? 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. How does the appearance of an (unsigned) Additional Answer entry convey any kind of real world trust/authentication? In other words, why should it not ALWAYS pass the same TLS certificate checks ? is to use unencrypted DNS, why not just use it anyway? use DDR to discover details about all supported encrypted DNS protocols. It's a little odd to mention this as the DNR draft really tries hard to say to only use the network's offered encrypted DNS servers, so this option is in conflict with the DNR draft. Unfortunately, all currently deployed software does not know this, so it will be very common that this happens. URL SHOULD treat URL as a locally served zone per [RFC6303] Why is this not a MUST ? queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. I don't see how this would improve security for the client. It also mixes up behaviour of proper DNS clients that have their own retransmit logic for if they get no answer. attack where an attacker can block connections to the encrypted DNS server, and recommends that clients prevent it by switching to SVCB- reliant behavior once SVCB resolution does succeed. For DDR, this means that once a client discovers a compatible Designated Resolver, it SHOULD NOT use unencrypted DNS until the SVCB record expires I wonder which attacker can block encrypted DNS connections but not spoof (or block!) an unsigned SVCB record to the local client? And even if that is the case, this would be a denial of service attack if the DNS client cannot fallback to unencrypted DNS.