围绕反向DNS的要求令人困惑！ 如果反向DNS不存在，人们经常谈论所有的事情 ，这听起来很可怕。 即使在应用程序不需要反向DNS的情况下，也经常引用RFC来支持强制性的PTRlogging创build。
其中一些RFC包括：
RFC1912 ： 常见的DNS操作和configuration错误
每个可上网的主机都应该有一个名字。 …确保您的PTR和Alogging匹配。 对于每个IP地址，在in-addr.arpa域中应该有匹配的PTRlogging。 如果一台主机是多宿主的（多个IP地址），请确保所有的IP地址都有对应的PTRlogging（不仅仅是第一个）。 如果没有匹配的PTR和Alogging，可能会导致Internet服务丢失，类似于根本不在DNS中注册。
RFC1033 ： 域pipe理员操作指南
添加一个主机。
To add a new host to your zone files: Edit the appropriate zone file for the domain the host is in. Add an entry for each address of the host. Optionally add CNAME, HINFO, WKS, and MX records. Add the reverse IN-ADDR entry for each host address in the appropriate zone files for each network the host in on.
尽pipe如此，有些人仍然坚持说，pipe理DNSpipe理的标准并不要求创buildPTRlogging。 实际要求是什么？
pipe理DNS操作的标准是否要求所有设备都有匹配的PTRlogging？ 没有。
某些协议的标准是否需要与相应的A或AAAAlogging一致的PTRlogging？ 是。
一些不受RFC控制的应用程序有相同的要求吗？ 是。
PTRlogging是否可以指向CNAME？ 是的，但CNAME目标必须是相关设备的唯一名称（而不是另一个CNAME）。 （ RFC2181§10.2 ， RFC1034§3.6.2 ）
强制PTRlogging创build是一个最佳实践吗？ 一般认为是这样，但也有它自己的问题。
这个问答提供的目的是帮助rest一个常见的误解。
RFC1796的一个悲剧性的低报价部分适用于这里：
出版作为一个RFC提供了一定程度的认可是一个令人遗憾的错误观念。 它不是，或者至less不超过正规杂志上的出版物。 事实上，每个RFC都有一个相对于它与互联网标准化过程的关系的状态：信息性，实验性或标准跟踪（build议标准，草案标准，互联网标准）或历史。
RFC1912是信息。 RFC1033没有明确的标签，并且有一个UNKNOWN的正式名称，这意味着它太旧了， 不应该被认为是任何事情的参考 。 他们没有定义标准，也不能用来正式增加标准。 他们不应该在上下文中被引用，这意味着他们正在界定一个标准。
将信息性RFCbuild议视为良好的build议和普遍接受的最佳实践。 反向DNSbuild议一目了然：遵循这些准则可以降低由于反向DNS是必要的而且没有计划的情况下应用程序无法正常工作的风险。 你当然不能指望一个DNSpipe理员知道每一个需要它的应用程序/协议，可悲的是，请求这些logging的服务所有者往往也是如此。
这就是说，除了非常好的自动化之外 ，强制性的PTRlogging创build政策也会造成污染。
PTRlogging不会与其对应的A / AAAAlogging保持同步，这导致假的PTR数据随着时间的推移蠕变。 这些数据只是误导那些试图将这些信息视为可信的人。 当一些应用程序所有者正在寻找幻影问题的原因时，他们急于跳上它。 随着IPv6的采用变得越来越普遍，这个问题只会越来越严重，特别是对负责运营商级IP空间的DNSpipe理员而言。 更糟的是：没有PTRlogging，或PTRlogging不准确？ 如果一个协议因为标准要求有效的DNS而中断，两者都不好，而后者实际上可能会更糟 。 除此之外，每个人对此事的看法都不一样。 这很好：您可以自由地将最适合您团队和公司的政策和工具放在一起。 只要确保它们能够扩展并产生一致的结果，并且记住，反向DNS只会像你的团队成员必须给予它的时间和纪律一样准确。
也不是这样。 人们经常会混淆PTRlogging（NXDOMAIN）和断开的反向DNS之间的界限。
NXDOMAIN的答复将只会导致一个问题，如果您正在与需要转发确认反向DNS（FCrDNS）的服务进行通信。 邮件服务器，Kerberos，Oracle扫描VIP等
如果您无法及时获得NXDOMAIN响应，则反向DNS破损。 许多应用程序（最着名的sshd ）会阻止反向DNS查找，如果有问题及时获取来自上游源的响应，导致应用程序内出现延迟。