DNS not resolving on Mac OS X Some of my coworkers are having troubles on their Macs - DNS resolution does not work under 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 under OS X. The computers are 15" MacBook Pros, early 2011 model.

Things they've tried that have not worked:


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


EDIT response 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


&nbsp;

$ dig @8.8.8.8 www.apple.com
; &lt;&lt;&gt;&gt; DiG 9.6.0-APPLE-P2 &lt;&lt;&gt;&gt; @8.8.8.8 www.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -&gt;&gt;HEADER&lt;&lt;- 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.