DNS not resolving on Mac OS X

Some of my co-workers are having troubles on their Macs - DNS resolution does not work in Mac OS X. They're running Snow Leopard 10.6.8. They can use DNS in a Windows 7 virtual machine (VMware Fusion 3.1.3) running on OS X. The computers are 15" MacBook Pros, early 2011 model.

Things they've tried that didn't work:

• turning airport on/off
• rebooting
• using wired connection instead of wifi
• deleting connection credentials and adding it again
• turning off Mac firewall
• using static IP
• manually setting DNS servers
• restarting mDNSResponder
• the fixes from this other question

EDIT response to Martín's answer:

• Can you ping the DNS you want to use?

$ ping apple.com
ping: cannot resolve apple.com: Unknown host

• What is/are the IP address(es) of the DNS(s) you want to use?

This is a company DNS server that is given with DHCP, it works well for other people. I've also tried Google's 8.8.4.4 and 205.171.3.65 (which I found from GRC's DNS Benchmark to be the fastest).

• Have you tried using 8.8.8.8 (google) or any of the OpenDNS 208.67.222.222 or 208.67.220.220?

It doesn't work, see Google Chrome output:

The server at www.apple.com can't be found, because the DNS lookup failed. DNS is the network service that translates a website's name to its Internet address. This error is most often caused by having no connection to the Internet or a misconfigured network. It can also be caused by an unresponsive DNS server or a firewall preventing Google Chrome from accessing the network.

• Can you ping those hosts?

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from
8.8.8.8: icmp_seq=0 ttl=58 time=3.925 ms

• creating a blank user

A guest user account was created, the DNS issue was still there when using the guest account.

• nslookup and dig both work fine

$ nslookup www.apple.com 8.8.8.8
Server:  8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
www.apple.com canonical name = www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net canonical name = www.apple.com.edgekey.net.
www.apple.com.edgekey.net canonical name = e3191.c.akamaiedge.net.
Name: e3191.c.akamaiedge.net
Address: 184.24.141.15

$ dig @8.8.8.8 www.apple.com
; <<>> DiG 9.6.0-APPLE-P2 <<>> @8.8.8.8 www.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11298
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;www.apple.com.   IN A
;; ANSWER SECTION:
www.apple.com.  1041 IN CNAME www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 38 IN CNAME www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 8794 IN CNAME e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 17 IN A 184.24.141.15
;; Query time: 4 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Oct 4 09:25:28 2011
;; MSG SIZE  rcvd: 158

• also flushing the DNS cache was done but it didn't help

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

EDIT 2:

$ cat /etc/resolv.conf
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
domain {redacted}.com
nameserver 8.8.8.8
nameserver 208.67.222.222

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.

Actually, I think you might want to use

scutil --dns

scutil -r hostname

These commands use the dynamic store in configd, as opposed to the flatfiles in /etc, which often are only read in single user mode and for non networked systems.

man scutil   # or

scutil --help  

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.

Name resolution under OSX (and UNIX in general) is taken from the IP addresses of the DNSs in the file located in /etc/resolv.conf (which OS X automatically generates as far as I can remember).

Since you've tried virtually anything that comes to my mind, I'd like to ask you:

• Can you ping the DNS you want to use?
• What is/are the IP address(es) of the DNS(s) you want to use?
• Have you tried using 8.8.8.8 (google) or any of the OpenDNS 208.67.222.222 or 208.67.220.220?
• Can you ping those hosts?

Finally, a usually nice test consists of creating a blank user and seeing if that new user exhibits the same problem. If it doesn't, then you can start digging what your current user has that could be causing the issue; if it also fails, then you know this is something more "system" related.

Also take a look around the Console to see if you can spot something that may be related (and would like to paste around here).

Last but not least, your Mac comes with two important DNS commands, nslookup and dig.

So to resolve www.apple.com using google's server, you'd type:

nslookup "host to resolve" "DNS server to use". E.g.:

$ nslookup www.apple.com 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
www.apple.com   canonical name = www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net    canonical name = www.apple.com.edgekey.net.
www.apple.com.edgekey.net   canonical name = e3191.c.akamaiedge.net.
Name:   e3191.c.akamaiedge.net
Address: 184.24.141.15

NSLookup is an old command (that was supposed to be deprecated some years ago and replaced by DIG, but its easy to use syntax was too good to kill I guess.), its "replacement" is dig, a much more powerful command, whose syntax is more crazy.

To perform the same query, you'd type:

dig @8.8.8.8 www.apple.com

ANd here's the output:

$ dig @8.8.8.8 www.apple.com

; <<>> DiG 9.7.3 <<>> @8.8.8.8 www.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17356
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.apple.com.         IN  A

;; ANSWER SECTION:
www.apple.com.      1782    IN  CNAME   www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 42 IN CNAME   www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 21581 IN CNAME   e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 2   IN  A   184.24.141.15

;; Query time: 26 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Oct  3 21:21:49 2011
;; MSG SIZE  rcvd: 158

As you can see, dig is much more "verbose" (which is good to debug what the heck is going on). The power of dig comes from the fact that you can specify what type of query you want to perform (Among other things).

In any case, let us know the exact outputs of these commands.