Code change:
Since clients can receive DNS SVCB answers over unencrypted DNS, on- path attackers can prevent successful discovery by dropping SVCB <del> queries or answers.  Clients should be aware that it might not be possible to distinguish between resolvers that do not have any Designated Resolver and such an active attack.  To limit the impact of discovery queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. </del> <ins> queries or answers, and thus prevent clients from switching to use encrypted DNS.  Clients should be aware that it might not be possible to distinguish between resolvers that do not have any Designated Resolver and such an active attack.  To limit the impact of discovery queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. Section 8.2 of I-D.ietf-add-svcb-dns describes a second downgrade 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, unless verification of the resolver fails. </ins> DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the

Related discussion:
text: I think that the answer here is that DDR resolution is SVCB-reliant as defined in the SVCB spec. Can you make that explicit please?
says It sounds like you're saying that DDR should adopt this without adjustments. That seems reasonable to me.
Right. I sort of assumed that it was SVCB-reliant, but it doesn't say that. Certainly, this is not a case where any deviation from spec is necessary. (The more of those we have, the better.)
DDR predates when the reliant and optional terms came about, which is why it wasn’t covered. I’m not clear on why anything would need to be said here. Reliant and optional seem to be modes for the client to block on getting SVCB records or falling back and ignoring them if they don’t arrive. Discovery based on IP addresses is done with an SVCB query for URL, and no other query types are allowed for URL By definition, this only works with SVCB. That doesn’t mean that a client can’t be SVCB optional for its general operation — it just means that if SVCB is blocked or fails, you don’t get to discover the encrypted resolver. What do we need to say here that would actually benefit things?
So SVCB-optional doesn't even make sense for this specification. I was just looking for a nudge in the form of: "The resolver/client uses SVCB in a SVCB-reliant mode." Just so that there is no confusion.
Yes, optional doesn’t make sense. But I still think that the entire reliant/optional choice is orthogonal to how DDR works. These are the two lines that mention reliant mode in the SVCB spec: Both of these seem to be about client behavior for connection establishment to a hostname. It’s specifically about connecting. It doesn’t make sense to connect to URL; this is a special purpose SVCB query used for discovery, which can lead to a connection. I don’t see any requirement from the SVCB spec that protocols that use SVCB need to define themselves as “reliant” or “optional”. Is there something I’m missing there?
How is this not about connecting from the point at which you feed the name into a SVCB query? A DDR client is trying to connect to a (secure) resolver. To that end, it is making a SVCB query.