Both NSEC and NSEC3 leak because they describe gaps between names that exist. A signer that can sign at query time does not need to describe a gap at all — it can answer about the name it was asked and nothing else.
The idea
Query: beta.example.com A (does not exist) Classic NSEC: "nothing exists between api and mail" -> reveals api and mail Synthesised: NSEC beta.example.com. -> \000.beta.example.com. "nothing exists between beta and the name immediately after beta" -> reveals nothing at all
The range returned is the smallest one that can contain the queried name and nothing else. It is a true statement, correctly signed, and it names no other record in the zone.
White lies and black lies
| Name | What it does |
|---|---|
| White lies | Synthesises a minimal NSEC range around the queried name. Truthful about non-existence, uninformative about everything else. |
| Black lies | Answers NOERROR with no records rather than NXDOMAIN, asserting the name exists with no data. Smaller responses, and it hides the distinction between a name that exists empty and one that does not exist. |
Cloudflare’s zones use this approach, and so do several other large operators. It is why a query for a non-existent name under those zones returns an NSEC record naming a range you have never seen before:
(an NSEC record whose range is specific to the name you asked for)
What it requires
- Online signing. The signature is produced when the query arrives, so the private key must be present on every authoritative server rather than on an offline signer.
- Fast signing. Practical with ECDSA, uncomfortable with RSA.
- Provider support. This is a signer feature, not a zone setting. If your DNS provider does not offer it, you choose between NSEC and NSEC3.
The trade is key exposure against enumeration
Offline signing keeps the private key off every internet-facing machine, which is a real security property, and it forces you to describe gaps. Online signing eliminates enumeration and puts the key where the queries are. Large operators make the second trade because they have the infrastructure to protect a key in production; most zones do not, and NSEC with zero-iteration NSEC3 as an alternative is a perfectly defensible answer.