Debian nowadays ships /etc/hosts like these per default:
127.0.0.1 localhost 127.0.1.1 <host_name>.<domain_name> <host_name>
The system hostname should always be resolvable even when the network is down. Basically, some applications still try to resolve a host via 127.0.1.1 so in order to accommodate, it is kept by default on current debian-type distributions.
The general rule of thumb is: If you don't have a permanent IP address for your host, use 127.0.1.1.
# No Permanent IP 172.0.0.1 localhost localhost.localdomain 127.0.1.1 blogs # Permanent IP 172.0.0.1 localhost localhost.localdomain 5.42.134.35 blogs
The hostname is not necessarily a domain name, 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 127.0.0.1 (and perhaps ::1) but often not to 127.0.0.0/8.
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 TLD. “localhost” is one of the reserved names, unlike ip6-localhost and friends and unlike .localdomain.
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 well.
The current way of having 127.0.1.1 <host_name>.<domain_name> <host_name> i.e. the hostname resolving to 127.0.1.1 leads to some issues, especially that you cannot reach those services that bind to 127.0.0.1 only. It also doesn't point to ::1.
These options could be used to resolve this:
Switch the <host_name>.<domain_name> <host_name> to 127.0.0.1 unless there is any strong reason to have it on another address.
In some tests:
127.0.0.1 localhost 127.0.0.1 foobar or (or the same entries swapped: 127.0.0.1 localhost 127.0.0.1 foobar.bar.net foobar or (or the same entries swapped: 127.0.0.1 localhost localdomain.localhost 127.0.0.1 foobar.bar.net foobar
all lead to the desired results
$ hostname foobar $ 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:
127.0.0.1 foobar.bar.net foobar not 127.0.0.1 foobar foobar.bar.net
The only question open here is, whether we generate:
127.0.0.1 localhost 127.0.0.1 foobar[.bar.net foobar] or 127.0.0.1 foobar[.bar.net foobar] 127.0.0.1 localhost
This controls what reverse resolution leads to (e.g. what tools like netstat show). The first ordering has a slight advantage as it 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 there is no technical reasons against, stop using 127.0.1.1 and let the hostname point to 127.0.0.1 as in:
127.0.0.1 localhost 127.0.0.1 foobar[.bar.net foobar]
This is probably less important but probably related:
Most people set the static IP address of a system for their hostname e.g.
127.0.0.1 localhost 66.66.66.66 foobar[.bar.net foobar]
Issues with that: