Verify whether a domain is signed and validated end-to-end
DNSSEC ("DNS Security Extensions") protects DNS responses against tampering by signing each record with cryptographic signatures. The chain of trust starts at the root zone (.), runs through the TLD (e.g. .com), and ends at your domain. Each link publishes a DS record in the parent zone that fingerprints the child zone's signing key. Our checker queries DS records in the parent and DNSKEY records in the zone to confirm both halves of the link exist.
Beyond just checking that records exist, the tool asks Cloudflare's validating resolver to authenticate the response. If Cloudflare returns the AD (Authenticated Data) flag, every signature in the chain — root → TLD → your domain — verified successfully. The four possible outcomes are: secure (full chain works), bogus (signatures invalid or expired), broken (DS in parent but no DNSKEY in zone), and unsigned (no DNSSEC at all). Each outcome means a different fix.
The result page shows every DS record (key tag, algorithm, digest type, digest hash) and every DNSKEY in the zone, labelled as KSK (Key Signing Key) or ZSK (Zone Signing Key). It flags deprecated algorithms — SHA-1 (algorithm 5/7), DSA, and SHA-1 digests — which modern resolvers may treat as insecure. Replace any of those with ECDSAP256SHA256 (algorithm 13) plus SHA-256 digests for the strongest setup.
Without DNSSEC, an attacker who can intercept your DNS traffic — at a coffee-shop Wi-Fi, a compromised router, or a malicious ISP — can return forged responses pointing your domain at their servers. DNSSEC signs each DNS response with a key tied through the chain of trust to the root zone, so resolvers can detect any tampering. It is especially important for domains that handle email (where forged MX records redirect mail to attackers) and for domains used by software updates or financial services.
A KSK (Key Signing Key) signs only the DNSKEY record set and corresponds to the DS record in the parent zone — it is the trust anchor for your domain. Because rotating a KSK requires updating the DS at the registrar, KSKs are kept long-lived and stored carefully. A ZSK (Zone Signing Key) signs everything else (A, AAAA, MX, TXT records). ZSKs rotate frequently — often automatically every few months — without requiring any registrar interaction. Splitting the work between KSK and ZSK is a security/operations tradeoff: short keys for daily use, long keys for the chain of trust.
"Broken" means you removed your DNSKEY without first removing the matching DS at your registrar — resolvers see the DS, fetch the zone, find no key, and refuse to serve the domain. Add the DNSKEY back or remove the DS. "Island" means the opposite: you signed your zone but never published the DS at the registrar, so external resolvers cannot tie your keys to anything trusted. Generate the DS from your KSK and submit it to your registrar — most registrar control panels have a "DNSSEC" or "DS records" form.
CDN providers like Cloudflare, Akamai, and Route53 implement DNSSEC at their authoritative servers, so signing happens automatically once you toggle it on. ALIAS or ANAME records (CNAME-flattening at the apex) are usually compatible because the provider returns A/AAAA records on the fly and signs them. The friction point is multi-vendor setups — using two DNS providers in primary/secondary mode breaks DNSSEC unless both providers share the same keys, which most do not support.
No. DNSSEC provides authenticity (responses cannot be forged) but not privacy — anyone on the wire can still see your queries and answers in plain text. For privacy you need DNS over HTTPS (DoH) or DNS over TLS (DoT), which encrypt the channel between your device and the resolver. DNSSEC and DoH/DoT solve different problems and complement each other: DoH stops the local network from seeing what you query; DNSSEC stops the resolver or anyone upstream from lying about the answer.
