☰

解决反向 DNS 区域的问题

tag-icon • tag-icon domain-name-system
解决反向 DNS 区域的问题

几天前，我们注意到部分外发邮件由于远程邮件服务器无法解析我们的 IP（例如Client host rejected: cannot find your hostname, [92.240.244.176]）而被延迟。我们最近没有对 DNS 进行任何更改，我们的 ISP 也表示他们没有对其进行任何更改。

我们将 92.240.244.128/25 从他们的 ns1/ns2.lightstorm.sk 委托给我们的 ns1/n2.mojhosting.sk（我们的 ns1 运行 BIND 9.10，ns2 运行 PowerDNS 4.0）。

他们声称我们的错误在于我们，因为我们的 DNS 服务器对此查询返回了 REFUSED host 92.240.244.202 ns1.mojhosting.sk，但这种情况肯定已经持续了很长时间。也许是因为该命令查询了 （它在我们的 ISP DNS 上只是 CNAME，但在我们的委托子树202.244.240.92.in-addr.arpa.中不存在）？每次运行这两条记录似乎对我都有效。128/25.244.240.92.in-addr.arpa.dig +trace

MX工具箱说：警告：收到来自“ns1.lightstorm.sk”的非权威（蹩脚）答案，但我不知道如何检查。 全球 DNS 传播检查器表明我们的 IP 在大多数地方无法解析。

此外，我们的 ISP 的 IPv6 连接性很差，我看到他们的 ns1/ns2 也有 IPv6 地址，这也会加剧问题吗？

答案1

您的 DNS 配置以某种方式“工作”，但它并不完全正确，因此在某些情况下可能会产生问题。

原因如下。

如果你直接查询，你会得到答复：

$ dig -x 92.240.244.176 +noall +ans +nottlunits
176.244.240.92.in-addr.arpa. 3590 IN CNAME 176.128/25.244.240.92.in-addr.arpa.
176.128/25.244.240.92.in-addr.arpa. 43191 IN PTR bill3.hostio.sk.

所以我们得到了最终的PTR记录，我们应该高兴。

.然而，如果我们诊断从（根）开始的所有路径直到176.244.240.92.in-addr.arpa.我们能发现问题。

DNSViz 位于https://dnsviz.net/d/202.244.240.92.in-addr.arpa/YYzr-A/dnssec/如果你看一下错误部分，就会显示这一点：

202.244.240.92.in-addr.arpa/CNAME：响应中未设置权威答复 (AA) 标志。（92.240.232.232、92.240.232.242、2a00:10d8:11::1:0:1、2a00:10d8:11::2:0:1、UDP_-_EDNS0_4096_D_KN）

您可以使用dig +trace 202.244.240.92.in-addr.arpa. PTR +nottlunits +nodnssec下面的内容看到相同的结果（在根和 2 个域处修剪第一步）：

[..]

92.in-addr.arpa.    86400 IN NS ns3.afrinic.net.
92.in-addr.arpa.    86400 IN NS pri.authdns.ripe.net.
92.in-addr.arpa.    86400 IN NS ns3.lacnic.net.
92.in-addr.arpa.    86400 IN NS ns4.apnic.net.
92.in-addr.arpa.    86400 IN NS rirns.arin.net.
;; Received 245 bytes from 200.10.60.53#53(d.in-addr-servers.arpa) in 199 ms

244.240.92.in-addr.arpa. 172800 IN NS ns1.lightstorm.sk.
244.240.92.in-addr.arpa. 172800 IN NS ns2.lightstorm.sk.
;; Received 133 bytes from 199.253.249.53#53(rirns.arin.net) in 142 ms

;; expected opt record in response
202.244.240.92.in-addr.arpa. 3600 IN CNAME 202.128/25.244.240.92.in-addr.arpa.
128/25.244.240.92.in-addr.arpa. 3600 IN NS ns1.mojhosting.sk.
128/25.244.240.92.in-addr.arpa. 3600 IN NS ns2.mojhosting.sk.
;; Received 119 bytes from 92.240.232.242#53(ns2.lightstorm.sk) in 173 ms

但最后一个答案有问题，缺少“AA”（权威答案）标志。这个最终名称服务器 ( ns1.lightstorm.sk) 提供了一些数据（CNAME记录），但没有表明它对此具有权威性，而它应该这样做。

请参阅此答案，无需不必要的详细信息：

$ dig @ns1.lightstorm.sk. 202.244.240.92.in-addr.arpa. PTR

[..]

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32312
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;202.244.240.92.in-addr.arpa. IN    PTR

;; ANSWER SECTION:
202.244.240.92.in-addr.arpa. 1h IN CNAME 202.128/25.244.240.92.in-addr.arpa.

;; AUTHORITY SECTION:
128/25.244.240.92.in-addr.arpa. 1h IN NS ns1.mojhosting.sk.
128/25.244.240.92.in-addr.arpa. 1h IN NS ns2.mojhosting.sk.

注意“标志”部分，它应该有一个“AA”标志。此外，它有“RA”（递归可用）这一事实似乎表明该名称服务器既是权威的又是递归的，这在大多数情况下是一个坏主意，这两项服务应该是分开的。

递归名称服务器将看到这一点，并拒绝继续，因此您会收到各种错误。ns1.lightstorm.sk.+的所有者ns2需要修复其配置，问题出在这里，而不是其他地方。

如果您想比较，这是一个类似的设置，但适用于 IP 162.202.233.81。

请注意 DNSViz 没有显示任何错误：https://dnsviz.net/d/81.233.202.162.in-addr.arpa/YY1_ag/dnssec/

并且如果您重做最后一步来与上面的步骤进行比较：

$ dig @ns2.swbell.net. 81.233.202.162.in-addr.arpa. PTR

[..]

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24342
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;81.233.202.162.in-addr.arpa. IN    PTR

;; ANSWER SECTION:
81.233.202.162.in-addr.arpa. 2h IN CNAME 81.80/29.233.202.162.in-addr.arpa.

;; AUTHORITY SECTION:
80/29.233.202.162.in-addr.arpa. 2h IN NS ns2.archaxis.net.
80/29.233.202.162.in-addr.arpa. 2h IN NS ns1.archaxis.net.

请注意“标志”部分的不同之处。

FWIW 反向树中的这种设置是在 RFC 2317“无类 IN-ADDR.ARPA 委派”中设计的，用于CNAME能够对树的各个部分进行子委派。

相关内容