Why '.local' Is a Bad Choice for an Internal Domain

I installed Ubuntu 9.04 on a machine at work this week, and that went quite flawlessly except for one weird little problem. I could access machines on the local network by their short name (e.g. ‘einstein’) but not by their fully-qualified domain name (‘einstein.intra.local’).

Now, if it had been the other way around, the explanation would have been obvious: a missing ‘search intra.local’ entry in /etc/resolv.conf. But being able to resolve short names but not long ones, that was a new problem for me. I used nslookup to verify that the local name server was responding correctly to both forms, and it was. But any other application, from ping to Mozilla Firefox, failed to resolve the long form.

A colleague put me on the path to the solution, however. In the zeroconf protocol, which is implemented in Linux as Avahi and on the Mac as Bonjour, the .local domain is magic and is considered a reserved name. Hence, when Avahi is running, any address resolution queries for a machine name ending in .local, are intercepted and the DNS server never gets to see them (nslookup bypasses the usual resolver API, however).

This is apparently a known issue, but it was new and quite surprising to me. I didn’t bother to investigate who is at fault here: did the zeroconf people blatantly highjack a perfectly valid namespace, or has .local always been reserved and everybody but me knew about it? Anyway, it’s fair to assume that zeroconf is here to stay now, so network administrators take note: better call your local domain something else.

Once you know what it is, the solution is easy. In my case I wasn’t interested in the functionality offered by Avahi, so I just uninstalled it (sudo apt-get remove avahi-daemon). Alternatively, here is a receipt for disabling the special treatment of .local, but keeping the rest of the daemon running.