What Is DNSSEC? A Plain-English Guide to the DNS Trust Layer

Published 2026-08-21

DNSSEC — the DNS Security Extensions (RFC 4033–4035) — is a set of cryptographic signatures that let a resolver prove a DNS answer genuinely came from the domain that published it and was not altered in transit. Ordinary DNS has no such proof: it answers in cleartext and trusts whatever reply arrives first, which is why a forged response can send your visitors and your email to an attacker while your real records sit untouched. DNSSEC closes that gap by signing every record and chaining those signatures from the DNS root down to your zone. The catch is that the chain has to stay unbroken — and the August 2026 defaults.exposed census, an independent scan of 432,127,908 domains, found 157,064 domains whose DNSSEC is signed but broken: the signatures fail validation, so every resolver that checks them refuses the answer and the domain effectively disappears. Turning DNSSEC on is a one-click job at most registrars. Keeping the chain valid through every key change is where domains fail — and a broken chain is worse than none.

If you have searched for “what is DNSSEC,” you are almost certainly at one of two moments: someone has told you to “enable DNSSEC” and you want to know what you are switching on, or a tool has told you your DNSSEC is broken and you want to know what that means. This guide answers both, in plain English, without assuming you run a nameserver for a living. The figures throughout come from the defaults.exposed August 2026 census, an independent scan of 432,127,908 domains graded as of 2026-08-16.

What DNSSEC Is, in One Sentence

DNSSEC is a way of digitally signing your DNS records so that anyone looking them up can verify they are authentic and unmodified.

That is the whole idea. When your domain publishes a signed answer — the address of your website, the mail servers that receive your email, the text records carrying your email-authentication policies — it attaches a cryptographic signature. A resolver that supports DNSSEC recalculates that signature and checks it against your published key. If it matches, the answer is trusted. If it does not — because someone tampered with it, or because your own signatures have expired or fallen out of sync — the resolver refuses to hand the answer back at all.

Two words describe what DNSSEC gives you, and it is worth fixing them early because they explain both its value and its most common failure:

Integrity — the answer a user receives is byte-for-byte the answer you published. Nobody altered it on the way.
Authenticity — the answer genuinely originated from the party that controls your zone, not from an impostor who injected it.

Notice what is not on that list: secrecy. DNSSEC does not hide anything, and we will come back to why that distinction trips people up. For now, hold onto the one-sentence version: DNSSEC is a wax seal on your DNS answers, not an envelope around them. For how defaults.exposed grades the two halves of that seal, see the DNSSEC DS and DNSSEC DNSKEY methodology pages.

The Problem It Solves: Cache Poisoning and Forged DNS Answers

To understand why DNSSEC exists, you have to see how easy plain DNS is to fool.

The Domain Name System was designed in the 1980s to be fast and simple, not secure. When your computer needs to reach a domain, it asks a resolver, “what is the address for this name?” The resolver asks a chain of servers, gets an answer, caches it to speed up the next lookup, and hands it back. Crucially, the original protocol has no way to tell a genuine answer from a forged one. A resolver trusts the first plausible reply it receives.

That gap has a name: cache poisoning. If an attacker can slip a forged answer into a resolver’s cache before the real one arrives — racing the legitimate reply, or exploiting predictable query patterns — then everyone using that resolver is quietly sent to the wrong place. The classic demonstration was the 2008 Kaminsky attack, which showed the race was far easier to win than anyone had assumed. And the damage is invisible from your side: your authoritative records remain perfectly correct, so nothing you can see looks wrong, while a slice of the internet is being handed a poisoned address for your name.

The consequences of a forged DNS answer are total, because DNS sits before every other control:

A forged A/AAAA record sends your website’s visitors to a phishing clone.
A forged MX record reroutes your inbound email through an attacker’s server.
A forged TXT record can pass a certificate authority’s domain-validation check, letting an attacker mint a real TLS certificate in your name.

DNSSEC defeats all three by making the forgery detectable. A poisoned answer is not signed by a key your chain vouches for, so a validating resolver throws it away and never caches it. (Repointing your records by breaking into your registrar account is a different attack that DNSSEC does not stop — that is account security, covered in DNS hijacking and spoofing: how attackers steal domain records.) DNSSEC’s job is narrow and specific: it stops answers being forged in flight.

How the Chain of Trust Works: Root → TLD → Your Zone

DNSSEC’s clever part is that you do not have to trust your domain’s key on faith. Every key is vouched for by the level above it, in an unbroken chain that runs all the way up to a single, publicly known starting point. Here is that chain in plain terms.

