scs@iti.org (Steve Simmons) (02/15/90)
Over the years I've noticed that most folks set the hostname to the fully qualified domain name. We've always made them simple hostnames, then relied on proper sendmail.cfs, etc, to add our domain as appropriate. Recently we've bumped into some vendor software bugs for which the workaround is to make hostname == FQDN. The vendor agrees their performance isn't correct, but we're not likely to see a real fix in the next couple of days. We're loathe to do things different on 'just one machine', and would prefer consistancy. I'm interested in any and all comments on why or why not to set hostname to FQDN.
keith@spider.co.uk (Keith Mitchell) (02/21/90)
scs%itivax%ox.com%umich%mailrus%cs.utexas.edu@tut.cis.ohio-state.edu
(Steve Simmons) writes:
"... I'm interested in any and all comments on why or why not to set
hostname to FQDN...." (FQDN = Fully Qualified Domain Name)
This is something I have found a bone of contention for a while. In
theory it shouldn't make any difference if you are running BIND, as
the "domain" directive in /etc/resolv.conf (or /etc/named.boot ?)
should tack it on to any unqualified hostnames you enter. I think the
principle of always using FQDNs is a good one, provided you can have
this short-cut for user input. Naive users certainly don't want to
know about domains.
In practice, however, the implementations are never quite up to it.
For example:
- rshd does not appear to pick up the default domain as above. So
you have to put a fully qualified name into your ".rhosts" or
"hosts.equiv" even if you're normally used to just the short name.
Ultrix V3 & SCO TCP/IP do this, but Excelan EXOS software gets it
right, and MIPS RISC/os 4.0 has a work-around.
- Some sendmails use the resolver library so that the "$w" (ie this
host's name) macro gets set to the FQDN, others just the basename.
This can lead to delightful behaviour such as:
"HELO redknee.spider.co.uk.spider.co.uk" if the sendmail.cf isn't
smart to it - I have yet to fix mine to get this right. Here,
Ultrix gets it right, and RISC/os and SCO get it wrong.
Your comment "The vendor agrees their performance isn't correct.."
intrigues me, as in the face of the above diverse behaviour I'm
confused as to what the correct behaviour IS. If anyone can throw
light on this, or what resolver calls are involved that produce the
above behaviour, I would be very keen to more. We would like to have
consistency in our sendmail.cf files, too.
Other FQDN problems I can think of would be clashes with Yellow
Pages, and the fact (minor one, this) that the domain qualification
can cause visual clutter in for example, "netstat" output. A output
option of "don't qualify hostnames" might be a nice way round this.
(Or how about "only qualify if it's not the local domain" ?)
Anyone else have experience of these ones ?
Keith Mitchell
Spider Systems Ltd. Spider Systems Inc.
Spider Park 12 New England Executive Park
Stanwell Street Burlington
Edinburgh, Scotland MA 01803
+44 31-554 9424 +1 (617) 270-3510
keith@spider.co.uk keith%spider.co.uk@uunet.uu.net
...!uunet!ukc!spider!keith keith%uk.co.spider@ukc.ac.ukscs@VAX3.ITI.ORG (Steve Simmons) (02/23/90)
> scs%itivax%ox.com%umich%mailrus%cs.utexas.edu@tut.cis.ohio-state.edu > (Steve Simmons) writes: > >"... I'm interested in any and all comments on why or why not to set >hostname to FQDN...." (FQDN = Fully Qualified Domain Name) . . . >In practice, however, the implementations are never quite up to it. >For example: . . . >Your comment "The vendor agrees their performance isn't correct.." >intrigues me, as in the face of the above diverse behaviour I'm >confused as to what the correct behaviour IS. If anyone can throw >light on this, or what resolver calls are involved that produce the >above behaviour, I would be very keen to more. In this vendors case, we can make the system hang 100% reliably by using unqualified names in the right circumstances. The workarounds (which do work, thank god!) require going 180 degrees to the vendors and UCBs bind documentation on some points. The vendor agrees the documentation is correct, the performance incorrect. To summarize the responses to my original item: Almost everyone said we should go to FQDNs even though they were not strictly required; the remainder claimed they were strictly required. This requires rebuilding our sendmail.cfs :-( our news files :-( our hosts files :-( our host.equiv files :-( . . . well, you get the idea. In addition, there is one *major* problem with this: many implementations allow a very limited size for the host name -- twelve and sixteen characters are the sizes most often cited. We have some of these systems in-house, mercifully we also have short fqdns on almost all systems (foo.iti.org). The problems we have with unqualified host names seem to be surfacing because so few sites use them in a true DNS enviroment. As such, the software for lots of packages has never been as thoroughly exercised in this area and we are the 'first discoverers' of bugs (remember the early days of intermixing YP and DNS? That uncovered a lot of previously unknown bugs). Since many of our systems are from proprietary vendors, we've decided to bite the bullet, make the changes to all the things above, and get in step with the rest of the world. Many thanks to all for the advice. Steve
owen@DG-RTP.DG.COM (Karl Owen) (02/23/90)
> From: Steve Simmons <scs@vax3.iti.org> > Subject: Re: Use Domain In Hostname Or Not? > To: keith@spider.co.uk (Keith Mitchell) > Date: Thu, 22 Feb 90 12:58:19 EDT > Cc: scs@itivax.iti.org, tcp-ip@nic.ddn.mil, bind@ucbarpa.Berkeley.EDU > > > scs%itivax%ox.com%umich%mailrus%cs.utexas.edu@tut.cis.ohio-state.edu > > (Steve Simmons) writes: > > > >"... I'm interested in any and all comments on why or why not to set > >hostname to FQDN...." (FQDN = Fully Qualified Domain Name) > . . . > > To summarize the responses to my original item: > > Almost everyone said we should go to FQDNs even though they were not > strictly required; the remainder claimed they were strictly required. > This requires rebuilding our sendmail.cfs :-( our news files :-( our > hosts files :-( our host.equiv files :-( . . . well, you get the idea. I'm not sure that I agree with this. We should be able to live with unqualified names as shortcuts. The burden belongs on the systems implementors, not on the users. For example, a simple library routine can be used to strip most of the clutter from netstat and to allow rshd and rlogind to recognize local parts of domain names. The routine looks up the domain part of the FQDN by doing a gethostbyname() on the result of gethostname(). It can then compare the domain part to the domain part of any FQDN and strip the domain part if appropriate. Karl -- Karl M. Owen owen@dg-rtp.dg.com Data General, RTP, NC ...!mcnc!rti!xyzzy!owen
vcerf@NRI.RESTON.VA.US (03/02/90)
I suggest that the important rule to follow is that any mail you export from a local domain which goes out on the Internet always bear a fully qualified domain name on all addressees. What you do with message copies internally is your business, but we need fully qualified names on anything flowing to the rest of the world. Vint Cerf