跳到主要内容

7. Authoritative Server Considerations (权威服务器注意事项)

7. Authoritative Server Considerations (权威服务器注意事项)​

7.1. Zone Signing (区域签名)​

使用 NSEC3 的区域必须满足以下属性:

  • 区域内拥有权威 RRSet 的每个所有者名称必须 (MUST) 有相应的 NSEC3 RR。对应于未签名委派的所有者名称可以 (MAY) 有相应的 NSEC3 RR。但是, 如果没有相应的 NSEC3 RR, 则必须 (MUST) 有一个 Opt-Out NSEC3 RR 覆盖到该委派的"下一个更近名称"。其他非权威 RR 不由 NSEC3 RR 表示。

  • 每个空非终结符 (empty non-terminal) 必须 (MUST) 有相应的 NSEC3 RR, 除非该空非终结符仅由 Opt-Out NSEC3 RR 覆盖的不安全委派派生。

  • 任何 NSEC3 RR 的 TTL 值应该 (SHOULD) 与区域 SOA RR 中的最小 TTL 值字段相同。

  • 已签名区域中每个 NSEC3 RR 的类型位图 (Type Bit Maps) 字段必须 (MUST) 指示原始所有者名称处存在的所有类型, 除了仅由 NSEC3 RR 本身贡献的类型。请注意, 这意味着 NSEC3 类型本身永远不会出现在类型位图中。

以下步骤描述了正确构造 NSEC3 RR 的方法。这不是唯一可能的方法。

  1. 选择哈希算法 (hash algorithm) 以及盐 (salt) 和迭代次数 (iterations) 的值。

  2. 对于区域中的每个唯一原始所有者名称, 添加一个 NSEC3 RR。

    • 如果正在使用 Opt-Out, 则未签名委派的所有者名称可以 (MAY) 被排除。

    • NSEC3 RR 的所有者名称是原始所有者名称的哈希, 作为单个标签 (label) 添加到区域名称之前。

    • Next Hashed Owner Name (下一个哈希所有者名称) 字段暂时留空。

    • 如果正在使用 Opt-Out, 则将 Opt-Out 位设置为 1。

    • 为了冲突检测 (collision detection) 目的, 可选地跟踪 NSEC3 RR 的原始所有者名称。

    • 此外, 为了冲突检测目的, 可选地创建一个额外的 NSEC3 RR, 对应于在前面添加星号标签的原始所有者名称 (即, 就好像通配符作为此所有者名称的子级存在一样), 并跟踪此原始所有者名称。将此 NSEC3 RR 标记为临时 (temporary)。

  3. 对于原始所有者名称处的每个 RRSet, 在类型位图字段中设置相应的位。

  4. 如果区域顶点 (apex) 和原始所有者名称之间的标签数量差大于 1, 则需要为顶点和原始所有者名称之间的每个空非终结符添加额外的 NSEC3 RR。此过程可能生成具有重复哈希所有者名称的 NSEC3 RR。可选地, 为了冲突检测, 跟踪这些 NSEC3 RR 的原始所有者名称, 并以类似于步骤 1 的方式为通配符冲突创建临时 NSEC3 RR。

  5. 将 NSEC3 RR 集合按哈希顺序 (hash order) 排序。

  6. 通过将具有相同哈希所有者名称的 NSEC3 RR 替换为单个 NSEC3 RR 来组合它们, 其类型位图字段由 NSEC3 RR 集合表示的类型的并集组成。如果跟踪了原始所有者名称, 则在组合时可以检测到冲突, 因为所有匹配的 NSEC3 RR 应该具有相同的原始所有者名称。丢弃任何可能的临时 NSEC3 RR。

  7. 在每个 NSEC3 RR 中, 通过使用哈希顺序中下一个 NSEC3 RR 的值插入下一个哈希所有者名称。区域中最后一个 NSEC3 RR 的下一个哈希所有者名称包含哈希顺序中第一个 NSEC3 RR 的哈希所有者名称的值。

  8. 最后, 向区域顶点添加一个具有相同哈希算法 (Hash Algorithm), 迭代次数 (Iterations) 和盐 (Salt) 字段的 NSEC3PARAM RR。

如果检测到哈希冲突, 则必须选择新的盐, 并重新启动签名过程。

7.2. Zone Serving (区域服务)​

本规范修改了权威服务器生成的启用 DNSSEC 的 DNS 响应。特别是, 它用 NSEC3 RR 替换了此类响应中 NSEC RR 的使用。

在以下响应情况下, DNSSEC [RFC4035] 规定的 NSEC RR 被证明相同事实的 NSEC3 RR 替换。本规范不会更改不包含 NSEC RR 的响应。

当返回包含多个 NSEC3 RR 的响应时, 所有 NSEC3 RR 必须 (MUST) 使用相同的哈希算法, 迭代和盐值。标志 (Flags) 字段值必须 (MUST) 为零或一。

7.2.1. Closest Encloser Proof (最近封闭者证明)​

对于许多 NSEC3 响应, 需要最近封闭者 (closest encloser) 的证明。这是证明 QNAME 的某个祖先是 QNAME 的最近封闭者。

