On Wed, Oct 17, 2018 at 1:45 PM Dave Lawrence <[email protected]> wrote:
> [email protected] 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.
>
I would suggest a combination:
OPTION-CODE
OPTION-LENGTH
| D | U | S | V | RESERVED
STALE-RRSET-INDEX 1
TTL-EXPIRY 1
....
V - verbose flag. Set to 1 by client if they want the individual
stale-rrset-index's returned.
Set to 0 if they only want the flags returned.
> 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."
>
One week sounds good as a default maximum (MAY be configurable).
> 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.
>
30 seconds is good. (May be configurable)
> Recommended that refresh attempts from the recursive to the
> authorities happen no more frequently than every 30 seconds.
>
Agreed. (MAY be configurable)
> 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.
>
Yes, that is worth mentioning, since some users won't immediately think of
that, and implementers should plan for that, so that compatible
implementations work the same.
--
Bob Harold
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
