RFC 1912 第 2.1 节声明如下：
确保您的 PTR 和 A 记录匹配。对于每个 IP 地址，在 in-addr.arpa 域中都应该有一个匹配的 PTR 记录。如果主机是多宿主的（多个 IP 地址），请确保所有 IP 地址都有相应的 PTR 记录（而不仅仅是第一个）。无法匹配 PTR 和 A 记录可能会导致 Internet 服务丢失，类似于根本没有在 DNS 中注册。此外，PTR 记录必须指向有效的 A 记录，而不是 CNAME 定义的别名。强烈建议您使用一些可以自动执行此检查的软件，或者从可以自动创建一致数据的数据库生成 DNS 数据。
我觉得这毫无意义，ISP 是否应该为每个 PTR 记录匹配 A 记录？在我看来，只有当 PTR 记录描述的 IP 地址托管对 DNS 不匹配敏感的服务（例如电子邮件托管）时，这才是重要的。在这种情况下，转发区域将在域名下配置（示例遵循“区域 -> 记录”格式）：
domain.tld -> mail IN A 1.2.3.4
并且 PTR 记录将配置为匹配：
3.2.1.in-addr.arpa -> 4 IN PTR mail.domain.tld.
ISP 是否有理由像这样在其网络上托管 IP 地址的正向查找？：
ispdomain.tld -> broadband-ip-1 IN A 1.2.3.4
答案1
匹配 PTR 和 A 记录可以验证 PTR 记录中的声明通过自动化手段。
如果没有提供 A 记录，则必须转到 whois 记录来验证 PTR 记录是否准确代表控制 IP 地址的实体，这是一个繁琐的手动过程，难以自动化，并且经常是错误或过时的。
在许多情况下，出于安全原因，这一点很重要。我熟悉的一个示例是：
假设您运营一个网站并发布独特的内容，但您发现您的内容被复制到其他网站，更糟糕的是，他们在搜索引擎中的排名比您更高！
盯着日志看了好几个小时，想知道到底是怎么有人让机器人绕过你的防御的，你终于注意到了数百个来自 Googlebot 的请求。但当你最终查找其中一个 IP 地址时，你发现它注册在 Bulletproof Ukraine Web Hosting 而不是 Google。你以为你被编入了索引，但实际上你被耍了。
你如何解决这个问题？很简单，你将 PTR 记录与 A 记录进行比较。谷歌甚至推荐这种方法。
这可以在许多 Web 编程语言中自动实现（PHP 是一个显著的例外）；你不能在 PHP 中可靠地执行此操作)，这样 Web 应用就可以检查 IP 地址，查看 PTR 是否匹配*.google.com，然后使用 A 记录来确认是否*.google.com匹配相同的 IP 地址。如果某处不匹配，则说明您发现了假冒的 Googlebot。
答案2
ISP 是否有理由像这样在其网络上托管 IP 地址的正向查找？
主要是一致性和完整性。虽然您可能很难想象为什么它很重要，但编写 RFC 的理由只有一个：让互联网上的每个人都对其他人将如何与他们互动有一个一致的基本理解。如果没有这个基础，互联网就会变成一堆乱七八糟的协议，任何人都可以按照自己的意愿实现，没有任何文档、兼容性、互操作性或一致性的期望。
已知依赖这些正向和反向查找的服务不应成为获得适当 RFC 处理的特殊服务。应该假设，如果您要与我们其他人一起参与，那么您将与我们其他人在同一水平上竞争。