8. 通用 DNSSEC (General DNSSEC)

大多数 DNSSEC 术语定义在 [RFC4033], [RFC4034], [RFC4035] 和 [RFC5155] 中. 这里重点列出在 DNS 社区中造成混淆的术语.

DNSSEC-aware and DNSSEC-unaware: 这两个术语在一些 RFC 中使用, 但尚未正式定义. 不过, [RFC4033] 第 2 节定义了多种 resolver 和 validator, 包括 "non-validating security-aware stub resolver", "non-validating stub resolver", "security-aware name server", "security-aware recursive name server", "security-aware resolver", "security-aware stub resolver" 和 "security-oblivious 'anything'". (注意, DNSSEC 相关文档中某些地方使用的 "validating resolver" 这一术语也没有定义.)

Signed zone: "其 RRset 已签名, 并包含构造正确的 DNSKEY, Resource Record Signature (RRSIG), Next Secure (NSEC) 和 (可选) DS 记录的区域." (引自 [RFC4033] 第 2 节.) 其他上下文中曾指出, 区域本身并不是真正被签名, 而是区域中的所有相关 RRset 被签名. 尽管如此, 如果一个应被签名的区域包含任何未签名 (或 opted out) 的 RRset, 这些 RRset 会被视为 bogus, 因此整个区域需要以某种方式处理.

还应注意, 自 [RFC6840] 发布以来, signed zone 不再要求必须有 NSEC 记录: signed zone 可以改为包含 NSEC3 记录. [RFC7129] 为 DNSSEC 用于提供经过认证的不存在否定响应的 NSEC 和 NSEC3 机制提供了更多背景说明和上下文.

Unsigned zone: [RFC4033] 第 2 节将其定义为 "未签名的区域". [RFC4035] 第 2 节将其定义为 "未按本节规则包含这些记录 [构造正确的 DNSKEY, Resource Record Signature (RRSIG), Next Secure (NSEC) 和 (可选) DS 记录] 的区域". [RFC4035] 第 5.2 节末尾有一条重要说明, 定义了另一种区域被视为 unsigned 的情况: "如果 resolver 不支持经过认证的 DS RRset 中列出的任何算法, 则 resolver 无法验证到 child zone 的认证路径. 在这种情况下, resolver SHOULD 将 child zone 视为 unsigned."

NSEC: "NSEC 记录允许 security-aware resolver 使用与认证其他 DNS 回复相同的机制, 对名称不存在或类型不存在的否定回复进行认证." (引自 [RFC4033] 第 3.2 节.) 简言之, NSEC 记录提供经过认证的不存在否定.

"NSEC 资源记录列出两个独立事项: 包含 authoritative data 或 delegation point NS RRset 的下一个 owner name (按区域的规范排序), 以及 NSEC RR 的 owner name 处存在的 RR 类型集合." (引自 RFC 4034 第 4 节)

NSEC3: 与 NSEC 记录一样, NSEC3 记录也提供经过认证的不存在否定; 但 NSEC3 记录缓解 zone enumeration 并支持 Opt-Out. NSEC3 资源记录定义在 [RFC5155] 中.

注意, [RFC6840] 说 [RFC5155] "现在被视为 [RFC4033] 第 10 节所述 DNS Security Document Family 的一部分". 这意味着早期 RFC 中一些只谈到 NSEC 记录的定义, 可能应被视为同时谈到 NSEC 和 NSEC3.

Opt-out: "Opt-Out Flag 指示此 NSEC3 RR 是否可以覆盖 unsigned delegations." (引自 [RFC5155] 第 3.1.2.1 节.) Opt-out 处理的是保护到 insecure zone 的 delegation 成本高昂的问题. 使用 Opt-Out 时, 属于 insecure delegation 的名称 (以及仅由 insecure delegation 派生的 empty non-terminals) 不需要 NSEC3 记录或其对应的 RRSIG 记录. Opt-Out NSEC3 记录不能证明或否定 insecure delegations 的存在. (改编自 [RFC7129] 第 5.1 节)

Zone enumeration: "通过连续查询发现区域完整内容的实践." (引自 [RFC5155] 第 1.3 节.) 这有时也称为 "zone walking". Zone enumeration 不同于 zone content guessing, 后者由猜测者使用一个包含可能标签的大型字典并连续发送查询, 或将 NSEC3 记录内容与这类字典进行匹配.

Key signing key (KSK): "只对区域中的 apex DNSKEY RRset 进行签名" 的 DNSSEC 密钥. (引自 [RFC6781] 第 3.1 节)

Zone signing key (ZSK): "可用于签署区域中除 apex DNSKEY RRset 以外所有需要签名的 RRset 的 DNSSEC 密钥." (引自 [RFC6781] 第 3.1 节.) 注意, KSK 和 ZSK 角色并不互斥: 单个密钥可以同时是 KSK 和 ZSK. 还要注意, ZSK 有时也用于签署 apex DNSKEY RRset.

Combined signing key (CSK): "在不区分 KSK 和 ZSK 的情况下, 即密钥同时具有 KSK 和 ZSK 角色时, 我们称其为 Single-Type Signing Scheme." (引自 [RFC6781] 第 3.1 节.) 这有时称为 "combined signing key" 或 CSK. 决定某个特定密钥是 ZSK, KSK 还是 CSK 的是运行实践, 而不是协议.

Secure Entry Point (SEP): DNSKEY RDATA 中的一个标志, "可用于区分那些在构建信任链时意图作为进入区域的安全入口点的密钥, 即它们 (将) 被父侧 DS RR 指向或被配置为 trust anchor. 因此, 建议在用作 KSK 的密钥上设置 SEP flag, 而不要在用作 ZSK 的密钥上设置; 对于不区分 KSK 和 ZSK 的情况 (即 Single-Type Signing Scheme), 建议在所有密钥上设置 SEP flag." (引自 [RFC6781] 第 3.2.3 节.) 注意, SEP flag 只是提示, 在验证期间, 不得因某个 DNSKEY RR 是否存在该标志而排除其作为 KSK 或 ZSK 使用.

DNSSEC Policy (DP): 一份声明, "阐明为 DNSSEC-signed zone 实施的安全要求和标准." (引自 [RFC6841] 第 2 节)

DNSSEC Practice Statement (DPS): "一份实践披露文档, 可支持 DNSSEC Policy (如果存在) 并作为其补充文档, 它从高层说明给定区域的管理方如何实施程序和控制." (引自 [RFC6841] 第 2 节)