Re: [DNSOP] New draft on delegation revalidation

[Gavin McCullagh <[e-mail]>]

Hi,

On Thu, May 28, 2020 at 8:56 AM Paul Vixie <[e-mail]> wrote:

> 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. ...
>

Those last few words seem very critical.  "If the NS set has changed or
disappeared".


> > 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.
>

I think Petr's point might be that someone could interpret the draft
(perhaps especially the simple mechanism) to mean that the NS TTL becomes
an effective cap on the TTL of all records below the zone cut even where
the NS set has not changed.

If lowering a delegating NS TTL to 300 for a very large zone (or one high
up the tree) meant a lot of resolvers might expire every record below the
zone cut every 300 seconds (even unsynchronized), then it seems like
lowering that TTL could produce a thundering herd.   I think the intent of
the draft and Shumon's quote above are that a resolver should only expire
cached subdomain records when the delegating NS changes.   Would it be
useful to be explicit about that?

I imagine even the NS revalidation means that if an operator lowers a
delegating NS TTL to e.g. 300 in advance of a change in order to "make that
change visible to resolvers reasonably quickly", they might well see a 300
second long period of thunder immediately after the change while every
resolver's cache expires that part of the tree and then fills it back up.

One minor other question:

      To revalidate a delegation, the iterative caching DNS resolver
      will forward the query that triggered revalidation to the
      nameservers at the closest enclosing zone cut above the
      revalidation point.

Does "the query that triggered revalidation" refer to the original client
query which had RD=1?  If so, does this fit with qname minimization?

Gavin