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

Question

围绕反向 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 记录。实际要求是什么？

Answer 1

简答

管理 DNS 操作的标准是否要求所有设备都具有匹配的 PTR 记录？不。

做一定的协议标准要求PTR，与相应的同意记录A或AAAA记录？是的。

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

PTR 记录可以指向 CNAME 吗？是的，但 CNAME 目标必须是相关设备的唯一名称（而不是另一个 CNAME）。( RFC 2181§10.2 , RFC1034 §3.6.2 )

强制 PTR 记录创建是最佳实践吗？普遍认为如此，但它有其自身的问题。

长答案

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

的可悲underquoted节RFC1796适用于这里：

令人遗憾的是，作为 RFC 发布提供了某种程度的认可，这是一种广泛传播的误解。它不会，或者至少不会超过在常规期刊上发表的文章。事实上，每个 RFC 都有一个状态，相对于它与互联网标准化过程的关系：信息、实验或标准跟踪（提议标准、草案标准、互联网标准）或历史。

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 查找，从而导致应用程序内的延迟。