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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
