Problem upgrading to 9.18 - important feature being removed

[Matthijs Mekking]

As the main developer of dnssec-policy, I would like to confirm that 
what has been said by Michael and Nick are correct.

I will repeat the most important takeaways:

- Setting the lifetime to unlimited on keys and BIND will never roll 
your keys automatically.

- Most issues that were shared on this list have to do with migrating to 
dnssec-policy.

- When migrating to dnssec-policy, make sure the configuration matches 
your existing keys.

- Make sure the migration is complete by checking that all states are in 
'omnipresent' (with 'rndc dnssec -status <zone>').

- If you feel like the DS is stuck in 'rumoured' state you might need to 
run 'rndc dnssec -checkds seen' on the key.

- It is not recommended to switch to dnssec-policy if you are currently 
in a rollover.

I acknowledge that migration takes some care and I wish the process was 
easier. We have some ideas to make it less error prone, but I haven't 
found the time to work on that.

On the more positive side, we haven't heard

Thanks to all for switching to dnssec-policy and reporting issues.

Best regards,

Matthijs


On 2/27/24 07:01, Nick Tait via bind-users wrote:
> 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.
>