DNS Spoofing and Cache Poisoning Explained

Every time you type a web address, your device asks the Domain Name System (DNS) to translate a name like bank.example into an IP address. DNS was designed in the 1980s for a friendlier internet: by default, its answers are neither encrypted nor signed. If an attacker can get a forged answer accepted, every connection that follows goes exactly where the attacker wants.

What is DNS Spoofing?

DNS spoofing is any attack that makes a device accept a false DNS answer. DNS cache poisoning is the most dangerous form: instead of fooling one device, the attacker plants a forged record in a DNS resolver's cache. Every user of that resolver then receives the bad answer until the record expires, which can be hours or days depending on the time-to-live (TTL) the attacker sets.

The Attack Mechanism

There are several ways to get a forged answer accepted:

Spoofing on the local network: An attacker who is already on-path, for example after an ARP spoofing attack, can see DNS queries and reply before the real server does. The victim accepts the first answer that matches.
Rogue DNS servers: Devices learn which DNS server to use from DHCP. After a DHCP starvation attack, a rogue DHCP server can hand out the attacker's DNS server to every new device on the network. Compromised home routers are used the same way.
Off-path cache poisoning: An attacker who cannot see the traffic floods a resolver with forged responses, racing the real answer. To be accepted, a forgery has to match the query's 16-bit transaction ID and the resolver's source port.
Hijacking the source: Rather than forging answers, attackers take over the registrar or DNS hosting account for a domain and change its records directly.

Real-World Impact

The Kaminsky attack (2008): Security researcher Dan Kaminsky showed that by asking a resolver for many random, non-existent subdomains, an attacker could trigger lookup after lookup and keep racing forged replies until one won, then poison the records for the entire domain. With a fixed source port, only the 16-bit transaction ID stood in the way. Vendors shipped a coordinated fix: randomising the source port of every query.
MyEtherWallet (2018): Attackers used a BGP hijack to take over IP addresses belonging to Amazon's Route 53 DNS service, answered DNS queries for myetherwallet.com and sent users to a fake site that stole cryptocurrency.
Sea Turtle (2019): Researchers at Cisco Talos reported a state-sponsored campaign that hijacked DNS records of government and infrastructure organisations by compromising registrars and DNS providers, then used the redirected traffic to harvest credentials.
SAD DNS (2020): Researchers found a side channel that let attackers guess a resolver's randomised source port, reviving off-path cache poisoning against many popular resolvers until they were patched.

Prevention Strategies

Protecting against DNS spoofing needs defences at several layers:

DNSSEC validation: DNSSEC adds cryptographic signatures to DNS records. A validating resolver rejects any answer whose signature doesn't check out, which defeats forged records. It proves authenticity but does not encrypt anything, and it only protects domains that are signed.
Hardened resolvers: Keep resolver software patched, make sure source port randomisation is on, restrict recursion to your own clients and never run an open resolver on the internet.
Encrypted DNS: DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the path between a device and its resolver, so an attacker on the local network can no longer read or forge the answers. They don't help if the resolver itself is poisoned, so combine them with DNSSEC.
HTTPS everywhere, with HSTS: Even if DNS is spoofed, an attacker can't present a valid certificate for your domain, so browsers show a warning instead of silently loading the fake site. HSTS stops users from clicking through.
Lock down the source: Protect registrar and DNS hosting accounts with strong, unique passwords and multi-factor authentication, and use registry lock for important domains.
Secure the local network: DHCP snooping and Dynamic ARP Inspection on managed switches block the rogue DHCP servers and ARP spoofing that local DNS attacks depend on.

Example: A Validating Resolver with Unbound

Unbound is a popular open-source resolver for home labs and businesses. These settings turn on DNSSEC validation and some extra hardening:

server:
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    harden-dnssec-stripped: yes
    use-caps-for-id: yes
    val-clean-additional: yes

You can check that validation works with dig. Query a signed domain through your resolver and look for the ad (authenticated data) flag in the response header:

dig cloudflare.com +dnssec

Key Terms

DNS (Domain Name System): The system that translates human-readable domain names into IP addresses. Resolver: The DNS server your device asks; it looks up answers on your behalf and caches them. Cache Poisoning: Inserting a forged record into a resolver's cache so that all of its users receive the false answer. TTL (Time to Live): How long a DNS record may be cached before it has to be looked up again. DNSSEC (DNS Security Extensions): Signatures on DNS records that let resolvers verify an answer really came from the domain's owner. DoH / DoT: DNS over HTTPS and DNS over TLS, which encrypt DNS traffic between a device and its resolver.

DNS quietly decides where every connection goes. Validating its answers with DNSSEC, encrypting them on the way and protecting the accounts that control your domains turns the internet's phonebook back into something you can trust.