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.