On Sat, May 30, 2020 at 1:13 PM Gavin McCullagh <gmccull...@gmail.com> wrote:
> 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? > Gavin - yes, I agree. I was indeed deliberate in my wording about "If the NS set has changed or disappeared" to avoid creating unnecessary work for resolvers. This topic is not yet discussed in the draft, but assuming the draft is adopted and we cover it, we can make it explicit. 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? > Yeah, good catch. We need to adjust that text slightly to be compatible with qname minimization, which should be pretty straightforward - it's just pruning the requisite number of left most labels for the enclosing zone. Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
