Re: [DNSOP] New draft on delegation revalidation

[Paul Vixie <[e-mail]>]

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