<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=GB2312" http-equiv=Content-Type>
<STYLE>
BLOCKQUOTE {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px; MARGIN-LEFT: 2em
}
OL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
BODY {
LINE-HEIGHT: 1.5; FONT-FAMILY: ËÎÌå; COLOR: #000080; FONT-SIZE: 10.5pt
}
</STYLE>
<META name=GENERATOR content="MSHTML 8.00.6001.18702"></HEAD>
<BODY style="MARGIN: 10px">
<DIV>Hi Dave,</DIV>
<DIV>
<DIV>>I presented on something similar at OARC a couple of years ago: <A
href="https://www.dns-oarc.net/files/workshop-201005/ha-opendnssec-oarc.pdf">https://www.dns-oarc.net/files/workshop-201005/ha-opendnssec-oarc.pdf</A></DIV>
<DIV>Thanks Dave,I have read that pdf file carefully and I have some
questions:</DIV>
<DIV>1.
"Add a new zone on the active signer, create 2 years of keys in advance"</DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>2. Signer Backup</DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>3. Zone data flow</DIV>
<DIV>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?</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>>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 </DIV>
<DIV>>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 </DIV>
<DIV>>onto it and then turn it up. That way the last known good key state is used.</DIV>
<DIV> </DIV>
<DIV>>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 </DIV>
<DIV>>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 </DIV>
<DIV>>problems. Others may not have that luxury.</DIV>
<DIV> </DIV>
<DIV>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 .</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Best regards,</DIV>
<DIV>Stuart</DIV></DIV></BODY></HTML>