Problem upgrading to 9.18 - important feature being removed

[Al Whaley]

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 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.
>>