DNSSEC Checker
Find out why validation is failing

What DNSSEC Actually Does — and What It Does Not

DNSSEC adds a signature to every answer a zone gives out, so a resolver can tell whether what arrived is what the zone actually published. Without it, DNS has no way to know: a resolver asks a question into the network and believes whatever comes back. That is the weakness behind cache poisoning, and it is the one thing DNSSEC was built to close.

It is equally important to be clear about what it does not do. DNSSEC does not encrypt anything. Every query and every answer still travels in the clear, and anyone on the path can see which names you look up. Hiding the query is a different job done by DNS over HTTPS and DNS over TLS, which in turn say nothing about whether the answer is genuine. The two protect opposite halves of the same conversation, and a domain can use either, both or neither.

The mechanism is a chain. Your zone signs its records with its own keys. The registry above you — the operator of your domain’s extension — publishes a short fingerprint of one of those keys, called a DS record. The root zone does the same for the registry. A resolver that trusts the root can follow that chain down to your records and verify each link. Break any link and the resolver does not fall back to an unsigned answer: it refuses to answer at all. If you want the underlying query path first, our guide on how DNS resolves domain names to IPs covers it, and what IP spoofing is and how to detect it explains the class of attack this is defending against.

How to Read Your DNSSEC Check Result

The verdict is one of eleven states. Most tools in this category collapse several of them into a single red cross, which hides the difference between a domain that is simply not using DNSSEC and one that is signed and failing — situations that call for opposite responses.

Two panels sit under the tables and they are the point of the page: Verified here lists what this tool computed itself, and Not verified here lists what it did not. A checker that does not tell you which is which is asking you to take its word for the whole thing.

The Chain of Trust, and the One Link That Usually Breaks

A zone publishes two kinds of key. The key signing key (KSK) signs the set of keys itself, and it is the one the parent vouches for. The zone signing key (ZSK) signs the ordinary records — your A records, your MX records, everything else. Splitting them means the zone signing key can be replaced as often as you like without ever touching the registrar.

The DS record at the registry is a digest of the key signing key. It is not a copy of the key: it is a short hash, so the registry holds something small and stable. This tool takes the DNSKEY your zone publishes right now, computes that digest itself, and compares the result with the DS the registry publishes, byte for byte. Two failures are possible and they are not the same thing:

• The DS names a key tag your zone does not publish. The registry is vouching for a key that no longer exists — almost always a key rollover where the new DS never reached the registrar.
• A key with that tag exists, but the digest differs. The tag is only sixteen bits, so two different keys can share one. This is the rarer and more confusing case, and it is invisible unless the digest is actually recomputed.

Both produce the same symptom for your visitors: the domain stops resolving. Neither is visible in an ordinary record lookup — our DNS lookup tool will happily show you the records themselves without any of this arithmetic, because that is a different question.

Signatures Expire — and Why One Day Left Can Be Perfectly Normal

Every DNSSEC signature — an RRSIG record, one for each set of records it covers — carries two timestamps: when it becomes valid and when it stops being valid. Unlike a TTL, that expiry is absolute. When it passes, a validating resolver stops accepting anything from the zone, even though every record is still published exactly as before. An expired signature is one of the most common causes of a sudden, total, apparently inexplicable outage.

The obvious way to warn about it is to flag anything expiring within a week. That rule is wrong, and measurably so. Several large operators sign their ordinary records with a rolling two-day window and re-sign continuously, while signing the key set for far longer — so a perfectly healthy zone routinely shows an A-record signature about a day from expiry. A seven-day rule would raise an alarm on some of the best-run zones on the internet, which is why this tool does not use one.

So this tool reports remaining life as a share of each signature’s own window, and it judges the signature over the key set and the signature over the A record separately, because the two often have very different lifetimes. One day left of a two-day window is fifty per cent — the middle of a normal cycle. One day left of a thirty-day window is three per cent, and that means the signer has already missed several chances to renew. The number that matters is the proportion, not the days.

Turning DNSSEC On Without Taking Your Domain Offline

The order matters more than anything else here, because the dangerous states are the in-between ones. Signing before the registry knows about your key is harmless. Telling the registry about a key you are not using yet is not.

