bind caching algorithm?

[Kevin Darcy]

Yes, it was a bad design, and BIND 9 was written from scratch to address 
this among many other design issues. One can set a "max-cache-size" in 
BIND 9 and -- according to the documentation at least -- if that limit 
is reached, older records will be expired prematurely in order to free 
up memory for newer records. I haven't actually tested this 
functionality however...

- Kevin

KyoungSoo Park wrote:

>Cleaning up the TTL-expired records is totally fine and
>having records until its TTL expires is also good when there is no 
>memory pressure.
>But this cleaning scheme should not be the only algorithm to evict the 
>cached items.
>The reason why I said it's not a good design is because I got the 
>impression this periodic cleaning
>is the only scheme that BIND-4 and 8 is using if Barry is right.
>I expected a kind of statistical evicting algorithm when the caching 
>buckets are full.
>Maybe BIND designer expect most records will expire soon before worrying 
>about the memory pressure,
>but that's not true.
>
>KyoungSoo
>
>  
>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>When it looks up an existing cached record, it checks whether its TTL 
>>>>has expired, and evicts it if so.  Also, there's a periodic "cleaning" 
>>>>that scans the entire cache, evicting all records that have expired; the 
>>>>frequency of this is controlled by the "clean-interval" named.conf 
>>>>option.
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>This seems clearly not a good design. I think the evicting algorithm 
>>>should have a mechanism of
>>>reflecting the past and/or future usage at the very least. What's the 
>>>intuition behind this?
>>>
>>>   
>>>
>>>      
>>>
>>The intuition is that the owner/administrator of a particular DNS datum 
>>is, within reasonable limits, the one who controls how volatile their 
>>datum is. Statistical methods are fine when you have nothing else to go 
>>on, but when the owner/administrator can tell you, through the protocol, 
>>how volatile a particular piece of data is, experience has shown that it 
>>is best to heed that command, at least as a maximum, i.e. it's OK to 
>>re-fetch the data from an authoritative source *before* the TTL has 
>>expired (and in fact, in memory-poor situations, you may need to 
>>prematurely evict data, thus trading off between memory usage and 
>>network usage), but it is almost uniformly a *bad* idea to hold onto 
>>data for which the administrator-set TTL has expired.
>>
>>- Kevin
>>
>>
>> 
>>
>>    
>>
>
>
>
>
>
>  
>