我今天遇到了一个奇怪的场景。
通常当我们设置一个bind9区域logging时，我们把NSlogging放在我们的ORIGIN中。 但是今天我发现一个工作bind9安装在生产站点有NSlogging指向另一个域：
[数据/ cat_com.zone]
$ORIGIN cat.com. $TTL 600 @ IN SOA ns.tree.com. hostmaster.cat.com. ( 2015030200 21600 3600 604800 86400 ) IN NS ns.tree.com. IN NS ns2.tree.com. IN MX 10 cat.com. ns IN A 1.2.3.124 ns2 IN A 1.2.3.124 host19 IN A 1.2.3.66 并在tree.com的logging中：[data / tree_com.zone]
$TTL 600 @ IN SOA ns.tree.com. hostmaster.tree.com. ( 2015030200 ; serial 28800 ; refresh 7200 ; retry 3600000 ; expire 86400 ; default_ttl ) @ IN NS ns.tree.com. @ IN NS ns2.tree.com. @ IN MX 10 mail.tree.com. tree.com. IN A 1.2.3.66 ns.tree.com. IN A 1.2.3.124 ns2.tree.com. IN A 1.2.3.124
而在named.conf中，它有这样的：
zone "tree.com" { type master; file "data/tree_com.zone"; }; zone "cat.com" { type master; file "data/cat_com.zone"; };
所以当我尝试在cat.com上parsingAlogging的时候，比如说host19.cat.com，我可以得到1.2.3.66的logging。 这很奇怪，因为根据SOA区域文件，NSlogging指向ns.tree.com，在tree.com的SOA区域文件中没有host19.cat.com的信息。 在这种情况下，dnsparsing过程如何无误地运行？ NSlogging是在这里起作用还是只有named.conf决定哪个SOA区域文件应该被使用（在这种情况下，cat.com将引用cat_com.zone文件），cat.com中的NSloggingSOA没有任何意义？
将域名/区域文件指向域外的名称服务器是完全ns1.example.com的，也就是说，使用ns1.example.com作为example.org域的名称服务器是完全ns1.example.com的。
这不仅意味着您不需要example.org区域中的胶水logging ，而且通常也更容易pipe理。
我认为你认为外部的NSlogging（如ns1.example.com意味着example.org域的资源logging也应该从example.com区域数据中检索出来，从而产生了轻微的概念性错误。 情况并非如此，NSlogging仅指向运行该域的名称服务的主机 ，但资源logging将来自example.org域专用的区域数据。