Re: CVS commit: src/bin/hostname

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 25 Jul 2013 08:23:26 +0100
    From:        David Laight <david%l8s.co.uk@localhost>
    Message-ID:  <20130725072326.GS24004%snowdrop.l8s.co.uk@localhost>

  | There are many (well some) systems that don't have a FQDN, and where there
  | isn't one that can be assigned.

Then one should be obtained for it ... these days domain names are cheap,
if you can afford a computer, you can afford to get it its own private
registered domain to go along with it - or if you have one already for
some other computer, you can save a few $s and share the domain...   There's
really no excuse for not doing that, it is quick and easy (and if you don't
care what the domain is, just that you have one, then trivially easy to
acquire.)

  | A modern example might be some kind of portable system system that
  | only ever connects to the outside world using wifi hotspots.
  | An older example would be a single system using dialup networking.

What does that have to do with anything?   Where the system is connected
(or how) is totally unrelated to its name.   Think of the computer name
being just like your personal name - think of what life would be like for
you if all you had was just "David" and no surname to go along with it
(of course, personal names aren't unique, which does cause problems, but
making them less unique makes the problems worse.)   But given that you
are David Laight you remain David Laight no matter what house (or flat) you
live in, or who you work for, or ...    The name is independent of the
connection point.   You can of course change your name, as a computer can
change its hostname, but both you and it should always have a name to use
anytime you need to use a name.

  | IIRC one of the original uses for FQDN was for email routing
  | (user@host.domain).But even then we always published addresses
  | user@mail_domain so that the outside world didn't know which machine
  | users read their mail on 'today' (that involved groging the sendmail
  | masquerade options).

Well, my e-mail address (munnari.oz.au) is a hostname ...  user%oz.au@localhost 
would
result in mail failing for certain (regardless of what the user part is).
[Aside: munnari.oz.au isn't in Australia though - it was once, but hasn't
been for many years now.]     But yes, you're right, most hosts don't need
fqdn's in order to receive incoming e-mail.

  | Since a system can have multiple IP addresses, subsets of which are
  | returned by forwards DNS lookups on many FQDN from different domains
  | it can have nothing to do with IP addresses!

Absolutely agreed - which is one reason all those dumb options added
to hostname(1) recently that related to address lookups are inappropriate.

  | For smtp EHLO you really want a name that will forwards lookup to the
  | source IP of the connection, that can only be determined after the
  | connection is established.

I have no idea what you're thinking of there.   The name in the EHLO (or HELO)
command should be the (or perhaps a) name for the host running the MTA.
That is, the (or one of the) host's globally unique names.   That's all that
is required of it - the receiving system will use it for logging, and
things like that (and may - these days probably will - verify that it
maps to the incoming IP address, but if that fails, it just means extra warning
text in the log) - it is certainly never intended to be used as an
e-mail address (and what's more the originating system isn't required to
have a smtp server running to receive incoming e-mail, now or ever.)

But as long as it is a name that belongs to the source host, it is irrelevant
which name is used if the host happens to have more than one.

  | So it isn't anything to do with mail transfer either.
  | (Yes, I know MTA have a habit of trying to find a FQDN at startup)

Actually, e-mail is one good example - the hostname is needed for the
Received headers that all MTAs are required to add (and those then get sent
on to the next system, so they need to be global names, not just local ones).
Further, message-id generation, whether done by the MTA, or by an MUA
(pkgsrc/mail/nmh generates message-ids itself if asked to do so, which is
the way I run it) - for that we must have a globally unique host name, both
because the standards require it (yeah, if that was the only reason I wouldn't
really care) and because it is the only way I can think of to actually be able
to guarantee generation of unique ids (unique to one message amongst all 
messages ever generated, by anyone, ever.)

Look at the message ID of this message - it isn't 
anything%munnari.oz.au@localhost
because it is being generated by nmh from my laptop.   Rather it's in kre.to
which is a domain that I (big surprise) have registered just for purposes
like this - I think there are some MX records to allow sending e-mail to
some of the hostnames that exist in it, but probably not all of them, but
apart from that, there's little practical use in names in that domain.
But it does mean that all my hosts (or virtual hosts in this case since
perseus is just NetBSD in a virtualbox) get unique names as they should.

  | So we now get down to things like the name in the security report emails.
  | Purely local significance.
  | 
  | What have I missed??

Ronald Dowdes gave you a list of other places where hostnames are used.
And X11 is certainly one of them ... in fact, as I have things configured
(largely for X11's benefit) illustrates why the DNSlookup(Rev-Lookup(hostname))
trick that is supposed to expand nicknames fails ... I put my hostname
in /etc/hosts (as do many people) and give it 127.0.0.1 (and ::1) as the
address assigned to the host.   Do a lookup on the hostname, you get ::1
(or 127.0.0.1 if it's a v4 lookup).  Do a reverse lookup on that (either of
them) and you get "localhost." back - as the localhost lines come earlier
in /etc/hosts, and they're also 127.0.0.1 and ::1.

The reason for 127.0.0.1 (or ::1) being assigned to the hostname is that it
makes X11 connections use local domain networking, and that makes them
(minutely) faster than using true IP.

But it really is more than just finding examples of places where the
hostname is used.

What really matters is what assumptions software can make about the
hostname - and for that we really should be allowing software to assume
that the name returned (whether via hostname(2), uname(2), or sysctl(2))
is a globally unique name.   nmh certainly assumes that, configure the
hostname to be just 'pc1' and you'll get message-id's that are
unique-local-stuff@pc1 which is non-compliant, and useless.

This is what's important.   If we need any changes to hostname(1), the
one change I'd be making (to what was there a week ago) would be to verify
that there's at least one '.' in the hostname supplied when setting the
hostname, and bitch loudly (and refuse to set it) if there isn't.  There's
no way to actually verify uniqueness, but we can at least weed out the trash.

Lastly, there are of course many hosts that don't need a name at all.
I'm sure there's one of those in my microwave oven, and probably a few more
in my car.   That's fine - nothing requires hosts to have a name if they're
not going to use it.  What's more, if you don't use anything that needs it,
NetBSD runs just fine with no hostname assigned at all.   Just if you go to
the trouble of actually assigning a hostname, make it a useful one.

kre