Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC 8767: Serve Stale Records #2106

Open
lrouquette opened this issue Dec 6, 2023 · 1 comment
Open

RFC 8767: Serve Stale Records #2106

lrouquette opened this issue Dec 6, 2023 · 1 comment

Comments

@lrouquette
Copy link

Is your feature request related to a problem? Please describe.
Improve DNS resiliency by serving stale records per (proposed) RFC 8767: https://tools.ietf.org/html/rfc8767

I wanted to see if there was interest to support this (or perhaps work is already under way).

@bluejekyll
Copy link
Member

Yes, I think this would be good. rfc 8767 only discusses recursive resolution, I would think we should also do this for the stub resolver as well. In terms of implementation, it seems like we might need a new timer,

- A client response timer, which is the maximum amount of time a recursive resolver should allow between the receipt of a resolution request and sending its response.
- A query resolution timer, which caps the total amount of time a recursive resolver spends processing the query.
- A failure recheck timer, which limits the frequency at which a failed lookup will be attempted again.
- A maximum stale timer, which caps the amount of time that records will be kept past their expiration.

I'd have to check, but I think the LRU cache we use has max_ttls, min_ttls, plus the record ttls. We could see if those meet some of these requirements? The logic would need to be changed to hold onto the cached record and wait for a timeout before returning. That timeout probably needs to be revisited in this case. Separately, if a response does come in during that time, the recursor should be able to update the cache, but I'm not sure if the resolver will be able to, that will be somewhat complex logic to get right as we have some of the connection lifetime bound to the return methods.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants