围绕反向 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)。(RFC 2181§10.2,RFC1034 §3.6.2)
强制 PTR 记录创建是最佳实践吗?普遍认为是这样,但它也有其自身的问题。
长答案
本问答旨在帮助消除常见的误解。
RFC1796 的一个可悲的被低估的部分在这里适用:
RFC1912 是信息性的。RFC1033 没有明确标记,官方指定为UNKNOWN,这意味着它太老了,不应该被视为任何东西的参考。它们不定义标准,也不能用于正式扩充标准。绝不应在暗示它们正在定义标准的上下文中引用它们。
将信息 RFC 建议视为很好的建议和普遍接受的最佳实践。反向 DNS 建议一目了然:遵循这些准则可降低您因反向 DNS 是必要的且未计划而导致应用程序无法运行的风险。您当然不能指望 DNS 管理员知道需要它的每个应用程序/协议,遗憾的是,请求这些记录的服务所有者往往也是如此。
也就是说,除了非常好的自动化之外,强制性 PTR 记录创建政策也会造成污染。
PTR
当设备退役时,记录无法与其对应的A
/记录保持同步是非常普遍的,这会AAAA
导致虚假PTR
数据随着时间的推移而蔓延。这些数据只会误导那些试图将该信息视为可信的人。一些应用程序所有者在寻找幻象问题的原因时急于跳上它。随着 IPv6 的采用变得越来越普遍,这个问题只会继续恶化,特别是对于负责运营商规模 IP 空间的 DNS 管理员而言。更糟糕的是:没有 PTR 记录,或者 PTR 记录不准确?如果一个协议因为它的标准需要有效的 DNS 而中断,那么两者都是坏的,而后者实际上可能更糟。除此之外,每个人对此事都有不同的看法。没关系:您可以自由地将最适合您的团队和公司的政策和工具放在一起。只需确保它们可扩展并产生一致的结果,并记住反向 DNS 的准确性取决于您的团队成员必须给予的时间和纪律。
但是缺少 PTR 记录会导致 sshd 挂起!
也不是真的。人们经常混淆缺少 PTR 记录 (NXDOMAIN) 和损坏的反向 DNS 之间的界限。
仅当您与需要前向确认反向 DNS (FCrDNS) 的服务通信时,回复
NXDOMAIN
才会导致问题。邮件服务器、Kerberos、Oracle 扫描 VIP 等。损坏的反向 DNS 是指您无法及时获得
NXDOMAIN
响应。sshd
如果无法及时从上游源获取响应,许多应用程序(最著名的)将阻止反向 DNS 查找,从而导致应用程序延迟。