Hi, On Thu, May 28, 2020 at 8:56 AM Paul Vixie <p...@redbarn.org> 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop