High availability

Some operators choose to deploy OpenDNSSEC in a high availability configuration. This page describes some general concepts to take into consideration when designing such a setup. 

Replicating a running instance of OpenDNSSEC

The entire state of a running instance of OpenDNSSEC does not need to be replicated. It is perfectly safe to re-sign the zone as long as you use the same key set.

Before copying data

For greater consistency consider manually running the enforcer immediately before copying data.

Before taking copies of the required data you should:

• Review the backup status of your keys (using the Require Backup option in conf.xml is recommended for high availability deployments)
• Backup your database with this command
• Stop the enforcer demon 
• If you are only using file based adapters (i.e. not AXFR or IXFR) then stop signer demon

What to copy

• The KASP database 
  
  • for MySQL also see the documentation at: myslq.com
  • for SQLite the database file is found by default in /var/opendnssec
• The configuration files (default location is the /etc/opendnssec/ directory)
• The state data
  
  • the minimum data required are the signconf files (default location is the  /var/opendnssec/signconf directory)
  • NOTE: when using only file adapters it may be convenient to copy the entire contents of /var/opendnssec directory (assuming default location)
• And, of course, the unsigned zones and keys must be available to the replicated instance

And that should be all you need to do.

After copying data

• Restart any demons that were stopped
• If restoring into an existing install of OpenDNSSEC ensure that the /var/opendnssec/tmp and /var/opendnssec/signed directories are empty

Master/Slave

Careful consideration should be given to which, if any, process are run on a slave (or on each master in a Master-Master) configuration. Some operators don't run either the enforcer or the signer on a slave instance but merely duplicate the data between the two instances in a timely fashion. Others run two master servers, both enforcing and signing but only publishing from an 'active' master.

Signatures lifetimes

When choosing signature lifetimes some consideration should be given for how long it may take to detect a failure and then fail over to a backup instance of OpenDNSSEC. Signatures should be valid for at least as long as this process is likely to take. 

Sanity checks

Many operators configure a set of sanity checks to ensure the output from 2 instances of OpenDNSSEC produce consistent results. These are often done via custom scripts. 

SOA considerations

Consideration also needs to be given to managing the zone SOA over a failure. 

User setups

Examples of user deployments can be found in the User Reference Material