casey at deccio.net
Wed Sep 9 20:59:06 UTC 2009
I'm trying to better understand NSEC3. I have a signed zone for which
I periodically resign expiring RRs with expiring RRSIGs using
dnssec-signzone. When I do so, I use a different salt each time,
which results in multiple salts being used in the zone. According to
This is harmless, since each RR stands
alone (that is, it denies the set of owner names whose hashes, using
the salt in the NSEC3 RR, fall between the two hashes in the NSEC3
RR) -- it is only the server that needs a complete set of NSEC3 RRs
with the same salt in order to be able to answer every possible
Also, according to RFC 5155:
There MUST be at least one complete set of NSEC3 RRs for the zone
using the same salt value.
If an NSEC3PARAM RR is present at the apex of a zone with a Flags
field value of zero, then there MUST be an NSEC3 RR using the same
hash algorithm, iterations, and salt parameters present at every
hashed owner name in the zone. That is, the zone MUST contain a
complete set of NSEC3 RRs with the same hash algorithm, iterations,
and salt parameters.
So from what I gather, each time a new salt (and therefore NSEC3PARAM)
is introduced to the mix, a new NSEC3 chain is generated, so given n
distinct owner names in the zone, there are n*(num NSEC3PARAM RRs)
NSEC3 RRs and covering RRSIGs.
I'm looking for a sanity check here. Aside from the increase in zone
size, there shouldn't be any resolution/validation problems with this,
correct? Is it more reasonable to use the same salt until the zone is
completely (i.e., all RRs) resigned?
More information about the bind-users