> On 23. Feb 2019, at 18:54, [email protected] wrote:
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale-03
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-serve-stale-03
Section 5:
If so, it adds that data to the response message; it MUST
set the TTL of each expired record in the message greater than 0,
with 30 seconds recommended.
Can we recommend to return a value randomly from an interval to add jitter
instead? This is a common mitigation to a "thundering herd".
Section 8:
I might have missed some of the discussion but has the point of view of
authoritative servers been considered?
What I really liked about a resolver signaling its' intent to stale serve to an
authoritative nameserver is that it allows to (dynamically) lower the TTL. This
allows an operator to react more quickly to changes without decreasing the
resilience by relying on the resolver to cache. It seems equally attractive to
both CDNs and "hobbyist" deployments.
Without signaling operators of authoritative nameservers either need to (non
exhaustive):
a.) Keep the trade-off between nameserver unavailability and rate of change.
b.) Discriminate based on the resolver address
c.) Wait for further large scale experiments to determine the adoption rate of
stale serving.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
