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