The one place for your designs
To enable design management, you'll need to meet the requirements. If you need help, reach out to our support team for assistance.
Feature request: Adapt BIND cache management so that fetched RRsets with TTL=0 use a different 'throw-away' cache
Inspired by Support ticket #16297
The problem is the cache can get filled up with TTL=0 records, causing the resolver to 'grind to a halt.'
For BIND resolvers that routinely field a large proportion of client queries that result in authoritative RRsets with TTL=0 (and we only have to look back at other reports where we've had problems making sure that TTL=0 content is handled properly and served solely to the clients making the query originally or which have been added to the fetch via clients-per-query before it has been complete, to know that these environments do exist...), can't we just avoid adding them to cache at all?
Suggestion:
A new TTL=0 cache This would be used as a temporary storage place for all content that comes back with TTL=0 but which needs to persist for the lifetime of the client queries that are waiting for recursion to complete (so might include some intermediate fetch results as well as the answers needed for the client query responses. When serving responses to clients, use both main cache and TTL=0 cache. (OR perhaps there could be a way to flag to the tasks responding to clients that they should also look in TTL=0 cache when assembling the query response)
I would hope, given that the content is due to be thrown away as soon as all the clients have been responded to, that it might be easier to manage this in terms of access control than in main cache.
The big advantage to main cache, is that this content is kept out of it, thus reducing cache flux and cache maintenance overhead involved in adding and then cleaning up these non-persisting RRsets.
(Implementing this would also obviate the need to action #1829 )