Xref: utzoo comp.protocols.tcp-ip.domains:300 comp.protocols.tcp-ip:12483
Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!sdd.hp.com!elroy.jpl.nasa.gov!mahendo!poseur.JPL.NASA.GOV!earle
From: earle@poseur.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support)
Newsgroups: comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject: Re: bug in BSD tahoe res_send()?
Keywords: BIND, res_send(), bug
Message-ID: <1752@mahendo.Jpl.Nasa.Gov>
Date: 4 Aug 90 04:18:32 GMT
References: <3010@awdprime.UUCP> <1199@van-bc.wimsey.bc.ca>
Sender: news@mahendo.Jpl.Nasa.Gov
Reply-To: earle@poseur.JPL.NASA.GOV
Followup-To: comp.protocols.tcp-ip.domains
Organization: Sun Microsystems - JPL on-site Software Support
Lines: 46

In article <1199@van-bc.wimsey.bc.ca>, skl@van-bc.wimsey.bc.ca (Samuel
Lam) writes:
>>I'm not sure if this is a bug, but in BSD tahoe res_send.c (6.21), the
>>following code looks fishy:
>...
>>|			if (_res.nscount == 1 || retry == _res.retry) {
>>                                             !!!^^^^^^^^^^^^^^^^!!!
> 
>(What a coincidence!)  I also nailed this one within the last month,
>as it had caused us grief around here for a long time and I finally
>gotten around to it.  I think this is definitely a bug, but my
>analysis is different from yours.
> 
>I fixed it by changing the problem line from
> 
>    if (_res.nscount == 1 || retry == _res.retry) {
>                          **
>to
>    if (_res.nscount == 1 && retry == _res.retry) {
>                          **
>
>as this fix made sense to me at the time.  i.e. The condition become
>"if we only have one name server, *then* if this is also our first
>attempt to use it, then <do ...>".

Yes, this is a bug.  But I do not think that your fix is the correct one;
for a better fix, use the res_send.c that comes with any BIND 4.8.2 version
that you can find (I believe several versions of BIND that purport to being
`BIND 4.8.2.x' abound; perhaps someone could make a definitive statement on
the situation?).  I chose the one from University of Toronto; you can get it
via anonymous FTP from neat.AI.Toronto.EDU, in `utbind.tar.Z'.  Examine the
code and you will see where this problem is dealt with directly.  The
connect()-ed socket is dis-connect()-ed if the resolver gets ECONNREFUSED
from the first round of nameserver queries.

In any case, this topic is fodder for the BIND mailing list, not the
comp.protocols.tcp-ip.domains newsgroup.  Use FTP to ucbarpa.Berkeley.EDU to
retrieve the archives of the BIND mailing list to find the original discussion
of this problem, and the solution proposed by the person whose fix is in the
U. of Toronto version.

--
	- Greg Earle
	  Sun Microsystems, Inc. - JPL on-site Software Support
	  earle@poseur.JPL.NASA.GOV	(Direct)
	  earle@Sun.COM			(Indirect)