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

[Vladimír Čunát <[e-mail]>]

On 09/05/2017 09:25 PM, tjw ietf wrote:
> This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale
I do support the adoption.  We plan to support some kind of
stale-serving in knot-resolver soon, so
I'm certainly willing to review and perhaps contribute some suggestions.

Still, I wonder about the intended level of vagueness of the text.  Is
it meant that the final RFC will leave (larger) unspecified corners?

One issue I see is the case when servers for some zone don't respond but
they (are expected to) only provide a *lead* to the final answer, e.g. a
delegation or a CNAME elsewhere.  In that case it seems useless to wait
without
action until the client timer fires, because we (typically) need at
least one more round-trip to get the final answer.  It might be also
good to touch the issue of negative caching of non-responsivity for some
short time (rfc2308.7.2) and consequently serving stale records
*immediately*.  There's a tradeoff between stale-ness and many resolvers
legitimately hammering servers that are/were under attack (or simply
broken).

I personally think that the length of stale-serving should derive from
the original TTL in some way, as very short TTL suggests the value is
more likely to change and operator doesn't mind increased traffic.
(Raised at IETF99, I think.)  The security section should perhaps stress
that the technique may effectively extend the range of validity in
RRSIGs, as served by validating resolvers (unless I misunderstand the
draft).  I suppose the AD flag might get zeroed in that case, but that
seems not to make much difference in practice (and we *do* want the
stale records, right?)

--Vladimir