Your DNSSEC zone is signed. It's also an open book.
You signed your zone. You checked the box. DNSSEC is enabled, the DS records are in place, and your registrar shows a green checkmark. You’re protected against DNS spoofing.
You’re also handing every subdomain you own to anyone who asks.
How NSEC gives away your zone
DNSSEC needs a way to prove that a name does not exist. If someone queries nope.example.com and there is no such record, the resolver needs cryptographic proof of that absence, not just silence.
The original solution is NSEC (Next Secure). It chains every name in the zone together in alphabetical order. Each NSEC record says “the next name after mail.example.com is vpn.example.com, and there is nothing in between.” A resolver verifies the signature and confirms that nope.example.com genuinely does not exist.
The problem is obvious once you see it. An attacker queries a name, gets back the NSEC record pointing to the next name, queries that name, gets the next one, and so on. Within minutes they have a complete list of every hostname in the zone. This is called NSEC walking, and it works against any DNSSEC-signed zone that uses plain NSEC.
Staging boxes, internal service names, things the operators probably did not want indexed by a stranger with a script.
NSEC3 closes the gap (mostly)
NSEC3, defined in RFC 5155, replaces the plaintext name chain with hashed names. Instead of “the next name after mail is vpn”, it says “the next hash after 1a2b3c... is 4d5e6f...”. An attacker can still walk the hash chain, but they get hashes instead of readable hostnames.
That does not make enumeration impossible. With enough compute, someone can try to reverse common names against the hashes. A dictionary of likely subdomains (www, mail, api, staging, dev) will crack quickly. But it raises the cost from “trivial scripted walk” to “offline brute force attack”, and for most zones with non-obvious naming, that is enough.
NSEC3 also supports opt-out, which lets unsigned delegations skip the chain entirely. This matters for large TLD operators but is less relevant for most organisations.
Migrating from NSEC to NSEC3 is a zone signing parameter change, not an infrastructure overhaul. If your provider does not support NSEC3, that alone is worth knowing.
There is a third option. Cloudflare uses plain NSEC but synthesizes the records on the fly for each query, a technique they call “black lies.” When you query a name that does not exist, Cloudflare returns an NSEC record that covers only that single name, not a pointer to the next real name in the zone. There is no chain, so there is nothing to walk. It looks like NSEC to a validator, but it leaks zero information about what else exists. SSLBoard detects this: if a zone uses NSEC but the records are synthesized in a way that prevents enumeration, we won’t flag it as vulnerable.
CNAMEs break your chain
Say you sign your zone with NSEC3, audit your records, everything looks good. But half your subdomains are CNAMEs pointing somewhere else: your status page on Atlassian, your docs on GitBook, your helpdesk on Zendesk.
Each of those CNAMEs resolves into the third party’s zone. If that zone is not signed with DNSSEC, or if it is signed with plain NSEC, you have a gap. Your domain says “trust the DNS chain” but the chain breaks or leaks at the delegation target.
If the target zone is unsigned, the DNSSEC validation chain is incomplete. An attacker who can poison the resolution of that CNAME target can redirect your subdomain without triggering any DNSSEC failure, because there is nothing to fail against. And if the target zone uses NSEC, an attacker can enumerate the target’s hostnames, which may reveal information about your infrastructure even though your own zone is locked down.
Most teams never check this. They sign their own zone and assume the job is done.
DNSSEC in SSLBoard reports
We added DNSSEC validation to SSLBoard reports. For every zone we discover, the report checks:
- Whether DNSSEC is enabled at all (signed vs unsigned)
- Whether the signing is valid (secure) or broken (bogus)
- Whether the zone uses NSEC or NSEC3 for denial of existence
- If NSEC is used, it flags the zone if it’s vulnerable to name enumeration
Beyond your own zones, we follow CNAME delegations to third party services and check whether those target zones also support DNSSEC. If your status page at status.example.com points to a provider whose zone is unsigned, you will see it flagged. Same if the provider’s zone uses NSEC and is walkable.
The point is to give you one view of where your DNSSEC posture actually stands, not just the parts you control directly.
Fixing it
If you are running NSEC, switch to NSEC3. Most managed DNS providers (Cloudflare, AWS Route 53, Google Cloud DNS) already use NSEC3 by default. If you are on a provider that does not, or if you run your own authoritative servers, check your zone signing configuration.
For CNAME delegations, you have less control. You can choose providers that support DNSSEC, and you can make DNSSEC support a procurement criterion. You probably cannot force your status page provider to switch from NSEC to NSEC3. But you can know about the gap and decide whether it matters for your threat model.
If you want to see where you stand, run your domain through SSLBoard. The DNSSEC section lays it out.