Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My workplace has an intranet with domain names like,, 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
ping: unknown host
$ ping server01
PING (X.X.X.X) ...

Why will server01 resolve (and print the name as, but will not?

share|improve this question
Had exactly the same problem with Ubuntu running in VMBox. @adam820's solution worked for me as well. – jimbojw Jan 25 '12 at 21:22
up vote 15 down vote accepted

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 However, when using mDNS (which uses .local as the default machine name extension), when you try to ping, it's actually broadcasting over mDNS looking for a machine with the name of ""; 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.

share|improve this answer
removing the mdns section resolved the issue – rhollencamp 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. – jimbojw Jan 25 '12 at 21:21

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, and the ip-address (reverse lookup)?

share|improve this answer
* 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 – rhollencamp Nov 10 '11 at 15:31
@rhollencamp: do you have nslookup on your system? – ott-- Nov 10 '11 at 16:15

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         :
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).
share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .