DNSSEC Explained: Chain of Trust, Record Types, and How to Validate Your Zone

What DNSSEC Solves: DNS Spoofing and Cache Poisoning

DNS was designed in the 1980s for a cooperative, relatively trusted network. It has no built-in mechanism for a resolver to verify that the answer it receives actually came from the authoritative nameserver — or that the answer hasn't been modified in transit.

Cache poisoning

DNS cache poisoning — also called DNS spoofing — exploits this by injecting forged DNS responses into a resolver's cache. Once poisoned, the resolver serves the attacker's fabricated record to every client that queries it until the record's TTL expires. A successful cache poisoning attack against a major ISP's resolver could redirect thousands of users to a fraudulent website, intercept email, or defeat HTTPS by directing traffic to a server the attacker controls (where they can present a fraudulently obtained or self-signed certificate).

The Kaminsky attack, disclosed in 2008, demonstrated that cache poisoning was practically exploitable against the majority of deployed resolvers using predictable transaction IDs. The industry responded with short-term mitigations (port randomisation), but these are probabilistic defences — DNSSEC is the cryptographic solution.

What DNSSEC does (and doesn't) protect

DNSSEC adds cryptographic signatures to DNS records. A DNSSEC-validating resolver can verify:

• The record set was genuinely published by the zone's authoritative nameserver (authentication of origin)
• The record set has not been modified in transit (data integrity)
• A record doesn't exist (authenticated denial of existence — via NSEC/NSEC3)

DNSSEC does not provide:

• Confidentiality — DNS queries and responses remain unencrypted (DNS-over-HTTPS/TLS addresses this separately)
• Protection against compromised authoritative nameservers — if the zone's signing key is stolen, the attacker can sign forged records
• Protection against domain hijacking at the registrar — DNSSEC doesn't prevent someone from transferring your domain

How the Chain of Trust Works

DNSSEC uses a hierarchical chain of trust that mirrors the DNS hierarchy itself: root zone → TLD zone → your zone. Each level in the hierarchy cryptographically vouches for the level below it.

DNSSEC CHAIN OF TRUST

[Root Zone]
  Signed by the Root KSK (Key Signing Key)
  Self-anchored — trust anchor pre-configured in resolvers
      ↓ DS record published by root zone
[TLD Zone — e.g., .com]
  Signed by .com's KSK
  Root zone's DS record authenticates .com's DNSKEY
      ↓ DS record published by .com zone
[Your Zone — e.g., example.com]
  Signed by example.com's KSK
  .com zone's DS record authenticates example.com's DNSKEY
      ↓ RRSIG records authenticate all other records
[Individual Records — A, MX, TXT, etc.]
  Each record set signed with example.com's ZSK (Zone Signing Key)

The chain begins with the root trust anchor — the root zone's public key, which is hardcoded into every DNSSEC-validating resolver. This is the single point from which all trust derives. When a resolver validates a DNSSEC-signed response for example.com, it follows the chain: root zone → .com zone → example.com zone, verifying each DS/DNSKEY relationship along the way.

Breaking any link in the chain — a missing DS record, an expired signature, a key rollover that wasn't coordinated with the parent zone — causes validation to fail for the entire zone. Resolvers configured to enforce DNSSEC validation (AD flag in resolver config) will return SERVFAIL rather than an unvalidated answer when the chain is broken.

⚠️ Warning: Broken DNSSEC is worse than no DNSSEC. A domain with no DNSSEC returns normal (unsigned) answers. A domain with broken DNSSEC returns SERVFAIL to every validating resolver, making the domain completely unreachable for users on DNSSEC-validating resolvers (including Google's 8.8.8.8 and Cloudflare's 1.1.1.1). Always verify the full chain before enabling DNSSEC, and verify again after any nameserver migration.

The Five DNSSEC Record Types Explained

DNSKEY — The zone's public keys

Every DNSSEC-signed zone publishes a DNSKEY record set containing at least two keys:

• KSK (Key Signing Key) — flags value 257. This key signs the DNSKEY record set itself. The KSK's hash is published as a DS record in the parent zone, anchoring the chain of trust. KSKs are typically rolled annually or less frequently.
• ZSK (Zone Signing Key) — flags value 256. This key signs all other record sets (A, MX, TXT, etc.). ZSKs are rolled more frequently (monthly or quarterly) to limit exposure if a key is compromised.

# Retrieve DNSKEY records for a zone
dig example.com DNSKEY

# Example output:
# example.com. 3600 IN DNSKEY 257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0dxCjjnopKl+GqJxpVXckHAeF...
#                                ^^^
#                                257 = KSK (Key Signing Key)
# example.com. 3600 IN DNSKEY 256 3 13 oJMRESz5E4gYzS/q6XDrvU1qMPYIjCWzJaOau8XNEZeqCYKD5ar0IRd...
#                                ^^^
#                                256 = ZSK (Zone Signing Key)

DS — Delegation Signer

The DS record is published in the parent zone (not your zone), and contains a hash of your zone's KSK. It's the link that connects your zone's DNSKEY to the chain of trust anchored in the root.

When you enable DNSSEC through your DNS registrar or provider, the crucial step is publishing the DS record in the parent TLD zone. Without this, your zone may be signed internally but the chain of trust is broken — validating resolvers will see an unsigned delegation and won't trust your signatures.

# Check DS record in the parent zone
dig example.com DS

# Example output:
# example.com. 3600 IN DS 12345 13 2 F1E4C...
#                          ^^^^^         ^  ^
#                          Key tag       |  Digest (SHA-256 hash of KSK)
#                                        Algorithm (13 = ECDSA P-256)

RRSIG — Resource Record Signature

Every record set in a DNSSEC-signed zone is accompanied by an RRSIG record containing the cryptographic signature over that record set. The RRSIG specifies which key signed the records, the signature validity period, and the signature value itself.

# Query with DNSSEC to see RRSIG records
dig +dnssec example.com A

# Example output:
# ;; ANSWER SECTION:
# example.com.  3600  IN  A      93.184.216.34
# example.com.  3600  IN  RRSIG  A 13 2 3600 (
#                 20260401000000  ← Signature expiry (UTC)
#                 20260301000000  ← Signature inception (UTC)
#                 54321           ← Key tag (identifies which ZSK signed this)
#                 example.com.
#                 <Base64 signature value> )

RRSIG records have validity periods — the signature expiry date in the RRSIG must not be in the past. Expired RRSIG records cause DNSSEC validation failure, even if the key itself is still valid. Zones with short RRSIG validity windows need frequent re-signing; most providers handle this automatically.

NSEC and NSEC3 — Authenticated Denial of Existence

A unique challenge in DNSSEC is how to prove that a record doesn't exist without returning an unsigned "not found" answer (which an attacker could fabricate). NSEC and NSEC3 solve this.

NSEC creates a sorted chain of all record names in the zone, with each NSEC record pointing to the next name. A query for a non-existent record returns the NSEC record that spans the gap where the queried name would have appeared, proving its absence. The drawback: an attacker (or anyone) can walk the NSEC chain to enumerate all records in the zone — a privacy concern for some operators.

NSEC3 addresses zone enumeration by hashing the record names before creating the chain. An observer can see the hashed values but not the plaintext record names. NSEC3 is the standard choice for zones where preventing enumeration matters.

How DNSSEC Validation Works Step-by-Step

When a DNSSEC-validating resolver receives a response for www.example.com A, it follows this chain:

1. Query example.com's nameservers for the A record. The response includes the A record and its RRSIG.

2. Retrieve example.com's DNSKEY record set. The resolver needs the ZSK (flags 256) to verify the RRSIG on the A record.

3. Verify the A record's RRSIG using the ZSK. The cryptographic signature validates that the A record was signed by the ZSK. If the signature is valid and unexpired, the A record's integrity is confirmed.

4. Verify the DNSKEY record set's RRSIG using the KSK. The DNSKEY set is itself signed by the KSK (flags 257). This confirms the ZSK is legitimate.

5. Retrieve the DS record from the .com zone. The DS record in the parent zone contains a hash of example.com's KSK.

6. Compare the DS hash against the KSK. If the hash of example.com's KSK matches the DS record published by .com, the KSK is authenticated by the parent zone.

7. Repeat up to the root. The .com zone's DNSKEY is authenticated by a DS record in the root zone. The root zone's KSK is the trust anchor — hardcoded in the resolver. Validation is complete.

If every link in this chain validates, the resolver sets the AD (Authentic Data) flag in the response, indicating the answer is DNSSEC-validated. If any link fails, the resolver returns SERVFAIL.

# Query with DNSSEC validation check — look for "ad" flag in response
dig +dnssec +adflag example.com A

# In the response flags, look for:
# ;; flags: qr rd ra ad; ...
#                      ^^
#                      "ad" = Authentic Data — DNSSEC validated successfully

# Test validation failure (broken DNSSEC example):
dig +dnssec dnssec-failed.org A
# Returns SERVFAIL if your resolver validates DNSSEC

How to Check If Your Zone Is Correctly Signed

Using dig

# Check if DNSKEY records exist for your zone
dig example.com DNSKEY +short

# Check if DS record exists in the parent zone
dig example.com DS +short

# Verify RRSIG records are present and unexpired
dig +dnssec example.com A | grep RRSIG

# Full DNSSEC chain validation trace
dig +dnssec +trace example.com A

# Check with a DNSSEC-validating resolver and look for the AD flag
dig +dnssec @8.8.8.8 example.com A
# Flags line should include "ad" if DNSSEC validates correctly

Using the DNSSEC Check tool

Our DNSSEC Check tool performs a full chain validation test for any domain — checking that DNSKEY records exist, DS records are published in the parent zone, RRSIG records are present and unexpired, and the chain validates from root to your zone. It surfaces the specific failure point for broken chains, making diagnosis faster than manual dig queries.

Checking RRSIG expiry

# Check RRSIG expiry dates for your A record
dig +dnssec example.com A | grep -A5 RRSIG

# The first date in the RRSIG is the expiry:
# 20260401000000 = April 1, 2026 UTC
# If this date is in the past, your signatures are expired

Most DNS providers that manage DNSSEC signing automatically re-sign records before RRSIG expiry. If you manage DNSSEC manually (using tools like BIND's dnssec-signzone or ldns-signzone), you must re-sign your zone before RRSIG records expire — typically every 30 days.

Common DNSSEC Errors and What They Mean

SERVFAIL on DNSSEC-validating resolvers

Cause: The DNSSEC chain is broken — a missing DS record, expired RRSIG, mismatched key, or key rollover that wasn't coordinated with the parent zone.

Diagnosis: Run dig +dnssec example.com A @8.8.8.8 and compare with dig +dnssec example.com A @your-authoritative-ns. If 8.8.8.8 returns SERVFAIL but your authoritative NS returns the record, the DNSSEC chain is broken. Use our DNSSEC Check to identify the specific failure point.

Fix: Identify the broken link (DS record in parent, DNSKEY in zone, or expired RRSIG) and correct it. If the chain is broken due to a failed key rollover, coordinate with your registrar to update the DS record, or temporarily disable DNSSEC and re-enable it cleanly.

DS record not published in parent zone

Cause: DNSSEC was enabled at the zone level (DNSKEY records exist) but the DS record was never submitted to the registrar for publication in the parent TLD zone.

Diagnosis: dig example.com DS returns empty (no DS record). dig example.com DNSKEY returns keys.

Fix: Submit the DS record (or the DNSKEY itself, which your registrar will hash to create the DS) through your domain registrar's control panel. This is the most common DNSSEC misconfiguration.

Nameserver migration with DNSSEC active

This is the highest-risk DNSSEC scenario and deserves specific attention.

⚠️ Warning: Migrating to a new DNS provider while DNSSEC is active requires careful coordination. The new provider will generate new signing keys — the DS record in the parent zone must be updated to reflect the new keys before the old nameservers stop serving. If the DS record still points to the old provider's keys after the nameserver switch, every validating resolver will return SERVFAIL for your domain.

The safe migration sequence:

1. Set up the zone at the new provider with DNSSEC disabled initially
2. Add all records, verify they match the old zone
3. Lower TTLs to 300 (see our DNS TTL guide)
4. Switch nameservers and wait for full propagation
5. Enable DNSSEC at the new provider and obtain the new DS record
6. Submit the new DS record to your registrar
7. After the new DS propagates (~24 hours), verify with dig example.com DS

For the full nameserver migration workflow, see our DNS Migration Without Downtime guide.

Expired RRSIG records

Cause: Zone re-signing was not performed before the RRSIG validity period expired. This is common with manually managed DNSSEC zones where automation isn't in place.

Diagnosis: dig +dnssec example.com A | grep RRSIG — the first timestamp in the RRSIG output is the expiry date. If it's in the past, signatures are expired.

Fix: Re-sign the zone immediately. Enable RRSIG auto-renewal if your DNS provider supports it. Set a monitoring alert for RRSIG expiry dates well before they expire — treat RRSIG expiry like certificate expiry.

Algorithm mismatch between DNSKEY and DS

Cause: The DS record in the parent zone was created with a different algorithm than the current DNSKEY. This can happen after a key algorithm upgrade (e.g., from RSA/SHA-256 to ECDSA P-256) where the DS record wasn't updated at the registrar.

Diagnosis: Compare the algorithm number in dig example.com DS against the algorithm in dig example.com DNSKEY. They must match.

Should You Enable DNSSEC? Pros, Cons, and Risks

Arguments for enabling DNSSEC

• Protection against cache poisoning — the primary threat DNSSEC was designed to address. Critical for domains where DNS manipulation could result in financial loss or user harm (banking, healthcare, email, e-commerce)
• Increasingly expected — regulators in some jurisdictions (DISA STIG for US government, certain EU frameworks) mandate DNSSEC for specific domain types
• Foundation for other security mechanisms — DANE (DNS-Based Authentication of Named Entities) and TLSA records depend on DNSSEC being active

Arguments against or cautions

• Operational complexity — key rollovers, DS record management, and RRSIG expiry monitoring add operational overhead that not all teams are equipped to manage
• Risk of SERVFAIL if misconfigured — broken DNSSEC silently breaks your domain for a significant fraction of internet users (those on validating resolvers). No DNSSEC at all is safer than broken DNSSEC
• Not a silver bullet — DNSSEC doesn't protect against registrar-level hijacking, compromised nameservers, or the vast majority of phishing attacks (which operate at the application layer)

Practical recommendation

Enable DNSSEC if: your DNS provider manages signing and key rollovers automatically, your registrar supports DS record management, and you have monitoring in place for DNSSEC chain health. Most major managed DNS providers (Cloudflare, Route 53, Google Cloud DNS) make this essentially automatic.

Defer or avoid DNSSEC if: you manage your own BIND/PowerDNS server without mature automation, you cannot monitor RRSIG expiry reliably, or you're planning a DNS provider migration in the near future (wait until after the migration is stable, then enable DNSSEC).

Frequently Asked Questions

Next Steps

Check your domain's current DNSSEC status with our DNSSEC Check — it validates the full chain from root to your zone and surfaces any specific failure points. Use DNS Lookup to inspect individual DNSKEY, DS, and RRSIG records, and NS Lookup to confirm your authoritative nameservers are consistently returning signed responses.

If you're planning a DNS provider migration and DNSSEC is active, read our DNS Migration Without Downtime guide for the coordination sequence that prevents the SERVFAIL risk during nameserver changes.

For understanding how DNS propagation interacts with DNSSEC — particularly during DS record publication and TTL expiry windows — see our How DNS Propagation Works guide.

Browse all DNS guides on DNSnexus for related topics.

Related Guides

• How DNS Propagation Works: TTL, Resolvers & the Global Timeline
• How to Migrate DNS to a New Host Without Downtime: A Complete Playbook
• DNS TTL Explained: What It Is, How to Set It, and When to Lower It