127

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
5
  • Happens for me on lion as well.
    – dkagedal
    Apr 28, 2012 at 21:11
  • Happening for me on Mavericks, 10.9.4
    – greg7gkb
    Jul 2, 2014 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.
    – dan
    Jul 29, 2015 at 18:07
  • Try to change your DNS configuration (change order or remove entries), that resolve the same issue for me
    – mems
    Oct 22, 2017 at 10:01
  • I am using my own DNS server on my home network and my Mac is always forgetting the names of one local machine or another. Thank you because the following fixes it when it goes wrong: sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder
    – Will
    Jan 25 at 14:50

27 Answers 27

100

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.

23
  • 7
    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, 2012 at 23:57
  • 2
    @dkagedal This is actually as good an answer as we're going to get - this happens because your mac caches the DNS entries to avoid hitting your DNS server (likely your router) for every DNS lookup - which happens a lot. This cache is necessary, and good, but it would be nice if there were better behavior when an entry is not found (I consider this a bug). In any case, there is some timeout in the cache; when I waited 10 minutes or so on my machine, this situation resolved itself. For the majority of users, the existing behavior is fine, so is not likely to be changed by Apple anytime soon.
    – Matt
    Nov 12, 2012 at 17:00
  • 4
    Of course this is not as good as it gets. No other OS has this problem. There is nothing wrong with the DNS, the record for www.google.com didn't go missing, it's just the MacOS cache that for somehow lost it and won't refetch it. And that's a bug that needs fixing.
    – dkagedal
    Dec 18, 2012 at 22:04
  • 1
    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, 2013 at 10:07
  • 1
    @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, 2015 at 18:08
15

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  
4
  • 6
    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, 2012 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. Jun 7, 2015 at 8:50
  • 3
    these commands don't solve the issue Oct 31, 2016 at 14:44
  • 1
    Thanks! This solution solved my problem. Specifically, dig hostname and host hostname was resolving the address but ping hostname was not resolving. After running the two commands above ping hostname started resolving.
    – Jono
    Aug 14, 2020 at 19:49
13

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.

