RFC 1912第2.1节陈述如下：
确保您的PTR和Alogging匹配。 对于每个IP地址，在in-addr.arpa域中应该有匹配的PTRlogging。 如果一台主机是多宿主的（多个IP地址），请确保所有的IP地址都有对应的PTRlogging（不仅仅是第一个）。 如果没有匹配的PTR和Alogging，可能会导致Internet服务丢失，类似于根本不在DNS中注册。 此外，PTRlogging必须指向有效的Alogging，而不是由CNAME定义的别名。 强烈build议您使用一些可自动执行此检查的软件，或者使用自动创build一致数据的数据库生成DNS数据。
这对我来说没有任何意义，ISP是否应该为每个PTRlogging保留Alogging？ 在我看来，只有PTRlogging描述的IP地址托pipe对DNS不敏感的服务（例如电子邮件托pipe）才是重要的。 在这种情况下，前向区域将在域名下configuration（示例遵循格式“区域 – >logging”）：
domain.tld -> mail IN A 1.2.3.4
PTRlogging将被configuration为匹配：
3.2.1.in-addr.arpa -> 4 IN PTR mail.domain.tld.
那么ISP是否有任何理由在这样的networking上主持IP地址的正向查找呢？
ispdomain.tld -> broadband-ip-1 IN A 1.2.3.4
networking服务提供商是否有任何理由为其networking上的IP地址进行正向查找？
一致性和完整性，主要。 虽然您可能很难想象为什么它很重要，但RFC却是为了一个很好的理由而编写的：因此，互联网上的每个人都对其他人如何与他们交互有一个基本的了解。 如果没有这个基础，互联网将会是一堆乱七八糟的协议，不pipe人们愿意如何实现，没有任何文档，兼容性，互操作性或一致性的期望。
已知依赖这些正向和反向查找的服务不应该是获得正确RFC处理的特殊服务。 应该假设，如果你要和我们其他人一起参加，那么你将和我们其他人一样在比赛场上打球。
通过匹配PTR和Alogging，可以通过自动方式validationPTRlogging中的索赔。
如果未提供Alogging，则必须访问whoislogging以validationPTRlogging是否准确地代表了控制IP地址的实体，这是一个繁琐的手动过程，很难自动化，往往是错误的或过时的。
在许多情况下，这对于安全原因是重要的。 我熟悉的一个例子是：
假设你运行一个网站并发布独特的内容，但是你发现你的内容正在复制到其他网站上，更糟糕的是，它们在search引擎中的排名比你高。
经过几个小时的盯着你的日志，想知道如何在世界上有人滑过一个僵尸过去，你终于注意到来自Googlebot的数百个请求。 但是当你最终查找一个IP地址时，你会发现它已经注册到了Bulletproof Ukraine Web Hosting而不是Google。 你以为你得到了索引，但是你却玩过了。
你怎么解决这个问题？ 很简单，您将PTRlogging与Alogging进行比较。 谷歌甚至推荐这种方法 。
这可以在许多Web编程语言中自动化（PHP是一个明显的例外; 您不能在PHP中可靠地执行此操作 ），以便Web应用程序可以检查IP地址，请参阅PTR是*.google.com ，然后使用Alogging以确认*.google.com匹配相同的IP地址。 如果某处存在不匹配的情况，则会发现一个假的Googlebot。