Re: bind caching algorithm?

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
>
>
>
>