[dns-operations] NSEC3PARAM change strange behaviour

[Misak 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


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20231012/41986fc9/attachment.html>