On Thursday, 28 May 2020 14:38:11 UTC Petr Špaček wrote: > On 25. 05. 20 5:23, Shumon Huque wrote: > > ... > > Most importantly: > > - Does the NS affect maximum TTL of _other_ data in the zone? > > > > I think there are probably different views on what should happen here. > > Folks who want very prompt takedown of "bad" domains, will probably > > prefer a complete pruning of the cache at the delegation point at the > > revalidation interval, if the NS set has changed or disappeared. ...
yes, that was the original motive for revalidation itself, noting that it also facilitates emergency redelegation, for example, after a registrant/registrar account compromise. so the domain might not be bad, but the cached content might be poisonous in other ways. > > When > > this topic has come up in the past, there has been pushback from some > > implementers that it's difficult to do this because they use a non-tree > > data structure for the cache (a hash table most commonly). ... i don't think we should argue the computer science behind implementing this. if the cache doesn't facilitate "rm -r" behaviour directly, then it might choose to bookend the retrievals, such that retrieving data having a bailiwick whose timestamp is older than the revalidation event would cause deletion and refetch at the time of the encounter. these details should not enter into a discussion of whether the system should have a capability or not. > > - If it does, doesn't it increase risk of thundering herd behavior? > > > > Possibly, depending on how popular the zone is, and what we decide is the > > answer to the previous question. At any rate, implementers should always > > employ strategies that bound how much work resolvers can be caused to do. > I'm not concerned about any single resolver instance, I'm more concerned > about large number of resolver instances doing the same thing at the same > time. > > E.g. if NS TTL was short (say 30 s) and it was used as cap on TTL of all > other records in the zone, then each resolver instance would clear zone > from its cache each 30 seconds. That might cause interesting behavior when > NS TTL is shortened e.g. before NS set change etc. > > I do not know if there really is a problem, I'm just trying to explain why > potential for thundering herd needs to be be seriously analyzed. if we can think of a way that the intervals can become synchronized, then we would treat this with random subtractive revalidation. to get a thundering herd every member of the herd would have to start their interval at the same time. such synchronicity is hard to trigger. -- Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
