[dns-operations] NSEC3PARAM change strange behaviour

[Misak A. Khachatryan]

Thank you Viktor,

In logs I see IXFR, which should be a case. This brings me to question to bind developers - shouldn't a change of dnssec-policy or at least such destructive ones automatically trigger AXFR?

Of course it's not a question to be asked here, I will check the documentation of bind and ask it in the appropriate mailing list.

Best regards,
Misak Khachatryan,
Network Administration and
Monitoring Department Manager,

GNC- ALFA CJSC
1 Khaghaghutyan str., Abovyan, 2201 Armenia
Tel: +374 60 46 99 70 (9670),
Mob.: +374 93 19 98 40
URL:    www.rtarmenia.am<http://www.rtarmenia.am>


On Wed, Oct 11, 2023 at 10:10 PM Viktor Dukhovni <ietf-dane at dukhovni.org<mailto:ietf-dane at dukhovni.org>> wrote:
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.
_______________________________________________
dns-operations mailing list
dns-operations at lists.dns-oarc.net<mailto:dns-operations at lists.dns-oarc.net>
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20231012/83d0d914/attachment-0001.html>