Tools

Tools: Essential Guide: Debugging DNS leaks: why your VPN isn't hiding what you think it is

2026-05-18 0 views admin
Tools: Essential Guide: Debugging DNS leaks: why your VPN isn't hiding what you think it is

The frustrating problem

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

Step 1: Confirm the leak

Step 2: Force DNS through the tunnel

Step 3: Tame the browsers and runtimes

Step 4: Block the leak path entirely

Prevention tips for future projects 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. 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. 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: 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. 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. 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: The monitor subcommand is underrated — it shows every query the stub resolver processes, including which interface it was sent over. 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: 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: 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. 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: 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: The +2 gives you debug output showing which resolver path was actually taken — invaluable when you're not sure if your fix landed. 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. 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. 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. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse

Command

Copy

# In one terminal, watch DNS on your physical NIC -weight: 600;">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 # In one terminal, watch DNS on your physical NIC -weight: 600;">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 # In one terminal, watch DNS on your physical NIC -weight: 600;">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 # systemd-resolved -weight: 500;">status, per-interface resolvectl -weight: 500;">status # Classic view cat /etc/resolv.conf # What's actually being asked, in real time -weight: 600;">sudo resolvectl monitor # systemd-resolved -weight: 500;">status, per-interface resolvectl -weight: 500;">status # Classic view cat /etc/resolv.conf # What's actually being asked, in real time -weight: 600;">sudo resolvectl monitor # systemd-resolved -weight: 500;">status, per-interface resolvectl -weight: 500;">status # Classic view cat /etc/resolv.conf # What's actually being asked, in real time -weight: 600;">sudo resolvectl monitor [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 [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 [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 # 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/-weight: 500;">update-resolv-conf down /etc/openvpn/-weight: 500;">update-resolv-conf # 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/-weight: 500;">update-resolv-conf down /etc/openvpn/-weight: 500;">update-resolv-conf # 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/-weight: 500;">update-resolv-conf down /etc/openvpn/-weight: 500;">update-resolv-conf network.trr.mode = 5 // Off by user choice; do not use DoH network.trr.mode = 5 // Off by user choice; do not use DoH network.trr.mode = 5 // Off by user choice; do not use DoH // 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 // 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 // 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 # nftables: block UDP/53 and TCP/53 on the physical interface -weight: 600;">sudo nft add table inet vpn_guard -weight: 600;">sudo nft add chain inet vpn_guard output { type filter hook output priority 0 \; } -weight: 600;">sudo nft add rule inet vpn_guard output oifname wlan0 udp dport 53 drop -weight: 600;">sudo nft add rule inet vpn_guard output oifname wlan0 tcp dport 53 drop # nftables: block UDP/53 and TCP/53 on the physical interface -weight: 600;">sudo nft add table inet vpn_guard -weight: 600;">sudo nft add chain inet vpn_guard output { type filter hook output priority 0 \; } -weight: 600;">sudo nft add rule inet vpn_guard output oifname wlan0 udp dport 53 drop -weight: 600;">sudo nft add rule inet vpn_guard output oifname wlan0 tcp dport 53 drop # nftables: block UDP/53 and TCP/53 on the physical interface -weight: 600;">sudo nft add table inet vpn_guard -weight: 600;">sudo nft add chain inet vpn_guard output { type filter hook output priority 0 \; } -weight: 600;">sudo nft add rule inet vpn_guard output oifname wlan0 udp dport 53 drop -weight: 600;">sudo nft add rule inet vpn_guard output oifname wlan0 tcp dport 53 drop - 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. - Test the leak path every time you change network config. Don't trust that the previous setup still works after a kernel -weight: 500;">update or VPN client -weight: 500;">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.

🏷️ Tags

toolsutilitiessecurity toolsessentialguidedebuggingleakshidingthinkrce

More from Tools

Tools: SSH died. Spent 3 hours fixing the wrong thing. (2026)

Tools: SSH died. Spent 3 hours fixing the wrong thing. (2026)

2026-05-20 0
Tools: Ultimate Guide: MainWP vs ManageWP vs custom scripts: how I manage 15+ WordPress sites in 2025

Tools: Ultimate Guide: MainWP vs ManageWP vs custom scripts: how I manage 15+ WordPress sites in 2025

2026-05-20 0
Tools: Metrics: How cAdvisor and CRI Collect Kubernetes Stats Kubelet

Tools: Metrics: How cAdvisor and CRI Collect Kubernetes Stats Kubelet

2026-05-20 0
Tools: Essential Guide: GPU Observability for Workloads That Cannot Phone Home

Tools: Essential Guide: GPU Observability for Workloads That Cannot Phone Home

2026-05-20 0

Trending

1

CVE-2025-61481: Critical Remote Code Execution Vulnerability in MikroTik RouterOS & SwitchOS

2025-10-27 • 189 views
2

CVE-2025-43939: Dell Unity OS Command Injection (High)

2025-10-30 • 148 views
3

Google disputes false claims of massive Gmail data breach

2025-10-30 • 130 views
4

Microsoft: DNS outage impacts Azure and Microsoft 365 services

2025-10-30 • 88 views
5

3.5B Accounts, 1 Critical Flaw: Meta Closes WhatsApp Data-Harvesting

2025-11-25 • 81 views