>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
