Draft: draft-ietf-add-ddr

Commentary: 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 does n'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 was n’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 do n’t arrive . Discovery based on IP addresses is done with an SVCB query for , and no other query types are allowed for By definition , this only works with SVCB . That does n’t mean that a client ca n’t be SVCB optional for its general operation — it just means that if SVCB is blocked or fails , you do n’t get to discover the encrypted resolver . What do we need to say here that would actually benefit things ? 
 So SVCB - optional does n'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 does n’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 does n’t make sense to connect to ; this is a special purpose SVCB query used for discovery , which can lead to a connection . I do n’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 . That it uses " " does n't change the overall goal . 
 Until a client uses the SVCB query for discovery , it does n’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 should n’t say it because it ’s really about client policy for allowing unencrypted DNS . If it ’s the latter , I do n’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 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 do n'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 do n'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 .
Since clients can receive DNS SVCB answers over unencrypted DNS, on-
path attackers can prevent successful discovery by dropping SVCB
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.
Since clients can receive DNS SVCB answers over unencrypted DNS, on-
path attackers can prevent successful discovery by dropping SVCB
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.