4

Background

Connected to WiFi on Macbook Air, Early 2014, running Big Sur 11.7.10, logged in as a Standard (limited) User.

Symptoms

  1. Browsing Internet works fine on Google Chrome.
  2. nslookup google.com works fine from Terminal.
  3. Browsing Internet does NOT work from Safari.
  4. ping google.com does NOT work from Terminal. (Cannot resolve, Unknown host)

Deductions

DNS server and resolution is working, HOWEVER the default MacOS resolution is NOT working.

Attempted Solution

From Terminal:

  • su to Admin user
  • Run command: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Result: DNS resolution still not working.

Improve this question
2
  • What do you get from 'dig google.com'?
    – Linc Davis
    Commented Apr 18 at 20:24
  • dig also works, just like nslookup. As another answer pointed out, these functions are clearly not using the same resolver service that the rest of macOS uses.
    – Daniel
    Commented Apr 20 at 1:33

5 Answers 5

Reset to default
3

A multi-part question, with multi-part answer :)

First: check status

  1. Google Chrome works -- newer settings of Chrome use secure DNS, thus not relying on MacOS's DNS resolution service. (Look at Settings, Privacy and Security, Security, Secure DNS and Secure DNS provider to see what Chrome uses).
  2. The terminal command nslookup does not use the system DNS server.
$ man nslookup
...
macOS NOTICE
       The nslookup command does not use the host name and address resolution or the DNS
       query routing mechanisms used by other processes running on macOS.  The results of
       name or address queries printed by nslookup may differ from those found by other
       processes that use the macOS native name and address resolution mechanisms.  The
       results of DNS queries may also differ from queries that use the macOS DNS routing
       library.
...

Instead nslookup uses the file /etc/resolv.conf. Usually that file has a line like nameserver 127.0.0.1, where that address is provided by the network (during DHCP) or by your OS (in Settings). The same happens with the dig command.

  1. Safari uses the DNS resolver mechanism.
  2. ping uses the DNS resolver mechanism.

In your case, tests (3) and (4) show there is indeed a problem.

Another potential test is to use the command scutil --dns. If the DNS resolver is healthy, the output should show a section "DNS configuration (for scoped queries)", with some valid endpoints.

Second: how to "restart" it?

For MacOS Big Sur the command you have in the question should do it:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

This page has instructions for other macos versions.

Additional

  • I would also check what made the service malfunction. You can use the Console application and look at the System log launchd.log. Alternatively, you can grep directly from the terminal. In my system, I'd use something like:
$ grep -i dns -R /private/var/log
Improve this answer
3
  • After resolving the issue yesterday (see my full Answer elsewhere in the thread), the problem has returned again. I'll likely need to get the staff to reset the router again. Just for completionist and curiosity's sake, I did scutil --DNS while my default DNS resolution is not functioning and I did indeed get a healthy result with the IP of the local router listed under DNS configuration (for scoped queries). I also tried your grep query and I didn't see any recent errors or anything that looked out of the ordinary.
    – Daniel
    Commented Apr 20 at 1:45
  • Your laptop is using the DNS server address provided by that network. If this is causing you trouble, you could temporarily put a fixed address that points to a reputable DNS server of your choice (8.8.8.8 is Google, 1.1.1.1 is Cloudflare, 9.9.9.9 is IBM, ...). The answer below can help.
    – jzer7
    Commented Apr 20 at 1:52
  • No, it's something more fundamental about the way that the default macOS resolver is passing the DNS requests through the router (I assume). I had already tried changing the DNS server to 8.8.8.8 (in System Preferences -> Network -> WiFi -> Advanced, and confirmed that the change had taken effect with scutil --DNS), as one of my first troubleshooting steps, but the problem persisted. I think this is beyond my ability to troubleshoot or solve because it is likely a strange edge case interaction between my older (out-of-date) macOS version and the very likely out-of-date router firmware.
    – Daniel
    Commented Apr 20 at 2:00
