What NSEC3 fixed, and did not

RFC 5155 replaced the plaintext successor names with hashes. The proof works the same way and the names are no longer directly readable — which turned out to raise the cost of enumeration rather than end it.

The change

NSEC     api.example.com.  NSEC  mail.example.com.

NSEC3    <hash(api)>.example.com.  NSEC3  1 0 0 -  <hash(mail)>  A RRSIG
                                          ^ ^ ^ ^
                                          | | | salt
                                          | | iterations
                                          | flags (1 = opt-out)
                                          hash algorithm

An attacker walking the zone now collects hashes instead of names. To turn a hash back into a name they have to guess the name and hash it — which, for hostnames, is a small dictionary and a fast operation.

The parameters, and what they cost

Parameter	Current guidance	Why
Iterations	0	Every iteration costs the resolver as much as the attacker. RFC 9276 is explicit: additional iterations provide no meaningful protection and are a denial-of-service vector against validators.
Salt	empty	A salt only helps against precomputed tables built in advance for a specific zone, which is not how this is attacked. Changing it requires re-signing the whole zone.
Opt-out	Off, unless you are a TLD	It allows unsigned delegations to be skipped, which shrinks a registry-sized zone enormously and proves nothing about the names it skips.

The guidance is counter-intuitive and worth stating plainly: the settings that look like they add security add none, and cost your validators real work. A large iteration count is one of the most common misconfigurations in signed zones, and it came from advice that was current a decade ago.

What it did not fix

The hashes are still enumerable. You walk the zone exactly as before and get a complete list of hashes.
Offline cracking is cheap. Hostnames come from a small vocabulary. A GPU recovers most of a typical zone from its hashes quickly.
The type bitmaps survive. Even an uncracked hash tells you a name exists and which record types it has.
It costs more to serve. Every negative answer requires hashing, and with iterations that cost is multiplied.

NSEC3 with high iterations is worse than NSEC

It provides enumeration resistance an afternoon of compute defeats, and it imposes a per-query cost on every validating resolver that reaches you. If enumeration genuinely matters for your zone, the answer is synthesised denial — the subject of the next lesson — not a larger iteration count.

Knowledge check

Why is NSEC3 with 100 iterations worse than NSEC3 with 0?

The iterations cost every validating resolver the same work they cost an attacker, and an attacker only has to do it once per zone.
High iteration counts are rejected by most validators.
It makes the zone file larger.
It is not worse — more iterations are strictly more secure.

Correct — The iterations cost every validating resolver the same work they cost an attacker, and an attacker only has to do it once per zone. RFC 9276 is explicit that additional iterations provide no meaningful protection and act as a denial-of-service vector against validators. The asymmetry runs the wrong way: resolvers pay per query, the attacker pays once.

Not this — High iteration counts are rejected by most validators. Many now cap or refuse very high counts, which is a consequence of the problem rather than the reason it is one.

Not this — It makes the zone file larger. The record count is unchanged. The cost is computation at query time.

Not this — It is not worse — more iterations are strictly more secure. That was the reasoning behind the original advice, and it does not hold. The hashed input is a short hostname from a small vocabulary; iteration does not change that.

The change

The parameters, and what they cost

What it did not fix

Try it on a real domain