互联网标准是否要求每个设备都使用反向DNS？

围绕反向DNS的要求令人困惑！人们经常谈论如果不存在反向DNS就会破坏一切，这听起来很可怕。即使在应用程序不需要反向DNS的情况下，也经常引用RFC以支持强制性PTR记录创建。

其中一些RFC包括：

RFC1912：常见的DNS操作和配置错误

每个可访问Internet的主机都应有一个名称。...确保您的PTR和A记录匹配。对于每个IP地址，in-addr.arpa域中都应该有一个匹配的PTR记录。如果主机是多宿主的（多个IP地址），请确保所有IP地址都有对应的PTR记录（而不仅仅是第一个）。缺少匹配的PTR和A记录会导致Internet服务丢失，就像根本没有在DNS中注册一样。

RFC1033：域管理员操作指南

添加主机。

 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.

尽管如此，仍然有人坚持说，管理DNS管理的标准并不需要创建PTR记录。实际要求是什么？

简短答案

规范DNS操作的标准是否要求所有设备都具有匹配的PTR记录？没有。

某些协议的标准是否要求PTR与相应记录A或AAAA记录一致的记录？是。

某些不受RFC约束的应用程序是否具有相同的要求？是。

PTR记录可以指向CNAME吗？是的，但是CNAME目标必须是所讨论设备的唯一名称（而不是另一个CNAME）。（RFC2181§10.2，RFC1034§3.6.2）

强制性PTR记录创建是最佳实践吗？通常认为是这样，但是它有其自身的问题。

长答案

本问答旨在帮助消除常见的误解。

RFC1796中用引号引起了悲剧的部分在这里适用：

令人遗憾的是，人们普遍误解为将RFC作为出版物提供一定程度的认可。它不（或至少不超过）常规期刊中的出版物。实际上，每个RFC都具有相对于其与Internet标准化过程的关系的状态：信息，实验或标准轨道（拟议标准，标准草案，Internet标准）或历史状态。

RFC1912是信息性的。RFC1033的标签不明确，并具有UNKNOWN的正式名称，这意味着它太旧了，不应视为任何内容的参考。它们没有定义标准，也不能用于正式增强标准。绝不要在暗示它们正在定义标准的上下文中引用它们。

将信息性RFC建议视为良好建议和公认的最佳实践。反向DNS建议一目了然：遵循这些准则可降低因反向DNS是必需且未计划的而导致应用程序无法正常工作的风险。您当然不能期望DNS管理员知道需要它的每个应用程序/协议，但是遗憾的是，服务所有者要求这些记录也是如此。

也就是说，除了非常好的自动化之外，强制性的PTR记录创建策略还会造成污染。

• 设备停止使用时，记录PTR与相应的A/ AAAA记录不同步是非常普遍的情况，这会导致伪PTR数据随时间推移而蠕变。这些数据只会误导那些试图将该信息视为可信的人。一些应用程序所有者在寻找幻像问题的原因时渴望跳上它。随着采用IPv6变得越来越普遍，这个问题只会继续恶化，尤其是对于负责运营商规模IP空间的DNS管理员而言。
• 对于同一个IP地址拥有多个PTR记录几乎是没有用的，而遵循信息RFC的建议将不可避免地导致这种情况。请参阅：为什么不建议在DNS中使用多个PTR记录？

更糟糕的是：缺少PTR记录，或者PTR记录不正确？如果协议由于其标准要求有效的DNS而中断，那么两者都不好，后者实际上可能更糟。除此之外，每个人对此事都有不同的看法。很好：您可以自由组合最适合您的团队和公司的策略和工具。只需确保它们能够扩展并产生一致的结果，并记住反向DNS仅与团队成员必须付出的时间和纪律一样准确。

但是缺少PTR记录会导致sshd挂起！

也不是真的。人们通常会混淆缺少PTR记录（NXDOMAIN）与反向DNS 中断之间的界限。

NXDOMAIN仅当您与需要前向确认的反向DNS（FCrDNS）的服务通信时，回复才会引起问题。邮件服务器，Kerberos，Oracle扫描VIP等

反向DNS断开是指您无法NXDOMAIN及时获得响应的情况。sshd如果在及时获取上游来源的响应时出现问题，许多应用程序（最著名的）将阻止反向DNS查找，从而导致应用程序延迟。