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