Re: bind caching algorithm?

KyoungSoo Park wrote:

>Barry Margolin wrote:
>
>
>
>>In article <c4sk89$12bh$1@sf1.isc.org>,
>>KyoungSoo Park <kyoungso@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