Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

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
add comment

2 Answers

up vote 11 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 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.

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
add comment

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

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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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