On 25 feb 2010, at 10.50, Rick van Rein wrote:
>> 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.
if you do not run with manual key generation (i.e. pre-generated keys), you
need to make sure the HSM:s at all replicas are sync before starting the
enforcer the replica. what keys are currently active is stored in the KASP
database only.
> OpenDNSSEC should not even try to manage keys, as that is the HSM domain.
the KASP enforcer will definitely manage the keys as in create (and delete)
them. it will however not replicate them between difference HSM:s, but you know
that.
> 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.
yes, you may need to replicate /etc/opendnssec (conf.xml, kasp.xml and
zonelist.xml) as well.
> 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.)
if anyone would consider MySQL in master-master mode, I'd take a look at MySQL
cluster (which is strictly speaking a multi-master engine, not a pure
master-master replication).
jakob
_______________________________________________
Opendnssec-user mailing list
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
