Last month I was setting up a hardened dev environment for a client doing security research. They wanted all traffic from their workstation tunneled through a VPN, no exceptions. Simple, right? Install WireGuard, flip the toggle, done.

Then I ran a leak test and watched their real ISP-assigned DNS server pop up on the report. The traffic was tunneled. The DNS queries weren't. We'd been working under a false sense of privacy for a week.

This is one of those bugs that doesn't crash anything, doesn't throw an error, and silently undermines the entire reason you set up the VPN in the first place. Let's walk through what's actually happening and how to fix it for good.

The frustrating problem

You've done everything right. You're connected to a VPN. curl ifconfig.me returns the VPN's exit IP. Your routing table looks clean. And yet, when you visit a DNS leak test site, your ISP's resolver shows up in the results.

Worse: in some cases your VPN tunnel is fine for HTTP and HTTPS, but DNS is going out of band. Every domain you visit is still visible to your ISP, your coffee shop's network, or whoever else is between you and the resolver you didn't mean to use.

If you're running this setup on a fleet of dev boxes or CI runners that talk to internal services, the consequences get worse. Internal hostnames can leak to public resolvers. Hostnames are often as sensitive as the queries themselves.

Root cause: DNS is not part of your VPN tunnel by default

Here's the thing most VPN tutorials gloss over. A VPN tunnel routes IP packets. DNS resolution happens at the OS level, often before the packet routing decision, using whatever resolver was configured by your DHCP lease, your /etc/resolv.conf, or your systemd-resolved stub.

There are usually three culprits:

• systemd-resolved keeps per-link DNS configurations and may continue using the original interface's DNS even when traffic is routed elsewhere.
• Browsers with DNS-over-HTTPS (Firefox, Chrome) bypass the OS resolver entirely and talk directly to a hardcoded DoH endpoint over HTTPS — which is tunneled through the VPN, but goes to a third party you may not trust.
• Applications using their own resolvers — Go binaries with GODEBUG=netdns=go, some container runtimes, and language-specific resolver libraries can ignore system settings.

The VPN sees the encrypted DoH request and dutifully tunnels it. The OS resolver sends its plaintext UDP/53 query out the wrong interface. Both paths can coexist on the same machine, which is what makes this so confusing to debug.

Step 1: Confirm the leak

Before fixing anything, prove it's actually leaking. The cheapest reliable test is tcpdump on the physical interface (not the VPN interface) while you trigger a lookup.

# In one terminal, watch DNS on your physical NIC
sudo tcpdump -i wlan0 -n 'udp port 53 or tcp port 53'

# In another terminal, trigger a fresh lookup
# Use a unique domain so cached answers don't hide the issue
dig $(uuidgen | tr A-Z a-z).example.com

If anything shows up on the first terminal, you're leaking. If the only DNS traffic appears on your VPN interface (wg0, tun0, etc.), you're clean.

You can also check what resolver your system thinks it's using:

# systemd-resolved status, per-interface
resolvectl status

# Classic view
cat /etc/resolv.conf

# What's actually being asked, in real time
sudo resolvectl monitor

The monitor subcommand is underrated — it shows every query the stub resolver processes, including which interface it was sent over.

Step 2: Force DNS through the tunnel

The fix depends on your VPN client, but the principle is the same: every DNS query must travel inside the encrypted tunnel and hit a resolver on the other side.

For a WireGuard config, this is one line:

[Interface]
PrivateKey = <your-private-key>
Address = 10.0.0.2/24
# Use a resolver that lives on the VPN side
DNS = 10.0.0.1

[Peer]
PublicKey = <peer-public-key>
Endpoint = vpn.example.com:51820
# Route everything, including DNS
AllowedIPs = 0.0.0.0/0, ::/0

The DNS = line tells wg-quick to update /etc/resolv.conf (or talk to systemd-resolved) so queries go to a server reachable only through the tunnel. The AllowedIPs = 0.0.0.0/0 part ensures the packet to that resolver actually enters the tunnel — without it, your route table might still send the DNS query out the default gateway.

For OpenVPN, the equivalent push options usually come from the server side, but you can force them locally:

# In your client config
dhcp-option DNS 10.8.0.1
block-outside-dns       # Windows-only, blocks leaks aggressively
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

On macOS and Linux, that update-resolv-conf script is the one that actually modifies the system resolver. It's worth reading — it's a useful template for understanding how DNS gets injected at runtime.

Step 3: Tame the browsers and runtimes

This is the step most people skip. Even with a perfect VPN config, Firefox and Chrome can still bypass your OS resolver if DoH is enabled.

For Firefox, set this in about:config:

network.trr.mode = 5   // Off by user choice; do not use DoH

Mode 5 disables DoH entirely. If you want DoH but routed through your VPN's resolver, use mode 3 and set network.trr.uri to your tunnel-side endpoint. The Mozilla TRR docs explain the modes in detail.

For Go programs, force the system resolver:

// Force cgo-based resolution which respects /etc/resolv.conf changes
// done by the VPN client. The pure-Go resolver has caching that
// can outlast a VPN session change.
import _ "net"

// Or via environment
// GODEBUG=netdns=cgo+2

The +2 gives you debug output showing which resolver path was actually taken — invaluable when you're not sure if your fix landed.

Step 4: Block the leak path entirely

Belt and suspenders. Add firewall rules that drop any DNS traffic not going through the tunnel. This way, if a misconfigured app tries to bypass, it fails loudly instead of leaking silently.

# nftables: block UDP/53 and TCP/53 on the physical interface
sudo nft add table inet vpn_guard
sudo nft add chain inet vpn_guard output { type filter hook output priority 0 \; }
sudo nft add rule inet vpn_guard output oifname wlan0 udp dport 53 drop
sudo nft add rule inet vpn_guard output oifname wlan0 tcp dport 53 drop

If an app tries to leak, it gets a connection refused instead of a successful query to your ISP. That's a much better failure mode — you'll notice it immediately.

Prevention tips for future projects

• Test the leak path every time you change network config. Don't trust that the previous setup still works after a kernel update or VPN client upgrade.
• Prefer kill-switch behavior — drop all non-VPN traffic at the firewall when the tunnel is down. Most modern VPN clients support this; if yours doesn't, use nftables.
• Standardize DNS at the tunnel exit. Run an unbound or dnsmasq instance on the VPN server so you control the resolver path end to end.
• Audit application-layer resolvers. Browsers, container runtimes, and language standard libraries each have their own DNS quirks. Document them per project.
• Run a periodic automated leak test. A daily cron job that runs dig against a unique subdomain and checks your authoritative server's logs for the source IP works well.

DNS leaks are the kind of bug that hides in plain sight. The fix isn't hard once you know where to look, but the surface area is bigger than most people realize. If you're going to put the work into setting up a VPN, spend the extra hour making sure your name resolution actually respects it.