Re: CVS commit: src/bin/hostname

[matthew sporleder <msporleder%gmail.com@localhost>]

On Thu, Jul 25, 2013 at 7:10 AM, Robert Elz <kre%munnari.oz.au@localhost> wrote:
>     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
>



I've run hundreds of systems which use either a short hostname (no
domain) or which have zero relation to their DNS, forward or reverse
(amazon instances).  This included mail servers.

I think it is most common for systems to use a single, short name and
then fully qualify it in /etc/hosts (maybe).

Systems with multiple IP addresses, existing on many vlans, NAT-ing
traffic here and there, running many VirtualHosts (web or email), who
are members of a pool of systems configured similarly, etc, completely
ruin any idea that forward and reverse dns mean anything to a server.

In my opinion, the more options, the better.  Networks are complicated
and real life system installs even more so.
If you can hack together a system of naming that works -for you-, then do it.

Matt