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
