NSEC3PARAM Lookup
NSEC3 parameters (hashed denial of existence).
Enter a value above to run NSEC3PARAM Lookup
e.g. example.com
Quick answer
NSEC3PARAM Lookup shows the parameters a zone uses for NSEC3, the hashed version of DNSSEC's proof-of-nonexistence that stops attackers from listing every name in the zone. The record reveals the hash algorithm, flags, iteration count, and salt used to compute the hashed names.
The NSEC3PARAM Lookup queries a signed zone's apex for its NSEC3PARAM record, which tells resolvers exactly how the zone hashes owner names for authenticated denial of existence. A DNSSEC zone proves that a name does not exist without revealing the whole zone; NSEC3 does this using salted, iterated SHA-1 hashes instead of the plaintext names that plain NSEC exposes. This tool shows the hash algorithm, flags, iteration count and salt in use, so you can confirm your signer is publishing the parameters an authoritative server needs to generate NSEC3 proofs.
How it works
The record lives only at the zone apex and has four fields: hash algorithm (1 = SHA-1, the only defined value), flags, iterations, and salt. Authoritative servers read NSEC3PARAM to know which parameters to apply when synthesising NSEC3 records for negative answers. A single NSEC3PARAM with a zero flags byte marks the parameter set that is complete and safe for servers to use; extra records with the opt-out or in-progress bits appear only during a re-salting rollover.
How to read the results
Read the fields left to right: algorithm should be 1, flags is usually 0, iterations is a small number, and salt is either a hex string or a single dash meaning empty. Current guidance (RFC 9276) is 0 additional iterations and an empty salt, because extra iterations only add CPU cost without real privacy gain. If you see iterations in the hundreds or a long salt, your zone is following outdated advice and can be tightened.
Common problems & fixes
No NSEC3PARAM at all means the zone either uses plain NSEC or is unsigned; check for DNSKEY and RRSIG first. High iteration counts (many resolvers now cap or reject values above 100) cause validation failures and SERVFAILs, so lower them to 0 and re-sign. A lingering second record after a salt change usually means the rollover never completed; finish resigning so only one clean NSEC3PARAM with flags 0 remains published.
Frequently asked questions
- What is the difference between NSEC and NSEC3?
- Both prove a name does not exist, but NSEC lists the actual next name in the zone, letting anyone walk and enumerate every record. NSEC3 replaces those names with hashes, so zone walking becomes far harder. NSEC3PARAM carries the salt and iteration settings the server uses to compute those hashes consistently across the zone.
- Should I use a salt and many iterations?
- No. RFC 9276 recommends an empty salt and zero extra iterations. A salt does not stop determined enumeration because it is public in the record, and high iteration counts only burden resolvers and your own servers. Many validating resolvers now treat large iteration counts as insecure or return SERVFAIL, so keep both minimal.
- Why does my zone have two NSEC3PARAM records?
- This normally happens during a salt or parameter change. The signer temporarily publishes the new parameter set alongside the old one, marking transitional records with a non-zero flag so servers keep using the fully deployed set. Once every NSEC3 record is re-signed with the new salt, the old NSEC3PARAM should be removed, leaving exactly one.