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
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).
The text was updated successfully, but these errors were encountered:
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.
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).
The text was updated successfully, but these errors were encountered: