mec@ardent.com (01/13/89)
How do you reconcile /etc/hosts, yellow pages, and named? Some of our customers want yellow pages. Some want a named. And some of them are happy with /etc/hosts and probably don't want anything more complicated/fragile than a small /etc/hosts file. How can we offer yellow pages and named at the same time? How can we make everybody happy? Pointers to specific RFCs and software welcomed. E-Mail to me and I'll summarize to the net. Michael Chastain mec@ardent.com "He who dies with the most Ardent Computer uunet!ardent!mec FRIENDS wins."
scottr@CSC-LONS.ARPA (Scott W. Rogers) (01/14/89)
Ultrix 3.0 (and 2.4) seem to have simplified this problem by instituting a control file (/etc/svcorder) to specify what service(s) and which order. i.e. BIND, YP, LOCAL for name resover, yellow pages, and/or local /etc/hosts. The system functions (gethostbyxxx) use this file to determine where to look, and in what order, for resolving hosts names. This seems like as good an approach as any. ------------------------------------------------------------------------ Scott W. Rogers Computer Sciences Corporation - Systems Division AT&T: (703) 876-1363 3160 Fairview Park Dr. - Falls Church, VA 22152 Fax: (703) 876-4072 Internet: scottr@csc-lons.ARPA ------------------------------------------------------------------------
cpw%sneezy@LANL.GOV (C. Philip Wood) (01/14/89)
When you find the answer let us all know.
My feeling is that a gethostby{name,addr} routine should have a heirarchy
of lookup which could be configurable. But the default would be something
like:
/etc/hosts could contain the following kinds of entries:
hostname
+hostname
+
Order would be important.
Then gethostby{name,addr} would do the following:
Unless directed by some environment variable or other policy
mechanism:
open /etc/hosts and attempt to resolve the name
by searching sequentially through /etc/hosts
if the name is found and has the prefix '+' goto
the "YP domainname server for that host"
if the name is not found and the standalone '+' is
found then try the YP server.
If all the above has failed then go for the Internet
Domain nameserver pointed to by /etc/resolv.conf or
whatever mechanism. If there is no pointer to
an Internet Domain nameserver then I guess you are done!
casey@gauss.llnl.gov (Casey Leedom) (01/14/89)
| From: mec@ardent.com (Michael Chastain) | | How do you reconcile /etc/hosts, yellow pages, and named? The way that Sun has things set up works pretty well. Additionally, if you went that route you'd be operationally compatible with Sun OS on this issue. This second point is nearly as important as the original problem. People will spend no end of time bitching at your company if they have to something weird and different on your machines for no functional gain. That works its way toward a dissatisfied customer base Real Quick. In any case, their gethostby*() routines try to resolve names via YP and if YP isn't available, use /etc/hosts. Ypserv if forked off normally will deal with a dbm version of /etc/hosts created from /etc/hosts. But, if YP is forked off with a "-i" flag, when a resolution request comes down the line that ypserv can't handle, it hands it off to the name server and then returns it's results as if it had figured out the answer. These layers of operation mean that you have to run YP and BIND if you want BIND functionality, but normally that's not a problem. Two particular problems are worth mentioning however (below I outline a scheme that doesn't suffer this problem): 1. The YP protocol doesn't have the ability to return the answer ``I can't tell if the host exists or not - I timed out trying to get the answer for you'' I.e. a name server request timed out. This occurs as a pathological problem when a gateway to a large chunk of the network goes out. A client application will attempt to resolve a name, the request will end up in ypserv's hands, ypserv gets a time out from named, but because ypserv can't send that answer back to the client, ypserv simply exits. Meanwhile, the client, not getting any response to its query, figures it got dropped by the network and retransmits its request ... Forever. So you get a ypserv getting forked off once per second or so forever. Normally this isn't a problem because the client involved is someone typing ``telnet foo'' and they get tired after a while and hit ^C. But when the client is an automated program like sendmail which doesn't get tired you have problems. We've had situations where multiple sendmails will be running on multiple client machines and the combined YP traffic has dozens of ypservs being forked off per second. The load average slowly climbs up past 16 as more and more sendmails hang waiting on name resolution and pretty soon the server machine crashes. It turns out that sendmail is basically the sole problem point along these lines in a standard configuration. Bill Nowicki at Sun solved the problem by putting timeouts around all gethostby*() calls and we haven't had a problem since. He set the timeout to 90 seconds which I feel is high, but that just means you have transient loads on your sever for 90 seconds for each sendmail that times out. Obviously a better solution would be to extend the YP protocol, but that would require a lot of work. 2. The second problem is also associated with sendmail: MX records. If you use sendmail in the configuration above, you get better service than if you just had a host table because you're getting name/address resolution for every host in the domain system that's on the internet, but you don't get to mail to hosts which have MX records set up. Bill Nowicki's solution here is to run a different version of sendmail that interfaces to the name server directly. In fact, he simply uses the sendmail from Berkeley for this. Note that this also solves the problem above since sendmail no longer goes through ypserv. This has the disadvantage of requiring that you provide two sendmail binaries, but since you can compile them both from the same sources, that's not to great a problem. In the final analysis, I think that YP's best use is as a distributed user/group/id name service. I don't think that it makes a great distributed host name/address service now that the DOMAIN system is available. It does have the significant advantage that you can simply edit an old style host table and generate a YP host database from that which is simpler than dealing with name server databases, but this is only an advantage for an isolated network since any networks connected to the internet will eventually be forced to setting up a name server somewhere, and once you have a name server somewhere, it's trivial to set up most of your hosts to either contact that name server or run a secondary name server neither of which require complicated name server databases. Given this and the fact that the DOMAIN system is here to stay, I'd say that I'd be tempted to set up the library routines to try to contact a name server first, use YP second, and finally look in /etc/hosts. This means that there'll be a slight delay any time anyone tries to resolve something, but people will put up with lower performance a lot better than lower functionality or ease of use. Besides, the delay shouldn't be that bad. You could do something like keeping track of what you're using in the library so that an application would only suffer a delay on the first resolution, but that would mean that if the name server or YP were temporarily unavailable when an application first started it wouldn't use either when service came back. This would be a severe problem if the application in question were a daemon or server of some sort. Moreover, it would lead to unpredictable behavior from a user's perception (two people sitting next to each other might start the same application a couple of seconds apart and one would get host table lookups throughout the execution of the application while the other got name service. People would not be happy. I think that the best place to put the automatic switch is in the res_*() routines. In that configuration you could use stock BSD code for everything except the res_*() routines which would have your additions to lookup YP. The res_*() routines already back off to host table lookups if a name server can't be contacted - all you'd have to do is insert a YP stage in between. Finally, I'd just use the standard MX sendmail in the above configuration. It's MX queries would time out if there wasn't a name server available and it's subsequent res_*() for address would go through the above automatic switch between BIND, YP, and host table lookup. Hope this helps. Casey
medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) (01/14/89)
The only real way to make things work is to replace yp with pure named service for hostname service only (of course, if you punt yp completely, you'll probably be better off). For 4.0, you can get a shared library from SUN that has the 4.8 resolver code in it, and still has everything else handled by yp. For 3.5, you basically have to throw away the SUN network utilities and recompile them from source, linking them against a libc built with the 4.8 resolver code. We did that for our systems, and it wasn't too bad considering we had 4.3 sources. You just can't make things work right by calling the resolver routines from yp. You also have to get a completely new copy of sendmail as well, because even if you replace all the yp calls with named calls, you must have MX support, and the distributed sendmail doesn't do that. You can also get an MX capable sendmail from SUN, though you are probably better off compiling 5.59 or 5.61 yourself... Thanks, Milo
steve@umiacs.UMD.EDU (Steven D. Miller) (01/16/89)
It seems to me that the following combinations of DNS/YP/host table usage are valid: 1) You're using the domain name system. In this case, *all* host lookups should go through the DNS. The only exception here is that at boot time, you'll need to be able to fall back on the host table so that you can do a host name lookup to configure your network interface. Other than that, you *never* fall back on the host tables, as host table information is out-of-date, wrong, and won't be around for too much longer. I'd rather have no answer than a wrong one, though I suppose this is something of a religious issue. Similarly, sendmail should do MX lookups, and do them through the DNS directly, with nothing serving as an intermediary. This approach is always the right one, irrespective of whether or not you're also running YP. Since YP has no concept of soft failures, there's no way for ypserv -i ever to work 100% correctly. And, after all, if you're using the DNS, your host information is all being served by a DNS server, and you have no need to keep duplicate host information around in YP. (There may actually be a few exceptions to this in highly security-conscious environments, where perhaps the existence of some hosts is not to be advertised to the outside world. I'm not sure how to handle those cases. What do other people think?) 2) You're not using the domain name system. This breaks down into two cases: 2A) You're also not using YP. All lookups go to /etc/hosts. (Note that it's important for your customers to be able to purge YP entirely from their systems without causing any catastrophes.) 2B) You're using YP. Do whatever most other YP servers do in terms of falling back on host tables when necessary. I think that Sun is moving toward this approach. It's possible to get SunOS 4.0.1 C libraries that do host lookups through the DNS, and YP lookups for everything else; they're available for anonymous FTP from uunet. I think they may come on the Sun distribution tapes in the future, though you shouldn't take my word on that. (Could someone from Sun confirm or deny this rumor?) If you software follows these rules, is is my opinion that it will work in accordance with the letter and spirit of the domain RFCs. I'm sure that others will (and, indeed, already have) beg to differ. Does the Hosts Requirements RFC have anything to say on this matter? -Steve Spoken: Steve Miller Domain: steve@mimsy.umd.edu UUCP: uunet!mimsy!steve Phone: +1-301-454-1808 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742
mec@ardent.com (Michael Chastain) (01/31/89)
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 <casey@gauss.llnl.gov> 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 <medin@nsipo.nasa.gov> 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 <steve.mimsy.umd.edu> 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 <craig@nnsc.nsf.net> 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."
rbj@DSYS.ICST.NBS.GOV (Root Boy Jim) (05/16/89)
? From: steve@umiacs.umd.edu (Steven D. Miller) ? It seems to me that the following combinations of DNS/YP/host table usage ? are valid: ? 1) You're using the domain name system. In this case, *all* host ? lookups should go through the DNS. The only exception here is that ? at boot time, you'll need to be able to fall back on the host table ? so that you can do a host name lookup to configure your network ? interface. Other than that, you *never* fall back on the host ? tables, as host table information is out-of-date, wrong, and won't ? be around for too much longer. I'd rather have no answer than a ? wrong one, though I suppose this is something of a religious issue. True. I would like to add one more belief to our religion. I would caution against using the host tables even to bring the network up. First, consider a gateway, with two interfaces with two different IP addresses but only one name. You obviously can't do: ifconfig ie0 foo.bar.com ifconfig ie1 foo.bar.com Now perhaps one could (and should?) define a foo-gw.bar.com address, but the order of addresses in /etc/hosts will determine which IP address is returned first, so you really need three names, especially if you are using the same host table on multiple hosts on multiple subnets. Simpler to just use one name, and use naked IP addresses on the ifconfigs. Now consider a host on an subnet with only one gateway to the rest of the would. It needs a `route add default <gateway> 1' line. Again, the order of the entrys in the host table will determine which IP address is returned first. Another good place to use IP addresses. ? (Note that it's important for your customers to be able to ? purge YP entirely from their systems without causing any ? catastrophes.) This is an important point. So far, Sun has amazingly shown great restraint in not forcing YP down everyone's throat. As far as I know, YP has nothingh to do with the Arpanet Reference Model. It is a proprietary service, an RFC has not been written for it, and there is no mention in any of the host requirements for or of it. True, it is found in other vendor's implementations of NFS; Sequent, for example, has all the YP stuff in it's NFS librarys. It is my belief that for such vendors it is easier to just take the whole package than to split off just the good parts. Besides, they paid for it anyway, and too much software is better than not enuf, especially if you can throw the excess away. However, there remains a significant number of people out there (Steve and myself, among others) which are constitutionally opposed to YP. We will certainly not use it in its current form and may never use it in any form whatsoever. ? -Steve ? Spoken: Steve Miller Domain: steve@mimsy.umd.edu UUCP: uunet!mimsy!steve ? Phone: +1-301-454-1808 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742 ESIG2WIDE. Root Boy Jim is what I am Are you what you are or what?
gore@eecs.nwu.edu (Jacob Gore) (05/17/89)
/ comp.protocols.tcp-ip / rbj@DSYS.ICST.NBS.GOV (Root Boy Jim) / May 16, 1989 / >So far, Sun has amazingly shown great >restraint in not forcing YP down everyone's throat. They do force it if you are their customer. Their setup scripts tipically give you three choices: 1. YP server 2. YP client 3. not networked at all On most of their machines, you can do without YP, but it takes a lot of work to strip off all the stuff that refers to it, replace the libraries with BIND versions, etc. The 386i cannot be used without YP at all. Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,chinet,att}!nucsrl!gore
rbj@DSYS.ICST.NBS.GOV (Root Boy Jim) (05/18/89)
? / comp.protocols.tcp-ip / rbj@DSYS.ICST.NBS.GOV (Root Boy Jim) / May 16, 1989 /
? >So far, Sun has amazingly shown great
? >restraint in not forcing YP down everyone's throat.
? They do force it if you are their customer. Their setup scripts tipically
? give you three choices:
? 1. YP server
? 2. YP client
? 3. not networked at all
? On most of their machines, you can do without YP, but it takes a lot of
? work to strip off all the stuff that refers to it, replace the libraries
? with BIND versions, etc.
Well, yes and no. We run SunOS 3.5 with the 4.0 nameserver kit. All this
does is give you an MX sendmail that talks to the name server and a new
libresolv.a and netdb.h to build against. Actually, everything else
looks in /etc/hosts. If it's not there, you can use nslookup to find
the IP address and use the dotted notation raw. I haven't built any
kernels recently, but I seem to remember setup also giving you the
choice of not using YP at all.
? The 386i cannot be used without YP at all.
Hey, I was only talking about real Suns :-)
? Jacob Gore Gore@EECS.NWU.Edu
? Northwestern Univ., EECS Dept. {oddjob,chinet,att}!nucsrl!gore
Root Boy Jim is what I am
Are you what you are or what?melohn@ENG.SUN.COM (Bill Melohn) (05/18/89)
In article <7080015@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes: >/ comp.protocols.tcp-ip / rbj@DSYS.ICST.NBS.GOV (Root Boy Jim) / May 16, 1989 / >They do force it if you are their customer. Their setup scripts tipically >give you three choices: > 1. YP server > 2. YP client > 3. not networked at all This is misleading; the installation procedure used in the current versions of SunOS allow you to choose one of the following options for YP: server, master, client, or none. Independent of this choice is the configuration option for network interface. >On most of their machines, you can do without YP, but it takes a lot of >work to strip off all the stuff that refers to it, replace the libraries >with BIND versions, etc. Again, under current versions of the operating system, all that is required is the replacement of the shared library with one linked with the resolver routines. Such a library is available for FTP from several Internet sources, and in tape form from the US answer center. >The 386i cannot be used without YP at all. The above does not refer to the sun386i.
jordan@cs.columbia.edu (Jordan Hayes) (05/19/89)
Root Boy Jim <rbj@DSYS.ICST.NBS.GOV> writes:
Simpler to just use one name, and use naked IP addresses on the
ifconfigs.
The DNS was created to make things easier. Using IP addresses doesn't
make things easier. If you have two IP addresses on the same machine,
name them uniquely and put the following data into your database:
foo IN A 128.253.5.1
IN A 128.253.6.1
foo-gw IN A 128.253.6.1
That way, if I ask for "foo", I get two addresses to try. If I ask for
foo-gw, I get the right one. Your hostname (for any kind of external
identification) should be "foo" -- the only problem this leaves us is
what to do about the reverse lookup. Possibilities include returning
"foo" for either address (good for continuity), or returning the
interface-specific name (good for troubleshooting and correctness).
/jordangore@eecs.nwu.edu (Jacob Gore) (05/19/89)
/ comp.protocols.tcp-ip / melohn@ENG.SUN.COM (Bill Melohn) / May 18, 1989 / > In article <7080015@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes: > >They do force it if you are their customer. Their setup scripts tipically > >give you three choices: > > 1. YP server > > 2. YP client > > 3. not networked at all > > This is misleading; the installation procedure used in the current > versions of SunOS allow you to choose one of the following options for > YP: server, master, client, or none. Independent of this choice is the > configuration option for network interface. I apologize. I have only dealt with 4.0.1 on the 386i. Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,chinet,att}!nucsrl!gore
gore@eecs.nwu.edu (Jacob Gore) (05/19/89)
>Root Boy Jim <rbj@DSYS.ICST.NBS.GOV> writes: > > Simpler to just use one name, and use naked IP addresses on the > ifconfigs. / comp.protocols.tcp-ip / jordan@cs.columbia.edu (Jordan Hayes) / May 18 1989 / >The DNS was created to make things easier. Using IP addresses doesn't >make things easier. If you have two IP addresses on the same machine, >name them uniquely and put the following data into your database: > >foo IN A 128.253.5.1 > IN A 128.253.6.1 >foo-gw IN A 128.253.6.1 For ifconfig's??? In order for this to work, the name server has to be running on THIS machine, and you have to be able to launch it before you do the ifconfigs. It seems that it's much easier to start up network programs after the network interfaces are configured. IP numbers may not "make things easier", but they are predictable. I think they are reasonable names for specific interfaces. Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,chinet,att}!nucsrl!gore
db@helium.east.sun.com (David Brownell) (05/26/89)
In article <7080016@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes: >/ comp.protocols.tcp-ip / melohn@ENG.SUN.COM (Bill Melohn) / May 18, 1989 / >> In article <7080015@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes: [ someone said, "Sun doesn't ** make ** you run YP" ] >> >They do force it if you are their customer. Their setup scripts tipically >> >give you three choices: >> > 1. YP server >> > 2. YP client >> > 3. not networked at all >> >> This is misleading; the installation procedure used in the current >> versions of SunOS allow you to choose one of the following options for >> YP: server, master, client, or none. Independent of this choice is the >> configuration option for network interface. > >I apologize. I have only dealt with 4.0.1 on the 386i. Actually, it's slightly misleading even on the Sun386i packaging of SunOS, though the point that you weren't originally intended to network it without YP is correct. (No flames please; I really didn't like this, and this restriction ** is ** being removed in the next release.) The first choice is "yp master" (with extra services to maintain YP remotely); slaves have to be set up separately. Also, the only way a yp master is different from a non-networked system is that the non-networked one uses the internal loopback network for all its network traffic, not an Ethernet ... they're both YP masters. The reason behind this was to simplify things so that there would be just a single straightforward way to administer things. That's still something that'd be great to see, but it can't be done with the existing YP protocols. One of the main reasons is that YP doesn't have the kind of support that the name server does, allowing multiple domains to chat with one another. You really ought to be able to set up a machine as a domain all by itself and then use standard protocols to talk between domains, or to cooperatively construct larger domains from sets of smaller ones. I for one really look forward to using something that looks more like X.500 than YP, but that's a ways off into the future. Even then, I suspect that different sorts of applications will still need different ways to manipulate their own naming/configuration data. David Brownell dbrownell@sun.com Sun Entry Systems Software sun!suneast!db Billerica, MA David Brownell dbrownell@sun.com Sun Entry Systems Software sun!suneast!db Billerica, MA