Preventing DNS Spoofing and Cache Poisoning

Every visit to a website, every email delivery and most API calls begin with a DNS lookup. If an attacker can make that lookup return the wrong address, the user ends up talking to the wrong server while the address bar still shows the correct domain name. That is the essence of DNS spoofing, and its most damaging form, cache poisoning, can affect thousands of users at once. This guide explains how these attacks work at a conceptual level, why a discovery in 2008 changed the way resolvers are built, and which defences domain owners and network operators should have in place today. The focus is entirely defensive: understanding the weakness well enough to close it.

What DNS spoofing and cache poisoning actually mean

DNS spoofing is a broad term for any situation in which a client receives a DNS answer that did not come from the legitimate source. It can happen on a compromised Wi-Fi network, through malware that edits a local hosts file, or through a rogue DNS server handed out by a malicious router.

Cache poisoning is a specific and more serious variant. Recursive resolvers, such as those run by internet providers, companies and public DNS services, cache answers to save time. If an attacker convinces a resolver to accept and cache a forged record, the resolver will serve that false record to every client that asks for the name until its time to live (TTL) expires. One successful injection can therefore redirect a large population of users without touching any of their devices.

The underlying reason is historical. Classic DNS runs mostly over UDP, a connectionless protocol, and the original design assumed that the network was reasonably trustworthy. A resolver accepted the first plausible response that matched its outstanding question. There was no built-in way to prove where an answer came from.

How a resolver decides to trust an answer

When a resolver sends a query to an authoritative server, it later receives a response and has to decide whether that response belongs to the question it asked. Traditionally it checks a handful of fields:

• The question section must match the name and type that were asked.
• The transaction ID, a 16-bit number, must match the ID used in the query.
• The response must arrive from the IP address and port the query was sent to, and back to the source port the resolver used.

If all of these match, the response is accepted. An off-path attacker who cannot see the real traffic has to guess these values. Before 2008 many resolvers used a fixed or predictable source port, leaving only the 16-bit transaction ID, which is just 65,536 possibilities. That is a small search space for a determined attacker who can send many packets quickly.

The Kaminsky attack of 2008 and why it mattered

Weaknesses in transaction IDs were known well before 2008, but defenders took some comfort from caching itself: once a resolver had a valid answer cached, an attacker had to wait for the TTL to expire before trying again. In 2008 the security researcher Dan Kaminsky showed that this comfort was misplaced.

His insight, described here only at a high level, was that an attacker did not need to race the resolver for the exact name they wanted to hijack. By triggering lookups for many different non-existent subdomains, they could generate a fresh race every time, and a forged response could carry additional records that pointed the whole domain at attacker-controlled name servers. The long-TTL protection disappeared, and a predictable resolver could be poisoned in a short time.

The disclosure led to an unusually coordinated, multi-vendor patch release in July 2008. The fix that shipped everywhere was not a redesign of DNS but a way to make guessing far harder: source port randomisation. Kaminsky and others were clear that this was a mitigation, and that the long-term answer was cryptographic validation through DNSSEC.

Layered mitigations inside the resolver

Modern resolvers combine several techniques that each add unpredictability to a query, so an off-path attacker has much more to guess.

Source port randomisation

Instead of sending every query from the same UDP port, the resolver picks a random source port for each query from a large range. Combined with the random 16-bit transaction ID, this multiplies the number of values an attacker must guess by tens of thousands. It turned a practical attack into a much more expensive one, which is why it became the standard response in 2008. Note that some NAT devices and firewalls rewrite source ports in predictable ways, which can quietly undo this protection, so it is worth checking the behaviour of the network edge.

0x20 encoding (case randomisation)

DNS names are case-insensitive, but most authoritative servers copy the question exactly as received into their answer. The technique known as 0x20 encoding, named after the bit that differs between upper and lower case ASCII letters, randomises the capitalisation of the query name, for example wWw.ExAmPlE.cOm. The resolver then checks that the response preserves the same pattern. Each letter adds roughly one bit of entropy. It is less effective for short names and must tolerate servers that do not preserve case, so resolvers typically apply it with fallbacks.

Other resolver checks

• Bailiwick checking: discarding records in a response that fall outside the zone the server is authoritative for.
• Hardened glue handling: refusing to let additional-section records overwrite trusted cached data.
• Rate limiting and unwanted-reply thresholds: noticing floods of mismatched responses and reacting, for example by retrying over TCP.
• QNAME minimisation (RFC 7816, later RFC 9156): sending only the necessary part of the name to each server, which reduces data leakage.

