[Bug 604283] [NEW] network servers do not listen on 127.0.1.1

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

Binary package hint: ifupdown

release: Ubuntu 10.04 LTS (but probably all releases back to Hardy and forward to Maverick)
package: ifupdown: Installed: 0.6.8ubuntu29

Since upgrading my systems to lucid and cleaning up the configurations,
I've noticed strange behaviour where client tcp or udp sessions to local
tcp/ip servers have timed out even though the servers were running and
netstat showed they were listening on all interfaces. Wireshark traces
showed that successful connections went to 127.0.0.1, while any
connection attempt to 127.0.1.1 would fail.

The systems are fully controlled by NetworkManager <offtopic>a long and painful story!</offtopic> and so /etc/network/interfaces contains only two lines:
    auto lo
    iface lo inet loopback

This "minimal configuration" is not only highly recommended to avoid
wierd behaviour with NetworkManager, but also to avoid problems with
upstart (e.g.
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/497299). All the
other network interfaces are managed by NM.

"In the old days", a typical /etc/hosts file would define all the local hostnames as follows:
    127.0.0.1  myhostname.localdomain  myhostname  localhost.localdomain  localhost 

For several releases (back as far as Hardy), ubuntu installations have been creating a more sophisticated version of the hosts file (presumably because of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316099), e.g.
    127.0.0.1  localhost
    127.0.1.1  myhostname.mydomain  myhostname

This modern variant allows the system to always resolve its own hostname
and canonical name, even when there is no external network.

It appears to work really well... e.g. "ping hostname" and "ping
localhost" both succeed. "hostname" and "hostname -f" return the
expected values. (note: I don't fully understand why ping hostname
actually works - perhaps because the class A 127.0.0.0 subnet has been
defined for ever as a loopback subnet?).

The problem comes when a local client tries to connect to a local server... a well-behaved server will listen on "all available network interfaces", e.g.
    brian at myhostname:~$ netstat -ln | grep 53
    tcp        0      0 10.1.252.115:53         0.0.0.0:*               LISTEN     
    tcp        0      0 192.168.252.115:53      0.0.0.0:*               LISTEN     
    tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN     
    udp        0      0 10.1.252.115:53         0.0.0.0:*                          
    udp        0      0 192.168.252.115:53      0.0.0.0:*                          
    udp        0      0 127.0.0.1:53            0.0.0.0:*                          

... so, when a client tries to connect to the local server (in my not
very realistic example you would have to edit /etc/resolv.conf to point
to myhostname instead of the default localhost), the nslookup connection
would never be received by the local bind server and so will eventually
time out.

If we are to keep the "new style" hosts file structure (and I think we
should), then we MUST ensure that local servers are able to access all
available interfaces, including BOTH of the loopback addresses mentioned
in the hosts file, so we need to define an additional interface for the
myhostname loopback address.

This can be easily demonstrated by defining a second (virtual) address for the lo interface:
    sudo ifconfig lo:0 127.0.1.1 netmask 255.0.0.0

Stop the server and it will discover the extra interface when it is restarted:
    brian at myhostname:~$ netstat -ln | grep 53
    tcp        0      0 10.1.252.115:53         0.0.0.0:*               LISTEN     
    tcp        0      0 192.168.252.115:53      0.0.0.0:*               LISTEN     
    tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN     
    tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN     
    udp        0      0 10.1.252.115:53         0.0.0.0:*                          
    udp        0      0 192.168.252.115:53      0.0.0.0:*                          
    udp        0      0 127.0.1.1:53            0.0.0.0:*                          
    udp        0      0 127.0.0.1:53            0.0.0.0:*                          

Of course, this circumvention will only last until the next reboot. The
solution can be made permanent by updating the
/etc/networking/interfaces file to automatically bring up both loopback
interfaces early in the boot process:

    # This file describes the network interfaces available on your system
    # and how to activate them. For more information, see interfaces(5).

    # automatically bring up both these interfaces at boot (ifup -a == all)
    auto lo lo:0

    # The standard loopback network interface
    iface lo inet loopback

    # another loopback interface for that pesky dual loopback hosts file
    iface lo:0 inet static
      address 127.0.1.1
      netmask 255.0.0.0

I do not know if there is a more elegant solution to the same problem
(but remember that some of the server processes are started very early,
hence the upstart bug reference above).

If acceptable, this bug should be pushed upstream to encompass the other
distros that use the same multiple loopback interface /etc/hosts file
organisation.

** Affects: bind9 (Ubuntu)
     Importance: Undecided
         Status: Invalid

** Affects: ifupdown (Debian)
     Importance: Unknown
         Status: New


** Tags: patch udd-find
-- 
network servers do not listen on 127.0.1.1
https://bugs.launchpad.net/bugs/604283
You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to bind9 in Ubuntu.