Xref: utzoo comp.protocols.tcp-ip.domains:298 comp.protocols.tcp-ip:12467
Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!van-bc!skl
From: skl@van-bc.wimsey.bc.ca (Samuel Lam)
Newsgroups: comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject: Re: bug in BSD tahoe res_send()?
Summary: Yes it is one.
Keywords: BIND, res_send(), bug
Message-ID: <1199@van-bc.wimsey.bc.ca>
Date: 3 Aug 90 05:43:22 GMT
References: <3010@awdprime.UUCP>
Reply-To: Samuel Lam <skl@wimsey.bc.ca>
Organization: Balliffe Intersystem, Vancouver, B.C., Canada
Lines: 35

In article <3010@awdprime.UUCP>, jeffe@sandino.austin.ibm.com
 (Peter Jeffe 512.823.4091) wrote:
>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 coincident!)  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 ...>".

I have talked to the Berkeley person in charge of 4.4 about this (Mike)
at the Vancouver IETF this week, and he commented that the 4.3-tahoe
BIND is a couple years old and suggested that I take a look at the
4.4-reno BIND (to be available shortly) to see if the bug is still
there before I post a note to the BIND mailing list about it.

...Sam
-- 
Internet: <skl@wimsey.bc.ca>	UUCP: {van-bc,ubc-cs,uunet}!wimsey.bc.ca!skl