What Is DNSSEC? How It Protects Your Domain

DNS was designed in the 1980s without any built-in authentication. When a resolver asks a nameserver for a record, it has no way to verify that the response actually came from the authoritative source. DNSSEC (Domain Name System Security Extensions) fixes this by adding cryptographic signatures to DNS records, allowing resolvers to verify that the data they receive is authentic and has not been tampered with. For a foundational understanding of how DNS works, see our complete DNS guide.

The core problem is straightforward. Without DNSSEC, an attacker can forge DNS responses (a technique called cache poisoning) and redirect users to malicious servers. The user types your domain into their browser, gets a forged IP address, and ends up on an attacker's server. DNSSEC makes this type of attack detectable by giving resolvers a way to cryptographically verify every response.

How DNSSEC Works

DNSSEC adds digital signatures to DNS records. When a zone is signed, every record set gets a corresponding signature record. Resolvers that support DNSSEC validation can check these signatures against published public keys to confirm the data is legitimate.

The system introduces several new DNS record types that work together.

RRSIG (Resource Record Signature)

Every signed record set in a zone gets an RRSIG record. This record contains a cryptographic signature generated using the zone's private key. When a resolver receives a DNS response, it uses the corresponding public key to verify that the signature matches the data. If someone has modified the data in transit, the signature check fails.

DNSKEY (DNS Public Key)

The DNSKEY record contains the public key for a zone. Resolvers use this key to verify RRSIG signatures. Each zone typically has two key pairs: a Zone Signing Key (ZSK) that signs the actual records, and a Key Signing Key (KSK) that signs the DNSKEY record itself. This separation allows for easier key rotation. The ZSK can be rotated frequently without involving the parent zone.

DS (Delegation Signer)

The DS record lives in the parent zone and contains a hash of the child zone's KSK. This is the record that links the chain of trust between zones. When a resolver validates a child zone's DNSKEY, it checks that the hash matches the DS record in the parent. Your registrar publishes the DS record in the parent zone (the TLD zone, for most domains).

NSEC and NSEC3 (Authenticated Denial of Existence)

DNSSEC also needs to prove when a record does not exist. NSEC and NSEC3 records provide authenticated denial of existence. Without these, an attacker could forge "that record doesn't exist" responses. NSEC3 is the more common variant because it uses hashed names, which prevents zone enumeration (walking the entire zone to discover all hostnames).

The Chain of Trust

DNSSEC validation depends on a chain of trust that starts at the DNS root zone and extends down through each level of the hierarchy. This chain is what makes the entire system work.

The root zone is signed with a well-known root key. This key is maintained by ICANN and is built into DNSSEC-validating resolvers. The root zone contains DS records for each TLD (.com, .org, .net, etc.). Each TLD zone is signed with its own keys and contains DS records for the domains registered under it. Each domain is signed with its own keys.

When a resolver needs to validate a response for example.com, it follows this path:

1. The resolver already trusts the root zone's public key.
2. It retrieves the DS record for .com from the root zone and validates it.
3. It retrieves the DNSKEY for .com and confirms the DS hash matches.
4. It retrieves the DS record for example.com from the .com zone and validates it.
5. It retrieves the DNSKEY for example.com and confirms the DS hash matches.
6. It retrieves the RRSIG for the requested record and validates it against the DNSKEY.

If every link checks out, the resolver knows the response is authentic. If any link fails, the resolver returns an error instead of potentially poisoned data.

What DNSSEC Protects Against

DNSSEC directly addresses several attack vectors that exploit the lack of authentication in traditional DNS.

Cache Poisoning

Without DNSSEC, an attacker can send forged responses to a recursive resolver, which caches them and serves them to every user who queries that resolver. With DNSSEC, the resolver can detect that the forged response has an invalid signature and discard it. This is the primary threat DNSSEC was designed to counter. Learn more about this attack vector in our DNS hijacking guide.

Man-in-the-Middle Attacks

An attacker positioned between a resolver and an authoritative server can intercept and modify DNS responses. DNSSEC signatures make any modification detectable because the attacker cannot produce valid signatures without the zone's private key.

Response Forgery

