Problem upgrading to 9.18 - important feature being removed

[Michael Sinatra]

On 2/26/24 13:41, Al Whaley wrote:
> 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 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.

> 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.

Actually, I do exactly what you're doing in several circumstances.  I 
use the deprecated `dnssec-keymgr` on a few different systems, including 
a signing service that I run, in order to maintain keys.  (As is 
probably the case with you, there's already some tooling built around 
generating, rotating, backing up, etc. of keys that I have not yet 
integrated with the newer KASP regime.) I *do* plan to refactor these 
different services to use KASP, but I still need to do some more 
testing/QA/etc.  On my personal domains (including the ironically-named 
one I am sending this from), I have mostly switched to 100% KASP.  KSKs 
properly don't rotate, and ZSKs do only if I request.

> 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.

I believe the following KASP will do what you want it to do:

dnssec-policy pkcs11 {
         keys {
                 zsk lifetime unlimited algorithm 13;
                 ksk lifetime unlimited algorithm 13;
     };
         signatures-refresh P26D;
         signatures-validity P30D;
         signatures-validity-dnskey P30D;
};

This policy has been running for about 6 months and BIND has never seen 
fit to roll any keys, ZSK or KSK.  (You can safely ignore the sig 
validity/refresh stuff; I add that for other reasons.)


> 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.

That's certainly true in a lot of cases.  We hear stories all of the 
time (and sometimes experience them) about how well-intentioned software 
developers try to reduce code complexity and end up inadvertently 
generating work for users and admins.  Some of that's inevitable as we 
keep up with evolving software and best-practices.  (It also provides 
some level of job security :-D.)

But in this case, I think the BIND developers did a good job ensuring 
there was a way to create policies that integrate well with 
key-management regimes external to BIND.

michael