5
  • 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. Apr 16, 2016 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 127.0.0.1 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. Apr 16, 2016 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 8.8.8.8 (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. Apr 16, 2016 at 6:39
  • It says that address 127.0.0.1 is already in use, when I try to start dnsmasq. What do I have to do? High Sierra
    – IceFire
    Oct 24, 2017 at 12:02
  • @IceFire I know this is old but that means that there's already a service bound on that port (53). Technically that means it's getting the error EADDRINUSE but I won't go there :) As for this answer I find it intriguing. I have a similar problem but I think (hope) for me that the other answer will resolve it only that I don't need to enable it at least for my home network as I have my own authoritative DNS servers (and one happens to be local and what I use). Otoh as a long time Unix user the fact I could use /etc/resolv.conf is appealing but will try the other first.
    – Pryftan
    Mar 15, 2019 at 12:56
8

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.

9
  • See my edit to the question.
    – Cajunluke
    Oct 4, 2011 at 19:33
  • @CajunLuke hmmmm interesting… I mind adding the output of: cat /etc/resolv.conf to your question? Oct 4, 2011 at 22:10
  • Edited. (Padding to make comment fit.)
    – Cajunluke
    Oct 4, 2011 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? Oct 4, 2011 at 23:22
  • 1
    Or if you want really short you can always do ... dig +short a apple.com ...
    – Pryftan
    Mar 15, 2019 at 13:02
6

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 ssh -D and tried DNS lookups through the tunnel.

2
  • 2
    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 com.apple.mDNSResponder.plist, rebooted, and the problem was solved. I wish I could upvote you a billion times. Apr 3, 2012 at 16:11
  • 1
    Do note delete com.apple.mDNSResponder.plist! 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/com.apple.mDNSResponder.plist than helped. Mar 15, 2014 at 18:09
5

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/com.apple.alf.plist /Library/Preferences/com.apple.alf.plist

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!

4

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/com.apple.networking.discoveryd

and now all is well.

2
  • 1
    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, 2015 at 14:56
  • Annoying this happens all the time for me. Have to restart the service. May 6, 2015 at 17:26
2

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:

  1. Copied /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist from the system image.
  2. sudo chown root /System/Library/LaunchDaemons/com.apple.mDNS*
  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/com.apple.mDNSResponder.plist

2

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

2
  • 1
    Maybe we should mention support.apple.com/en-au/HT203244. Jun 7, 2015 at 9:01
  • @DAVincent A few years late, but that link is disappointing. It's clearly an Apple bug but they're attributing it to user error.
    – weberc2
    Jun 11, 2019 at 4:17
2

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

networksetup -setdnsservers <networkname> 192.168.188.1 8.8.8.8

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

2

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.

3
  • 1
    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? Jun 7, 2015 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, 2015 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, 2015 at 13:48
2

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.

2
  • Thank you very much, this was my issue. I've been debugging for hours, and when I looked in /etc/resolver I of course found a file called "test", with the erronous IPs...
    – keyser
    Jan 24, 2019 at 14:25
  • Exactly my issue. I only realised this once I ran scutil --dns and noticed that resolver #8 added custom nameservers for my problematic domain. I first tried to remove them via the scutil command line interface but no luck. And then I somehow stumbled upon /etc/resolver... hallelujah!This answer was very useful to explain the idea of DNS on macOS.
    – llude
    Oct 23, 2019 at 20:56
2

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:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd>
<plist version="1.0">
  <dict>
  <key>KeepAlive</key>
  <true/>
  <key>RunAtLoad</key>
  <true/>
  <key>WorkingDirectory</key>
  <string>/etc/sensu</string>
  <key>UserName</key>
  <string>root</string>
  <key>Label</key><string>org.sensuapp.sensu-client</string>
    <key>ProgramArguments</key>
    <array>
      <string>/usr/bin/sensu-client</string>
      <string>-d/etc/sensu/conf.d/</string>
      <string>-b</string>
    </array>
  </dict>
</plist>

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.

2

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 for example.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 (run man arp for help).source

To debug mDNSResponder process, the following command may help:

(sleep 1 && sudo killall -INFO mDNSResponder &); log stream | grep mDNSResponder

The above command will send SIGINFO signal to the process which will dump debugging details into log output which can be read and analysed.

1

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:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.apple.mDNSResponder.reloaded</string>
    <key>OnDemand</key>
    <false/>
    <key>InitGroups</key>
    <false/>
    <key>UserName</key>
    <string>_mdnsresponder</string>
    <key>GroupName</key>
    <string>_mdnsresponder</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/sbin/mDNSResponder</string>
    </array>
    <key>MachServices</key>
    <dict>
        <key>com.apple.mDNSResponder</key>
        <true/>
            <key>com.apple.mDNSResponder.dnsproxy</key>
            <true/>
    </dict>
    <key>Sockets</key>
    <dict>
        <key>Listeners</key>
        <dict>
            <key>SockFamily</key>
            <string>Unix</string>
            <key>SockPathName</key>
            <string>/var/run/mDNSResponder</string>
            <key>SockPathMode</key>
            <integer>438</integer>
        </dict>
    </dict>
    <key>POSIXSpawnType</key>
    <string>Interactive</string>
    <key>EnablePressuredExit</key>
    <false/>
</dict>
</plist>
1

Restarting DNSResponder / clearing DNS cache in macOS Mojave:

sudo killall -HUP mDNSResponder

No problems with System Integrity Protection, unlike with reloading the config files.

1

In my case, the root cause was that the DoS protection system of my home WiFi router erroneously added the MAC address of my macOS device to the blacklist. After manually clearing the blacklist and running sudo killall -HUP mDNSResponder, dig, ping and traceroute commands are all working well.

1

On Mac OS Mojave 10.14.6, I recently started seeing frequent dns lookup failures. I have this function in my .bashrc:

function resetdns() {
     dscacheutil -flushcache;
     sudo killall -HUP mDNSResponder
     sudo killall -9 mDNSResponder mDNSResponderHelper
     sudo launchctl stop homebrew.mxcl.dnsmasq 
     sudo launchctl start homebrew.mxcl.dnsmasq
}

On running

$ resetdns

dns lookups started working fine again.

0

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.

0

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/com.apple.mDNSResponder.plist

and

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

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!

0

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.

0

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.

~ $  time nslookup www.google.com
;; connection timed out; no servers could be reached


real    0m21.041s
user    0m0.006s
sys     0m0.010s

 ~ $  time nslookup www.google.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   www.google.com
Address: 172.217.5.4


real    0m0.079s
user    0m0.006s
sys     0m0.010s
0

What worked for me was removing all the server entries from DNS Servers and Search Domains from:

System Preferences → Network → Advanced... → DNS

0

Uninstalling the Umbrella Roaming Client made DNS lookups work fine for me on Mac OS Mojave.

Run the application in

Applications > OpenDNS Roaming Client  > Umbrella Roaming Client Uninstaller.
0

Running on MacOS Mojave 10.14.6. Mostly the same issues, as OP & others. Everything working fine then all of a sudden no access to Internet or Local addresses. I can access by IP Address but not by DNS. Neither Wifi or Wired connection. Clearly a DNS issue. I can see correct DNS entries in Network Preferences...Advanced...DNS. Up to now only resolution was a reboot. Would then work fine for a few days, then it would happen again.

What worked for me was provided above by @user674669

function resetdns() {
 dscacheutil -flushcache;
 sudo killall -HUP mDNSResponder
 sudo killall -9 mDNSResponder mDNSResponderHelper
 sudo launchctl stop homebrew.mxcl.dnsmasq 
 sudo launchctl start homebrew.mxcl.dnsmasq

}

On running

$ resetdns

I ran each line in the function individually. Will now see if I can script it, as I am pretty sure I will need it again.

So Ok, I have a resolution, but the main question is why is this happening? Previously, I had tried "sudo killall -HUP mDNSResponder" to no avail, but I had not run the other commands. I may try just the first three and see if that resolves it. If it requires the two commands that reference homebrew, could homebrew be the problem?

I am sure I will have another opportunity to check this further.

Again many thanks to @user674669!

Update 08-26-2021:

Issue re-occurred. Ran the first three commands only:

 dscacheutil -flushcache;
 sudo killall -HUP mDNSResponder
 sudo killall -9 mDNSResponder mDNSResponderHelper

...tested connection after each one. Seemed to require all three, doesn't completely resolve the issue, only restores DNS functionality until it re-occurs.
The real issue still remains...why is this happening.

And sorry, I may be a newbie here, but I am also an analyst and have been for years. I believe my answers as posted are relevant to this topic. No one here has come up with a definite conclusive resolution to this issue. And I reference a different (but also same) answer in respect to the person (@user674669) who did provide the steps I was able to use to help partially (as the issue returns at a later time) resolve the issue. And with this update, I have determined that not all the steps posted by @user674669 are required (at least in my case) to restore the DNS functionality. I believe my comments are helpful to others having this same issue.

LThibx

3
  • 1
    Welcome to Ask Different. Thanks for your answer but it's a bit confusing to read because you reference a different answer. Please edit your answer to only include the relevant steps to resolve the problem. - From Review
    – fsb
    Aug 25, 2021 at 21:24
  • 1
    Firstly, welcome to Ask Different! :) Thank you for your post, I'm sure this will be helpful to others. However, you may want to edit it to remove the bits that don't belong in an answer. More specifically, everything from "So, ok, I have a resolution..." onwards could be removed, as it reads more like a question. Also, feel free to edit your answer if/when you feel you can improve/clarify it. Thanks again for your contribution! :)
    – Monomeeth
    Aug 25, 2021 at 22:06
  • This answer seems to be a mix of a (self confessed) re-iteration of user674669'a answer and a new question. There doesn't seem to be any new solution provided. Aug 26, 2021 at 0:30
0

2022 and having this issue.

nslookup & dig returned the correct dns values but ping and ssh to the intended device just returned the public ip of my domain.

in my case I had to turn off my DNS profile and "the limit IP address tracking" in the network settings pref pane.

now everything works correctly & search domains work correctly.

-1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .