用SVNdeviseDNS主/从

如果您没有连接到主/从架构，那么您可以使用SVN保持它们同步，而不必在BIND中build立主/从关系; BIND服务器将提供相同的数据，其行为与主/从configuration中的相同，根本不需要互相通话或需要两台服务器上的不同configuration。

你的SVN仓库应该独立于BIND服务器 – 如果需要的话，它可以驻留在其中的一个服务器上，但是如果可以的话，你可能想避免这种情况，并给它自己的服务器。 SVN服务器将持有主副本的数据，BIND服务器将检索该数据并提供服务。 从逻辑的angular度来看，SVN服务器是主服务器，BIND服务器是从服务器，但是从DNS的angular度来看，我们会让这两个BIND服务器认为他们是主服务器，并带有完整的区域副本。

svnsync是一个同步SVN仓库到同一个仓库的第二个副本的工具; 根据您的体系结构，您可能希望使用svnsync将存储库的副本发送到备份站点。 您永远无法提交已同步数据的存储库，因此它基本上是只读的，但在主存储库丢失的情况下仍会覆盖您。

所以，要做到这一点，需要设置一些东西：

• 设置一个集中访问的SVN服务器。 有几个选项来configuration这个; 我在这里写了一个选项的总结（以及每个选项的一些优缺点）。 如果需要，请将svnsync设置为DR服务器，或者将svnadmin dump --incremental – 将资源库的平面文件转储设置为备份。
• 在SVN服务器中构build区域文件，并将区域文件的副本签出到您希望将它们存储在BIND服务器上的目录中。 您将需要确保BIND服务器可以在没有人工交互的情况下提取数据。 应该保存BIND服务器用来validationSVN的密码或SSH密钥。
• configurationBIND以读取从SVN签出的区域文件。 用type master;设置每个区块type master; – 他们每个都会将查询的答案作为权威性的（就像在主/从configuration中那样）。
  • （从DNS的angular度来看，一台服务器仍然是“主要的主服务器”，因为它存在于该区域的SOAlogging中，但主要对dynamic更新很重要 – 名称parsing可以通过任一节点进行）
• 设置一些东西来保持区域文件的更新。 这可能看起来像是一个cron作业，它会根据您之前签出的SVN工作目录运行svn update ，然后通过其init脚本向BIND进程reload ，告诉它这些区域已经改变。
• 通过您的SVN客户端处理您的区域对存储库！ 提交后，服务器将获取更改，重新加载其区域并提供当前数据。 确保每次更改都更新区域序列号！

顺便说一句，我绝对也宽恕使用configurationpipe理工具来分发区域文件，如200_success已经build议。 如果你这样做，你将直接删除BIND服务器的连接到SVN服务器，并支持更新的cron作业; 这些方面将由configurationpipe理工具交付。 其余这些笔记仍然适用; BIND服务器的工作stream程，configuration以及configuration后的行为保持不变。

你需要使用SVN吗？ Bind9支持主/从体系结构

然后，您可以将您的主区域文件签入SVN。

如果您使用CFEngine或Puppet来pipe理您的机器，请使用它来分发您的区域和configuration文件，并指示进程重新加载新的数据。 您的提交后脚本可以将文件写入CFEngine / Puppet主服务器并触发运行。

如果你不使用CFEngine或Puppet，你应该认真考虑这样做。 由于您在pipe理多台机器，因此这是一件非常明智的事情。

顺便提一句，我还build议从预提交脚本运行named-checkzone以防止提交重叠的区域文件。