1

open Terminal app in Applications/Utilities, type sudo -s and give your password. Check that you have a useable, public DNS resolver IP ( I use 9.9.9.9, 1.1.1.1, 8.8.8.8 ) in the DNS configuration for your machine with scutil --dns. Compare that output with cat /etc/resolv.conf

If all that looks cool, I would then determine if the PF firewall is enabled and if any filter rules are interfering. My process for doing this would be something like:

Check to see if the firewall is enabled with pfctl -si | head -1 and look at the bottom line for the status of the firewall -- it will say enabled or disabled

if the PF firewall is enabled, list the ruleset: pfctl -vvsr

this will give you a numbered list of rules, along with the count of packets affected by the rule.

If your PF firewall is enabled, disable it with a pfctl -d -Fa and then determine if the problem disappeared.

If so, re-enable the firewall with pfctl -E and then echo "set loginterface pflog0" | pfctl -mf - and then create the log interface with ifconfig pflog0 create. fire up a tcpdump ( not sure if I installed mine via home-brew package manager, or if it came with the default Mac OS install...) tcpdump -I pflog0 -n -s 0 -vvv -XX

Then open another Terminal window by holding down the Apple / command key on the keyboard ( usually next to the space bar ) and the letter 'n'. type dig www.google.com a +short. you should see an ip address returned. if not, look at the other Terminal window, you will see the dns request, and the rule number of the PF rule that blocked it.

Hope that helps.

F.

Improve this answer
1

@jzer7's answer has good information about commands/apps that use the system resolver (ping, Safari) vs others like nslookup or dig which don't. So I won't rehash that.

I will add that files in /var/log/ are likely to be missing some information since those legacy logs have been replaced partially or entirely by the Unified Logging System. To query the ULS for DNS-related entries, you can do something like

log show --last 10m --predicate 'subsystem == "com.apple.mDNSResponder" || subsystem == "com.apple.mdns"'

To zero in on only Errors/Faults, and output in JSON format (which contains more detail) here's a variant:

log show --style json --last 10m --predicate '(subsystem == "com.apple.mDNSResponder" || subsystem == "com.apple.mdns") && logType IN {16,17}'

For further filtering and searching, I'd suggest piping output to jq or fx. Happy hunting!

edit: In case the comment I made elsewhere in this topic gets lost, I want to restate:

This sounds like the hotel is intercepting UDP port 53 and trying to MITM it or redirect it to their own (broken) DNS server, probably for logging/blocking purposes. I suggest trying to set up system-wide TLS-based DNS (such as Cloudflare WARP or Tailscale) to mitigate this.

Improve this answer
3
  • I attempted the second query and this is representative of the errors I get when trying to do a DNS lookup using the default macOS resolver: { "traceID" : 3181299489705988, "eventMessage" : "sending to <IPv4:BBsGzUOI> failed: [64: Host is down]", "eventType" : "logEvent", "source" : null, "formatString" : "sending to %@ failed: %{darwin.errno}d", "activityIdentifier" : 0, "subsystem" : "com.apple.mdns", "category" : "resolver", "threadID" : 343543, "senderImageUUID" : "445C4B31-B13A-3A0D-A218-A1B4B516A8AA", "backtrace" : { "frames" : [ (continued.)
    – Daniel
    Commented Apr 20 at 1:52
  • { "imageOffset" : 471914, "imageUUID" : "445C4B31-B13A-3A0D-A218-A1B4B516A8AA" } ] }, "bootUUID" : "F2FB4113-3C90-4169-85F1-FF91A47BD101", "processImagePath" : "\/usr\/sbin\/mDNSResponder", "timestamp" : "2024-04-20 09:35:46.186414+0800", "senderImagePath" : "\/usr\/sbin\/mDNSResponder", "machTimestamp" : 78396928987542, "messageType" : "Error", "processImageUUID" : "445C4B31-B13A-3A0D-A218-A1B4B516A8AA", "processID" : 204, "senderProgramCounter" : 471914, "parentActivityIdentifier" : 0, "timezoneName" : "" }
    – Daniel
    Commented Apr 20 at 1:53
  • Sorry, I'm sure you know that StackExchange doesn't allow neat formatting in comments.
    – Daniel
    Commented Apr 20 at 1:54
