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 <matthijs at isc.org>
>>> To: bind-users at lists.isc.org
>>> Subject: Deprecating auto-dnssec and inline-signing in 9.18+
>>> Message-ID: <b69d059d-3657-0b68-cb69-766d87a1dec3 at 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.
>>>