DNS Cache Poisoning - Kaminsky-Angriff und DNS-Spoofing

DNS Cache Poisoning (DNS spoofing) is an attack in which fake DNS responses are injected into the cache of a recursive resolver. All users who use this resolver then receive incorrect IP addresses and are redirected to the attacker’s servers—without any visible warning in the browser (since the domain name appears correct).

Basic Principles of DNS and Vulnerabilities

Normal DNS Process

When a browser needs the IP address of a domain, the following sequence occurs: The browser queries the local resolver (e.g., 8.8.8.8); if there is no cache hit, the resolver queries the root nameserver, then the .de nameserver, and finally the authoritative nameserver for bank.de. The response (e.g., 203.0.113.1) is returned and cached by the resolver for the duration of the TTL (e.g., 300 seconds). The browser then opens the received IP address.

The Vulnerability

The resolver caches responses for future queries. If an attacker succeeds in injecting a forged response before the genuine one, the resolver caches the incorrect IP for the entire TTL duration. All users are then redirected to the attacker’s server for the duration of the TTL.

Classic Birthday Attack Approach (before Kaminsky)

The original attack was based on guessing the 16-bit transaction ID (65,536 possible values) of DNS. However, since a resolver queries only once per name, there were too few attempts for a viable attack—until Dan Kaminsky achieved the decisive breakthrough in 2008.

Kaminsky Attack (2008)

The Clever Idea (CVE-2008-1447)

Dan Kaminsky realized: Instead of waiting for the response for bank.de, one queries for random subdomains. The resolver has no cached responses for xyz123.bank.de and must query the nameserver for bank.de—which can be repeated as often as desired.

The attack in three steps

Step 1: The attacker sends requests for RANDOM.bank.de, MORE_RANDOM.bank.de, etc. Since these are random subdomains, there are no cache hits—the resolver must query the nameserver for bank.de.

Step 2: At the same time, the attacker sends thousands of forged responses—not only for the requested subdomain, but with a crucial addition in the ADDITIONAL section:

Fake response for: xyz123.bank.de = 198.51.100.99
ADDITIONAL section:     bank.de nameserver = ns.attacker.com
                        ns.attacker.com    = 198.51.100.99

Step 3: If a forged response is accepted, the resolver does not just cache the subdomain—it caches the entire nameserver for bank.de as the attacker’s server. All future bank.de queries are then redirected to ns.attacker.com.

Why is this so dangerous?

With a fast connection, millions of forged packets can be sent per second. The 16-bit transaction ID (65,536 values) combined with the known source port 53 results in only 65,536 possible combinations—in targeted attempts, the attack took about 30 seconds to succeed. Nearly all recursive resolvers worldwide were affected.

Patch (RFC 5452)

The countermeasure was query source port randomization: Instead of always using port 53 as the source port, a random port between 1024 and 65535 is selected. This results in 32-bit entropy (16-bit TxID × 16-bit port = 4 billion combinations). The attack now takes weeks instead of seconds.

Modern Attack Variants

Variant 1 - On-Path Attack (Classic MITM)

An attacker on the same network (Wi-Fi, compromised ISP) uses ARP spoofing on the gateway and positions themselves between the client and the resolver. Since they can see DNS requests, they know the transaction ID and respond immediately with a forged IP address—no guessing required.

Protection: DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) encrypt DNS traffic and prevent eavesdropping.

Variant 2 - SAD DNS (2020, CVE-2020-25705)

This side-channel attack exploits ICMP error messages: The attacker sends UDP packets to the resolver. ICMP "Port Unreachable" responses reveal whether a specific source port is being used by the resolver. This allows the source port to be determined in fewer than 30,000 attempts, making cache poisoning feasible again.

Patch: ICMP rate limiting and non-linear port randomization.

Variant 3 – Attacking the Resolver-to-Nameserver Channel

Classic DNS traffic between the resolver and nameserver is unencrypted. BGP hijacking can reroute nameserver queries. An attacker on the BGP path then responds as a spoofed nameserver.

