Your report flags zone enumeration. Before anything else, two reassurances: your signatures are fine, and nothing is broken. This is not the same class of problem as a bogus zone, and it is not an outage waiting to happen.
What it means is that the records proving a name does not exist can be walked to produce a list of the names that do. Anyone can retrieve your subdomain inventory without sending a single query to a host.
The usual advice is “switch to NSEC3”. That is not wrong, but it is oversold, and the parameters most people choose actively make things worse.
NSEC3 raises the cost, it does not close the door
NSEC signs a sorted chain of your actual names, so walking it is trivial and complete. Ask for a name that does not exist, get told what comes next, repeat. A full zone listing takes seconds.
NSEC3 publishes hashes of names instead. Better, but the hashes are still published, which means an attacker collects them once and then attacks them offline, at their own pace, against a wordlist. And subdomain names are not passwords. vpn, mail, staging, jenkins, vpn2, test fall immediately. Tooling for exactly this has existed for years.
So the honest framing is that NSEC3 converts a trivial walk into a dictionary attack. Unusual names survive. Everything predictable does not.
The iterations trap
This is the part worth getting right, because the intuition is backwards.
People reason that if hashing once helps, hashing a thousand times must help more, and set a high iteration count. RFC 9276 says to use zero additional iterations and an empty salt.
The reasoning:
- The attack is offline, so extra iterations slow the attacker by a constant factor they simply absorb. The protection gained is negligible.
- The cost lands on every validating resolver, on every negative answer, forever. You are paying a permanent performance tax for that negligible gain.
- Resolvers have responded by capping it. High iteration counts are increasingly treated as insecure or failed outright, so an aggressive setting can push your zone toward resolution failures.
- The salt does not help either. It is published in the zone, so it prevents precomputed tables shared across zones and nothing else.
If you already run NSEC3 with high iterations, lowering them to zero is a genuine improvement rather than a compromise.
Then decide whether it matters to you
With the above understood, this becomes a straightforward judgment call rather than a checkbox:
| Your situation | Reasonable response |
|---|---|
| Public web presence, predictable names, nothing sensitive in the naming | Accept it. www and mail being listable costs you nothing |
| Internal or pre-production names in the public zone | Fix the naming, not the hashing. Those records are the actual problem |
| Names that reveal vendors, customers, or internal structure | NSEC3 with RFC 9276 parameters, plus a review of what is published at all |
| Provider offers no choice | Common with managed DNS. Proceed as though the list is public, because it effectively is |
The uncomfortable case is the second row. If jenkins.internal.example.com appearing in a public list worries you, the exposure is that the record is published, not that the denial-of-existence mechanism revealed it. Hashing it is obscuring a symptom.
Public DNS names were never secrets
Worth saying plainly, because it sets the right expectation for the whole category.
Certificate Transparency logs publish every name on a publicly trusted certificate, permanently and for free. Passive DNS collectors, scan data, and search engines fill in much of the rest. Zone enumeration is one route into a list that is already largely obtainable by other means.
So the right conclusion is not that this finding is unimportant. It is that hostname secrecy is not a control you can lean on, and anything reachable at a guessable name needs to be safe to have found. Treat NSEC3 as tidying up, and put the effort into what those hosts actually expose.
What to check after a change
Signing changes affect the whole zone, so confirm both that enumeration is addressed and that validation still works. A rescan should show the zone still Secure, with the enumeration finding resolved.
If the zone status moves to Bogus at any point, stop and fix that first. A broken signature will take your domain offline at every validating resolver, which is a far worse outcome than a listable zone. DNSSEC validation and zone findings covers the statuses and the other findings you may see alongside this one.
For the wider argument about why this matters, including how CNAME targets can leak a zone you do not control, see Your DNSSEC zone is signed. It’s also an open book.