我敢肯定，我忽略了这么简单的东西，但我只是没有看到它…我试图委托我们的testingnetworking的/ 24和/ 64反向区域到testingnetworking内的主机。 我看到IPv4 / 24和IPv6 / 64代表团都遇到同样的问题，所以我现在将重点讨论IPv4。
我们在内部使用172.31.0.0/16是Testnetworking。
我想委托99.31.172.in-addr.arpa. 到172.31.99.11和.12的testingnetworking中的两个新的域控制器
$ORIGIN 99.31.172.in-addr.arpa. @ NS svr-addc1.ad.example.com.au. @ NS svr-addc2.ad.example.com.au.
很显然，我用“示例”取代了我们的实际域。
完成重新命名后，我从本地parsing器获取NXDOMAIN：
# dig -x 172.31.99.11 @localhost ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> -x 172.31.99.11 @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50720 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;11.99.31.172.in-addr.arpa. IN PTR ;; Query time: 29 msec ;; SERVER: ::1#53(::1) ;; WHEN: Tue Jul 9 16:38:33 2013 ;; MSG SIZE rcvd: 43
与此同时，我已经委托给IP的定向查询工作正常：
# dig -x 172.31.99.11 @172.31.99.11 ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> -x 172.31.99.11 @172.31.99.11 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44598 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;11.99.31.172.in-addr.arpa. IN PTR ;; ANSWER SECTION: 11.99.31.172.in-addr.arpa. 1200 IN PTR svr-addc1.ad.example.com.au. ;; Query time: 2 msec ;; SERVER: 172.31.99.11#53(172.31.99.11) ;; WHEN: Tue Jul 9 15:49:51 2013 ;; MSG SIZE rcvd: 81
这是正向查找的代表团，按预期工作：
$ORIGIN ad.example.com.au. @ NS svr-addc1 @ NS svr-addc2 ; glue records: svr-addc1 A 172.31.99.11 AAAA 2001:xxxx:xxxx:c699::addc:21 svr-addc2 A 172.31.99.12 AAAA 2001:xxxx:xxxx:c699::addc:22
反向查找其他/ 24networking仍然正常工作：
# dig -x 172.31.42.101 @localhost +short sw-sana.example.com.au.
编辑
如果我将区域添加到named.conf作为type forward区域，则一切工作正常：
### TEST network delegated to the new AD controllers zone "99.31.172.in-addr.arpa" IN { type forward; forwarders { 172.31.99.11; 172.31.99.12; }; }; zone "9.9.6.cxxxxxxxx1.0.0.2.ip6.arpa" IN { type forward; forwarders { 2001:xxxx:xxxx:c699::addc:21; 2001:xxxx:xxxx:c699::addc:22; }; };
并使用本地parsing器挖掘工程：
# dig -x 172.31.99.11 +short svr-addc1.ad.example.com.au.
我真的不明白我做错了什么： – /
一旦在主DNS服务器上委托了一个域，它将不会响应这些域的DNS查询，除非recursion为ON。 转发工作的原因是，转发器默认情况下是recursion的。 您可能会尝试先启用recursion。
我想委托99.31.172.in-addr.arpa。 到172.31.99.11和.12的testingnetworking中的两个新的域控制器
$ORIGIN 99.31.172.in-addr.arpa. @ NS svr-addc1.ad.example.com.au. @ NS svr-addc2.ad.example.com.au.
你把上面的行放在哪个文件中？ 代表团应该在包含区域（即代表logging99.31.172.in-addr.arpa。应该存在于区域内31.172.in-addr.arpa。）另外，作为一个风格问题，你有什么收获通过改变$ ORIGIN？ 它会使logging不那么明确地清晰，并且如果在文件中进一步定义了其他区域内容，可能会导致副作用。
最后，主名称服务器（不是testingnetworking中的名称服务器）上的named.conf文件仍包含99.31.172.in-addr.arpa的区域声明。 在其意见？