The Domain Name System is often called the “phone book of the internet” — it translates human-readable domain names into IP addresses. But when attackers compromise this system, every device trusting that DNS server can be silently redirected to malicious infrastructure. DNS hijacking and cache poisoning are among the most dangerous network-level attacks because they operate invisibly below most users’ radar.
What Is DNS Hijacking?
DNS hijacking occurs when an attacker intercepts or manipulates DNS queries so that domain lookups resolve to attacker-controlled IP addresses rather than legitimate servers. There are several distinct types:
Router DNS Hijacking
Home and small-office routers store a DNS server setting that all connected devices use by default. Attackers compromise routers through default credentials, unpatched firmware vulnerabilities, or cross-site request forgery (CSRF) attacks launched from malicious web pages. Once inside, they change the DNS server field from a legitimate resolver (8.8.8.8, 1.1.1.1) to one they control.
Every device on that network then receives DNS responses from the attacker’s server. Victims browsing to their bank’s domain might land on a pixel-perfect phishing clone without a single warning.
ISP-Level DNS Hijacking
Some internet service providers engage in a practice called NXDOMAIN hijacking — when you query a domain that doesn’t exist, instead of returning a proper “not found” response, they redirect you to a search or advertising page. While not always malicious, this same technique can be weaponized by ISPs in authoritarian countries or by malicious actors who compromise ISP infrastructure.
Malware-Based DNS Hijacking
Malware families like DNSChanger (dismantled by the FBI in 2011 but with lasting successors) modify the DNS server settings stored in a host’s network configuration. On Windows, these are found in the network adapter settings. On Linux/macOS, the resolver settings in /etc/resolv.conf or system network manager configurations are targeted.
The Kaminsky Attack: Cache Poisoning at Scale
The most technically elegant DNS attack ever discovered was published by Dan Kaminsky in 2008. It exploits a fundamental weakness in how DNS caching resolvers work.
How DNS caching works: When your resolver queries an authoritative server for bank.com, it caches the response for the record’s Time-To-Live (TTL) duration. Any subsequent query for bank.com is answered from cache — no network round trip needed.
The birthday paradox angle: DNS uses 16-bit transaction IDs (0–65535) to match responses to queries. Before Kaminsky’s work, the assumed attack required sending roughly 65,536 forged responses. The birthday paradox tells us the actual collision probability is much higher — with roughly 300 forged responses, there’s a 50% chance of hitting the correct ID if source ports are also predictable.
Kaminsky’s insight: Rather than poisoning the record for bank.com directly (which would only work while the attacker raced the legitimate response), he queried a unique random subdomain like random1234.bank.com. This subdomain certainly wasn’t cached, so the resolver had to go out and ask. Kaminsky then flooded thousands of forged responses — each claiming to be the authoritative answer, and each including a glue record that said “by the way, the authoritative nameserver for all of bank.com is at IP 1.2.3.4” (the attacker’s server).
If any forged response arrived before the legitimate one and the transaction ID matched, the resolver cached the attacker’s nameserver as authoritative for the entire bank.com domain. Every subsequent lookup for that domain — for all users of that resolver — would be answered by the attacker.
Detecting DNS Hijacking
You can manually verify DNS responses by comparing what your configured resolver returns against what the domain’s authoritative nameserver says:
# What your current resolver says
dig A example.com
# What the authoritative nameserver says (bypass your resolver)
dig A example.com @$(dig NS example.com +short | head -1)
# Check who your system is actually using as a resolver
cat /etc/resolv.conf # Linux/macOS
ipconfig /all | findstr DNS # WindowsIf the IP addresses differ, your resolver may be compromised or poisoned. Also check your router’s DNS settings against what your ISP officially provides.
DNSSEC: The Cryptographic Defense
DNS Security Extensions (DNSSEC) adds cryptographic signatures to DNS records. Each DNS zone has a public/private key pair. The zone owner signs their records with the private key; resolvers verify signatures using the published public key — which is itself anchored back to the DNS root zone in a chain of trust.
| Layer | What It Signs |
|---|---|
| Root Zone | Signs TLD keys (.com, .org) |
| TLD Zone | Signs registrar-delegated keys |
| Domain Zone | Signs individual A, MX, CNAME records |
With DNSSEC, a forged DNS response would fail signature verification. The resolver would refuse the record rather than cache it.
Limitations: DNSSEC protects data integrity and authenticity but does not encrypt DNS traffic. Queries and responses are still visible in plaintext on the network. For privacy, use DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT).
HTTPS and HSTS as a Safety Net
Even when DNS is hijacked, HTTPS provides a second line of defense. If you navigate to https://bank.com and the attacker redirects you to their server, their server must present a valid TLS certificate for bank.com. Obtaining a fraudulent certificate from a trusted CA is extremely difficult (though not impossible — see DigiNotar in 2011).
HTTP Strict Transport Security (HSTS) goes further. When a site sends the Strict-Transport-Security header, browsers refuse to connect to that domain over plain HTTP for the specified duration — even if DNS points to an attacker’s IP. The HSTS Preload List (maintained by Chrome) bakes in HTTPS requirements for major domains before you ever visit them.
Real-World Incidents
- 2018 — BGP Hijacking of Amazon Route 53: Attackers used BGP route injection to hijack DNS traffic for MyEtherWallet. For two hours, users were redirected to a phishing server. BGP hijacking can redirect entire DNS resolver networks, not just individual records.
- 2019 — Sea Turtle Campaign: Nation-state actors hijacked DNS for government and telecoms domains across the Middle East and North Africa by compromising registrars and ccTLD operators — demonstrating ISP and registry-level hijacking at scale.
- DNSChanger (2007–2011): Infected 4 million computers globally, redirecting victims to ads and blocking security update sites.
Defenses at a Glance
| Threat | Defense |
|---|---|
| Router hijacking | Change default credentials, update firmware, use DoH on devices |
| Cache poisoning | Enable DNSSEC on your domain; use a resolver that validates DNSSEC |
| Malware-based | Endpoint protection, verify /etc/resolv.conf and adapter settings |
| ISP-level | Use encrypted DNS (DoH/DoT) via Cloudflare 1.1.1.1 or NextDNS |
| Phishing via hijack | HSTS preloading, certificate pinning |
DNS is foundational infrastructure. Attacks against it are attacks against every service that depends on it. Verifying your resolver settings, enabling DNSSEC on domains you control, and enforcing HTTPS with HSTS are the minimum baseline for any security-conscious organization or individual.