回复: Re: [Opendnssec-user] How to do HA with opendnssec

[刘硕]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20120730/3c5f768a/attachment.htm>