☰

委派 /24 和 /64 反向区域

tag-icon • tag-icon bind reverse-dns delegation ptr-record
委派 /24 和 /64 反向区域

我确信我忽略了一些非常简单的事情，但我只是没有看到它……我正在尝试将我们的测试网络的 /24 和 /64 反向区域委托给测试网络内的主机。我发现 IPv4 /24 和 IPv6 /64 委托都存在同样的问题，因此我暂时将重点放在 IPv4 上。

我们在内部使用172.31.0.0/16，作为172.31.99.0/24测试网络。

我想委托99.31.172.in-addr.arpa.给测试网络中位于 172.31.99.11 和 .12 的两个新域控制器

$ORIGIN 99.31.172.in-addr.arpa.
@       NS      svr-addc1.ad.example.com.au.
@       NS      svr-addc2.ad.example.com.au.

显然，我用“示例”替换了我们的实际域名。

在完全重新加载命名之后，我从本地解析器获得了 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

对其他 /24 网络的反向查找仍可正常工作：

# 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.c.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa" IN {
    type forward;
    forwarders { 2001:xxxx:xxxx:c699::addc:21; 2001:xxxx:xxxx:c699::addc:22; };
};

使用本地解析器进行挖掘是可行的：

# dig -x 172.31.99.11 +short
svr-addc1.ad.example.com.au.

我真的不明白我做错了什么：-/

答案1

一旦在主 DNS 服务器上委派了域名，除非启用了递归，否则它将不会响应这些域名的 DNS 查询。转发之所以有效，是因为转发器默认会进行递归。您可以先尝试启用递归。

答案2

我想将 99.31.172.in-addr.arpa 委托给测试网络中位于 172.31.99.11 和 .12 的两个新域控制器

$ORIGIN 99.31.172.in-addr.arpa.
@       NS      svr-addc1.ad.example.com.au.
@       NS      svr-addc2.ad.example.com.au.

您将上述行放入哪个文件？委派应位于包含区域中（即，99.31.172.in-addr.arpa 的委派记录应存在于 31.172.in-addr.arpa 的区域内。）此外，作为一个风格问题，更改 $ORIGIN 会给您带来什么好处？它会使记录变得不那么明确，并且如果您在文件中进一步定义了其他区域内容，则可能会产生副作用。

最后，主名称服务器（而不是测试网络中的服务器）上的 named.conf 文件在其视图中是否仍然包含 99.31.172.in-addr.arpa 的区域声明？

相关内容