[dns-operations] NSEC3PARAM change strange behaviour

[Mark Andrews]

No. The change is done incrementally. You want changes in the data to make it to the secondaries in a timely manner.  That can’t happen if they get stuck behind a large AXFR.  

-- 
Mark Andrews

> On 12 Oct 2023, at 22:25, Misak Khachatryan <kmisak at gmail.com> wrote:
> 
> 
> 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
> 
> 
>> On Wed, Oct 11, 2023 at 10:10 PM Viktor Dukhovni <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
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> _______________________________________________
> dns-operations mailing list
> 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/bbf6cad2/attachment-0001.html>