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 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.
It does, until you make configuration changes to the dnssec-policy. So
it will never do that on its own.
I am sorry, but so far I have heard nothing that disputes the functional
parity with 'auto-dnssec'.
Best regards,
Matthijs
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 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 <matth...@isc.org>
To: bind-users@lists.isc.org
Subject: Deprecating auto-dnssec and inline-signing in 9.18+
Message-ID: <b69d059d-3657-0b68-cb69-766d87a1d...@isc.org>
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