> > I wonder if it makes sense to be more explicit here that one isn’t > > meant to keep using expired data forever, but is expected to keep > > trying to refresh it. So, maybe?: > > > > NEW > > If the data is unable to be > > authoritatively refreshed when the TTL expires, the record MAY be > > used as though it is unexpired until an authoritative refresh is > > successful. > > END > > I think your proposed text is worse since it contradicts the current > draft, which limits the time during which you can serve stale answers > "The maximum stale timer should be configurable, and defines the > length of time after a record expires that it should be retained in > the cache. The suggested value is between 1 and 3 days. [Even if you > cannot contact the authoritative servers, my note.]"
Yes, true. So maybe add "for a period of time or" before "until" in my suggestion. Or see if you can come up with better wording. If you really think it doesn't need to be qualified here because the rest of the document takes care of it, I won't push it further. I just think it best to say *something* here that doesn't make it sound like an entirely open-ended "MAY". > > Is another possible new security consideration that bad actors could > > DDoS authoritative servers with the explicit intent of having stale > > cached information used for longer, perhaps to extend the life of a > > cache-poisoning attack or some such? > > Yes, seems right. Also reported by Viktor Dukhovni during the last > call. May be add at the end of section 10 "Attackers could be incited > to dDoS authoritative servers with the explicit intent of having stale > cached information used for longer. But if they have this capacity, > they probably could do much worse things than prolongating old data." Other than that "prolongating" isn't a word (use "prolonging the life of"), that's probably OK. Maybe add that the benefit outweighs the risk, or some such, and then we'll see what the Sec ADs think. Barry Barry _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
