☰

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

tag-icon • tag-icon domain-name-system reverse-dns fcrdns
互联网标准是否要求每个设备都进行反向 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.

尽管如此，有些人仍然坚持认为 PTR 记录的创建不是DNS 管理标准对此有明确要求。具体要求是什么？

答案1

简短答案

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

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

一些不受 RFC 管辖的应用程序是否有相同的要求？是的。

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

强制创建 PTR 记录是最佳做法吗？人们普遍认为是的，但它也有自己的问题。

长答案

提供此问答的目的是帮助消除一个常见的误解。

一段被引用次数极少的悲剧性文字RFC1796适用于此：

遗憾的是，人们普遍误以为，以 RFC 形式发布会获得一定程度的认可。事实并非如此，或者至少不会比在普通期刊上发布更多。事实上，每个 RFC 都有其状态，与其与互联网标准化过程的关系有关：信息性、实验性、标准轨道（拟议标准、草案标准、互联网标准）或历史性。

RFC1912 是信息性的。RFC1033 没有明确标记，并且有官方名称未知，这意味着它太老了它不应该被视为任何事物的参考。它们并不定义标准，也不能用来正式增强标准。绝不应该在暗示他们正在定义标准的上下文中引用他们的话。

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

话虽如此，非常好的自动化另外，强制性的 PTR 记录创建政策也会造成污染。

  • 在设备退役时，记录与相应的/记录PTR不同步的情况极为常见，从而导致随着时间的推移伪造数据不断增加。这些数据只会误导那些试图将这些信息视为可信的人。一些应用程序所有者在寻找幻影问题的原因时急于抓住它。随着 IPv6 的采用越来越普遍，这个问题只会继续恶化，特别是对于负责运营商规模 IP 空间的 DNS 管理员而言。AAAAAPTR
  • 为同一个 IP 地址设置多个 PTR 记录是毫无用处的，遵守信息 RFC 的建议将不可避免地导致这种情况。请参阅：为什么不建议 DNS 中有多个 PTR 记录？

更糟糕的是：没有 PTR 记录，还是 PTR 记录不准确？如果协议因为其标准需要有效的 DNS 而中断，那么两者都不好，而且后者实际上可能是更差除此之外，每个人对此事都有不同的看法。这很好：您可以自由地制定最适合您的团队和公司的政策和工具。只需确保它们可扩展并产生一致的结果，并记住反向 DNS 的准确性取决于您的团队成员必须给予它的时间和纪律。

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

这也不正确。人们经常混淆 PTR 记录 (NXDOMAIN) 的缺失和破碎的反向 DNS。

NXDOMAIN仅当您与需要正向确认反向 DNS (FCrDNS) 的服务进行通信时，回复才会导致问题。邮件服务器、Kerberos、Oracle 扫描 VIP 等。

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

相关内容