Plain DNS has no way to verify that a response hasn't been tampered with — a resolver asks a question and trusts whatever answer comes back. DNSSEC closes that gap with cryptographic signatures, but publishing the right records isn't the same as the chain actually validating end-to-end — and a broken chain is a worse state than having no DNSSEC at all.
What DNSSEC Actually Protects Against
Without DNSSEC, an attacker positioned to intercept or spoof DNS traffic — on a compromised network, a malicious resolver, or via cache poisoning — can return a fake answer to a DNS query with nothing to catch it. DNSSEC signs each response cryptographically, so a validating resolver can confirm the answer actually came from the zone's legitimate operator and wasn't altered in transit.
How the Chain of Trust Works
A domain enables DNSSEC by generating signing keys (published as DNSKEY records) and registering a matching DS record with its registrar. That DS record is what links the domain into the parent zone's (the TLD's) own chain — the root zone trusts the TLD, the TLD's DS record trusts the domain's DNSKEY, and every response is signed against that chain. A resolver performing full validation walks the entire chain before trusting an answer; one broken link anywhere invalidates everything below it.
Why a Broken Chain Is Worse Than No DNSSEC
Publishing DNSKEY records without a correctly matching DS record at the registrar — or vice versa — doesn't leave a domain in some in-between "partially protected" state. It breaks the chain outright, and a validating resolver encountering a broken chain will typically refuse to resolve the domain at all rather than silently ignore the failed signature. A domain with DNSSEC misconfigured can become entirely unreachable for visitors on validating resolvers, while working fine for everyone else — a confusing, inconsistent failure mode that a domain with no DNSSEC configured simply doesn't have.
Reading the Result
- DNSKEY records found — the domain has published signing keys at all.
- Chain validated — whether a real resolver, walking the full chain from the root down, actually confirms it. This is the signal that matters; DNSKEY records existing without a validated chain is the broken-chain scenario above, not a working setup.
A domain with keys published but an unvalidated chain almost always traces back to a DS record mismatch at the registrar — the next thing worth checking is the domain's actual name server delegation with a DNS Lookup.
Does This Domain Actually Need DNSSEC?
Most sites function normally without it — DNS spoofing requires an attacker in a specific position to exploit, which isn't a realistic threat for every domain. It matters more for domains that are frequently impersonated, handle sensitive transactions, or are otherwise high-value targets, where DNS-level spoofing carries real consequences.
Frequently Asked Questions
My domain shows DNSKEY records but "not validated" — what's wrong?
The DS record at the registrar most likely doesn't match the DNSKEY actually published — a mismatch anywhere in the chain breaks validation entirely, even though the keys themselves exist. Check the DS record configured at the registrar against what the domain's name servers are actually publishing.
Should every domain enable DNSSEC?
Not necessarily. It's real protection, but it also adds a new way to misconfigure a domain into being unreachable if the chain breaks — a worse outcome than never having enabled it. It's most worth the added complexity for domains that are actual spoofing targets, not a default every domain needs.
Will DNSSEC slow down DNS resolution?
Marginally — validating a signature adds a small amount of overhead compared to plain DNS, but it's generally not noticeable in practice. It's not the reason most domains skip it; the added configuration complexity and misconfiguration risk are the bigger factors.
Test whether a domain's DNSSEC chain actually validates with the DNSSEC Test.