Code change:
address on multiple different networks, a Designated Resolver that has been discovered on one network SHOULD NOT be reused on any of the other networks without repeating the discovery process for each <del> network. However, if a given Unencrypted DNS Resolver designates a Designated Resolver that does not use a private or local IP address and can be verified using the mechanism described in verified, it MAY be used on different network connections so long as the subsequent connections over other networks can also be successfully verified using the mechanism described in verified.  This is a tradeoff between performance (by having no delay in establishing an encrypted DNS connection on the new network) and functionality (if the Unencrypted DNS Resolver intends to designate different Designated Resolvers based on the network from which clients connect). </del> <ins> network, since the same IP address may be used for different servers on the different networks. </ins> 4.2.

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.