神明達哉 wrote:
At Wed, 15 Nov 2017 05:41:04 +0000,
P Vix<[email protected]> wrote:
1) when the request explicitly signals it is ok;
2) when the request groks EDNS but might or might not understand
a staleness option; or
3) in all cases.
My current understanding is that you and Paul are of position 1, while
I'm at 3. At first glance 2 would appear to be pretty nearly the same
as 3 as far as its permissive toward unaware clients, but
significantly it does at least provide signal you could still access
via protocol debugging (dig, tcpdump, etc).
I expect you to implement 3. I expect us to document 1.
Realistically, I expect virtually everyone will implement 3, given how
this kind of feature is sold in the marketing context. ,,,
me too. that's why, in:
https://mailarchive.ietf.org/arch/msg/dnsop/zRuuXkwmklMHFvl_Qqzn2N0SOGY/?qid=ff8e732c964b76fed3bbf333b89b111f
...i wrote:
therefore a "serve stale" team within IETF-DNSOP was convened, to try to
standardize the methods and signal patterns necessary to extend the
usability lifetime of records when their authority servers are not
reachable at the time of normal TTL-based expiry. most of us recognize
that TTL's will continue to be stretched no matter what changes are or
are not made to the specification, and so we expect the resulting RFC to
document current practice _without recommending it_ and to also document
a new practice _with recommendations_ as to its proper uses.
comments would be very welcome.
--
P Vixie
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
