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