Problem upgrading to 9.18 - important feature being removed

[Darren Ankney]

Hi,

Here is a (possibly) helpful guide that might be of use when migrating
from auto-dnssec to dnssec-policy:
https://kb.isc.org/docs/dnssec-key-and-signing-policy

Thank you,
Darren Ankney

On Tue, Feb 27, 2024 at 1:01 AM Nick Tait via bind-users
<bind-users at lists.isc.org> 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.
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users