====== Network - What is the Meaning of 127.0.1.1 in the /etc/hosts File? ====== Debian nowadays ships /etc/hosts like these per default: 127.0.0.1 localhost 127.0.1.1 . 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 . 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 . to 127.0.0.1 ===== Switch the . 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 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] ===== Should the hostname point to a static IP address (or better said an address that is not the loopback)? ===== 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: * 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. If down, you cannot use the address anymore. * Firewalling: It may be safer knowing that stuff directed to the localhost really uses the loopback interface... and is not touched by any of the 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 . or actually are. If we would generally point them to 127.0.0.1, 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 special.// * 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.// 66.66.66.66 0.eth0.localhost 66.66.77.66 1.eth0.localhost 88.22.11.01 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 namespace. One could even do aliases like: 66.66.66.66 0.eth0.localhost 66.66.77.66 1.eth0.localhost 88.22.11.01 0.eth1.localhost 66.66.77.66 ssh.localhost 66.66.77.66 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 127.0.0.1 localhost 127.0.1.1 . even when they do have a static IP. ===== References ===== https://lists.debian.org/debian-devel/2013/07/msg00809.html