此证明由 (最多) 两个不同的 NSEC3 RR 组成:

  • 一个匹配最近 (可证明的) 封闭者的 NSEC3 RR。

  • 一个覆盖到最近封闭者的"下一个更近名称"的 NSEC3 RR。

第一个 NSEC3 RR 本质上提出了一个可能的最近封闭者, 并证明该特定封闭者确实存在。第二个 NSEC3 RR 证明该可能的最近封闭者是最近的, 并证明 QNAME (以及 QNAME 和最近封闭者之间的任何祖先) 不存在。

在后续描述中, 这些 NSEC3 RR 统称为"最近封闭者证明"。

例如, 不存在的"alpha.beta.gamma.example."所有者名称的最近封闭者证明可能证明"gamma.example."是最近封闭者。此响应将包含匹配"gamma.example."的 NSEC3 RR, 并且还将包含覆盖"beta.gamma.example." (即"下一个更近名称") 的 NSEC3 RR。

当使用 Opt-Out (第 6 节) 时, 可能无法证明实际的最近封闭者, 因为它是或是由 Opt-Out 跨度覆盖的不安全委派的一部分。在这种情况下, 使用最近可证明封闭者 (closest provable encloser) 而不是证明实际的最近封闭者。也就是说, 使用最近的封闭权威名称。在这种情况下, 用于此证明的 NSEC3 RR 集合称为"最近可证明封闭者证明"。

7.2.2. Name Error Responses (名称错误响应)​

为了证明 QNAME 的不存在, 响应中必须 (MUST) 包括最近封闭者证明和覆盖最近封闭者处 (不存在的) 通配符 RR 的 NSEC3 RR。这个 (最多) 三个 NSEC3 RR 的集合既证明了 QNAME 不存在, 也证明了可能匹配 QNAME 的通配符也不存在。

例如, 如果"gamma.example."是到 QNAME 的最近可证明封闭者, 则响应的授权部分 (authority section) 中包含覆盖"*.gamma.example."的 NSEC3 RR。

7.2.3. No Data Responses, QTYPE is not DS (无数据响应, QTYPE 不是 DS)​

服务器必须 (MUST) 包括匹配 QNAME 的 NSEC3 RR。此 NSEC3 RR 在其类型位图字段中绝对不能 (MUST NOT) 设置与 QTYPE 或 CNAME 对应的位。

7.2.4. No Data Responses, QTYPE is DS (无数据响应, QTYPE 是 DS)​

如果存在匹配 QNAME 的 NSEC3 RR, 服务器必须 (MUST) 在响应中返回它。此 NSEC3 RR 的类型位图字段中绝对不能 (MUST NOT) 设置与 DS 和 CNAME 对应的位。

如果没有匹配 QNAME 的 NSEC3 RR, 服务器必须 (MUST) 返回 QNAME 的最近可证明封闭者证明。覆盖"下一个更近名称"的 NSEC3 RR 必须 (MUST) 设置 Opt-Out 位 (请注意, 根据定义这是正确的 -- 如果未设置 Opt-Out 位, 则出现了问题)。

如果服务器对 QNAME 处区域切分 (zone cut) 的两侧都是权威的, 则服务器必须 (MUST) 从区域切分的父侧返回证明。

7.2.5. Wildcard No Data Responses (通配符无数据响应)​

如果 QNAME 存在通配符匹配, 但在该名称处不存在 QTYPE, 则响应必须 (MUST) 包括 QNAME 的最近封闭者证明, 并且必须 (MUST) 包括匹配通配符的 NSEC3 RR。此组合既证明了 QNAME 本身不存在, 也证明了匹配 QNAME 的通配符确实存在。请注意, 到 QNAME 的最近封闭者必须 (MUST) 是通配符 RR 的直接祖先 (如果不是这种情况, 则出现了问题)。

7.2.6. Wildcard Answer Responses (通配符应答响应)​

如果 QNAME 和 QTYPE 存在通配符匹配, 则除了在响应的应答部分 (answer section) 中返回的扩展通配符 RRSet 之外, 还必须返回通配符匹配有效的证明。

此证明通过证明 QNAME 不存在并且 QNAME 的最近封闭者和通配符的直接祖先是相同的 (即, 匹配了正确的通配符) 来完成。

为此, 必须 (MUST) 返回覆盖通配符直接祖先的"下一个更近名称"的 NSEC3 RR。不需要返回匹配最近封闭者的 NSEC3 RR, 因为此最近封闭者的存在通过响应中存在的扩展通配符来证明。

7.2.7. Referrals to Unsigned Subzones (到未签名子区域的引用)​

如果存在匹配委派名称的 NSEC3 RR, 则该 NSEC3 RR 必须 (MUST) 包含在响应中。NSEC3 RR 的类型位图中的 DS 位绝对不能 (MUST NOT) 设置。

如果区域是 Opt-Out 的, 则可能没有与委派对应的 NSEC3 RR。在这种情况下, 响应中必须 (MUST) 包括最近可证明封闭者证明。其中覆盖委派之"下一个更近名称"的 NSEC3 RR 必须 (MUST) 将 Opt-Out 标志设置为一 (请注意, 除非出现问题, 否则情况将是这样)。

