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@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@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
