Ask Different is a question and answer site for power users of Apple hardware and software. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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
ping: cannot resolve 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 and (which I found from GRC's DNS Benchmark to be the fastest).

Have you tried using (google) or any of the OpenDNS or

It doesn't work, see Google Chrome output:

The server at 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
PING ( 56 data bytes 64 bytes from 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

Non-authoritative answer: canonical name = canonical name = canonical name =


$ dig @
; <<>> DiG 9.6.0-APPLE-P2 <<>> @
; (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

;; Query time: 4 msec
;; 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


$ 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
share|improve this question
Happens for me on lion as well. – dkagedal Apr 28 '12 at 21:11
Happening for me on Mavericks, 10.9.4 – greg7gkb Jul 2 '14 at 20:15
This look like an historical problem which rotted the life of users and network admins from Leopard to Yosemite. If someone still see this problem, please report clearly if you have more than one interface active and moreover getting its conf. from a DHCP server (from different sides). Why? I never saw such a problem on any other Unix and on none of my Macs (I have a lot), but none of them has more than one interface talking toward a DNS info source. – daniel Azuelos Jul 29 '15 at 18:07

14 Answers 14

up vote 68 down vote accepted

It turns out the solution was to bounce mDNSResponder:

sudo launchctl unload -w /System/Library/LaunchDaemons/
sudo launchctl load -w /System/Library/LaunchDaemons/

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/
sudo launchctl load -w /System/Library/LaunchDaemons/

OS X 10.10.4+, Yosemite

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

share|improve this answer
Worked for me as well. Thanks! – dkagedal Apr 28 '12 at 21:09
But this isn't really a satisfactory answer. I need to know how to stop it from happening in the first place. – dkagedal Aug 25 '12 at 23:57
Got this problem on 10.9 and solution worked perfectly. In my case DNS was resolving for full names but not short ones. – sorin Oct 29 '13 at 10:07
@Matteo Maybe the file doesn't have to exist, or maybe the answer needs to be updated for Yosemite. Do you have this issue? Does running those commands fix it? – CajunLuke Jan 13 '15 at 18:08
@DavidVincent Are you using the discoveryd command? What version of Yosemite are you on? Can you post the full command and response you're using? – CajunLuke Jun 10 '15 at 18:10

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 (google) or any of the OpenDNS or
  • 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 using google's server, you'd type:

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

$ nslookup

Non-authoritative answer:   canonical name =    canonical name =   canonical name =

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 @

ANd here's the output:

$ dig @

; <<>> DiG 9.7.3 <<>> @
; (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

;         IN  A

;; ANSWER SECTION:      1782    IN  CNAME 42 IN CNAME 21581 IN CNAME 2   IN  A

;; Query time: 26 msec
;; 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.

share|improve this answer
See my edit to the question. – CajunLuke Oct 4 '11 at 19:33
@CajunLuke hmmmm interesting… I mind adding the output of: cat /etc/resolv.conf to your question? – Martín Marconcini Oct 4 '11 at 22:10
Edited. (Padding to make comment fit.) – CajunLuke Oct 4 '11 at 22:59
@CajunLuke i'm puzzled. Let's go back to the roots… this only happens on this machine, and only under OSX, the VMs are ok. I'm starting to suspect that Parallels or VMware may be causing some trouble. What type of network are these VMs using? Bridged? Shared? – Martín Marconcini Oct 4 '11 at 23:22
It's VMware Fusion, and we're using the NAT option. There are probably twenty identical (imaged) machines, out of which two have this issue. OS X has the problem, VMs do not. – CajunLuke Oct 4 '11 at 23:44

I had the same exact same symptoms (and spend a while troubleshooting) but I was able to resolve it when I realized that I messed with /System/Library/LaunchDaemons/ and what I did was somehow interpreted as malformed. I restored from a backup and the machine was able resolve hostnames again.

Before coming to the solution, I also realized that I was able to browse the internet if I used a socks5 proxy through "ssh -D" and tried DNS lookups through the tunnel.

share|improve this answer
My company has been having this issue for months and months, each time taking Macs to the "Genius bar" whose only solution was to wipe the hard drives and start over. I saw your post, and deleted, rebooted, and the problem was solved. I wish I could upvote you a billion times. – Tom Thorogood Apr 3 '12 at 16:11
Do note delete! I did it as @TomThorogood suggested. I have hard time to get back. Even I put the file back and restart I was unable to get any response from Internet. The sudo launchctl load -w /System/Library/LaunchDaemons/ than helped. – Pavel Binar Mar 15 '14 at 18:09

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  
share|improve this answer
You don't explain why these commands would help with this problem. Do they even? Or this this meant as a comment to one of the other answers or something? – dkagedal Sep 21 '12 at 19:58
One possible advantage of scutil is that it might work regardless of whether the computer has discoveryd or mDNSResponder. It dates from before their introduction. – D A Vincent Jun 7 '15 at 8:50

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:

  • Put this in a resolv.conf file that is in the same directory as the dnsmasq.conf file (nb: not /etc/resolv.conf):

  • 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
    dnsmasq: using nameserver
    dnsmasq: using nameserver
    dnsmasq: read /etc/hosts - 6 addresses
  • Open Network Preferences and make sure that is the only DNS server (network preferences -> advanced -> DNS -> add

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
I'd just like to point out that after 16 straight hours scouring the Internet, this is the only solution I've found that both lets me resolve internal company names AND allows for split networking to function properly. Thank you SO much for making this comment. – Ron Thompson Apr 16 at 6:28
I'd also point out that on OS X El Capitan, in order to script setting this up, I wrapped my openconnect command in a python script, along with commands such as networksetup -setdnsservers and networksetup -setsearchdomains "$COMPANY_NAME".com. Add in your dnsmasq command and it's all set! I finally have a stable VPN solution thanks to this comment. – Ron Thompson Apr 16 at 6:32
For future readers, I found it easiest to just ssh into my box at work, determine which IP's it had for name servers, and then hardcode those IP's into my resolv.conf below (googles DNS server). That allows all non company names to resolve properly without having to go through company servers, which I find useful for privacy and speed. As far as hardcoding goes, those IP's aren't going to change any time soon, and if they do, I won't be the only one affected and it should be trivial to edit two lines. – Ron Thompson Apr 16 at 6:39

I had a very, very similar issue, except the symptoms were slightly different.

My user could not resolve any name (local NAS, Google etc) but a guest user on the same iMac (OS X 10.7.4) worked fine.

Flushing and restarting mDNSResponder as mentioned worked for a while. Whilst it would remain working when the iMac was put in sleep mode, it would always fail once rebooted.

When the flush/restart stopped working I looked for other reasons/solutions and I found that it was related to my firewall. I don't know what in my (OS X) firewall settings was causing it, but if I restored the firewall setting it worked.

To restore the default settings I used:

sudo cp /usr/libexec/ApplicationFirewall/ /Library/Preferences/

Obviously any custom rules will have been removed with this restore.

I wanted to share my version of this issue as it's been causing me grief on and off for months and this post is the best collection of possible solutions on the net!

share|improve this answer

I hit this problem on Yosemite (10.10). Turns out that a key daemon, discoveryd, was killed off as it was consuming too much CPU.

2014/10/22 3:50:07.000 PM kernel[0]: process discoveryd[49] thread 1251 caught burning CPU! It used more than 50% CPU (Actual recent usage: 68%) over 180 seconds. thread lifetime cpu usage 90.016372 seconds, (74.516637 user, 15.499735 system) ledger info: balance: 90007570271 credit: 90007570271 debit: 0 limit: 90000000000 (50%) period: 180000000000 time since last refill (ns): 131905306167 

Strangely rebooting didn't cause it to be restarted.

I manually restarted the service with:

sudo launchctl kickstart -k system/

and now all is well.

share|improve this answer
This was the solution for me on Yosemite as well. Some details: host, dig, and Chrome worked fine, but ping, telnet, ssh, firefox, and safari could not resolve hostnames. This solution fixed my issue. – Ryan Hoegg Apr 28 '15 at 14:56
Annoying this happens all the time for me. Have to restart the service. – Callum Rogers May 6 '15 at 17:26

I am having the same problem with 10.6.8. The first trip to an Apple Store resulted in system restore. But, after that, DNS broke again while I was overseas and didn't have a system DVD with me. At that time I found this thread and deleted /System/Library/LaunchDaemons/ per @freezedpeanuts and @Tom Thorogood.

It fixed the problem, but, amazingly, DNS broke for the third time couple of days later. I hunted down a system image of 10.6.3 and:

  1. Copied /System/Library/LaunchDaemons/ from the system image.
  2. sudo chown root /System/Library/LaunchDaemons/*
  3. Rebooted

That fixed the problem.

It breaks periodically for me now (once a month or so), and the restore procedure is down to the steps above, except instead of rebooting you can:

sudo launchctl load -w /System/Library/LaunchDaemons/

share|improve this answer

Turning Wi-Fi off and on again helped.

MacBook Pro with 10.9.1

Especially if you turn off wifi and then reboot. The extra delay and starting with no IP/network connection ensure the request to rejoin the network has better chances to succeed.

share|improve this answer
Although the question may need some editing, it still says (at the time of writing this comment) that the workers already tried turning Wi-Fi off and on again. Maybe we could retract this answer? – D A Vincent Jun 7 '15 at 8:59
I don't have enough reputation to add a comment to a post on turning wifi off and then on, but that worked for me. Retracting the answer would be silly. – user150725 Oct 6 '15 at 10:11
+1 for the suggestion to try again. Multiple answers help lots of people, and each router has different time outs and behaviors. – bmike Oct 6 '15 at 13:48

Please note to anyone still having issues, you might have to remove any public DNS servers until cache is cleared.

share|improve this answer
Maybe we should mention – D A Vincent Jun 7 '15 at 9:01

I had seemingly the same problem as the OP. Using the tool networksetup I found that for the given network name, some wrong DNS was configured:

networksetup -getdnsservers <networkname>

listed as DNS. Using scutil --dns I've got comparable results, listing that resolver #2 used nameserver[0] :

Using the command

networksetup -setdnsservers <networkname>

I was able to reconfigure the DNS for the given network and resolve names of local and global machines when connected to the VPN.

share|improve this answer

As it turns out, to solve the problem you have to configure a search domain and add it to the search domain field under System Preferences dns configuration. Basically, the search domain will work sort of the way that .local does, but instead it will be .

You have to set up your search domain as a master zone in your dns server for this to work.

share|improve this answer

I've a similar problem with finding the host server. We have 21 iMacs running from the Server (El Capitan, recently upgraded) and only one won't bind. The fix is usually pretty simple through Users and Groups in SysPref. Deleting the host server and re-binding, finding the available server in the dropdown option, but for some unknown reason the server is listed as unkown-00-00-12-34-56-78.home, which I've found is the MAC address of the server. I ran this in terminal:

sudo launchctl unload -w /System/Library/LaunchDaemons/


sudo launchctl load -w /System/Library/LaunchDaemons/

returned to bind to the server in SysPref and the correct server name option briefly appeared and then changed back to "unkown-00-00-12-34-56-78.home" right in front of my eyes!

share|improve this answer

After upgrading from Snow Leopard on an old Mac Book to Mountain Lion, the system could not resolve DNS. Flushing, restart, nothing helped. Changing WiFi to a different Access point (my phone) helped.

Mountain Lion adds a new client field to the DHCP network settings. Filling in this field seemed to make the wifi access point happy. Leaving it blank meant nothing was getting thru, even though the wifi connection seemed to succeed.

share|improve this answer

Your Answer


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.