How to Check for DNS Leaks on macOS

You turn the VPN on, the icon says connected, and the site that shows your IP address now shows a different one. Everything looks right. But your Mac can still ask the wrong party where websites live, and a connected icon does not tell you that. This guide shows how to check for a mac vpn dns leak using tools that are already on the machine, plus an online test, and how to read what you see.

If you want the theory first, what a DNS leak is explains the concept and how DNS works covers the lookup chain. Here we assume you know the basics and want a repeatable routine for macOS.

What a DNS leak means on a Mac

Every time you open a site, your Mac asks a DNS resolver to turn the name into an IP address. With a working VPN, that question should travel inside the tunnel to a resolver the VPN chooses. In a leak, the question goes out through your ordinary connection to the resolver of your router, your internet provider or the cafe network. The page still loads, the VPN icon is green, and the only visible change is that whoever runs that resolver can see the list of names you look up.

That list is not nothing. It shows which services you use and when. A leak does not expose page content, because that part is encrypted in the tunnel, but it undermines one of the reasons many people turn a VPN on.

On a Mac the picture has a twist. macOS does not keep one global DNS server. It keeps a set of resolvers, each tied to a network interface and sometimes to specific domain names, and the system decides per lookup which one applies. That flexibility is exactly why a leak can hide in places that other systems do not have, and it is why the Terminal view is useful.

How macOS chooses a DNS server

A short mental model makes the rest easier.

• Each network service (Wi-Fi, Ethernet, a VPN) can supply DNS servers, either learned automatically from the network or typed in by you.
• The system resolver service, mDNSResponder, answers lookups for almost every app. It decides which resolver to ask based on interface order, domain-specific rules and whether a resolver is marked as reachable.
• A VPN that works correctly adds a resolver tied to its tunnel interface, and arranges for it to take priority for general lookups.
• Some apps skip the system entirely. Browsers with their own secure DNS setting send lookups straight to a provider of their choice, regardless of what the system says.

So there are two questions: what does the system believe, and what do individual apps actually do. A thorough check looks at both.

Step one: record your DNS before connecting

You need a baseline. Disconnect the VPN, then do the following.

1. Open System Settings, go to Network, choose your active connection (Wi-Fi or Ethernet), click Details and open the DNS tab. The labels vary a little between macOS versions. Note the servers listed. If the list is grey and automatic, your router supplies them.
2. In Terminal, run scutil --dns. The output is long. Look at the first block, labelled resolver #1, and note its nameserver lines and the if_index entry, which names the interface (for example en0).
3. Optionally run networksetup -getdnsservers Wi-Fi. It prints servers you set by hand, or says "There aren't any DNS Servers set", meaning the Mac uses what the network hands out. If your connection has another name, list the names with networksetup -listallnetworkservices.

Write the resolver addresses down. Typical results are a private address such as 192.168.1.1 (your router, one of the private ranges in RFC 1918) or the addresses of a public resolver you chose earlier.

Step two: connect and compare

Connect the VPN and wait a few seconds. Then run scutil --dns again and compare.

What a healthy result usually looks like:

• A resolver tied to a utun interface appears, and it is listed early.
• The default resolver for general lookups is not the router address you noted in step one.
• Any remaining resolvers that still point at en0 are tied to specific domain names (a local network name, for example), not to everything.

Warning signs:

• Resolver #1 is unchanged from your baseline and still points at en0 with your router's address.
• There is no utun resolver at all.
• Several resolvers appear and the one on en0 is listed before the tunnel one.

Be careful about concluding too much from this alone. The output shows configuration, not the path a particular query took. Treat it as an early indicator and confirm with a test.

Step three: run an online DNS leak test

Open a DNS leak test page in your browser. Choose the extended or full test if one is offered, because it sends many unique lookups and collects the answers. The page then lists the resolvers that actually asked on your behalf, usually with the organisation that operates each.

Read the results like this.

What you see	What it suggests
Only resolvers operated by the VPN side, or ones that differ from your baseline	No leak visible in this browser
Your home router or your internet provider's resolver	A leak: lookups left the tunnel
A large public resolver you did not set	Possibly the browser's secure DNS, a profile, or a setting you forgot; investigate
The same resolver list as before you connected	The VPN probably is not changing DNS at all
A mix of both kinds	Partial leak, often IPv6 or a domain-specific rule

A few cautions apply. A test shows the resolvers seen by the test site, and large DNS providers answer from many addresses, so you may see several lines for one operator. The country shown for a resolver is a guess based on its address. And an online page can only report on the browser you used, so a clean result in one browser says little about a different app.

For a broader review, the EFF's Cover Your Tracks site also tests what your browser reveals, though it targets fingerprinting rather than DNS alone.

Step four: check the system resolver from Terminal

Online tests run in the browser. To see what the system itself does, ask it directly.

