☰

无类反向映射委托不适用于“dig -x”。这会影响什么吗？

tag-icon • tag-icon domain-name-system bind dns-zone
无类反向映射委托不适用于“dig -x”。这会影响什么吗？

网络Zytrax.com，我在那里了解到无类反向映射委托，表示dig -x <ip address>如果使用这种委派方法（使用 CNAMES），那么就不应该在这里工作。

例如：

这不应该起作用： dig -x 192.168.23.66

这应该可以工作： dig 66.64/27.168.192.IN-ADDR.ARPA

当我稍微修改它时它确实起作用了（指定它被委托到的服务器以及我想要的 PTR 记录）： dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA

它似乎按照教程中描述的方式工作：

我设置了类似的委派，它的行为如上所述：当我使用dig -x委派范围内的 IP 地址时，委派名称服务器会告诉我谁对66.64/27.168.192.IN-ADDR.ARPA.无类网络委派到的服务器拥有权限，仅适用于第三个命令（dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA）。

可以吗？安全吗？

由于它不适用于 dig -x（或 nslookup），我想知道是否还有其他方法不起作用。解析器可以毫无问题地解析此类 IP 地址吗？例如，如果使用这种委派方法，电子邮件服务器是否可以毫无问题地执行反向查找？有什么理由不使用它吗？

我的例子（略有修改）：

dig @ns1.example.com -x 192.168.134.1

;; ANSWER SECTION:
1.134.168.192.in-addr.arpa. 60  IN  CNAME   1.0-127.134.168.192.in-addr.arpa.
;; AUTHORITY SECTION:
0-127.192.113.134.in-addr.arpa. 10 IN   NS      ns2.example.com.


dig @ns2.example.com PTR 1.0-127.192.168.134.in-addr.arpa.

;; ANSWER SECTION:
1.0-127.192.168.192.in-addr.arpa. 10 IN PTR     1st_super.example.com.

为什么没有奏效

我委托的区域名称是错误的，并且由于在第二个查询中使用了错误的名称，我得到了答案（这两个错误部分互相抵消）。

错误（未反转）：

0-127.192.168.134.in-addr.arpa.

本来应该：

0-127.134.168.192.in-addr.arpa.

修复此错误并让委派服务器成为委派区域的从属服务器后，一切dig -x <ipaddress>正常。

答案1

总结

如果你创建一个RFC2317-style classless in-addr.arpa 委派，您无法使用 IP 地址的反向映射直接向权威名称服务器查询子委派，这完全正常。
真正重要的是解析器服务器可以查找反向名称（例如dig -x 192.0.2.1 @8.8.8.8，对于与您的环境/用例相关的任何 IP 地址和解析器服务器组合）。

RFC2317 解释

RFC2317 提供了一种解决方法，解决的总体问题是，从 IPv4 地址到 DNS 中的反向名称的基于约定的映射（例如192.0.2.1-> 1.2.0.192.in-addr.arpa）早于无类委派，并有效地将可能的委派点锁定到/0、/8、16、/24。/32（您只能在每个标签处委派，并且映射定义为简单地将 IPv4 地址的每个八位字节以相反的顺序定义为标签。）
映射必须以不同的方式定义，映射到一些更细粒度的命名方案，以真正允许类似委派的操作/27。

RFC2317 不会改变基本情况，实际上它不会以任何方式改变协议。
它所做的只是建议一种方案，人类操作员可以使用该方案来解决无法进行无类委托的限制。

该计划可概括如下：

  1. 你可以CNAME为实际反向区域中的某些名称集定义别名（添加记录）（根据命名约定），将这些名称映射到新命名空间
    （新的命名空间确实可以有任何名称，但 RFC2317 建议使用描述性名称，并将新命名空间作为现有区域的子名称in-addr.arpa）
  2. 您委托与此对应的区域新命名空间有必要的

结果是，被要求查找的解析器服务器1.2.0.192.in-addr.arpa将正常执行该操作，并遇到该CNAME记录，而不是PTR它真正要查找的记录。
然后，它只需跟随CNAME进入新的命名空间，而无需了解 RFC2317 是否存在，如果一切按照 RFC2317 的建议进行设置，它将找到PTR可以在该新名称中使用的记录。

例如如果你有一个2.0.192.in-addr.arpa.区域，ns1.other.example.其中包括以下内容：

1.2.0.192.in-addr.arpa. IN CNAME 1.0/27.2.0.192.in-addr.arpa.
0/27.2.0.192.in-addr.arpa. IN NS ns7.example.com.

实际的反向名称（）的查找过程1.2.0.192.in-addr.arpa.将导致CNAME，并且解析器将CNAME正常处理，无论它指向何处，都会跟随它。

在这个例子中，它导致1.0/27.2.0.192.in-addr.arpa.，并且区域也有一个委托，0/27.2.0.192.in-addr.arpa.因此ns7.example.com.解析器可以继续查找过程新名字一切都会好起来的。

另一方面，如果你向它发送查询，1.2.0.192.in-addr.arpa.它将ns7.example.com.对此一无所知。
ns7.example.com. 才不是具有该地址的反向区域，它仅具有松散相关的区域，实际的反向区域通过这些别名引用该区域。

要检查 RFC2317 样式的委托是否有效，首先，您可以检查实际解析器是否成功查找名称。
但是，深入了解细节，您需要检查实际反向区域的名称服务器响应的内容（CNAME在本例中应该是），检查规范名称（CNAME“目标”）的委托位置，然后检查该名称服务器是否按记录指定的规范名称做出响应CNAME。

相关内容