Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I think this started with the Snow Leopard update. Cleaned out the .ssh directory, still having the issue.

~: uname -a
Darwin california-example-com.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386

~: ssh -V
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009

~: ls -l ~/.ssh

~: nslookup nevada
Server:     10.94.62.3
Address:    10.94.62.3#53

Name:   nevada.example.com
Address: 10.94.62.3

~: ssh nevada
ssh: Could not resolve hostname nevada: nodename nor servname provided, or not known
share|improve this question
    
Can you ssh to (a) nevada.example.com and (b) 10.94.62.3? –  SvW Sep 12 '09 at 20:02
2  
Can you ping nevada? What does "ssh -v nevada" show? –  markdrayton Sep 12 '09 at 20:44
    
Odd question; do you use Split DNS and/or can ping nevada? –  Chealion Sep 13 '09 at 6:48
    
Thanks for the follow-ups... answers: ssh nevada.example.com = no ssh 10.94.62.3 = yes (and had to confirm host key because I'd cleared known hosts) ping nevada = name resolution problem telnet nevada (tho it doesn't run telnetd) = name resolution problem Split DNS = not intentionally, don't know what it is :-) From OS X network settings pane, I've got 10.94.62.3 as the DNS server listed before the two provided by my ISP, and example.com in the search domains list. Other systems on my network can use DNS normally to ssh to nevada (and others). –  Peter Cardona Sep 13 '09 at 17:21
    
sorry about the lack of line breaks in the above comment... –  Peter Cardona Sep 13 '09 at 17:22
add comment

10 Answers

up vote 15 down vote accepted

I ran into the exact same problem and found a thread about a Mac mini having DNS issues on Apple's Discussions extremely helpful.

The crux of the issue: mDNSResponder seems to occasionally change the order of the DNS servers it queries and so if it queries your ISP's DNS servers first it won't get a proper record (or if you're using split DNS you'll get your public IP).

The best fix for this is to ensure (as you did) that only the required DNS servers are listed in your DNS settings. This may require removing the ISP DNS servers from your DHCP (as I had to do as well - all requests are forwarded through the local DNS server anyway).

The reason utilities like dig and nslookup will succeed as normal is they are using BIND and /etc/resolv.conf directly unlike the rest of the operating system.

For reference in Snow Leopard the DNS cache is now stored by mDNSResponder and in order to clear it you need to restart the process using sudo killall -HUP mDNSResponder. You can get more info (logging, dump internal state, etc.) by using different flags to the killall command.

"sudo killall -USR1 mDNSResponder" to enable operation logging.
"sudo killall -USR2 mDNSResponder" to enable packet logging.
"sudo killall -HUP mDNSResponder" to clear the DNS cache.
"sudo killall -INFO mDNSResponder" to dump mDNSRepsonder's internal state.

Source: Snoop Dogg on that same thread.

share|improve this answer
    
Thanks, googling led me here, this fixed it. "arp" reported the wrong IP, dig reported the correct "ip". No amount of dns flushing fixed it before I tried this. I do note that I had to execute the dscacheutil -flushcache as well. I'd also point out that local routers can behave strangely and ISPs don't also play fair in terms of TTL sometimes. –  Aitch Oct 5 '11 at 9:18
add comment

we had problems like this:

host example.com     <<< WORKED
ping example.com     <<< FAILED

Solved with something like this:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Applications on Mac OS X do not use the same mechanism for DNS as "host/dig/nslookup".

Using "host/dig/nslookup" were useful for determining this was not a network issue. It was an issue with the local system resolved with the above commands.

share|improve this answer
    
