DNSSEC (Domain Name System Security Extensions) is a suite of IETF specifications that adds cryptographic signatures to DNS records. These signatures allow resolvers to verify that DNS responses are authentic and have not been tampered with in transit.

What attacks does DNSSEC prevent?

DNSSEC directly prevents DNS cache poisoning (also called the Kaminsky attack) and DNS spoofing, where an attacker injects false DNS records to redirect traffic. It does not protect against DDoS attacks on DNS infrastructure or encrypt the DNS query itself.

Does DNSSEC encrypt my DNS queries?

No, DNSSEC authenticates DNS responses but does not encrypt them. Your DNS queries and responses are still visible to network observers. For query privacy, you need DNS over HTTPS (DoH) or DNS over TLS (DoT) in addition to DNSSEC.

What is a DNSKEY record?

A DNSKEY record contains the public key used to verify DNSSEC signatures for a zone. There are two types: the Zone Signing Key (ZSK) which signs the zone's resource records, and the Key Signing Key (KSK) which signs the ZSK and establishes the trust chain.

What happens if DNSSEC validation fails?

If DNSSEC validation fails, a DNSSEC-aware resolver will return a SERVFAIL error and refuse to return the response to the client. This prevents the user from being redirected to a spoofed address, though it may also block legitimate traffic if misconfiguration causes validation failures.

Is DNSSEC widely deployed?

DNSSEC adoption is uneven. The root zone and most country-code top-level domains are signed, and major TLDs like .com and .org support it. However, less than 30% of domains under these TLDs are actually DNSSEC-signed, leaving a large portion of internet traffic without this protection.

DNSSEC Explained: Stopping DNS Spoofing at the Root

Introduction

In 2008, security researcher Dan Kaminsky discovered a critical flaw in the DNS protocol that allowed an attacker to poison a recursive resolver’s cache in under ten seconds. By flooding a resolver with forged responses, an attacker could redirect an entire internet service provider’s users to malicious sites — for every website, not just one. The vulnerability affected an estimated 85% of the internet’s DNS resolvers. Emergency patches coordinated across the industry bought time, but the underlying protocol remained broken.

The real fix is DNSSEC, a set of cryptographic extensions to the Domain Name System. Instead of trusting that a DNS response came from the right server, DNSSEC lets resolvers verify it mathematically using digital signatures. A forged response will fail validation and be discarded before it reaches you.

Understanding DNSSEC matters because DNS is the directory service for everything on the internet. An attacker who controls what your DNS resolver believes controls where your traffic goes — regardless of TLS certificates and firewalls.

DNSSEC Explained: What It Is

DNSSEC (Domain Name System Security Extensions) is a suite of IETF standards — primarily RFC 4033, 4034, and 4035 — that adds digital signatures to DNS records. It allows a validating resolver to verify that the DNS data it received was created by the authoritative name server for that zone and has not been modified in transit.

The DNS protocol was designed in the 1980s without authentication. Every DNS response is a plain UDP packet with a transaction ID — and the Kaminsky attack demonstrated that guessing this ID is trivial for a well-resourced attacker. DNSSEC does not change the underlying protocol; it adds a layer of cryptographic proof on top of it.

Crucially, DNSSEC authenticates but does not encrypt. Your DNS query and its answer are still transmitted in plaintext. DNSSEC tells you the answer is genuine; it does not hide the question or the answer from observers on the network. For query privacy, you need DNS over HTTPS or DNS over TLS.

How DNSSEC Works

DNSSEC builds a chain of trust from the DNS root down to individual domain zones. Each link in the chain is secured by digital signatures:

Zone Signing: The domain owner generates two key pairs: a Zone Signing Key (ZSK) and a Key Signing Key (KSK). The ZSK signs every resource record in the zone. The KSK signs the ZSK.
Delegation Signer: A hash of the KSK (called a DS record) is submitted to the parent zone. For example, the .com registry stores a DS record for example.com. This creates the chain: root signs .com, .com signs example.com.
RRSIG Records: For every DNS record set (A, MX, CNAME, etc.), the authoritative server publishes a cryptographic signature in an RRSIG record. This signature is produced by the ZSK.
Resolver Validation: When a DNSSEC-aware resolver receives a response, it retrieves the RRSIG and uses the published DNSKEY (via the chain of trust from the root) to verify the signature. If the signature is valid, the record is authentic. If not, the resolver returns SERVFAIL.
NSEC/NSEC3: DNSSEC also authenticates the non-existence of records using NSEC (Next Secure) records, preventing an attacker from claiming a domain has no records when it does.

