On Sep 7, 2023, at 6:58 PM, Bron Gondwana <br...@fastmailteam.com> wrote: > > On Fri, Sep 8, 2023, at 02:18, Paul Hoffman wrote: >> Thanks for the review! >> >> On Sep 7, 2023, at 7:16 AM, Bron Gondwana via Datatracker <nore...@ietf.org> >> wrote: >> >> > My only concern is that it does fall back very easily to cleartext, for a >> > long >> > damping period. As a protocol implementer myself, I would generally >> > expect to >> > retry something one or two more times over the course of a few minutes >> > before >> > giving up entirely for 24h, since the server at the other end may have just >> > been restarting and either dropped an existing connection or rejected a SYN >> > packet, but be ready a moment later. I'd be happy with a limit of >> > something >> > like 5 tries over 2 minutes (one every 30 seconds) before giving up. >> >> In Section 4.3, the "damping" parameter has a "suggested default" of 1 day. >> That's a suggestion, not at all a requirement. It was established based on >> the idea that almost every domain name has multiple nameservers, and that it >> is likely that if one server has a failure such as a timeout, the resolver >> will try the other nameservers (which may or may not be encrypting). > > Yeah, that bit makes sense, so you'll wind up with one of them having > encrypted connection and the other not - so you'll probably want to default > to sending further requests to that once since you have it tagged as > available for encryption. > >> Are you proposing a shorter value for "damping", or a note saying "1 day is >> just the suggested value, you might choose a shorter one if you want"? Or >> something else? > > I'm suggesting a backoff algorithm which isn't "single failure gives you N > hours of no retry" - particularly, if you have an existing encrypted > connection and it has a fault, my reading was that you don't retry at all to > form an encrypted connection, even when talking to somewhere that has > previously succeeded. I agree you don't want to try more than once per day > against a server that's never supported encryption, but if you have had > consistent success encrypting to a server, then a single failure, you don't > want to be treating that one the same! It's definitely worth retrying faster > than a full day later.
This sounds like you want a smaller value than 1 day for `damping` then. Because those parameters are only suggested defaults, a resolver operator like you could simply change the 1 day to maybe 1 hour, with the risk of slowing down resolution to that one nameserver. --Paul Hoffman _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
