[GH-ISSUE #2106] RFC 8767: Serve Stale Records #889

New issue

Open

opened 2026-03-16 00:45:23 +03:00 by kerem · 2 comments

kerem commented

2026-03-16 00:45:23 +03:00

Owner

Originally created by @lrouquette on GitHub (Dec 6, 2023).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2106

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).

Originally created by @lrouquette on GitHub (Dec 6, 2023). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2106 **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).

kerem added the

enhance

crate:resolver

crate:recursor

labels

2026-03-16 00:45:23 +03:00

kerem commented

2026-03-16 00:45:34 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jan 28, 2024):

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.

@bluejekyll commented on GitHub (Jan 28, 2024): 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, ```text - 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.

kerem commented

2026-03-16 00:45:39 +03:00

Author

Owner

@LeeTeng2001 commented on GitHub (Jun 23, 2025):

bump, would love to see this feature

@LeeTeng2001 commented on GitHub (Jun 23, 2025): bump, would love to see this feature

kerem referenced this issue

2026-03-16 02:24:23 +03:00

[PR #889] [MERGED] Add valid_until method for specific resolver lookup results #1767