> -----Original Message-----
> From: Mike Malsman [mailto:zep@ni.enate.org]
> Sent: Saturday, 4 November 2006 1:51 AM
> To: dns@list.cr.yp.to
> Subject: Re: Dnscache timing out
>
> On Nov 2, 2006, at 8:53 PM, Christopher Lenton wrote:
> > Hi Mike,
> >
> > Sorry I forgot to include information about the logging. Yes I am
> > using daemontools with /etc/dnscache/log/run:
> > #!/bin/sh
> > exec setuidgid dnscache multilog -*
>
> no problem, thanks for the clarification. if you don't ever intend
> to keep or process logs, you can save some system and user
> cpu time.
> configure your dnscache run script to route its output to
> /dev/null, and remove your log service. this saves the time
> the system takes to process the pipe, and the time that
> multilog takes to decide not to log anything.
Noted.. Will definitely implement that.
> > It seems like the failures have reduced somewhat as I
> increased the -o
> > parameter. In the last few hours, I have had only one
> timeout recorded
> > on the SLB router's syslog:
> >
> > Nov 3 12:38:58.563 AEDT: %SLB-6-REAL: Real 203.23.xx.xx (DNS1FARM)
> > has changed state to FAILED Nov 3 12:40:05.303 AEDT: %SLB-6-REAL:
> > Real 203.23.xx.xx (DNS1FARM) has changed state to OPERATIONAL
>
> I cannot really comment on this, except to say that I run
> some fairly high volume dnscache's with an -o value of 250.
> FreeBSD will keep a queue of UDP requests in a buffer of its
> own. I admittedly do not fully comprehend the effects of
> increasing the value of -o.
>
> how is it that your Ciscos are configured to test dnscache?
> in my configuration, I have several dnscache instances behind
> Foundry ServerIron load balancers. they are configured to
> query an A record for 'localhost.', which is good because
> dnscache will always respond '127.0.0.1' to this query,
> without consulting the Internet. if you are querying an
> external address, you are allowing the possibility of a
> failure external to dnscache to affect your load balanced
> configuration.
You raise an interesting point that I failed to include in my previous
posts. Dnscache *always* responds locally on the external WAN interface
(as in a locally borne query). The timeouts occur when I make a query
from an external host to the external WAN interface. This same test does
not fail when running BIND. Am I going prematurely bald? Yes.
As of last week, I reluctantly switched back to BIND due to the
timeouts. I'm not sure exactly what to do, but I will continue to debug
and persist with implementing dnscache. Frustrating to say the least.
Rgds,
Chris
This email and any files transmitted with it are confidential and intended
solely for the
use of the individual or entity to whom they are addressed. Please notify the
sender
immediately by email if you have received this email by mistake and delete this
email
from your system. Please note that any views or opinions presented in this
email are solely
those of the author and do not necessarily represent those of the
organisation.
Finally, the recipient should check this email and any attachments for the
presence of
viruses. The organisation accepts no liability for any damage caused by any
virus
transmitted by this email.
|