On Sun 2022-04-10 11:57:40 -0700, Christian Huitema wrote: > But Sara has a point, we should give servers a way to control the > deployment.
Authoritative servers do have a way to control deployment: they can simply refuse connections on encrypted transport. Rather than refusing arbitrary connections haphazardly on the basis of time of arrival (or some other unrelated feature), though, maybe we should offer guidance on how to selectively refuse connections on the basis of the client IP address (to avoid state-flapping on the recursive resolver side). I've noted this as https://gitlab.com/dkg/dprive-unilateral-probing/-/issues/22 > Servers could very well be flooded with queries just after starting to > test DoT and DoQ. We should address that by changing the server > responses, not the client queries. For example, we might want to define > an extended DNS error message rejecting a query because the capacity to > process encrypted requests is exceeded. And we might want to specify > that clients receiving such messages should stop unilateral attempts to > use that server for a while. DoT or DoQ servers could use that to > progressively enable the service for a fraction of their clients, maybe > using some kind of filter based on the client's IP. I'd be game to use this document to define such an extended error message, but i don't understand how its semantics would differ from merely rejecting the connection attempt with an ICMP Port Unreachable message (which non-implementing authoritative servers will send anyway). In a strongly-authenticated protocol, the difference between an extended DNS error code and ICMP Port Unreachable would be that the client could rely on the authenticity of the DNS error code (ICMP Port Unreachable is of course always spoofable by the network path). But in this opportunistic deployment, both signals are spoofable. Maybe the concern is that the authoritative server implementation might not have control over the full stack enough to respond ICMP Port Unreachable to a specific subset of client IP addresses. In that case, i can imagine two distinct modes of operation: - the server only has the opportunity to respond after the TLS/QUIC handshake is complete. In this case, i don't see why the server shouldn't just go ahead and handle the query; some part of the stack has already borne the connection setup costs. - the server can respond early during the TLS/QUIC handshake. In this case, we'd want to define an error at that layer, so that the authoritative server can signal failure without incurring any additional connection costs. Does this analysis seem right to you? Or is there a reason that i'm missing that an authoritative server would want to have the signal at the layer where a extended DNS error message would make sense? --dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
