☰

什么是反向 DNS？

tag-icon • tag-icon domain-name-system reverse-dns
什么是反向 DNS？

我有很多*.in-地址.arpa我的 OpenDNS 帐户中的域请求。我知道这应该是正常的，并且与反向 DNS 有关。

我已经读过很多资料了，但仍然不明白它是如何工作的，为什么我会收到这么多的请求（比 www.google.com 的数量还多）。我只是需要一个像爱因斯坦建议的那样的人，可以向我解释这个反向 DNS 是用来做什么的，就像他向他的祖母解释一样。

答案1

反向 DNS 是从 IP 地址到 DNS 名称的映射。因此它类似于 DNS，但反向。如果您被分配了 IP 地址，则必须设置反向 DNS 来告诉世界这些地址的用途。

实际上，如果您想知道当前系统是什么，216.239.32.10您可以设计所谓的反向查找，方法是还原 IP 地址并向其添加 in-addr.arpa。因此它看起来像这样：10.32.239.216.in-addr.arpa。PTR 记录应该会告诉您它是什么系统。dig 工具使用 -x 开关自动执行此操作。

pehrs$ dig -x 216.239.32.10

; <<>> DiG 9.6.0-APPLE-P2 <<>> -x 216.239.32.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49177
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

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

;; ANSWER SECTION:
10.32.239.216.in-addr.arpa. 86400 IN    PTR ns1.google.com.

;; AUTHORITY SECTION:
32.239.216.in-addr.arpa. 86400  IN  NS  ns1.google.com.
32.239.216.in-addr.arpa. 86400  IN  NS  ns2.google.com.
32.239.216.in-addr.arpa. 86400  IN  NS  ns4.google.com.
32.239.216.in-addr.arpa. 86400  IN  NS  ns3.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.     205358  IN  A   216.239.34.10
ns1.google.com.     205358  IN  A   216.239.32.10
ns4.google.com.     205358  IN  A   216.239.38.10
ns3.google.com.     205358  IN  A   216.239.36.10

;; Query time: 63 msec
;; SERVER: x#53(x)
;; WHEN: Tue Jan  4 13:35:14 2011
;; MSG SIZE  rcvd: 204

注意 PTR 记录。它告诉我们216.239.32.10事实上是ns1.google.com。

答案2

简而言之，反向 DNS 用于从 IP 地址获取域名，而正常 DNS 用于从域名获取 IP 地址。

它的实际工作方式是，有一个名为 in-addr.arpa 的虚拟顶级域，为了找到 IP 地址 ABCD 的域名，DNS 客户端会在 DCBAin-addr.arpa 上进行查找。对于 in-addr.arpa 子域的委派，有各种复杂的规则，以确保这些请求到达正确的地方。维基百科文章还不错，尽管可能有点简洁：http://en.wikipedia.org/wiki/Reverse_DNS_lookup。

对你来说这意味着如果你拥有一个 IP 地址块，并且你想要能够为这些地址创建反向 DNS 记录，以便可以查找它们的域名，你需要确保无论谁给你这个地址块都已经设置了适当的委派，这样你就可以管理 in-addr.arpa 的子域，从而可以创建适当的 DNS PTR 记录。

答案3

由于您要求使用反向 DNS，请考虑以下内容。

有人想向您的邮件服务器发送一封电子邮件。它声称自己是该服务器mail.example.com。然后您可以使用反向查找来检查他的 IP 是否确实属于该地址mail.example.com。如果不是，您就知道可能出了问题。如果您甚至找不到反向条目，那就更加可疑了。（至少在最后一种情况下，邮件可能是垃圾邮件，许多提供商都会将其视为垃圾邮件。）

其他连接也是如此。事实上，sshd将标记连接尝试，就好像POSSIBLE BREAK-IN ATTEMPT!反向和正向条目不匹配一样。但默认行为是忽略它。

相关内容