7.2.8. Responding to Queries for NSEC3 Owner Names (响应 NSEC3 所有者名称的查询)​

NSEC3 RR 的所有者名称不像其他所有者名称那样在 NSEC3 RR 链中表示。结果, 每个 NSEC3 所有者名称被另一个 NSEC3 RR 覆盖, 有效地否定了 NSEC3 RR 的存在。这是一个悖论 (paradox), 因为 NSEC3 RR 的存在可以通过其 RRSIG RRSet 证明。

如果以下条件全部为真:

  • QNAME 等于现有 NSEC3 RR 的所有者名称, 并且

  • QNAME 处不存在 RR 类型, 在 QNAME 的任何后代处也不存在,

则响应必须 (MUST) 构造为名称错误响应 (第 7.2.2 节)。或者, 换句话说, 权威名称服务器将表现得好像 NSEC3 RR 的所有者名称不存在。

请注意, NSEC3 RR 作为 AXFR 或 IXFR 查询的结果返回。

7.2.9. Server Response to a Run-Time Collision (服务器对运行时冲突的响应)​

如果不存在的 QNAME 的哈希与现有 NSEC3 RR 的所有者名称发生冲突, 则服务器将无法返回证明 QNAME 不存在的响应。在这种情况下, 服务器必须 (MUST) 返回 RCODE 为 2 (服务器失败, server failure) 的响应。

请注意, 使用本文档中指定的哈希算法 SHA-1, 此类冲突是极不可能的。

7.3. Secondary Servers (辅助服务器)​

辅助服务器 (以及可能的其他实体) 需要可靠地确定哪些 NSEC3 参数 (即, 哈希, 盐和迭代次数) 存在于每个哈希所有者名称处, 以便能够为否定响应选择适当的 NSEC3 RR 集合。这由区域顶点处存在的 NSEC3PARAM RR 指示。

如果存在多个 NSEC3PARAM RR, 则存在多个有效的 NSEC3 链。服务器必须选择其中一个, 但可以使用任何标准来这样做。

7.4. Zones Using Unknown Hash Algorithms (使用未知哈希算法的区域)​

根据本规范签名但使用无法识别的 NSEC3 哈希算法值的区域无法有效地提供服务。这样的区域应该 (SHOULD) 在加载时被拒绝。服务器在处理将属于此类区域的查询时应该 (SHOULD) 以 RCODE=2 (服务器失败) 响应。

7.5. Dynamic Update (动态更新)​

使用 NSEC3 签名的区域可以接受动态更新 [RFC2136]。但是, NSEC3 为动态更新引入了一些特殊考虑因素。

在区域中添加和删除名称必须 (MUST) 考虑空非终结符的创建或删除。

  • 当删除具有相应 NSEC3 RR 的名称时, 必须 (MUST) 删除由该名称创建的空非终结符对应的任何 NSEC3 RR。请注意, 多个名称可能断言特定空非终结符的存在。

  • 当添加需要添加 NSEC3 RR 的名称时, 还必须 (MUST) 为创建的任何空非终结符添加 NSEC3 RR。也就是说, 如果不存在匹配空非终结符的现有 NSEC3 RR, 则必须创建并添加它。

区域中存在 Opt-Out 意味着某些名称的添加或委派将不需要更改区域中的 NSEC3 RR。

  • 当删除委派 RRSet 时, 如果该委派没有匹配的 NSEC3 RR, 则它已被选择退出 (opted out)。在这种情况下, 不需要进一步操作。

  • 当添加委派 RRSet 时, 如果委派的"下一个更近名称"被现有的 Opt-Out NSEC3 RR 覆盖, 则可以 (MAY) 添加委派而不修改区域中的 NSEC3 RR。

区域中存在 Opt-Out 意味着在添加或删除 NSEC3 RR 时, 应在新的或修改的 NSEC3 RR 中设置的 Opt-Out 标志的值是不明确的。服务器应该 (SHOULD) 遵循以下这组基本规则来解决歧义。

这些规则的核心概念是保留覆盖 NSEC3 RR 的 Opt-Out 标志的状态。

  • 当删除 NSEC3 RR 时, 不应更改前一个 NSEC3 RR (其下一个哈希所有者名称被修改的那个) 的 Opt-Out 标志的值。

  • 当添加 NSEC3 RR 时, Opt-Out 标志的值设置为先前覆盖 NSEC3 RR 所有者名称的 NSEC3 RR 的 Opt-Out 标志的值。也就是说, 现在是前一个的 NSEC3 RR。

如果有问题的区域在使用 Opt-Out 标志时是一致的 (即, 区域中的所有 NSEC3 RR 对该标志具有相同的值), 则这些规则将保留该一致性。如果区域在标志的使用上不一致 (即, 部分 Opt-Out 区域), 则这些规则将不会保留标志使用的相同模式。

对于部分使用 Opt-Out 标志的区域, 如果该使用有逻辑模式, 则可以通过在服务器上使用本地策略 (local policy) 来维护该模式。

最后于 更新