On Thu, Sep 7, 2023 at 7:15 PM Paul Hoffman <paul.hoff...@icann.org> wrote:
> On Sep 7, 2023, at 6:58 PM, Bron Gondwana <br...@fastmailteam.com> wrote: > >> 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. > I think you might want to rephrase this part. It seems like you really mean retries asymptotically approaching a 1 day timeout. What I've found works is exponential backoff that doesn't get too pessimistic, and also contains some amount of uncertain time intervals. It seems very dumb at first. But, if one piece breaks that may have nothing to do with DNS, you will get a stampede. Introducing a little bit of uncertainty can help. thanks, Rob
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
