[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

/etc/hosts and resolving of the local host/domainname - vs.


Somme years ago Thomas Hood started a discussion[0] about how the system
hostname should be resolved.
The eventual result[1] was that Debian nowadays ships /etc/hosts like
these per default: localhost <host_name>.<domain_name> <host_name>

As also described in the Debian reference[2].

I had a short mail conversation with Thomas and he proposed bringing up
the following at d-d.

Some background:
- The hostname is not necessarily a domain name, at least not de jure.
But in reality, many programs and people rely or are at least used to to
the hostname being resolvable.
That practise won't change and we cannot do much about it.

- Most applications that listen to the loopback actually only listen to (and perhaps ::1) but often not to

- A system does not necessarily have a domainname set (e.g. during
installation). Whether this is a good idea or not (especially with
respect to security considerations) is beyond that mail.
At least we should say it doesn't have to.
I personally always set a domain (well my own domain) even on mobile
systems that are connected to arbitrary networks.

- The system hostname (and domainname if any) should ALWAYS be
resolvable, whether a network is up or not, regardless of which.
(Assuming that lo is always up, if not, many things break anyway.)

- "localhost" when added like this to /etc/hosts is basically like a
"localhost" is one of the reserved names, unlike ip6-localhost and
friends and unlike .localdomain.

- Back then, Thomas pointed out several ides on who the resolution could
be done (e.g. with a small nsswitch module) - I think the way
via /etc/hosts is probably the most simple one and also the one which
literally everybody will expect.
Therefore I don't suggest another system.

- The hostname MUST resolve to an address of the local host.
And if there is a domain name set, hostname.domainname MUST do so as

- The current way of having <host_name>.<domain_name> <host_name>
i.e. the hostname resolving to leads to some issues,
especially that you cannot reach those services that bind to
It also doesn't point to ::1.

So I have basically two proposals / things to discuss:

I) Switch the <host_name>.<domain_name> <host_name> to unless
there is any strong reason to have it on another address.

I made some tests:
/etc/hosts (or the same entries swapped):       localhost       foobar
or (or the same entries swapped:       localhost       foobar.bar.net     foobar
or (or the same entries swapped:       localhost localdomain.localhost       foobar.bar.net     foobar

all lead to the desired results
$ hostname 
$ hostname -f
foobar respectively foobar.bar.net
$ hostname -d
<nothing> respectively bar.net

even hostname -a works as it should.

So the only thing that needs to be secured for the correct resolution is
that we don't mix up the localhost line with the foobar line.
And the order of the line's entries is important, e.g. it must be:       foobar.bar.net     foobar
not       foobar     foobar.bar.net

The only question open here is, whether we generate:       localhost       foobar[.bar.net     foobar]
or       foobar[.bar.net     foobar]       localhost

This controls what reverse resolution leads to (e.g. what tools like
netstat show).
I personally would take the first ordering,... since one sees localhost
then which usually makes it really clear what happens.

Further, but this isn't the case anymore anyway,... we should not
generate localhost.localdomain.

=> so the overall proposal (I) is:
If no one has any technical reasons against, can we stop using
and let the hostname point to as in:       localhost       foobar[.bar.net     foobar]

II) The second proposal is IMHO less important but probably related:
Should the hostname point to a static IP address (or better said an
address that is not the loopback)?

Most people set the static IP address of a system for their hostname
e.g.       localhost     foobar[.bar.net     foobar]

Issues with that:
- Even if static, the iface may be up or not... sure this is true for lo
as well,... but lo usually always works... with some fancy network card
you can easily have driver problems (I could tell you some stories about
the myrinet cards at our institute).
If down, you cannot use the address anymore.

- Firewalling: I personally feel more safe if I know that stuff directed
to the localhost really use the loopback interface... and are not
touched by any of my (e.g.) eth0 firewall rules.

- Predictability:
When we set 127.x.x.x as default on systems with no static IP, and
x.x.x.x on the others... on does not immediately know on a system what
<host_name>.<domain_name> or <host_name> actually are.
If we would generally point them to, it would be always clear,
hostname = loopback.

- "Primary Interface"
At least nowadays, there is probably nothing like a primary iface
anymore. I guess there never really was actually.
Setting one static IP address for the hostname makes this one however

- Problems
I must say though, that I have meet several programs which do some weird
ways of interface discovery, and these will break when one doesn't set
the global IP address.
The problem with such is that they don't let you configure the bind
address, but always use the hostname to detect it.
Don't know about any in Debian, but at the institute we have troubles
with that issue with e.g. dCache.

Now some people may argue, that they conveniently use the feature of
some programs, which allow to configure the bind addresses via
hostnames. If the address changes, you just adapt /etc/hosts,... and all
these services will automatically pick it up (at the next start).
Sure, this is handy and I use it myself, but nothing keeps people from
doing things like.     0.eth0.localhost     1.eth0.localhost     0.eth1.localhost

That's a simple schema I use,... 0. gives a number for the address, eth0
the interface which listens for it and localhost is used as a reserved

One could even do aliases like:     0.eth0.localhost     1.eth0.localhost     0.eth1.localhost     ssh.localhost     http.localhost

If I want to move ssh to another IP,.. I simply change that address, and
OpenSSH will pick it up next time, as well as iptables will.
Tools like netstat will sill show me the "neutral" 0.eth0.localhost
instead of ssh.localhost, due to the ordering.

Anyway... proposal (II) is basically:
Don't force but encourage people to use localhost <host_name>.<domain_name> <host_name>
even when they do have a static IP.

So... waiting for your technical advise :)


[0] http://lists.debian.org/debian-boot/2005/06/thrd2.html#00639
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316099

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: