Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Apr 2001 12:35:22 -0400 (EDT)
From:      Kenneth W Cochran <kwc@world.std.com>
To:        "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: Strange localhost NS look attempts
Message-ID:  <200104041635.MAA00043@world.std.com>

next in thread | raw e-mail | index | archive | help
>From owner-freebsd-stable@FreeBSD.ORG  Wed Apr  4 11:46:09 2001
>From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
>Subject: Re: Strange localhost NS look attempts
>To: at@rominet.net (Alain Thivillon)
>Date: Wed, 4 Apr 2001 08:45:12 -0700 (PDT)
>Cc: freebsd-stable@FreeBSD.ORG
>
>[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

But I *do* run a local named, cache-only though.  But
discounting that, shouldn't the resolver be getting that
from /etc/hosts anyway?  (/etc/host.conf is "as-installed,"
hosts followed by bind.)

>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

Interesting...  So this is appearing to not be a problem
with named/bind, Netscape or firewall/wrapper config, but
something about the resolver?...  Perhaps something that
has "slipped through the cracks" over time?

-kc

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?200104041635.MAA00043>