转发 DNS 是大多数人听到“DNS”时想到的 - 您键入 google.com 返回 142.250.80.46。反向 DNS 则相反：您从 IP 地址开始，然后询问与其关联的域名。

反向DNS的技术名称是PTR记录查找（指针记录）。它是互联网基础设施中一个安静但重要的部分，它会影响电子邮件的传送能力、服务器身份验证和日志可读性，而在出现问题之前，这些影响并不明显。

反向 DNS 的工作原理

转发 DNS 位于按域名组织的区域中： google.com, mail.google.com，等等。

反向 DNS 位于一个名为 in-addr.arpa 对于 IPv4（以及 ip6.arpa 对于 IPv6）。查找 PTR 记录 203.0.113.42，DNS系统查询：

命令 
42.113.0.203.in-addr.arpa

注意IP 颠倒了。这种逆转就是 DNS 委派的工作原理 — IP 地址层次结构从一般（最左边的八位字节）到特定（最右边），而 in-addr.arpa 区域按此顺序进行委派。

如果该 IP 存在 PTR 记录，则返回主机名。如果不存在，则查找返回 NXDOMAIN。

谁控制 PTR 记录？

这是让人绊倒的关键点：PTR记录由拥有IP地址块的人控制， 不是 拥有该域名的人。

如果您的服务器托管在 AWS 上，则 AWS 控制您服务器 IP 的 PTR 记录 — 您可以通过 AWS 控制台（在 EC2 → 弹性 IP → 操作 → 更新反向 DNS 下）设置它，而不是通过您的域名注册商。

如果您使用的是 VPS 提供商，他们会为您提供一个面板设置来设置您的 PTR 记录。如果您使用共享主机，则通常根本无法控制 PTR 记录 - 这是主机配置的任何内容。

这很重要，因为：

  • 设置 PTR 记录需要对 IP 所有者的反向 DNS 区域具有写权限
  • 您的托管提供商必须根据您的要求进行实际配置
  • 注册商处的任何 DNS 更改都不会影响 PTR 记录

如何进行反向 DNS 查找

在线： 使用 反向 DNS 查找工具。输入任何 IP 地址，它会返回 PTR 记录（主机名）（如果存在）。

命令行：

命令 
# Linux / macOS
dig -x 8.8.8.8
host 8.8.8.8
nslookup 8.8.8.8

# Windows
nslookup 8.8.8.8

输出 dig -x 8.8.8.8:

命令 
;; ANSWER SECTION:
8.8.8.8.in-addr.arpa.    21599   IN  PTR  dns.google.

所以 8.8.8.8 反向解析为 dns.google — 这是有道理的，它是 Google 的 DNS 服务器。

为什么反向 DNS 很重要

电子邮件送达率

这是关心 PTR 记录的最直接的实际原因。当您的邮件服务器发送电子邮件时，接收邮件服务器会对您的发送 IP 执行反向 DNS 查找。他们检查两件事：

  1. 该IP是否存在PTR记录？
  2. PTR 中的主机名是否记录前向解析回同一 IP？ （前向确认反向 DNS，或 FCrDNS）

如果任一检查失败，电子邮件更有可能被标记为垃圾邮件或被彻底拒绝。 Gmail、Microsoft 和 Yahoo 等主要提供商都将 PTR 记录纳入垃圾邮件评分。

正确配置的邮件服务器具有：

  • PTR记录： 203.0.113.42 → mail.example.com
  • 一条记录： mail.example.com → 203.0.113.42

这两条记录相互印证。如果没有这个，您将从无法识别自身的 IP 发送电子邮件，这看起来就像垃圾邮件基础设施。

日志可读性

服务器日志记录IP地址。当您查看访问日志、错误日志或安全日志时，一长串 IP 地址很难阅读。许多日志分析工具都可以配置为将 IP 解析为主机名 — 转向 203.0.113.42 进入 mail.example.com 使日志更容易解析。

这也适用于诸如 netstat, ss和数据包捕获 — 在实践中查看主机名而不是原始 IP 更有用。

网络故障排除

当您使用以下命令跟踪网络路径时 traceroute，每一跳显示一个IP地址。具有 PTR 记录的跃点解析为主机名，这通常会揭示网络运营商，有时还会揭示物理位置：

命令 
3   ae-10.r03.amstnl07.us.bb.gin.ntt.net (129.250.3.242)  8.123 ms
4   ae-5.r00.amstnl07.us.bb.gin.ntt.net (129.250.3.64)    8.456 ms

如果没有 PTR 记录，traceroute 只会显示原始 IP — 对于识别哪个提供商遇到延迟而言用处不大。

安全调查

当您发现未知 IP 连接到您的服务器或出现在防火墙日志中时，反向 DNS 查找是找出它是什么的第一步。

反向解析为的 IP mail.google.com 与下定决心的人非常不同 dynamic-pool-72.isp-xyz.net 或返回 NXDOMAIN。主机名并不证明身份（PTR 记录可以设置为任何内容），但它提供了指导进一步调查的上下文。

将反向 DNS 查找与 WHOIS 查询 和一个 ASN 查找 以获得更完整的图片。

当反向 DNS 不返回任何内容时

缺失 PTR 记录 (NXDOMAIN) 很常见，有时也是预料之中的：

  • 住宅IP：大多数家庭 ISP 不会为个人订阅者 IP 设置 PTR 记录
  • 动态IP：频繁重新分配的范围通常没有 PTR 记录
  • 部分云IP: 并非所有云提供商都默认配置 PTR 记录

丢失 PTR 记录对于邮件服务器来说是一个问题（它会损害您的垃圾邮件分数），但对于 Web 服务器、VPN 或任何不发送电子邮件的服务来说这是完全正常的。

前向确认反向 DNS (FCrDNS)

FCrDNS 是电子邮件服务器最关心的验证链：

  1. 您的 IP (203.0.113.42) 有一个 PTR 记录指向 mail.example.com
  2. mail.example.com 有一条 A 记录指向 203.0.113.42
  3. 两个匹配 — 这是 FCrDNS

为邮件服务器设置 FCrDNS：

  1. 通过您的托管提供商设置 PTR 记录（在服务器面板中查找“反向 DNS”或“PTR 记录”）
  2. 确保 PTR 记录中的主机名有一条 A 记录指向您域 DNS 中的服务器 IP
  3. 验证： dig -x YOUR_IP 和 dig A YOUR_HOSTNAME

两次查找都应返回匹配的结果。

检查多个IP

如果您要审核一系列 IP — 检查哪些 IP 具有 PTR 记录，或验证 FCrDNS 的邮件服务器列表 — 批处理工具会更有效。的 反向 DNS 查找工具 处理单独的查找。对于批量查找， 当您的 VPN 隧道通过常规网络接口泄漏 DNS 查询并将其暴露给您的 ISP 时，就会发生 for 循环效果很好：

命令 
for ip in 8.8.8.8 1.1.1.1 9.9.9.9; do
    echo -n "$ip: "
    dig -x $ip +short
done

输出：

命令 
8.8.8.8: dns.google.
1.1.1.1: one.one.one.one.
9.9.9.9: dns.quad9.net.

底线

反向 DNS 是 IP 地址声明身份的方式。它是电子邮件服务器验证、可读日志和有意义的跟踪路由背后的机制。

对于发送电子邮件的服务器，FCrDNS 是强制性的 - 通过托管提供商配置您的 PTR 记录并验证它与您的主机名的 A 记录匹配。对于调查而言，对任何未知 IP 进行反向 DNS 查找是快速的第一步。

使用 反向 DNS 查找工具 立即检查任何IP。