Unable to resolve .foo.local domain names

My workplace has an intranet with domain names like server01.foo.local, server02.foo.local, etc. I recently booted the Fedora 16 live environment to test it out and discovered that these domain names do not resolve.

For example:

$ ping server01.foo.local
ping: unknown host server01.foo.local
$ ping server01
PING server01.foo.local (X.X.X.X) ...

Why will server01 resolve (and print the name as server01.foo.local), but server01.foo.local will not?

While I'm not 100% up on the reasoning behind why it doesn't work as expected, there seems to be a very large conflict with the mDNS service (Avahi in Linux, Bonjour/Zeroconf in Mac/Windows) and Windows networks that use .local as the internal routing name for domains. What seems to happen is that when pinging server01, it's skipping over using mDNS for resolution and then appending the search domain (foo.local) to the request, successfully querying the DNS server for server01.foo.local. However, when using mDNS (which uses .local as the default machine name extension), when you try to ping server01.foo.local, it's actually broadcasting over mDNS looking for a machine with the name of "server01.foo"; when it fails, it doesn't move on to straight-up DNS for whatever reason. A large workaround to this is not naming your domain .local, which probably goes against most Windows admins' training for domain structuring. That being said:

If mDNS is of no consequence in your network (as is common in the enterprise, which tends to run dedicated DNS servers versus the home network, where mDNS is sometimes used), then changing the search order is the easiest workaround.

This can be found in /etc/nsswitch.conf. The section for hosts will list the order, which for Fedora 16 default is:

hosts:      files mdns4_minimal [NOTFOUND=return] dns myhostname

If you change that to:

hosts:      files dns mdns4_minimal [NOTFOUND=return] myhostname

where you're moving dns ahead in the search order, that should fix things for now. Alternatively, if you know you're not going to need mDNS at all, just remove the "mdns4_minimal [NOTFOUND=return]" portion.

Looking at this bug on Red Hat's tracker, it seems that this is a long-standing problem with no apparent fix at the moment. Though, if someone can provide more insight as to why this happens this way, it'd be appreciated.

I'd suggest another solution in case you are using the .local domain. First it's not a good idea as it seems a standard/convention to use .local for some multicast dynamic discovery.

But if you insist, it is also easier to just remove nss-mdns package or libnss-mdns package depending on your distro and you'll get the issue resolved. If you don't need that functionality, then why have it lingering in there?

Here's yum info nss-mdns:

Summary     : glibc plugin for .local name resolution
URL         : http://0pointer.de/lennart/projects/nss-mdns/
License     : LGPLv2+
Description : nss-mdns is a plugin for the GNU Name Service Switch (NSS)
            : functionality of the GNU C Library (glibc) providing host name
            : resolution via Multicast DNS (aka Zeroconf, aka Apple Rendezvous,
            : aka Apple Bonjour), effectively allowing name resolution by common
            : Unix/Linux programs in the ad-hoc mDNS domain .local.
            : 
            : nss-mdns provides client functionality only, which means that you
            : have to run a mDNS responder daemon separately from nss-mdns if
            : you want to register the local host name via mDNS (e.g. Avahi).

Some things you can check:

• is there an order in /etc/host.conf, that specifies to check /etc/hosts before querying DNS?

• is server01 in /etc/hosts?

• is there a search foo.local in /etc/resolv,conf? That would append foo.local to any hostname you looking up

I wonder if your nameserver is set up correctly. If you still have nslookup, what does it return for server01, server01.foo.local and the ip-address (reverse lookup)?