Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!nrl-cmf!ames!ubvax!ardent!mec From: mec@ardent.com (Michael Chastain) Newsgroups: comp.protocols.tcp-ip Subject: Reconciling /etc/hosts, yp, and named? (SUMMARY) Keywords: summary /etc/hosts yp named Message-ID: <2265@ardent.UUCP> Date: 31 Jan 89 00:02:43 GMT References: <1737@ardent.UUCP> Sender: news@ardent.UUCP Reply-To: mec@ardent.com (Michael Chastain) Organization: Ardent Computer, Sunnyvale, CA Lines: 78 Here's the summary of responses to my question, "how do you reconcile /etc/hosts, yp, and named". Thanks to all ~25 respondents. We haven't made a decision for our product yet, but we're leaning towards the "/etc/svcorder" solution. SHORT SUMMARY Don't invent your own weird or different scheme for this problem. Don't use a yp map for a service provided by the Domain Name System. At least make it possible for customers who hate yp to configure their systems to not use it. Look at Ultrix 3.0 /etc/svcorder; look at SunOS 4.0; look at Hesiod (a BIND extension from MIT project Athena). Get Sendmail 5.59. You'll need it for MX support anyways. Use BSD rather than Sun source, because having sendmail call YP loses big-time. LONG SUMMARY Three people described the Ultrix 3.0 scheme, which is: "a control file (/etc/svcorder) to specify what service(s) and which order. i.e. BIND, YP, LOCAL for name resolver, yellow pages, and/or local /etc/hosts". [This looks like the best scheme to me.] Casey Leedom posted a good description of SunOS 4.0, which I'll summarize: The resolution order is: Yellow pages Name server /etc/hosts The major problem with this is that "the YP protocol doesn't have the ability to return ... a name server request timed out". This causes programs like sendmail to get stuck in a loop talking to a YP server. In the specific case of sendmail, which is the major victim, the problem can be avoided by using BSD 5.59 sendmail and the following resolver order: Name server /etc/hosts [I think Sun's solution is inferior to /etc/svcorder, but a lot of people have Suns and probably like this arrangement.] Anti-yp quotes: Milo Medin writes "if you punt yp completely, you'll be better off" and "you just can't make things work right by calling the resolver routines from yp". Steve Miller writes "Note that it's important for your customers to be able to purge YP entirely from their systems without causing any catastrophes". Craig Partridge warns that if your sendmail uses yp name resolution, and a name server goes down, "you are also potentially blasting dozens or hundreds of packets per second across the network. Furthermore, there are situations in which this situation is stable." [Punting yp certainly simplifies the problem, and I gather there are a lot of arguments pro and con this position. I don't want to start a yp war on the net! Enlighten me via e-mail if you must!] Casey also makes an important point about choosing an existing scheme instead of inventing our own: "People will spend no end of time bitching at your company if they have to do something weird and different on your machines for no functional gain." [Agreed!] Michael Chastain mec@ardent.com "He who dies with the most Ardent Computer uunet!ardent!mec FRIENDS wins."