Troubleshooting
Mac DNS Issues? Here's How to Diagnose and Fix Them
Mac websites loading slowly, partially, or not at all? Diagnose DNS with dig, scutil, and the right cache flushes for macOS Sonoma and Sequoia.
You open Safari, type nytimes.com, and the page hangs at “Looking up nytimes.com” for 15 seconds before loading. Or some sites load instantly and others time out. Or your iPhone on the same Wi-Fi is fast but your MacBook is dragging.
DNS is the address book of the internet, and when it’s slow or broken, everything feels slow even though your raw connection is fine. The good news: DNS issues on a Mac are some of the easiest networking problems to diagnose, because Apple ships solid command-line tools.
Step 1: Confirm it’s DNS
Open Terminal:
ping 1.1.1.1
ping cloudflare.com
If 1.1.1.1 (an IP address) pings fine but cloudflare.com (a hostname) fails or is slow, DNS is the problem. The connection is fine; only the name lookup is broken.
You can also check from a different angle:
dig cloudflare.com
The “Query time” line at the bottom tells you exactly how long DNS took. Anything over 100ms is slow; over 1000ms is broken.
Step 2: Check what DNS server you’re using
scutil --dns
The output is verbose, but look for “resolver #1” and the “nameserver” entries beneath it. These are the DNS servers your Mac is currently using. If they’re your router’s IP (192.168.x.x), that’s normal — most routers proxy DNS.
If the listed nameservers are slow or wrong, that’s your fix.
Step 3: Flush the DNS cache
This is the single most useful DNS command on Mac. Open Terminal:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
The first command flushes the resolver cache. The second restarts the multicast DNS responder, which on macOS handles both .local resolution and the regular DNS cache.
After running both, retry the slow sites. If they’re suddenly fast, the cache was holding stale answers — common after switching networks, changing DNS, or after an ISP-side change.
Step 4: Try a faster public DNS
If your ISP’s DNS or your router’s DNS is slow, switch to a faster public resolver. The widely-used options:
- Cloudflare: 1.1.1.1 and 1.0.0.1 (also IPv6: 2606:4700:4700::1111).
- Google: 8.8.8.8 and 8.8.4.4.
- Quad9: 9.9.9.9 (filters known malicious domains).
- OpenDNS: 208.67.222.222 and 208.67.220.220 (with optional content filters).
To set them on your Mac:
System Settings → Network → Wi-Fi → Details → DNS tab. Click + to add entries. Drag your preferred ones to the top. Apply.
Step 5: Check for DNS hijacking
Some networks intercept DNS for filtering, captive portals, or ad insertion. Check:
dig +short version.bind chaos txt @192.168.1.1
(Replace 192.168.1.1 with your router’s IP.)
If you get an unexpected response or a timeout, your router is doing something to DNS. Hotels, airports, and some ISPs run “transparent DNS proxies” that override your settings — even with public DNS configured on your Mac, requests get redirected.
Workarounds:
- Use DNS over HTTPS (DoH) or DNS over TLS (DoT) to encrypt DNS queries so they can’t be intercepted.
- macOS 11+ supports DoH/DoT via Configuration Profiles. Cloudflare provides a downloadable profile at one.one.one.one.
Step 6: Reset the network configuration
If DNS is broken in a way no setting fixes, the SystemConfiguration cache may be corrupt:
- Wi-Fi off.
- Finder → Go → Go to Folder →
/Library/Preferences/SystemConfiguration/. - Move to desktop:
preferences.plistNetworkInterfaces.plistcom.apple.network.identification.plist
- Restart the Mac.
- Wi-Fi on, rejoin network.
DNS settings rebuild from scratch.
Step 7: Check /etc/hosts
The /etc/hosts file overrides DNS for specific names. If a developer tool or VPN modified it, you may have stale entries pointing to wrong IPs.
cat /etc/hosts
Default content is just localhost entries. If you see entries you didn’t add — especially for popular sites — that’s your culprit. Edit:
sudo nano /etc/hosts
Remove lines that don’t belong. Save (Ctrl+O, Enter, Ctrl+X).
Common offenders:
- Old
dnsmasqconfigs from local development. - Ad-blocking apps that added entries.
- Corporate device management agents.
- Pi-hole / NextDNS with sideloaded entries.
Step 8: Check for VPN interference
A VPN configures custom DNS that routes through the VPN tunnel. If the VPN’s DNS is slow, every lookup is slow even after the connection is established.
Disconnect the VPN. Test DNS speed. If it’s faster, the VPN’s DNS was the bottleneck. Configure the VPN to use a faster public DNS (most clients let you specify this in settings).
Old VPN apps may also have left DNS-altering network extensions behind:
systemextensionsctl list
If you see extensions from VPNs you no longer use, they may still be intercepting and routing DNS to nowhere.
A clean VPN uninstall removes the system extension, network configurations, helper tools, and stale DNS settings. Drag-to-trash leaves all of those. Sweep’s app uninstaller does the full removal.
Step 9: Check for IPv6 issues
Some ISPs and routers have flaky IPv6, which causes Macs to attempt IPv6 lookups, time out, then fall back to IPv4 — a 30-second delay on every DNS query.
Disable IPv6 temporarily:
networksetup -setv6off Wi-Fi
(Replace “Wi-Fi” with your service name from networksetup -listallnetworkservices.)
Test DNS speed. If it’s faster, IPv6 was the issue. You can leave it off, or fix it at the router level.
To re-enable:
networksetup -setv6automatic Wi-Fi
Step 10: Test on a different network
Connect to your iPhone’s hotspot. Run the same DNS tests. If DNS is fast on the hotspot but slow on home Wi-Fi, the issue is the home network — not your Mac.
In that case, focus on the router:
- Reboot it.
- Update firmware.
- Change DNS settings in the router admin panel.
Step 11: Check the resolver order
scutil --dns shows multiple “resolver” entries. Each handles different domains:
- resolver #1: default for all queries.
- resolver #2+: specific domains routed elsewhere (often VPN-induced).
If a VPN inserted a custom resolver for *.corp.example.com, that resolver applies for those domains only. Most home users only need resolver #1, with public DNS as the nameserver.
If you see resolvers from VPNs that aren’t connected, those are stuck. Sign out of the VPN cleanly and check again.
Step 12: Check for “happy eyeballs” timeout
macOS uses an algorithm called Happy Eyeballs to race IPv4 and IPv6 connections and pick the winner. When the IPv6 path is broken, Happy Eyeballs introduces a delay. The fix is the same as Step 9 — disable IPv6, or fix the underlying issue.
Step 13: Restart the resolver in detail
A more aggressive flush:
sudo killall -INFO mDNSResponder
sudo killall -HUP mDNSResponder
sudo dscacheutil -flushcache
The first command logs internal state to system log (you can sudo log show --predicate 'process == "mDNSResponder"' --last 5m to read it), then HUP restarts.
If mDNSResponder keeps respawning into a broken state, Apple’s bug. Check Console.app for crashes around startup.
Step 14: Restart the Mac
If all else fails, a full restart cycles every network state. After reboot, before opening any apps, run:
sudo dscacheutil -flushcache
ping cloudflare.com
If DNS works immediately after a clean boot but degrades over time, something running on your Mac is breaking it. Likely candidates: ad blockers, VPN clients, security software, or background processes from an uninstalled app.
Step 15: When DNS is genuinely broken upstream
Some scenarios you can’t fix:
- ISP’s DNS is overloaded during peak hours: switch to public DNS.
- A specific website’s authoritative DNS is misconfigured: nothing you can do.
- DNSSEC validation fails because the domain owner messed up: nothing you can do.
- Your network blocks port 53 outbound (rare): use DoH/DoT to bypass.
Most “DNS issues on Mac” cases are fixed by Step 3 (cache flush), Step 4 (switching to public DNS), or Step 8 (VPN cleanup). The dscacheutil + mDNSResponder commands together are the single most useful piece of network troubleshooting on macOS — keep them in your back pocket.