Persistent cache
Jim Reid
jim at rfc1035.com
Fri Nov 1 00:23:01 UTC 2002
>>>>> "ObiWan" == ObiWan <grayhat at gmx.net> writes:
William> Is there any advantage to a persistent cache in BIND?
>> No. When a conventional server starts, it builds up a cache
>> fairly quickly. Loading old, possibly stale, data seems an
>> exercise in pointlessness. All that's saved is a bit of latency
>> perhaps and some bandwidth for DNS lookups. That will get lost
>> in the noise. Meanwhile extra complexity is added to the server
>> to dump and reload an old cache. Things will get even uglier
>> with views in BIND9. Each view has its own cache. What if the
>> server finds the view definitions changed before the restart?
>>
>> BTW, "persistent cache" is an oxymoron.
ObiWan> Well, this is not completely correct ... first of all the
ObiWan> NS records for a domain (w/o to mention MX) will get
ObiWan> cached, saved and reloaded and this will save time on
ObiWan> lookups, then for "desktop" machines (not servers) the
ObiWan> persistent cache will allow to establish a "warm-up" state
ObiWan> quicker and to use less bandwidth and this is not exactly
ObiWan> a "bad thing" imo.
None of what you say conflicts or corrects what I said earlier. It is
highly improbable that you can measure a discernable difference from
pre-loading the cache. [With stale data no less!] Remember all you're
saving is the overhead of the initial lookup. At best this is a
micro-optimisation. One big drawback of loading an old cache is that
the server is fed possibly out of date information. The consequences
of that could be far reaching and very unpleasant: much, much worse
than the cost of an extra DNS lookup or two.
More information about the bind-users
mailing list