On Wed, Sep 11, 2019 at 12:06:23PM -0400, Barry Leiba <[email protected]> wrote a message of 75 lines which said:
> 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.]" > 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." _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