Protection: DNSSEC provides protection through cryptographic signing of DNS responses.

Variant 4 - TTL Manipulation

The attacker injects a forged response with a high TTL (e.g., 86,400 seconds = 1 day). Even if the attack is detected, the damage persists for one day. Countermeasure: Set minimum TTLs after detection and flush caches.

DNSSEC as a Security Measure

How DNSSEC Works

DNSSEC adds cryptographic signatures to DNS responses:

1. The DNS zone is signed with a private key: Each A record receives an RRSIG record
2. The public key is published in the DNSKEY record
3. A chain of trust runs via DS records all the way to the root zone

The resolver checks the signature (RRSIG), the authenticity of the key (DS record in the parent nameserver), and NSEC/NSEC3 for the verifiable non-existence of records. A forged response without a valid signature results in SERVFAIL—cache poisoning is not possible.

Checking DNSSEC verification

dig +dnssec bank.de A
# RRSIG record in the response shows the signature
# "ad" flag (Authenticated Data) means: DNSSEC validated!

DNSSEC weaknesses

DNSSEC does not protect everything: Without NSEC3, zone enumeration is possible (use NSEC3 as protection). The content of DNS communication is not encrypted; only the origin is authenticated. Operation is complex due to key rollovers and signing processes. DNSSEC responses are significantly larger than normal DNS responses, which increases the amplification potential in DDoS attacks.

Implementation Status in Germany (2024)

Approximately 60% of .de domains have DS records (DNSSEC-signed). However, DNSSEC only provides protection if a validating resolver is also used. Google (8.8.8.8) and Cloudflare (1.1.1.1) validate DNSSEC. Many ISP resolvers, on the other hand, do not validate DNSSEC—those who rely on such resolvers have no DNSSEC protection.

Detection Methods

Monitoring DNS Responses

By comparing DNS responses from multiple independent resolvers, deviations can be detected that indicate cache poisoning:

# Query the IP for bank.de from 5 different resolvers:
for resolver in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222 4.2.2.1; do
    echo -n "$resolver: "
    dig @$resolver bank.de A +short
done
# Different IPs → Anomaly!

Passive DNS Monitoring

Security providers such as Farsight DNSDB and PassiveTotal collect historical DNS responses. If a domain’s IP suddenly changes, an alert is triggered. This approach also aids in post-incident forensics.

Client-side detection via DANE

DANE (DNS-based Authentication of Named Entities) anchors the TLS certificate hash in a TLSA record in the DNS. The browser checks whether the server certificate matches the TLSA record. In the case of a spoofed IP, an incorrect certificate would be presented, triggering a TLSA mismatch and a warning.

Mitigation Measures

For DNS Operators (Name Server Administrators)

• Implement DNSSEC (sign the zone)
• Schedule key rollover processes (typically: 5-year cycles)
• Set minimum TTLs when suspicious activity is detected (rapid recovery)
• Enable rate limiting on ICMP (SAD DNS Mitigation)

For resolver operators (organizations with their own DNS)

• Enable query source port randomization
• Enable DNSSEC validation (BIND: dnssec-validation auto;)
• Use DNS-over-TLS (DoT) for upstream queries
• 0x20 encoding: Randomize queries with random capitalization
• Enable response rate limiting (RRL)

For end users and businesses

• DNS-over-HTTPS (DoH): Encryption prevents on-path attacks. Can be enabled in Firefox and Chrome; Cloudflare (1.1.1.1) and Quad9 (9.9.9.9) support DoH.
• Use a validating DNSSEC resolver (not all ISP resolvers validate)
• Operate your own validating resolver with DNSSEC within the enterprise

For developers and the application layer

• HSTS and HSTS preloading: Enforce HTTPS even if the IP address is incorrect
• Certificate pinning: Anchor the certificate of the genuine server in the client
• DANE/TLSA records: Anchor the TLS certificate in DNS