You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Optimistic caching and serving stale records are great for performance, but in today's implementation it's depending on the cache to be filled up before anything is deleted. If using a big cache-size a record could live in the cache for weeks leading to old data.
Suggestion for three configurable parameters to make DNSProxy RFC 8767 compliant and give the DNS-admin full control:
1. "stale-answer-ttl"
Defines the TTL for a stale record. Today it's hardcoded to 10 seconds, but RFC 8767 recommends a value of 30 seconds for stale records.
2. "max-stale-ttl"
Defines how long a stale record can live in the cache. Recommended values from RFC 8767 is 1-3 days.
3. "stale-refresh-time"
The period for serving a stale answer while updating it upstream. RFC 8767 recommends 30 seconds or higher.
Background:
Optimistic caching and serving stale records are great for performance, but in today's implementation it's depending on the cache to be filled up before anything is deleted. If using a big cache-size a record could live in the cache for weeks leading to old data.
Suggestion for three configurable parameters to make DNSProxy RFC 8767 compliant and give the DNS-admin full control:
1. "stale-answer-ttl"
Defines the TTL for a stale record. Today it's hardcoded to 10 seconds, but RFC 8767 recommends a value of 30 seconds for stale records.
2. "max-stale-ttl"
Defines how long a stale record can live in the cache. Recommended values from RFC 8767 is 1-3 days.
3. "stale-refresh-time"
The period for serving a stale answer while updating it upstream. RFC 8767 recommends 30 seconds or higher.
Sources:
https://www.rfc-editor.org/rfc/rfc8767
https://www.isc.org/blogs/2020-serve-stale/
The text was updated successfully, but these errors were encountered: