Re: broken dnsservers

From: Duane Wessels <>
Date: Sat, 04 Jul 1998 23:08:39 -0600

Andy Farkas writes:

>I am having problems with dnsservers blocking and refusing to do requests,
>eventually to the point where I have to manually stop squid, then
>individually kill off the dnsserver processes. Can somebody point me in
>the right direction to help me find out what's wrong?
>I know the name server is working, it has been for the past 12 months ...
>but I do notice A LOT of lame servers and bad referrals that named logs.
> Is this BIND related??
> PII-233 128mb 6.1g scsi running FreeBSD 2.2.6, Squid 1.1.20


>Squid Config:
>- no cache_host entries
>- cache_mem 64
>- cache_swap 2048
>- cache_dns_program /usr/local/squid/bin/dnsserver
>- dns_children 32
>- dns_defnames off
>- (any others you need to know?)
>here is what cachemgr.cgi says:
>DNSServer Statistics:
>dnsserver requests: 5233
>dnsserver replies: 9365


>dnsservers status:
>dnsserver #1:
>Flags: AB
>FDs (in/out): 5/5
>Alive since: Sat, 04 Jul 1998 10:41:18 GMT
>Last Dispatched: 53330.738 seconds ago
>Read Buffer Size: 4095 bytes
>Read Offset: 0 bytes

Well, there are a couple of possibilities.

One possibility is that the gethostbyname() call really is blocked
in the dnsserver processes. One thing you might try is upgrade
your BIND library. Then recompile Squid to link with the new

Another possibility is that the dnsservers aren't really blocked
on gethostbyname(), but the dnsserver <-> squid inter process
communication is confused. One thing which is common on
FreeBSD is that the dnsserver replies are read in multiple chunks.
This is obviously occuring with you because the reply count (9365)
is higher than the request count (5233). One thing you can do
about this is build a new kernel with a larger MBUF cluster size.

Also, if your load is not very high, consider upgrading to 1.2 (beta).
It has improved squid <-> dnsserver communication.

Duane W.
Received on Sat Jul 04 1998 - 22:10:08 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:41:03 MST