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: That it uses "URL" doesn't change the overall goal.
Until a client uses the SVCB query for discovery, it doesn’t know if an encrypted resolver exists that is designated. I’m not sure if saying a DDR-aware client is “SVCB-reliant” means that it will not use the unencrypted resolver for application queries until it discovers an encrypted resolver (which is not a requirement, obviously, since clients can be allowed to continue using unencrypted DNS if their local policy allows it), or it means that the connection to the discovered encrypted DNS server is SVCB-reliant, which is tautologically true since the existence of said server was only discovered via SVCB. If it’s the former, we shouldn’t say it because it’s really about client policy for allowing unencrypted DNS. If it’s the latter, I don’t see the value of adding anything, and I’m not sure it really fits the meaning of “reliant”.
I believe DDR clients' recommended behavior is exactly the behavior recommended in Section 8.2 of SVCB-DNS, quoted above. It is initially SVCB-optional, and becomes SVCB-reliant once SVCB resolution succeeds. Specifically: if you do discover an encrypted resolver, and you attempt connection, you SHOULD NOT fall back to unencrypted if that connection fails. Otherwise, you've added a downgrade vulnerability to attackers on the "transport path" (which may not be the same as the bootstrap-query path). As this is the default recommendation for SVCB-DNS, I don't think any additional normative language is strictly required. However, I think a reminder might be appropriate. This does not address the question of whether to wait for SVCB resolution before issuing any initial queries. As a practical matter, I don't think we can require that.
Okay, I agree with the behavior you describe there of being initially optional and then becoming reliant. I can try to find a place where it makes sense to reference that section.