[GH-ISSUE #1720] Add more substantial caching to the recursor #748

New issue

Closed

opened 2026-03-16 00:07:24 +03:00 by kerem · 2 comments

kerem commented

2026-03-16 00:07:24 +03:00

Owner

Originally created by @bluejekyll on GitHub (Jun 6, 2022).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1720

Is your feature request related to a problem? Please describe.

Once #1710 is merged, we should add a new caching authority that sits in front of the recursor requests and make sure it is suitable for large numbers of requests. Consider making the max and min TTLs be configurable by record type as well.

Describe the solution you'd like

The recursive resolver has an LRU integrated to day, but it is not currently configurable. The max and min TTLs for the LRU should be exposed to the config file in the server for the recursor (these should be added to the forwarder/resolver config as well to be consistent).

Originally created by @bluejekyll on GitHub (Jun 6, 2022). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1720 **Is your feature request related to a problem? Please describe.** Once #1710 is merged, we should add a new caching authority that sits in front of the recursor requests and make sure it is suitable for large numbers of requests. Consider making the max and min TTLs be configurable by record type as well. **Describe the solution you'd like** The recursive resolver has an LRU integrated to day, but it is not currently configurable. The max and min TTLs for the LRU should be exposed to the config file in the server for the recursor (these should be added to the forwarder/resolver config as well to be consistent).

kerem

2026-03-16 00:07:24 +03:00

closed this issue
added the
perf

crate:resolver

crate:recursor
labels

kerem commented

2026-03-16 00:07:40 +03:00

Author

Owner

@divergentdave commented on GitHub (Oct 25, 2024):

Is #2524 sufficient to close out this issue?

I think the recursor's internal LRU cache is preferable to the idea of a separate caching authority from the first paragraph. If the cache and the recursor were separated by a layer of encapsulation, that would preclude caching internally-generated queries for nameserver referrals, etc.

The forwarder/resolver config currently includes minimum and maximum TTL values. I did not add the ability to change these for particular record types to the resolver config, as I did to the recursor config. If there's interest in doing so, that should be straightforward, though we'll have to decide what the configuration should look like, and how to handle backwards compatibility of positive_min_ttl, etc. at the top-level of ResolverOpts.

@divergentdave commented on GitHub (Oct 25, 2024): Is #2524 sufficient to close out this issue? I think the recursor's internal LRU cache is preferable to the idea of a separate caching authority from the first paragraph. If the cache and the recursor were separated by a layer of encapsulation, that would preclude caching internally-generated queries for nameserver referrals, etc. The forwarder/resolver config currently includes minimum and maximum TTL values. I did not add the ability to change these for particular record types to the resolver config, as I did to the recursor config. If there's interest in doing so, that should be straightforward, though we'll have to decide what the configuration should look like, and how to handle backwards compatibility of `positive_min_ttl`, etc. at the top-level of `ResolverOpts`.

kerem commented

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

Author

Owner

@bluejekyll commented on GitHub (Oct 25, 2024):

This looks great! thanks for getting all those changes in. I agree that I think this is resolved with your changes.

@bluejekyll commented on GitHub (Oct 25, 2024): This looks great! thanks for getting all those changes in. I agree that I think this is resolved with your changes.

kerem referenced this issue

2026-03-16 02:18:08 +03:00

[PR #748] [MERGED] fix clippy warnings from 1.34 #1653