DNSSEC Checker

Check whether a domain is protected by DNSSEC. Enter a domain and this tool asks a validating resolver to authenticate it and reads three signals: the AD (Authenticated Data) flag, the DS record that links the chain of trust at the registrar, and the zone's DNSKEY. Together they tell you whether DNSSEC is fully working, signed but broken, or simply not enabled.

How to use the DNSSEC Checker

Enter a domain and press Check DNSSEC. The tool reports a verdict plus three underlying signals:

• AD flag — whether a validating resolver authenticated the answer's signatures. This is the clearest sign DNSSEC is actually working.
• DS record — whether the parent zone (set via your registrar) publishes a delegation-signer record, which anchors the chain of trust.
• DNSKEY — whether the zone publishes signing keys.

The verdict combines them: valid (AD set), signed but not validating (keys present but the answer was not authenticated — usually a broken chain), or not signed (no DNSSEC at all).

What DNSSEC is and what these signals mean

Plain DNS has no built-in way to prove an answer is genuine. A resolver simply trusts whatever comes back, which is what makes cache poisoning and on-path spoofing possible — an attacker who can inject a forged reply can send users to the wrong server. DNSSEC (DNS Security Extensions) fixes this by cryptographically signing DNS records, so a validating resolver can verify the records really came from the zone's owner and were not tampered with.

DNSSEC works as a chain of trust from the root down to the domain. Each link is one of the records this tool checks:

• DNSKEY — the public keys a zone uses to sign its records. Their presence means the zone is signed.
• RRSIG — the actual signatures attached to each record set (verified by the resolver behind the scenes).
• DS (Delegation Signer) — a hash of the zone's key, published in the parent zone. This is the critical link: it is what you set at your registrar, and it tells the parent "trust this child zone's keys." Without a matching DS, the chain is broken even if the zone is signed.
• AD flag — when a validating resolver successfully checks the whole chain, it sets the Authenticated Data bit on its answer. Seeing AD set is the practical proof that validation succeeded end to end.

That structure explains the three verdicts. If the zone is signed (DNSKEY present), the registrar publishes a matching DS, and signatures are valid, a validating resolver sets AD and you are fully protected. If the zone has keys but the resolver did not authenticate the answer, the chain is broken — most often a missing or stale DS at the registrar, or expired RRSIG signatures (DNSSEC signatures expire and must be re-signed automatically; if that breaks, the domain can become unreachable for validating resolvers, a more dangerous failure than having no DNSSEC at all). If there are no keys and no DS, the domain simply is not signed. Enabling DNSSEC is a two-step act: turn it on at your DNS host to publish the keys, then copy the resulting DS record to your registrar to complete the chain.

Common use cases

• Confirming DNSSEC is live — verify the AD flag is set so you know validation actually works, not just that keys exist.
• Finishing setup — after enabling signing at your DNS host, check that the DS record made it to the registrar.
• Diagnosing a broken chain — catch a signed-but-not-validating state before it makes the domain unreachable.
• Auditing a domain — see at a glance whether a domain is protected against DNS spoofing.
• Pre-migration check — confirm DNSSEC status before moving DNS providers, since a careless move can break the chain.

Fixing a broken or missing DNSSEC chain

The two states worth acting on are "not signed" and "signed but not validating". Here is what each needs:

• Not signed and you want protection. Enable DNSSEC in your DNS host's dashboard, which publishes the DNSKEY and RRSIG records. Then take the DS record it generates and add it at your registrar (in the domain's DNSSEC settings). The chain is only complete once the DS is in place.
• Signed but not validating. The chain is broken. The usual causes are a missing or mismatched DS at the registrar (for example after a key rollover the DS was not updated) or expired signatures because automatic re-signing stalled. Re-publish the correct DS, or fix signing at the DNS host. Until it validates, strict resolvers may refuse to resolve the domain at all.
• Moving DNS providers. Turn DNSSEC off (remove the DS at the registrar and wait for it to clear) before migrating, then re-enable and re-add the new DS at the new host. Migrating with DNSSEC live and mismatched keys is a classic way to take a domain offline.

DNSSEC protects the integrity of DNS answers; it is complementary to transport encryption like the DNS-over-HTTPS this tool uses. To read the underlying records yourself, the general DNS Lookup can query DS, DNSKEY and other types directly.