At Thu, 07 Sep 2017 13:42:45 -0700, Paul Vixie <p...@redbarn.org> wrote:
> > If we don't work on a proposal like this, I'd love to see a specific > > counter proposal that doesn't violate the current protocol > > specification (i.e., using a cached answer beyond its TTL) and still > > avoids resolution failure when authoritative servers are forced to be > > non-responsive due to huge scale DoS attacks. > > i think the actual problem statement is broader, and that by solving for this > narrow version, we would lose the complexity/capability tradeoff -- we'd add > more state and more signaling at a cost higher than what we would get for it. I'm not sure specifically what you mean by these, but... > it's a general reachability problem not specifically ddos problem. reasons for > not being able to refresh data in a cache include ddos, but also backhoes, > wire cutters, squirrels, circuit breakers, and bad design/provisioning. ...I agree here. I'm well aware of the generic nature of the issue, but I mentioned one specific instance of the problem in my previous message just because that's the most obvious one. > i think the right answer will look like a miniature version of IXFR/AXFR and > NOTIFY, such that a cache can register its intent to become a partial stealth > secondary server, and by participating, an authority server can both indicate > its willingness to have this done, and possibly remember what was transmitted > so as to facilitate subsequent cache invalidation or zone change notification > messaging. one could even imagine a dns cookie exchange at the outset, to help > authenticate later messages. sort of a super-lightweight session protocol. I guess we are also on the same page in a sense here. One possible justification for a behavior like draft-tale-dnsop-serve-stale is that it can be considered a recursive server variant of a secondary authoritative server that keeps using primary's zone content even if the auth server is unreachable for a certain period (until, of course, the entire zone expires). If this makes some sense, we may be able to develop a cleaner solution than serve-stale by expanding the observation. I'm not necessarily a fan of the specific approach described in draft-tale-dnsop-serve-stale, but I have to admit it's a practical workaround (if not a "solution") for a real-world problem happening today. I'd be happier if the wg agrees on working on a better solution, but in that case we should also be pragmatic. That includes the recognition that any protocol extension that requires changes to both recursive and authoritative servers will take quite long to deploy. Since the problem is real and current, the solution should have an intermediate state that might look a mere hack. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