The table below summarises what each control protects and where its limits lie.

DNSSEC: proving that an answer is genuine

All the mitigations above make forgery harder, but none of them lets the resolver prove that a record is authentic. DNSSEC does. The zone owner signs its records with private keys, publishes the matching public keys as DNSKEY records, and the parent zone publishes a DS record that vouches for the child key. A validating resolver follows this chain of trust from the root down to the record it received. If the signature does not verify, the resolver returns a failure (SERVFAIL) instead of a possibly forged answer.

For domain owners, this means that the most effective step you can personally take against cache poisoning of your own names is to sign your zone and make sure the DS record is published at the registry through your registrar. We cover the setup and its pitfalls in detail in why DNSSEC is essential for domain security. Two practical warnings: key rollovers must be planned, and if you change DNS providers you must update or remove the DS record, otherwise validating resolvers will treat your domain as broken.

Encrypted DNS: DoT and DoH

DNSSEC authenticates data, but it does not hide it, and the hop between a laptop or phone and its resolver is often the most exposed part of the journey, especially on public Wi-Fi. Two standards encrypt that hop:

• DNS over TLS (DoT), defined in RFC 7858, wraps DNS in TLS on a dedicated port, 853. It is easy for network operators to identify and manage.
• DNS over HTTPS (DoH), defined in RFC 8484, carries DNS messages inside HTTPS on port 443, so it blends in with ordinary web traffic and is widely supported by browsers and operating systems.

Both prevent an on-path attacker from reading or silently altering responses between client and resolver, provided the client authenticates the resolver certificate. Neither replaces DNSSEC: if the resolver itself has been poisoned, an encrypted channel will faithfully deliver the poisoned answer. The strongest posture combines encrypted transport to a validating resolver.

Hardening your own resolvers

If you run recursive resolvers for an office, a data centre or customers, a few configuration choices make a significant difference:

1. Do not run an open resolver. Restrict recursion to your own networks. Open resolvers are abused for amplification and give attackers an easy target.
2. Separate authoritative and recursive roles. A server that answers for your zones should not also perform recursion for the internet.
3. Enable DNSSEC validation and keep the root trust anchor updated automatically.
4. Keep software current. Resolver projects regularly publish fixes for cache-related weaknesses.
5. Limit cache TTLs to sensible maximums and enable protections against unwanted replies.

A minimal example for the Unbound resolver might look like this:

server:
    interface: 10.0.0.53
    access-control: 10.0.0.0/8 allow
    access-control: 0.0.0.0/0 refuse
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    harden-glue: yes
    harden-dnssec-stripped: yes
    harden-referral-path: yes
    use-caps-for-id: yes
    qname-minimisation: yes
    unwanted-reply-threshold: 10000000
    cache-max-ttl: 86400

The equivalent in BIND would restrict recursion with an access control list and enable validation:

acl internal { 10.0.0.0/8; 127.0.0.1; };
options {
    recursion yes;
    allow-recursion { internal; };
    allow-query-cache { internal; };
    dnssec-validation auto;
};

Always test changes in a staging environment, since strict hardening options can expose misconfigured third-party zones.

Monitoring and checks for domain owners

Most organisations do not run resolvers for the public, but they do own domains whose answers can be targeted. A practical routine includes:

• Checking that your name servers and registrar records have not changed unexpectedly. A quick lookup with the TLDix WHOIS and RDAP tool shows the current name servers, status codes and DNSSEC flag for a domain.
• Verifying signatures with dig +dnssec example.com A and confirming that a validating resolver returns the ad flag.
• Enabling registrar lock and two-factor authentication, because hijacking a registrar account achieves the same result as poisoning with far less effort.
• Keeping domains, SSL certificates and DNS hosting from expiring. An expired domain can be re-registered by someone else, which is effectively a permanent spoof. Tracking renewal dates in your TLDix domain panel removes that risk.

Bringing it together

Cache poisoning exploits the fact that classic DNS trusted the first plausible answer. Randomised ports, transaction IDs and 0x20 encoding make guessing expensive; resolver hardening removes easy shortcuts; encrypted transports protect the client link; and DNSSEC finally lets resolvers verify that data is genuine. No single control is enough, but together they make DNS dramatically safer. For domain owners, the short list is clear: sign your zones, protect your registrar account, monitor your records and never let critical names expire.