FQDN cache taking over for IPcache?

I sent this once before but only recieve one reply regarding upgrading the
kernel (which does need doing, but we would have to bill the client and
they don't want to spend the money...). Does anyone know what would make
Squid's FQDN cache behave the way I describe? Please help!

--- mesage follows ---
FQDN cache taking over for ipcache? Wierd you say? I agree! Here's my
problem:

On one of my caches (running 1.1.20 with no patches, on a Linux 2.0.30
(redhat) machine using "old" BIND (pre-BIND-8)) has started using the FQDN
cache "in place" of the ipcache. I didn't change anything in the config
file when I upgraded it to 1.1.20, it still has the usual dns_children 7
and the default ipcache_size along with default high/low ipcache
watermarks. There are no references to the FQDN cache, which I think is
not enabled by default.

Cachemgr reports that there are three entries in the ipcache,
sd.cache.nlanr.net (for the cache tracker I presume), and to versions of
the machines own hostname (one with "www." preceding the rest of the name,
both are valid). There have been 142321 requests, 311 hits, and 79 misses
(according to cachemgr, although I've never trusted the "misses"). There
aren't any negative hits, and there is 1 pending hit. There has been one
call to gethostbyname(). All 7 dnsservers are up and running. I'm kinda
curious where all the requests went that wern't cache hits OR misses...

FQDN cache -- which shows nothing on all my other caches -- says that
there are 109 entires, have been 2953 requests, 586 hits, 442 pending
hits, 1345 negative hits, and 580 misses. There have been no calls to
gethostbyaddr(). Again, FQDN cache isn't active (at least not in cachemgr)
on any of my other caches, and I havn't done anything specific to this
cache that would effect FQDN cache (it was just like all the other caches
before upgrading to Squid 1.1.20).

I checked the FAQ, user's guide, and the ChangeLog that comes with Squid
and I saw nothing related to this. Since I have access to the next cache
up the hierarchy from this one (I run it too), I can see that the problem
cache apparently has been passing all it's name lookups up to it's parent
without caching them itself. The parent is working just fine. The problem
cache was working fine when it was running 1.1.18.

Pretty wierd, huh? Can anyone offer any suggestions? I have no idea what's
causing this strange problem. The rest of the cache's functions are
working fine and it moves about 70-100 MB/s a day without any user
complaints. There's just something amiss with it's DNS functions.

TIA,

        -Bill
Received on Thu Mar 12 1998 - 10:26:38 MST