这里是快速和肮脏的：在BIND9与视图之间共享的dynamic区域，做一个nsupdate，更新/创build/删除一个logging将工作正常，如果我从一个客户端查询该logging落入同一视图我做nsupdate从。
从一个与我以前用nsupdate 不一样的视图查询的时候，将会抛出NXDOMAIN（如果添加一条新logging），或者在更改/更新时显示旧的logging信息，直到某个任意长度的时间（比如说15分钟）通行证，或者我强制执行$ rndc freeze && rndc thaw 。 $ rndc sync似乎没有做任何事情来解决这个问题 – 我希望这只是一个日记文件的事情，因为日记刷新logging大约15分钟。
如果不清楚的话，下面是一些让我们开始的伪代码：
BIND视图
view "cdn-redir" { match-clients { 10.1.1.0/24; 10.1.2.0/24; }; include "cdn-zone.db"; include "dynamic-zone.db"; }; view "default" { match-clients { any; }; include "dynamic-zone.db"; };
示例命令行
user@ns:~$ nsupdate -k rndc.key > server localhost > zone example.com. > update add foohost.example.com. 600 A 10.5.6.7 > send > quit user@ns:~$ dig foohost.example.com (resolv.conf points to 127.0.0.1) [ responds with correct answer 10.5.6.7 ]
在其他地方，主机与nsupdate的视图相同
[email protected]:~$ foohost.example.com (resolv.conf points to above nameserver) [ responds with correct answer 10.5.6.7 ]
在其他地方，主机与nsupdate不一样
[email protected]:~$ dig foohost.example.com (resolv.conf points to above nameserver) [ responds with NXDOMAIN even though I'm asking the same server ]
在这一点上，如果我有耐心，这个问题最终会自行解决（也许15分钟），但我经常没有耐心的奢侈，所以我被迫在域名服务器上$ rndc freeze && rndc thaw强行解决问题。
另一方面
在事情完全颠倒的一面，如果我从属于“cdn-redir”视图的地址对服务器执行nsupdate，则问题会自行反转。 来自匹配“cdn-redir”的客户端的后续查询在nsupdate之后立即得到正确的logging，而没有用“rndc freeze / thaw”来摆弄， 但是查询来自“cdn-redir”视图之外的地址的查询现在具有延迟/ rndc愚蠢性。
我最终的问题
如果它像42一样简单，我会张开双臂。
我想避免“rndc freeze && rndc解冻”，因为害怕丢失来自DHCP服务器的dynamic更新。 有谁知道如何更有效/更有效地获得更新的logging之间的logging同步，或者可以指出哪里可能会出错？
编辑：BIND 9.9.5 / Ubuntu 14.04，但它发生在Ubuntu和BIND的以前的版本。
谢谢大家！
按照Andrew B的要求，这是编辑（和部分）区域：
$ORIGIN . $TTL 3600 example.com IN SOA ns1.example.com. HOSTMASTER.example.com. ( 2009025039 ; serial 900 ; refresh 15 600 ; retry 10 86400 ; expire 1 day 900 ; minimum 15 min ) NS ns1.example.com. $ORIGIN example.com. $TTL 30 AEGIS A 10.2.1.60 TXT "31bdb9b3dec929e051f778dda5abd0dfc7" $TTL 86400 ts-router A 10.1.1.1 A 10.1.2.1 A 10.1.3.1 A 10.1.4.1 A 10.1.5.1 A 10.1.6.1 A 10.1.7.1 A 10.1.8.1 A 10.2.1.1 A 10.2.2.1 A 10.2.3.1 ts-server A 10.2.1.20 ts-squid0 A 10.2.2.20 ts-squid1 A 10.2.2.21 $TTL 600 tssw4 A 10.2.3.4 tssw5 A 10.2.3.5 tssw6 A 10.2.3.6 tssw7 A 10.2.3.7 ; wash rinse repeat for more hosts $TTL 30 wintermute A 10.2.1.61 TXT "003f141e5bcd3fc86954ac559e8a55700"
不同的观点单独行事，这实际上比运行单独的命名实例更方便。 如果在不同的视图中有相同名称的区域，这只是巧合，它们仍然是完全独立的区域，没有任何其他区域更相关。
有多个单独的区域使用相同的区域文件不能在绑定更新区域内容（奴隶区域，具有dynamic更新的区域等）的情况下工作。 我不确定是否有损坏区域文件本身的风险。
您可以通过将一个视图中的区域作为另一个视图中具有相同名称的区域的从属设备来设置您想要执行的操作。 这显然是一个有点复杂的configuration，但使用TSIG密钥的匹配客户端以及通知/转让我相信它应该是可行的。
编辑：国际学习中心已经发布了这种情况下的知识库文章， 如何共享多个视图之间的dynamic区域？ ，提示上面提到的同样的configuration。
这是他们的configuration例子，有一些改进的格式：
key "external" { algorithm hmac-md5; secret "xxxxxxxx"; }; key "mykey" { algorithm hmac-md5; secret "yyyyyyyy"; }; view "internal" { match-clients { !key external; 10.0.1/24; }; server 10.0.1.1 { /* Deliver notify messages to external view. */ keys { external; }; }; zone "example.com" { type master; file "internal/example.db"; allow-update { key mykey; }; also-notify { 10.0.1.1; }; }; }; view "external" { match-clients { key external; any; }; zone "example.com" { type slave; file "external/example.db"; masters { 10.0.1.1; }; transfer-source { 10.0.1.1; }; // allow-update-forwarding { any; }; // allow-notify { ... }; }; };
有类似的意见问题，我决定摆脱他们，并将授权转移到区域。
您可以通过简单包含两个区域文件来replace问题中的视图，让当前共享的区域不受影响，并将allow-query {}添加到“dynamic-zone.db”定义中，如下所示：
zone "dynamic.zone" { allow-query { 10.1.1.0/24; 10.1.2.0/24; }; type master; file "/etc/bind/zones/master/dynamic.zone"; update-policy { .... }; };
通过这个，你实现了你设定的目标，使dynamic.zone只能从指定的networking访问，并让其他区域公开。