使用父域查询子域的 DNS SRV
Using parent domain to query DNS SRV for sub domain
我正在编写一个应用程序来查询 DNS SRV 记录，以找出从电子邮件地址获得的域的内部服务。以下做法是否正确。
- 假设电子邮件域是 test.example.com
- 查询SRV记录_service._tcp.test.example.com
- 没有返回任何 SRV 记录
- 现在查询SRV记录_service._tcp.example.com
- 返回一条记录。因此使用这条记录连接
上面的做法对吗？假设不是，是否有任何 RFC 或标准阻止应用程序这样做？
Is the above approach right?
不，不是。你不应该“爬”到根。
在 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 后缀列表，它有很多缺点。
这基本上是对您在 RFC5507 的“§4. 区域边界对应用程序不可见”中阅读的内容的翻版，在这里引用核心部分：
The false assumption has lead to an approach called "tree climbing",
where a query that does not receive a positive response (either the
requested RRSet was missing or the name did not exist) is retried by
repeatedly stripping off the leftmost label (climbing towards the
root) until the root domain is reached. Sometimes these proposals
try to avoid the query for the root or the TLD level, but still this
approach has severe drawbacks:
[..]
o For reasons similar to those outlined in RFC 1535 [RFC1535],
querying for information in a domain outside the control of the
intended entity may lead to incorrect results and may also put
security at risk. Finding the exact policy boundary is impossible
without an explicit marker, which does not exist at present. At
best, software can detect zone boundaries (e.g., by looking for
SOA Resource Records), but some TLD registries register names
starting at the second level (e.g., CO.UK), and there are various
other "registry" types at second, third, or other level domains
that cannot be identified as such without policy knowledge
external to the DNS.
确实还要注意为 MX 给出的示例，因为天真地认为您在那里应用了相同的算法，但正如 RFC 所说：
To restate, the zone boundary is purely a boundary that exists in the
DNS for administrative purposes, and applications should be careful
not to draw unwarranted conclusions from zone boundaries. A
different way of stating this is that the DNS does not support
inheritance, e.g., an MX RRSet for a TLD will not be valid for any
subdomain of that particular TLD.
有很多人试图爬到根部...并制造很多问题的例子：
- 过去，微软和
wpad.dat：https://news.softpedia.com/news/wpad-protocol-bug-puts-windows-users-at-risk-504443.shtml
- 最近，Microsoft 再次关于电子邮件自动发现：https://www.zdnet.com/article/design-flaw-in-microsoft-autodiscover-abused-to-leak-windows-domain-credentials/
所以，简而言之，如果对 DNS 没有深入的了解，请不要创建任何“爬”到根目录的东西。请注意，关于 SRV 的 RFC2782 给出了“使用规则”，没有爬到根的情况。
您没有完全解释为什么要考虑这个问题。我建议您查看最新的 HTTPS/SVCB DNS 记录（RFC 尚未发布，但 IANA 已经分配了 RR 类型代码点，并且已被 Apple、Cloudflare 和 Google 使用已经），因为它们可能提供与 SRV 类似的功能，但可能与您的用例更相关。
我正在编写一个应用程序来查询 DNS SRV 记录，以找出从电子邮件地址获得的域的内部服务。以下做法是否正确。
- 假设电子邮件域是 test.example.com
- 查询SRV记录_service._tcp.test.example.com
- 没有返回任何 SRV 记录
- 现在查询SRV记录_service._tcp.example.com
- 返回一条记录。因此使用这条记录连接
上面的做法对吗？假设不是，是否有任何 RFC 或标准阻止应用程序这样做？
Is the above approach right?
不，不是。你不应该“爬”到根。
在 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 后缀列表，它有很多缺点。
这基本上是对您在 RFC5507 的“§4. 区域边界对应用程序不可见”中阅读的内容的翻版，在这里引用核心部分：
The false assumption has lead to an approach called "tree climbing", where a query that does not receive a positive response (either the requested RRSet was missing or the name did not exist) is retried by repeatedly stripping off the leftmost label (climbing towards the root) until the root domain is reached. Sometimes these proposals try to avoid the query for the root or the TLD level, but still this approach has severe drawbacks:
[..]
o For reasons similar to those outlined in RFC 1535 [RFC1535], querying for information in a domain outside the control of the intended entity may lead to incorrect results and may also put security at risk. Finding the exact policy boundary is impossible without an explicit marker, which does not exist at present. At best, software can detect zone boundaries (e.g., by looking for SOA Resource Records), but some TLD registries register names starting at the second level (e.g., CO.UK), and there are various other "registry" types at second, third, or other level domains that cannot be identified as such without policy knowledge external to the DNS.
确实还要注意为 MX 给出的示例，因为天真地认为您在那里应用了相同的算法，但正如 RFC 所说：
To restate, the zone boundary is purely a boundary that exists in the DNS for administrative purposes, and applications should be careful not to draw unwarranted conclusions from zone boundaries. A different way of stating this is that the DNS does not support inheritance, e.g., an MX RRSet for a TLD will not be valid for any subdomain of that particular TLD.
有很多人试图爬到根部...并制造很多问题的例子：
- 过去，微软和
wpad.dat：https://news.softpedia.com/news/wpad-protocol-bug-puts-windows-users-at-risk-504443.shtml - 最近，Microsoft 再次关于电子邮件自动发现：https://www.zdnet.com/article/design-flaw-in-microsoft-autodiscover-abused-to-leak-windows-domain-credentials/
所以，简而言之，如果对 DNS 没有深入的了解，请不要创建任何“爬”到根目录的东西。请注意，关于 SRV 的 RFC2782 给出了“使用规则”，没有爬到根的情况。
您没有完全解释为什么要考虑这个问题。我建议您查看最新的 HTTPS/SVCB DNS 记录（RFC 尚未发布，但 IANA 已经分配了 RR 类型代码点，并且已被 Apple、Cloudflare 和 Google 使用已经），因为它们可能提供与 SRV 类似的功能，但可能与您的用例更相关。