On Thu, May 21, 2020 at 8:24 AM Petr Špaček <petr.spa...@nic.cz> wrote:
> > > > https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01 > > I would appreciate a practical example of changes envisioned in the > following paragraph: > > > A common reason that zone owners want to ensure that resolvers place > > the authoritative NS RRset preferentially in their cache is that the > > TTLs may differ between the parent and child side of the zone cut. > > Some DNS Top Level Domains (TLDs) only support long fixed TTLs in > > their delegation NS sets, and this inhibits a child zone owner's > > ability to make more rapid changes to their nameserver configuration > > using a shorter TTL, if resolvers have no systematic mechanism to > > observe and cache the child NS RRset. > > Could someone please post an example in steps? Something like: > - time 0, NSSET parent = {P0}, NSSET child = {C0} > - time 1, NSSET parent = {P1}, NSSET child = {C1} > ... along with textual description what operator is hoping to achieve? > I'll try to come up with a step by step example later. But in the example cited, what the operator is trying to achieve is to change their nameserver configuration (e.g. switch to another set of nameservers for their zone) in such a way that (1) they can make that change visible to resolvers reasonably quickly, and (2) to make sure they are able to backout that change quickly if things go wrong. They can do this by lowering the TTL in the child NS set which is under their control -- assuming that resolvers are preferentially caching the child NS set, in accordance with the data ranking rules of the DNS protocol (the child NS set is authoritative). Ad 4. Delegation Revalidation: > > I agree with author's note "we would prefer to discard the extensive > mechanism" but the simple mechanism has simple description for me to > understand consequences. > I've heard the same from other implementers too. Paul V has mentioned that there are some subtle corner cases that are dealt with more precisely by the extensive algorithm (I can't recall the details right now, but maybe he will elaborate for us). Even if we end up on the simple path, it would be good to have a better understanding of those cases. > The simple mechanism: > > > > o Cap the time to cache the child NS RRset to the lower of child and > > parent NS RRset TTL. The normal iterative resolution algorithm > > will then cause delegation revalidation to naturally occur at the > > expiration of the capped child NS TTL, along with dispatching of > > the validation query to upgrade NS RRset credibility. > > So far so good, but it does not specify what should happen with RRsets > other than NS. Even if nothing is prescribed please state that explicitly.. > Thanks, yes I agree we should discuss all of these. Some quick thoughts for now .. 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. 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). Most resolvers these days already enforce a max cache TTL parameter, so that typically prevents too much abuse. But at the very least, they should probably use the revalidation interval as a signal to stop "pre-fetching" records below the cut. - 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. It might be reasonable to suggest that resolvers enforce a lower limit on the child NS TTL (5 minutes?). If they see something less than that, it would be set to the limit instead. - If it does not, is it even worth the effort if attacker can put week long > TTL for A/AAAA and keep using that? > Answered above ... > - How should resolver handle RCODE=NXDOMAIN? Should it have different > effect than changing NS set to different set of servers? If resolvers are following RFC 8020 strictly, they are pruning their cache at the delegation - that would be the ideal. Otherwise, they should allow cached records below to live on, subject to max-cache TTL and disabling of pre-fetching. Or change in DS record value? > Which value? TTL or RDATA? DS TTL expiration would automatically trigger a revalidation of the child SEP keys at the parent. RFC 4035 says DS and delegating NS TTL SHOULD match, so NS revalidation should happen on the same time scale. In reality though, they are often different (COM/NET uses 2d for NS, 1d for DS). if NS > DS, a resolver could just decide to explicitly fetch the expiring DS first and wait out the delegating NS TTL if the DS rdata has not changed. But it seems much simpler to just say that if there is a secure delegation, then the DS TTL should be used as the NS revalidation interval too. For me personally mixing two problems (GHOST domains and NS inconsistency) > in single proposal does not help me to understand reasoning behind the > proposal and its intended effects. > Ok, we'll think about how to make this clearer. But the two topics are related. If resolvers prefer the authoritative child NS set, then timely revalidation of the delegation at the parent is also necessary. Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
