DNSSEC Checker

Server assisted New DNS & Domains

Walk the DNSSEC chain of trust from the root zone down to the domain: the DS records at each parent, the DNSKEY set of each zone with key tags and KSK/ZSK roles, and whether signatures (RRSIG) are returned. A validating resolver is asked with checking enabled and disabled, so a broken (bogus) zone can be told from an unsigned one, and each link is reported as secure, insecure, bogus or unknown.

Privacy: The name you look up is sent from the Mutqan server to the public DNS resolvers named in the results. Nothing is stored.

What is DNSSEC?

DNSSEC (RFC 4033–4035) adds signatures to DNS records so that a validating resolver can prove an answer came unaltered from the zone. Trust flows down a chain: the root zone's key vouches for each TLD through a DS record, the TLD for each domain, and so on; a zone with no DS at its parent is insecure (unsigned), and one whose chain does not validate is bogus and stops resolving on validating resolvers.

Security note: A broken DNSSEC chain (bogus) takes the whole domain offline for users of validating resolvers; change keys or DNS providers only with a planned rollover.

How to use DNSSEC Checker

  1. Type the domain or host name, such as example.com or www.example.com.
  2. Press Check DNSSEC. The Mutqan server walks the chain with Cloudflare's validating resolver.
  3. Read the result and the AD flag, then go through the chain table from the root down: the first link that is not secure is where protection stops or breaks.
  4. Follow the next steps: publish the DS at your registrar, fix a bogus chain, or plan a key rollover.

DNSSEC Checker features

  • The chain of trust from the root zone through the top-level domain to the domain, one row per zone
  • DS records at each parent and the DNSKEY set of each zone, with key tags, algorithms and KSK/ZSK roles
  • Each link marked secure, insecure, bogus or unknown, with the reason in plain language
  • Bogus told apart from unsigned and from a nameserver failure, by asking the resolver with validation on and off
  • The resolver's AD flag for the name itself — the answer a validating resolver gives your users
  • Signing algorithms RFC 8624 marks MUST NOT or NOT RECOMMENDED for signing (RSA/SHA-1, RSA/SHA-512, DSA, GOST), SHA-1 DS digests and keys with the REVOKE flag reported
  • A failed query is reported as unknown for that level, never as signed or unsigned

Inputs and outputs

Inputs

  • Domain name — a domain or host name, typed as a name or a URL; internationalised names are accepted. IP addresses are refused, because DNSSEC protects names.
  • Fixed by the tool — the resolver (Cloudflare 1.1.1.1), the queries (A for the name, DS and DNSKEY for each zone, the root's DNSKEY) and the DNSSEC flags (DO on, CD on and off); there is nothing else to set.

Outputs

  • Summary — the result, whether the answer was authenticated (AD flag), the number of zones in the chain and the DNS queries made.
  • Chain of trust — one row per zone from the root: status, DS records at the parent (key tag, algorithm, digest type), DNSKEY records (role, key tag, algorithm), whether signatures were returned, and a note.
  • Findings — what the resolver's answers show, retired algorithms and digests, keys being revoked and levels that could not be checked.
  • What to do next — the step that follows from the result.

DNSSEC Checker example

A domain signed with ECDSA P-256 under a signed TLD (cloudflare.com, October 2026)

Input:

cloudflare.com

Output:

Result: Signed and validated (the resolver authenticated the answer) · Authenticated (AD flag): Yes · Zones in the chain: 3 · DNS queries: 7
Chain of trust:
root zone (.) — secure: the trust anchor — Root zone keys (the trust anchor).
com — secure: signed and linked to the parent — DS 19718 · ECDSAP256SHA256 · SHA-256 — DNSKEY …, KSK 19718 (ECDSAP256SHA256)
cloudflare.com — secure: signed and linked to the parent — DS 2371 · ECDSAP256SHA256 · SHA-256 — DNSKEY ZSK 34505 (ECDSAP256SHA256), KSK 2371 (ECDSAP256SHA256)
Findings: The resolver validated the answer for this name (AD flag set) — cloudflare.com

How to read the DNSSEC Checker results

Signed and validated: every link from the root is secure and the resolver set the AD flag; users of validating resolvers get authenticated answers for this name.

Not signed (insecure): somewhere the chain has no DS record — usually at the domain itself. Answers are accepted without authentication; this is the state of most domains and is not an error.

Signed zones, answer not authenticated: every zone shown is signed and linked, yet the resolver did not authenticate the answer for the name itself — often because the name is a CNAME into a zone without DNSSEC. Users get that answer without authentication.

Broken (bogus): a DS exists but the keys or signatures below it do not validate. Validating resolvers — 1.1.1.1, 8.8.8.8, 9.9.9.9 and many ISP resolvers — answer SERVFAIL, so the name stops resolving for their users.

Lookup fails: the name fails with validation on and off alike, which points at the nameservers rather than DNSSEC.

DNSKEY published but no DS at the parent: the zone is signed, but nobody can verify the signatures until the DS is published at the registrar.

When to use DNSSEC Checker

  • Confirming that DNSSEC works after you turned on signing and published the DS at the registrar.
  • Diagnosing a domain that suddenly stopped resolving on 1.1.1.1 or 8.8.8.8 but works elsewhere.
  • Checking a domain before moving it to another DNS provider or registrar, when an old DS can break it.
  • Auditing which of your domains are signed, and with which algorithms.

Troubleshooting

  • "Broken (bogus)" right after a change of DNS provider: the registrar still holds the DS of the old provider's key. Replace it with the new provider's DS, or remove it until the new zone is signed; resolvers recover as the old DS expires from their caches.
  • "DNSKEY published but no DS at the parent": copy the DS (or the DNSKEY, if the registrar asks for that) from your DNS provider into the registrar's DNSSEC settings.
  • "No DNSKEY matches the key tag and algorithm of the DS": the DS at the registrar belongs to an old or different key. Publish the DS of the current KSK.
  • The result is "Could not be determined": a query for one level failed or timed out. Run the check again; a level that keeps failing has nameservers that do not answer DNSSEC queries properly.
  • The request-limit message: a DNSSEC check costs 7 to 11 DNS queries from a budget shared with the other DNS tools; wait the seconds shown.

Frequently asked questions about DNSSEC Checker

What is the difference between insecure and bogus?

Insecure means the zone is not signed or not linked to its parent (no DS record): resolvers accept its answers without authentication. Bogus means the zone claims to be signed but the chain does not validate; validating resolvers such as 1.1.1.1, 8.8.8.8 and Quad9 then answer SERVFAIL, so the domain stops resolving for their users.

Why is my domain signed but still insecure?

Signing the zone publishes DNSKEY and RRSIG records, but the chain of trust only starts when the DS record of the key-signing key is published in the parent zone. Most registrars need you to add the DS record (or enable DNSSEC) in their control panel; until then the checker shows DNSKEY published but no DS at the parent.

How does the checker decide that a zone is secure?

It asks Cloudflare's validating resolver with DNSSEC requested: the AD flag says the resolver validated the answer, and the DS and DNSKEY records show that a key matching the parent's DS exists at every level. A second query with checking disabled tells a bogus zone from a nameserver failure. The tool reports the resolver's validation; it does not verify the signatures itself.

What should I do before moving a signed domain to another DNS provider?

Plan the key change: either remove the DS record at the registrar and wait for its TTL to expire before switching, or have the new provider publish your keys during the move (a multi-signer rollover). Switching nameservers while the old DS stays at the parent makes the domain bogus.

Which names are checked?

The root zone, the top-level domain and each level down to the name you enter, up to four zone levels; for deeper names the levels in between are skipped and the report says how many. Levels that are not zones of their own are covered by the zone above them and are left out with a note.

Technical notes

DNSSEC (RFC 4033, 4034 and 4035) signs every record set of a zone with RRSIG records made by the zone's keys, published as DNSKEY records: usually a key-signing key (KSK, flag 257) that signs the key set and a zone-signing key (ZSK, flag 256) that signs the rest. The parent zone vouches for the child with a DS record, a digest of the child's KSK; the root zone's keys are the trust anchor validating resolvers start from, so trust flows root → TLD → domain.

The checker asks Cloudflare's validating resolver for the name with DNSSEC requested: the AD flag says the resolver validated the answer. For the root, the TLD and each level down to the name (at most four zone levels) it fetches the DS and DNSKEY records and checks that a key matches the DS key tag and algorithm. A second query with checking disabled (CD bit, RFC 6840) tells a bogus zone, which fails only with validation on, from a nameserver failure, which fails both ways, and from an unsigned zone, which answers the same both ways without AD.

The signatures themselves are verified by the resolver, not by the tool; the page reports the resolver's verdict and the records it is based on. Levels that are not zones of their own are left out with a note, and for names deeper than four levels the middle ones are skipped and counted.

Limitations and methodology

Validation is Cloudflare's: the tool reports the resolver's AD flag and SERVFAIL behaviour and does not verify signatures itself. Another resolver with a stale cache may briefly disagree.

At most four zone levels are checked; for deeper names the middle levels are skipped, and a problem in a skipped level shows only through the final result.

Only the name's A query is validated; a broken signature on another record type of the same name (MX, TXT…) would not show up here.

The check runs from the Mutqan server at the Cloudflare edge, not from your network, so it does not show whether your own resolver validates DNSSEC.

Security and privacy

The name you enter goes to the Mutqan server, which asks Cloudflare's public DNS over HTTPS for the DS and DNSKEY records of the name and the zones above it. Nothing is stored.

References