DNSSEC: Securing DNS Against Cache Poisoning and Spoofing

The Domain Name System is often called the phonebook of the internet — it translates human-readable domain names into the IP addresses that computers use to route traffic. Originally designed for reliability rather than security, DNS has no built-in authentication mechanism. A resolver receiving a response has no way to verify that the answer came from the legitimate authoritative server and has not been modified in transit. This fundamental weakness has been exploited in attacks ranging from cache poisoning to BGP hijacking to nation-state DNS manipulation. DNSSEC — DNS Security Extensions — addresses this gap by adding cryptographic signatures to DNS data.

In 2008, security researcher Dan Kaminsky disclosed a devastating DNS cache poisoning technique that reduced the time required to poison a resolver's cache from years (with earlier techniques) to mere seconds. The attack exploited the fact that DNS queries use UDP and a 16-bit transaction ID, giving only 65,536 possible IDs. By flooding a resolver with forged responses while simultaneously triggering recursive queries, an attacker could race the legitimate response and inject a malicious answer into the resolver's cache — redirecting all users of that resolver to an attacker-controlled server for the poisoned domain.

Emergency patches added source port randomization (expanding the effective transaction ID space to about 32 bits), but this is a stopgap. DNSSEC is the proper solution: even if a resolver receives a forged response, it will fail the cryptographic signature verification and discard the malicious data.

DNSSEC uses public key cryptography to sign DNS records. Each DNS zone has one or more cryptographic key pairs. The zone owner signs their records with the private key, and validators use the corresponding public key to verify signatures. The trustworthiness of a zone's public key is established through a chain of trust anchored at the DNS root.

Key Record Types

• RRSIG (Resource Record Signature) — Contains the cryptographic signature for a specific RRset (a set of DNS records of the same type for the same name). Every signed RRset has a corresponding RRSIG record.
• DNSKEY — Contains the public key used to verify RRSIG records in the zone. A zone typically has two DNSKEY records: a Key Signing Key (KSK) and a Zone Signing Key (ZSK).
• DS (Delegation Signer) — A hash of a child zone's KSK, published in the parent zone. This is the cryptographic link between parent and child zones that forms the chain of trust.
• NSEC/NSEC3 (Next Secure) — Provides authenticated denial of existence. When a query for a nonexistent name is made, NSEC records cryptographically prove that the name does not exist in the zone, preventing attackers from injecting fake NXDOMAIN responses.

Zone Signing: KSK vs ZSK

DNSSEC separates zone signing duties into two key types for operational flexibility:

• Zone Signing Key (ZSK) — Signs all RRsets in the zone. Rotated frequently (monthly or quarterly) to limit exposure if compromised. The ZSK is signed by the KSK.
• Key Signing Key (KSK) — Signs the DNSKEY RRset (which includes the ZSK). The KSK public key's hash is published as a DS record in the parent zone. KSKs are rotated less frequently (annually) because each rotation requires coordination with the parent zone.

This two-key model allows ZSK rotation without requiring an update to the parent zone's DS record on every rotation — only KSK rotations require parent zone interaction.

Consider resolving the DNSSEC-signed domain example.com:

1. The DNS root zone is signed with the root KSK. Validating resolvers ship with the root's KSK hash hardcoded as a trust anchor.
2. The root zone's DS record contains a hash of the .com TLD's KSK. The root's RRSIG on this DS record proves its authenticity.
3. The .com zone's DS record contains a hash of example.com's KSK, signed by the .com ZSK.
4. The example.com zone's DNSKEY records include the ZSK and KSK, signed by the KSK (RRSIG over the DNSKEY RRset).
5. Each RRset in example.com (A records, MX records, etc.) is accompanied by an RRSIG signed by the ZSK.

A validating resolver follows this chain from the trusted root to verify every signature at each level. If any signature is invalid or missing, the resolver returns SERVFAIL — indicating that the response cannot be trusted — rather than returning potentially poisoned data.

