Free domain tool
Read the DS record at the parent, the zone's DNSKEY set, and what a validating resolver says about the chain — including the broken state that takes a domain offline.
An unsigned domain is how most of the internet runs — a missing improvement, not a fault. The dangerous state is a domain whose DS record promises a signed zone that fails validation: resolvers that validate, which includes Google, Cloudflare and most ISPs, answer SERVFAIL and the domain simply stops resolving for their users. This checker is built to catch that state and to say so with the weight it deserves.
CloudSpex does not run its own cryptographic validation. It asks a DNSSEC-validating public resolver over DNS-over-HTTPS and reports the answer — including which resolver it was — so a "validated" here is always someone's validation, named. For the wider DNS picture, use the DNS Health Check; to find a nameserver that is listed but not serving the zone, use the Nameserver Checker.
DNSSEC adds cryptographic signatures to DNS, so a resolver that validates can detect a forged answer. The chain starts with a DS record at the parent zone and continues with the zone's own DNSKEY records and signatures.
Not by itself. Most of the internet's domains are unsigned. An unsigned domain's answers can in principle be forged by an on-path attacker, so signing is a real improvement — but its absence is a missing improvement, not a misconfiguration, and this checker scores it that way.
It means the validating resolver this checker asked — Google Public DNS or Cloudflare — returned the AD (authenticated data) flag, stating that it validated the chain. CloudSpex reports that resolver's result by name. It does not run its own cryptographic validation, and nothing here should be read as if it did.
Because resolvers that validate — Google, Cloudflare and most ISPs — refuse to resolve a domain whose chain fails validation. They answer SERVFAIL, so the website, email and everything else on the domain becomes unreachable for a large share of users. An unsigned domain merely lacks a protection; a badly signed one is down.
DNSKEY records are the zone's public keys, published in the zone itself. The DS record is a fingerprint of the key, published at the parent zone — for example .com — which is what links the chain of trust from the parent to your zone. Both must agree for validation to succeed.
RFC 8624 retires some older signing algorithms, such as RSASHA1. Validators still accept them today, so the domain keeps working, but their cryptographic margin is gone and support is being withdrawn — worth rolling to a current algorithm like ECDSAP256SHA256.
No. This checker queries a DNSSEC-validating public resolver over DNS-over-HTTPS and reports what that resolver answered: the records it returned and whether it marked them authentic. The validation is the resolver's, and the page names which resolver it was.
It means the observations contradict each other — for example a DS record is published but the resolver did not mark the answers authentic. Rather than guessing which signal to trust, no score is produced and the observations are listed as they were seen.