Problem upgrading to 9.18 - important feature being removed

[Nick Tait]

On 27/02/2024 13:22, Michael Sinatra wrote:
> On 2/26/24 13:41, Al Whaley wrote:
>> Originally (under the above command) RR records for DNSSEC were 
>> maintained by bind, but the ZSK and KSK keys were maintained by me.  
>> This command is being discarded.  I understand that bind "sort of" 
>> supports this feature in 9.18 by allowing the DNSSEC policy statement 
>> to declare unlimited lifetime, but after careful reading of the 
>> documentation and reading a number of complaints, it turns out that 
>> bind may under various circumstances decide that it is appropriate 
>> not to use existing keys and decide that it knows best, and then it 
>> makes new ones.  This potential instability of course would be 
>> disastrous, and completely unnecessary.
>
> I have never experienced this, in either BIND 9.16 or BIND 9.18 
> (including the latter with KASP set to not rotate any keys).  Can you 
> elaborate as to where in the documentation and/or what complaints you 
> have seen where correctly configured KASPs in 9.18.24+ decide to roll 
> keys?  I'd certainly like to know if that's the case, for reasons 
> described below. 

The only example that I can recall (from this list) where this type of 
thing happened was where someone specified a different algorithm when 
transitioning to dnssec-policy. The advice for this type of situation is 
to transition to dnssec-policy with the same algorithm first, and make 
sure everything in your state files is "omnipresent", and only then 
update the dnssec-policy to use a different algorithm.

My (somewhat uneducated) advice would also be to avoid 
implementing dnssec-policy if you were in the middle of a key roll-over. 
Not because I think it would necessarily create a problem, but more to 
reduce risk and make it easier to verify that nothing untoward has happened.

In other words, if you aren't in the middle of a roll-over, and your 
current keys don't have any expiration set, then you can reconfigure 
your zone to use a dnssec-policy that specifies the same algorithm as 
what you previously had, and BIND should be happy to carry on using the 
existing keys -- indefinitely if you've specified an unlimited lifetime. 
The only difference you should notice is that after 
implementing dnssec-policy there are additional *.state files in your 
keys directory.

The only other thing I'd add is that if (after transitioning 
to dnssec-policy) you do initiate a manual roll-over, keep an eye on 
your state files to verify that the new key becomes "omnipresent". This 
can take much longer than you might expect! For ZSK roll-overs don't be 
surprised if it takes 9-10 days. Also FYI for KSK (and CSK) roll-overs, 
you may need to run rndc commands to tell BIND when DS records are 
added/removed -- but that is possibly what you already do with auto-dnssec?

Of course in life there are no absolute guarantees, so you should back 
up your configuration and make a plan to mitigate the impacts in the 
event that everything turns pear-shaped?

Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240227/86d86ac7/attachment-0001.htm>