由于缺乏更好的标题。我们的环境需要有子域，我们允许使用 bind 作为 DNS 服务器进行动态更新，并使用其 nsupdate 实用程序通过密钥文件进行身份验证。我们希望使这更加冗余。目前，我们为所有这些子域配备了一个主名称服务器，并为我们的顶级域配备了多个辅助名称服务器（但不为子域配备）。例如，使用 bar.com 作为 TLD，使用 foo.bar.com 作为子域。foo.bar.com 子域区域文件将具有类似以下内容的条目：
NS ns1.bar.com
A 1.2.3.4
MX mx1.bar.com
www A 1.2.3.5
...
并且主区域文件将包含“foo”的条目，例如：
foo NS ns1.bar.com
目前，子域名不会复制到其他名称服务器，即 ns1 是唯一可以解析这些子域名的名称服务器，即使 ns2、ns3 等设置为 bar.com 域的辅助服务器。关于如何更可靠地进行设置的想法？如果删除 bar.com 区域文件中的胶水记录，并在每个子域名中设置多个 NS 记录（并将它们设置为辅助名称服务器上的从属服务器），这将有助于解析域名，但如果子域名需要更新，它不会有助于提供备用“更新”服务器。如果此示例中的 ns1 已关闭，那么如何允许 nsupdate 客户端更新其区域并将其复制到其他名称服务器以及 ns1 重新上线时？使用 Bind 是否可行？
答案1
也许这会有所帮助 - BIND 可以使用 MySQL 作为后端（您可能需要重新编译它并启用正确的选项），并且 MySQL 有 Cluster 版本（也是免费的），它有点多主。也许可以将它们组合在一起以满足您的需求... 还有 PowerDNS，它也可以使用 SQL 作为后端。
答案2
BIND9（再次 - 带有适当的补丁）能够使用 LDAP 数据库作为后端。如果您想尝试，Fedora 和 RHEL 6.4+ 包含带有 LDAP 支持的修补 BIND。
可以使用 LDAP 后端进行多主操作，每个 DNS 主服务器计算自己的序列号并将自己宣传为主服务器（以 SOA 主服务器名称），因此来自客户端的更新将分发到所有服务器。在这种情况下，数据复制在 LDAP 级别处理。
描述的多主 DNS 用于 FreeIPA 项目。FreeIPA 可以为您设置复制的 LDAP 环境。（集成/复制/多主 DNS 是 FreeIPA 的附加功能，FreeIPA 的主要重点是身份管理。）
FreeIPA 主页：http://freeipa.org/
LDAP 后端本身可以在以下位置找到https://fedorahosted.org/bind-dyndb-ldap/ 带有 BIND9“接口”的补丁可在此处找到：https://github.com/mnagy/bind-dynamic_db/downloads
答案3
DNS 协议中没有机制（更不用说 BIND 了）允许将在不同的“主服务器”上收到的动态更新合并并复制到多个从服务器（以及主“主服务器”启动时）。
您要么坚持使用具有动态更新和 IXFR 支持的“一主多辅”模型，要么使用某种形式的带外机制来更新所有服务器。