Dns Caching - Learning Module

Loading content...

0/228

DNS Cache Poisoning: Understanding the Threat

The Dark Side of DNS Caching

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.

What You Will Learn

By the end of this page, you will understand how DNS cache poisoning attacks work, the classic attack methodology, the revolutionary Kaminsky attack, modern defenses including source port randomization and DNSSEC, and best practices for protecting DNS infrastructure from poisoning.

Cache Poisoning Fundamentals

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:

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

Converting Mermaid diagram...

The 16-bit Query ID Problem

Classic DNS uses a 16-bit query ID (Transaction ID), providing only 65,536 possible values. An attacker who can send thousands of forged responses has a reasonable probability of guessing the correct ID. This limited entropy was the fundamental weakness enabling early cache poisoning attacks.

Classic Cache Poisoning Attack

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:

The resolver must query for a domain (can't predict when)
The attacker must guess the 16-bit query ID correctly
The forged response must arrive before the legitimate response
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:

Classic Attack Constraints

•Must trigger query — Attacker needs to cause the resolver to query the target domain (e.g., by sending email with lookup triggers or accessing attacker-controlled webpage)
•Single attempt window — Once the resolver receives any response, the window closes until TTL expiry
•TTL blocking — High TTL on target domain means long wait between attack attempts
•Detection risk — Large-scale query ID flooding may trigger intrusion detection

Historical Attack Example:

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

Attacker sends email to victim organization, causing resolver to query attacker's domain
Attacker's DNS server intentionally delays response
Attacker floods resolver with forged responses for www.bank.com with random query IDs
If any forged response matches, resolver caches attacker's IP for bank.com
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.

UDP Makes Spoofing Trivial

DNS primarily uses UDP, which has no handshake or connection state. Attackers can trivially forge the source IP address in UDP packets. Unlike TCP, where connection establishment proves the sender can receive responses at the claimed IP, UDP accepts packets at face value—making DNS response spoofing straightforward for on-path or blind attackers.

The Kaminsky Attack (2008)

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:

Attacker triggers query for random1.bank.com (non-existent)
Attacker floods forged responses, attempting to win the race
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

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

Kaminsky Attack vs. Classic Poisoning
Characteristic	Classic Attack	Kaminsky Attack
Target	Specific domain record (A record)	NS delegation (authority)
Attack attempts	One per TTL period	Unlimited (new random subdomain each time)
Time to success	Days/weeks (probabilistic)	Minutes to hours
Impact scope	Single domain record	Entire zone (all subdomains)
TTL dependency	Must wait for TTL expiry between attempts	No waiting needed

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

Days to Compromise

Kaminsky estimated a competent attacker could poison a resolver's cache for any target domain within 10 seconds under optimal conditions, or reliably within hours under realistic conditions. The attack was practical, devastating, and affected nearly every DNS resolver on the Internet.

Defense: Source Port Randomization

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

Entropy	Possibilities	Brute Force (1000 guesses/sec)
16 bits	65,536	~65 seconds
32 bits	~4 billion	~50 days

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

check-port-randomization.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# Test if your resolver uses source port randomization
# Using DNS-OARC's entropy test
 
# Method 1: Use dig to query the entropy test server
dig +short porttest.dns-oarc.net TXT
 
# Sample output (randomized ports):
# "y.y.y.y is GREAT: 26 queries in 3.3 seconds from 26 ports with std dev 17746"
 
# Sample output (poor randomization):
# "x.x.x.x is POOR: 26 queries in 2.8 seconds from 1 ports with std dev 0"
 
# Method 2: Check BIND configuration
# In named.conf, ensure:
# options {
#     use-v4-udp-ports { range 1024 65535; };
#     use-v6-udp-ports { range 1024 65535; };
# };
 
# Method 3: Observe resolver traffic (requires network capture)
tcpdump -nn -c 100 'udp port 53' | grep -oP 'src port \K[0-9]+'
# Should show varying port numbers, not a single repeated value

Implementation Considerations:

NAT complications — Some NAT devices re-map source ports, potentially reducing entropy. Enterprise NATs should preserve DNS source port randomization.
Firewall rules — Firewalls must allow inbound responses on the randomized ephemeral ports, not just well-known DNS ports.
Load balancers — DNS load balancers must ensure randomized ports are preserved end-to-end.
IPv4 vs. IPv6 — Both address families need separate port randomization.

Port Randomization is Necessary but Not Sufficient

Source port randomization raised the bar for attackers but didn't solve the fundamental problem—DNS responses still lack cryptographic authentication. A determined attacker with sufficient resources (botnets, ISP-level access) could still attempt billions of guesses. DNSSEC provides the cryptographic solution.

Defense: DNSSEC Validation

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:

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

DNSSEC Record Types:

DNSSEC Record Types
Record Type	Purpose	Contains
DNSKEY	Zone's public key	Public key used to verify RRSIGs
RRSIG	Signature over records	Cryptographic signature for a record set
DS	Delegation Signer	Hash of child's DNSKEY (links parent to child)
NSEC/NSEC3	Authenticated denial	Proves non-existence of names/records

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.

DNSSEC Adoption Status

As of 2024, DNSSEC validation is enabled by default on major public resolvers (Google, Cloudflare, Quad9). Zone signing adoption varies: government domains (.gov) have high adoption; commercial domains lag. Full DNSSEC protection requires both signed zones AND validating resolvers.

Additional Defenses and Mitigations

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

Defense Layers:

Additional Cache Poisoning Defenses

•0x20 Encoding (DNS Cookies) — Randomize case of domain name letters in queries (wWw.ExAmPlE.cOm); authoritative must echo exact case back. Adds ~15-20 bits of entropy. Attacker must guess the random case pattern.
•DNS Cookies (RFC 7873) — Cryptographic cookies exchanged between resolver and authoritative; validates response authenticity without full DNSSEC overhead.
•Response Rate Limiting (RRL) — Authoritative servers limit identical responses per time window; makes flooding attacks slower and detectable.
•TCP for DNS — Using TCP eliminates UDP spoofing (TCP handshake proves sender). Increasing adoption with DNS-over-TLS and DNS-over-HTTPS.
•Bailiwick Checking — Resolvers only accept additional/authority records within the queried domain's bailiwick; prevents injecting records for unrelated domains.

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:

Protocol	Transport	Port	Authentication
Traditional DNS	UDP/TCP	53	None (spoofable)
DNS-over-TLS (DoT)	TLS	853	Server certificate
DNS-over-HTTPS (DoH)	HTTPS	443	Server certificate
DNS-over-QUIC (DoQ)	QUIC	853	Server certificate

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).