• dscacheutil -q host -a name example.com resolves a name using the same path as most Mac apps. It prints the address but not which server answered, so it only confirms that resolution works.
• nslookup example.com prints a Server: line. Be aware that nslookup reads its own copy of the resolver settings, which can differ from what mDNSResponder uses for apps. A Server: line showing your router while scutil --dns shows a tunnel resolver does not prove a leak.
• dig example.com prints the answer and a SERVER: line, with the same caveat. If dig is missing on your Mac, nslookup does the job.

You can force a query to a specific resolver with dig @address example.com, which is useful to check that a resolver is reachable, but remember that doing so bypasses the system's own choice and is no proof of leaks.

The honest summary is that Terminal tools tell you what the Mac is configured to do, and the online test tells you what actually reached a DNS server on the internet. Good diagnosis uses both.

Mac-specific reasons for a leak

If a leak is real, it nearly always has one of these causes.

1. Manually typed DNS servers. If you once set a DNS server by hand in the Network pane, some VPN apps cannot override it, and the typed server keeps answering. Remove it to return to automatic.
2. A DNS profile or encrypted DNS configuration. A configuration profile that sets encrypted DNS system-wide can take priority over the VPN's resolver. Look in the profiles section of System Settings (General, then Device Management or Profiles) for ones you do not recognise.
3. iCloud Private Relay. It changes how Safari and some other traffic leaves the Mac, which can make results hard to interpret. Compare with it off, remembering that a privacy relay and a full VPN are different tools.
4. Browser secure DNS. Chrome, Firefox and other browsers can send lookups over HTTPS to a provider they choose. RFC 8484 describes the mechanism. If the browser setting is on, the browser may ignore the VPN's resolver on purpose.
5. IPv6. If your network provides IPv6 and the VPN covers only IPv4, lookups or traffic can use IPv6 outside the tunnel.
6. Service order. With both Wi-Fi and Ethernet, or a USB adapter, the order of network services affects which resolver is tried first.
7. Another networking tool. A second VPN, a content filter, a security suite or a local DNS cache such as a development resolver can intercept lookups.
8. Captive portals and weak reconnects. Right after waking from sleep or joining hotel Wi-Fi, the Mac may use the network's resolver for a while before the tunnel re-establishes.

Fixing a leak, in order of effort

Go from the easiest change to the hardest, testing after each one.

1. Disconnect and reconnect the VPN, then rerun the test. Many leaks are only transient.
2. Flush the cache with sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Cached answers can hide what is happening.
3. Set DNS back to automatic in Network, Details, DNS if you had typed servers by hand.
4. Turn off browser secure DNS for the test, and Private Relay as well. If the leak disappears, you have found the cause and can decide which setting matters more to you.
5. Remove unknown profiles after confirming they are not from your employer or school.
6. Check IPv6. If the VPN does not cover it, turning it off for the test connection in Network, Details, TCP/IP shows whether it is the source.
7. Restart the Mac to clear resolver state, then connect again before opening any other app.
8. Contact support with your baseline and result if nothing changes. The Mac troubleshooting guide lists what to prepare.

Do not paste random Terminal commands from forum posts into a Mac that you rely on. The commands above only read settings or clear a cache, which is as far as a routine check needs to go.

A worked example

Sofia works from a cafe on a MacBook. At home, scutil --dns shows resolver #1 at 192.168.1.1 on en0. At the cafe she connects the VPN and runs the command again. Resolver #1 now points to an address on utun4, and the router address is moved down the list, tied to a local domain. She runs an extended online test: the listed resolvers are not her cafe's provider. She repeats the test in a second browser and sees the same.

Then she turns on secure DNS in her usual browser to see what changes, and the test lists a large public resolver she chose a year ago. The VPN is fine; the browser setting is simply doing its own thing. She decides to leave it off while on public networks and notes this in a short checklist. Her routine now takes three minutes: baseline, connect, compare, test in two browsers.

When to repeat the check, and what a clean result means

Re-run the routine after a macOS update, after installing another network tool or profile, after switching to a new router, and when you set up the VPN on a new Mac. Save the baseline so you can compare quickly.

A clean result means that in the tested conditions your lookups did not reach your usual resolver. It does not prove the VPN is flawless, and it says nothing about what the VPN provider's resolver can see; the point of a VPN is to move trust, not to remove it. It also does not address other leak types. If you want a full routine, the VPN testing article covers IP, WebRTC and kill switch checks, and the help guide on checking whether your VPN is working is the quick version.

Summary

To check a mac vpn dns leak, record your resolvers before connecting, connect, compare with scutil --dns, then confirm with an extended online test in more than one browser. If a leak shows, the usual suspects are hand-typed DNS servers, profiles, Private Relay, browser secure DNS, IPv6, service order or another network tool. Fix them one at a time and retest after each change. When your Mac is ready, you can download the VPNclient app and view passes on the pricing page.