跳到主要内容

3. Background to DNS64-DNSSEC Interaction (DNS64-DNSSEC 交互背景)

3. Background to DNS64-DNSSEC Interaction (DNS64-DNSSEC 交互背景)​

DNSSEC ([RFC4033], [RFC4034], [RFC4035]) 对 DNS64 提出了特殊的挑战, 因为 DNSSEC 旨在检测对 DNS 响应的更改, 而 DNS64 可能会更改来自权威服务器的响应.

递归解析器可以是安全感知的 (security-aware) 或安全无关的 (security-oblivious).此外, 根据运营商策略, 安全感知的递归解析器可以是验证的 (validating) 或非验证的 (non-validating).在以下情况中, 递归解析器也执行 DNS64, 并且有本地策略要验证.我们将这种一般情况称为 vDNS64, 但在以下所有情况中, 应假定需要 DNS64 功能.

DNSSEC 包括一些信令位, 这些信令位提供了关于查询发起方理解什么的一些指示.

如果查询到达 vDNS64 设备时设置了 "DNSSEC OK" (DO) 位, 则查询发起方发出信号表示它理解 DNSSEC.DO 位不表示查询发起方将验证响应.它仅意味着查询发起方可以理解包含 DNSSEC 数据的响应.相反, 如果 DO 位被清除, 则表明查询代理不知道 DNSSEC.

如果查询到达 vDNS64 设备时设置了 "Checking Disabled" (CD) 位, 这表明查询代理希望获得所有验证数据, 以便它可以自己进行检查.根据本地策略, vDNS64 仍然可以验证, 但无论如何它必须将所有数据返回给查询代理.

以下是可能的情况:

  1. DNS64 (DNSSEC 感知或 DNSSEC 无关) 接收到 DO 位被清除的查询.在这种情况下, DNSSEC 不是问题, 因为查询代理不理解 DNSSEC 响应.如果其本地策略要求, DNS64 可以对响应进行验证.

  2. 安全无关的 DNS64 接收到 DO 位被设置的查询, 并且 CD 位被清除或设置.这就像非 DNS64 情况一样: 服务器不支持它, 所以查询代理运气不佳.

  3. 安全感知且非验证的 DNS64 接收到 DO 位被设置且 CD 位被清除的查询.这样的解析器不验证响应, 可能是由于本地策略 (参见 [RFC4035], 第 4.2 节).因此, 这种情况等同于前一种情况, 不会进行验证.

  4. 安全感知且非验证的 DNS64 接收到 DO 位被设置且 CD 位被设置的查询.在这种情况下, DNS64 应该将它获得的所有数据传递给查询发起方 (参见 [RFC4035] 第 3.2.2 节).除非验证解析器准备自己执行 DNS64, 否则这种情况不适用于 DNS64.如果 DNS64 修改记录, 客户端将获取数据并尝试验证它, 就客户端而言, 数据将是无效的.

  5. 安全感知且验证的 DNS64 解析器接收到 DO 位被清除且 CD 位被清除的查询.在这种情况下, 解析器验证数据.如果失败, 它返回 RCODE 2 (Server failure); 否则, 它返回答案.这是 vDNS64 的理想情况.解析器验证数据, 然后合成新记录并将其传递给客户端.假定不验证的客户端 (否则它应该设置 DO 和 CD) 无法知道涉及 DNS64.

  6. 安全感知且验证的 DNS64 解析器接收到 DO 位被设置且 CD 位被清除的查询.这类似于前一种情况, 除了解析器还应该在响应上设置 "Authentic Data" (AD) 位.

  7. 安全感知且验证的 DNS64 解析器接收到 DO 位被设置且 CD 位被设置的查询.这实际上与安全感知且非验证的递归解析器接收到类似查询的情况相同, 并且会发生同样的事情: 如果 DNS64 执行了合成, 下游验证器将把数据标记为无效.节点需要自己执行 DNS64, 否则通信将失败.

最后于 更新