Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!NSIPO.NASA.GOV!medin
From: medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Domain Name Screaming
Message-ID: <8907022301.AA01289@erendira.arc.nasa.gov>
Date: 2 Jul 89 23:01:36 GMT
References: <37397@sgi.SGI.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 50


This is silly.  Either the DNS is fully authoritative or it isn't.  This
is like checking hosttable information and if not there, asking the nameserver
to take a crack at it.  This may seem sensible on the surface, but if you
think about it a bit, it's a lose.

Say the YP domain has more info than the DNS.  In this case, people outside
the YP domain will get back incorrect or incomplete information, since they
don't have access to the YP information.

Say the DNS has more info than the YP system.  In this case, you can get into a
case where the YP system returns one thing and the DNS returns something
different.  There is of course the issue of who is right, but more important 
is that it's different.  Once you get things consistent, it's a lot easier to
make sure it's saying the correct thing.

The only case where you win is where the DNS and the YP system are totally
consistent with each other, in which case you could have used straight DNS
all along, and not have gone through this mess.  

The implementation issue is orthogonal to the issue of which system is more
authoritative.  Even if YP had the concept of a 'soft-err', you still
have the consistency issue to deal with.  The YP hostinfo architecture works
fine in an environment where you don't have any reason to talk to the
DNS.  If you're connected to the Internet and want to interoperate, then
you have a problem trying to make things play together.

What we have done since 3.5 is rebuild the libc.a library after replacing
the YP hostinfo code completely with DNS resolver equivalents.  This has
worked very well, though under 3.X meant you had to relink the 3.5
utilities, which was a bit difficult since SUN didn't ship you the .o
files.  Under 4.X, it's much easier, as the hostent structures are consistent
with 4.3 BSD, and all you need to do is rebuild the shared libc library, and
all those dynamically linked utilities automagically work fine.  The stuff
that's left (rcp, arp, etc...) can be rebuilt with 4.3 code or SUN source.  

The kind folks at SUN have even gone so far as to do this for you and make
it available for FTP from uunet.uu.net.  They are even handing out the -pic
.o archives (the .o's just before the are linked into the shared libc),
so you can replace whatever pieces you like.  I even hear these things
will be shipped as a standard part of 4.1.  So SUN at least is trying
to do the right thing (backwards compatibility can really be painful
sometimes).  

Note that I've talked about replacing just the YP hostinfo code.  The rest of
the YP system is left intact (so automounter and the rest work fine) to
use if you want...   

					Thanks,
					    Milo