I’ve created a new validation rate graph based on the statistics gathered on our resolvers. The data is up-to-date until week 43 (this week). The graph shows an interesting trend: In the graph you can see three lines representing three different resolver locations spread out across The Netherlands. What is interesting is that the validation […]
OpenDNSSEC is much more dependent on proper timing than plain DNS, mainly because of the regular rollover of keys. Because of this, a lot of care must go into the design of timing, and especially the TTL parts of DNS records.
This procedure is needed when one (not both) Hardware Security Module (or HSM) has failed. Before doing this, it should be established that there is no repair possible.
This is a nasty procedure that must only be performed if private key material of ZSK and/or KSK is (or may have been) compromised. It always leads to temporary unsatisfactory performance, which is why the chances for this are virtually eliminated with our architecture: either the domain drops out of validating resolvers, or it becomes insecure.
If either the master or slave instance of OpenDNSSEC fails, follow the procedures below. It is assumed that an empty instance is available as a cloneable virtual machine.
Every once in a while, for example once a year, the KSK for each zone needs to be rolled over. This involves communication with the parent zone, making it a little more complicated than internal-only procedures.
Making backups is a regular task. Recovering from a backup is only done when both Hardware Securite Modules (or HSMs) have lost their data; if only one got damaged, follow the procedure for HSM replacement.