DNS cache poisoning tricks a resolver into storing a fake DNS record, redirecting users to attacker-controlled infrastructure without touching the target server. DNSSEC was designed to fix this with cryptographic signing, but slow adoption, complex deployment, and operational fragility have left the majority of the internet still running without it.
Pithy Security | Cybersecurity FAQs – The Details
Question: How does DNS cache poisoning work and why hasn’t DNSSEC fixed it?
Asked by: Grok 2
Answered by: Mike D (MrComputerScience) from Pithy Security.
How Attackers Race the Clock to Inject Fake DNS Records
DNS resolvers cache responses from authoritative name servers to avoid re-querying them on every request. Cache poisoning exploits the window between when a resolver sends a query and when it receives a legitimate response. The attacker floods the resolver with forged responses, trying to win the race. Each DNS query includes a 16-bit transaction ID. If the attacker can guess or brute-force that ID and match the correct source port before the real response arrives, the resolver accepts the fake record and caches it for the duration of the TTL. Everyone who queries that resolver during that window gets the wrong answer. Dan Kaminsky’s 2008 disclosure showed this was practical at scale by exploiting predictable source port randomization, allowing poisoning within seconds. The underlying mechanic hasn’t fundamentally changed since then. Variants like the SAD DNS attack (2020) demonstrated the technique still works against modern resolvers by using side channels to narrow down port numbers.
Why DNSSEC Deployment Has Stalled Below Meaningful Thresholds
DNSSEC solves cache poisoning by having zone operators sign their DNS records with public-key cryptography. Resolvers that support validation reject any response that fails signature verification. The protocol works. The deployment doesn’t. As of 2024, ICANN data shows that while the root zone and most TLDs are signed, validation rates among resolvers remain inconsistent, and a significant share of second-level domains still aren’t signed at all. The reasons are operational, not technical. DNSSEC requires zone operators to manage cryptographic keys, handle key rollovers correctly, and maintain chain-of-trust from the root down to their domain. A misconfigured or expired DNSSEC signature doesn’t degrade gracefully. It breaks DNS resolution entirely for validating resolvers. Many organizations have watched a botched key rollover take down a domain and decided the risk of misconfiguration outweighs the security benefit. The 2019 ICANN KSK rollover caused measurable resolution failures for validating resolvers worldwide. That kind of operational cost has a chilling effect on adoption.
When DNS Security Controls Actually Limit Poisoning Risk
DNSSEC isn’t the only option. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the query channel, which prevents the eavesdropping that SAD DNS-style attacks rely on to narrow transaction IDs and port numbers. Cloudflare’s 1.1.1.1 and Google’s 8.8.8.8 both support DoH and DoT. Major browsers now implement DoH by default in several configurations. These don’t provide the same cryptographic integrity guarantees as DNSSEC, but they raise the practical difficulty of poisoning significantly for opportunistic attackers. For organizations running internal resolvers, source port randomization (RFC 5452), 0x20 encoding, and response rate limiting all add friction. CISA’s Trusted Internet Connections guidance recommends monitoring DNS traffic as a detection control when prevention is incomplete. Defense in depth matters here because no single control closes the gap.
What This Means For You
- Enable DNS over HTTPS or DNS over TLS on internal resolvers and endpoint clients to eliminate the cleartext channel that side-channel poisoning attacks require.
- Audit whether your public-facing domains are DNSSEC-signed and that key rollovers are automated and monitored to avoid outages from expired signatures.
- Monitor DNS query logs for anomalous TTL values, unexpected record changes, or high-volume query patterns that may indicate poisoning activity or reconnaissance.
- Verify that your upstream recursive resolvers perform DNSSEC validation, since an unsigned response from a non-validating resolver gives you no integrity guarantee even if your zone is signed.
Related Questions
Want Cybersecurity Breakdowns Like This Every Week?
Subscribe to Pithy Security (Free) → pithysecurity.substack.com