0

Some additional things to try:

  • Change DNS settings on Mac shows how to change DNS servers (relevant bit copied here: "Apple menu > System Settings, click Network in the sidebar, click a network service on the right, click Details, then click DNS. (You may need to scroll down.)"), you could try pinging each of them, as sometimes a single dodgy server can cause issues.
  • Are you using a VPN of some sort? It's possible that may have messed with where your DNS queries are going. If possible, try uninstalling it/deleting the configuration.
  • Check that the contents of /etc/resolv.conf and /etc/hosts is sensible (no odd overrides of names or IP addresses).
  • The answer at How can I display the current DNS servers from the command line under OS X? and others show a number of ways to get the DNS servers used, you could see what the output of those are.
Improve this answer
0

I probably should have mentioned that I travel a lot, and I am currently in a hotel in a foreign country. I assumed that the issue was with my computer because:

  1. Everything had been working fine for several days.
  2. The fact that DNS would work when using Chrome or nslookup indicated to me that the DNS resolution was working, but the problem was specifically limited to the default macOS DNS resolver, and therefore the problem must be something specifically limited to my Macbook.

It turns out that the problem is some specific combination of the router at this hotel and the default macOS DNS resolver.

I found several other StackExchange threads with similar issues:

But none of the solutions worked for me.

I finally tried restarting my Macbook (I had been trying to avoid this), and yet the problem still persisted after a restart.

It was at this point that I finally considered that the problem might not be with my Macbook.

I asked the hotel staff to powercycle their wireless router and APs and... DNS resolution in macOS started functioning again as it should.

So, there must be something failing on the router side, but there is still some blame to be laid at the feet of macOS since 'nslookup' and Chrome continue to function normally. In short, there must be something unique and peculiar about the way that the default DNS resolver in macOS works that makes it incompatible with whatever bug is presenting itself on the WiFi or router side.

Improve this answer
4
  • Sounds like the hotel simply has a badly broken setup. This sounds like they are intercepting UDP port 53 and trying to MITM it or redirect it to their own preferred DNS server, probably for logging/blocking purposes. Could also be DHCP exhaustion, misconfigured NAT, or any number of other network shenanigans often seen on public networks like that. I suggest trying to set up system-wide TLS-based DNS (such as Tailscale) to mitigate this.
    – luckman212
    Commented Apr 20 at 2:59
  • The fact that the connection worked for days without issue and that the problem went away after power cycling the hardware makes me think it's more likely a bug with the firmware or hardware than an intentional configuration issue. The fact that nslookup and dig and Google Chrome still work makes me think there is also some bug in the macOS DNS resolver. Somehow those two bugs are conflicting in a unique way.
    – Daniel
    Commented Apr 21 at 3:23
  • "DNS would work when using Chrome or nslookup ... and therefore the problem must be something specifically limited to my Mac" — Chrome uses several mechanisms, such as native DoH and prefetching, to work around DNS issues. It is NOT always a valid indicator that you're connected to a working network. And nslookup, as you correctly point out, is completely independent of the system DNS resolvers. So I would disagree with your conclusion that the problem must be with your Mac's config.
    – luckman212
    Commented Apr 23 at 3:40
  • The Internet worked fine on my WiFi-connected Android and iOS phones at the same time. The issue was isolated to my MacBook, but resetting the router fixed it (for a time). It's definitely something weird.
    – Daniel
    Commented Apr 24 at 4:20

You must log in to answer this question.

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