bind caching algorithm?

[Kevin Darcy]

KyoungSoo Park wrote:

>Barry Margolin wrote:
>
>  
>
>>In article <c4sk89$12bh$1 at sf1.isc.org>,
>>KyoungSoo Park <kyoungso at cs.princeton.edu> wrote:
>>
>> 
>>
>>    
>>
>>>Hi,
>>>
>>>Is there anyone who's familar with bind's caching algorithm?
>>>I know it's based on TTLs of the result records, but there should be an 
>>>evicting algorthm as well.
>>>How does bind do cache eviction? LRU, LFU ... ?
>>>   
>>>
>>>      
>>>
>>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