DNSSEC Explained: What It Protects and How to Check It

A domain can be perfectly reachable one moment and completely gone the next. Nothing changed in the code, and nothing went down on the server. The cause is often a single expired DNSSEC signature. A validating resolver will not warn you and move on. It refuses the answer outright.

This guide explains what DNSSEC actually protects. It walks through the records that build the chain of trust. It also shows how to check whether a domain is signed and validating today.

What DNSSEC Actually Does (and What It Doesn’t)

DNSSEC adds digital signatures to DNS records. A resolver uses them to verify a record came from the real server and was not altered. It authenticates DNS answers. It does not encrypt them, so anyone watching the network can still see which domains you query.

Every DNS response you receive today can be forged. A malicious resolver, a compromised network, or a classic cache-poisoning attack can all inject fake answers. Normal DNS has no way to tell a real answer from a fake one.

DNSSEC closes that gap with public-key cryptography. Each signed zone publishes a public key and signs its records with the matching private key. A validating resolver checks the signature against the public key before trusting the answer.

DNSSEC does one job well: authentication. It confirms a record came from the zone’s real owner and was not changed in transit. It says nothing about who can see the query. Confusing DNSSEC with privacy is the single most common misconception about it, covered in more depth further down.

DNSKEY, RRSIG, and DS: The Three Records Behind DNSSEC

Three record types carry DNSSEC’s cryptography. DNSKEY publishes a zone’s public signing keys. RRSIG is the digital signature attached to a set of records. DS, published in the parent zone, links a child zone’s key to a zone one step higher in the hierarchy.

You will meet each of these records if you look at a signed zone with dig. For a refresher on ordinary DNS records like A and MX, see our guide to DNS records explained. This one builds on that foundation.

DNSKEY: The Public Keys

DNSKEY holds the public key. Every signed zone publishes at least two DNSKEYs. The Zone Signing Key, flag 256, signs everyday records. The Key Signing Key, flag 257, signs the DNSKEY set itself. Splitting the roles lets the frequently used ZSK rotate often while the KSK changes rarely.

RRSIG: The Signatures

RRSIG is the signature itself. Every signed record set gets a matching RRSIG. It carries the signing algorithm, the signature’s validity window, and the key that produced it. Resolvers reject a record if its RRSIG has expired, even if the record’s actual data is correct.

DS: The Link to the Parent Zone

DS sits in the parent zone, not your own. It is a hash of your zone’s KSK, published at your registrar. The DS record is the single link that ties your zone’s key to the zone above it. From there, the chain continues up to the root.

The Chain of Trust: From the Root to Your Domain

The chain of trust starts at the DNS root, whose key every validating resolver already trusts. The root signs the key for each top-level domain. Each TLD signs the key for the domains beneath it, one link at a time down to yours.

Every validating resolver ships with one hardcoded trust anchor: the root zone’s public key. Everything else builds from that single starting point.

When a resolver looks up example.com, it first fetches the DS record for .com from the root. The root signs that DS record with its own key. That DS record lets the resolver trust .com’s own DNSKEY.

The resolver repeats the process one level down. It fetches the DS record for example.com from .com, signed by .com’s key. That lets it trust example.com’s own DNSKEY.

Break any single link in that chain and everything below it loses trust. A missing DS record, an expired signature, or a key mismatch all have the same effect. It does not matter if the lower zones are signed correctly themselves.

The root’s own key changes too, on a schedule ICANN calls a KSK rollover. The next one is scheduled for October 11, 2026. A new key called KSK-2024 takes over signing duties from the key used since 2017. Well-configured resolvers update their trust anchor automatically. Older or manually configured resolvers that miss the change can lose DNSSEC validation entirely, for every signed domain.

NSEC and NSEC3: Proving a Name Doesn’t Exist

DNSSEC also has to prove a name does not exist, not just that a name is real. NSEC lists the next real name in the zone, which lets anyone walk the entire zone. NSEC3 hashes names first, blocking that enumeration while still proving absence.

Proving a record does not exist is trickier than proving one does. A resolver cannot get a signature for something that was never created.

The original approach, NSEC, lists every name in the zone in sorted order. Each NSEC record points to the next real name in the zone. That lets a resolver prove no name exists between two known names. The tradeoff: anyone can walk the chain, name by name, and enumerate the entire zone.

That side effect matters for zones that treat their subdomain list as sensitive, or simply do not want it scraped. NSEC3 fixes it by hashing each name before building the chain. A resolver can still prove absence between two hashes, but recovering the real names from those hashes takes real effort.

Most modern DNSSEC deployments use NSEC3 by default. Plain NSEC still appears on some older or smaller zones where enumeration is not a concern.

DNSSEC vs Encrypted DNS: Authentication Is Not Privacy

DNSSEC and encrypted DNS solve different problems and neither replaces the other. DNSSEC proves a DNS answer is genuine but sends it in plain text. DoH and DoT hide which domains you look up but do not verify the answer is authentic.

People often assume a secure padlock icon or an encrypted connection means DNS is safe end to end. It does not. HTTPS and DoH protect the connection to a server. Neither one confirms the DNS answer that pointed you there was genuine. Our SSL certificate checker covers the padlock side of that confusion in more detail.

The two protections stack, and using both closes more gaps than either alone. A resolver can validate DNSSEC and still leak your query to your ISP in plain text. Or it can encrypt your query with DoH and still hand you a forged, unsigned answer. Running both DNSSEC validation and an encrypted DNS resolver, like Cloudflare or Quad9, closes both gaps at once.

When DNSSEC Breaks: SERVFAIL and Real-World Outages

