Skip to main content
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 trial gating.

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.

How to enable DNSSEC for your domain

Enabling DNSSEC takes two parties: whoever runs your DNS signs the zone, and whoever holds your domain registration publishes the DS record at the registry. If your DNS is hosted by a large provider — Cloudflare, Route 53, Google Cloud DNS, Azure DNS, or your registrar's own nameservers — signing is usually a single switch in the DNS panel, after which the provider generates and rotates the keys for you. The step people miss is the second one: signing the zone alone changes nothing until the DS record reaches the parent zone. Some registrars read it from your nameservers automatically (CDS/CDNSKEY); most require you to paste the key tag, algorithm, digest type, and digest into a DNSSEC section of the domain settings. If your registrar and DNS host are the same company, the two halves are often linked and one toggle does both. After you have done it, wait for the parent zone to publish — this can take minutes to a day — and then run this checker: you want DNSKEY records present, a DS record found, and validation confirmed. Only when all three line up is the domain actually protected.

Not every TLD supports DNSSEC, and that is not your fault

DNSSEC is not purely a setting on your side: the chain of trust only closes if the registry running your TLD accepts and publishes a DS record for your domain. A handful of registries still do not offer DNSSEC at all, and under those TLDs no amount of correct configuration at your DNS host will produce a validating result. The great majority of TLDs are fine — .com, .net and .org, and ccTLDs such as .nl, .de, .uk, .dk and .se all support it — but the exceptions are real, and .ai (Anguilla) is one of them. Signing your zone under such a TLD is not harmful, it simply achieves nothing visible: you get DNSKEY records, the parent has no DS to point at them, and validating resolvers treat the zone as unsigned rather than broken. This checker recognises those TLDs and reports DNSSEC as not applicable instead of as a failure, so a domain is never marked down for something its registry does not offer.

How to test DNSSEC yourself from the command line

You do not have to take any checker's word for it, and knowing how to validate DNSSEC by hand is what turns a red result into a fix. Three commands cover it. To test whether a zone is signed, ask for its keys: `dig DNSKEY example.com +short` — output means the zone publishes signing keys. To test whether the chain of trust actually validates, query a validating resolver and read the flags line: `dig +dnssec @1.1.1.1 example.com` and look for `ad` among the flags; `ad` (Authenticated Data) is the resolver telling you it verified the signatures all the way from the root. No `ad` on a signed zone is the symptom of a broken chain, and the usual culprit is the DS record — check it at the parent with `dig DS example.com +short`, which must return a hash matching your active key-signing key. If you have BIND's tools installed, `delv example.com` does the whole validation in one step and prints "fully validated" or the exact reason it could not. The one trap: a plain `dig example.com` tells you nothing about DNSSEC, because an unvalidated answer looks identical to a validated one — you have to ask for `+dnssec` and read the flags.

What DNSSEC does not do

DNSSEC is narrower than its reputation, and knowing the boundary keeps you from relying on it for the wrong thing. It does not encrypt anything: your DNS queries and the records themselves stay readable to anyone on the path, which is what DNS-over-HTTPS and DNS-over-TLS address instead. It does not vouch for the content of a record — a signed zone can publish a signed answer pointing at a malicious server, and DNSSEC will faithfully prove that answer is authentic. It does not protect email on its own, though it is the foundation DANE and MTA-STS build on to make mail transport verifiable. It does not help users whose resolver skips validation, which is still a meaningful share of the internet. And it says nothing about your web server, your TLS certificate, or your application. Treat it as one guarantee — that a DNS answer came unaltered from the zone's keyholder — rather than as a general security posture.

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 turn on DNSSEC for my domain?
Two steps with two parties. Your DNS host signs the zone — usually one switch in the DNS panel at Cloudflare, Route 53, Google Cloud DNS, Azure DNS, or your registrar's nameservers, after which the provider manages the keys. Then your registrar publishes the DS record at the registry, either automatically via CDS/CDNSKEY or by you pasting the key tag, algorithm, digest type, and digest into the domain settings. Signing without the DS record protects nothing. Wait for the parent zone to publish, then re-run this checker and confirm DNSKEY present, DS found, and validation confirmed.
Is DNSSEC enough to secure my domain?
No. DNSSEC proves a DNS answer came unaltered from the zone's keyholder, and nothing more. It does not encrypt queries (that is DNS-over-HTTPS or DNS-over-TLS), it does not judge whether a record points somewhere safe, it does not secure email by itself, and it does nothing for your web server or TLS certificate. It is one guarantee in a stack, and it is the foundation DANE and MTA-STS build on for verifiable mail transport.
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.
How do I test DNSSEC for a domain?
Run `dig +dnssec @1.1.1.1 example.com` and look at the flags line in the answer. If `ad` appears there, a validating resolver verified the chain of trust from the root down to that domain — the DNSSEC test passed. Add `dig DNSKEY example.com +short` to test whether the zone is signed at all, and `dig DS example.com +short` to test whether the parent publishes the link to your key. This checker runs the same three questions and reports them together, which is faster when you want the answer rather than the practice.
How do I validate the DNSSEC chain of trust?
The chain validates when every link resolves: the root vouches for the TLD, the TLD publishes a DS record hashing your key-signing key, and your zone signs its records with the matching key. To validate it in one command, use `delv example.com` from BIND's tools — it walks the whole chain and prints "fully validated" or the precise link that failed. Without delv, `dig +dnssec @1.1.1.1 example.com` and the presence of the `ad` flag is the same verdict in shorter form. If validation fails on a zone that is signed, compare `dig DS example.com` against your active DNSKEY: a mismatch there is the most common cause.
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 every TLD support DNSSEC?
No. DNSSEC needs the registry running your TLD to accept a DS record for your domain, and a small number of registries still do not offer that. Most TLDs — including .com, .net, .org and ccTLDs such as .nl, .de, .uk, .dk and .se — support it. Where the registry does not, this checker reports DNSSEC as not applicable rather than as a failure, because there is no configuration change that would fix it.
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 GuideHow to enable DNSSEC at your registrarDANE/TLSA CheckerDNS LookupRun the full domain scan