Summary
DNS cache poisoning is an attack technique that injects forged response records into recursive DNS resolvers, causing subsequent user queries to be redirected to attacker-controlled servers. The 2008 attack method disclosed by Dan Kaminsky revealed the systemic risk of this vulnerability, prompting ICANN and the internet engineering community to accelerate DNSSEC deployment. This page analyzes the attack from three dimensions: attack principles, technical evolution, and defense mechanisms.
Problem Definition
The core problem of DNS cache poisoning lies in how recursive DNS resolvers determine whether a received response genuinely originates from an authoritative DNS server rather than from an attacker. When a resolver cannot effectively verify the authenticity of the response source, an attacker can preempt the legitimate response with a forged one, injecting malicious IP addresses into the resolver’s cache. All downstream users of that resolver will then be persistently redirected for the duration of the cache’s TTL.
This page focuses on the technical principles and defense mechanisms of DNS cache poisoning, and does not cover DNS hijacking (modifying authoritative server records) or DNS filtering (ISP-level interception) as separate attack categories.
Background
DNS Resolution Process and Caching Mechanism
DNS resolution follows a recursive query model: a client sends a query to a recursive resolver, which iteratively queries root servers, top-level domain servers, and authoritative servers to obtain the target domain’s IP address. For efficiency, recursive resolvers cache query results for a period defined by the TTL (Time to Live). Within the TTL window, the resolver returns cached records directly without re-querying.
This caching mechanism is the performance cornerstone of the DNS system, but it also constitutes the attack surface for cache poisoning: once a forged record enters the cache, its effect persists until the TTL expires or the cache is flushed.
Transaction ID and Source Port: Original Defense
Early DNS protocol used a 16-bit Transaction ID and source port as response verification. The recursive resolver generates a random Transaction ID and records the source port when issuing a query, accepting only responses where both match. However, the 16-bit Transaction ID provides only 65,536 possibilities, and actual source port ranges are typically far smaller than the theoretical maximum, making brute-force guessing feasible.
Core Findings
The Breakthrough Significance of the Kaminsky Attack
The 2008 attack method publicly disclosed by Dan Kaminsky systematically exploited two properties of DNS caching: first, when the resolver has no cached record for a target domain, it issues a new query and awaits a response, opening a window for forged responses to compete; second, even if an attacker’s first forged response has a mismatched Transaction ID, the resolver simply discards it without flagging an attack, allowing the attacker to repeatedly send forged responses until hitting the correct ID.
Kaminsky’s key innovation was that the attacker forges not only the target subdomain’s record but also simultaneously injects forged NS records and A records for the authoritative server. Once the forged NS record is cached, the resolver will direct all subsequent queries for any subdomain under that domain to the attacker-controlled server, achieving persistent hijacking of the entire domain.
| Attack Stage | Technique | Impact Scope |
|---|---|---|
| Query trigger | Lure resolver to query non-existent subdomain | Single query window |
| Competing response | Flood forged Transaction ID responses | Success poisons cache |
| NS record injection | Forge authoritative NS and A records | Entire domain persistently compromised |
| TTL extension | Set long TTL to maintain cache | Prolongs attack duration |
Current Defense Mechanisms
-
DNSSEC: Verifies the authenticity and integrity of DNS responses through a digital signature chain (RRSIG records), eliminating the possibility of forged responses being accepted at the protocol layer. DNSSEC is the most fundamental cache poisoning defense, but its effectiveness depends on a complete trust chain from the root zone to the target domain.
-
Source Port Randomization: Expands the recursive resolver’s query source port from the fixed port 53 to a full-range random port, increasing the attacker’s guess space from approximately 65,536 to approximately 2^32, significantly raising the difficulty of brute-force attacks. As a transitional measure before DNSSEC deployment, it is now enabled by default in mainstream DNS software.
-
0x20 Mixed Case Encoding: Randomly converts some characters in the query domain name to uppercase, requiring the response to maintain the same case pattern, further increasing forgery difficulty. Proposed by ICANN DNS security researchers as a supplement to source port randomization.
-
DoH/DoT Encrypted Transport: DNS over HTTPS and DNS over TLS encrypt the query channel, preventing man-in-the-middle observation and tampering of DNS queries and responses, providing additional transport-layer protection.
Risks and Limitations
| Risk | Impact Level | Mitigation |
|---|---|---|
| DNSSEC trust chain breakage | High | Verify complete signature chain from root to target domain; encourage registrar DNSSEC enablement |
| Predictable resolver source ports | Medium | Ensure DNS software version supports full-range source port randomization |
| Long cache TTL expanding attack window | Medium | Set reasonable TTL; periodically refresh cache |
| Incomplete DoH/DoT deployment | Low | Prioritize enabling encrypted DNS queries at the network level |
| Attacker on same network path | High | Operate in trusted network environments; use trusted recursive resolvers |
Compliance Boundary
This page is limited to technical analysis and defense mechanism descriptions for DNS cache poisoning attacks. It does not constitute security audit advice or vulnerability disclosure. Domain holders should conduct security assessments in conjunction with their registrar’s DNSSEC support capabilities and the NIST SP 800-81 deployment guide. The attack principles described are for educational purposes only; any DNS attack against unauthorized systems violates applicable laws.
Related Entries
- DNS Security and Domain Governance Guide: Complete research framework for DNS security
- DNS Hijacking Attack Analysis and Defense: Attack techniques and defense measures for DNS hijacking
- DNSSEC In-Depth: DNSSEC protocol principles and deployment practices
- DNSSEC Check Guide: Tools and methods for verifying domain DNSSEC deployment status
- 2026 DNS Security and Domain Governance Report: Industry security posture and trend analysis
Frequently Asked Questions
How does DNS cache poisoning differ from DNS hijacking?
Cache poisoning targets the recursive resolver's cache, injecting forged records so subsequent queries return incorrect results. DNS hijacking typically involves directly modifying authoritative DNS server responses or altering resolution paths. The targets and techniques differ.
Can DNSSEC fully prevent cache poisoning?
DNSSEC verifies DNS response authenticity through digital signatures, effectively preventing forged responses from being cached. However, its effectiveness depends on a complete trust chain from the root zone to the target domain. Any broken link weakens the protection.