Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!mlb.semi.harris.com!del
From: del@mlb.semi.harris.com (Don Lewis)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: BIND bug list
Message-ID: <9005312013.AA12287@thrush.mlb.semi.harris.com>
Date: 31 May 90 20:13:20 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 47

On May 31,  4:16pm, Philippe Prindeville wrote:
} Subject: Re: BIND bug list
> The resolver shouldn't be a system call (since it is session layer),
> but at the same time it shouldn't be linked into every applicaton,
> since you might want to upgrade it or add functionality.
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.

> 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.

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.

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.

> 
> 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.