跑步绑定9.8.2。 我已经使用DNS主/服务器对成功设置了“视图”的TSIG密钥。 每个视图的两台服务器之间的区域传输按预期工作。 在我们投入生产之前，我需要对一些事情做一些澄清。 我们的prod服务器也允许区域传输到除了从服务器以外的其他几个服务器。 我们有一个类似于这个的acl设置：
other_xfer_allowed { xxxx; // This is our Secondary DNS server 127.0.0.1; // localhost can make zone transfers xxxx/24; // Corporate server farm range is allowed to make zone-transfers xxxx/24; // NAT pool for internal DNS server Zone Transfers }; // end of "other_xfer_allowed" ACL 而在“允许转移”声明中，我们已经包含了该ACL。 我的问题是：
现在我们正在使用TSIG，我需要与所有这些其他服务器的pipe理员并提供他们我的TSIG密钥，以便他们可以请求区域传输？ 我想这样的事情需要做，因为它需要在从服务器上configuration，但我不确定。
下一个，
我设置了视图，以便在请求logging时，“内部”networking上的客户端将被呈现与外部客户端不同的logging。 而目前只有一个区域需要有不同的logging。 然而，我的理解是，由于视图是以源IP为基础的，如果我只在一个区域的“内部”视图中包含这个区域，如果一个logging被请求来自同一个IP的另一个区域，它们可能会得到一个nxdomain因为IP限于那一个视图。
所以，我的问题是，是否需要在两个视图中包含所有区域，以便所有客户端都可以获得结果，即使我现在只有一个区域指向两个不同的区域文件？ 在这两个视图中的所有其他人将指向相同的区域文件，除非有另一个区域，我们需要为内部客户提供一个不同的视图。
现在，最后一个问题。
我有一个关于allow-query语句的问题。 在我们的生产服务器上，我们有一个ACL列表，我们称之为“允许”。 我们在全局选项中有一个允许查询语句，只允许在允许的ACL中来自IP的查询。 然而，我们在conf文件中的每一个区域条目都有一个“allow-query {any;};语句，这是否违背了查询的”允许“ACL的目的呢？区域语句优先于全局语句？
现在我们正在使用TSIG，我需要与所有这些其他服务器的pipe理员并提供他们我的TSIG密钥，以便他们可以请求区域传输？ 我想这样的事情需要做，因为它需要在从服务器上configuration，但我不确定。
首先，关于“提供他们我的TSIG密钥”：不，只是生成一个单一的密钥，并与您的设置涉及的每个人分享它没有太大的意义。
我会说每个派对创build一个密钥，毕竟你可以拥有尽可能多的密钥。 通过这种方式，您可以对不同的参与方进行不同的访问，并撤销一方的访问权限，而不会取消每个人的访问权限。
另外，在某些情况下使用TSIG并不一定意味着在所有情况下都使用TSIG（尽pipe这通常是可取的），但如果适用于您的场景，则可以混合使用基于IP和基于密钥的访问控制。
所以，我的问题是，是否需要在两个视图中包含所有区域，以便所有客户端都可以获得结果，即使我现在只有一个区域指向两个不同的区域文件？ 在这两个视图中的所有其他人将指向相同的区域文件，除非有另一个区域，我们需要为内部客户提供一个不同的视图。
每个查询只会打一个视图（匹配的第一个视图）。
其含义是，如果数据在客户端查询的视图中不可用，无论是在该视图的区域中，还是通过recursion（如果recursion可用于客户端，他们请求它），他们不能得到数据。
完全有可能您需要在视图之间复制更多的区域。
我有一个关于allow-query语句的问题。 在我们的生产服务器上，我们有一个ACL列表，我们称之为“允许”。 我们在全局选项中有一个允许查询语句，只允许在允许的ACL中来自IP的查询。 然而，我们在conf文件中的每一个区域条目都有一个“allow-query {any;};语句，这是否违背了查询的”允许“ACL的目的呢？区域语句优先于全局语句？
是的， zone指定的allow-query将覆盖全局allow-query值。 对于与您的区域匹配的查询，这意味着不使用全局设置，但是如果启用了recursion，那么您也正在处理与您的任何区域不匹配的查询。
请参阅手册中的allow-*设置以了解这些设置如何相互作用。