<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<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>
<div>
<div>
<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br>
Best regards,<br>
Misak Khachatryan,<br>
Network Administration and<br>
Monitoring Department Manager,<br>
<br>
GNC- ALFA CJSC<br>
1 Khaghaghutyan str., Abovyan, 2201 Armenia<br>
Tel: +374 60 46 99 70 (9670),<br>
Mob.: +374 93 19 98 40<br>
URL: <a href="http://www.rtarmenia.am" target="_blank">www.rtarmenia.am</a><br>
</div>
</div>
<br>
</div>
</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>
</body>
</html>