0

我正在编写一个应用程序来查询 DNS SRV 记录，以找出从电子邮件地址获得的域的内部服务。执行以下操作是否正确。

  • 假设电子邮件域是 test.example.com
  • 查询SRV记录_service._tcp.test.example.com
  • 没有返回 SRV 记录
  • 现在查询 SRV 记录 _service._tcp.example.com
  • 返回一条记录。因此使用此记录连接

上述方法对吗？假设不是，是否有任何 RFC 或标准阻止应用程序执行此操作？

4

1 回答 1

1

上述方法对吗？

不它不是。你不应该“爬”到根。

在 RFC 中没有明确告诉您不要这样做，您甚至会发现一些规范告诉您要爬到根，请参阅CAA规范（但它们必须在一年中更改，因为关于爬到根）。

大多数时候，这种攀登带来的问题多于解决方案，而这一切都来自于“寻找行政边界”，这看起来比实际上要简单得多。

如果我们回到你的例子，你说，使用_service._tcp.test.example.com然后_service._tcp.example.com，然后我想你留在那里，因为你“显然”知道你不应该去_service._tcp.com下一步，因为你“知道”example.com并且com不在相同的行政边界，所以你不应该越过这个限制。

好的，是的，在那个特定的例子（和 TLD）中，事情看起来很简单。但是想象一个任意的名字，让我们说www.admin.santé.gouv.fr，你怎么知道在哪里停止攀登？

总的来说，这是一个难题。尝试解决它（参见 IETF DBOUND 工作组）但失败了。如果您需要追求，您基本上只有两个场所：要么通过 DNS 调用找到委托（区域削减）（并非所有委托都是新的管理边界，但管理的改变应该意味着委托；显然，在每个点，因此您无法仅通过查看字符串来找到所有这些，您需要进行实时 DNS 查询）或使用 Mozilla Public Suffix List，这有很多缺点。

这基本上是您可以在 RFC5507 的“§4. Zone Boundaries are Invisible to Applications”中阅读的内容的重新散列，在此处引用核心部分：

错误的假设导致了一种称为“爬树”的方法，其中通过反复剥离最左边的标签（爬向根）直到到达根域。有时这些建议试图避免查询根或 TLD 级别，但这种方法仍然存在严重的缺点：

[..]

o 由于类似于 RFC 1535 [RFC1535] 中概述的原因，在目标实体控制之外的域中查询信息可能会导致错误的结果，也可能会危及安全。如果没有明确的标记，就不可能找到准确的策略边界，目前还不存在。充其量，软件可以检测区域边界（例如，通过查找 SOA 资源记录），但一些 TLD 注册机构从二级开始注册名称（例如，CO.UK），并且在二级有各种其他“注册”类型，第三，或其他级别的域，如果没有 DNS 外部的策略知识就无法识别。

确实还要注意给出的示例，MX因为您在此处应用相同的算法的幼稚观点，但正如 RFC 所说：

重申一下，区域边界纯粹是为了管理目的而存在于 DNS 中的边界，应用程序应注意不要从区域边界得出无根据的结论。另一种表述方式是 DNS 不支持继承，例如，TL​​D 的 MX RRSet 对该特定 TLD 的任何子域都无效。

有各种各样的例子表明人们试图爬到根源......并制造了很多问题：

所以，简而言之，如果对 DNS 没有扎实的了解，请不要创建任何“爬”到根目录的东西。请注意，RFC2782 aboutSRV给出了“使用规则”，没有爬到根的情况。

您没有完全解释为什么要考虑这个问题。我建议您查看最新的HTTPS/ SVCBDNS 记录（RFC 尚未发布，但 IANA 已分配 RR 类型代码点，Apple、Cloudflare 和 Google 已在使用），因为它们可能提供与SRV但可能的类似功能集与您的用例更相关。

于 2021-10-19T04:32:51.653 回答