[dns-operations] NSEC3PARAM change strange behaviour

[Viktor Dukhovni]

On Wed, Oct 11, 2023 at 07:32:28PM +0400, Misak Khachatryan wrote:

> I'm maintaining a rather big DNS zone - around 2.5 Megabytes in ASCII
> format, more than 40k records overall.

40k records is neither small, nor unusually large.  This should work
without issues.

> Authoritative server software is Bind. NSEC3PARAM in dnssec-policy was
> defined as:
>
>   nsec3param optout yes salt-length 24;
> 
> Today i decided to change it to:
>
>   nsec3param optout yes;
> 
> which according to defaults for my Bind version expands to:
> nsec3param iterations 5 optout yes salt-length 8;
> 
> After issuing rndc reconfig for around 3 minutes my monitoring went crazy,
> sending notifications about dnssec errors, but checking the zone with
> DNSViz and DNSSEC Analyzer reporting that everything is normal. Using dig
> @server zone NSEC3PARAM at problematic time server didn't return NSEC3PARAM
> record, reporting it as missing.

The new NSEC3 chain should be constructed in full, before the nameserver
switches to the resulting chain once it is fully built.

At that point, the SOA would be bumped, and zone transfers can start.
The key question is whether the transfers will IXFR or AXFR (which may
be more appropriate for such a bulk change).

> Three minutes later everything went normal. In the Bind log I see several
> zone transfers to slaves around every second. I presume that such a big
> zone can't be transferred in one part, which causes this behavior.

For this change, The zone transfer needs to be atomic.  It is not OK to
have half an NSEC3 chain.

> My question to other maintainers of big zones - do you have such
> experience, and what is the correct way to update NSEC3 parameters in
> order to have a smooth transition?

I don't have relevant experience, but you should be able to reproduce
the scenario in a test environment, and if not using the latest version
of BIND, try a newer (or else earlier) version and compare.

-- 
    Viktor.