Hello, Just to add my two cents on the topic and submit what we consider good practice to other OpenDNSSEC users for discussion:
We also do key pre-generation, not because of the discussed bug, but because we consider it safer. Our HSM (AEP Keyper) provides the ability to lock its API for key generation, import and export. Hence, what we generally to pre-generate keys for a given period (e.g. 2 years): * stop ods-signer and ods-enforcer * unlock the HSM API for key generation import and export * generate the new keys (ods-ksmutil key generate --interval P2Y --policy ...) * purge the old keys (ods-ksmutil key purge --policy ...) * lock the the HSM API for key generation import and export * start ods-signer and ods-enforcer We think it is safer to have a given set of keys pre-generated and locked in the HSM protected enclosure rather than having an "open" API to generate keys. This also allow to keep a backup of the keys and to import them to a redundant unit. We also have a monitoring on the remaining keys per policy so as not to forget the next pre-generation batch. Regards, On 2019-02-13 20:00, Abdulkareem H. Ali wrote: >> On 13/02/2019 13:44, Berry A.W. van Halderen wrote: > >> >> Regarding other HSMs mentioned in this thread I cannot speculate >> at the moment without knowing the version number of OpenDNSSEC. >> Also I'm unaware of the ability of these HSMs to properly support >> concurrent access to the HSM by multiple applications. >> >> What ODS does is, that one program lets the HSM generate keys, >> and after this is done, it signals the other program (enforcer >> to signer) which key to use. If the key isn't available immediately >> (which it should, but let's be forgiving) then the signer >> will try to do again later. It only a restart will solve the >> problem then it is never possible to run any signer with external >> key generator and it is only possible to integrate all your >> software in one monolith or run any signer in one-shot mode or >> closing and reconnecting to the HSM. >> >> Such a workaround is a pain and really the HSM would need an update. >> So I don't want to do such a hack without proper reason. >> >> \Berry > > > Hi Berry > > > We actually face the issue with both version 1.4.X and 2.1.3 at the > moment. However on both instances we're using Thales HSMs, different > models and at separate locations. > > > The problem occurs even if only one zone is in the DB, and nothing else > is connecting to the HSM, so in our case there's no concurrent > connections to the HSM. We add a zone and the enforcer creates the > required keys for the first time, and then the signer can't find them > and we see the exact same error log as in this thread. > > > As mentioned previously, our workaround to limit the need to have to > restart 'ods-signers' when a ZSK rollover happens, is pregenerating keys > for each of our policies. > > > Thanks, > > Kareem. > > > > > > _______________________________________________ > Opendnssec-user mailing list > [email protected] > https://lists.opendnssec.org/mailman/listinfo/opendnssec-user > -- Guillaume-Jean Herbiet, PhD System engineer Fondation RESTENA / dns.lu 2, avenue de l'Université L-4365 Esch-sur-Alzette tel.: +352.424409 fax.: +352.422473 https://www.restena.lu https://www.dns.lu Public key ID: 0x3A4C47C7
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
