From owner-freebsd-stable Thu Apr 4 18:59:31 2002 Delivered-To: freebsd-stable@freebsd.org Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by hub.freebsd.org (Postfix) with ESMTP id 0413E37B41D for ; Thu, 4 Apr 2002 18:59:24 -0800 (PST) Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g352xAx73104; Fri, 5 Apr 2002 12:59:11 +1000 (EST) (envelope-from marka@isc.org) Message-Id: <200204050259.g352xAx73104@drugs.dv.isc.org> To: Andy Farkas Cc: hawkeyd@visi.com, stable at FreeBSD From: Mark.Andrews@isc.org Subject: Re: named connections "in vain" In-reply-to: Your message of "Fri, 05 Apr 2002 12:02:09 +1000." Date: Fri, 05 Apr 2002 12:59:10 +1000 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Thu, 4 Apr 2002 Mark.Andrews@isc.org wrote: > > > > Apr 3 07:38:20 sheol /kernel: Connection attempt to UDP 192.168.16.2:2 > 314 fr > > > om 192.168.16.2:53 > > > > > > I can't figure out what named is trying to talk with. > > > > Named is replying to clients that have already given up waiting. > > These are most probably SERVFAILs saying that the nameserver has > > given up but they could also be late answers where the nameserver > > has had to work through several dead servers. > > Named is replying to itself, not a client, ie. the host at 192.168.16.2 > made a request to 192.168.16.2 which timed-out. You can have *both* the server and clients on the same box. > > > > The only theory I can > > > come up with is that named is not waiting long enough for the forwarder > to > > > reply, and does the query itself. When the forwarder does [finally] rep > ly, > > > the connection has already been closed (either by named or ipf)? > > I think it has something to do with the resolver library having a short > time-out value and named having a longer one. The resolver timeout is large enough that for 99.99% of queries where there is not misconfiguration or otherwise broken server involved in the resolution process it will complete before the resolver gives up. Multiple broken servers can cause the resolution process to exceed the timeouts of the resolver. > An application (say sendmail) will use the resolver library to make a > query. The query goes to the nameserver listed in /etc/resolv.conf which > happens to be the same server as the app is running on. The query has a > short time-out - it fails because named hasn't answered yet - the app goes > on. Later, named gets an answer and tries to reply to a nonexistant > connection. Yep. > > Do you know if in fact there are separate time-out values for the resolver > library and named? Yes they are different. Mark > -- > > :{ andyf@speednet.com.au > > Andy Farkas > System Administrator > Speednet Communications > http://www.speednet.com.au/ > > > -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message