wow that worked!!! I've been looking everywhere for a solution!!!! i was just about to format and restore my laptop, you saved me a ton of time! thanks! sorry but I couldn't upvote :-( Note: My DNS stopped working after I ran the Util OnyX, don't know why. I was able to use dig/nslookup but nothing else. –  user85044 Jun 20 '11 at 3:13
add comment

I've experienced the same problem… And while restarting mDNSResponder does seem to "work", restarting it a couple of times every hour sort of sucks.

So, for now, I've "solved" the problem by running dnsmasq locally. To do that:

  • Build dnsmasq (download the tgz and make or brew install dnsmasq)
  • Put this in a dnsmasq.conf file:
resolv-file=resolv.conf
user=nobody
group=nobody
interface=lo0
cache-size=1024
  • Put this in a resolv.conf file that is in the same directory as the dnsmasq.conf file (nb: not /etc/resolv.conf):
nameserver 8.8.8.8
nameserver 4.2.2.1
nameserver 4.2.2.2
  • Run dnsmasq with sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf. The output should look something like:
...
dnsmasq: reading resolv.conf
dnsmasq: using nameserver 4.2.2.1#53
dnsmasq: using nameserver 4.2.2.2#53
dnsmasq: using nameserver 8.8.8.8#53
dnsmasq: read /etc/hosts - 6 addresses
  • Open Network Preferences and make sure that 127.0.0.1 is the only DNS server (network preferences -> advanced -> DNS -> add 127.0.0.1)

Things should begin to work nicely again.

Once things are working, you can run dnsmasq without the --no-daemon and --log-queries options, so it will start in the background and you don't need to keep a Terminal window open.

share|improve this answer
add comment

I noticed I had 10.94.62.3 in the DNS server list (network prefs pane) followed by 2 from my ISP. I removed the other 2, forcing all name lookups thru 10.94.62.3 for this Location and now I can resolve names on my network as well as outside.

No idea why this worked.

share|improve this answer
add comment

I guess we have a similar issue, as I described here: http://apple.stackexchange.com/questions/50457/nslookup-works-ping-and-ssh-dont-os-x-lion-10-7-3

I believe, the problem lies within the searchdomains configuration: ping/ssh trying to use gethostbyname2() which fails because named is not running anymore (in Lion at least) and /etc/resolv.conf with the configured searchdomains is thus ignored. /etc/hosts is the last resort for gethostbyname2() and thus ssh works again with proper entries in /etc/hosts. Should be fixed by Apple imho.

share|improve this answer
add comment

Have you tried nevada-example-com.local?

share|improve this answer
    
Had not tried that, but got same resolution issue. Starting to seem like NOTHING (ssh, telnet, ping, http) resolves thru the server that nslookup is defaulting to. How could that be? Maybe a conflict between the OS X level settings and some /etc/whatever file that the underlying BSD implementation cares about? –  Peter Cardona Sep 13 '09 at 17:25
    
No, OS X does not use init levels — not even the BSD syubsystem. –  Nerdling Sep 13 '09 at 20:05
add comment
dscacheutil -flushcache

That command refreshes your DNS cache.

Is 10.94.62.3 a DNS Server you trust? If so, why is there only one? You should have at least 2 DNS servers to refer to for failover purposes. If that one goes down, you're a sitting duck.

share|improve this answer
add comment

DNS order lookups seems to work differently in Snow Leopard. If you can't lookup a domain, check to see if you have any invalid DNS servers listed in your network preferences. If you are using a standard DHCP setup, then you shouldn't have any DNS Servers listed. Prior to my upgrate I had an old DNS server listed, and it didn't affect anything. Once I upgraded I totally lost dns.

Open Network Preferences > Choose Airport > Advanced. Select the DNS tab, and remove any DNS Servers that are invalid.

share|improve this answer
add comment

Have you looked at Console? (Applications -> Utilities -> Console) You may find that mDNSResponder is showing up under: Diagnostic and Usage Information -> System Diagnostic Reports

If it's crashing due to another program which is loading modules (such as Little Snitch or Hands Off) you may see it there.

share|improve this answer
add comment

I had the same problem with nslookup resolving my windows box, but ping giving me a "unknown host". I tried what Navdeep suggested and went to clear out the nameservers in the Network Preferences->Advanced->DNS tab. It would not let me subtract them, they were grayed out. I finally hit the + and they disappeared. I canceled adding a new one and applied changes, once no DNS servers were showing. Ping started working after that. The strange thing is that my local router/DHCP server was the first in the list and is the one responsible for resolving the Windows box. It must be something weird with the ordering. The other nameserver listed, is a work NS and would not be able to resolve the windows host. THANKS Navdeep!

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