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

[Viktor Dukhovni]

On Tue, Jan 19, 2021 at 03:39:26PM +0000, Matthew Richardson wrote:

> >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.

Sure, but this is essentially equivalent to resigning the whole zone.
With a sufficiently large zone, this is not a cheap operation.

> 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"?

There are no issues with TTLs and NSEC3 salt.  A given set of NSEC3
records and RRSIGs is either a valid DoE proof or not based on the salts
in those records.  There is no expectation that other records use the
same salt, or even that the salt is the same across all the records in
question.  The NSEC3PARAM RR is internal signalling between the primary
and secondary servers, it is not used by resolvers.

Indeed for .COM the NSEC3PARAM RR does not match the actual policy, it
shows the opt-out bit off.

    com. IN NSEC3PARAM 1 0 0 -

while actual DoE proofs carry the opt-out bit:

    CK0POJMG874LJREF7EFN8430QVIT8BSM.com. IN NSEC3 (
        1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A
        NS SOA RRSIG DNSKEY NSEC3PARAM )

It seems that the authoritative servers know to use opt-out via
some other mechanism.

-- 
    Viktor.