Re: Problem upgrading to 9.18 - important feature being removed
Al,
On 3/4/24 17:15, Al Whaley wrote:
Matthij, Petr,
Thanks for responding.
I am trying to make the case that one can NOT do the same things with
'lifetime unlimited'. One can do some of the same positive things, but
only if conditions are just right, and one cannot block the negative
overriding key replacement. If I have it all wrong, and one can do the
same things, then I would like to understand that, but currently that
does not seem to be the case.
With 'auto-dnssec maintain' one tells bind to update the zone signing
with any RR changes and keep the signing up to date. As long as bind
finds suitable keys in the key directory, I'm done at that point. I
don't have to worry that there are conditions that will trigger bind to
replace my keys with some that it likes better, because that code
doesn't even exist in earlier versions.
You can do that with dnssec-policy, key lifetime unlimited. It is true
it takes a migration effort, but that is not unique for dnssec-policy.
Software is evolving and with major releases comes backwards
incompatible changes.
Without that 'maintain' feature, but using 'lifetime unlimited' bind
will, if it feels like it, replace my keys with some it makes itself,
which of course takes my domain(s) offline as they no longer comply with
the consistency check with the DS record at the TLD / next level up.
This is viewed by some as simply a migration problem, and therefore
simply a 'one off' thing, and once one is past that point and settled
with 9.20, no problems exist. But this isn't true. If I change my
configs in some way that bind doesn't like, or I install a new update
that has slightly different criteria for key suitability testing in the
new code, that could cause bind to 'deprecate' my keys and make its
own. I don't want bind to be making that decision. I talked more about
this problem in an earlier email. >
I would like two new features in the dnssec-policy statement.
1) please add 'key-gen no' to stop not only key generation but the
decision process about whether my keys are unsuitable so that bind
doesn't reject them any more than it would in 9.16. If future versions
of bind have additional criteria that would cause it to deprecate my
current keys, this would block them.
I am willing to consider an option 'keymgr auto/manual/off' option.
2) also please add 'algorithm any'. right now if I have a mix of
algorithms (e.g. 8 and 13) I can't have one single default policy. If I
don't specify an algorithm, bind defaults to 13, instead of
'unspecified'. My algorithm 8 keys will be deemed unsuitable,
deprecated, and will be replaced by algorithm 13 keys - a bad thing.
No, there are too many corner cases for this and goes against the DPPS
(DNSSEC Policy Practice Statement) design. If you want two algorithms
you can specify that with:
dnssec-policy {
keys {
ksk lifetime unlimited algorithm 8;
zsk lifetime unlimited algorithm 8;
ksk lifetime unlimited algorithm 13;
zsk lifetime unlimited algorithm 13;
};
};
This is one of the sources of instability that I am trying to
communicate. If at some point 13 is not well regarded and everyone is
being shepherded to some other algorithm, let's just for the minute call
it '22', then when I update bind, all my keys would get regenerated to
algorithm 22 if my policy statement doesn't specify an algorithm; the
default would be changed. Then all my domains are broken.
If you don't want that to happen, specify your own policy rather than
using the default.
Also, your zone would not be broken because BIND will start an algorithm
rollover and moves to the new state without going insecure.
I know that
I can have my software generate bind configs with different
dnssec-policy statements with different algoritms given explicitly, by
rummaging around in the key directory, figuring out which algorithm the
keys are using for various domains, and make sure the appropriate policy
statements with the right algorithm number are generated for various
domains, but it would be so much cleaner if I could have the algorithm
unspecified. > Also, just to communicate what I imagine this would mean
in all cases, if I had 'key-gen yes' (presumably the default) in a
policy statement and 'algorithm any', when bind regenerated a key, it
would use the same algorithm as the current keys. If there weren't any
current keys, then it could use the latest greatest algorithm (currently
13) though it might be best to be able to specify this, or one could
have it just not generate any and throw an error message (which I would
prefer). With large numbers of domains, there will always be a mix of
algorithms. Relations with other organizations can slow down
conversions from older algorithms to new ones.
My main point here is that I am not just trying to get bind to not 'time
out' my keys (with 'lifetime unlimited'), I am trying to prevent it
Re: Problem upgrading to 9.18 - important feature being removed
Matthij, Petr, Thanks for responding. I am trying to make the case that one can NOT do the same things with 'lifetime unlimited'. One can do some of the same positive things, but only if conditions are just right, and one cannot block the negative overriding key replacement. If I have it all wrong, and one can do the same things, then I would like to understand that, but currently that does not seem to be the case. With 'auto-dnssec maintain' one tells bind to update the zone signing with any RR changes and keep the signing up to date. As long as bind finds suitable keys in the key directory, I'm done at that point. I don't have to worry that there are conditions that will trigger bind to replace my keys with some that it likes better, because that code doesn't even exist in earlier versions. Without that 'maintain' feature, but using 'lifetime unlimited' bind will, if it feels like it, replace my keys with some it makes itself, which of course takes my domain(s) offline as they no longer comply with the consistency check with the DS record at the TLD / next level up. This is viewed by some as simply a migration problem, and therefore simply a 'one off' thing, and once one is past that point and settled with 9.20, no problems exist. But this isn't true. If I change my configs in some way that bind doesn't like, or I install a new update that has slightly different criteria for key suitability testing in the new code, that could cause bind to 'deprecate' my keys and make its own. I don't want bind to be making that decision. I talked more about this problem in an earlier email. I would like two new features in the dnssec-policy statement. 1) please add 'key-gen no' to stop not only key generation but the decision process about whether my keys are unsuitable so that bind doesn't reject them any more than it would in 9.16. If future versions of bind have additional criteria that would cause it to deprecate my current keys, this would block them. 2) also please add 'algorithm any'. right now if I have a mix of algorithms (e.g. 8 and 13) I can't have one single default policy. If I don't specify an algorithm, bind defaults to 13, instead of 'unspecified'. My algorithm 8 keys will be deemed unsuitable, deprecated, and will be replaced by algorithm 13 keys - a bad thing. This is one of the sources of instability that I am trying to communicate. If at some point 13 is not well regarded and everyone is being shepherded to some other algorithm, let's just for the minute call it '22', then when I update bind, all my keys would get regenerated to algorithm 22 if my policy statement doesn't specify an algorithm; the default would be changed. Then all my domains are broken. I know that I can have my software generate bind configs with different dnssec-policy statements with different algoritms given explicitly, by rummaging around in the key directory, figuring out which algorithm the keys are using for various domains, and make sure the appropriate policy statements with the right algorithm number are generated for various domains, but it would be so much cleaner if I could have the algorithm unspecified. Also, just to communicate what I imagine this would mean in all cases, if I had 'key-gen yes' (presumably the default) in a policy statement and 'algorithm any', when bind regenerated a key, it would use the same algorithm as the current keys. If there weren't any current keys, then it could use the latest greatest algorithm (currently 13) though it might be best to be able to specify this, or one could have it just not generate any and throw an error message (which I would prefer). With large numbers of domains, there will always be a mix of algorithms. Relations with other organizations can slow down conversions from older algorithms to new ones. My main point here is that I am not just trying to get bind to not 'time out' my keys (with 'lifetime unlimited'), I am trying to prevent it from deciding my keys don't meet 'current standards' and make new ones. As far as I know, there's no way to do that. regards Al On 3/4/2024 06:05, Matthijs Mekking wrote: On 3/1/24 12:23, G.W. Haywood wrote: Hi there, On Fri, 1 Mar 2024, Ond?ej Sur? wrote: On 26. 2. 2024, at 22:41, Al Whaley wrote: > 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. ... ... ultimately, the developers working on BIND 9 are just a few people and it's absolutely reasonable to remove rarely used features - especially if there's a replacement ... For every decision we make, be it adding a new feature or removing an old feature, we do carefully consider the implications ... And in this case I think it would be unfair to the developers not to mention that more than two years ago, before actually implementing this change, the developers did
Re: Problem upgrading to 9.18 - important feature being removed
On 3/1/24 12:23, G.W. Haywood wrote: Hi there, On Fri, 1 Mar 2024, Ond?ej Sur? wrote: On 26. 2. 2024, at 22:41, Al Whaley wrote: > 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. ... ... ultimately, the developers working on BIND 9 are just a few people and it's absolutely reasonable to remove rarely used features - especially if there's a replacement ... For every decision we make, be it adding a new feature or removing an old feature, we do carefully consider the implications ... And in this case I think it would be unfair to the developers not to mention that more than two years ago, before actually implementing this change, the developers did ask for comment and there was debate. If the OP took a part in that debate I missed it. See here for the FYI: https://lists.isc.org/mailman/htdig/bind-users/2022-November/106948.html In short, we said we would go forward with the deprecation, despite key creation in HSM's was not yet supported (it will be in 9.20, already merged in our development release). There is functional parity, everything you do with auto-dnssec can also be done with dnssec-policy. If you don't want to do automatic key rollovers, use 'lifetime unlimited' on keys. There is a section on manual key rollover in our kb article: https://kb.isc.org/docs/dnssec-key-and-signing-policy - Matthijs 8<-- Date: Tue, 10 Aug 2021 10:02:59 +0200 From: Matthijs Mekking To: bind-users@lists.isc.org Subject: Deprecating auto-dnssec and inline-signing in 9.18+ Message-ID: Content-Type: text/plain; charset=utf-8; format=flowed Hi users, We are planning to deprecate the options 'auto-dnssec' and 'inline-signing' in BIND 9.18. The reason for this is because 'dnssec-policy' is the preferred way of maintaining your DNSSEC zone. Deprecating means that you can still use the options in 9.18, but a warning will be logged and it is very likely that the options will be removed in BIND 9.20. We would like to encourage you to change your configurations to 'dnssec-policy'. See this KB article for migration help: https://kb.isc.org/docs/dnssec-key-and-signing-policy Do you have reasons for keeping 'inline-signing' or 'auto-dnssec' configurations? Is there a use case that is not (yet) covered by 'dnssec-policy'? Any other concerns? Please let us know. 8<-- To try to make this more positive, Maybe the lesson here is that if you're using BIND other than because it happened to come with your distro, then it's probably a good idea to keep an eye on this list to monitor the plans for development. If it says that in the ARM, which IMO it probably should, I missed that too. -- 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
Hi there, On Fri, 1 Mar 2024, Petr ?pa?ek wrote: On 01. 03. 24 12:23, G.W. Haywood wrote: ... Maybe the lesson here is that if you're using BIND other than because it happened to come with your distro, then it's probably a good idea to keep an eye on this list to monitor the plans for development.? If it says that in the ARM, which IMO it probably should, I missed that too. ARM has warning like this: https://bind9.readthedocs.io/en/v9.18.15/reference.html#namedconf-statement-auto-dnssec If you have a proposal to improve it I'm all ears. That warning is (a) specific to this issue and (b) in section 8. I was thinking of something (a) more general and (b) in section 1 - where people might see it before the attention span gives out. :) Section 1.4.6 seems the obvious existing place to say something like "The BIND users' mailing list is the place for users to get help with BIND. In addition the developers use it to gauge opinion on proposals for changes to BIND's features. If you use BIND more than casually, it's a good idea to subscribe to the list. You can do this by..." -- 73, Ged. -- 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 Fri, 1 Mar 2024, Ondřej Surý wrote: I wanted to address this comment. We (the developers) don't remove the features out of convenience or because we have 'better idea'. It's a known problem with humans that the discipline to remove items is oftentimes lacking, and that humans will tend to solve problems or "improve" things by implementing additive rather than subtractive measures. It's enough of a mental schism to consider adding and removing items as equivalent to different processes IMO. A maintainable software can't look like Katamari[1]. With the former insight, this remark may look a little different than it otherwise would. ;-) Removing unused things is an honorable and admirable objective: keep up the good work. You come onto this mailing list and tell us about it, typically well in advance. I'm generally in favor of removing unused features; emphasis is of course on "unused". -- Fred Morris, internet plumber-- 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 01. 03. 24 12:23, G.W. Haywood wrote: Do you have reasons for keeping 'inline-signing' or 'auto-dnssec' configurations? Is there a use case that is not (yet) covered by 'dnssec-policy'? Any other concerns? Please let us know. 8<-- To try to make this more positive, Maybe the lesson here is that if you're using BIND other than because it happened to come with your distro, then it's probably a good idea to keep an eye on this list to monitor the plans for development. If it says that in the ARM, which IMO it probably should, I missed that too. ARM has warning like this: https://bind9.readthedocs.io/en/v9.18.15/reference.html#namedconf-statement-auto-dnssec If you have a proposal to improve it I'm all ears. -- Petr Špaček Internet Systems Consortium -- 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
Hi there, On Fri, 1 Mar 2024, Ond?ej Sur? wrote: On 26. 2. 2024, at 22:41, Al Whaley wrote: > 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. ... ... ultimately, the developers working on BIND 9 are just a few people and it's absolutely reasonable to remove rarely used features - especially if there's a replacement ... For every decision we make, be it adding a new feature or removing an old feature, we do carefully consider the implications ... And in this case I think it would be unfair to the developers not to mention that more than two years ago, before actually implementing this change, the developers did ask for comment and there was debate. If the OP took a part in that debate I missed it. 8<-- Date: Tue, 10 Aug 2021 10:02:59 +0200 From: Matthijs Mekking To: bind-users@lists.isc.org Subject: Deprecating auto-dnssec and inline-signing in 9.18+ Message-ID: Content-Type: text/plain; charset=utf-8; format=flowed Hi users, We are planning to deprecate the options 'auto-dnssec' and 'inline-signing' in BIND 9.18. The reason for this is because 'dnssec-policy' is the preferred way of maintaining your DNSSEC zone. Deprecating means that you can still use the options in 9.18, but a warning will be logged and it is very likely that the options will be removed in BIND 9.20. We would like to encourage you to change your configurations to 'dnssec-policy'. See this KB article for migration help: https://kb.isc.org/docs/dnssec-key-and-signing-policy Do you have reasons for keeping 'inline-signing' or 'auto-dnssec' configurations? Is there a use case that is not (yet) covered by 'dnssec-policy'? Any other concerns? Please let us know. 8<-- To try to make this more positive, Maybe the lesson here is that if you're using BIND other than because it happened to come with your distro, then it's probably a good idea to keep an eye on this list to monitor the plans for development. If it says that in the ARM, which IMO it probably should, I missed that too. -- 73, Ged. -- 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 01. 03. 24 8:01, Ondřej Surý wrote: On 26. 2. 2024, at 22:41, Al Whaley wrote: 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. Hi, I wanted to address this comment. We (the developers) don't remove the features out of convenience or because we have 'better idea'. A maintainable software can't look like Katamari[1]. Yes, sometimes we have better ideas (without the quotes) and we implement them, because they make things simpler, better, more stable, faster, ... add your own. Sometimes we even break things. But ultimately, the developers working on BIND 9 are just a few people and it's absolutely reasonable to remove rarely used features - especially if there's a replacement either in or out of BIND 9. Giving a choice is great, but then **who** will carry the costs of giving the choice? Maintaining all kind of knobs and options does come with burden and that burden might ultimately lead to a situation where all the time and resources are spent on maintaining those old features, and there's not enough left to add new improvements. For every decision we make, be it adding a new feature or removing an old feature, we do carefully consider the implications it has on the users, on the developers, and on the world as a whole. And it is kind of hurtful to imply that we do things just because "we know better" (paraphrasing). I want to add a math exercise. Assume: - BIND config has 300 statements - none are context-dependent - all statements have only yes/no options - all bugs are caused ONLY by combination two options - all bugs are 100 % reproducible and do not depend on data (cache, zones, RPZ rules etc.) Under these very simplistic assumptions we get roughly 300!/(300-2)! = 89 700 subsets of 2 statements. For these, we get 89 700 * 4 = 358 800 possibly problematic boolean combinations. Mere 358 800 config combinations to test! Piece of QA cake, obviously. -- Petr Špaček Internet Systems Consortium P.S. My combinatorics is really really rusty, but I think that even if I got it wrong by two orders of decimal magnitude you get the idea. -- 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 26. 2. 2024, at 22:41, Al Whaley wrote: > > 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. Hi, I wanted to address this comment. We (the developers) don't remove the features out of convenience or because we have 'better idea'. A maintainable software can't look like Katamari[1]. Yes, sometimes we have better ideas (without the quotes) and we implement them, because they make things simpler, better, more stable, faster, ... add your own. Sometimes we even break things. But ultimately, the developers working on BIND 9 are just a few people and it's absolutely reasonable to remove rarely used features - especially if there's a replacement either in or out of BIND 9. Giving a choice is great, but then **who** will carry the costs of giving the choice? Maintaining all kind of knobs and options does come with burden and that burden might ultimately lead to a situation where all the time and resources are spent on maintaining those old features, and there's not enough left to add new improvements. For every decision we make, be it adding a new feature or removing an old feature, we do carefully consider the implications it has on the users, on the developers, and on the world as a whole. And it is kind of hurtful to imply that we do things just because "we know better" (paraphrasing). 1. https://en.wikipedia.org/wiki/Katamari_Damacy Ondřej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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/27/24 19:35, Michael Richardson wrote: Matthijs Mekking wrote: > As the main developer of dnssec-policy, I would like to confirm that > what has been said by Michael and Nick are correct. Cool. > - When migrating to dnssec-policy, make sure the configuration matches > your existing keys. Is there a way to validate the policy against what's in a specific zone/directory? Effectively, "do your key management stuff --just-kidding --verbose"? There is nothing like that today. > - Most issues that were shared on this list have to do with migrating > to dnssec-policy. Agreed: and it bit me, and I am still a bit shell shocked. > - If you feel like the DS is stuck in 'rumoured' state you might need > to run 'rndc dnssec -checkds seen' on the key. okay, good to know this. . o O ( Umbrella Academy ) > - 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. Are there open issues? So far this were only ideas and not turned into gitlab issues, but things that I have been considering is a check to see if migration is complete (that would prevent any other policy changes), a named-checkconf option to see if the dnssec-policy configuration matches the existing key-directory. Carsten created an issue for dry-running a migration: https://gitlab.isc.org/isc-projects/bind9/-/issues/4606 -- 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
AW: Problem upgrading to 9.18 - important feature being removed
> -Ursprüngliche Nachricht- > Von: bind-users Im Auftrag von Carsten ... > It would be nice to have a "dry-run" mode in BIND 9, where BIND 9 would > report steps it would do because of "dnssec-policy", but will not execute the > changes. If this Bind9 is only a hidden primary, disable all outgoing XFR for the respective zone, and make a copy of the Bind config and zone/journal files. That way you could test the new config and avoid leakage of broken/unwanted zones. Regards Klaus -- 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
Matthijs Mekking wrote: > As the main developer of dnssec-policy, I would like to confirm that > what has been said by Michael and Nick are correct. Cool. > - When migrating to dnssec-policy, make sure the configuration matches > your existing keys. Is there a way to validate the policy against what's in a specific zone/directory? Effectively, "do your key management stuff --just-kidding --verbose"? > - Most issues that were shared on this list have to do with migrating > to dnssec-policy. Agreed: and it bit me, and I am still a bit shell shocked. > - If you feel like the DS is stuck in 'rumoured' state you might need > to run 'rndc dnssec -checkds seen' on the key. okay, good to know this. . o O ( Umbrella Academy ) > - 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. Are there open issues? signature.asc Description: PGP signature -- 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
Hi Ondřej, > On 27. Feb 2024, at 16:43, Ondřej Surý wrote: > > Carsten, could you please fill a feature request in the GitLab? Done, #4606. Greetings Carsten -- 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
Hi Jim, > On 27. Feb 2024, at 16:39, Jim P. via bind-users > wrote: > > There should also be an option to display the current configuration in > specific detail to easily create a new KASP (side question: why does DNS > need a new acronym?) The term “KASP” for “Key-and-signing-policy” has been around in the DNS community for many years. I remember first hearing that term when .SE (Sweden) started signing their TLD in 2005. In the beginning of DNSSEC deployment, the KASP was a document that defines how DNSSEC is implemented for a given DNS zone (that is still a good practice, writing down DNSSEC algorithms used, key sizes and rollover intervals etc). In the last years, improvements in the DNS server software (OpenDNSSEC, Knot DNS, but also BIND 9) made it possible to define the KASP in the software, which makes it easier to match the KASP document with the KASP configuration on the server itself. From my view, this is a good development. Greetings Carsten -- 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
Carsten, could you please fill a feature request in the GitLab? Thanks, -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 27. 2. 2024, at 16:06, Carsten Strotmann via bind-users > wrote: > > Hi Matthijs, > >> On 27 Feb 2024, at 15:54, Matthijs Mekking wrote: >> >> - When migrating to dnssec-policy, make sure the configuration matches your >> existing keys. > > the most problems I've seen so far have to do with this step: admins "think" > they have created a configuration that matches the current keys, but they > haven't (for one reason or other, it happens for me, despite working a lot > with DNSSEC and BIND 9). > > It would be nice to have a "dry-run" mode in BIND 9, where BIND 9 would > report steps it would do because of "dnssec-policy", but will not execute the > changes. > > That way, admins can create a configuration with "dry-run" mode enabled, > check the logfiles, and if the actions in the log-file match the > expectations, the "dry-run" mode can be removed and the new configuration > will become active. > > Greetings > > Carsten > -- > 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 -- 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 Tue, 2024-02-27 at 16:06 +0100, Carsten Strotmann via bind-users wrote: > It would be nice to have a "dry-run" mode in BIND 9, where BIND 9 > would report steps it would do because of "dnssec-policy", but will > not execute the changes. **This** ^^^ There should also be an option to display the current configuration in specific detail to easily create a new KASP (side question: why does DNS need a new acronym?) I don't do DNS as a full time job, so I'm in the dark on a lot of the reasoning and needs for all these changes, BUT simple testing that I have done have shown me that dnssec-policy fails often enough that I'm planning on waiting until the last possible hour in hopes that there is better tooling and simpler documentation. Not everyone running a DNS server can afford the time to be an expert at bind9, and I doubt that ISC only wants to have bind9 used by the 42 people who are experts of bind9. -Jim P. -- 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
Hi Matthijs, On 27 Feb 2024, at 15:54, Matthijs Mekking wrote: > - When migrating to dnssec-policy, make sure the configuration matches your > existing keys. the most problems I've seen so far have to do with this step: admins "think" they have created a configuration that matches the current keys, but they haven't (for one reason or other, it happens for me, despite working a lot with DNSSEC and BIND 9). It would be nice to have a "dry-run" mode in BIND 9, where BIND 9 would report steps it would do because of "dnssec-policy", but will not execute the changes. That way, admins can create a configuration with "dry-run" mode enabled, check the logfiles, and if the actions in the log-file match the expectations, the "dry-run" mode can be removed and the new configuration will become active. Greetings Carsten -- 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
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 '). - 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. -- 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
Hi, Here is a (possibly) helpful guide that might be of use when migrating from auto-dnssec to dnssec-policy: https://kb.isc.org/docs/dnssec-key-and-signing-policy Thank you, Darren Ankney On Tue, Feb 27, 2024 at 1:01 AM 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. > -- > 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 -- 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 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
