On Saturday, 30 May 2020 17:13:10 UTC Gavin McCullagh wrote: > ... > > 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.
i hadn't seen that possible interpretation, and never intended that potential outcome, so thank you for explaining that the draft language is unclear in that way. > > 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 there are two discussable matters there. first, the thundering herd would still have to be externally synchronized somehow, or else each member of the herd would begin their 300-second cycle independently, and never thunder. second, the only condition under which "rm -r $apex" would occur in the cache is if the delegation point disappears or if it rolls over 100% (no NS RRs in common between two successive NS RRsets seen during delegation.) so, very rare. we can clarify the language to remove the possible misinterpretation you're describing. > 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? yes, apparently so :-). > 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. until and unless we have a way for authorities to notify existing caches that a delegation has changed (either in content of NS or DS RRset, or A/AAAA glue under the delegation point, or TTL of any of that), then the change in your example would not be seen by all caches at the same time, which means they could not synchronize their revalidation cycles into a thundering herd. as an interesting corner case, an RFC2308 negative proof that included a delegation section could cause an updated delegation to be seen immediately by a large number of caches, for example during a randomized subdomain attack. it seems possible that this latent attack vector deserves mention in the revalidation draft, but i'm not sure how to describe "synchrony should be avoided" other than to say that caches practicing delegation revalidation ought to begin this process at a random time during the last 20% of the delegating TTL, to avoid becoming part of a thundering herd if their original delegation reception time was somehow broadly synchronized. > > 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? that language predates Q-M, so thanks for noticing the mismatch. we'll have to say "whatever query would normally be forwarded to the authority". what we're trying to avoid is making an NS query for the delegation, since that's considered by many authority operators as a diagnostic query that they can't or won't answer. but i agree, this has to be updated to cover the Q-M method. -- Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
