NSEC3PARAM NSEC3 Parameters Common
Publishes the hashing parameters (algorithm, iterations, salt) a zone uses for its NSEC3 records.
What it's for
An NSEC3PARAM record publishes, at the zone apex, the exact hashing parameters (algorithm, iteration count, salt) used to generate every NSEC3 record in that zone. It exists as a single, discoverable place for resolvers and zone-management tools to learn how a zone's NSEC3 hashing works, separate from the individual NSEC3 records scattered throughout the zone.
It's a companion record to NSEC3, not an alternative to it — a zone using NSEC3 for denial-of-existence will have exactly one NSEC3PARAM record (at the apex) alongside many NSEC3 records (one per existing name).
Format & syntax
example.com. 3600 IN NSEC3PARAM 1 0 10 ABCD1234
- Hash Algorithm — matches what's used in the zone's NSEC3 records (currently only
1, SHA-1, is defined) - Flags — mirrors the NSEC3 opt-out flag usage at the zone level
- Iterations — the hash iteration count used throughout the zone
- Salt — the salt value used, in hex (or
-if no salt is used)
Critically, the NSEC3PARAM record itself is published unsigned in terms of query response behavior for the apex — it's specifically designed so a resolver can retrieve the current hashing parameters without needing to already know them, closing what would otherwise be a bootstrapping problem.
How it's used in practice
- Enabling resolvers/tools to compute NSEC3 hashes themselves — some validation and troubleshooting tools need to independently compute what a name's NSEC3 hash should be, which requires knowing the exact algorithm, iterations, and salt the zone uses — this record is where that comes from.
- Salt rotation — periodically changing the salt (a security practice to limit the usefulness of any precomputed hash tables an attacker may have built) means updating the NSEC3PARAM record along with re-hashing every NSEC3 record in the zone — again, something DNSSEC signing tooling automates rather than something done by hand.
- Zone signing software internals — most domain owners never interact with NSEC3PARAM directly; it's generated and maintained automatically by the same signing process/software that produces NSEC3, DNSKEY, and RRSIG records.
Common mistakes & gotchas
- Manually editing NSEC3PARAM without re-hashing NSEC3 records — if the parameters (especially the salt) change, every existing NSEC3 record in the zone becomes inconsistent with the new NSEC3PARAM value unless they're all regenerated together. This is a good example of why NSEC3PARAM changes should always go through proper signing tooling rather than manual edits.
- Confusing NSEC3PARAM with NSEC3 — NSEC3PARAM is a single zone-level metadata record; NSEC3 is the actual per-name denial-of-existence chain. They work together but serve different roles.
- Assuming this record matters outside DNSSEC contexts — like the rest of the DNSSEC-specific record types, this is entirely irrelevant to zones that don't have DNSSEC signing enabled.
Comparison & FAQ
| Type | Purpose | Key difference from NSEC3PARAM |
|---|---|---|
| NSEC3 | The actual per-name denial-of-existence chain | NSEC3PARAM is metadata describing how those hashes were computed, not a proof itself |
| DNSKEY | The signing key for the zone | Entirely separate DNSSEC mechanism — key management versus denial-of-existence hashing parameters |
Do I need to configure NSEC3PARAM manually?
No — it's generated and managed automatically by your DNS provider's DNSSEC signing process when NSEC3 is in use, alongside the NSEC3, DNSKEY, and RRSIG records.
Why does NSEC3PARAM exist separately from NSEC3 records?
It provides a single, predictable place at the zone apex where the hashing parameters (algorithm, iterations, salt) are published, so tools and resolvers can learn how to compute or verify NSEC3 hashes without already needing to know the zone's specific configuration.
What happens if the salt in NSEC3PARAM changes?
Every NSEC3 record in the zone needs to be regenerated to match the new salt, since they're all hashed using the parameters this record describes — this is handled automatically by proper zone-signing tooling, not something to change by hand.
Is NSEC3PARAM relevant if my zone doesn't use DNSSEC?
No, it's entirely specific to DNSSEC-signed zones using NSEC3 for authenticated denial of existence.