主页 / server / 问题 / 1089071
Accepted
vinz
Asked: 2022-01-06 08:22:42 +0800 CST

bailiwick 规则澄清 AUTHORITY 和 ADDITIONAL 部分

  • 772

这是我不明白的辖区规则示例：

adobe.net从net.TLD 服务器解析给出：

;; AUTHORITY SECTION:
adobe.net.  172800  IN  NS  ns1.omtrdc.net.
adobe.net.  172800  IN  NS  ns2.omtrdc.net.

;; ADDITIONAL SECTION:
ns1.omtrdc.net. 172800  IN  A   66.235.157.6
ns2.omtrdc.net. 172800  IN  A   66.235.157.7

并解决ns1.omtrdc.net.给出：

;; AUTHORITY SECTION:
omtrdc.net. 172800  IN  NS  ns201.adobe.net.
omtrdc.net. 172800  IN  NS  ns202.adobe.net.

;; ADDITIONAL SECTION:
ns201.adobe.net.    172800  IN  A   204.74.108.252
ns202.adobe.net.    172800  IN  A   204.74.109.252

如果在这两种情况下都不信任附加部分，则会导致循环。

据我了解，有两条规则：

  • 如果 ADDITIONAL 与 AUTHORITY 部分的 NS 记录不匹配，则不应信任它们，以避免名称服务器发送明显的妥协记录。
  • AUTHORITY 部分 NS 应该是请求域的子集。ns1.omtrdc.net.不是 的子集adobe.net.，因此无法信任附加部分中的 IP。

但是，我已经看到了一些值得信任的实现，因为它们是（回复的 TLD 服务器）ns1.omtrdc.net.的子集。.net

如果我理解得很好（在阅读了一些论文和实现之后），由于 TLD 服务器管理net.区域，我们可以相信 . 下的任何内容net.，即它的 IPns1.omtrdc.net.是adobe.net.

这有意义还是我忘记了一些重要的部分？

domain-name-system

1 个回答

  1. Best Answer

    我不确定是否真的看到你的问题。

    ADDITIONAL被定义为可选（因此客户端可以自由地忽略该数据，出于安全原因，它确实应该在大多数情况下忽略它）......除非没有其他方法可以实现某些东西，这是胶水。但问题是 DNSSEC 没有涵盖额外的胶水，因此没有经过身份验证，因此必须小心处理。

    请注意，您adobe.net使用名称服务器的情况omtrdc.net不是“in-bailiwick”的定义。如果名称服务器名称也在adobe.net. 因此，您的情况就是所谓的“内部名称服务器”，因为名称服务器名称与它们具有权威性的域名位于同一注册表的内部。

    [ 老实说，个人注意事项：我觉得域 A 的这种设置使用域 B 下的名称服务器，其名称服务器回到域 A 下是非常危险的。A或B中的任何错误都可能禁用 A和B 的解析；这是某种循环，应避免 DNS 中的循环（或小心处理并采取适当的缓解措施和保护措施）]。

    您可以在 RFC 8499 中找到很多关于 DNS 术语的出色定义。

    它有这个例如：

    Bailiwick：“In-bailiwick”是描述名称服务器的修饰符，其名称是包含对名称服务器的委托的区域的子域或（很少）与该区域的来源相同。

    至于

    这有意义还是我忘记了一些重要的部分？通过显示 dig 或类似的 DNS 输出，您做得很好，但缺少/模糊的是您查询数据的名称服务器，您应该展示并研究它以获得清晰的画面。在 DNS 中的大多数误解情况下，我认为它来自于权威和递归名称服务器之间的混淆。

    ADDITIONAL部分的定义与 RFC 1034 中的定义类似：

    Additional
    Carries RR 可能有助于使用其他部分中的 RR。

    然后它完全出现在描述解析算法的第 4.3.2 节中：

    将子区域的 NS RR 复制到回复的权限部分。将任何可用的地址放入附加部分，如果这些地址不能从权威数据或缓存中获得，则使用胶水 RR。转到第 4 步。

    回到 RFC 8499 你会得到进一步的解释：

    只有引用的响应包含一个空的答案部分。它包含权威部分中引用区域的 NS RRset。它可能包含在附加部分中提供地址的 RR。AA 位清零。

    和

    在查询匹配别名的情况下，并且服务器对别名的目标不具有权威性，但对别名目标之上的某个名称具有权威性，解析算法将产生一个响应，其中包含别名和转介。这样的部分回答和推荐响应在“回答”部分中有数据。它在权威部分具有引用区域的 NS RRset。它可能包含在附加部分中提供地址的 RR。

    至于：

    但是，我已经看到了一些实现

    是的，内容ADDITIONAL可能会根据您查询的名称服务器及其配置方式而有所不同。例如，参见minimal-responsesBind 选项，记录在https://bind9.readthedocs.io/en/latest/reference.html中，说明：“此选项控制向权限和响应的附加部分添加记录。此类记录可能是包含在响应中以对客户有帮助；例如，NS 或 MX 记录可能具有包含在附加部分中的关联地址记录，从而无需单独的地址查找。但是，将这些记录添加到响应中不是强制性的，并且需要额外的数据库查找，在编组响应时导致额外的延迟。” 它有 4 个可能的值，因此在线上有很多不同的行为。

    最后是：

    因为 TLD 服务器管理网络。区，我们可以相信网下的任何事情。

    是的，没有:-)。以过去的 Verisign SiteFinder“实验”为例：您查询任何 com 权威名称服务器以获取任何不存在的名称，然后您得到了一条A记录。你信不信？

    • 1

相关问题