From owner-freebsd-net  Mon Dec  7 17:06:02 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id RAA12905
          for freebsd-net-outgoing; Mon, 7 Dec 1998 17:06:02 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from poboxer.pobox.com (port95.prairietech.net [208.141.230.95] (may be forged))
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA12830
          for <net@FreeBSD.ORG>; Mon, 7 Dec 1998 17:05:58 -0800 (PST)
          (envelope-from alk@poboxer.pobox.com)
Received: (from alk@localhost)
	by poboxer.pobox.com (8.9.1/8.9.1) id TAA61062;
	Mon, 7 Dec 1998 19:04:39 -0600 (CST)
	(envelope-from alk)
From: Tony Kimball <alk@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon,  7 Dec 1998 19:04:38 -0600 (CST)
X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.<li^!8ecK]}3L-
	6`ZQW3}kxy*5]B<KA"&iBl58"/$W-0PP`B7c%'XczR)8T0VN47L`rQlu8qBIX4TJ|v'D%:k7GO%v4A
	Os>Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO
	5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed
Reply-To: alk@pobox.com
To: net@FreeBSD.ORG
Subject: Re: resolver behaviour
References: <alk@pobox.com>
	<199812080031.QAA10114@salsa.gv.tsc.tdk.com>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13932.30101.788469.964960@avalon.east>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Quoth Don Lewis on Mon, 7 December:
: So if you discover that one of netscape.com's servers is broken, you're
: going to add a non-broken server to for netscape.com to your /etc/resolv.conf?
: Then when you find another broken server, you'll add another entry to
: /etc/resolv.conf, etc.

My expectation, on the basis of anecdotal experience, is that
two should be quite sufficient, if chosen well.  Name servers
at widely separated locations in the DNS graph rarely (if ever!
for I have never seen it happen) suffer common corruption.  

: NXDOMAIN replies are issued by servers that have been configured to
: be authoritative for the zone in which the name resides and that name
: is not listed in the zone file.

...and by servers which have been misconfigured, or are plain buggy,
and all those who rely upon those servers.

Quoth Mike Jenkins on Mon, 7 December:
: So the new resolver algorithm would sort of look like this?
: 
: 	for i in nameserver-list
: 	do
: 		answer=query $i
: 		case answer in
: 		timeout)  ;; # try next nameserver
: 		NXDOMAIN) ;; # try next nameserver
: 		*) break  ;; # got answer
: 		esac
: 	done
: 	return answer

Thanks.  This is what happens in practice today, only the looping is
done by hand by the end-user, instead of in the library.  I think such
an algorithm introduces too much latency into bad requests (i.e. ones
for which NXDOMAIN is correct), though.  When a person does it
manually, they do it because they *know* the request is valid, and the
server is broken.

read nameserver-list
set alarm at timeout
pausetime = timeout / N
nx = null
select-list = null

trap eintr {
  if nx == null return timeout
  else return nx
}

for i in nameserver-list
do
  query i 
  push i select-list
  select on select-list for pausetime
  for answer in pending replies
  do
    case postive(answer):
       return answer
    case NXDOMAIN:
       nx = answer
       continue
  done
end loop





  







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