Your zone signs its own records. Each set of records in your zone (all your A records, all your MX records, and so on) is signed, producing a signature record called an RRSIG. The signature is made with your zone’s private key; the matching public key is published in your zone as a DNSKEY record. So far, though, this proves nothing on its own — an attacker could generate their own key pair and sign a forgery just as convincingly.

Your parent vouches for your key. This is the link that makes it trustworthy. Your parent zone — the registry that runs your TLD, such as the operator of .com or .ae — publishes a small fingerprint of your public key called a DS record (Delegation Signer). The DS record lives in the parent, not in your zone, and it says, in effect, “the key for this domain is the one that hashes to this value.” An attacker cannot forge that, because they cannot publish records in the TLD registry.

Each parent is vouched for in turn. The TLD’s own key is fingerprinted by a DS record in the root zone, the top of the DNS. And the root’s key — the single trust anchor the whole system rests on — is a well-known value that validating resolvers ship with and the internet community manages in public, ceremonially, with cameras rolling.

So the chain runs: root → TLD → your domain. A validating resolver starts from the root key it already trusts, follows the DS fingerprints down through the TLD to your zone, checks that your DNSKEY matches the DS your parent published, and only then trusts the RRSIG on the answer you gave it. If any link is missing or mismatched, the whole chain breaks and the resolver returns an error rather than a possibly-forged answer.

Two extra pieces are worth knowing because they explain routine DNSSEC housekeeping:

KSK and ZSK. Most zones use two keys: a Key Signing Key (the one the DS points to) and a Zone Signing Key (the one that signs day-to-day records). Splitting them means you can rotate the busy ZSK often without asking your parent to update the DS every time.
NSEC / NSEC3. DNSSEC also signs “this name does not exist” answers, so an attacker cannot forge a fake “no such record” reply either. This is called authenticated denial of existence.

The grading of the parent-side DS and the zone-side DNSKEY is split across the DNSSEC DS and DNSSEC DNSKEY methodology pages precisely because a break can happen on either side of that handshake.

DNSSEC Is Not Encryption: What It Does and Doesn’t Protect

This is the single most common misunderstanding, so it gets its own section.

DNSSEC signs; it does not hide. Your DNS records are public information by design — anyone can look up your MX records or your website’s address, and DNSSEC does nothing to change that. When you enable DNSSEC, your queries and answers still travel across the network in cleartext, exactly as before. A network observer between you and your resolver can still see which domains you look up. What they cannot do is change the answer without the tampering being caught.

Put simply:

DNSSEC provides integrity and authenticity — “this answer is genuine and unaltered.”
DNSSEC does not provide confidentiality — “nobody can see what I looked up.” That is a different problem, solved by different technology.

The confidentiality layer is encrypted DNS transport: DNS over HTTPS (DoH, RFC 8484) and DNS over TLS (DoT, RFC 7858). These wrap the conversation between your device and your resolver in an encrypted tunnel so an eavesdropper cannot read the names you are resolving. They are complementary to DNSSEC, not a substitute — DoH/DoT hide the question and the answer in transit; DNSSEC proves the answer is real. A privacy-conscious setup wants both, and mistaking one for the other leaves a real gap:

Run DNSSEC alone and your lookups are authentic but visible.
Run DoH/DoT alone and your lookups are private but you are trusting your resolver to have given you a genuine answer, with no cryptographic proof from the zone itself.

If you take one thing from this section: DNSSEC is about trust, not secrecy. It answers “can I believe this DNS record?” — never “can someone see it?”

Why 157,064 Domains Have Broken DNSSEC

Here is the uncomfortable finding. Enabling DNSSEC is easy; keeping it valid is a discipline — and at internet scale, a measurable number of domains fail that discipline in the worst possible way.

The August 2026 census found 157,064 domains publishing broken DNSSEC: the signatures are present, but they fail validation. This is not the same as having no DNSSEC. A domain with no DNSSEC resolves normally everywhere. A domain with broken DNSSEC is refused by every resolver that validates — and that includes the major public resolvers a large share of the internet uses. The result is a domain that is invisibly down: the website will not load and the email will bounce for validating users, while the owner, whose own non-validating tools may still work, often has no idea anything is wrong. We quantify that population in the companion report, Broken DNSSEC: 157,064 domains are invisibly down.

The reason a signed domain breaks almost always traces to the handshake between two systems that must stay in lockstep. Common causes:

Key rollover gone wrong. Keys are meant to be rotated periodically. If the zone starts signing with a new key before — or without — the matching DS fingerprint being updated in the parent, the chain snaps. This is the classic outage, and it is why key rolls are the most nervous moment in DNSSEC operations.
Split management mismatch. Your registrar publishes the DS record; your DNS host publishes the DNSKEY. If those are two different companies and the DS at the registrar does not match the key at the host — because one changed and the other did not — validation fails even though both sides look configured.
Expired signatures. RRSIG records have a validity window. If the automated re-signing that is supposed to refresh them stalls, the signatures lapse and every answer starts failing validation on a deadline nobody was watching.
Algorithm rollover errors. Migrating from an older signing algorithm to a newer one is another moment where the parent and child can fall out of step.

The pattern behind all four is the same: DNSSEC has a severe, silent failure mode. Nothing degrades gracefully. The chain either holds or it refuses the answer outright — which is exactly the property that makes broken DNSSEC worse than no DNSSEC. If you already run DNSSEC, the practical takeaway is that deployment was only half the job; confirming the chain still validates, and monitoring it through every key change, is the other half. Check your domain free at defaults.exposed tells you in one scan whether your chain validates right now or is silently broken.

Should You Enable DNSSEC? A Decision Guide

DNSSEC is worth having for most domains that matter — but the honest answer depends on whether you can maintain it, because a domain you cannot maintain is better left unsigned than signed and broken. Work through the decision below.

Lean toward enabling DNSSEC if:

Your domain carries email or hosts a service where an interception or a phishing clone would cause real harm — that is most business domains.
Your registrar and DNS host support one-click / automated DNSSEC, ideally with the DS record pushed to the registry for you. When one provider runs both the zone and the delegation, the dangerous handshake is handled internally and the outage risk drops sharply.
You can arrange even light monitoring so a broken chain is caught in hours, not months.

Be cautious — automate first — if:

Your registrar and DNS host are different companies and you would be updating the DS by hand. This split is the single biggest source of the broken chains in the census figure above. Do not sign until you have a reliable process (or automation such as CDS/CDNSKEY, where the child publishes the desired DS and the parent picks it up) for keeping the two sides in sync through every roll.
You have no way to notice a validation failure. An unmonitored signed domain is an outage waiting for its first key roll.

Whatever you decide, do two things:

Validate after you enable. Signing the zone is step one; confirming that the parent DS actually chains to your DNSKEY, with no expired signatures, is what proves it works. Do not assume “switched on” means “validating.”
Monitor through every key change. The failure is silent, so the only defence is watching. This is exactly what a continuous scan is for — see how alerting before a key-rollover outage works so a broken chain reaches you before it reaches your customers.

DNSSEC also sits alongside the other DNS controls that live in public records — nameserver redundancy so your name always resolves, and a CAA record so only the certificate authorities you choose can issue for you. The nameserver-diversity and CAA-record methodology pages cover those, and the whole DNS picture is drawn together in DNS Security Explained: why 94 million domains rely on two landlords.

What This Means

For business owners, DNSSEC is a control you almost never touch directly but should insist on getting right, because the thing it protects is the trustworthiness of your own name. Without it, a forged DNS answer can send your customers to a fake version of your site or quietly reroute your email, with nothing on your own screens looking wrong. The important nuance is that DNSSEC is not a “turn it on and forget it” switch: the census finding of 157,064 broken chains is proof that a badly maintained signature can take your domain offline more reliably than an attacker would. Ask your registrar or IT provider two questions — “is DNSSEC enabled and validating?” and “who is watching it through key changes?” — and make sure both have real answers.

For IT and infrastructure teams, the operational reality is that DNSSEC’s value and its risk come from the same property: it fails closed. That is what makes it effective against cache poisoning, and it is what turns an unmanaged key roll or a stale DS into an internet-wide outage for your domain. Split registrar/DNS-host management is the hazard to design out first — prefer a provider that automates the DS handshake, or adopt CDS/CDNSKEY automation, and never roll a key by hand without confirming the parent updated. Then monitor validation continuously, because the one thing you cannot rely on is noticing the failure yourself: your local, non-validating tooling will keep resolving the domain long after your validating customers have stopped being able to reach you.

FAQ

What is DNSSEC? DNSSEC (DNS Security Extensions, RFC 4033–4035) is a way of cryptographically signing DNS records so that a resolver can verify an answer is authentic and unaltered before trusting it. Plain DNS has no such check — it accepts whatever reply arrives first — which lets attackers forge answers through cache poisoning. DNSSEC attaches a signature to each record set and chains those signatures from the DNS root down to your domain, so a forged answer that is not signed by a trusted key is rejected outright. It provides integrity and authenticity, not secrecy. The August 2026 census of 432,127,908 domains found 157,064 with signed but broken DNSSEC.