This video explains the DNSSEC trust chain — from the DNS root through TLD to individual domains — and why each signature in the chain matters.

The DNSSEC chain of trust: from the signed root zone through TLD delegation to individual domain zone verification.

DNSSEC vs Unsigned DNS

The difference between a DNSSEC-signed domain and an unsigned one is the difference between a phone directory you can verify was printed by the publisher versus one that anyone could have photocopied and altered. Both look the same on the surface, but only one lets you check its authenticity.

Without DNSSEC, a cache poisoning attack works like this: an attacker races to get a forged response accepted by a resolver before the real one arrives. With modern tooling, this can take milliseconds. With DNSSEC, even if the forged response arrives first, the resolver will reject it because it cannot produce a valid signature from the authoritative key.

The trade-off is operational complexity. DNSSEC requires managing key pairs, publishing DS records to parent zones, and carefully handling key rollovers. A misconfiguration can cause your entire domain to return SERVFAIL for all resolvers that validate DNSSEC, effectively taking your site offline for a large portion of users.

Feature	Unsigned DNS	DNSSEC-Signed DNS
Cache poisoning protection	None	Cryptographic verification
Response tampering detection	None	Signatures over all records
Query encryption	None	None (use DoH/DoT for this)
Non-existence proof	None	NSEC/NSEC3 records
Operational complexity	Low	High (key management required)

Real-World Use Cases

Government agencies were early adopters of DNSSEC because they operate under mandates like CISA’s BOD 18-01, which required all .gov domains to be DNSSEC-signed. A federal agency handling sensitive citizen data cannot afford to have its DNS records spoofed — redirecting a taxpayer filing a return to a phishing site impersonating a government portal would be a catastrophic breach of public trust.

Financial services use DNSSEC to protect the initial DNS lookup for online banking portals. A user navigating to their bank relies on DNS to find the correct IP address before TLS even begins. DNSSEC ensures that first lookup is tamper-proof, removing a critical attack surface before the encrypted session is established.

Large-scale registrars like Cloudflare and AWS Route 53 have simplified DNSSEC deployment by automating key generation, signing, and DS record submission. This has lowered the barrier for smaller organizations that previously lacked the in-house expertise to manage DNSSEC manually.

Common Mistakes to Avoid

The most dangerous DNSSEC mistake is failing to manage key rollovers. DNSSEC keys have finite lifetimes and must be rotated periodically. If you let a key expire without publishing a new one and updating the DS record at the parent zone, your domain will start failing DNSSEC validation and become unreachable for millions of users. Always use a calendar reminder or automated tooling for key rollovers.

A second common error is testing DNSSEC in production without a rollback plan. Signing a zone incorrectly — for example, uploading the wrong DS record to your registrar — can instantly take your domain offline for validating resolvers. Always test signing in a staging environment and have a procedure to remove DNSSEC signing quickly if validation breaks.

Finally, organizations sometimes assume DNSSEC means DNS is secure. It is not. DNSSEC only authenticates responses. It does nothing to prevent someone from watching your queries (use DoH or DoT for privacy), it does not protect against a compromised authoritative server returning correctly signed but malicious records, and it offers no protection against DDoS attacks targeting your DNS infrastructure.

Getting Started

Start by checking whether your domain is currently DNSSEC-signed using the ICANN DNSSEC Analyzer at dnssec-analyzer.verisignlabs.com. Enter your domain and the tool will show you each step of the trust chain and flag any broken links.

If you are ready to sign your domain, check whether your DNS hosting provider supports DNSSEC. Cloudflare, AWS Route 53, and most major registrars now have one-click DNSSEC signing. The hardest part — submitting the DS record to the parent zone — is typically automated by modern registrars.

For monitoring, use tools like Zonemaster to validate your DNSSEC configuration after any change and before any planned key rollover. Pair DNSSEC with the TLS protections covered in our TLS 1.3 vs TLS 1.2 guide, and read about Certificate Transparency to complete the picture of how web trust is established end to end.