1. Enable signing at your DNS host. The zone starts publishing DNSKEY records and signatures. Nothing changes for visitors: without a DS at the registry, resolvers still treat the zone as unsigned.
2. Check that the zone really is signing before going further — that is the “signed but unlinked” state above, and it is exactly where you want to be at this point.
3. Copy the DS record to your registrar. Most hosts show it ready to paste; some show the DNSKEY and let the registrar compute the digest. Both are fine, as long as what ends up at the registry is a digest of a key you are actually publishing.
4. Check again. The moment the DS appears, validation is live — and so is the risk. This is the step where a mismatch takes the domain down.

Reversing it runs the opposite way: remove the DS at the registrar first, wait for it to expire from caches, and only then stop signing. Since the DS lives in the parent zone, the wait is governed by the parent’s TTL rather than yours, and that is usually a few hours rather than days — the result above shows nothing about it, so check the DS TTL yourself before you stop signing. Our DNS propagation checker will show you when the old record has actually cleared, and a WHOIS lookup will tell you which registrar to make the change at if you are not sure.

Why Your Domain Vanished: SERVFAIL Explained

When DNSSEC validation fails, a resolver does not tell you the signature was bad. It returns SERVFAIL, which means only “I cannot give you an answer”. The same code covers a dead nameserver, a timeout and a broken signature, which is why the failure is so often misdiagnosed. Worse, the domain still works perfectly for anyone whose resolver does not validate — so half your colleagues see a problem and half do not.

There is a clean way to separate the causes, and this tool uses it. Re-ask the same question with the CD flag — Checking Disabled — which instructs the resolver to return the data without validating it. If the records appear with CD set and disappear without it, the records exist and it is validation refusing them. That is the difference between “your nameserver is down” and “your signatures are wrong”, in one extra query.

When our checks pass and resolvers still refuse

This is a real state and the tool reports it rather than hiding it. The DS can match, the signature over the key set can verify, and validating resolvers can still reject the zone — because something further down is wrong: a record signed by a key the zone does not publish, a signature over one individual record set that does not verify, or a problem in the records that prove a name does not exist. When that happens the result says so plainly instead of awarding a pass on the strength of the checks that did succeed.

What This Checker Verifies, and What It Does Not

Every result carries two panels, and the second one is the more useful of the pair. A DNSSEC validator that reports only pass or fail is asking you to trust the whole of its reasoning without showing you any of it.

Verified here, by computation

• The DS digest, recomputed from the DNSKEY the zone publishes and compared with the registry’s copy byte for byte.
• The signature over the key set, checked cryptographically against the key it names. Seven algorithms are implemented: RSA/SHA-256 (8), RSA/SHA-512 (10), ECDSA P-256 (13), ECDSA P-384 (14), Ed25519 (15) and the two deprecated SHA-1 algorithms (5 and 7). Anything else — RSA/MD5, DSA, ECC-GOST, Ed448 — is reported as not checked here rather than quietly counted as a pass.
• A second signature over the A record, normally made with a different key, so the zone signing key is exercised as well as the key signing key.
• Signature validity windows, as a share of each window rather than a fixed number of days.

Not verified here, and why

• The link from the root down to your registry. Verifying it means trusting a key published by IANA, and a tool that hardcodes a fingerprint it cannot re-check at source is asserting something it does not know. Instead the result shows what three independent validating resolvers concluded — each of which does check that link, against its own trust anchor.
• Signatures over record types whose data contains a host name — SOA, NS, MX, CNAME. Those names can arrive compressed and must be rewritten into canonical form before the signature can be checked. Getting that wrong produces a confident “invalid” on a healthy zone, so this build does not attempt it.
• Denial-of-existence records (NSEC and NSEC3), which prove a name does not exist. They are a common source of failure and they are not checked here.

That last group is exactly why the resolver column exists. Where our own arithmetic runs out, three independent validators are still watching, and the verdict takes their answer seriously. If you are choosing a resolver for your own network rather than auditing a domain, our guide to DNS security solutions covers a different problem — filtering malicious domains, rather than proving answers are genuine.

Frequently Asked Questions About DNSSEC