Change:
address, clients MAY choose to opportunistically use the Encrypted Resolver even without this certificate check (opportunistic). <ins> If resolving the name of an Encrypted 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 Encrypted Resolver name. </ins> 4.2. There are situations where authenticated discovery of encrypted DNS

Discussion:
Added some text to address and reference to SVCB draft with regards to hints explained why resolvers should provide hints clients MUST subject resolved IP addresses to the same security requirements as other IP address
I think we should invert this advice. We should recommend not including IP hints, and instead instruct recursive resolvers to append the relevant A and AAAA records in the Additional Section. The IP hints are strictly a performance hack when using a legacy non-SVCB-aware recursive resolver. This text is specifically applicable only to SVCB-aware recursive resolvers, so we can tell them to do it the right way instead.
NAME 's suggestion sounds good to me. Let's emphasize that the addresses should come in the same response as the SVCB record, with a preference for Additional Section.
I reviewed the draft on the git and came with a similar comment. preventing the use of ipv4hint My first comment is that we should favor IPv6 over IPv4 in our example. My second comment is that the first example uses a local target that is using a hint mentioned as SHOULD NOT in the svcb specification. The scenario I see that might be useful are: From the IP address of the unencrypted resolver: when the encrypted resolver has a different IP address than the one advertised. From the name of encrypted resolvers. Duplication of the IP address adds operational complexity and is a source of misconfiguration and makes updates harder. This may result in the resolver being unreachable and I do not think we should take that path even with a low probability. If I try to balance this with the potential outcomes, it at most reduces the connectivity of an additional round trip. Firstly, this does not sound - at least to me - as a big issue. Then it seems to me the same results can be achieved safely using additional data RRSets. If the additional round trip is performed, it is also likely that resolutions will prefetch the first connection performed by the end user. In any case, I do not see the benefit provided by the ip hint to compete with its disadvantages.
I have updated the text accordingly. The description of the need for an additional name resolution still mentions this will result if there are no A/AAAA or IP hints included because it's true, but the SHOULD is for the A/AAAA. I have also removed the IP hints from the examples altogether.

This PR also address the duplicate issue regarding adding ipv6 hints.
sure, thanks for the update.
We should make sure that any examples including an ipv4hint also include an ipv6hint or only include an ipv6hint. (per URL)
Address this then trivialized this by simply not including IP hint in the first place.
Migrated from original DEER issue: URL
From Ben: Strictly speaking, a compliant SVCB client is expected to perform the additional lookups anyway. The hints just avoid a delay while those queries complete. If you think it's important to "skip" those followup queries, we would have to make a deeper change. Otherwise, you could say "avoid waiting for DNS lookup...".
From Eliot Lear: The draft currently reads: When responding to these special queries for "URL", the SVCB records SHOULD contain at least one "ipv4hint" and/or "ipv6hint" keys. What happens when neither hint is present? The client should just query the local infrastructure, right? You almost say that, but not quite.
This is an interesting case. There are threat model implications to always querying the template name elsewhere. I will draft up something to address that includes a commentary on the implications for the client.