Problem upgrading to 9.18 - important feature being removed

[Al Whaley]

As far as I have been able to determine through some fairly extensive 
reading, a feature I depend on has fallen out of favor with the BIND 
developers, and is being removed.
DNSSEC in 9.18 has two automatic actions where the original code had 
just one, and the second cannot be disabled.
I am referring to the deprecated feature:

|auto-dnssec maintain;|

||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 am sure there are the usual people that will assure me I don't or 
shouldn't want to do what I am doing, but I am experienced and have good 
reasons.  Yes I know that I can have bind update the DS records, but for 
good reason I definitely do not want to do that.  I need some syntax 
that assures my use of existing KSK and ZSK keys and prevents bind from 
changing them.

I wonder if the bind developers are open to allowing a command in the 
new policy statement structure that blocks this 'feature' of 
automatically updating ZSK and KSK?  If there is such a thing already, I 
will be delighted to hear that I had missed seeing it.

A lot of pain and suffering in this world comes from people being sure 
they have a 'better idea' and everybody needs to do whatever.  This 
feels a bit like that.  A command that gives choice and real certainty 
would be great.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240226/f5b824ef/attachment.htm>