NSEC records form a sorted chain of all existing names in a zone. When a query returns NXDOMAIN, the NSEC record proves that no name exists between the NSEC record's owner name and the next name in the chain. The limitation of NSEC is zone enumeration: by following the chain of NSEC records, anyone can enumerate every name in a signed zone.

NSEC3 addresses this by using hashed owner names instead of plaintext names. The hash function is iterable (applied multiple times), making offline brute-force of the zone's names computationally expensive. NSEC3 is the preferred choice for zones where zone enumeration is a privacy concern — effectively any publicly accessible domain.

Enabling DNSSEC requires action at both your DNS hosting provider (authoritative nameserver) and your domain registrar:

1. Sign the zone at your DNS provider — Major DNS providers (Cloudflare, Route53, NS1) offer one-click DNSSEC enablement. The provider generates KSK and ZSK pairs, signs all records, and publishes DNSKEY and RRSIG records automatically.
2. Publish the DS record at your registrar — After zone signing, your DNS provider will give you DS record data (the KSK hash). You must submit this to your domain registrar, which publishes it in the TLD zone (e.g., .com). Until this step is complete, the chain of trust is broken and validators will not validate your zone.
3. Verify the chain — Use DNSVIZ (dnsviz.net) or the ICANN DNSSEC debugger to visualize your chain of trust and identify any broken links.

When a validating resolver encounters a DNSSEC signature failure — expired signature, invalid signature, missing DS record, or chain of trust break — it returns SERVFAIL rather than the potentially compromised data. To users, this appears as an inability to resolve the domain. This is intentional: returning unverified data would defeat the purpose of DNSSEC. Operators of DNSSEC-signed zones must monitor for signature expiration closely — an expired RRSIG causes the same SERVFAIL from the user's perspective as a cache poisoning attack.

DNSSEC operational failures are common and can cause widespread outages. The most frequent mistake is failing to update the DS record at the registrar before or during a KSK rollover. If the old KSK is removed from the zone before the new DS record is published by the parent, validating resolvers will see a broken chain of trust and return SERVFAIL for all queries to the zone. The Swedish top-level domain .se experienced a multi-hour nationwide DNS outage in 2009 due to exactly this error.

Safe KSK rollover procedure: add the new KSK DNSKEY record alongside the old one, wait for the DS record TTL to expire, publish the new DS record at the registrar, wait for the parent zone TTL to expire, then remove the old KSK.

DANE (DNS-based Authentication of Named Entities) leverages DNSSEC to publish TLS certificate fingerprints in DNS, creating an alternative or supplement to the CA system. A TLSA record at _443._tcp.example.com specifies what certificate (or CA) a client should expect when connecting to port 443 on example.com. If the presented certificate does not match the TLSA record, the connection should be rejected. DANE is widely implemented for SMTP (securing email delivery between mail servers) but has limited browser support for HTTPS. Email providers like Postfix and Exim support SMTP DANE.

• dig +dnssec — Requests DNSSEC records in the response: dig +dnssec example.com A. Use dig +sigchase for signature chain following (where supported).
• dnsviz.net — Visual representation of the DNSSEC chain of trust. Invaluable for diagnosing broken chains.
• ICANN DNSSEC Debugger — dnssec-debugger.verisignlabs.com. Step-by-step validation trace.
• Zonemaster — Comprehensive DNS and DNSSEC zone health checker.
• delv (DNS lookup and validation) — Part of BIND, performs full DNSSEC validation locally: delv @8.8.8.8 example.com A +rtrace.

DNSSEC provides the cryptographic authentication layer that DNS was originally missing. By signing zone data and establishing a verifiable chain of trust from the DNS root to individual records, DNSSEC eliminates the effectiveness of cache poisoning attacks and DNS spoofing. The operational overhead — key management, monitoring signature expiration, coordinating KSK rollovers with registrars — is real but manageable with proper tooling and automation. Every public-facing domain should have DNSSEC enabled, and every organization should ensure their recursive resolvers perform DNSSEC validation. The combination of DNSSEC with DANE further strengthens the entire PKI ecosystem by providing a DNS-anchored alternative to CA-issued certificates for SMTP security.