DNS Poisoning and DNS Leaks Explained: Why Websites Fail to Load

When you type a web address, the first thing your device does is look up the address: it turns the domain name into an IP address. This step is called DNS resolution, and if it goes wrong, nothing after it — connecting, encrypting, loading — can happen. The two most common problems are:

• DNS poisoning: you get the wrong IP, so the connection either fails or shows a certificate error;
• DNS leaks: you’re connected to a VPN, but your DNS queries bypass the tunnel and still go to your local network — revealing every site you visit, and still open to poisoning.

1. ① Ask for directionsDNS lookup: domain → IP
2. ② Someone answers firstThe forged reply is believed
3. ③ An empty houseDNS poisoning: site won't load
4. ④ Shouting out of the windowDNS leak: query skips the tunnel
5. ⑤ Ask inside the tunnelEncrypted DNS + tunnel

An analogy: asking for directions before you set off

DNS is like an information kiosk on the corner with a big address book. Before going somewhere, you ask the person in the kiosk where it is, then set off with the address.

1. Asking normally: you ask, the kiosk looks it up, and you get the right address.
2. Someone answers first: before the kiosk can reply, a stranger shoves a fake address into your hand. You can’t tell real from fake, so you trust whichever arrives first.
3. The result: you follow the fake address to an empty, boarded-up house. That’s DNS poisoning — the site won’t load, even though your connection works.
4. Shouting from inside the tunnel: you’re already riding in a sealed tunnel car, but you lean out of the window and shout your question to a roadside kiosk. Someone nearby writes down where you’re going, and the stranger can still hand you a fake address. That’s a DNS leak.
5. The right way: seal the question in an envelope and hand it, inside the tunnel, to a trusted address book at the far end. You get the right address, and nobody outside sees a thing.

How a DNS lookup works

A typical lookup (covered in more detail in Common network protocols):

1. A program asks the operating system: what’s the IP of www.example.com?
2. The system checks its cache, then asks the network’s configured DNS server (usually your router or your ISP’s resolver);
3. If that server has no cached answer, it asks the root servers → the top-level domain (.com) servers → the site’s own authoritative server, then returns the answer and caches it for a while.

The catch: classic DNS is plaintext over UDP port 53, and it’s unsigned:

• Any device along the way can see which domain you’re looking up;
• Programs accept the first well-formed answer that arrives and discard anything later — including the real one.

(DNSSEC can sign DNS records, but most sites and clients don’t enforce it, so in practice it offers little protection.)

DNS poisoning: getting the wrong address

DNS poisoning means a DNS lookup returns a false result. It usually happens in one of two ways:

Method	How it works
Racing the answer (on-path injection)	A device on the path sees your query and immediately sends a forged reply, which arrives before the real DNS server’s answer
Cache poisoning	A false record gets into a DNS server’s cache, so everyone who asks that server gets the wrong address

Typical symptoms:

• The page spins and eventually shows “connection timed out” or “connection reset” — the forged IP isn’t the site at all;
• The browser shows “Your connection is not private” or another certificate error — the server you reached can’t present the site’s certificate (HTTPS is doing its job here; see What HTTPS encrypts);
• The same site loads sometimes and fails other times, depending on what’s cached.

How to tell if it’s DNS poisoning

Look up the same domain with your local DNS and with encrypted DNS, and compare:

# Lookup using your system's default DNS
nslookup www.example.com

# Lookup using DNS over HTTPS (returns JSON)
curl -s "https://cloudflare-dns.com/dns-query?name=www.example.com&type=A" -H "accept: application/dns-json"

If the IPs are completely different and the local one belongs to an organisation that has nothing to do with the site (check with any IP lookup service), it’s very likely poisoned. Note that large sites use CDNs, so different IPs in different places are normal — what matters is whether the IP belongs to the site’s provider.

Why changing your DNS server doesn’t help

Many guides suggest switching to a public DNS server. But as long as the query is plaintext UDP 53, it can still be seen and answered first along the way — you’ve only changed which kiosk you shout at, not the fact that you’re shouting in the street. What actually works:

• Encrypted DNS: DNS over HTTPS (DoH) or DNS over TLS (DoT) — the query is encrypted, so it can’t be read or forged on the way;
• DNS through the tunnel: the query enters the encrypted tunnel and only leaves on the server’s side, so your local network never touches it.

DNS leaks: queries that bypass the tunnel

A DNS leak is when you’re connected to a VPN and your web traffic is in the tunnel, but DNS queries still go over your local network to the local DNS server. Two consequences:

1. Privacy: your local network can’t see page contents, but it can see every domain you look up;
2. Still poisoned: you still get wrong addresses, so even though the connection goes through the tunnel, it goes to the wrong IP and the site still won’t load.

Common causes:

Cause	What happens
System proxy only	A system proxy only covers programs that honour the setting; other programs’ DNS queries aren’t affected at all (see System proxy vs TUN mode)
IPv6 bypass	The client only captures IPv4, but the system sends DNS queries over IPv6
Parallel queries on every adapter	Some systems query the DNS servers of all network adapters at once and use whichever replies first
Programs with their own DNS	Browser “secure DNS” settings, or apps with a hard-coded DNS server

How to test for a DNS leak

Search for “DNS leak test” to find an online checker. They work by making your browser resolve a batch of randomly generated subdomains, then showing which DNS servers asked for them.

• Only overseas public DNS servers in the results: no leak;
• Your local ISP’s DNS servers in the results: some queries bypassed the tunnel.

With split routing on, common local sites are deliberately resolved by local DNS (it’s faster and returns the nearest CDN address), so that isn’t a leak. The test’s random subdomains aren’t on the local-site list and should be resolved through the tunnel.

Sequence diagram: unprotected vs protected DNS lookups

Step	What happens
①–③	Without protection, the program sends a plaintext DNS query straight to local DNS. The local network sees the domain, and a device on the path may send back a forged address first; the real answer arrives a moment later and is thrown away
④–⑤	With TUN mode, the program sends its DNS query as usual (destination port 53). The client intercepts it and hands it to its own DNS module
⑥–⑨	Overseas domains: the client queries over encrypted DNS (DNS over TLS), and the whole query travels through the tunnel, leaving from the server’s side to a public DNS service. The answer comes back encrypted
⑩	The client returns the correct address to the program, which then connects according to the routing rules
⑪–⑫	Common local sites: the client asks local DNS directly and gets the nearest CDN address, for the best speed

How Pangolin handles DNS

• Captures every DNS query: in TUN mode, queries to port 53 are handled by the client regardless of which DNS server a program is set to use, so nothing leaks out over your local network;
• Overseas domains use encrypted DNS through the tunnel: queries go to a public DNS service over DNS over TLS, carried inside the tunnel — they can’t be seen or forged on the way;
• Common local sites resolve nearby: with Smart routing on, common local sites use local DNS so you don’t get an overseas CDN address;
• IPv4 only: so programs can’t slip around the tunnel over IPv6.

If you still see certificate errors or sites that won’t load while connected to Pangolin, reconnect and restart your browser to clear old DNS cache entries, then check whether the browser’s “secure DNS” is set to a different server. More fixes are in Troubleshooting.

Related reading

• Previous: Split tunneling explained
• Next: Why is my internet slow at night?
• Common network protocols: IP, TCP, UDP, DNS, HTTP, TLS, QUIC
• System proxy vs TUN mode