DNS Spoofing and Poisoning: How Attackers Redirect Your Traffic

You type “bank.com” into your browser. Your computer asks a DNS server: “What’s the IP address for bank.com?” The DNS server responds with an IP address. Your browser connects to that IP address.

What if the DNS response is forged? What if the IP address you receive belongs to the attacker? You’d connect to the attacker’s server, see a perfect replica of your bank’s login page, enter your credentials, and hand them directly to the attacker.

The URL bar still says bank.com. The page looks real. But you’re not talking to your bank.

How DNS spoofing works

DNS — the Domain Name System — is the phone book of the internet. It translates human-readable domain names into IP addresses that computers use to route traffic. DNS was designed in 1983. Security was not a design goal.

DNS spoofing corrupts this translation process. There are two primary variants:

Local DNS spoofing

The attacker sits on the same network as the victim (via evil twin, ARP poisoning, or rogue access point) and intercepts DNS queries. When the victim’s device asks “where is bank.com?”, the attacker responds before the legitimate DNS server can, providing a forged IP address.

DNS cache poisoning

The attacker targets the DNS resolver itself — the server your ISP or organization uses to look up domain names. By injecting forged records into the resolver’s cache, the attacker corrupts name resolution for everyone who uses that resolver. A single successful poisoning attack can redirect thousands of users simultaneously.

The Kaminsky attack, discovered in 2008, demonstrated that DNS cache poisoning was practical against any resolver. Patches were issued, but the underlying protocol vulnerability — DNS responses are not cryptographically authenticated — remains.

The perfect phishing page

Traditional phishing sends you to a suspicious URL — something like bank-secure-login.com or banksecurity.net. You might notice. Your browser might warn you. Your email filter might catch it.

DNS spoofing sends you to bank.com. The real domain. The URL is correct. Bookmarks work. Saved passwords autofill. There is no visual indicator that anything is wrong.

The attacker clones the target website — which takes minutes with modern tools — and serves it from their own server. The only difference is the IP address behind the domain name, and users never see IP addresses.

DNS spoofing is phishing without the typosquatting. The domain is right. The page is right. The user has zero visual cues that they’re on the wrong server. This is why it’s one of the most dangerous attacks in the MITM family.

Why DNS-over-HTTPS doesn’t fully solve it

DNS-over-HTTPS (DoH) encrypts DNS queries so attackers on the network cannot read or modify them in transit. This is a genuine improvement over plaintext DNS. But it has limitations:

• It only protects the query, not the resolution chain. If the upstream DNS resolver itself is compromised or poisoned, DoH faithfully delivers the poisoned response over an encrypted channel.
• Corporate networks often disable it. Many enterprises run their own DNS resolvers for security monitoring and policy enforcement. DoH bypasses these controls, so IT departments disable it.
• It doesn’t protect against local spoofing. If the attacker controls the network gateway (evil twin, rogue AP), they can redirect DoH queries to their own DoH server that returns forged responses.
• Adoption is inconsistent. Not all applications use the system’s DoH configuration. Many libraries and tools still make plaintext DNS queries.

DNSSEC: the right idea, almost no deployment

DNSSEC cryptographically signs DNS records, allowing resolvers to verify that a response hasn’t been tampered with. This is the correct solution to DNS spoofing at the protocol level.

The problem is adoption. As of 2026, fewer than 5% of domains have DNSSEC properly configured. The protocol is complex to deploy, easy to misconfigure, and increases DNS response sizes significantly. Major outages caused by DNSSEC misconfigurations (Cloudflare, 2023) have made operators cautious about deployment.

Even when DNSSEC is deployed, most end-user devices don’t validate signatures themselves — they rely on the resolver to validate. If the last mile between the resolver and the device is compromised, the validated response can still be replaced.

How ZK Proven catches DNS spoofing

ZK Proven doesn’t depend on DNS being secure. It verifies the identity of the server at the application layer, independent of how the DNS resolution occurred.

Canary signal validation

ZK Proven embeds cryptographic canary challenges in the connection handshake. These challenges require the server to prove it possesses secrets that are bound to the legitimate infrastructure — not just the domain name, but the actual cryptographic identity of the service.

A spoofed DNS record redirects you to the attacker’s server. That server can serve a cloned webpage, but it cannot respond to canary challenges because it doesn’t possess the ZK Proven service credentials. The canary fails. The score collapses. The connection dies before the page renders.

Network topology verification

DNS spoofing changes where your traffic goes, which changes the network path. The hop count, latency distribution, and routing characteristics of the connection to the attacker’s server are different from those of a connection to the legitimate server. ZK Proven’s topology proof catches these discrepancies.

Certificate chain independence

An attacker who controls DNS can potentially obtain a valid TLS certificate for the spoofed domain (via automated certificate authorities like Let’s Encrypt that verify domain control through DNS). ZK Proven’s verification is independent of the TLS certificate. It verifies the cryptographic identity of the service, not the domain certificate. A valid certificate on a malicious server still fails ZK Proven’s canary challenge.

Real-world DNS attacks

Sea Turtle (2019)

A nation-state campaign that compromised DNS registrars and DNS hosting providers to redirect traffic for government organizations and telecommunications companies across the Middle East and North Africa. Attackers obtained valid certificates for spoofed domains and intercepted email and VPN credentials.

DNSpionage (2018–2019)

A campaign targeting Lebanese and UAE government agencies by compromising DNS records to redirect traffic through attacker-controlled servers. The attackers used valid Let’s Encrypt certificates, making the spoofed connections appear fully legitimate in the browser.

MyEtherWallet hijack (2018)

Attackers used BGP hijacking to redirect traffic to Amazon’s Route 53 DNS servers, then poisoned DNS records for MyEtherWallet.com. Users who visited the site had their cryptocurrency wallets drained. The attack combined BGP and DNS manipulation — two infrastructure-layer attacks that no application-layer tool detected.

Stop trusting DNS

DNS is a 40-year-old protocol designed for a network where everyone was trusted. That network no longer exists. DNSSEC is the right fix but won’t reach meaningful adoption for years. DoH helps but isn’t comprehensive.

ZK Proven doesn’t wait for DNS to become secure. It verifies every connection at the cryptographic level, regardless of how it was routed. DNS can be spoofed, poisoned, hijacked — it doesn’t matter. The connection still has to prove itself.