☰

管辖区规则关于权限和附加部分的澄清

tag-icon • tag-icon domain-name-system
管辖区规则关于权限和附加部分的澄清

以下是我不理解的管辖范围规则的一个例子：

adobe.net从TLD 服务器解析net.可获得：

;; 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 部分，就会导致循环。

据我了解，有两条规则：

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

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

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

这有意义吗或者我忘记了一些重要的部分？

答案1

我不太确定我是否真正明白你的问题。

ADDITIONAL被定义为可选的（因此客户端可以自由地忽略该数据，出于安全原因，它确实应该在大多数情况下忽略它）……除非没有其他方法可以实现某些功能，即胶水。但问题是，ADDITIONAL 又名胶水不受 DNSSEC 保护，因此未经身份验证，因此必须小心处理。

adobe.net请注意，您使用 下的名称服务器的情况omtrdc.net不是“辖区内”的定义。如果名称服务器名称也在 下，那么它就是辖区内adobe.net。因此，您的情况就是所谓的“内部名称服务器”，因为名称服务器名称与它们所授权的域名位于同一注册中心的内部。

[ 个人补充：说实话，我觉得域 A 使用域 B 下的域名服务器（而域 B 下的域名服务器又在域 A 下）的这种设置非常危险。A 中的任何错误或者B 可能使 A 无法解析和B；这是一种循环，应该避免 DNS 中的循环（或小心处理并采取适当的缓解和保护措施）]。

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

例如：

辖区：“辖区内”是一个修饰符，用于描述一个名称服务器，该名称服务器的名称是包含对名称服务器的委托的区域的子域或（很少）与该区域的原点相同。

至于

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

ADDITIONAL部分定义类似于 RFC 1034：

附加
携带 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记录。您相信吗？

相关内容