我知道顶点记录(区域“根”处的记录)可以有 PTR 记录,但我经常看到区域根记录没有匹配的 PTR,或者它们指向与关联主机记录不同的位置。
例子:
dig umich.edu @8.8.8.8; dig -x 141.211.243.251
(truncated for brevity)
;; ANSWER SECTION:
umich.edu. 709 IN A 141.211.243.251
(truncated for brevity)
;; ANSWER SECTION:
251.243.211.141.in-addr.arpa. 1800 IN PTR www.umich.edu.
(truncated for brevity)
没有 PTR 的原因:
- 不放入 PTR 的一个原因是,如果您对地址区域没有权威性。例如,我正在将 A 记录指向云提供商,并且我无法使用 CNAME,因为它是区域根。
- 我能理解的另一个原因是,如果您使用任播作为 DNS 服务,则可能无法在不同地点获得相同的答案(地理位置)。Google.com 似乎就是这样做的。
但是,除了上述例外情况外,还有什么理由“永远”或“总是”这样做呢?我认为默认情况下应该始终有一个正确的 PTR。
答案1
我明白迈克尔的观点,因为我认为他指的是命名空间中用于处理反向映射的域:in-addr.arpa
和ip6.arpa
。话虽如此,我明白你的意思。
域的反向 DNS (rDNS) 查找不必与正向查找匹配。我在共享主机上有一个域。我从我的域名和的正向查找中获得了相同的 IP 地址www
。此 IP 地址的 RDNS 查找返回共享服务器:
23.168.192.in-addr.arpa. 14400 IN PTR foo.bar.example.com.
既然你正在寻找最佳实践,那就看看IETF 的草稿 使用 DNS 反向映射的注意事项。值得一读整篇文档。这里有一个特别重要的点:
应用程序不应依赖反向映射来正常运行,尽管依赖反向映射的功能
在没有反向映射的情况下显然无法工作。需要提醒运营商和用户,使用反向树(有时与查找 PTR 记录产生的名称
结合使用)并不能提供真正的安全性,可能会 导致错误的结果,并且通常只会增加 DNS 服务器的负载。此外,如果地址块持有者未能 正确配置反向映射,这些地址块的用户将受到 惩罚。
和这个:
通过建议应用程序避免使用反向映射作为
安全机制,本文档指出,
尽管许多应用程序都使用这种做法,但它是一种无效的
安全形式。应用程序应该使用更好的身份验证机制
。
我希望这有帮助。