Totor Asked: 2014-08-08 04:38:45 +0800 CST2014-08-08 04:38:45 +0800 CST 2014-08-08 04:38:45 +0800 CST 为什么不建议在 DNS 中使用多个 PTR 记录？ 772 我经常 读到不建议在 DNS 配置中使用多个 PTR 记录。 然而，原因往往是模糊的，或者不是那么明显，命名： “它可能会导致问题”， “可能会在需要单一答案的程序中触发错误”：那是软件的问题，不是吗？！ “可以使 DNS 应答数据包太大”：这不是用EDNS解决的吗？ 这些是很好的理由吗？你知道任何其他（好的）理由吗？这一切看起来像是一种“遗留恐惧”…… domain-name-system 3 个回答 Voted Best Answer Håkan Lindqvist 2014-08-08T09:11:32+08:002014-08-08T09:11:32+08:00 PTR反向名称（例如）的记录7.2.0.192.in-addr.arpa应识别与该 IP 地址关联的规范名称。 网络节点的网关指针和全地址节点的普通主机指针都使用 PTR RR 指向相应主机的主域名。 来自：https ://www.rfc-editor.org/rfc/rfc1035#section-3.5 这种期望反映在进行反向查找的软件中。通常，此类软件特别希望返回单个名称，并且希望能够使用该名称作为该主机的规范名称。如果返回多个名称，通常只随机取一个，因为他们绝对无法知道您在这个特定场合更喜欢哪一个。 由于一般期望是有一个与 IP 地址相关联的规范名称，并且该名称是PTR应该指向的名称，因此添加多个名称通常没有好处（没有人期望任何随机A/AAAA记录具有匹配的PTR），但它有可能缺点，因为它可能会导致奇怪的结果，因为PTR如果您添加了多个记录，您将无法控制将使用哪些记录。 从本质上讲，如果您有多个PTR记录，实际上并没有使您的主机看起来更合法，而是相反，您冒着验证失败或破坏某些东西的风险。 作为一个可能有点极端的比喻，在机场交出五本带有您的照片但姓名不同的护照可能不会像您只交出一个那样被接收。 Giovanni Tirloni 2014-08-08T05:15:40+08:002014-08-08T05:15:40+08:00 这一切都归结为不可预测的行为，因为 RFC 没有施加限制或处理这些 PTR 记录的方法。大多数实现将选择循环，您将无法获得所需的结果（多个名称与单个 IP 的完美匹配）。 您可以在此处阅读更多相关信息：https ://supernoc.rogerstelecom.net/pdfs/multiple-ptrs.pdf 此外，从 Glibc 的 getnameinfo 函数 ( https://sourceware.org/bugzilla/show_bug.cgi?id=5790 ) 检查这个错误。你怎么能保证这不会发生在互联网上无数不同的系统中（其中一些非常老旧且未打补丁）？ 作为经验法则，为了强调，避免未指定和不可预测的行为总是好的。不幸的是，单个 IP 的多个 PTR 记录属于该类别（就 RFC 而言）。 user274768 2015-03-06T18:52:14+08:002015-03-06T18:52:14+08:00 如果您有多个 PTR，您如何保证 PTR 将匹配特定的转发记录？ 这在邮件服务器交互中尤其重要，大多数入站接收 SMTP 服务器将检查正向是否与反向匹配 相当困难的是你有多个 PTR 并且无法保证选择了哪个 PTR 并且它与你在连接时给出的前锋匹配 保证完美匹配的最简单方法是拥有一个匹配前向条目的 PTR
PTR反向名称（例如）的记录7.2.0.192.in-addr.arpa应识别与该 IP 地址关联的规范名称。来自：https ://www.rfc-editor.org/rfc/rfc1035#section-3.5
这种期望反映在进行反向查找的软件中。通常，此类软件特别希望返回单个名称，并且希望能够使用该名称作为该主机的规范名称。如果返回多个名称，通常只随机取一个，因为他们绝对无法知道您在这个特定场合更喜欢哪一个。
由于一般期望是有一个与 IP 地址相关联的规范名称，并且该名称是
PTR应该指向的名称，因此添加多个名称通常没有好处（没有人期望任何随机A/AAAA记录具有匹配的PTR），但它有可能缺点，因为它可能会导致奇怪的结果，因为PTR如果您添加了多个记录，您将无法控制将使用哪些记录。从本质上讲，如果您有多个
PTR记录，实际上并没有使您的主机看起来更合法，而是相反，您冒着验证失败或破坏某些东西的风险。作为一个可能有点极端的比喻，在机场交出五本带有您的照片但姓名不同的护照可能不会像您只交出一个那样被接收。
这一切都归结为不可预测的行为，因为 RFC 没有施加限制或处理这些 PTR 记录的方法。大多数实现将选择循环，您将无法获得所需的结果（多个名称与单个 IP 的完美匹配）。
您可以在此处阅读更多相关信息：https ://supernoc.rogerstelecom.net/pdfs/multiple-ptrs.pdf
此外，从 Glibc 的 getnameinfo 函数 ( https://sourceware.org/bugzilla/show_bug.cgi?id=5790 ) 检查这个错误。你怎么能保证这不会发生在互联网上无数不同的系统中（其中一些非常老旧且未打补丁）？
作为经验法则，为了强调，避免未指定和不可预测的行为总是好的。不幸的是，单个 IP 的多个 PTR 记录属于该类别（就 RFC 而言）。
如果您有多个 PTR，您如何保证 PTR 将匹配特定的转发记录？
这在邮件服务器交互中尤其重要，大多数入站接收 SMTP 服务器将检查正向是否与反向匹配
相当困难的是你有多个 PTR 并且无法保证选择了哪个 PTR 并且它与你在连接时给出的前锋匹配
保证完美匹配的最简单方法是拥有一个匹配前向条目的 PTR