[Opendnssec-user] Signer/HSM redundancy and database replication

[Rick van Rein]

Hello all,

Replication sounds like a 1.1 issues -- if that version is to support
TLD registries.  I wonder inhowfar... ?

> We're planning to set up a signing environment with redundant signer
> servers that both have their own hardware HSM.

We are looking into a similar approach for SURFnet.  Except that we
are using SAFEnet HSMs.

> The keys and the key
> information should thus be synchronized between the servers in order to
> reduce the amount of manual work when switching over to the secondary
> server. That is, the secondary server should always have the same keys
> as the primary server and should always know, which keys are currently
> active.

That means you do not want to use a procedure based on key backup.

> The keys can be obviously synchronized by replicating the encrypted
> keystore file between the servers (at least when using Sun SCA).

Yes, this functionality belongs in the HSM, and you would thus end up
with such an HSM-specific reasoning.  With Safenet HSMs, we'll end up
using a client library that replicates all updates accross two HSMs.

OpenDNSSEC should not even try to manage keys, as that is the HSM domain.
As a poor man's solution there is the support for manual key backup, which
basically stops the use of keys until they have been backed up.  See the
man page on ksmutil for details.

> In
> addition to the keystore, is it enough to replicate the KASP database
> (kasp.db) between the servers? It seems that the kasp.db contains all
> the information about the keys and their states, but please let me know
> if there are some other files that need to be synchronized.

Normally, the KASP database is filled from configuration files, so
you would need to sync those in addition to the database?  AFAIK there
is no "export KASP DB to /etc/opendnssec/*.conf" command, so the DB
alone may not suffice.

It sounds like this batch backup procedure would require KASP to not
use a key until its metadata has been replicated; so if you would
also need the key backup facilities to manage replication of metadata.

I'm also wondering if mere MySQL replication is designed to work for
the KASP database to be updated?  MySQL replication can work in either
master-master or master-slave mode, and it is able to use different
autoincrement IDs in master-master mode.  (I think master-master is
needed to have to active signers at the same time, and master-slave
could support a disaster fallback signer.)


I hope this helps,

Cheers,
 -Rick