<div dir="ltr"><div>Thank you Viktor,</div><div><br></div><div>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?</div><div><br></div><div>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.<br></div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br>Best regards,<br>Misak Khachatryan</div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 11, 2023 at 10:10 PM Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org">ietf-dane@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Oct 11, 2023 at 07:32:28PM +0400, Misak Khachatryan wrote:<br>
<br>
> I'm maintaining a rather big DNS zone - around 2.5 Megabytes in ASCII<br>
> format, more than 40k records overall.<br>
<br>
40k records is neither small, nor unusually large.  This should work<br>
without issues.<br>
<br>
> Authoritative server software is Bind. NSEC3PARAM in dnssec-policy was<br>
> defined as:<br>
><br>
>   nsec3param optout yes salt-length 24;<br>
> <br>
> Today i decided to change it to:<br>
><br>
>   nsec3param optout yes;<br>
> <br>
> which according to defaults for my Bind version expands to:<br>
> nsec3param iterations 5 optout yes salt-length 8;<br>
> <br>
> After issuing rndc reconfig for around 3 minutes my monitoring went crazy,<br>
> sending notifications about dnssec errors, but checking the zone with<br>
> DNSViz and DNSSEC Analyzer reporting that everything is normal. Using dig<br>
> @server zone NSEC3PARAM at problematic time server didn't return NSEC3PARAM<br>
> record, reporting it as missing.<br>
<br>
The new NSEC3 chain should be constructed in full, before the nameserver<br>
switches to the resulting chain once it is fully built.<br>
<br>
At that point, the SOA would be bumped, and zone transfers can start.<br>
The key question is whether the transfers will IXFR or AXFR (which may<br>
be more appropriate for such a bulk change).<br>
<br>
> Three minutes later everything went normal. In the Bind log I see several<br>
> zone transfers to slaves around every second. I presume that such a big<br>
> zone can't be transferred in one part, which causes this behavior.<br>
<br>
For this change, The zone transfer needs to be atomic.  It is not OK to<br>
have half an NSEC3 chain.<br>
<br>
> My question to other maintainers of big zones - do you have such<br>
> experience, and what is the correct way to update NSEC3 parameters in<br>
> order to have a smooth transition?<br>
<br>
I don't have relevant experience, but you should be able to reproduce<br>
the scenario in a test environment, and if not using the latest version<br>
of BIND, try a newer (or else earlier) version and compare.<br>
<br>
-- <br>
    Viktor.<br>
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div>