10. Special Considerations (特殊考虑因素)

使用本规范签名的区域对其施加了额外的域名长度限制。特别是, 当转换为哈希所有者名称时, 名称超过 [RFC1035] 规定的 255 八位字节 (octets) 长度限制的区域无法使用本规范。

特定区域中域名的实际最大长度取决于区域名称的长度 (相对于整个域名) 和所使用的特定哈希函数。

例如, SHA-1 产生 160 位的哈希。160 位的 base-32 编码 (encoding) 产生 32 个字符。这 32 个字符作为单个标签添加到区域名称之前, 其中包括一个八位字节的长度字段。当使用 SHA-1 时, 区域名称的最大长度为 222 个八位字节 (255 - 33)。

[RFC2672] 的第 3 节中的 DNAME 规范具有"无后代"限制 (no-descendants limitation)。如果在节点 N 处存在 DNAME RR, 则在 N 的任何后代处绝对不能 (MUST) 有数据。

如果 N 是区域的顶点, 则在 N 的后代处将存在 NSEC3 和 RRSIG 类型。本规范更新 DNAME 规范, 以允许在顶点的后代处存在 NSEC3 和 RRSIG 类型, 而不管顶点处是否存在 DNAME。

设置所使用的迭代次数允许区域所有者选择计算哈希的成本, 从而选择生成字典 (dictionary) 的成本。请注意, 这与盐 (salt) 的效果不同, 后者防止对所有时间使用单个预计算字典。

显然, 迭代次数也会影响区域所有者签名和服务区域的成本以及验证者验证来自区域的响应的成本。因此, 我们对迭代次数施加上限。我们将此基于近似验证 RRSet 成本的迭代次数。

因此, 限制基于最小区域签名密钥 (zone signing key) 的大小, 向上舍入到最近的表值 (如果密钥大于最大表值, 则向下舍入)。

对于给定的密钥大小, 区域所有者绝对不能 (MUST NOT) 使用高于下表所示的迭代次数值。在验证者已验证 NSEC3 RR 上的签名正确后, 解析器可以 (MAY) 将具有更高值的响应视为不安全 (insecure)。

此表基于 SHA-1 计算成本与大小为 1024 位 (150 比 1), 2048 位 (500 比 1) 和 4096 位 (2500 比 1) 的密钥的 RSA 验证成本之间的比率的近似值。

SHA-1 计算与 DSA 验证之间的比率更高 (对于大小为 1024 的密钥为 1500 比 1)。更高的迭代计数会降低性能, 而对于相同的密钥大小, DSA 验证已经比 RSA 更昂贵。因此, 表中的值必须 (MUST) 独立于密钥算法使用。

在将已经签名且受信任的区域过渡到本规范时, 必须小心防止在过程中出现客户端验证失败。

基本过程如下:

将所有 DNSKEY 过渡到使用第 2 节中描述的算法别名 (algorithm aliases) 的 DNSKEY。安全且可靠地更改区域的 DNSKEY RRSet 的实际方法超出了本规范的范围。但是, 最终结果必须 (MUST) 是父级中的所有 DS RR 都使用指定的算法别名。

在此过渡完成后, 所有不支持 NSEC3 的客户端将把区域视为不安全。此时, 权威服务器仍返回包含 NSEC RR 的否定响应和通配符响应。
将已签名的 NSEC3 RR 添加到区域, 可以增量添加或一次性全部添加。如果增量添加, 则最后添加的 RRSet 必须 (MUST) 是 NSEC3PARAM RRSet。
在添加 NSEC3PARAM RRSet 后, 服务器根据本规范切换到使用 NSEC3 RR 服务否定响应和通配符响应。
增量或一次性删除 NSEC RR。

要安全地过渡回 DNSSEC [RFC4035] 签名区域, 只需反转上述过程:

10. Special Considerations (特殊考虑因素)​