DNS Cache Poisoning: Understanding the Threat

DNS caching enables efficient and scalable name resolution—but it also creates a devastating attack surface. DNS cache poisoning exploits the trust relationship between resolvers and the records they cache, allowing attackers to inject fraudulent DNS data that can redirect traffic to malicious servers.

The consequences of successful cache poisoning are severe:

• Phishing attacks — Users attempting to reach bank.com are redirected to an attacker-controlled lookalike site
• Credential theft — Login pages for email, corporate access, or financial services capture user credentials
• Malware distribution — Software download sites redirect to malware-laden payloads
• Man-in-the-middle attacks — All traffic for a domain routes through attacker infrastructure
• Business disruption — Critical services become unreachable or redirect to competitors

Understanding cache poisoning attacks is essential for network security professionals, and the history of these attacks has driven fundamental changes in DNS protocol implementations.

DNS cache poisoning works by tricking a resolver into caching fraudulent DNS records. Once poisoned, the resolver returns attacker-controlled IP addresses to all clients querying for the targeted domain—until the poisoned record's TTL expires.

The Core Vulnerability:

DNS was designed in the 1980s for a trusted network environment. The protocol lacks built-in authentication—there's no cryptographic proof that a DNS response came from a legitimate authoritative server. Resolvers rely on matching responses to request parameters:

• Source IP matches expected authoritative server IP
• Query ID matches the original query
• Question section matches original query
• Response arrives on expected port

If an attacker can forge a response that matches these parameters and arrives before the legitimate response, the resolver accepts and caches the fraudulent data.

The Race Condition:

Cache poisoning is fundamentally a race condition:

1. Resolver sends query to authoritative server
2. Attacker floods resolver with forged responses
3. If a forged response matches query parameters before the legitimate response arrives, poisoning succeeds
4. Legitimate response arrives later and is ignored (resolver already has 'answer')

Before the Kaminsky attack (2008), cache poisoning required an open birthday attack window—the attacker needed to guess the query ID and respond before the legitimate server, which was challenging because:

