salting NSEC3

Casey Deccio casey at
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
RFC 5155:
   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 mailing list