Thanks for the review! On Sep 7, 2023, at 7:16 AM, Bron Gondwana via Datatracker <noreply@xxxxxxxx> 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). 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? --Paul Hoffman -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
