Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!GIPSI.GIPSI.FR!philipp
From: philipp@GIPSI.GIPSI.FR (Philippe Prindeville)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: BIND bug list
Message-ID: <9006011614.AA00857@Gipsi.Gipsi.Fr>
Date: 1 Jun 90 18:14:42 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 65


	From: del@mlb.semi.harris.com (Don Lewis)
	Date: Thu, 31 May 1990 16:13:20 EDT
	Subject: Re: BIND bug list
	
	If your machine has shared libraries (ala Sun), you can put the
	resolver code there.  You can then upgrade the resolver code and
	all your applications will see the changes.

Yes, but there is more than just Suns out there.  A more portable
solution is needed.
	
	> Really,
	> the best thing to do is to RPC to a local resolver daemon that can
	> do things like measure which servers give timely responses, and
	> which ones are south.  Also, things like address sorting based on
	> policy constraints could be done there also.
	If you get a BIND version >= 4.8, you can do this now if you don't list
	any name server addresses in /etc/resolve.conf, and list the real name
	servers as forwarders in /etc/named.boot.  BIND is also kind enough
	to do caching for you, which is a definite win.  The only thing lacking
	is that BIND doesn't keep track of performance data, but that should
	probably not be too hard to add.

One of us is confused here:  I thought we were talking solely about
the resolver, not the nameserver as well.  I don't think installing
the nameserver on every workstation is a solution.  It would give
a rich local cache, but it would be better to have one or two forwarding
nameservers for the local site, and let them accumulate the cache.
	
	The problems with this approach are:
	  * If the local BIND process dies, your host will be very unhappy
	  * The local BIND process is not able to distinguish between a
	    forwarder being down and a query that the forwarder is having
	    trouble resolving (due to the nameservers it is querying not
	    responding).  If you list only one forwarder, you are killed
	    by the first case.  If you list multiple forwarders, you may
	    time out the first query and try the next forwarder, which will
	    not have any better luck.  This is a good way to thrash the
	    internet, and it will also muck up your performance data.

Yes, another reason not to run a nameserver on every host.

	Basically recursive queries and UDP don't mix very well.  Recursive
	queries work fine with TCP, but then you are limited as far as the
	number of simulataneous queries that you can support.

Yes, so?  Apropos of what?

	> If this sounds like ypbind to you, Don't Panic.  I'm not advocating
	> yellow pages.  Just saying there should be more thread/RPC type
	> design in UNIX.
	> 
	> It would be nice if the IAB would say type-X RPC (XDR, etc) will be
	> the official protocol of the Internet, so we could get on with the
	> design of system servers...
	I don't think there needs to be a new protocol, maybe just some
	enhancements to the existing protocol to better support recursive
	queries.

Eh, no:  I meant a protocol for RPC between processes, such as a
client program (maybe telnet) wanting to talk to a server (such as
a local resolver daemon).

-Philip