Re: Problem upgrading to 9.18 - important feature being removed
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
Re: Problem upgrading to 9.18 - important feature being removed
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
Problem upgrading to 9.18 - important feature being removed
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. -- 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
BIND 9.16 is approaching EOL in April, 2024
The BIND 9.16 release branch is approaching EOL as of April, 2024. We encourage users running 9.16 or (gasp) 9.11, to upgrade to 9.18. The 9.18 branch has consistently out-performed the 9.16 branch, and we are confident that it is more stable than 9.16. One of our support engineers has prepared a helpful knowledgebase article on updating from 9.16 to 9.18 (https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918) which may be useful to you as you plan your migration. For an overview of our release plan, we maintain another knowledgebase article (https://kb.isc.org/docs/aa-00896). This was updated earlier this month, to move the start of future new stable branches from Q1 to Q2. The problem with starting a new stable branch in Q1 is, after the long holiday quiet period, we always have a number of important fixes and changes we need to release *before* we can start a new stable branch. We are currently projecting that our next stable branch, BIND 9.20, will be released in Q2. For your convenience, we also maintain our planned EOL dates listed next to each software release on https://www.isc.org/download/. Vicky Risk-- 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
