DNSSEC Explained: How DNS Security Extensions Protect Against Cache Poisoning

In 2008, security researcher Dan Kaminsky discovered a critical vulnerability in the DNS protocol that enabled an attacker to inject fraudulent DNS records into a resolver's cache with alarming efficiency. The attack exploited the fact that DNS queries use UDP and include a 16-bit transaction ID for matching responses to requests. An attacker who could send a flood of forged DNS responses with guessed transaction IDs had a realistic probability of successfully poisoning a resolver's cache before the legitimate authoritative response arrived. A poisoned cache would direct users querying that resolver to attacker-controlled IP addresses for days — the duration of the injected record's TTL.

The practical impact of a successful cache poisoning attack is severe: users of the affected resolver would be transparently redirected to fraudulent websites even when typing the correct URL, enabling mass credential theft, malware distribution, and man-in-the-middle attacks at scale. Kaminsky coordinated a coordinated disclosure with DNS software vendors and major resolver operators, resulting in an emergency patch that added source port randomization to DNS queries, dramatically increasing the entropy an attacker must guess from 16 bits to approximately 32 bits. While this mitigated the immediate threat, the fundamental architectural vulnerability remained until DNSSEC adoption.

• The Kaminsky attack poisoned DNS resolver caches by flooding with forged responses containing guessed transaction IDs
• A successful attack redirected all users of the poisoned resolver to attacker-controlled IP addresses
• The 2008 emergency patch added source port randomization, increasing guessing difficulty significantly
• Source port randomization is mitigation, not a fix — DNSSEC provides the cryptographic solution
• Cache poisoning remains relevant today for resolvers without DNSSEC validation enabled

DNSSEC (DNS Security Extensions) adds cryptographic digital signatures to DNS records, allowing validating resolvers to verify that the response they received is authentic — it was genuinely produced by the authoritative nameserver for that zone and has not been modified in transit. DNSSEC specifically protects against cache poisoning attacks by making forged DNS responses cryptographically detectable: a forged response cannot carry a valid signature because the attacker does not possess the zone's private signing key. Any resolver with DNSSEC validation enabled will reject responses that fail signature verification.

It is equally important to understand what DNSSEC does not provide. DNSSEC does not encrypt DNS queries or responses — the content of DNS traffic remains visible to network observers. DNSSEC does not prevent distributed denial-of-service attacks against DNS infrastructure. DNSSEC does not prevent zone operators from publishing incorrect records — it only guarantees the authenticity of records that are actually published. DNSSEC validation also does not protect users whose resolvers do not perform validation, which is why widespread adoption of DNSSEC validation at major public resolvers like Cloudflare 1.1.1.1 and Google 8.8.8.8 is essential for the security guarantees to benefit ordinary users.

• DNSSEC provides: cryptographic proof that DNS responses are authentic and unmodified
• DNSSEC prevents: cache poisoning attacks by making forged responses cryptographically detectable
• DNSSEC does not provide: encryption of DNS queries — traffic content remains visible
• DNSSEC does not prevent: DDoS against DNS infrastructure or incorrect data published by zone operators
• Protection requires: both zone signing by domain operators AND validation enforcement by resolvers

DNSSEC introduces several new DNS record types that work together to provide cryptographic authentication. The RRSIG (Resource Record Signature) record contains the digital signature for a set of DNS records (called a resource record set). Every signed resource record set in a DNSSEC zone has a corresponding RRSIG record. The DNSKEY record publishes the public key used to verify RRSIG signatures, allowing resolvers to obtain the zone's public key directly from DNS and use it to verify each signature. Zones typically publish two DNSKEY records: the Zone Signing Key (ZSK) used for signing individual record sets, and the Key Signing Key (KSK) used for signing the DNSKEY record set itself.

The DS (Delegation Signer) record is published in the parent zone and contains a hash of the child zone's KSK. This record creates the cryptographic link between parent and child zones that forms the DNSSEC chain of trust. When a resolver validates a DNSSEC response, it retrieves the DS record from the parent zone and verifies that it matches the KSK in the child zone, confirming that the parent has explicitly vouched for the child zone's signing key. The NSEC (Next Secure) and NSEC3 (Next Secure 3) records provide authenticated denial of existence — they allow a signed response to cryptographically prove that a queried name does not exist in the zone, preventing an attacker from claiming a name resolves to their IP.

• RRSIG: the digital signature record that accompanies each signed resource record set in the zone
• DNSKEY: publishes the public keys (ZSK and KSK) used to verify signatures in the zone
• DS: published in the parent zone, contains a hash of the child zone's KSK to link the chain of trust
• NSEC/NSEC3: enable authenticated denial of existence, preventing forged NXDOMAIN responses
• NSEC3 uses hashed names to prevent zone walking — enumeration of all names in a signed zone

