Path: utzoo!attcan!uunet!husc6!ukma!tut.cis.ohio-state.edu!ucbvax!NSIPO.ARC.NASA.GOV!medin From: medin@NSIPO.ARC.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) Newsgroups: comp.protocols.tcp-ip Subject: Re: Domain Name Screaming Message-ID: <8907050456.AA01507@nsipo.arc.nasa.gov> Date: 5 Jul 89 04:56:51 GMT References: <37409@sgi.SGI.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 89 This is reasonable, but there is a minor hassle. The named stuff I know about is not nearly as easy to set up in a small site as YP. There is more typing, and room for choice with 4.3+ named configuration files. Given that DNS is more powerful, one would be surprised if it were otherwise. In its current state, named is more appropriate for sites such as ours with network hacks who like to fiddle with resolv.conf's, named.boot's, .rev files, and so on. Is there an alternative to a resolv.conf listing the servers on each client? The broadcast RPC of YP is insecure, but it is easier to reassign servers. Named is also a bit unforgiving--ever notice what happens if you happen to put a period after a host address in a database file? You define a name=-1. Don't forget the fun chaos one can make with resolver loops. If you ran named on the clients and told them about the root servers they could figure out everything else from there. Of course you could always broadcast named queries (ugly, but possibly useful for finding things initially). If you went to as much effort in making the user interface to BIND as nice as YP, you'd have it capable of being run more easily in small non-connected islands as well as in the Internet. In addition, there are available awk or perl scripts that take a hosttable as input and output a set of DNS files to feed to named. Sendmail is complicated too, but people didn't throw it away and write something more friendly. They put time and effort into making configuration easier. It's also a lot more robust than it used to be. Obviously, most of these are characteristics of the 4.3 implementation and not DNS itself. Many (but not all) of the well known bad parts of YP are implementation shortcomings rather than protocol botches. Agreed. It's too bad people reject protocol architectures because of implementation issues as opposed to fundamental problems with the architecture. That's why we have ugliness like Appletalk in the world... :-( Notice that the vast majority of all workstations do not have access to the Internet, are on very small networks, and do not have an a priori need for DNS. How many times have we seen nets of small organizations winding up connected to the Internet? Also don't forget that DNS has things like multiple address per hostname and MX record support. YP doesn't. Even in a small organization, these things can be useful. It's much easier grwoing if you treat small systems the same way as big ones, rather than coming up with different solutions. Look what happens when you get a large pile of PC's running some brand X proprietary LAN software package and then you have to connect to a set of heterogeneous systems (like mini's or workstations). Here you throw away the PC oriented approach and go with something more standard. Besides, small systems and small networks have a strong tendency to get bigger, because of technology issues. Always relying on either DNS or YP is an incomplete answer. It is sometimes necessary to have your own, private extensions to the central government's data. For example, imagine that you do not have root passwords for the DNS/YP server(s), and that you want to use rcp to a host which is not correctly in the databases--maybe one of central governments has not processed the paper work needed before adding a new hostname, or made a mistake. Most utilities let you use numbers rather than names. The fact that rcp and rlogin don't is an artifact of the implementation. That is, no one has bothered to fix it. In your example, I'd just use FTP. You will always get mistakes that break things, whether it's YP or DNS systems. Depending on how the YP space is set up, you may not be any better off than the DNS case in your example. There are many organizations (like Apple) who have private DNS data that doesn't escape to the outside. That isn't an argument for YP, it's an argument for knobs to BIND to make that easier. Remember, the DNS is a protocol architecture, and not BIND. Maybe what you're saying is that sometimes YP is the right answer and sometimes DNS is. I buy that, especially given certain implementation issues. But trying to get them to work together is a problem. That's my main argument anyway. I'm arguing for consistency. If YP is what you want, that's fine, just don't try and mix it up DNS information. Vernon Schryver Silicon Graphics vjs@sgi.com Thanks, Milo PS Usual disclaimers apply of course...