BIND似乎从上到下查看configuration文件，并根据match-clients将查询分配给第一个匹配的视图。 根据http://www.zytrax.com/books/dns/ch7/view.html这正是它应该如何工作。
在我的configuration中，可能有其他视图适用于匹配客户端configuration中的用户，我想以某种方式遍历它们。 如果没有积极的冲击（从上到下是好的），理想情况下应该继续，并检查下面的观点。
这在某种程度上可能与BIND？ 这是一个例子。 在这个下面的configuration中，来自192.168.1.100或192.168.200的用户都只能到第一个视图。 相反，我希望用户192.168.1.200也访问第二个视图。
acl "kids" { 192.168.1.100; 192.168.1.200; }; view "kids"{ response-policy { zone "kids"; }; match-clients { kids; }; recursion yes; zone "kids" { type master; file "kids.db"; allow-query { none; }; }; }; acl "teens" { 192.168.1.200; }; view "teens"{ response-policy { zone "teens"; }; match-clients { teens; }; recursion yes; zone "teens" { type master; file "teens.db"; allow-query { none; }; }; }; 它不能以你想达到的方式来完成。 在第一次匹配和外部视图中查看匹配停止，只能存在一组默认的条目。 客户端只能匹配一组区域。
你可以让所有的视图都包含你想要服务于客户端的所有区域定义（在你的例子中，192.168.1.200应该只在“teens”acl中，而“teens”视图应该定义为“kids”和“青less年”区）。 您可以使用“包含”命令来避免不必要的重复，但这是事实。
绝对有可能…
acl "kids" { 192.168.1.100; }; view "kids"{ response-policy { zone "kids"; }; match-clients { kids; }; recursion yes; zone "kids" { type master; file "kids.db"; allow-query { none; }; }; }; acl "teens" { 192.168.1.200; }; view "teens"{ response-policy { zone "teens"; }; match-clients { teens; }; recursion yes; zone "teens" { type master; file "teens.db"; allow-query { none; }; }; zone "kids" { type master; file "kids.db"; allow-query { none; }; }; };
对于你的奴隶你需要使用tsig，并从视图中排除你的奴隶，请参阅如何绑定处理allow-notify和match-clients有一个例子。