1. The resolver must query for a domain (can't predict when)
2. The attacker must guess the 16-bit query ID correctly
3. The forged response must arrive before the legitimate response
4. If the attack fails, the domain is cached legitimately, and the attacker must wait for TTL expiry

The Birthday Problem:

Named after the mathematical birthday paradox, attackers can improve their odds by sending many forged responses with different query IDs simultaneously. The probability of matching any one of N guesses follows approximately:

P(match) = 1 - (1 - 1/65536)^N ≈ N/65536 for small N

With 1,000 attempts: ~1.5% success rate per attack window With 10,000 attempts: ~14% success rate per attack window With 65,536 attempts: ~63% success rate (but obvious network flood)

Classic Attack Limitations:

Historical Attack Example:

In 2005, security researchers demonstrated cache poisoning against older BIND versions:

1. Attacker sends email to victim organization, causing resolver to query attacker's domain
2. Attacker's DNS server intentionally delays response
3. Attacker floods resolver with forged responses for www.bank.com with random query IDs
4. If any forged response matches, resolver caches attacker's IP for bank.com
5. All organization users now reach attacker's server when visiting bank.com

This attack was dangerous but had a relatively low success probability per attempt due to the constraints above. The Kaminsky attack would change this dramatically.

In 2008, security researcher Dan Kaminsky discovered a devastating improvement to DNS cache poisoning that eliminated the TTL waiting period, allowing continuous attack attempts until success. This vulnerability affected virtually all DNS resolver implementations worldwide and triggered an emergency coordinated disclosure.

The Revolutionary Insight:

Kaminsky realized that instead of targeting www.bank.com directly (which gets cached on success OR failure), an attacker could target random, non-existent subdomains:

aaa123.bank.com
xyz456.bank.com  
rnd789.bank.com

Each random subdomain is a unique query that won't be in cache. The attacker can trigger unlimited queries without waiting for TTL expiry.

The Attack Mechanism:

1. Attacker triggers query for random1.bank.com (non-existent)
2. Attacker floods forged responses, attempting to win the race
3. But the forged response doesn't just answer for random1.bank.com—it includes a fraudulent authority section:

; Forged response (simplified)
; ANSWER SECTION:
random1.bank.com.    3600    IN    A    6.6.6.6

; AUTHORITY SECTION:
bank.com.            86400   IN    NS   ns1.evil.com.

; ADDITIONAL SECTION:  
ns1.evil.com.        86400   IN    A    6.6.6.6

4. If accepted, the resolver now believes ns1.evil.com is authoritative for bank.com
5. All future queries for bank.com and all subdomains go to the attacker

Why Random Subdomains Work:

NXDOMAIN responses for random1.bank.com are cached, but:

• random2.bank.com is a different query—cache miss
• random3.bank.com is a different query—cache miss
• Attacker can generate unlimited unique subdomains

Each new subdomain triggers a fresh query to the authoritative server, creating a new race window. The attacker can flood thousands of attempts per second until one succeeds.

The Emergency Response:

Kaminsky's disclosure triggered one of the largest coordinated security patches in Internet history:

• Disclosed privately to major vendors (July 2008)
• All major DNS software patched simultaneously
• Emergency patches for BIND, Windows DNS, Unbound, etc.
• CVE-2008-1447 assigned

The primary defense deployed against Kaminsky-style attacks was source port randomization. This dramatically increased the entropy an attacker must guess to successfully forge a response.

Before Port Randomization:

Resolvers sent all queries from a fixed source port (often UDP 53 or another predictable port). Attackers only needed to guess:

• 16-bit Query ID (65,536 possibilities)
• Known destination port

After Port Randomization:

Resolvers now use random source ports for each query, requiring attackers to guess:

• 16-bit Query ID (65,536 possibilities)
• 16-bit Source Port (65,536 possibilities, minus reserved ports → ~64,000)

Combined entropy: ~32 bits instead of 16 bits

Port randomization didn't eliminate the vulnerability—it made it computationally impractical on reasonable timescales.

Implementation Considerations:

1. NAT complications — Some NAT devices re-map source ports, potentially reducing entropy. Enterprise NATs should preserve DNS source port randomization.

2. Firewall rules — Firewalls must allow inbound responses on the randomized ephemeral ports, not just well-known DNS ports.

3. Load balancers — DNS load balancers must ensure randomized ports are preserved end-to-end.

4. IPv4 vs. IPv6 — Both address families need separate port randomization.

DNSSEC (Domain Name System Security Extensions) provides the definitive defense against cache poisoning by adding cryptographic authentication to DNS responses. With DNSSEC, resolvers can verify that DNS data genuinely came from the authoritative source and hasn't been tampered with.

How DNSSEC Prevents Poisoning:

1. Zone signing — Domain owners cryptographically sign their DNS records
2. Chain of trust — Each zone's public key is vouched for by its parent (up to root)
3. Validation — Resolvers verify signatures before caching any data
4. Forgery detection — Attacker's forged responses lack valid signatures → rejected

DNSSEC Record Types:

DNSSEC Validation Flow:

1. Resolver queries example.com A record
2. Authoritative responds with:
   - A record: example.com → 93.184.216.34
   - RRSIG: Signature over the A record
   - DNSKEY: example.com's public key

3. Resolver verifies:
   a. Is RRSIG valid for the A record using DNSKEY? ✓
   b. Is DNSKEY vouched by parent's DS record?
   
4. Resolver queries .com for DS record:
   - DS record: Hash of example.com DNSKEY
   - RRSIG: Signature from .com
   
5. Resolver continues chain to root:
   - Root DNSKEY is the trust anchor (pre-configured)
   
6. If entire chain validates → response authentic
   If any signature fails → reject response

Why Poisoning Fails with DNSSEC:

An attacker forging a response cannot:

• Sign with the domain's private key (only the legitimate owner has it)
• Create a valid DS record (only the parent zone can)
• Bypass the chain of trust (anchored at root)

The forged response will have missing or invalid signatures → resolver rejects it.

Beyond source port randomization and DNSSEC, multiple additional defenses strengthen DNS against cache poisoning:

Defense Layers:

Bailiwick Checking Explained:

The Kaminsky attack exploited resolvers accepting out-of-bailiwick glue records. Modern resolvers apply strict bailiwick rules:

Query: random123.bank.com A

Forged response includes:
  AUTHORITY: bank.com NS ns1.evil.com    ← In bailiwick (under bank.com)
  ADDITIONAL: ns1.evil.com A 6.6.6.6     ← OUT of bailiwick!

Modern resolver behavior:
  ✗ Rejects ns1.evil.com glue (not under bank.com bailiwick)
  ✓ Only accepts records logically related to query

DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT):

Encrypted DNS transport eliminates on-path spoofing:

These protocols prevent response spoofing between client and resolver by authenticating the resolver via TLS certificates. However, they don't protect the resolver-to-authoritative communication (DNSSEC still needed there).

Despite defensive measures, organizations must monitor for and respond to cache poisoning attempts. Detection and response capabilities are essential components of DNS security.

Indicators of Cache Poisoning:

Response Procedures:

Immediate Actions:

1. Cache flush — Clear poisoned entries immediately

   # BIND
   rndc flush
   rndc flushname bank.com
   
   # Unbound
   unbound-control flush bank.com
   unbound-control flush_zone bank.com
   
   # Windows DNS Server
   Clear-DnsServerCache
   

2. Isolate affected resolver — Redirect clients to alternate DNS until investigation completes

3. Block attack source — If attack source identified, block at firewall

Investigation:

1. Capture DNS traffic for forensic analysis
2. Compare cached data against authoritative source
3. Review resolver logs for anomalous query patterns
4. Check for DNSSEC validation status of affected domains

Long-term Remediation:

1. Enable DNSSEC validation if not already active
2. Verify source port randomization is functioning
3. Review network path for NAT devices that might reduce entropy
4. Consider DNS-over-TLS/HTTPS for client-resolver communication
5. Implement response rate limiting on authoritative servers