DNS was built in the 1980s to solve one problem: turn a name people can remember into an address a machine can reach, quickly and at scale, across a small network of institutions that mostly trusted each other. Security wasn't part of the brief. Queries went out unencrypted and unauthenticated over UDP port 53, and for the most part they still do.
That design left a gap. If a resolver can't tell whether an answer really came from the domain it asked, an attacker can slip in a forged one. This is DNS cache poisoning - Dan Kaminsky showed in 2008 how practical it was - where bogus IP data gets injected into a resolver's cache. Type yourbank.com, get sent to a server the attacker controls, and nothing on screen looks wrong. You entered the right address and saw no error. That's what makes it dangerous.
DNSSEC (DNS Security Extensions) is the IETF's fix that didn't require rebuilding the internet. It doesn't encrypt anything - the names you look up are still visible - and it isn't about privacy. What it does is sign DNS records with public-key cryptography so a resolver can prove an answer is genuine and unmodified. If you want to see whether a given domain has that protection switched on and wired up correctly, the DNSSEC check reports its status in plain language.
How the chain of trust works
Start with the signatures themselves. DNS records travel in groups called RRSets - all the A records for a name, say, or all the MX records. Each set gets a matching signature stored in an RRSIG record. A validating resolver pulls the records and their RRSIG together, then verifies the signature using the domain's public key, which lives in a DNSKEY record.
The obvious question: why trust that DNSKEY? Because it's anchored to a chain that climbs all the way to the internet root. It works in layers:
- Zone Signing Key (ZSK) signs the individual record sets, producing the RRSIG entries. Its public half is published in a
DNSKEYrecord. - Key Signing Key (KSK) signs the ZSK. Its public half sits in a
DNSKEYrecord too. Splitting the roles lets you rotate the busy ZSK often while the KSK stays put. - Delegation Signer (DS) record is a hash of your KSK. You hand it to your parent registry - the operator of
.comor.org- who publishes it as a DS record on their side. - Root anchor: the registry's own keys chain up to the ICANN root, whose key resolvers ship hardcoded.
So validation for yourdomain.com traces upward: your zone's signatures check against your DNSKEY, your KSK is vouched for by the DS record at .com, and .com vouches up to the root that everyone already trusts.
There's one more piece. DNSSEC also has to prove when a name doesn't exist, so an attacker can't forge a "no such record" reply. That's handled by NSEC and NSEC3 records - authenticated denial of existence. NSEC3 hashes the names it lists so nobody can walk the zone and enumerate every hostname you run.
What the check looks at
Break any link in that chain and validating resolvers - Google on 8.8.8.8, Cloudflare on 1.1.1.1 - stop returning your records at all. Instead of a wrong answer they return SERVFAIL, and for a large slice of the internet your domain simply goes dark. There's no partial credit here; DNSSEC either validates or it fails shut.
When you run a domain, the tool inspects the records that make up the chain and tells you how they line up. It checks for DNSKEY presence - both a ZSK and a KSK, and the algorithm in use, such as RSA/SHA-256 or ECDSA P-256. It looks at the RRSIG signatures covering your record sets, including their inception and expiration windows, and flags ones that look expired. It checks whether a DS record exists at the parent and whether it matches the KSK published in your zone. And it confirms NSEC or NSEC3 is in place for negative answers.
Think of it as a status and diagnostic read rather than a full validating resolver doing the signature math itself. It surfaces the common, real-world failures - a missing DS record, signatures past their dates, an absent DNSKEY - and explains what each one means. If you'd rather look at any single record type on its own, the individual DNSKEY, DS, RRSIG and NSEC lookups just fetch and display that record for the domain.
Where DNSSEC usually goes wrong
Most DNSSEC outages trace back to a handful of predictable mistakes.
Expired RRSIG signatures. Signatures are deliberately time-limited, often to a 14-to-30-day window. Something - usually an automated re-signing job - has to renew them before they lapse. When that script quietly fails, the signatures expire, resolvers refuse the answers, and the domain drops offline even though nothing about the records "looks" wrong.
Orphaned DS records. Moving to a new DNS host generates fresh keys. If you switch providers and forget to update the DS record at your registrar, the parent keeps pointing at a hash of the old KSK. The chain no longer connects, and validation fails. This is the classic migration trap.
Weak algorithms. Older RSA/MD5 and RSA/SHA-1 signatures are no longer considered safe. If a domain is still on one of these, moving to something modern like ECDSA is worth doing before it becomes a problem.
Before you rely on it
If you're turning DNSSEC on, or you've just moved DNS hosts, check the chain end to end before you consider the job finished - the DS record at the registrar is the step people miss most. And if a domain ever becomes unreachable for some users but not others, an expired signature or a stale DS record is worth ruling out early. Run your domain through the DNSSEC check, or pull a broader picture with the All DNS Records lookup, and you'll know where the chain stands.