internet-dra...@ietf.org writes:
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-02
Here's a summary of the functional updates:
Puneet Sood @ Google added as co-author in the short-lived -01.
A second, simpler EDNS option for signaling is proposed for
discussion. That makes:
* Option 1: Capable of identifying exactly which RRSets are stale so
that a stub can use that information to handle each exactly as
desired.
* Option 2: Simplified to only indicate that stale data appears in
the answer, but not where.
A discussion note for the updated TTL definition, that "capping values
with the high order bit as being max positive, rather than 0, is a
change from [RFC2181]. Also, we could use this opportunity to
recommend a much more sane maximum value like 604800 seconds, which is
one week, instead of the literal maximum of 68 years."
Raised the suggested response TTL on stale records to 30 seconds, from
1 second. That's in the message from the recursive to its client.
Recommended that refresh attempts from the recursive to the
authorities happen no more frequently than every 30 seconds.
One thing I've realized isn't mentioned in the draft but maybe should
be is that even in the absence of an EDNS option stale data can also
be disabled by the client request if it asks without the recurse flag
on (dig +norec). Since serve-stale as proposed relies on recursion
failing, if there was no attempted recursion that could have failed
there will be no revisiting the cache to find stale answers.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
