- How to Clear DNS Cache on Mac. Resetting DNS cache is not the same in each version of Mac OS X. If you are a Mac user for a longer period, you may know that this process in OS X Yosemite is similar to some other older versions.
- This network discovery and scanning tool is available for Windows, Mac OS X and Linux computers, as well as Android and iOSmobile devices. The computer versions don't currently have a GUI and must be used via an interactive command-line interface, but the mobile versions do have a GUI and are great for scanning Wi-Fi networks.
To find the fastest DNS servers for your Mac, iPad, or AirPort Extreme, try using Namebench. It's an open source DNS benchmark utility that can quickly and accurately find the fastest DNS servers for your location. This can be used to get mac address for remote computers also. Below are few examples on how to use this command. It works on XP, Vista, Windows 7, Server 2003 and Server 2008 operating systems.
To fix cache poisoning or other Internet connectivity issues, you may have to clear DNS cache on your Mac. Follow this hands-on guide to easily flush out the DNS cache from macOS and do share your valuable feedback down below in the comments!
If you are a network administrator, web developer or a system administrator of Mac, you may have to flush DNS cache on macOS for quite a few reasons. Especially, if you want a name server to resolve rightly or a change in DNS address to be detected by your individual system.
Besides the above reasons, if you have altered the
/etc/ hosts
file and you need the modifications to take effect minus rebooting the Mac, then you may find it necessary to dump and reset DNS caches.How to Clear DNS Cache on Mac
- Resetting DNS cache is not the same in each version of Mac OS X. If you are a Mac user for a longer period, you may know that this process in OS X Yosemite is similar to some other older versions. This is probably due to the discoveryd replacing mDNSResponder, and then switching back to mDNSResponder yet again.
- Despite the change, flushing DNS cache remains a terminal command in Yosemite, but there is a little different depending on the exact version of the OS you are using.
- You get to clear either Unicast DNS or Multicast DNS, or both. If you are attempting to reset all DNS caches on the Mac, then you may have to consider clearing both as a proper measure.
Flush DNS Cache in macOS Sierra or macOS High Sierra
Clear DNS cache in macOS Sierra and macOS High Sierra, you have to use a new command. Head over to this quick guide to finding out how it’s done.
Mac Dns Settings
Clear DNS Cache in Mac OS X Yosemite or El Capitan
From OS X 10.10.4 onwards, with the inclusion of 10.11, Apple has discarded discoveryd and has substituted it with mDNSResponder. As a result, to flush DNS caches in OS X Yosemite and Mac OS X El Capitan, and most likely future releases, following is the command string:
sudo dscacheutil -flushcache;sudo killall -HUP mDNSResponder; say cache flushed
Using the above command clears all DNS caches for OS X 10.10.4 and onwards.
Being a Mac user for a long time, you may remember that this command string essentially is what worked in the release preceding Yosemite. However, the releases of OS X Yosemite previous to 10.10.4 will employ different command string as mentioned below.
To reset cache you need to use the Terminal. Find the Terminal app in /Applications/Utilities/ or open it with Spotlight. Target both UDNS (Unicast DNS) and MDNS (Multicast DNS) with two different commands to fully flush all DNS caches in the most recent version of OS X.
Clear MDNS Cache
- OS X Yosemite and later:
sudo killall -HUP mDNSResponder
- OS X v10.10 through v10.10.3:
sudo discoveryutil mdnsflushcache
Press return key and enter the admin password when asked.
Clear UDNS Cache
sudo discoveryutil udnsflushcaches
Another time, press the return key and enter the admin password when asked. In the second command, the caches is plural, a small but crucial syntax variation.
How to Flush and Reset All DNS Caches in OS X Yosemite
If desirable it is also possible to string the two commands together. The following command will announce out loud when you clear the caches:
sudo discoveryutil mdnsflushcache;sudo discoveryutil udnsflushcaches;say flushed
Without a doubt MDNS and UDNS caches are different, but you can figure that both commands are required for functional DNS cache to really clear in OS X Yosemite. For your own requirements, if you only need to clear one or the other, it is fully possible.
It is noteworthy that OS X Yosemite has moved on from mDNSResponder. Thus, you need not kill the mDNSResponder process to refresh DNS caches as in earlier versions of Mac OS X.
In case you are using an earlier version of OS X like Mavericks, Mountain Lion, or Lion, then the commands to flush DNS will be different. Below we have mentioned Terminal commands for the earlier versions of Mac OS X, have a look.
How to flush DNS cache in OS X Mavericks, Mountain Lion, and Lion
The command below will facilitate you to reset the DNS cache in OS X v10.9.5 and earlier:
sudo killall -HUP mDNSResponder
If you are using Mac OS X Snow Leopard, then the Terminal commands for the same are below, check it out.
How to flush DNS cache in Mac OS X Snow Leopard
Just copy paste the command given below to reset the DNS cache in OS X v10.6 through v10.6.8:
sudo dscacheutil -flushcache
How to Check DNS Cache Details in OS X El Capitan or Yosemite
While you are changing DNS, if you want to know about what is cached at the time, you can use the commands as follows:
Get UDNS Cache Statistics
sudo discoveryutil udnscachestats
Additionally, you can recover details about multicast DNS cache with the following command:
sudo discoveryutil mdnscachestats
Both the above-mentioned commands offer information such as the number of DNS entries cached, providing an account of details in the following way:
UDNS Cache Stats: Cached 1250 of 1900
If you run the commands before and after executing the flushcache variations, you will discover that they must be reset to 0 entries cache, just like given below:
MDNS Cache Stats: lo0: Cached 6 of 7500
How Do You Know If Change Has Occurred
Once you clear the cache, if you wish to know whether the IP or name server has really changed, make use of the ‘dig’ command with the URL as given below:
dig igeeksblog.com
dig and nslookup are quite similar, but with the exception that dig gives better result by including additional information. It provides details like the set DNS server used to access the domain, a timestamp and the included query time; all these details are useful when troubleshooting name server problems. If the query time in the result is sluggish, you must use a tool named namebench to get a faster DNS server, commonly OpenDNS or Google DNS.
That’s pretty much it!
Wrapping up
Hopefully, getting rid of DNS cache will no longer be a big deal for you. Have any question? Toss it up in the comments below.
You might want to take a peek at these posts as well:
Found this guide helpful? Download our app and stay connected with us via Facebook, Twitter, and Telegram to read more such articles.
Previous articleBest Health Accessories for iPhone and iPad in 2019: Monitor Your Health On the Go
Next articleRecycle Your Old Tech With Apple’s Recycling Program to Contribute Your Bit In Saving The Planet
Please enable JavaScript to view the comments powered by Disqus.
Active2 months ago
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?
• 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 forother 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?
• creating a blank user
A guest user account was created, the DNS issue was still there when usingthe guest account.
• nslookup and dig both work fine Best search tool for mac os x.
• also flushing the DNS cache was done but it didn't help
EDIT 2:
Community♦
CajunLukeCajunLuke15.7k6 gold badges47 silver badges70 bronze badges
22 Answers
It turns out the solution was to bounce mDNSResponder:
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.
OS X 10.10.4+, Yosemite
In OSX 10.10.4 the mDNSResponder has been reintroduced. So use the first one will work again.
Community♦
CajunLukeCajunLuke15.7k6 gold badges47 silver badges70 bronze badges
Actually, I think you might want to use
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.
chiggsychiggsy2,1981 gold badge20 silver badges33 bronze badges
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 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:
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.
Martin MarconciniMartin Marconcini20.7k1 gold badge49 silver badges81 bronze badges
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
orbrew install dnsmasq
) - Put this in a
dnsmasq.conf
file: - Put this in a
resolv.conf
file that is in the same directory as thednsmasq.conf
file (nb: not/etc/resolv.conf
): - Run
dnsmasq
withsudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf
. The output should look something like: - 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
techrafdnsmasq
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.2,8407 gold badges16 silver badges32 bronze badges
David WoleverDavid Wolever9381 gold badge10 silver badges19 bronze badges
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/com.apple.mDNSResponder.plist
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
techrafssh -D
and tried DNS lookups through the tunnel.2,8407 gold badges16 silver badges32 bronze badges
freezedpeanutsfreezedpeanuts
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:
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!
CajunLuke15.7k6 gold badges47 silver badges70 bronze badges
Simon C SmithSimon C Smith
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.Strangely rebooting didn't cause it to be restarted.
I manually restarted the service with:
and now all is well.
Brian de AlwisBrian de Alwis
Mac tool box for sale tuscon az. 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/com.apple.mDNSResponder.plist
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:
- Copied
/System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
from the system image. sudo chown root /System/Library/LaunchDaemons/com.apple.mDNS*
- 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/com.apple.mDNSResponder.plist
DKrootDKroot
Please note to anyone still having issues, you might have to remove any public DNS servers until cache is cleared.
Dustin MatlockDustin Matlock
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:
listed 192.168.0.1 as DNS. Using scutil --dns I've got comparable results, listing that resolver #2 used nameserver[0] : 192.168.0.1.
Using the command
I was able to reconfigure the DNS for the given network and resolve names of local and global machines when connected to the VPN.
rexfordrexford
In my case, everything else was fine: mDNSResponder was running and working,
host
/nslookup
worked, both /etc/resolv.conf
and networksetup
reported the correct DNS servers, etc. Despite all that, DNS resolution in general (e.g. with ping
) inevitably stopped working at some point a few hours after boot.This specific problem may be somewhat unlikely, but I'm going to document it here as an answer anyway.
I only noticed when the machine started slowing down, but there were a lot of identical processes running.
sensu-client
, specifically.We had it configured in launchd with this plist file:
The
-b
flag to sensu-client
makes it fork to the background, acting as a daemon. However, all launchd
sees is that the original process terminated, so (in accordance with the KeepAlive
flag) it restarts it. This leaves thousands of forked processes in the background, and even then launchd will be none the wiser to the fact that it is running.I believe that these several thousand processes (all
sensu-client
, the software we had written a launchd config for) may have been simultaneously making requests to mDNSResponder, effectively resulting in a local denial of service of the DNS cache. Killing these processes and fixing the plist given to launchd eventually solved the problem.The plist fix was just to remove the
-b
(background / daemonise) flag from the sensu-client invocation. Note that this is not sensu's fault; this plist was written by a former system administrator at this company.Score_UnderScore_Under
Here are few advanced commands which can help to troubleshoot the DNS problem:
- Run
dig
to list the root name servers. - Run
dig example.com
to run DNS lookup forexample.com
domain. - List your hardware ports by:
networksetup -listallhardwareports
. - Check output of the DHCP/BOOTP packet that the client accepted from the DHCP/BOOTP server by:
ipconfig getpacket en0
. - Check your DNS configuration by:
scutil --dns
. - Verify that
mDNSResponder
process is running by:ps wuax | grep mDNSResponder
. - Flush ARP translation entries by:
arp -ad
(runman arp
for help).source
To debug
mDNSResponder
process, the following command may help:The above command will send
kenorbkenorbSIGINFO
signal to the process which will dump debugging details into log output which can be read and analysed.7,6629 gold badges54 silver badges103 bronze badges
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.
bmike♦168k46 gold badges304 silver badges662 bronze badges
Lukasz MadonLukasz Madon
This probably won't help anybody, but in case, I accidentally some time ago, created a file in the folder, when a DNS was down for a particular domain:
/etc/resolver/
and this was preventing a specific name from ever being resolved, two years later.
JérémieJérémie
Unfortunately none of this helped me, and turned out after an hour of trying to figure it out and beating my head against the coffee table . something, somehow, somewhere .. removed the
/System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
file, and was the reason I had this problem.Realized this when I saw this error message:
/System/Library/LaunchDaemons/com.apple.mDNSResponder.plist: No such file or directory
Here's a copy of a version from El Capitan:https://gist.github.com/tripflex/e7147690d1768dc74b1dd626614573c0
Here's the code from that gist:
sMylessMyles
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.
YeisonYeison
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:Mac Check Dns
and
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!
cwj73cwj73
Used mac tool chest for sale. When following commands from accepted answer:
you may run into warning:
Operation not permitted while System Integrity Protection is engaged
Change Dns In Mac
You need to turn it off. Whole instruction here:https://www.howtogeek.com/230424/how-to-disable-system-integrity-protection-on-a-mac-and-why-you-shouldnt/
andilabsandilabs4743 gold badges7 silver badges19 bronze badges
In my case I had OpenDNS installed in the past and it wasn't removed cleanly. There were several dns related processes running such as DNSdnscrypt-proxy. I couldn't force quit them in Activity Monitor but I was able to stop them from starting up on restart by removing the .plist file in Library/LaunchDaemons.
HaoHao
Go to Settings -> Network -> Advanced -> DNS. Then make literally any changes at all to DNS (reorder your DNS entries, for example). Then click 'Ok' followed by 'Apply' on the next screen. Don't be fooled into thinking that the particular change you made was significant; it's the magic of the 'Apply' button.
weberc2weberc2
What worked for me was removing all the server entries from DNS Servers and Search Domains from:
Dns Server Mac
System Preferences → Network → Advanced.. → DNS
Nimesh Neema24.5k9 gold badges63 silver badges95 bronze badges
MarceloMarcelo
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.
xt1xt1