The Problem DNSSEC Solves: DNS Cache Poisoning
Traditional DNS has no mechanism to verify whether a response is genuine. A recursive resolver simply trusts whatever answer arrives first. In 2008, security researcher Dan Kaminsky demonstrated a practical attack — now known as the Kaminsky attack — that could poison a resolver's cache in under a minute by flooding it with forged responses before the legitimate answer arrived. A poisoned resolver returns a fake IP address for a domain, silently redirecting all users querying that resolver to an attacker-controlled server — a perfect platform for phishing, credential harvesting, or malware distribution.
DNSSEC was designed to make this class of attack impossible. By adding digital signatures to DNS records, it allows any validating resolver to detect and reject forged responses, even if an attacker manages to inject them into the resolution path.
How DNSSEC Works: Keys and Signatures
DNSSEC uses asymmetric cryptography — the same mathematical foundation as HTTPS certificates. Each DNS zone generates a public/private key pair. The private key is kept secret by the zone operator and is used to cryptographically sign every set of DNS records in the zone. The public key is published in the DNS zone itself as a DNSKEY record, allowing anyone to verify the signatures.
When a validating resolver receives a DNS response for a DNSSEC-signed zone, it also retrieves the corresponding RRSIG record — a digital signature over the resource record set. It then uses the zone's published DNSKEY to verify that the signature is valid. If the records were altered in transit, the signature check fails and the resolver rejects the answer.
The Chain of Trust
Verifying a zone's DNSKEY requires trusting that the DNSKEY itself has not been forged. DNSSEC solves this with a chain of trust rooted at the DNS root zone. Each parent zone publishes a DS (Delegation Signer) record for each child zone it delegates to. The DS record contains a cryptographic hash of the child zone's DNSKEY. A resolver that trusts the parent zone's signature on the DS record can derive trust in the child zone's DNSKEY.
This chain extends from the root zone — whose trust anchor (a hash of the root DNSKEY) is hardcoded into all validating resolvers — down through TLD zones like .com and .org, and into individual second-level domains like example.com. Every link in the chain is verified before the final answer is accepted. If any link is broken — a missing DS record, an expired signature, or a key mismatch — the entire chain fails.
NSEC and NSEC3: Authenticated Denial of Existence
DNSSEC must also handle the case where a queried name does not exist. Without authentication, an attacker could forge an NXDOMAIN response for a domain that does exist, effectively suppressing legitimate DNS answers. DNSSEC addresses this with NSEC (Next Secure) records, which prove that no names exist between two adjacent signed names in the zone. A resolver that receives an NSEC record with a valid RRSIG can cryptographically verify that a queried name truly does not exist.
NSEC has a drawback: by chaining all signed names together, it allows zone enumeration — an attacker can walk the entire zone to discover all domain names. NSEC3 was introduced to mitigate this by using hashed names in the chain instead of plaintext names, making enumeration significantly harder without eliminating it entirely.
What Happens When DNSSEC Validation Fails
When a validating resolver detects an invalid signature — whether due to tampering, a misconfigured zone, or an expired key — it returns a SERVFAIL response. From the user's perspective, the domain simply does not resolve. This is a deliberate design choice: DNSSEC treats an unverifiable answer as more dangerous than no answer at all, so it refuses to pass along a result it cannot authenticate.
DNSSEC failures are sometimes caused by misconfiguration rather than attacks — for example, a zone operator who rotates their signing key without properly updating the DS record in the parent zone. This can cause valid domains to appear broken for users on validating resolvers. Zone operators must carefully manage key rollovers to avoid breaking the chain of trust.
DNSSEC vs DNS over HTTPS: Complementary, Not Competing
DNSSEC and DNS over HTTPS (DoH) are often confused because both are described as "secure DNS," but they address entirely different threats. DNSSEC verifies the content of DNS responses — it ensures the record you received is the one the zone operator published. DoH encrypts the transport — it prevents anyone on the network path from observing which domains you are querying.
DNSSEC does not hide your queries from network observers. DoH does not verify that the responses you receive are genuine. Using both together provides both transport privacy and content integrity, which is why modern DNS deployments increasingly support and encourage both simultaneously.
How to Check if a Domain Uses DNSSEC
The most direct method is the dig command. Run dig DS example.com to query the parent zone for a Delegation Signer record — a non-empty answer confirms DNSSEC is enabled. Run dig +dnssec A example.com to see RRSIG records returned alongside the A record. Online, Verisign's DNSSEC Analyzer at dnssec-analyzer.verisignlabs.com provides a visual chain-of-trust diagram for any domain. You can also use delv (DNSSEC Lookaside Validation), which is included in modern BIND distributions and performs full DNSSEC validation with detailed output.
DNSSEC Record Types
| Record Type | Purpose | What It Contains | Where It Lives |
|---|---|---|---|
| RRSIG | Cryptographic signature over a resource record set | Signature, algorithm, key tag, expiration, signer name | Same zone as the signed records |
| DNSKEY | Public key for the zone | Public key data, flags (ZSK or KSK), algorithm | The zone apex (e.g., example.com) |
| DS | Delegation signer — links parent to child zone | Hash of child zone's DNSKEY, algorithm, key tag | Parent zone (e.g., .com zone) |
| NSEC | Proves a name does not exist (plaintext chain) | Next signed name, record types that do exist | Same zone as signed records |
| NSEC3 | Proves a name does not exist (hashed chain) | Hash of next name, hash algorithm, iterations, salt | Same zone as signed records |
Frequently Asked Questions
What does DNSSEC protect against?
DNSSEC protects against DNS cache poisoning — attacks where a malicious resolver or man-in-the-middle injects forged DNS responses that redirect users to attacker-controlled IP addresses. By verifying cryptographic signatures on every DNS record, a validating resolver can detect any modification to a legitimate record and refuse to use the forged answer. DNSSEC does not protect against local DNS hijacking (malware changing your device's DNS settings) or router hijacking.
Does DNSSEC encrypt DNS queries?
No. DNSSEC does not encrypt DNS queries or responses. It adds digital signatures to DNS records so that the content of a response can be verified as authentic, but the queries and responses are still transmitted in plaintext over the network. Anyone on the network path can still observe which domains you are querying. For query privacy, use DNS over HTTPS (DoH) or DNS over TLS (DoT), which encrypt the transport. DNSSEC and DoH/DoT are complementary — DNSSEC validates content integrity, while DoH/DoT provides transport privacy.
What is a DNSKEY record?
A DNSKEY record contains the public cryptographic key for a DNS zone. Zone operators generate a public/private key pair; the private key signs all records in the zone, and the public key is published as a DNSKEY record so that validating resolvers can verify those signatures. Zones typically publish two DNSKEY records: a Zone Signing Key (ZSK) used to sign individual resource records, and a Key Signing Key (KSK) used to sign the ZSK, which is also represented by a DS record in the parent zone to establish the chain of trust.
What happens if DNSSEC validation fails?
When a validating resolver detects that a DNSSEC signature is invalid — because the record was tampered with, the signature has expired, or the key does not match — it returns a SERVFAIL response to the client instead of the potentially forged answer. From the user's perspective, the domain appears to not resolve at all. This is intentional: DNSSEC treats a failed validation as more dangerous than a failed lookup, so it refuses to return an unverified answer.
How do I check if a domain uses DNSSEC?
Use the dig command to query for DS records in the parent zone: run dig DS example.com to see if a delegation signer record exists. A non-empty answer means the domain is DNSSEC-signed. You can also run dig +dnssec example.com to see RRSIG records returned alongside A records. Online tools like Verisign's DNSSEC Analyzer (dnssec-analyzer.verisignlabs.com) provide a visual chain-of-trust breakdown for any domain, showing which parts of the chain are signed and whether they validate correctly.
Is DNSSEC the same as DNS over HTTPS?
No, they solve different problems. DNSSEC adds cryptographic signatures to DNS records to verify that responses have not been tampered with — it protects data integrity but does not encrypt the queries. DNS over HTTPS (DoH) encrypts the DNS query and response inside an HTTPS connection to protect them from eavesdropping on the network path — it provides transport privacy but does not verify record authenticity. Using both together provides both integrity verification and transport privacy, which is why they are considered complementary rather than competing technologies.