Nslookup & dig fail; ping, traceroute, and scutil -r work

dnsping

I'm running on 10.8.2. All of a sudden, traditional nameserver lookups are failing on my machine:

$ nslookup www.att.com
;; connection timed out; no servers could be reached

$ dig www.att.com

; <<>> DiG 9.8.3-P1 <<>> www.att.com
;; global options: +cmd
;; connection timed out; no servers could be reached

But operations that use name services work fine:

$ scutil -r www.att.com
Reachable


$ ping www.att.com
PING e2318.dscb.akamaiedge.net (23.1.57.145): 56 data bytes
64 bytes from 23.1.57.145: icmp_seq=0 ttl=55 time=22.862 ms
64 bytes from 23.1.57.145: icmp_seq=1 ttl=55 time=26.947 ms
^C
--- e2318.dscb.akamaiedge.net ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 22.862/24.904/26.947/2.043 ms

I've tried setting the name server addresses to different destinations via the network system preference (e.g., 4.2.2.2, 208.67.222.222, 208.67.220.220, etc.) but that doesn't seem to make any difference.

I'm guessing there is an internal configuration file for the on-board DNS server that isn't getting updated, but I haven't a clue where to look for that.

Best Answer

I'm still not sure what was causing the problem, but after suffering from another seemingly unrelated issue, I did a complete re-install of 10.8. I had originally upgraded from 10.6 -- though the utilities had seemed to work fine for a while after the initial upgrade, my suspicion is that I did something to some unknown-to-me configuration while attempting to diagnose/resolve the other issue (something that apparently disabled some aspects of DNS access).

After the re-install, all DNS-related utilities are now working fine.

Related Solutions

DNS lookups fail with e.g. `ping`, but work with `host`

Why they made this change, I don't know, but it's driven me crazy for a while.

I don't know why things work for host, but not ping, but I think it has to do with the nature of these two utilities. Ping is a simple (although very helpful) diagnostic utility for dropping packets on the wire that should get echoed back to you. The hostname lookup functionality is just a side effect of the job and handed off to the system's recursive resolver (I believe -- I haven't verified by checking linked libraries or anything of that sort). Host's main job is to do DNS name resolution, so it implements its own recursive resolver.

Apple's recursive resolver is mDNSResponder. For some reason, the version of mDNSResponder in Lion needs the "-AlwaysAppendSearchDomains" command line option to behave as it did in Snow Leopard (at least).

Here's a quick way to fix it:

sudo sed -i .orig '/ProgramArguments/,/<\/array>/ {
s/\(<string>-launchd<\/string>\)/\1\
                <string>-AlwaysAppendSearchDomains<\/string>/
}' /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

(There should be two tab characters at the start of the second-to-last line above, but I couldn't figure out how to get this little editor to insert tabs, so I added 16 spaces. Either should work, but the tabs fit the spacing of the original file better.)

This will add the "-AlwaysAppendSearchDomains" argument to the mDNSResponder startup plist file (and save a backup copy), but since this is controlled by launchd, that system needs to be told to restart mDNSResponder.

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

Now, if you check your running mDNSResponder process, you should see it running with your new argument:

ps auxww | grep mDNSResponder

(Props to http://www.makingitscale.com/2011/fix-for-broken-search-domain-resolution-in-osx-lion.html and http://kavassalis.com/2011/07/wtf-bug-in-os-x-10-7/, where I found my answers to this problem.)

MacOS – DNS not resolving on Mac OS X

It turns out the solution was to bounce mDNSResponder:

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

This was obtained by a different coworker from this Server Fault question.

OS X 10.10.0 – 10.10.3, Yosemite

Apparently, mDNSResponder doesn't exist in Yosemite (OS X 10.10). You can restart descoveryd instead to fix these issues.

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

OS X 10.10.4+, Yosemite

In OSX 10.10.4 the mDNSResponder has been reintroduced. So use the first one will work again.