What Is DNSSEC and Why Should You Care?
DNSSEC (Domain Name System Security Extensions) fixes this by adding cryptographic signatures to DNS responses. It doesn't encrypt anything; it proves that the records haven't been tampered with and that they came from the legitimate authoritative source.
The Problem DNSSEC Solves
Without DNSSEC, DNS is vulnerable to several attacks:
Cache poisoning. An attacker sends forged DNS responses to a resolver, injecting false records into its cache. Every user of that resolver then gets directed to the attacker's server. The Kaminsky attack in 2008 demonstrated that this was surprisingly easy to pull off.
Man-in-the-middle attacks. On compromised networks, an attacker can intercept DNS queries and substitute their own responses. Your browser shows the right domain name, but you're connected to a different server.
BGP hijacking. By manipulating internet routing, attackers can redirect DNS traffic through their own infrastructure. This has happened to major cryptocurrency exchanges and government websites.
DNSSEC doesn't prevent these interceptions; however, it makes forged responses detectable. If the signature doesn't verify, the resolver knows the response is bogus and discards it.
How DNSSEC Works
DNSSEC uses public-key cryptography to create a chain of trust from the root zone down to your domain.
1. The zone owner signs their records. Each DNS record set in a zone gets a cryptographic signature stored in an RRSIG record. The signing is done with a private key held by the zone operator.
2. The public key is published as a DNSKEY record. Resolvers use this key to verify the RRSIG signatures. There are typically two keys: a Zone Signing Key (ZSK) that signs the records, and a Key Signing Key (KSK) that signs the ZSK itself.
3. A hash of the KSK is published in the parent zone as a DS record. For example.com, the DS record lives in the .com zone. This is how the parent zone vouches for the child zone's key.
4. The chain continues up to the root. The .com zone is signed, and its DS record is in the root zone. The root zone is signed, and its keys are the trust anchors that resolvers have baked in.
When a DNSSEC-validating resolver receives a response, it walks this chain: verify the RRSIG with the DNSKEY, verify the DNSKEY with the parent's DS record, and repeat until you reach the root.
The Records Involved
DNSKEY: Contains the public keys used to sign the zone. Published in the zone itself.
RRSIG: Contains the actual signatures for each record set. One RRSIG per record type per name.
DS: Delegation Signer record. Published in the parent zone. Contains a hash of the child zone's KSK, forming the link in the chain of trust.
NSEC / NSEC3: Authenticated denial of existence. These records prove that a queried name or record type doesn't exist, preventing attackers from forging "no such domain" responses.
Why Adoption Is Still Incomplete
DNSSEC has been around since the mid-2000s but adoption remains partial. There are real reasons for this:
Operational complexity. Key management is nontrivial. Keys need to be rotated, and a botched rotation can take your domain offline. Signing errors don't just fail silently; they cause hard failures where resolvers refuse to return any answer.
Zone walking. NSEC records originally made it possible to enumerate every record in a zone. NSEC3 mitigated this with hashed names, but it added complexity.
No encryption. DNSSEC proves authenticity but doesn't provide privacy. DNS queries and responses are still in plaintext. This is sometimes confused with DNS-over-HTTPS or DNS-over-TLS, which address different problems.
Fragile failure modes. A misconfigured DNSSEC setup is worse than no DNSSEC at all. Without DNSSEC, a resolver returns the answer regardless. With broken DNSSEC, the resolver returns SERVFAIL and the domain becomes unreachable.
Despite these challenges, DNSSEC adoption is growing. Major registrars and DNS providers have automated key management, making it significantly easier to deploy than it was even five years ago.
Monitoring DNSSEC Records
Because DNSSEC failures are catastrophic (they don't degrade gracefully; they break hard), monitoring is especially important.
You want to know immediately if:
- A DNSKEY record changes unexpectedly (possible key compromise)
- A DS record in the parent zone doesn't match your DNSKEY (broken chain of trust)
- RRSIG records are approaching expiration (signatures have validity periods)
- DNSSEC is disabled entirely (DS record removed from parent)
Any of these will cause validating resolvers to reject your domain. The worst part: users on non-validating resolvers will see no problem, so your monitoring setup might not catch it unless it specifically tests DNSSEC validation.
Should You Enable DNSSEC?
If your registrar and DNS provider support automated DNSSEC management (and most major ones do now), the answer is yes. The operational burden has dropped significantly, and the protection against cache poisoning and response forgery is real.
If you're managing DNSSEC manually, proceed carefully. Test in a staging zone first, understand the key rollover process, and make sure your monitoring covers DNSSEC-specific failure modes.
Either way, if you already have DNSSEC enabled, monitor those records. Set up DNS monitoring to catch DNSSEC misconfigurations that could lock out a significant portion of your users.