Problem upgrading to 9.18 - important feature being removed
Matthijs Mekking
matthijs at isc.org
Tue Feb 27 14:54:08 UTC 2024
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.
>
More information about the bind-users
mailing list