主页 / server / 问题 / 1083194
Accepted
Marki555
Asked: 2021-11-11 14:04:50 +0800 CST

解决我们的反向 DNS 区域的问题

  • 772

几天前，我们注意到由于远程邮件服务器无法解析我们的 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似乎每次都对我有用。

MXtoolbox说：Warning: Received Non-Authoritative (lame) Answer from: 'ns1.lightstorm.sk'，但我不知道如何检查它。 全球 DNS 传播检查器显示我们的 IP 无法从大多数位置解析。

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

domain-name-system

1 个回答

  1. Best Answer

    您的 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记录，我们应该很高兴。

    但是，如果我们从.(root) 诊断所有路径，直到176.244.240.92.in-addr.arpa.我们发现问题为止。

    如果您查看错误部分，则https://dnsviz.net/d/202.244.240.92.in-addr.arpa/YYzr-A/dnssec/上的DNSViz 会显示它：

    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 +nodnssecwhich 看到相同的结果（在根和 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用于对树的部分进行子委托。

    • 1

相关问题