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 devel
