Signed, broken, or not enabled? Tri-state verdict, chain-of-trust walk, DANE-readiness, RRSIG expiry, and registrar-specific fix recipes — without reading the RFC.
Tri-state verdict, chain of trust walk, DANE-readiness, and registrar-specific fix recipes when things go sideways.
Tri-state verdict — green for valid, amber for published-but-broken, neutral grey for the ~95% of domains that aren't signed.
Root → TLD → your zone. Text tree plus an inline SVG graph — drop either into a support ticket.
Registrar-specific steps for Cloudflare / GoDaddy / Namecheap / Route 53 when the chain breaks.
What this doesn't do (v1): full recursive cryptographic trace — for that, DNSViz is the right next step.
“Not enabled” is the global default — we render it in neutral grey, not red. We only go amber when the zone is actively broken (records present, chain broken), which is the genuinely bad state that needs attention.
DNSSEC fails silently. A broken chain returns SERVFAIL to a validating resolver and no signal at all to a non-validating one — your domain just stops resolving for some users and nobody tells you. The checker walks each gate a validating resolver walks. Five things to look for:
Valid, published but broken, not enabled. “Not enabled” is the state most domains are in — neutral grey, no alarm. “Published but broken” is the genuinely bad state; that gets amber. Valid is green and wires through to the DANE checker.
Root → TLD → your domain, with a ✓ or ✗ next to each hop. Copy-pasteable text, not a screenshot of a node graph. Drop it into a support ticket and whoever reads it knows exactly where the chain broke.
Instead of raw 8, you see “RSASHA256 (8) — modern, widely supported.” Instead of 5, “RSASHA1 (5) — deprecated per RFC 8624, rotate to algo 13.” You know at a glance whether your algorithm is fine, getting old, or actually dangerous.
Not “rotate your keys.” Instead: “Your registrar's DS record (keytag 42069) points to a key your zone no longer has. Log in to Cloudflare → DNS → DNSSEC → replace with keytag X.” We keep copy for Cloudflare, GoDaddy, Namecheap, and Route 53; the tool pre-selects the right tab based on your nameservers.
When your result comes back “published but invalid,” we tell you this is the pattern that took Slack offline in 2021, .fj in 2022, and .nz in 2023 — and link each post-mortem. Turns a scary result into a recognisable one.
DNSSEC (DNS Security Extensions, RFC 4033–4035, consolidated in RFC 9364) cryptographically signs DNS records so resolvers can verify they haven't been tampered with in transit. A DNSSEC-protected domain publishes DNSKEY records signed by the zone, with a matching DS record at the parent registrar — forming an unbroken chain of trust from the DNS root down. For email admins, DNSSEC is the gate that unlocks DANE (RFC 7672): without a signed zone, TLSA records are silently ignored by compliant MX servers, and opportunistic TLS downgrade attacks remain possible. Adoption sits near 4% of .com in 2026, growing ~45% YoY — “not enabled” is the global default, not a failure.
The protocol doesn't encrypt DNS queries — that's DoH and DoT's job. DNSSEC answers a different question: “this DNS answer I received, is it the one the authoritative server actually published?” Without DNSSEC, anything in the resolution path — your ISP, a misbehaving middlebox, a compromised public Wi-Fi — can quietly rewrite the answer. With DNSSEC, the resolver either verifies an end-to-end signature chain and sets the AD flag, or rejects the answer entirely and returns SERVFAIL.
In practice, most operational drama around DNSSEC comes from three places: rolling keys without breaking the chain at the registrar, keeping RRSIG signatures re-signed before they expire, and remembering to update the DS at the registrar when you change DNS providers. This tool surfaces all three states and tells you which one you're in, in plain English.
Every DNSSEC query walks the same path. The resolver starts from a pre-configured trust anchor — almost always the IANA root KSK (key-tag 20326 as of this writing) — and verifies the signature on the root's DNSKEY RRset. That signed DNSKEY set includes the DS record for the next level down; resolve that zone, verify its DNSKEY against the DS, repeat until you reach the zone you actually want. At every step, the resolver has to see both a DS record at the parent and a matching DNSKEY at the child. Remove either one and the chain stops.
For a typical two-label domain like example.com, that's exactly three hops: root, com., and the domain. Three-label domains like blog.example.co.uk add one more hop. This tool renders those hops as a readable ASCII tree — useful when you need to paste the result into a ticket, a Slack channel, or an incident doc. Screenshots of node graphs don't survive the round-trip through support channels; text does.
The inline SVG graph adds the intra-zone detail: within your zone, there's usually a KSK (Key Signing Key, flag bit 15 set) and one or more ZSKs (Zone Signing Keys). The KSK signs the DNSKEY RRset and is the specific key the parent DS record points to. The ZSK signs everything else in the zone. Rolling the ZSK is routine automation; rolling the KSK requires coordination with the registrar because the DS has to change too.
DNSKEY records carry four numbers: flags (2 bytes), protocol (always 3), algorithm (one of a dozen IANA-assigned values), and the public key itself. The algorithm is the interesting one — it determines signature size, validation cost, and whether the zone meets current best-practice.
| Aspect | Algo 8 — RSASHA256 | Algo 13 — ECDSAP256SHA256 |
|---|---|---|
| Signature size | ~256 bytes (2048-bit key) | ~64 bytes |
| Validation cost | Baseline | ~10× faster |
| Resolver support | Universal | ~98% (2025); universally safe |
| Best for | Legacy zones already running it | New zones; the modern default |
| Response size impact | Higher — can push over UDP 512/1232 | Fits comfortably under every UDP MTU |
The DNSKEY flags field is 16 bits. The bit you care about is bit 15 (value 0x0001), called SEP (Secure Entry Point). When SEP is set, the key is a KSK — a Key Signing Key — and that's the key the parent DS record has to match. When SEP is clear, it's a ZSK. The flag field alone is how this tool labels each DNSKEY as KSK or ZSK.
Algorithms 1, 3, 5, 6, 7, and 12 are deprecated under RFC 8624 — MUST NOT be used for new signing. Algorithm 10 (RSASHA512) is acceptable but uncommon. Algorithms 14 (ECDSAP384), 15 (ED25519), and 16 (ED448) are modern and safe. When you see a deprecated algorithm in your result, the fix is always the same: rotate to 13 (or 15) using your DNS provider's algorithm-change flow.
DNSSEC has to prove that records don't exist, not just the ones that do. Otherwise, an attacker could strip records out in transit and the resolver would have no way to detect the omission. NSEC and NSEC3 are the two mechanisms DNSSEC defines for this.
| Aspect | NSEC | NSEC3 |
|---|---|---|
| RFC | RFC 4034 §4 | RFC 5155, guidance RFC 9276 |
| Zone walking | Trivial — names are in plaintext | Requires dictionary attack on hashes |
| Iteration count | N/A | Should be 0 per RFC 9276 |
| Best for | Small zones, nothing to hide | Default — privacy-preserving |
| Response complexity | Simple | Hash comparisons in the resolver |
The NSEC3 iteration count was originally intended to slow down zone-walking attacks by making hash computation expensive. Reality turned out otherwise: the cost falls on validating resolvers, which have to recompute the hash to verify every denial. RFC 9276 (July 2022) recommends iteration count 0; some modern resolvers cap incoming iterations at 100 and will refuse or downgrade zones that exceed that. If your zone has high iterations, lower them during the next re-signing.
Across SIDN, Cloudflare, and academic field studies, production DNSSEC outages cluster into a small set of named patterns. Every zone that fails DNSSEC fails in one of these five ways:
The parent registrar holds a DS record pointing to a key-tag / algorithm that your zone no longer publishes. Classic stale-DS-after-rollover pattern. Fix: either re-publish the DNSKEY the DS points at, or update the DS at the registrar to match a current DNSKEY.
The zone's signatures have passed their expiration date. Validating resolvers treat the zone as BOGUS. Usually means your provider's automated re-signing pipeline paused or broke. Fix: toggle signing off/on at the provider or manually re-sign.
Multiple KSKs are visible but the overlap window went wrong — e.g., the new DS was published at the registrar before the new DNSKEY appeared in the zone. Fix: RFC 7583 choreography — never remove a DS until the corresponding DNSKEY has been gone from the zone for TTL + propagation.
Moved DNS providers without regenerating and updating the DS. Old DS at the registrar points to a key the new provider doesn't have. Fix: remove the DS before the NS cutover to revert to unsigned temporarily, then re-publish once the new provider is live.
Your resolver's clock drifted outside the RRSIG validity window. The zone is fine; the resolver you're using is broken. Fix: sync the resolver's clock via NTP. Authoritative-server clock skew can cause this too but is rare on managed providers.
A domain can be in one of three DNSSEC states: not enabled (no DS record at the registrar — the majority of the internet), published but invalid (DNSKEY/DS mismatch, expired RRSIG, or incomplete key rollover — the Slack 2021 24-hour outage, .fj 2022, and .nz 2023 incidents all fell here), or valid (AD flag set, chain intact from root). Diagnosing which state you're in requires checking DS at the parent zone, DNSKEY at the domain itself, and the AD (Authenticated Data) flag on a DNSSEC-aware resolver. RFCs 4033/4034/4035 and the consolidating RFC 9364 define the protocol; RFC 7672 explains why email operators increasingly care.
When a domain lands in "published but invalid," it's the same failure class that took Slack offline in 2021, .fj in 2022, and .nz in 2023. Reading one of these post-mortems before you deploy DNSSEC pays for itself the first time a rollover goes sideways.
Slack's DNSSEC deployment went wrong in ways their post-mortem openly documents: DS/DNSKEY mismatch during rollover, partial resolver caches, and three rollbacks before the chain settled. The canonical case for why rollovers need overlap windows.
A DS update at the .fj registry arrived before Cloudflare's resolvers saw the matching DNSKEY. Validating resolvers returned SERVFAIL on every .fj domain; the outage was Cloudflare-visible, not user-visible — but domains silently disappeared from Cloudflare-routed users for hours.
An NSEC3 issue at the .nz level broke DNSSEC validation for New Zealand government and academic subdomains. InternetNZ's incident report walks through the debugging — worth reading once before you sign a high-traffic zone.
DNSSEC is a prerequisite for DANE (RFC 7672). DANE lets a domain pin the expected TLS certificate for its mail servers by publishing a TLSA record, anchoring trust in DNS instead of the public certificate authority system. Without DNSSEC, that TLSA record carries no authority — an attacker could forge both the cert and the pin — so compliant SMTP receivers silently ignore TLSA when the AD flag isn't set.
Signs DNS answers. Foundational layer — unlocks DANE, hardens the lookup path for SPF / DKIM / DMARC / BIMI.
TLSA records at _25._tcp.<mx>. TLS authentication between MTAs, anchored in DNSSEC.
The DNSSEC-free alternative. Policy served over HTTPS, anchored in the public Web PKI. Works without DNSSEC; most US domains run this instead of DANE.
If you already run DNSSEC, DANE is the natural next step and we'll wire you through to the DANE checker. If you don't run DNSSEC and don't want the operational overhead, MTA-STS gives you most of the same TLS-enforcement threat model without a DNSSEC dependency — the pragmatic fallback.
DNSSEC adoption sits around 4% of .com and 5% of .net per APNIC Labs and ICANN OCTO data, with end-to-end resolver-side validation at roughly 0.47% of DNS queries globally. Those numbers are growing (~45% YoY) but remain modest. “Not enabled” is the global default, and it's a deliberate architectural choice for most domains, not an oversight.
Enable DNSSEC when: you want DANE for SMTP; you operate under a regulatory framework that requires it (EU government under Forum Standaardisatie, German email service providers under BSI TR-03108, etc.); you run your own DNS infrastructure and want DNS-level tamper evidence; or you're in a high-value brand-impersonation threat model where an attacker could reasonably compromise an ISP or middlebox. Skip DNSSEC when you're a small site that already runs HTTPS — the marginal security benefit is small relative to the operational complexity, and a broken DNSSEC rollout can take your domain offline for hours.
One-click DNSSEC on Cloudflare, Route 53, or Google Cloud DNS takes minutes to enable. The hard part is keeping the DS record at the registrar synchronised with the DNSKEY at the provider across every key rollover, every NS change, and every provider migration. Most providers automate the first but not the others — the operational discipline is on you.
Type a domain without protocol or path (example.com, not https://example.com/). The tool walks all required DNS queries in parallel — expect results in ~2 seconds on a signed zone, ~1 second on an unsigned one.
Green `DNSSEC Valid` means the chain validates end-to-end; amber `DNSSEC Published — Invalid` means records exist but the chain is broken; neutral grey `DNSSEC Not Enabled` is the default state for ~95% of domains — not a failure, just the global baseline.
The text tree shows root → TLD → your zone with ✓ / ✗ at each hop. When something's wrong, the last ✓ before the ✗ tells you which layer broke. Copy-paste this into your ticket — it's much clearer than a screenshot of a graph.
Check the DNSKEY card for algorithm name and strength verdict. If you see `RSASHA1 (5) — deprecated`, rotate to algorithm 13 (ECDSAP256SHA256). Same for DS digest type 1 (SHA-1) — move to digest type 2 (SHA-256).
The `DS records` card shows what the parent zone is publishing. Cross-check those key-tags against the DNSKEYs at your zone — they must match. When they don't, that's a DS/DNSKEY mismatch: the most common DNSSEC failure mode and the one the registrar fix-recipe tab will walk you through.
Don't enable DNSSEC and then change DNS providers. Old DS at the registrar points to a key the new provider doesn't have — instant BOGUS. Remove the DS first (temporary unsigned), then cut over, then re-sign and publish the new DS.
Don't sign with deprecated algorithms. Algorithms 1, 3, 5, 6, 7, and 12 are MUST NOT under RFC 8624. If you see any of those in a result, rotate to algorithm 13 (ECDSAP256SHA256) — smaller, faster, universally supported.
Don't roll a KSK without the 2-TTL overlap. Publish the new DNSKEY, wait for the old KSK TTL to expire globally, then update the DS at the registrar. Skip the wait and you're Slack in 2021.
Don't enable DNSSEC without monitoring RRSIG expiry. If your provider's re-signing pipeline pauses, your zone goes BOGUS the moment signatures expire. Alert on RRSIG lifetime, not just DS presence.
DNSSEC is the upstream anchor. Here's the rest of the cohort.
DANE requires DNSSEC. If your zone is signed, the next step is checking TLSA records per MX.
DNSSEC signs the records that carry your DMARC policy. Confirm the policy is at enforcement.
The DNSSEC-free TLS enforcement path. If you can't run DNSSEC, start here.
DNSSEC hardens the DKIM / DMARC / BIMI lookup path end-to-end.
This tool gets you an interactive answer in a few seconds. For a full cryptographic trace or long-form reference, the following are the tools and docs we trust:
DNSSEC, the chain of trust, algorithm choices, NSEC vs NSEC3, the DANE linkage, and the outages people actually run into.
Still have questions about DNSSEC?