is my caching server caching responses to queries from other machines on my LAN?
Ladislav Vobr
lvobr at ies.etisalat.ae
Fri Sep 10 22:51:07 UTC 2004
Barry Margolin wrote:
> In article <chr9qi$1o3i$1 at sf1.isc.org>, zast at verizon.net (nic stage)
> wrote:
>
>
>>i bet there is a better way for me to check what responses were cached
>>than just guessing based on dig response times, but i haven't found
>>out how. any help would be greatly appreciated, and i'll look around
>>and see if i can help someone else right now too.
>
>
> "rndc dumpdb" will dump the cache to a text file.
Just a small comment here, there is a bind internall cache and bind
clients cache (these are my own definitons :-)), the borders are not
clear (maybe to me only :-) ) but by looking into the file you see what
bind has cached for itself, but how bind decides about it, whether it
will provide it when clients ask or it will initiate recursion to get
something better, or refuse it even to +norec clients there are no
details on it documented anywhere.
so you can not really say that if you see a.b.c.d cached in the
named_dump.db, your clients will be able to get it as a answer. (btw try
to explain it to your manager :-), that bind should be caching and is in
fact caching but there are some unknown unclear reasons, why nobody
other then bind itself really can see what it is caching very funny :-) )
I know barry you didn't say that, I just mentioned that, so people will
not think that whatever they see in the named_dump.db is provided to the
clients, since I believe general opinion is that if you see it in the
cache it is cached and clients will get it, I believed it myself, but
bind showed me many times that it would be too simple to be true :-)
Ladislav
>
> Also, when you use "dig" to query something, look at the TTL. If it's
> not a nice multiple of 60, there's at least a 95% chance that it came
> from the cache.
>
More information about the bind-users
mailing list