[dns-operations] NSEC3 parameter selection (BCP: 1 0 0 -)

Matthew Richardson matthew-l at itconsult.co.uk
Tue Jan 19 15:39:26 UTC 2021

On Tue, 19 Jan 2021 08:37:09 -0500, Viktor Dukhovni wrote:-

>On Tue, Jan 19, 2021 at 09:24:09AM +0000, Matthew Richardson wrote:
>> At Mon, 18 Jan 2021 13:55:21 -0500, Viktor Dukhovni wrote:-
>> >    2.  Changing the salt takes some care, so "nobody" does it.
>> Any pointers to the "care" required when changing salt (or the iteration
>> count) would be appreciated.  My searches reveal little information.  In
>> particular, what timing issues exist with respect to the zone's TTLs?
>Sorry for leaving this vague.  Changing the salt requires rebuilding the
>entire NSEC3 chain, and so is difficult to combine with incremental zone
>signing (such as BIND's "auto-dnssec maintain").  If you're doing
>periodic whole zone signing, which reconstructs the entire chain, you
>can change the salt at will each time the zone is signed from scratch.
>If, on the other hand, the zone is signed incrementally as individual
>records are modified, then there is not an opportunity to change the
>salt, which needs to be consistent across the entire chain.

My tests with Bind 9.11 using "inline-signing yes; auto-dnssec maintain;"
suggests that if one issues "rndc signing -nsec3param 1 0 0 [salt] [zone]"
all the NSEC3 records are immediately replaced and fully re-signed.  The
NSEC3PARAM record always seems to have a zero TTL.

Thus (I think) the master zone is always correctly/fully signed/nsec3ed as
it reconstructs the whole chain.

I wonder however about resolvers and negative caching, as the NSEC3 records
and their signatures have the default TTL for the zone and could therefore
be cached for several hours by resolvers.

Given Bind's behaviour (which looks good), are there any issues with
caching/TTLs were one to change the salt with "rndc signing"?

Best wishes,

More information about the dns-operations mailing list