Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Apr 2001 08:45:12 -0700 (PDT)
From:      "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
To:        at@rominet.net (Alain Thivillon)
Cc:        freebsd-stable@FreeBSD.ORG
Subject:   Re: Strange localhost NS look attempts
Message-ID:  <200104041545.IAA16525@gndrsh.dnsmgr.net>
In-Reply-To: <20010404093726.B46227@vinea.teaser.fr> from Alain Thivillon at "Apr 4, 2001 09:37:26 am"

next in thread | previous in thread | raw e-mail | index | archive | help
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Kenneth W Cochran <kwc@world.std.com> _crivait (wrote) :
> 
> > Agreed, I think it has more to do with the nameserver.  But
> > maybe Yet Another Netscape Problem?  Any idea(s) as to a fix?
> 
> This is because answer of DNS server comes back after the resolver
> timeout : query socket is closed and kernel log a connection attempt.

Does anyone see a huge descrepancy in these two contants:
named/ns_defs.h:#define RETRY_TIMEOUT   45
br1.reply.net:root {176}# grep -i timeout /usr/include/resolv.h
#define RES_TIMEOUT             5       /* min. seconds between retries */

Our systems log 10 of thousands of these UDP port 53 vain connections,
and now I see clearly why.  If your not running a local named you only
give a remote query 5 seconds, yet the remote named will try for 45
seconds to get you an answer... blech!!!

IMHO RES_TIMEOUT should be >> RETRY_TIMEOUT.


Or at least RES_TIMEOUT should reflect the way that named works as
far as it's own retries of getting data:
/*
 * Compute retry time for the next server for a query.
 * Use a minimum time of RETRYBASE (4 sec.) or twice the estimated
 * service time; * back off exponentially on retries, but place a 45-sec.
 * ceiling on retry times for now.  (This is because we don't hold a reference
 * on servers or their addresses, and we have to finish before they time out.)
 */

Ie retries go at 4, 8, 16, and 32 seconds, then we hit the 45 second
wall.  I am going to try a libc with RES_TIMEOUT set at 16 and see
what it does for the rate of log messages....

Either way, that 5 second RES_TIMEOUT has got to be placing an unneeded
load on our nameservers, due to the fact that the resolver gives up
before named does :-(.

> > Or should I Just Live With It?
> 
> Unless you want to recompile libc with a higher timeout (see
> /usr/include/resolv.h) (and as Netscape is a a.out binary, you should
> recompile libc of FreeBSD 2.2.8).

Thats just what I am going to do, thanks for pointing me at resolv.h :-)

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)               rgrimes@gndrsh.dnsmgr.net

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104041545.IAA16525>