更新到延迟视图之间共享的BIND动态区域

这是快速而又肮脏的：在具有在视图之间共享的动态区域的BIND9上，执行nsupdate，如果我从属于同一视图的客户端查询该记录，则更新/创建/删除记录将正常工作从。

从一种观点认为，查询是不一样的使用的nsupdate将抛出NXDOMAIN（如果将一个新的记录），或将显示在改变/更新直到某个时间任意长度的情况下，旧的记录信息的一个我（说15分钟）过去，或者我强行做$ rndc freeze && rndc thaw。 $ rndc sync似乎根本没有采取任何措施来解决该问题-我希望这只是日志文件，因为据记录日志刷新大约在15分钟左右。

如果不清楚，请使用下面的伪代码来入门：

绑定视图

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处于同一视图

user@10.11.12.50:~$ foohost.example.com (resolv.conf points to above nameserver)
  [ responds with correct answer 10.5.6.7 ]

在其他地方，主机与nsupdate 处于不同的视图

user@10.1.1.50:~$ 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，则问题本身就会逆转。在nsupdate之后，来自与“ cdn-redir”匹配的客户端的后续查询将立即获得正确的记录，而不会摆弄“ rndc冻结/解冻”，但是现在从超出“ cdn-redir”视图范围之外的地址进行的查询现在具有延迟/ rndc愚蠢性。

我的终极问题

如果它只有42岁，我会张开双臂...

我想避免因担心DHCP服务器缺少动态更新而不得不“ rndc冻结&& rndc解冻”。有谁知道如何更有效/有效地使视图之间的更新记录同步，或者可以阐明我可能出了什么问题？

编辑：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"

不同的视图分别起作用，这在运行单独的named实例上本质上是一种便利。如果在不同的视图中有名称相同的区域，这只是一个巧合，它们仍然是完全独立的区域，与其他任何区域都没有更多的关联。

在bind自行更新区域内容（从属区域，具有动态更新的区域等）的情况下，让多个单独的区域使用同一区域文件不起作用。我不确定是否存在损坏区域文件本身的风险。

通过使一个视图中的区域成为另一视图中具有相同名称的区域的从属，您可以设置类似您想要做的事情。显然，这将是一个有些复杂的配置，但是我将TSIG密钥用于匹配客户端以及通知/传输，我认为这应该是可行的。

编辑：ISC为此情况发布了KB文章，如何在多个视图之间共享动态区域？，建议使用与上述相同的配置。

这是他们的配置示例，格式有所改进：

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 { ... };
    };
};

对于视图也有类似的问题，我决定摆脱它们，然后将授权移到区域中。

您可以通过简单地包含两个区域文件来替换问题中的视图，让当前共享的区域保持不变，然后将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并使其他区域公开。