Le 10/08/2021 à 12:34, Matthijs Mekking a écrit :
> Hi Emannuel,
>
> Thanks for your response.
>
> On 10-08-2021 11:28, FUSTE Emmanuel via bind-users wrote:
>> Le 10/08/2021 à 10:02, Matthijs Mekking a écrit :
>>> 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.
> ...
>
>> Hello,
>>
>> As today state, it looks to me very premature.
>> inline-signing and auto-dnssec maintain are about transparent signature
>> maintenance. > dnssec-policy today is about transparent key
>> maintenance/rotation on top
>> of the engine used by "inline-signing and auto-dnssec maintain"
>> These are two distinct things for me.
>
> Could you explain what you mean with distinct? You already mention
> that it is "on top of" and to me it is exactly that: the one is the
> extension of the other: 'dnssec-policy' achieves the same things as
> 'auto-dnssec' and 'inline-signing', but is capable of more (key
> maintenance and rollover). So I don't see them as so distinct.
Yes one is built on top of the other and yes automatic key management
depend on automatic signature maintenance.
But conceptually they manage two different aspects of the DNSSEC
maintenance process, the later beeing a purely political thing (key
rotation).
>
>> Please add an example showing a dnssec-policy configuration giving the
>> same result as zone configured with inline-signing and auto-dnssec
>> maintain : auto signing without automatic key maintenance/rotation. It
>> should be another default build-in policy ("default-no-auto-rotate" or
>> something like that).
>
> dnssec-policy "no-auto-rotate" {
> keys {
> csk lifetime unlimited algorithm 13;
> };
> };
>
Ok as long as I could express what I have now, I'm fine and
dnssec-policy could be considered as a supersede of 'auto-dnssec' and
'inline-signing'.
In my case I have one active zsk (hsm), one active ksk (hsm), one
published ksk(hsm) for fast rollover (hsm) and one published but offline
key (software key).
If I could express that with dnssec-policy without enabling automatic
rotation (because of lack of full HSM support), that is perfect.
>
>> HSM support for automatic key management, pkcs11 object name mapping,
>> creation, deletion and more is completely missing from dnssec-policy.
>
> This is a good point. Key creation/deletion inside the HSM for
> dnssec-policy is on the roadmap and must be implemented.
Ok. That is my main concern.
>
>
>> There is even no LTS linux distribution with the open-sc libp11 openssl
>> engine packaged to be able to use non-deprecated (non native pkcs11)
>> HSM support.
>> For now I'm stuck with 9.11 for "on the shelf" pkcs11 support with ISC
>> bind packages.
>> With 9.16 packages I'm loosing the pkcs11 support because of lack of
>> proper version of open-sc libp11 openssl engine in most/all distribs.
>> Based on the ISC package, I should rebuild it with deprecated native
>> pkcs11 enabled or try do do a proper packaging of open-sc libp11 openssl
>> engine. One or the other is on my todo stack for ages but will become
>> more and more urgent as 9.11 is approaching definitive EOL.
>> With 9.18, I should have switched to libp11 engine and use deprecated
>> 'auto-dnssec' and 'inline-signing'.
>> As today plans, with 9.20 I should abandon HSM usage.
>
> This is planned for Q1 2024. So there is time.
Yes but time flies ;-)
Thank you
Best Regards,
Emmanuel.
_______________________________________________
Please 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
