# DNS leakage — your VPN is fine, your DNS is snitching > You paid for a good VPN, your traffic is encrypted, your exit IP is clean. Then every site you visit is quietly announced in plaintext to a resolver you never chose — often your ISP's — with your real subscriber account attached. DNS is the address book of the internet, and if the lookups leak outside your tunnel, the tunnel is theatre. The exit hides where your packets go; the DNS query already told someone where they were headed. Markdown twin of https://xmr.club/opsec/17-dns-leakage. CC-BY-4.0. Attribute "xmr.club". ## At a glance - Canonical: https://xmr.club/opsec/17-dns-leakage - Series: #OPSEC52 — weekly threat-model-first OPSEC cards - Week: 17 - Pillar: Network / VPN / Tor stack - Difficulty: intermediate - Cost: $0 - Language: en - Published: 2026-09-14 ## Body # OPSEC52 / Week 17 — DNS leakage: your VPN is fine, your DNS is snitching > You paid for a good VPN, your traffic is encrypted, your exit IP is clean. Then every site you visit is quietly announced in plaintext to a resolver you never chose — often your ISP's — with your real subscriber account attached. DNS is the address book of the internet, and if the lookups leak outside your tunnel, the tunnel is theatre. **Threat model:** your ISP and its logged resolver, any DNS provider that sees your queries in the clear (timestamped, tied to your line), a hostile Wi‑Fi operator running a captive resolver, and an analyst who only needs the **list of names you asked for** — not the page contents — to reconstruct your evening. A leaked lookup is metadata, and metadata is the part that survives encryption. ## The easy 20% everyone gets right Turn on the VPN, see a new IP on `whatismyip`, feel safe. That's the easy part, and it's genuinely necessary — but it only hides **where the packets exit**. DNS is a separate question: *before* your browser opens a connection to a site, it asks "what IP is this name?" If that question travels to the wrong resolver, or outside the encrypted tunnel, the exit IP is irrelevant. Someone already has a plaintext, timestamped log that says *this line looked up these hostnames at these times*. ## Why the query leaks even with a VPN up Three common failure modes, none obvious: - **Split-tunnel / OS resolver stickiness.** The operating system caches a DNS server from before the tunnel came up (your ISP's, or the coffee-shop router's) and keeps using it. The VPN moved your traffic; the OS never moved the lookups. - **IPv6 escape.** Your VPN tunnels IPv4 but the machine still has native IPv6. The browser prefers IPv6, resolves and connects over it, straight past the tunnel. This is the single most common "but I had a VPN" leak. - **WebRTC and app-level resolvers.** Browsers and some apps do their own name resolution or expose your real local addresses via WebRTC, bypassing whatever the OS is configured to do. The tell is subtle: everything *works*, pages load, so nothing prompts you to check. A leak is silent by construction. ## The fix, in order of leverage 1. **Force DNS through the tunnel.** A trustworthy VPN client resolves DNS *inside* the tunnel using the provider's own resolver and blocks all other DNS. Mullvad, IVPN and Proton do this by default — confirm the setting exists and is on, don't assume. 2. **Encrypt the query itself — DoH / DoT.** DNS‑over‑HTTPS or DNS‑over‑TLS wraps the lookup so the network can't read or forge it. Useful, but understand the trade: it hides the query from your ISP and moves that visibility to whoever runs the encrypted resolver. Encryption is not anonymity — pick a resolver you'd actually trust with your browsing list (Quad9, Mullvad DNS), not one that monetises it. 3. **Kill IPv6 if your VPN doesn't carry it.** If the client can't tunnel IPv6, disable IPv6 on the interface entirely. A disabled protocol can't leak. 4. **Leak‑proof kill switch.** The client should drop *all* traffic — DNS included — the instant the tunnel fails, rather than falling back to the local resolver. ## Verify — don't trust the marketing Assume a leak until you've proven otherwise. Load a DNS‑leak test (`dnsleaktest.com`, Mullvad's own check page) with the VPN up and read what resolvers answer. If you see your ISP, your city, or any server you didn't choose, the tunnel is leaking. Re‑test after every OS update and on every new network — a Windows or macOS update can silently reset resolver settings, and a captive‑portal Wi‑Fi will happily re‑inject its own. ## The privacy‑coin corner This is exactly why the transparent-chain crowd underrates network metadata. You can run a perfectly clean on‑chain footprint and still tie your wallet software, your node, and your block‑explorer habits together through leaked DNS — every `xmrchain.net` or exchange lookup is a name in someone's log. If you route wallet and node traffic over Tor (or a leak-proof tunnel with forced DNS), that correlation surface closes. Buying no‑KYC is the on‑chain half; not announcing every service you touch to your ISP is the network half. Both or neither. **One thing to do today:** bring your VPN up, open a DNS‑leak test, and actually look at which resolvers answer. If any of them are your ISP, you've been leaking your whole browsing list the entire time you thought you were covered — fix the client's DNS setting, disable IPv6 if it's not tunnelled, and re‑test. --- *Curated by [Cyber Satoshi](https://x.com/xbtoshi). Part of OPSEC52 — 52 weeks, 52 privacy pillars, threat‑model first. See also Week 1 (VPN exit discipline) and Week 5 (browser compartmentalization).* ## Related - HTML: https://xmr.club/opsec/17-dns-leakage - Series index: https://xmr.club/opsec - Twin index: https://xmr.club/llm/opsec.txt