DNS Cache Poisoning: What It Is and How to Stop It

DNS cache poisoning is one of the oldest and most dangerous attacks on internet infrastructure, and it remains relevant today because it requires no malware on the victim's machine, leaves no obvious footprint in browser history, and can redirect thousands of users simultaneously. When it works, your users type a legitimate domain name, their browser resolves it to an IP address an attacker controls, and they land on a fake site — all without a single warning. Understanding exactly how this happens and how to shut it down is not optional for anyone running DNS infrastructure or even a small business network.

What DNS Cache Poisoning Actually Is

Every recursive DNS resolver — the server that does the heavy lifting of finding an IP address on behalf of your device — caches answers for a period of time defined by the record's TTL (Time to Live). That caching is what makes DNS fast. Without it, every single DNS query would have to travel all the way up to a root nameserver and back, which would be brutally slow at scale.

Cache poisoning exploits this caching mechanism. An attacker tricks a recursive resolver into storing a forged DNS record for a legitimate domain. Once that bad record is in the cache, every client that asks the resolver for that domain gets directed to the attacker's IP — for the entire duration of the TTL. No individual machine needs to be compromised. The attack happens at the resolver level.

The forged record could point a banking domain to a phishing server, redirect a software update domain to one that serves malware, or reroute email to an attacker-controlled mail server. The scope is limited only by the attacker's creativity.

Why DNS Cache Poisoning Happens: The Technical Root Cause

The original DNS protocol, designed in the early 1980s, has no built-in authentication. A resolver sends a UDP query with a transaction ID — originally just a 16-bit number — and accepts whatever response arrives first that matches that ID and the source port. That is a tiny attack surface: only 65,536 possible transaction IDs.

In the classic Kaminsky Attack (disclosed in 2008 by security researcher Dan Kaminsky), an attacker queries a resolver for a non-existent subdomain of a target domain repeatedly, then floods the resolver with forged responses containing not just the answer for that fake subdomain, but also a poisoned authority section that overwrites the NS record for the entire parent domain. The attacker races to get the forged response accepted before the real nameserver replies. With only 65,536 transaction IDs to guess and a fast internet connection, the odds are surprisingly good.

Modern resolvers added source port randomization, which raised the effective entropy to around 32 bits (65,536 ports × 65,536 IDs), making blind guessing impractical — but not impossible, especially if the attacker can observe network traffic or exploit on-path positions. The deeper fix is DNSSEC, which we will cover shortly.

Who Is at Risk

Any environment that relies on an unprotected recursive resolver is potentially at risk. That includes:

• Corporate networks running their own internal resolvers (Windows DNS Server, BIND, Unbound) without DNSSEC validation enabled.
• ISP-provided resolvers that have not deployed source port randomization or DNSSEC validation — still common in some regions.
• Home routers acting as DNS proxies that forward queries to upstream resolvers. If your router is running an outdated firmware, it may strip the randomization added by the upstream resolver.
• Cloud-hosted resolvers with misconfigured security groups that expose port 53 to the public internet, enabling amplification and spoofing attacks.
• Any domain that has not signed its zone with DNSSEC, because even if the resolver validates, there is nothing to validate against.

Step-by-Step: How to Defend Against DNS Cache Poisoning

Step 1: Enable DNSSEC Validation on Your Resolver

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records. A validating resolver checks these signatures against a chain of trust anchored at the root zone. A poisoned record, by definition, cannot carry a valid signature, so it gets rejected before it ever enters the cache.

If you run BIND, open named.conf and confirm the following is present in your options block:

Restart BIND after making changes:

If you run Unbound, check that your unbound.conf contains:

Then initialize the root trust anchor if it does not exist:

For Windows Server DNS, DNSSEC validation is disabled by default on recursive resolvers. Enable it in PowerShell:

Step 2: Sign Your Own Zones with DNSSEC

Enabling validation on your resolver only helps if the zones being queried are actually signed. If you control a domain, you need to sign it. Most modern registrars and DNS hosting providers support this with a few clicks.

For Cloudflare DNS: Go to your domain in the Cloudflare dashboard, navigate to DNS, then DNSSEC, and click Enable DNSSEC. Cloudflare generates the keys, signs the zone, and shows you a DS record to add at your registrar.

For AWS Route 53: In the Route 53 console, select your hosted zone, click Enable DNSSEC Signing, and follow the prompts to create a KSK (Key Signing Key) using AWS KMS. Then add the DS record to your registrar.

If you manage your own authoritative nameserver with BIND, use the following to generate keys and sign the zone:

Then publish the DS record shown in the .key file at your registrar. Without that DS record, the chain of trust is broken and validation will fail.

Step 3: Verify Source Port Randomization

Even before DNSSEC validation is fully deployed across all zones, source port randomization is your first line of statistical defense. Test whether your resolver is using it:

A response of GREAT means randomization is working correctly. GOOD means partial randomization. POOR means the resolver is predictable and vulnerable to blind injection attacks. If you get POOR, update your resolver software immediately — any BIND version below 9.5.1, Unbound below 1.4.0, or PowerDNS Recursor below 3.1.7.2 predates source port randomization support.

Step 4: Use DNS over TLS or DNS over HTTPS for Client Queries

Even a correctly configured resolver can be attacked if traffic between clients and the resolver travels in plaintext over an untrusted network. DNS over TLS (DoT, port 853) and DNS over HTTPS (DoH, port 443) encrypt the query in transit, preventing on-path attackers from injecting forged responses before they reach the resolver.

Configure DoT on a Linux client using systemd-resolved:

For Windows 11, go to Settings, Network and Internet, your active connection, DNS server assignment, Edit, set to Manual, enter your preferred DNS IP (e.g., 1.1.1.1), and switch DNS over HTTPS to On.

For enterprise environments, deploy a local DoT/DoH proxy such as dnsdist or a Pi-hole instance with DoH upstream, so all clients on the network benefit without per-device configuration.

Step 5: Harden Your Resolver's Network Exposure

An open recursive resolver — one that answers queries from the entire internet — is a liability and an amplification vector. Lock it down:

• In BIND, use an allow-recursion ACL to restrict recursive queries to your own subnets only.
• Block inbound port 53 at your firewall for all external IP ranges that should not be querying your resolver.
• Enable Response Rate Limiting (RRL) to mitigate amplification abuse.

Step 6: Monitor Cache Integrity

Set up periodic monitoring to detect anomalies in DNS resolution results for critical domains. Compare results from your internal resolver against a known-good public resolver like 8.8.8.8 or 1.1.1.1. A discrepancy is a red flag.

A simple bash script for this purpose:

Run this as a cron job every five minutes for any business-critical domains.

How to Verify Your Defenses Are Working

After implementing the steps above, run these checks:

1. Use the OARC port randomization test (shown above) to confirm your resolver scores GREAT.
2. Use the Verisign DNSSEC Analyzer at dnssec-analyzer.verisignlabs.com to verify your zone's DNSSEC chain of trust is intact from root to your domain.
3. Check your resolver logs for SERVFAIL responses with a dnssec reason — these indicate the resolver is correctly rejecting invalid signatures.
4. Query a DNSSEC-signed domain and confirm the AD (Authenticated Data) flag is set in the response:

You can also use our DNS Lookup tool to inspect the full DNS response for any domain, including DNSSEC-related records like RRSIG, DNSKEY, and DS records, to verify the chain is properly configured without needing to install command-line tools.

What About Public DNS Resolvers

If managing your own resolver is not feasible, switching to a public resolver that already enforces DNSSEC validation and supports DoT/DoH is a solid mitigation for end users and small businesses:

• Cloudflare 1.1.1.1 — validates DNSSEC, supports DoT and DoH, fastest average latency globally.
• Google 8.8.8.8 — validates DNSSEC, supports DoT and DoH.
• Quad9 9.9.9.9 — validates DNSSEC and also blocks known malicious domains at the resolver level, a useful extra layer.

Switching your router to use one of these upstream resolvers protects every device on your network. For most home routers, log in at 192.168.1.1 or 192.168.0.1 (TP-Link users may also try tplinkwifi.net; Netgear users try routerlogin.net; ASUS users try asusrouter.com), find the WAN or Internet DNS settings, and replace the ISP-provided resolver IPs with 9.9.9.9 and 149.112.112.112.

How to Prevent Future Exposure

Defense against DNS cache poisoning is not a one-time fix. It requires ongoing hygiene:

• Keep resolver software updated. BIND, Unbound, and PowerDNS release security patches regularly — subscribe to their announcement mailing lists.
• Rotate DNSSEC keys on a schedule (annually for ZSKs, every two to five years for KSKs) and automate the rollover process to avoid chain-of-trust breaks.
• Review TTL values. Extremely high TTLs mean a poisoned record stays in cache longer. Extremely low TTLs increase query volume and exposure. A TTL of 300 to 3600 seconds is a reasonable balance for most records.
• Audit any third-party DNS providers or CDN services you rely on to confirm they have DNSSEC signing enabled for your zones.
• Conduct periodic DNS audits for all domains your organization owns, including subdomains, to ensure no zones have been delegated to resolvers you no longer control.

The Bottom Line

DNS cache poisoning is a threat that has been known for decades, and the industry has developed solid, well-tested countermeasures: DNSSEC validation, zone signing, source port randomization, and encrypted transport. The problem is that these defenses require deliberate configuration — none of them are enabled by default in most environments. A resolver that accepts unsigned DNS responses over plaintext UDP is trusting every answer it receives, and that trust is exactly what attackers exploit. Implementing the steps above closes the gap and makes your DNS infrastructure genuinely difficult to manipulate.