<div dir="ltr"><div>Hello,</div><div><br></div><div>I'm maintaining a rather big DNS zone - around 2.5 Megabytes in ASCII format, more than 40k records overall.</div><div><br></div><div>Authoritative server software is Bind. NSEC3PARAM in dnssec-policy was defined as:</div><div>nsec3param optout yes salt-length 24;</div><div><br></div><div>Today i decided to change it to:</div><div>nsec3param optout yes;</div><div><br></div><div>which according to defaults for my Bind version expands to:</div><div>nsec3param iterations 5 optout yes salt-length 8;</div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br></div><div class="gmail_signature" data-smartmail="gmail_signature">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.</div><div class="gmail_signature" data-smartmail="gmail_signature"><br></div><div class="gmail_signature" data-smartmail="gmail_signature">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.</div><div class="gmail_signature" data-smartmail="gmail_signature"><br></div><div class="gmail_signature" data-smartmail="gmail_signature">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?<br></div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br></div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br>Best regards,<br>Misak Khachatryan</div></div></div></div>