If you're not attached to the master/slave architecture, then you can use SVN to keep them in sync without building a master/slave relationship in BIND; the BIND servers will be serving the same data, behaving the same as they would in a master/slave configuration, without talking to each other at all or needing different configurations on the two servers.
Your SVN repository should be independent from the BIND servers - it can reside on one of them if it needs to, but you'll probably want to avoid that if you can, and give it its own server. The SVN server will hold the master copy the data, and the BIND servers will retrieve that data and serve it. From a logical perspective, the SVN server is the master and the BIND servers are slaves - but from a DNS perspective, we'll be making both BIND servers think they're masters, with a full copy of the zones.
svnsync is a tool to synchronize an SVN repository to a second copy of the same repository; depending on your architecture, you may want to use
svnsync to send a copy of your repository to a backup site, for instance. You can never commit against the repository that's having data synced to it, so it's essentially read-only, but still covers you in the event of a loss of your primary repository.
So, to get this working, there's a few things to set up:
- Set up a centrally accessible SVN server. There are several options for how to configure this; I've written a summary of the options (and some of the pros and cons of each) here. If desired, set up
svnsync to a DR server, or
svnadmin dump --incremental flat-file dump of a repository to pull into a backup.
- Build the zone files up in the SVN server, and check out a copy of the zone files into the directory where you want them stored on the BIND servers. You'll want to make sure that the BIND server can pull the data without human interaction; the password or SSH key that the BIND server is using to authenticate to SVN should be saved.
- Configure BIND to read those zone files that were checked out from SVN. Set each
zone block up with
type master; - they'll each serve the answers for queries to the zone as authoritative (as would happen in a master/slave configuration, as well).
- (One server is still the "primary master" from a DNS perspective, due to its presence in the zone's
SOA record, but that mostly just matters for dynamic updates - name resolution will work through either node)
- Set something up to keep the zone files up to date. What this'll probably look like is a cron job that runs
svn update against the SVN working directory that you checked out earlier, then sends a
reload to your BIND process through its init script to tell it that the zones have changed.
- Work with your zones through your SVN client against the repository! After you commit, the servers will grab changes, reload their zones, and serve the current data. Make sure you update the zone serials number on each change!
By the way, I definitely also condone using a configuration management tool to distribute the zone files, as 200_success has suggested. If you do that, you'll just be removing the BIND servers' connections directly to the SVN server, and the cron job supporting updates; those aspects will be handed by the configuration management tool. The rest of these notes still apply; the workflow, configuration of the BIND servers, and their behavior once configured, remain the same.