On Tue, Sep 12, 2023 at 5:26 PM Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote:
> > Thanks for all this discussion. The main purpose of having any sort of > damping in the draft is to encourage operators of authoritative servers > that they will not find themselves in trouble even if they enable > encrypted transport briefly for experimentation or evaluation, and then > turn it off again. > > There are two kinds of trouble that such an authoritative server could > find itself in: > > a) It could be flooded with queries on a transport that it no longer > supports. > > b) Queries from recursive resolvers could fail or be substantially > delayed when the encrypted transport is disabled. > > The `damping` parameter primarily influences (a), which i'd argue is > likely the less-important of the two, operationally, since it doesn't > cost the authoritative operator that much to send a "port closed" ICMP > response. ((b) is influenced more by the `timeout` parameter.) > [...] >From my perspective, the simple approach described in the draft is a > good opportunistic baseline -- minimally complex, works fine > (opportunistically) with a functioning server in the absence of an > active attacker, and fails gracefully in the face of errors on the > server side. > I still think this is wrong, because connection establishment is the expensive thing here. But I don't object strongly. Let's say the server network hardware gets unplugged for 30 seconds. Does everyone then try to re-establish an encrypted connection 24 hours later? In this situation, the operator cannot send a "send a 'port closed' ICMP response", because the network is broken. The reason to insert at least a little bit of variability in the retry requests is to help bring up a server after something close to the server breaks. The other way to deal with this problem is to arbitrarily reject connections at the server as things come back up, but the draft then recommends another 24 hours. thanks, Rob thanks, Rob
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
