运行 Bind 9.8.2。我已使用 DNS 主服务器/服务器对成功设置了“视图”的 TSIG 密钥。每个视图的 2 个服务器之间的区域传输按预期工作。在投入生产之前，我需要澄清几件事。我们的生产服务器还允许将区域传输到除从属服务器之外的其他几个服务器。我们的 acl 设置类似于此：
other_xfer_allowed {
x.x.x.x; // This is our Secondary DNS server
127.0.0.1; // localhost can make zone transfers
x.x.x.x/24; // Corporate server farm range is allowed to make zone-transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
}; // end of "other_xfer_allowed" ACL
在“允许传输”语句中，我们已包含该 ACL。我的问题是：
既然我们正在使用 TSIG，我是否需要联系所有这些其他服务器的管理员并向他们提供我的 TSIG 密钥，以便他们可以请求区域传输？我认为需要做这样的事情，因为它需要在从属服务器上进行配置，但我不确定。
下一个，
我设置了视图，以便“内部”网络上的客户端在请求记录时，看到的记录与外部客户端的记录不同。目前只有一个区域需要有不同的记录。但是，我的理解是，由于视图基于源 IP，如果我只在“内部”视图中包含一个区域，如果从同一 IP 请求另一个区域的记录，他们可能会得到 nxdomain 答案，因为该 IP 仅限于该视图。
因此，我的问题是，我是否需要在两个视图中都包含所有区域，以便所有客户端都可以获得结果，即使我目前只有一个指向两个不同区域文件的区域？两个视图中的所有其他区域都将指向同一个区域文件，除非当然有另一个区域，我们需要为内部客户端呈现不同的视图。
现在，最后一个问题。
我对 allow-query 语句有疑虑。在我们的生产服务器上，我们有一个 ACL 列表，我们将其称为“允许”。我们在全局选项中有一个允许查询语句，仅允许来自允许 ACL 中的 IP 的查询。但是，conf 文件中的每个区域条目也都有一个“allow-query { any; }; 语句。这是否违背了为查询设置“允许”ACL 的目的？这是不好的设计吗？区域语句不是优先于全局语句吗？
答案1
既然我们正在使用 TSIG，我是否需要联系所有这些其他服务器的管理员并向他们提供我的 TSIG 密钥，以便他们可以请求区域传输？我认为需要做这样的事情，因为它需要在从属服务器上进行配置，但我不确定。
首先，关于“向他们提供我的 TSIG 密钥”：不，只生成一个密钥并将其与设置中涉及的每个人共享是没有意义的。
我会说为每个参与方创建一个密钥，毕竟您可以拥有任意数量的密钥。这样，您可以向不同的参与方授予不同的访问权限，并撤销一方的访问权限，而无需撤销所有人的访问权限。
此外，对某些事物使用 TSIG 并不一定意味着对所有事物都使用 TSIG（尽管它通常是更可取的），如果适合您的场景，则可以混合基于 IP 和基于密钥的访问控制。
因此，我的问题是，我是否需要在两个视图中都包含所有区域，以便所有客户端都可以获得结果，即使我目前只有一个指向两个不同区域文件的区域？两个视图中的所有其他区域都将指向同一个区域文件，除非当然有另一个区域，我们需要为内部客户端呈现不同的视图。
每个查询只会命中一个视图（第一个匹配的视图）。
这意味着，如果客户端通过查询命中的视图中没有数据，无论是在该视图的区域中还是通过递归（如果客户端可以使用递归并且他们请求了递归），他们就无法获取该数据。
您完全有可能需要于视图之间复制更多区域。
我对 allow-query 语句有疑虑。在我们的生产服务器上，我们有一个 ACL 列表，我们将其称为“允许”。我们在全局选项中有一个 allow query 语句，仅允许来自允许 ACL 中的 IP 的查询。但是，conf 文件中的每个区域条目也都有一个“allow-query { any; }; 语句。这是否违背了为查询设置“允许”ACL 的目的？这是不好的设计吗？区域语句不是优先于全局语句吗？
是的，allow-query在 a 中指定的zone将覆盖全局allow-query值。对于与您的区域匹配的查询，这意味着不使用全局设置，但是如果启用了递归，那么您还要处理与您的任何区域都不匹配的查询。
请参阅allow-*手册中的设置了解这些设置如何相互作用。