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 <[email protected]> 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 <[email protected]> >> 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 >> [email protected] >> https://lists.dns-oarc.net/mailman/listinfo/dns-operations > _______________________________________________ > dns-operations mailing list > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
