Hi Dave,
>I presented on something similar at OARC a couple of years ago:
>https://www.dns-oarc.net/files/workshop-201005/ha-opendnssec-oarc.pdf
Thanks Dave,I have read that pdf file carefully and I have some questions:
1. "Add a new zone on the active signer, create 2 years of keys in advance"
That's a great idea and there is no need to worry about the sync between the
signer server and its backup server, but can OpenDNSSEC create keys and add
relation them to a specific zone? We don't have HSM now, so we have to make and
save keys with SoftHSM.
2. Signer Backup
You need to stop OpenDNSSEC first and then make a tarball after that zone files
are rsynced out and finally start the OpenDNSSEC. How do you determine which
time is suitable to stop OpenDNSSEC, what if when the ods-signerd is still
doing the signature work. Do you think stop the processes does little harm to
the normal work flow? If we don't stop OpenDNSSEC and rsync the zone files,
then there may be sometime when the rsync work not finished and the signer who
is using new keys meets disastrous situation, say power-off. So I think stop
OpenDNDSSEC is correct, but we should make rsync work just before signing work
starts, then we can guarantee the keys used by signer is stored on the backup
server. I think <RequireBackup> may help,if we don't run command like backup
prepare the keys newly generated will not be used in signing zones, we can run
ods-ksmutil backup prepare and ods-ksmutil backup commit and then do rsync work
immediately.
3. Zone data flow
Is the full zone file created by zone authoring every time? What about
authoring zone in the signer server? You rsync the signed zone files out to
BIND and let it reload the whole signed file? Do you have any test results
about the time consuming? Our zone files are all large enough to exceed a
million domains, is that method suitable for us?
>We solve the key synchronization problem by creating 2 years of keys in
>advance, ensure that they are present on all HSMs before using them in
>production. We don't run multiple OpenDNSSEC's
>concurrently. There is only one live at a time, but we back it up frequently
>and copy that full backup to the slave signer. When we need to use the slave
>signer we restore the last good backup
>onto it and then turn it up. That way the last known good key state is used.
>We also don't do automatic failover, our signature expiry time is long enough
>to allow for us to detect a problem and have a human check it out and follow
>the change->management process before doing anything. We could surely do this
>differently to allow for fully automated failover, but we decided to err on
>the side of caution. Fortunately we're not in
>a situation where we have to guarantee that updates to zones passing through
>the signer have to always be made in less time than we typically take to do
>manual intervention in the case of
>problems. Others may not have that luxury.
Yes, the signature expire time is long enough to have a human check, but if we
do not do automatic failover the updates to zones can not be published in time.
We are in a situation that updates to zones passing through the signer have to
always made in less than 15min or so, so we have to resign the zones in a short
time and make the new data available for dig, and that's why automatic failover
is considered by us .
Best regards,
Stuart
_______________________________________________
Opendnssec-user mailing list
Opendnssec-user@lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
