DNSSEC Explained: How DNS Security Extensions Protect Your Domain
DNS was designed without built-in authentication, making it vulnerable to spoofing and cache poisoning attacks. DNSSEC adds cryptographic signatures to DNS responses, allowing resolvers to verify that the data they receive is authentic and unmodified. This guide explains how DNSSEC works, the chain of trust model, and how to enable it for your domain.
What Is DNSSEC?
DNSSEC (Domain Name System Security Extensions) is a suite of specifications defined in RFCs 4033, 4034, and 4035 that add origin authentication and data integrity to DNS. DNSSEC does not encrypt DNS traffic — it signs DNS responses so that resolvers can verify that the data came from the authoritative source and was not tampered with in transit.
Without DNSSEC, a DNS resolver has no way to verify whether a response is legitimate. An attacker who intercepts DNS traffic (via cache poisoning, BGP hijacking, or a compromised network) can redirect users to malicious servers. DNSSEC prevents this by allowing resolvers to cryptographically verify every response.
You can check whether any domain has DNSSEC enabled using our DNSSEC Checker tool.
The Chain of Trust: Root to Domain
DNSSEC establishes trust through a hierarchical chain of trust that mirrors the DNS hierarchy itself. Each level in the chain vouches for the level below it:
- Root zone. The DNS root zone is signed with a well-known key (the root KSK). This key is the trust anchor that all DNSSEC-validating resolvers are configured with. ICANN manages the root zone signing.
- TLD zone. The root zone contains DS (Delegation Signer) records for each TLD (.com, .org, .de, etc.). These DS records are hashes of the TLD's signing key, establishing that the root trusts the TLD's key.
- Domain zone. The TLD zone contains DS records for each DNSSEC-enabled domain. These DS records link the domain's signing key to the TLD's authority.
- Record level. Every DNS record in the domain zone has an RRSIG (Resource Record Signature) that can be verified using the domain's published DNSKEY.
If any link in this chain is broken or missing, DNSSEC validation fails. A resolver may return a SERVFAIL response or mark the response as "bogus" depending on its configuration.
DNSSEC Record Types Explained
DNSSEC introduces several new record types to the DNS:
DNSKEY Records
DNSKEY records contain the public keys used to verify RRSIG signatures. A zone typically has two DNSKEY records: one for the KSK (Key Signing Key) and one for the ZSK (Zone Signing Key). Resolvers use these public keys to verify that the signatures on other records are valid.
DS Records (Delegation Signer)
DS records are published in the parent zone (e.g., the .com zone for a .com domain) and contain a hash of the child zone's KSK. This is the link that connects the chain of trust between zones. When you enable DNSSEC for your domain, you submit the DS record to your domain registrar, who publishes it in the TLD zone.
RRSIG Records (Resource Record Signature)
RRSIG records contain cryptographic signatures for other DNS record sets. Every A, AAAA, MX, TXT, and other record in a DNSSEC-signed zone has a corresponding RRSIG record. The signature covers the record data, record type, TTL, and other fields, ensuring none of them have been modified.
NSEC/NSEC3 Records
NSEC and NSEC3 records provide authenticated denial of existence. When a resolver asks for a record that does not exist, the authoritative server returns an NSEC/NSEC3 record proving that the name does not exist in the zone. NSEC3 improves on NSEC by using hashed names to prevent zone enumeration (walking the zone to discover all names).
KSK vs ZSK: Two-Key Architecture
DNSSEC uses a two-key system for operational flexibility:
- KSK (Key Signing Key): A strong, long-lived key that signs only the DNSKEY record set. Its hash is published as the DS record in the parent zone. Because updating the DS record requires coordination with the registrar, the KSK is rotated infrequently (typically every 1–2 years).
- ZSK (Zone Signing Key): A lighter key that signs all other records in the zone. Because the ZSK is validated by the KSK (not the parent zone), it can be rotated frequently without involving the registrar. Typical ZSK rotation is every 1–3 months.
Some modern implementations use a single CSK (Combined Signing Key) that performs both roles, simplifying key management at the cost of less operational flexibility.
How to Enable DNSSEC for Your Domain
Enabling DNSSEC involves two parties: your DNS provider (who signs the zone) and your domain registrar (who publishes the DS record in the parent zone). Here is the general process:
- Enable DNSSEC at your DNS provider. Most managed DNS providers (Cloudflare, Route 53, Google Cloud DNS) offer one-click DNSSEC activation. The provider generates the key pair and begins signing your zone.
- Get the DS record. Your DNS provider will give you the DS record details: key tag, algorithm, digest type, and digest value.
- Submit the DS record to your registrar. Log into your domain registrar and add the DS record. This publishes it in the TLD zone, completing the chain of trust.
- Verify the configuration. Use our DNSSEC Checker to confirm that the chain of trust is complete and all signatures are valid.
If your DNS provider and registrar are the same company (e.g., Cloudflare for both), the DS record submission is often automated.
Common DNSSEC Issues and Troubleshooting
DNSSEC adds complexity to DNS operations. Here are the most common issues and how to resolve them:
- Bogus responses (SERVFAIL). This means DNSSEC validation failed. Common causes include expired RRSIG signatures, mismatched DS records, or clock skew on the signing server. Check that your zone is being re-signed before signatures expire.
- Insecure delegation. The parent zone does not have a DS record for your domain. DNSSEC is configured at your DNS provider but the chain of trust is broken at the registrar level. Submit the DS record to your registrar.
- Key rollover failures. When rotating KSK or ZSK keys, timing is critical. The old key must remain published until all cached signatures have expired. Premature key removal causes validation failures.
- Algorithm mismatch. The DS record in the parent zone must reference the same algorithm as the DNSKEY in your zone. If you change algorithms during a key rollover, update the DS record as well.
- Large DNS responses. DNSSEC significantly increases the size of DNS responses (RRSIG, DNSKEY records). Ensure your authoritative servers support EDNS0 (Extended DNS) and that firewalls do not block DNS responses larger than 512 bytes.
DNSSEC and DANE
DNSSEC is a prerequisite for DANE (DNS-Based Authentication of Named Entities), which allows domain owners to publish TLS certificate information in DNS via TLSA records. DANE relies entirely on DNSSEC to guarantee the authenticity of TLSA records. Without DNSSEC, DANE has no security value. You can verify both with our DANE Checker.
Verifying Your DNSSEC Setup
After enabling DNSSEC, verify the full chain of trust:
- DNSSEC Checker — Validates the entire chain of trust from root to your domain, checks RRSIG expiration, and verifies DS/DNSKEY consistency.
- DNS Lookup — View DNSKEY, DS, and RRSIG records for any domain.
- DANE Checker — If you also use DANE, verify that TLSA records are properly signed and the certificate matches.