Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

[神明達哉 <[e-mail]>]

At Thu, 07 Sep 2017 13:42:45 -0700,
Paul Vixie <[e-mail]> 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