DNSSEC validation relies on a chain of cryptographic trust that begins at the DNS root zone and extends through each level of the domain hierarchy. The root zone is signed, and the root zone's trust anchor — the root KSK's public key — is pre-configured in validating resolver software. This root trust anchor is the single point of ultimate trust in the DNSSEC hierarchy. ICANN maintains the root zone signing keys and publishes them in multiple authoritative sources including the IANA Trust Anchor Repository. The root zone DS records for each signed TLD create the first links in the chain, extending trust downward through the hierarchy.

Each level in the chain vouches for the level below it through DS records. The root zone publishes DS records for signed TLDs like .com, .org, and .net. The TLD registry publishes DS records for each registered second-level domain that has been DNSSEC-enabled by its registrant. The registrant's zone is then signed with a ZSK, and the KSK hash is submitted to the registrar as a DS record. When a resolver validates a DNS response for example.com, it follows this chain: root trust anchor → root zone signs .com DS → .com zone signs example.com DS → example.com DNSKEY verifies example.com RRSIG.

• Root zone trust anchor: the root KSK public key pre-configured in validating resolver software
• Root zone signs DS records for all signed TLDs, establishing the first chain links
• TLD registry (e.g., Verisign for .com) publishes DS records for DNSSEC-enabled second-level domains
• Registrants submit their KSK hash to their registrar, which publishes it as a DS record in the TLD zone
• Validation fails if any link in the chain is broken or if signatures have expired

DNSSEC zones typically use two distinct key types for security reasons rooted in key management best practices. The Zone Signing Key (ZSK) is used to sign all resource record sets in the zone and is rotated frequently — often every 30 to 90 days. Because the ZSK is used for many signature operations, keeping it short-lived limits exposure if the key is compromised. The Key Signing Key (KSK) has a single function: it signs the DNSKEY record set that contains both the KSK and ZSK public keys. Because the KSK hash is published as a DS record in the parent zone (which requires coordinating with the registrar), KSKs are rotated less frequently — typically annually.

The KSK rollover at the DNS root zone in 2018 was a landmark event in internet security history. ICANN conducted the first-ever root KSK rollover, a process that required coordinating with resolver operators worldwide to ensure their trust anchors were updated before the old key was retired. Some resolvers that had not been updated to support RFC 5011 automatic trust anchor updates experienced validation failures during and after the rollover, causing DNS resolution failures for their users. The event highlighted the operational complexity of key management in DNSSEC and the importance of keeping resolver software current with trust anchor update support.

• ZSK (Zone Signing Key): signs all record sets in the zone, rotated frequently (every 30-90 days)
• KSK (Key Signing Key): signs only the DNSKEY record set, rotated annually due to registrar coordination requirement
• ZSK rollover: publish new ZSK DNSKEY first, then switch signing, then remove old ZSK after TTL expires
• KSK rollover: requires submitting new DS record to registrar before retiring old KSK
• RFC 5011 automates trust anchor updates for resolvers, enabling smooth KSK rollovers

Enabling DNSSEC for your domain requires two coordinated steps: signing your zone at your DNS hosting provider, and publishing the DS record at your domain registrar. Most major DNS hosting providers — Cloudflare, AWS Route 53, Google Cloud DNS — offer one-click DNSSEC signing that handles zone signing automatically and provides the DS record values to submit to your registrar. The registrar then publishes the DS record in the TLD zone, completing the chain of trust. The entire process typically takes less than an hour when both provider and registrar support DNSSEC through their management interfaces.

Despite its security benefits, DNSSEC has practical limitations that explain why adoption has been slower than many security professionals hoped. DNSSEC does not encrypt DNS queries — anyone on the network path can still read the domain names being queried. UDP packet fragmentation caused by the larger DNSSEC response sizes (due to signature data) can cause resolution failures on networks with poor MTU handling. Key rollover operations require careful coordination and can cause outages if mismanaged. For query privacy, DNS over HTTPS (DoH) and DNS over TLS (DoT) are complementary technologies that encrypt the query stream, addressing the privacy gap that DNSSEC leaves unresolved.

• Step 1: enable DNSSEC signing at your DNS hosting provider — most offer automated zone signing
• Step 2: submit the DS record to your domain registrar to complete the chain of trust to the TLD
• DNSSEC does not encrypt queries — use DoH or DoT for DNS query privacy in addition to DNSSEC
• Large DNSSEC responses can cause UDP fragmentation issues on some networks and firewalls
• Key rollover mistakes are a common cause of DNSSEC-related DNS outages — test rollovers carefully