神明達哉 wrote:
At Thu, 16 Nov 2017 22:02:33 -0800,
Paul Vixie<[email protected]> wrote:
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.
This (including the entire message) looks reasonable to me, as long as
we mean it, i.e., we actually seriously work on the "new practice" as
a followup wg task, rather than just using it as an excuse to publish
the current serve-stale draft.
later in [ibid], i wrote:
this system would allow gradual insertion of the new state management
logic on an opportunistic basis -- motivated authority and recursive
server operators, which would include CDN operators who must perform
both services perfectly -- would be early adopters, and like ECS before
it, the "hot" part of the community would be upgraded years earlier than
the last outlier.
i think that it's in the large RDNS operators' interests, and in the
large authority operators' interests, and in CDN and proxy operators'
interests, to deploy these new protocols -- and that once they see
positive results, they will find it in their best interests to turn off
the older pre-standard TTL stretching logic that should be described,
but _not recommended_, in the TTL-stretch specification.
if i could not visualize a fully interest-aligned deployment path for
the operators who most need TTL stretching, then i would agree with your
concern that we might not "mean" it.
But I'd note there might be some confusion here (perhaps only for me,
though). I've been having the impression that we are talking about
"signalling" between the stub and caching (usually recursive) server,
perhaps because it's a followup of this message:
https://www.ietf.org/mail-archive/web/dnsop/current/msg21339.html
But your suggestion is signalling (mainly) between caching and
authoritative servers, right?
yes. i don't think anything that requires end-system upgrades is going
to answer the market need for TTL stretching. even "happy eyeballs" took
five years to be adopted and another two years to stabilize.
I thought recommending to allow fallback to stale
1) when the request explicitly signals it is ok;
between stub and caching wasn't realistic, as I didn't see a strong
incentive for the developers and users of stub (except for
protocol-savvy kinds). That's why I was pessimistic in my previous
message. I see more reality if it's about signalling between caching
and authoritative since, as you pointed out, there may also be
incentive for authoritative operators to adopt the "new practice".
the TTL stretching specification should ideally introduce new stub
signalling to turn off stretching, so that those of us using "dig" in
diagnostic mode, can learn more about the TTL-state of the RRset in our
local RDNS.
--
P Vixie
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
