我有几个设备，每个都有自己的IP地址。 有不同的名字指向这些地址（在几个不同的领域）。 作为一个例子与设备
10.0.0.1被称为dev1.example.com和abc.example.net 192.168.1.1被称为dev2.example.com和xyz.example.net 在example.com和example.net （ Alogging）各自的DNS权威。
我想了解是否有将IP地址指向（ PTR ）单个名称（如contact-john-doe.example.org ）的DNS含义。
其基本原理是确保在其日志，监控等中查看其中一个IP地址的人员将contact-john-doe.example.org作为已parsing的名称。 这个解决的名字可能会或可能不会指向一个真实的IP address / CNAME ，由于IP地址背后的服务的性质（这些是扫描器并且它们不为最终用户提供任何服务），这应该没有关系。
虽然从1996年的信息（非标准） RFC 1912表明：
确保您的PTR和Alogging匹配。 对于每个IP地址，在in-addr.arpa域中应该有匹配的PTRlogging。 如果一台主机是多宿主的（多个IP地址），请确保所有的IP地址都有对应的PTRlogging（不仅仅是第一个）。 如果没有匹配的PTR和Alogging，可能会导致Internet服务丢失，类似于根本不在DNS中注册。
尽pipe这不是PTRlogging与Alogging匹配的要求。 您将从PTR不匹配中看到的最常见问题是邮件传送。 也就是说，我会确保你至less把logging指向你实际拥有和控制的域名。
由定义RFC的标准强加的准则是， PTRlogging应该指向关联IP的规范主机名，并且不指向别名。 这很重要，因为您的问题似乎表明您在某些情况下正在考虑在CNAME中使用一个点，而在其中许多模式中使用的是虚假值。
RFC1034§3.5 （荣誉@HåkanLindqvist，让我一如既往的诚实）
地址节点用于在正常域空间中保存指向主要主机名的指针。
RFC1034§3.6.2 ：
RR中指向其他名称的域名应始终指向主名称而不是别名。 这样可以避免在访问信息时发生额外的干扰。
这两个RFC都是在明确的定义之前编写的，不应该存在（ RFC2119 ）。 这是不幸的，因为DNS是互联网的粘合剂，原始标准中的许多build议都会被忽略，直到被附加的RFC进一步加强。 这就是说，这里的意图是相当明显的。 在使用合适的loggingtypes时，将DNS用作通用层次数据库是一回事，完全忽略这些build议是另一回事。
如果你继续下去，你会破坏一切吗？ 可能不会，但它仍然不是一个非常好的方法，特别是如果你打算这样做不映射回对用户或软件有用的值。 （使DNS recursors做更多的工作，没有附加价值）