How does DNSSEC work? Your zone signs its records, producing RRSIG signatures, and publishes the matching public key as a DNSKEY record. Your parent zone — the registry for your TLD — publishes a small fingerprint of that key, called a DS record, which vouches for it. The TLD’s own key is in turn fingerprinted by the DNS root, whose key every validating resolver already trusts. A resolver follows this chain from the root down to your domain; if the DS in the parent matches your DNSKEY and the RRSIG checks out, the answer is trusted. If any link is missing or mismatched, the resolver returns an error instead of a possibly forged answer.

Is DNSSEC necessary? For most domains that carry email or host anything worth impersonating, DNSSEC is strongly recommended, because it is the only mechanism that stops your DNS answers being forged in transit. But it carries a maintenance duty that no other DNS record does: a broken or expired signature takes the domain offline for every validating user, so an unmonitored deployment can hurt more than help. The census found 157,064 domains proving exactly that failure. The right rule is to enable DNSSEC where your registrar and DNS host can keep the chain in sync automatically and you can monitor it — and to fix or postpone it where you cannot. Check your domain free at defaults.exposed to see your current status.

Does DNSSEC encrypt DNS? No — and this is the most common misconception. DNSSEC signs DNS answers so their authenticity can be verified, but it does nothing to hide them; your queries and answers still travel in cleartext, and an observer can still see which domains you look up. DNSSEC gives you integrity and authenticity, not confidentiality. Encrypting the DNS conversation is a separate technology: DNS over HTTPS (DoH) and DNS over TLS (DoT), which wrap the lookup in an encrypted tunnel. The two are complementary — DNSSEC proves the answer is genuine, DoH/DoT keep the question private — and a complete setup uses both rather than treating one as a replacement for the other.

Data to cite

“DE’s August 2026 census found 157,064 domains with broken DNSSEC: signatures are present but fail validation, so validating resolvers return SERVFAIL and the domain effectively disappears.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Broken DNSSEC is worse than no DNSSEC — a broken chain of trust is refused outright by validating resolvers, not downgraded to a plain answer.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Across the 432,127,908-domain census, DNSSEC remains a small minority of zones, so a broken chain is a self-inflicted outage on a control most domains never adopt in the first place.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“DNSSEC authenticates DNS answers but is not encryption — it does nothing for confidentiality, which is the job of DNS over HTTPS (DoH) and DNS over TLS (DoT).” — defaults.exposed August 2026 Domain Security Census (432M domains)

See where your own domain stands

DNSSEC fails silently. A key rolled without the parent DS being updated, a signature left to expire, a registrar and DNS host quietly out of sync — none of it shows up in your own browser or inbox, because your local tools do not validate. The first sign is often a customer who cannot reach you, and by then the domain has been invisibly down for a while. The only way to know your chain holds is to check it from a validating vantage point, and the check costs nothing.

Check your domain free at defaults.exposed — it reads your live DNS straight from the public record and tells you whether your DNSSEC actually validates or is silently broken, alongside your nameserver spread, your CAA posture, and your email-authentication grade. It takes about 30 seconds and needs no account. If you want that chain watched through every key change so a broken roll reaches you before it reaches your users, see how alerting before a key-rollover outage works.

Read the flagship census report: The State of Domain Security 2026 →

Aggregate data only. Data stored and processed in the EU.

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 432,127,908 domains scanned. All figures are counts of graded domains. References: RFC 4033–4035 (DNSSEC), RFC 8484 (DoH), RFC 7858 (DoT), RFC 8659 (CAA), RFC 1034/1035 (DNS).

How to cite this report

Press / blog: defaults.exposed (2026). What Is DNSSEC? A Plain-English Guide to the DNS Trust Layer. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/what-is-dnssec-a-plain-english-guide-to-the-dns-trust-layer

Academic: defaults.exposed. (2026, August 21). What Is DNSSEC? A Plain-English Guide to the DNS Trust Layer. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/what-is-dnssec-a-plain-english-guide-to-the-dns-trust-layer

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=432,127,908 domains scanned)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/v9/methodology Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Data sourced from the August 2026 grading methodology (v9) — 34 checks, 376 million domains. Browse the census statistics or the Census Explorer, or see all August 2026 research →