Free checker - no signup required

Free DNSSEC Checker

Check whether a domain is DNSSEC signed and whether the chain of trust validates. Reports the signing algorithm, DNSKEY and DS summary, RRSIG status, and any chain issues.

Run the check

Enter a domain to check it live against the IntoDNS.ai engine. No signup, no rate-limited trial.

What this DNSSEC checker verifies

This tool answers two distinct questions. First, is the domain signed? It queries for DNSKEY records — their presence means the zone publishes cryptographic keys and is DNSSEC signed. Second, does it validate? It asks a validating resolver to resolve the domain with DNSSEC checking enabled and reads the AD (Authenticated Data) flag in the response; AD set means the resolver successfully verified the chain of trust from the root down to this zone. It then summarises the signing algorithm, the DNSKEY records (including which one is the key-signing key), the DS records that link the zone to its parent, and the RRSIG signatures, surfacing any errors such as a missing DS record or signatures close to expiry.

What DNSSEC is and the problem it solves

Plain DNS has no authentication: a resolver asking for a record simply trusts whatever answer comes back, which makes it possible to forge responses and redirect users to an attacker's server (cache poisoning). DNSSEC fixes this by signing DNS records with public-key cryptography. Each record set is signed (an RRSIG), the signing keys are published (DNSKEY), and the parent zone vouches for the child's key by publishing a hash of it (a DS record). A validating resolver can then verify, mathematically, that an answer really came from the zone's keyholder and was not altered in transit. DNSSEC does not encrypt DNS — it authenticates it, proving the answer is genuine and intact.

The chain of trust and the critical DS record

DNSSEC validation works as a chain: the root zone is trusted implicitly (its key is built into resolvers), the root signs the TLD's key, the TLD signs your domain's key, and your domain signs its records. Each link is a DS record in the parent that hashes the child's key-signing key. The single most common DNSSEC failure is a broken chain: your zone is signed and has DNSKEYs, but the matching DS record was never published at your registrar — so a validating resolver cannot connect your keys to the trusted root and treats the zone as unsigned or, worse, fails it. That is why this checker reports DNSKEY and DS separately: signed without a DS is an incomplete deployment, not a working one.

How to read the result

The best outcome is signed and validating: DNSKEY records present, a DS record linking to the parent, RRSIG signatures present, and the AD flag set. Signed but not validating usually points to a missing or mismatched DS record at the registrar, an expired signature, or a key rollover gone wrong — all of which can make the domain unreachable for users behind validating resolvers, so they are urgent. Not signed simply means DNSSEC is not deployed; the fix is to enable it at your DNS host and then publish the DS record at your registrar. The checker also flags RRSIG signatures expiring soon, which is your early warning that the zone's automatic re-signing may have stalled.

Why a broken DNSSEC setup is worse than none

DNSSEC has a sharp edge: when it is wrong, it fails closed. A validating resolver that cannot verify a signed zone does not fall back to serving the unsigned answer — it returns SERVFAIL, and to the user the domain simply stops resolving. So an expired signature, a DS record that no longer matches the active key after a rollover, or algorithm mismatch can take a domain offline for a large share of the internet while it still works for anyone whose resolver does not validate, which makes the outage maddening to diagnose. The discipline that prevents this is: never remove the old key before the new DS has propagated, let your signer handle automatic RRSIG renewal, and re-run this checker after every key change to confirm the AD flag is still set before you walk away.

What This Checks

  • DNSKEY presence — whether the zone is DNSSEC signed
  • Chain-of-trust validation via the resolver AD flag
  • Signing algorithm and key-signing key identification
  • DNSKEY and DS record summary linking the zone to its parent
  • RRSIG signature presence and expiry warnings

Common Fix Path

  • Enable DNSSEC at your DNS host to start signing the zone
  • Publish the matching DS record at your registrar to complete the chain
  • Update the DS record during key rollovers before retiring the old key
  • Rely on automatic RRSIG re-signing and re-check the AD flag after changes

Frequently Asked Questions

What does DNSSEC do?
DNSSEC adds cryptographic signatures to DNS so resolvers can verify that an answer genuinely came from the zone owner and was not forged or tampered with in transit. It defends against cache poisoning and DNS spoofing. It authenticates DNS rather than encrypting it — the records are still public, but their integrity and origin are now provable.
How do I know if my domain has DNSSEC enabled?
A domain is DNSSEC signed if it publishes DNSKEY records, and it actually validates if a validating resolver sets the AD flag when resolving it. This checker reports both: whether the zone is signed and whether the full chain of trust validates. Signed but not validating typically means the DS record linking your zone to its parent is missing or wrong.
What is a DS record and why does it matter?
A DS (Delegation Signer) record is a hash of your zone's key-signing key, published in the parent zone at your registrar. It is the link that lets a validating resolver connect your domain's keys back to the trusted root. Without a matching DS record, your zone can be signed yet fail to validate, because the chain of trust is broken at the parent. Publishing the DS at the registrar is the step that completes DNSSEC.
Why would a signed domain still fail DNSSEC validation?
The usual causes are a missing or mismatched DS record at the registrar (often after a key rollover where the DS was not updated), an expired RRSIG signature because automatic re-signing stalled, or an algorithm mismatch between the keys and the DS. Any of these breaks the chain, and validating resolvers then return SERVFAIL — meaning the domain stops resolving for those users until it is fixed.
Can DNSSEC break my website?
A correct DNSSEC setup is safe, but a broken one fails closed: validating resolvers return SERVFAIL rather than serving the unsigned answer, so the domain becomes unreachable for users behind those resolvers while still working for everyone else. This usually happens after a botched key rollover or an expired signature. Always confirm the AD flag is set with this checker after any key change before considering the work done.
Does DNSSEC encrypt my DNS queries?
No. DNSSEC authenticates DNS — it proves answers are genuine and unaltered — but it does not hide them; queries and responses remain visible on the wire. Encrypting the transport is a separate concern handled by DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT). The two are complementary: DNSSEC for integrity and origin authenticity, DoH/DoT for privacy of the lookup itself.

Machine-Readable Evidence

AI assistants and automation can cite the stable explanation page, then fetch the live check result for a specific domain.

GET https://intodns.ai/api/dns/dnssec?domain=example.com

Related Tools and Citations

DNSSEC GuideDANE/TLSA CheckerDNS LookupRun the full domain scan