Even without being on the network path, an attacker can attempt to send forged responses that arrive at the resolver before the legitimate response. DNSSEC validation catches these because the signatures will not match.

What DNSSEC Does Not Do

Understanding the limitations is just as important as understanding the benefits.

DNSSEC does not encrypt DNS queries or responses. All DNS data remains visible to anyone who can observe network traffic. DNSSEC provides authentication and integrity, not confidentiality. If you need encrypted DNS, look at DNS over HTTPS or DNS over TLS.

DNSSEC does not prevent DDoS attacks. In fact, DNSSEC responses are larger than unsigned responses because they include signature data. This can make DNS amplification attacks slightly more effective.

DNSSEC does not protect the last mile. If an attacker compromises the user's local DNS settings (through malware or a rogue router), DNSSEC validation on the upstream resolver doesn't help unless the user's stub resolver also performs validation.

DNSSEC does not protect against registrar compromise. If an attacker gains access to your registrar account and changes your DS records, they can sign a malicious zone with their own keys and the chain of trust will validate it. Strong DNS security practices at the registrar level remain essential.

How to Enable DNSSEC

Enabling DNSSEC is a two-part process: signing your zone and publishing DS records at your registrar.

How to Check if a Domain Has DNSSEC

You can check any domain's DNSSEC status using standard DNS tools. Use dig with the +dnssec flag to request DNSSEC records. For step-by-step instructions on using dig and other DNS lookup tools, see our guide on how to check DNS records.

dig example.com +dnssec

If the response includes RRSIG records and the ad (Authenticated Data) flag is set, the domain is signed and the resolver validated it. You can also check for DS records directly:

dig example.com DS

If a DS record exists in the parent zone, the domain has DNSSEC configured.

Online tools like dnsviz.net, Verisign's DNSSEC Analyzer, and ICANN's DNSSEC Look-up Tool provide detailed validation results without needing command-line access.

DNSSEC and Different Record Types

DNSSEC signs all record types in a zone. A records, AAAA records, MX records, TXT records, CNAME records, and NS records all get RRSIG signatures. This means DNSSEC protects not just web traffic but also email routing, service discovery, and any other DNS-dependent function.

DNSSEC Adoption Status

DNSSEC adoption has been slow but is accelerating. The root zone was signed in 2010. As of 2025, roughly 30-40% of .com domains have DS records published, up significantly from under 5% a decade ago. Some TLDs have much higher adoption. The .nl (Netherlands) TLD has over 60% DNSSEC adoption. The .se (Sweden) and .br (Brazil) TLDs also have strong adoption rates.

On the validation side, major public resolvers (Google Public DNS, Cloudflare 1.1.1.1, Quad9) all perform DNSSEC validation by default. This means that even if adoption at the domain level is incomplete, a growing share of DNS queries are validated when DNSSEC is available.

The biggest barriers to wider adoption are complexity and the risk of misconfiguration. A broken DNSSEC chain (expired signatures, mismatched DS records) makes a domain completely unreachable for validating resolvers. This is worse than no DNSSEC at all, which is why continuous monitoring of DNSSEC status is important. Check your zone's signing status alongside your other records as part of your DNS security strategy.

Key Rotation and Maintenance

DNSSEC is not a set-and-forget configuration. Keys need to be rotated periodically. The ZSK is typically rotated every few months. The KSK is rotated less frequently, often once a year or less, because rotating it requires updating the DS record at the registrar.

Automated key management is available from most major DNS providers. Cloudflare handles all key rotation automatically. Route 53 supports automatic rotation as well. If you manage your own DNSSEC signing (using BIND or similar), you need to handle key generation, signing, and DS record updates yourself.

Failed key rotation is one of the most common causes of DNSSEC-related outages. If signatures expire before new ones are generated, or if DS records at the registrar don't match the current KSK, the entire chain of trust breaks.

References

• RFC 4033 - DNS Security Introduction and Requirements
• RFC 4034 - Resource Records for the DNS Security Extensions
• RFC 4035 - Protocol Modifications for the DNS Security Extensions
• Cloudflare - DNSSEC: How It Works
• ICANN - DNSSEC: What Is It and Why Is It Important?