Defense in Depth

Modern DNS security employs multiple overlapping defenses: port randomization + 0x20 encoding for query entropy, DNSSEC for cryptographic authenticity, DNS cookies for ongoing session validation, and encrypted transport for client-resolver security. Each layer addresses different attack vectors.

Detecting and Responding to Poisoning

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:

Warning Signs of Poisoning

•Unusual query volumes — Flood of queries for random subdomains of a target domain (Kaminsky attack signature)
•Response anomalies — DNS responses from unexpected IP addresses or with unexpected TTLs
•DNSSEC validation failures — Increased SERVFAIL responses indicating signature validation problems
•User reports — Multiple users reporting certificate warnings or incorrect sites for well-known domains
•Cache inconsistencies — Different resolver instances showing different IP addresses for same domain

Response Procedures:

Immediate Actions:

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

Isolate affected resolver — Redirect clients to alternate DNS until investigation completes
Block attack source — If attack source identified, block at firewall

Investigation:

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

Long-term Remediation:

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

Silent Poisoning Risk

Sophisticated attackers may poison caches with records that redirect to functional-looking sites that slowly harvest credentials or inject malware. Without active monitoring and certificate validation (HTTPS), poisoning may go undetected for extended periods. User-facing certificate warnings are often the first visible sign.

Summary: Protecting DNS from Cache Poisoning

DNS cache poisoning exploits the trust relationship in DNS caching to redirect traffic to attacker-controlled servers. Understanding these attacks and defenses is essential for secure DNS operations.

Key takeaways from this page:

Key Takeaways

•DNS lacks built-in authentication — Traditional DNS has no cryptographic verification that responses are legitimate, enabling forgery attacks.
•Cache poisoning is a race condition — Attackers attempt to inject forged responses before legitimate responses arrive, exploiting matching query IDs and ports.
•The Kaminsky attack eliminated TTL waiting — By targeting non-existent subdomains, attackers can make unlimited attempts without waiting for cache expiry.
•Source port randomization is the primary defense — Adding ~16 bits of port entropy to 16 bits of query ID entropy makes brute-force impractical.
•DNSSEC provides cryptographic authentication — Zone signing and validation create a chain of trust that definitively prevents response forgery.
•Defense in depth is essential — Multiple layers (port randomization, 0x20 encoding, DNSSEC, DNS cookies, encrypted transport) address different attack vectors.
•Bailiwick checking prevents cross-domain poisoning — Modern resolvers only accept records within the queried domain's scope.
•Monitor for poisoning indicators — Unusual query patterns, validation failures, and cache inconsistencies may signal an attack.

What's next:

We've explored the threats to DNS caching. Next, we'll examine DNS Cache Management—the operational practices for maintaining healthy caches, tuning cache parameters, implementing cache policies, and managing cache lifecycles in enterprise environments.

Page Complete

You now understand how DNS cache poisoning attacks work, from classic approaches to the devastating Kaminsky attack, and the multi-layered defenses that protect modern DNS infrastructure. Next, we'll explore operational cache management practices.