A validating resolver treats a broken DNSSEC signature as an attack, not a warning. It refuses to return any answer at all. The result is SERVFAIL, and every visitor using that resolver sees the domain as completely down.

A signed zone that stops resolving cleanly is one of the most disorienting outages in DNS. Nothing shows an error page. The domain just seems to vanish for a subset of users.

The most common causes are mundane. A DNSSEC signature expires because an automated re-signing job silently failed. A key rollover finishes at the authoritative server before the parent zone’s DS record catches up. A registrar submits the wrong DS data during a nameserver migration.

The scale of the risk is not theoretical. On May 5, 2026, DENIC, the .de registry, published broken DNSSEC signatures for the entire top-level domain. DENIC later confirmed the cause was a routine, scheduled key rollover that produced signatures resolvers could not validate. Millions of .de domains became unreachable at once for anyone using a validating resolver, until the signatures were fixed.

Diagnosing this starts with one dig command. Query with validation disabled using the CD flag, then compare it to a normal query.

# Query with DNSSEC validation disabled
dig @8.8.8.8 example.com +cd

# Query normally, with validation enabled
dig @8.8.8.8 example.com

# Compare against a domain known to validate cleanly
dig @8.8.8.8 cloudflare.com +dnssec

If the domain resolves with CD but fails without it, DNSSEC is the cause. It is not a routing or server problem. From there, check whether the RRSIG has expired. Also confirm the DS record at the parent still matches the current DNSKEY. If routing or the server itself turns out to be the real issue, our network troubleshooting guide covers the rest. It walks through the remaining diagnostic steps.

How to Check If a Domain Has DNSSEC Enabled

Two of our tools answer two different DNSSEC questions. The WHOIS lookup shows whether a domain publishes a DS record at all. The DNS Lookup tool shows whether a live query actually validates end to end.

Two of NetworkCheckr’s tools answer this from different angles, and the distinction matters.

Our WHOIS lookup queries the registry directly. It shows whether a domain has published a DS record at all. That means the parent zone is aware the domain is signed. This is a delegation check, not a validation check. A domain can publish a DS record and still be broken.

Our DNS Lookup tool queries live, using Google’s DNS-over-HTTPS resolver. For any record type, it shows a DNSSEC status of Validated or Not Validated. Validated means Google’s resolver checked the signatures and trusts the answer right now. This is the real-time, end-to-end test.

For a command-line check, query DNSKEY and DS directly:

dig example.com DNSKEY +short
dig example.com DS +short

Empty output on either command means the domain is not signed, or the parent has no record of it. For a visual, step-by-step map of the chain, Verisign’s DNSSEC Debugger walks each link and highlights exactly where it breaks. The independent tool DNSViz does the same, showing the full authentication graph.

Enabling DNSSEC on Your Own Domain (General Steps)

Enabling DNSSEC means signing your zone with your DNS provider, then publishing a DS record at your registrar. Most managed DNS providers, including Cloudflare and Route 53, automate the signing. The manual step is almost always the DS record at the registrar.

Turning on DNSSEC involves two separate systems that must agree: your DNS host and your registrar. Getting the order wrong when enabling or disabling it is the fastest way to trigger the SERVFAIL outage above. Treat the sequence below as strict, not a suggestion.

Most managed DNS providers sign zones automatically once you flip a setting. Cloudflare, Route 53, and Google Cloud DNS handle key generation, signing, and rotation without manual key management. If you self-host DNS with BIND or Knot, you manage keys and re-signing yourself. That usually runs through a cron job or built-in automation.

1. Confirm your DNS provider supports DNSSEC signing, then enable it in their dashboard.
2. Retrieve the DS record data your provider generates: key tag, algorithm, digest type, and digest.
3. Log in to your domain registrar and find the DNSSEC or DS record section.
4. Enter the DS record data exactly as your DNS provider provided it.
5. Wait for the DS record to propagate. Same-provider setups often finish in under an hour; cross-provider setups can take up to 24 to 48 hours.
6. Verify with a DNSKEY and DS query, or our DNS Lookup tool, that validation succeeds.

Why DNSSEC Adoption Still Lags in 2026

Nearly every top-level domain signs its own zone, but individual domain owners have not followed. Roughly a third of internet users sit behind a resolver that validates DNSSEC. Only a small fraction of everyday DNS traffic is both signed and checked.

The infrastructure at the top of DNS is essentially done. Most generic top-level domains and the majority of country-code domains sign their own zones. The bottleneck sits one level down, at individual domains.

Signing a zone takes ongoing operational care: key rotation, re-signing before expiry, and coordinating changes with the registrar. Many domain owners see no visible benefit and skip it. A domain that is not signed simply behaves as if DNSSEC does not exist. There is no broken padlock and no browser warning. Nothing pushes an administrator to act.

Validation tells a similar story from the resolver side. About 36 percent of global DNS traffic now resolves through a validating resolver. Roughly 7 percent of zones are securely delegated. Google and Cloudflare’s public resolvers, which default to validating, drive much of that validation share. But validation only matters for signed domains, so the two numbers rarely overlap. Our guide to reading a WHOIS lookup puts a number on the domain side. Roughly 4 percent of .com domains are currently signed.

Frequently Asked Questions

Quick answers to what readers ask most about DNSSEC. That includes what it actually protects and why a signed domain can suddenly stop resolving. These cover checking, enabling, and troubleshooting DNSSEC on a real domain.

Related Tools & Resources

Our WHOIS and DNS Lookup tools both surface DNSSEC data, from opposite ends of the chain. Use the WHOIS lookup to check delegation at the registry. Use the DNS Lookup tool to confirm a query actually validates.