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?

  • Had exactly the same problem with Ubuntu running in VMBox. @adam820's solution worked for me as well.
    – jimbo
    Jan 25 '12 at 21:22

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.

  • removing the mdns section resolved the issue Nov 10 '11 at 21:54
  • Thank you soooooooo much for adding this. Had exactly the same problem and moving the dns entry first solved it. In my case, I'm using latest Ubuntu, not Fedora, but the solution was exactly the same.
    – jimbo
    Jan 25 '12 at 21:21
  • worth nothing, I just tried this and found that cisco VPN's using vpnc cannot connect after removing those entries on the hosts: .* line in /etc/nsswitch.conf. Replacing these settings fixed the issue.
    – dobbs
    Jul 28 '17 at 15:42
  • " when it fails, it doesn't move on to straight-up DNS for whatever reason." . The reason is fairly obvious. [NOTFOUND=return] means "if mDNS tells you a .local name is not found, then that is authorative, and there's no point in asking further". Moving DNS before mDNS is a work-around, but just making mDNS failures non-authorative is already sufficient.
    – MSalters
    Nov 7 '17 at 13:23
  • Yes, that is a valid comment; this was 7 years ago and I didn't know that at the time. But yes, removing it, removing the package as noted below, or changing the order are all valid workarounds/solutions.
    – adam820
    Oct 4 '18 at 16:58

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)?

  • * host.conf has nothing about order * server01 is not in /etc/hosts * search foo.local is in /etc/resolv.conf (NetworkManager put it there), but removing it does not help. I tried write-protecting /etc/resolv.conf after editing it so NM could not overwrite and rebooting; no dice Nov 10 '11 at 15:31
  • @rhollencamp: do you have nslookup on your system?
    – ott--
    Nov 10 '11 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.