DNSSEC checker

Type a domain: you see whether its zone is signed, whether the signature chain holds from the parent zone down, and which algorithms it uses. A broken chain makes the domain disappear for every resolver that validates.

The DNS lookups go straight from your browser to public resolvers (Cloudflare, Google): we see nothing.

What the checker looks at

The DS record: Published in the parent zone (.org, .fr…) by your registrar: it says “this zone is signed, with this key”. Without it, nothing is validated, even if the zone carries signatures.
The DNSKEY records: The public keys of the zone: a key-signing key (flags 257), the one the DS points to, and usually a zone-signing key (flags 256).
Validation: The same question is asked twice to a validating resolver, with validation on and off. Answered only with validation off: the chain is broken.
Algorithms: The signing algorithm of each key and the digest of each DS. RSA/SHA-1 and SHA-1 digests still validate but are no longer recommended (RFC 8624).

How to read the result

Signed and validated: A DS at the parent, matching keys, and the resolver confirms the answers (the AD flag). Nothing to do but watch it: key changes are when chains break.
Not signed: No DS at the parent. The domain works, but nothing stops a forged DNS answer on the way. Turning DNSSEC on is done at your DNS provider, then at your registrar.
Broken: The resolver refuses the answers. Visitors behind validating resolvers (most large ISPs, 1.1.1.1, 8.8.8.8) cannot reach the site or deliver mail. This is worse than no DNSSEC at all.

Errors people run into

The messages resolvers and test tools give when a chain does not hold, and what to do.

SERVFAIL

Why. A validating resolver found a DS at the parent but could not validate the answers: the DS points to a key the zone no longer publishes, signatures have expired, or the zone moved to a provider that does not sign it.

Fix. If you changed DNS provider: remove the DS at the registrar, wait for its TTL, then turn DNSSEC on at the new provider and publish the new DS. Otherwise re-sign the zone and check that the DS matches the current key-signing key.

No DS record found at the parent

Why. The zone is signed at your DNS provider, but the registrar was never given the DS: the chain stops above your zone and nothing is validated.

Fix. Copy the DS (key tag, algorithm, digest type, digest) from your DNS provider to your registrar. Some pairs of providers do it for you (CDS/CDNSKEY).

DS algorithm does not match any DNSKEY

Why. The DS at the parent was made for a key with another algorithm than the keys the zone publishes now, usually after an algorithm change or a move.

Fix. Publish the DS of the current key-signing key at the registrar and remove the old one, in that order, leaving time for the TTLs.

Questions

Does DNSSEC encrypt my DNS?

No. It signs the answers so that a resolver can check they were not altered; the questions and answers stay readable. Encryption of the transport is DNS over TLS or HTTPS.

Is an unsigned domain a vulnerability?

It is a missing protection, not a hole: the domain works, but a forged answer cannot be told from a real one. It matters more where the DNS carries security decisions: MX, CAA, TLSA, the records of your mail.

Can turning DNSSEC on break my domain?

Yes, if the DS and the keys stop matching. The risky moments are a change of DNS provider and a key change. Remove the DS before a move, and check after each change.

Do you send anything to our servers?

No. The lookups go from your browser to public resolvers (Cloudflare, Google); we see neither the domain nor the result.