非官方中文译本声明：本页为 IETF RFC 4035《Protocol Modifications for the DNS Security Extensions》 的非官方中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布、不受版权限制；依据 BCP 78，本译本为署名翻译作品，译文力求忠实但不构成官方版本，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc4035。
RFC 4035《DNS 安全扩展的协议修改》中文译本
摘要
本文档是描述 DNS 安全扩展（DNSSEC）的一组文档中的一员。DNS 安全扩展是一组新的资源记录与协议修改，为 DNS 增加数据来源认证（data origin authentication）与数据完整性（data integrity）。本文档描述 DNSSEC 协议修改。本文档定义了已签名区（signed zone）的概念，以及使用 DNSSEC 提供服务与解析的要求。这些技术使安全感知解析器（security-aware resolver）能够认证 DNS 资源记录与权威的 DNS 错误指示。
本文档取代（obsoletes）RFC 2535，并纳入对 RFC 2535 的所有更新的变更。
1. 引言
DNS 安全扩展（DNSSEC）是一组新的资源记录与协议修改，为 DNS 增加数据来源认证与数据完整性。本文档定义 DNSSEC 协议修改。本文档第 2 节定义了已签名区的概念，并列出了区签名（zone signing）的要求。第 3 节描述了处理已签名区所需的权威名称服务器行为修改。第 4 节描述了包含安全感知解析器功能的实体的行为。最后，第 5 节定义了如何使用 DNSSEC RR 来认证响应。
1.1. 背景与相关文档
本文档是定义 DNSSEC 的一组文档中的一员，应当作为一个集合一起阅读。
[RFC4033] 包含 DNSSEC 的引言与通用术语的定义；假定读者熟悉该文档。[RFC4033] 还包含被本文档集更新与取代的其他文档的列表。
[RFC4034] 定义了 DNSSEC 资源记录。
还假定读者熟悉 [RFC1034]、[RFC1035] 及其后续更新文档中所描述的基本 DNS 概念；特别是 [RFC2181] 与 [RFC2308]。
本文档定义了 DNSSEC 协议操作。
1.2. 保留词汇
本文档中的关键词「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」与「OPTIONAL」应按照 [RFC2119] 中的描述加以解释。
2. 区签名
DNSSEC 引入了已签名区的概念。已签名区按照第 2.1、2.2、2.3 与 2.4 节分别规定的规则，包含 DNS 公钥（DNSKEY）、资源记录签名（RRSIG）、下一安全（NSEC）以及（可选）委派签名者（DS）记录。未按本节规则包含这些记录的区即未签名区（unsigned zone）。
DNSSEC 需要对 CNAME 资源记录（[RFC1035]）的定义进行修改。第 2.5 节修改 CNAME RR，以允许 RRSIG 与 NSEC RR 与 CNAME RR 出现在相同的 owner name 处。
DNSSEC 规定了两种新 RR 类型 NSEC 与 DS 的放置位置，它们可以放置在区切口（zone cut）的父侧（即在委派点处）。这是对「禁止在区切口处的父区中放置数据」这一普遍禁令的例外。第 2.6 节描述了这一修改。
2.1. 在区中包含 DNSKEY RR
为签署一个区，该区的管理员生成一把或多把公钥/私钥对，并使用私钥签署区中的权威 RRset。对于用于在区中创建 RRSIG RR 的每把私钥，该区应当（SHOULD）包含一条含有相应公钥的区 DNSKEY RR。区密钥 DNSKEY RR必须（MUST）置位 flags RDATA 字段的 Zone Key 位（参见 [RFC4034] 第 2.1.1 节）。与其他 DNS 操作相关联的公钥可以（MAY）存储在未标记为区密钥的 DNSKEY RR 中，但不得（MUST NOT）用于验证 RRSIG。
如果区管理员打算让已签名区在作为安全孤岛（island of security）之外还能被使用，则区顶点必须（MUST）至少包含一条 DNSKEY RR，作为进入该区的安全入口点。随后该安全入口点可被用作父区中相应 DS RR 的安全委派目标（参见 [RFC4034]）。
2.2. 在区中包含 RRSIG RR
对于已签名区中的每个权威 RRset，必须（MUST）至少存在一条满足下列要求的 RRSIG 记录：
- RRSIG owner name 等于该 RRset 的 owner name。
- RRSIG 类等于该 RRset 的类。
- RRSIG Type Covered 字段等于该 RRset 的类型。
- RRSIG Original TTL 字段等于该 RRset 的 TTL。
- RRSIG RR 的 TTL 等于该 RRset 的 TTL。
- RRSIG Labels 字段等于该 RRset owner name 中的标签数，不计入空的根标签，也不计入最左侧标签（如果它是通配符）。
- RRSIG Signer's Name 字段等于包含该 RRset 的区的名称。
- RRSIG Algorithm、Signer's Name 与 Key Tag 字段标识区顶点处的一条区密钥 DNSKEY 记录。
为给定 RRset 构造 RRSIG RR 的过程在 [RFC4034] 中描述。一个 RRset可以（MAY）关联多条 RRSIG RR。请注意，由于 RRSIG RR 与它们所包含签名的 RRset 紧密关联，RRSIG RR 与所有其他 DNS RR 类型不同，不构成 RRset。特别是，具有共同 owner name 的 RRSIG RR 之间的 TTL 值不遵循 [RFC2181] 所描述的 RRset 规则。
RRSIG RR 本身不得（MUST NOT）被签名，因为对 RRSIG RR 签名不会增加任何价值，而且会在签名过程中造成无限循环。
出现在区顶点名称处的 NS RRset必须（MUST）被签名，但出现在委派点处的 NS RRset（即父区中把该名称委派给子区名称服务器的 NS RRset）不得（MUST NOT）被签名。与委派相关联的 glue 地址 RRset不得（MUST NOT）被签名。
对于每个 RRset，必须（MUST）存在一条使用区顶点 DNSKEY RRset 中每种算法的至少一条 DNSKEY 生成的 RRSIG。区顶点 DNSKEY RRset 本身必须（MUST）由委派父区（如有）中 DS RRset 里出现的每种算法签名。
2.3. 在区中包含 NSEC RR
区中每个具有权威数据或委派点 NS RRset 的 owner name 都必须（MUST）有一条 NSEC 资源记录。NSEC RR 的格式以及为给定名称构造 NSEC RR 的过程在 [RFC4034] 中描述。
任何 NSEC RR 的 TTL 值应当（SHOULD）与区 SOA RR 中的 minimum TTL 值字段相同。
NSEC 记录（及其关联的 RRSIG RRset）不得（MUST NOT）是任何特定 owner name 处唯一的 RRset。也就是说，签名过程不得（MUST NOT）为在区被签名之前不是任何 RRset owner name 的 owner name 节点创建 NSEC 或 RRSIG RR。其主要原因是：希望同一区的已签名与未签名版本之间的名称空间保持一致，以及希望降低安全无感递归名称服务器（security-oblivious recursive name server）中响应不一致的风险。
已签名区中每条 NSEC 资源记录的类型位图必须（MUST）表明 NSEC 记录本身及其对应的 RRSIG 记录均存在。
需要 RRSIG 记录的 owner name 集合与需要 NSEC 记录的 owner name 集合之间的区别很微妙，值得强调。RRSIG 记录存在于所有权威 RRset 的 owner name 处。NSEC 记录存在于已签名区对其具有权威性的所有名称的 owner name 处，也存在于已签名区向子区委派的委派点 owner name 处。NSEC 与 RRSIG 记录都不存在于（父区中的）glue 地址 RRset 的 owner name 处。不过请注意，这种区别在很大程度上只在区签名过程中可见，因为 NSEC RRset 是权威数据，因此会被签名。这样，在已签名区中，任何具有 NSEC RRset 的 owner name 也会具有 RRSIG RR。
委派点处 NSEC RR 的位图需要特别注意。对应委派 NS RRset 以及父区对其具有权威数据的任何 RRset 的位必须（MUST）被置位；对应父区对其不具权威性的任何非 NS RRset 的位必须（MUST）被清除。
2.4. 在区中包含 DS RR
DS 资源记录在 DNS 区之间建立认证链。当子区已签名时，委派点处应当（SHOULD）存在 DS RRset。DS RRset可以（MAY）包含多条记录，每条引用子区中用于验证该区 RRSIG 的一把公钥。区中所有 DS RRset必须（MUST）被签名，且 DS RRset不得（MUST NOT）出现在区的顶点。
DS RR应当（SHOULD）指向存在于子区区顶点 DNSKEY RRset 中的一条 DNSKEY RR，且子区的区顶点 DNSKEY RRset应当（SHOULD）由相应的私钥签名。不满足这些条件的 DS RR 对验证没有用处，但因为 DS RR 与其对应的 DNSKEY RR 位于不同的区，且 DNS 只是松散一致的，因此可能发生暂时的不匹配。
DS RRset 的 TTL应当（SHOULD）与委派 NS RRset（即包含该 DS RRset 的同一区中的 NS RRset）的 TTL 相匹配。
构造 DS RR 需要了解子区中对应的 DNSKEY RR，这意味着子区与父区之间需要通信。这种通信是一个运营问题，不在本文档讨论范围之内。
2.5. 对 CNAME 资源记录的修改
如果在已签名区的某个名称处存在 CNAME RRset，则该名称处需要（REQUIRED）适当的 RRSIG 与 NSEC RRset。出于安全动态更新的目的，该名称处还允许存在 KEY RRset（[RFC3007]）。其他类型不得（MUST NOT）出现在该名称处。
这是对 [RFC1034] 中给出的 CNAME 原始定义的修改。CNAME RR 的原始定义不允许任何其他类型与 CNAME 记录共存，但已签名区要求每个权威名称都有 NSEC 与 RRSIG RR。为解决这一冲突，本规范修改 CNAME 资源记录的定义，允许其与 NSEC 和 RRSIG RR 共存。
2.6. 出现在区切口处的 DNSSEC RR 类型
DNSSEC 引入了两种新的 RR 类型，它们比较特殊，可以出现在区切口的父侧。在区切口的父侧（即在委派点处），owner name 处需要（REQUIRED）NSEC RR。如果被委派的区已签名并寻求建立通向父区的认证链，则也可能出现 DS RR。这是对原始 DNS 规范（[RFC1034]）的例外——该规范规定只有 NS RRset 可以出现在区切口的父侧。
本规范更新原始 DNS 规范，允许 NSEC 与 DS RR 类型出现在区切口的父侧。当这些 RRset 出现在区切口的父侧时，它们对父区是权威的。
2.7. 已签名区示例
附录 A 展示了一个小型已签名区的完整示例。
3. 提供服务（Serving）
本节描述包含安全感知名称服务器（security-aware name server）功能的实体的行为。在许多情况下，此类功能将是安全感知递归名称服务器的一部分，但安全感知权威名称服务器也具有其中一些要求。特定于安全感知递归名称服务器的功能在第 3.2 节中描述；特定于权威服务器的功能在第 3.1 节中描述。
在下面的讨论中，术语「SNAME」「SCLASS」与「STYPE」的使用方式与 [RFC1034] 相同。
安全感知名称服务器必须（MUST）支持 EDNS0（[RFC2671]）报文大小扩展，必须（MUST）支持至少 1220 字节的报文大小，并应当（SHOULD）支持 4000 字节的报文大小。由于 IPv6 数据包只能由源主机分片，除非已知路径 MTU，否则安全感知名称服务器应当（SHOULD）采取措施，确保它在 IPv6 上传输的 UDP 数据报在必要时按最小 IPv6 MTU 分片。关于报文大小与分片问题的进一步讨论，请参阅 [RFC1122]、[RFC2460] 与 [RFC3226]。
安全感知名称服务器若收到不包含 EDNS OPT 伪 RR 或 DO 位被清除的 DNS 查询，必须（MUST）将 RRSIG、DNSKEY 与 NSEC RR 视同任何其他 RRset 处理，并且不得（MUST NOT）执行下文描述的任何额外处理。由于 DS RR 类型具有只在委派点处父区中存在的特殊性质，DS RR 始终需要一些特殊处理，如第 3.1.4.1 节所述。
收到对安全 RR 类型的显式查询、而查询内容与其所服务的多个区（例如，在服务器对两区均具有权威性的委派点之上和之下的 NSEC 与 RRSIG RR）相匹配的安全感知名称服务器，应保持行为自洽。只要对名称服务器的每次查询响应始终一致，名称服务器可以（MAY）返回以下之一：
- 委派点之上的 RRset。
- 委派点之下的 RRset。
- 委派点之上与之下两者的 RRset。
- 空的 Answer 部分（无记录）。
- 某些其他响应。
- 一个错误。
DNSSEC 在 DNS 报文头中分配了两个新位：CD（禁用检查，Checking Disabled）位与 AD（已认证数据，Authentic Data）位。CD 位由解析器控制；安全感知名称服务器必须（MUST）将查询中的 CD 位复制到相应的响应中。AD 位由名称服务器控制；安全感知名称服务器必须（MUST）忽略查询中 AD 位的设置。关于这些位的行为细节，请参见第 3.1.6、3.2.2、3.2.3、4 与 4.9 节。
按照 [RFC2672] 的描述从 DNAME RR 合成 CNAME RR 的安全感知名称服务器，不应（SHOULD NOT）为合成的 CNAME RR 生成签名。
3.1. 权威名称服务器
收到相关查询（其 EDNS（[RFC2671]）OPT 伪 RR 的 DO 位（[RFC3225]）已置位）时，已签名区的安全感知权威名称服务器必须（MUST）按照下列规则加入额外的 RRSIG、NSEC 与 DS RR：
- 可用于认证响应的 RRSIG RR必须（MUST）按照第 3.1.1 节的规则包含在响应中。
- 可用于提供经认证的不存在证明的 NSEC RR必须（MUST）按照第 3.1.3 节的规则自动包含在响应中。
- 在委派响应中，DS RRset 或证明不存在 DS RR 的 NSEC RR 二者之一必须（MUST）按照第 3.1.4 节的规则自动包含。
这些规则仅适用于其语义传达资源记录存在或不存在信息的响应。也就是说，这些规则无意排除诸如 RCODE 4（「未实现」）或 RCODE 5（「拒绝」）之类的响应。
DNSSEC 不改变 DNS 区传送协议。第 3.1.5 节讨论了区传送要求。
3.1.1. 在响应中包含 RRSIG RR
当响应一个 DO 位已置位的查询时，安全感知权威名称服务器应当（SHOULD）尝试发送安全感知解析器可用于认证响应中 RRset 的 RRSIG RR。名称服务器应当（SHOULD）尽一切努力在响应中把 RRset 与其关联的 RRSIG 保持在一起。响应中包含 RRSIG RR 受下列规则约束：
- 当把已签名 RRset 放入 Answer 部分时，名称服务器必须（MUST）也将其 RRSIG RR 放入 Answer 部分。RRSIG RR 的包含优先级高于任何其他可能必须包含的 RRset。如果空间不允许包含这些 RRSIG RR，名称服务器必须（MUST）置位 TC 位。
- 当把已签名 RRset 放入 Authority 部分时，名称服务器必须（MUST）也将其 RRSIG RR 放入 Authority 部分。RRSIG RR 的包含优先级高于任何其他可能必须包含的 RRset。如果空间不允许包含这些 RRSIG RR，名称服务器必须（MUST）置位 TC 位。
- 当把已签名 RRset 放入 Additional 部分时，名称服务器必须（MUST）也将其 RRSIG RR 放入 Additional 部分。如果空间不允许同时包含 RRset 及其关联的 RRSIG RR，名称服务器可以（MAY）保留 RRset 而丢弃 RRSIG RR。如果发生这种情况，名称服务器不得（MUST NOT）仅仅因为这些 RRSIG RR 放不下而置位 TC 位。
3.1.2. 在响应中包含 DNSKEY RR
当响应一个 DO 位已置位且请求已签名区区顶点处 SOA 或 NS RR 的查询时，该区的安全感知权威名称服务器可以（MAY）在 Additional 部分返回区顶点 DNSKEY RRset。在这种情况下，DNSKEY RRset 及其关联的 RRSIG RR 的优先级低于将放入 Additional 部分的任何其他信息。除非响应报文中有足够的空间同时容纳 DNSKEY RRset 及其关联的 RRSIG RR，否则名称服务器不应（SHOULD NOT）包含 DNSKEY RRset。如果没有足够的空间包含这些 DNSKEY 与 RRSIG RR，名称服务器必须（MUST）省略它们，且不得（MUST NOT）仅仅因为这些 RR 放不下而置位 TC 位（参见第 3.1.1 节）。
3.1.3. 在响应中包含 NSEC RR
当响应一个 DO 位已置位的查询时，已签名区的安全感知权威名称服务器必须（MUST）在下列每种情况下包含 NSEC RR：
无数据（No Data）：该区包含与 <SNAME, SCLASS> 完全匹配的 RRset，但不包含任何与 <SNAME, SCLASS, STYPE> 完全匹配的 RRset。
名称错误（Name Error）：该区不包含任何与 <SNAME, SCLASS> 完全匹配或通过通配符名称扩展匹配的 RRset。
通配符应答（Wildcard Answer）：该区不包含任何与 <SNAME, SCLASS> 完全匹配的 RRset，但包含一个通过通配符名称扩展与 <SNAME, SCLASS, STYPE> 匹配的 RRset。
通配符无数据（Wildcard No Data）：该区不包含任何与 <SNAME, SCLASS> 完全匹配的 RRset，但包含一个或多个通过通配符名称扩展与 <SNAME, SCLASS> 匹配的 RRset，但不包含任何通过通配符名称扩展与 <SNAME, SCLASS, STYPE> 匹配的 RRset。
在上述每种情况下，名称服务器都会在响应中包含 NSEC RR，以证明区中不存在与 <SNAME, SCLASS, STYPE> 完全匹配的项，并证明名称服务器返回的响应在给定区中数据的情况下是正确的。
3.1.3.1. 包含 NSEC RR：无数据响应
如果区包含与 <SNAME, SCLASS> 匹配的 RRset，但不包含与 <SNAME, SCLASS, STYPE> 匹配的 RRset，则名称服务器必须（MUST）在响应的 Authority 部分中包含 <SNAME, SCLASS> 的 NSEC RR 及其关联的 RRSIG RR（参见第 3.1.1 节）。如果空间不允许包含 NSEC RR 或其关联的 RRSIG RR，名称服务器必须（MUST）置位 TC 位（参见第 3.1.1 节）。
由于搜索名称存在，通配符名称扩展不适用于此查询，一条已签名的 NSEC RR 就足以证明所请求的 RR 类型不存在。
3.1.3.2. 包含 NSEC RR：名称错误响应
如果区不包含任何与 <SNAME, SCLASS> 完全匹配或通过通配符名称扩展匹配的 RRset，则名称服务器必须（MUST）在 Authority 部分连同其关联的 RRSIG RR 一起包含下列 NSEC RR：
- 证明 <SNAME, SCLASS> 不存在完全匹配的 NSEC RR。
- 证明区中不存在任何会通过通配符名称扩展与 <SNAME, SCLASS> 匹配的 RRset 的 NSEC RR。
在某些情况下，单条 NSEC RR 可能同时证明这两点。如果是这样，名称服务器应当（SHOULD）只在 Authority 部分包含该 NSEC RR 及其 RRSIG RR 各一次。
如果空间不允许包含这些 NSEC 与 RRSIG RR，名称服务器必须（MUST）置位 TC 位（参见第 3.1.1 节）。
当这些 NSEC 与 RRSIG RR 包含在响应的 Authority 部分时，其 owner name 不适用通配符名称扩展。
请注意，这种形式的响应包括 SNAME 对应区中空非终端名称（empty non-terminal name）的情况（即不是任何 RRset 的 owner name、但是一条或多条 RRset 的父名称的名称）。
3.1.3.3. 包含 NSEC RR：通配符应答响应
如果区不包含任何与 <SNAME, SCLASS> 完全匹配的 RRset，但包含一个通过通配符名称扩展与 <SNAME, SCLASS, STYPE> 匹配的 RRset，则名称服务器必须（MUST）在 Answer 部分包含通配符扩展后的应答及相应的通配符扩展后的 RRSIG RR，并必须（MUST）在 Authority 部分包含一条 NSEC RR 及其关联的 RRSIG RR，以证明区中不存在与 <SNAME, SCLASS> 更接近的匹配。如果空间不允许包含应答、NSEC 与 RRSIG RR，名称服务器必须（MUST）置位 TC 位（参见第 3.1.1 节）。
3.1.3.4. 包含 NSEC RR：通配符无数据响应
这种情况是前述情况的组合。区中不存在与 <SNAME, SCLASS> 完全匹配的项，尽管区中确实存在通过通配符扩展与 <SNAME, SCLASS> 匹配的 RRset，但其中没有与 STYPE 匹配的。名称服务器必须（MUST）在 Authority 部分连同其关联的 RRSIG RR 一起包含下列 NSEC RR：
- 证明在通过通配符扩展匹配 <SNAME, SCLASS> 的通配符 owner name 处，不存在匹配 STYPE 的 RRset 的 NSEC RR。
- 证明区中不存在任何本会成为 <SNAME, SCLASS> 更接近匹配的 RRset 的 NSEC RR。
在某些情况下，单条 NSEC RR 可能同时证明这两点。如果是这样，名称服务器应当（SHOULD）只在 Authority 部分包含该 NSEC RR 及其 RRSIG RR 各一次。
当这些 NSEC 与 RRSIG RR 包含在响应的 Authority 部分时，其 owner name 不适用通配符名称扩展。
如果空间不允许包含这些 NSEC 与 RRSIG RR，名称服务器必须（MUST）置位 TC 位（参见第 3.1.1 节）。
3.1.3.5. 找到正确的 NSEC RR
如上所述，在若干情况下，安全感知权威名称服务器必须找到一条 NSEC RR，以证明不存在与特定 SNAME 匹配的 RRset。在权威区内找到这样一条 NSEC RR 相对简单，至少在概念上是如此。下面的讨论假定名称服务器对原本应持有匹配 SNAME 的不存在 RRset 的区具有权威性。下面的算法是为了清晰而非效率而编写。
为找到证明区 Z 中不存在匹配名称 N 的 RRset 的 NSEC，构造一个序列 S，它由 Z 中每个 RRset 的 owner name 构成，按规范顺序（[RFC4034]）排序，无重复名称。找到名称 M——如果在序列中真的存在以 N 为 owner name 的 RRset，那么 M 将紧排在 N 之前。M 就是证明不存在以 N 为 owner name 的 RRset 的那条 NSEC RR 的 owner name。
用于查找「证明给定名称未被任何适用的通配符覆盖」的 NSEC RR 的算法与之类似，但多一个步骤。更准确地说，用于查找证明「不存在具有适用通配符名称的 RRset」的 NSEC 的算法，与查找证明「不存在具有任何其他 owner name 的 RRset」的 NSEC RR 的算法完全相同。所缺的部分是一种确定不存在之适用通配符名称的方法。实际上这很容易，因为权威名称服务器作为 [RFC1034] 第 4.3.2 节所述正常查找算法步骤 (1)(c) 的一部分，已经检查过恰好这个通配符名称是否存在。
3.1.4. 在响应中包含 DS RR
当响应一个 DO 位已置位的查询时，返回委派（referral）的安全感知权威名称服务器会随 NS RRset 一起包含 DNSSEC 数据。
如果委派点处存在 DS RRset，名称服务器必须（MUST）在 Authority 部分随 NS RRset 一起返回 DS RRset 及其关联的 RRSIG RR。
如果委派点处不存在 DS RRset，名称服务器必须（MUST）随 NS RRset 一起返回证明 DS RRset 不存在的 NSEC RR 以及该 NSEC RR 的关联 RRSIG RR。名称服务器必须（MUST）将 NS RRset 放在 NSEC RRset 及其关联 RRSIG RR 之前。
包含这些 DS、NSEC 与 RRSIG RR 会增加委派报文的大小，并可能导致部分或全部 glue RR 被省略。如果空间不允许包含 DS 或 NSEC RRset 及关联的 RRSIG RR，名称服务器必须（MUST）置位 TC 位（参见第 3.1.1 节）。
3.1.4.1. 响应 DS RR 查询
DS 资源记录类型比较特殊，因为它只出现在区切口的父区一侧。例如，委派 "foo.example" 的 DS RRset 存储在 "example" 区中，而不是存储在 "foo.example" 区中。这要求名称服务器与解析器都采用特殊的处理规则，因为按常规 DNS 规则，子区的名称服务器对区切口处的名称具有权威性，但子区不包含 DS RRset。
安全感知解析器在寻找委派点处所需 DS RR 时，会向父区发送查询（参见第 4.2 节）。但是，为了避免混淆可能参与处理此类查询的安全无感解析器（例如，在网络配置强制安全感知解析器将其查询经由安全无感递归名称服务器转发的情况下），有必要制定特殊规则。本节其余部分描述安全感知名称服务器如何处理 DS 查询以避免此问题。
只有当以下所有条件都满足时，安全感知名称服务器才需要特殊处理：
- 名称服务器收到了对区切口处 DS RRset 的查询。
- 名称服务器对子区具有权威性。
- 名称服务器对父区不具有权威性。
- 名称服务器不提供递归。
在所有其他情况下，名称服务器要么有某种获取 DS RRset 的方法，要么即使按前 DNSSEC 处理规则也不可能指望它持有 DS RRset，因此名称服务器可以按照正常处理规则返回 DS RRset 或错误响应。
不过，如果以上所有条件都满足，则名称服务器对 SNAME 具有权威性，但无法提供所请求的 RRset。在这种情况下，名称服务器必须（MUST）返回权威的「无数据」响应，表明子区区顶点处不存在 DS RRset。此类响应的示例见附录 B.8。
3.1.5. 响应 AXFR 或 IXFR 类型查询
DNSSEC 不改变 DNS 区传送过程。已签名区将包含 RRSIG、DNSKEY、NSEC 与 DS 资源记录，但这些记录相对于区传送操作没有特殊含义。
权威名称服务器在发送或接受区传送之前，不要求验证该区是否已正确签名。但是，如果区不满足第 2 节所述的任何签名要求，权威名称服务器可以（MAY）选择拒绝整个区传送。区传送的主要目标是确保所有权威名称服务器持有完全相同的区副本。选择自行执行区验证的权威名称服务器不得（MUST NOT）选择性拒绝某些 RR 而接受另一些。
DS RRset 只出现在区切口的父侧，是父区中的权威数据。与任何其他权威 RRset 一样，DS RRset必须（MUST）包含在其作为权威数据的区的区传送中。就 DS RRset 而言，这个区是父区。
NSEC RR 在区切口处同时出现在父区与子区中，并且在父区与子区中都是权威数据。区切口处父侧与子侧的 NSEC RR 永远不会彼此相同，因为子区区顶点处的 NSEC RR 将始终表明子区 SOA RR 的存在，而区切口处父侧的 NSEC RR 永远不会表明 SOA RR 的存在。与任何其他权威 RR 一样，NSEC RR必须（MUST）包含在其作为权威数据的区的区传送中。区切口处父侧的 NSEC RR必须（MUST）包含在父区的区传送中，子区区顶点处的 NSEC必须（MUST）包含在子区的区传送中。
RRSIG RR 在区切口处同时出现在父区与子区中，并且在包含该 RRSIG RR 所提供签名的权威 RRset 的那个区中是权威的。也就是说，区切口处 DS RRset 或父侧 NSEC RR 的 RRSIG RR 将在父区中是权威的，而子区区顶点中任何 RRset 的 RRSIG 将在子区中是权威的。区切口处父侧与子侧的 RRSIG RR 永远不会彼此相同，因为子区区顶点中 RRSIG RR 的 Signer's Name 字段将指示子区区顶点中的一条 DNSKEY RR，而区切口处父侧 RRSIG RR 的同一字段将指示父区区顶点中的一条 DNSKEY RR。与任何其他权威 RR 一样，RRSIG RR必须（MUST）包含在其作为权威数据的区的区传送中。
3.1.6. 权威响应中的 AD 与 CD 位
CD 与 AD 位是为在安全感知解析器与安全感知递归名称服务器之间通信而设计的。这些位在很大程度上与安全感知权威名称服务器的查询处理无关。
安全感知名称服务器在查询处理过程中不对权威数据执行签名验证，即使 CD 位被清除也是如此。安全感知名称服务器在构造权威响应时应当（SHOULD）清除 CD 位。
除非名称服务器认为响应中 Answer 与 Authority 部分的所有 RRset 都是真实的（authentic），否则安全感知名称服务器不得（MUST NOT）在响应中置位 AD 位。安全感知名称服务器的本地策略可以（MAY）认为来自权威区的数据无需进一步验证即为真实的。但是，除非名称服务器通过安全手段（例如安全区传送机制）获得权威区，并且已明确配置了此行为，否则名称服务器不得（MUST NOT）如此认为。
支持递归的安全感知名称服务器在生成涉及通过递归获得的数据的响应时，必须（MUST）遵循第 3.2 节给出的 CD 与 AD 位规则。
3.2. 递归名称服务器
如 [RFC4033] 所述，安全感知递归名称服务器是同时以安全感知名称服务器与安全感知解析器两种角色运作的实体。本节使用术语「名称服务器侧」（name server side）与「解析器侧」（resolver side）分别指代安全感知递归名称服务器内实现安全感知名称服务器角色的代码与实现安全感知解析器角色的代码。
解析器侧遵循适用于任何安全感知解析器的常规缓存与消极缓存（negative caching）规则。
3.2.1. DO 位
安全感知递归名称服务器的解析器侧在发送请求时必须（MUST）置位 DO 位，无论名称服务器侧收到的发起请求中 DO 位的状态如何。如果发起查询中的 DO 位未置位，名称服务器侧必须（MUST）从响应中剥离任何认证用 DNSSEC RR，但不得（MUST NOT）剥离发起查询显式请求的任何 DNSSEC RR 类型。
3.2.2. CD 位
CD 位的存在是为了允许安全感知解析器在安全感知名称服务器处理特定查询时禁用签名验证。
名称服务器侧必须（MUST）将查询中 CD 位的设置复制到相应的响应中。
安全感知递归名称服务器的名称服务器侧必须（MUST）把 CD 位的状态连同发起查询的其余部分一起传给解析器侧，以便解析器侧知道它是否需要验证其返回给名称服务器侧的数据。如果 CD 位被置位，则表示发起方解析器愿意执行其本地策略所要求的任何认证。因此，递归名称服务器的解析器侧无需对响应中的 RRset 执行认证。当 CD 位被置位时，即使递归名称服务器的本地认证策略会拒绝这些记录，递归名称服务器应当（SHOULD）在可能的情况下把所请求的数据返回给发起方解析器。也就是说，通过置位 CD 位，发起方解析器已表明它自己负责执行认证，递归名称服务器不应干预。
如果解析器侧实现了 BAD 缓存（见第 4.7 节），且名称服务器侧收到与解析器侧 BAD 缓存中某条目匹配的查询，则名称服务器侧的响应取决于原始查询中 CD 位的状态。如果 CD 位被置位，名称服务器侧应当（SHOULD）从 BAD 缓存返回数据；如果 CD 位未置位，名称服务器侧必须（MUST）返回 RCODE 2（服务器失败）。
上述规则的意图是：为能够自行执行签名验证检查的客户端提供原始数据，同时保护依赖安全感知递归名称服务器解析器侧执行此类检查的客户端。签名验证可能失败的若干可能原因所涉及的条件，可能并不同等地适用于递归名称服务器与调用它的客户端。例如，递归名称服务器的时钟可能设置不正确，或者客户端可能知道递归名称服务器不知道的相关安全孤岛。在这种情况下，「保护」一个能够自行执行签名验证的客户端、使之永远看不到「坏」数据，对客户端并无帮助。
3.2.3. AD 位
除非名称服务器认为响应中 Answer 与 Authority 部分的所有 RRset 都是真实的，否则安全感知递归名称服务器的名称服务器侧不得（MUST NOT）在响应中置位 AD 位。当且仅当解析器侧认为 Answer 部分的所有 RRset 以及 Authority 部分中任何相关的消极响应 RR 都是真实的时，名称服务器侧应当（SHOULD）置位 AD 位。解析器侧必须（MUST）遵循第 5 节所述过程来确定相关 RR 是否真实。不过，为向后兼容，当响应包含未签名的 CNAME RR、且这些 CNAME RR 可以证明是根据 [RFC2672] 所述的合成规则从同样包含在响应中的一条真实 DNAME RR 合成而来时，递归名称服务器可以（MAY）置位 AD 位。
3.3. 示例 DNSSEC 响应
示例响应报文参见附录 B。
4. 解析（Resolving）
本节描述包含安全感知解析器功能的实体的行为。在许多情况下，此类功能将是安全感知递归名称服务器的一部分，但独立的安全感知解析器也有许多相同的要求。特定于安全感知递归名称服务器的功能在第 3.2 节中描述。
4.1. EDNS 支持
安全感知解析器在发送查询时必须（MUST）包含带 DO（[RFC3225]）位置位的 EDNS（[RFC2671]）OPT 伪 RR。
安全感知解析器必须（MUST）支持至少 1220 字节的报文大小，应当（SHOULD）支持 4000 字节的报文大小，并必须（MUST）使用 EDNS OPT 伪 RR 中的「发送方 UDP 负载大小」（sender's UDP payload size）字段通告它愿意接受的报文大小。安全感知解析器的 IP 层必须（MUST）正确处理分片的 UDP 数据包，无论此类分片数据包是通过 IPv4 还是 IPv6 接收的。关于这些要求的讨论，请参阅 [RFC1122]、[RFC2460] 与 [RFC3226]。
4.2. 签名验证支持
安全感知解析器必须（MUST）支持第 5 节所述的签名验证机制，并应当（SHOULD）对收到的每个响应应用这些机制，除非出现以下情况：
- 安全感知解析器是安全感知递归名称服务器的一部分，且该响应是代表一个 CD 位被置位的查询执行递归的结果；
- 该响应是直接通过某种应用接口生成的查询的结果，而该接口指示安全感知解析器不要为此查询执行验证；或
- 本地策略已为此查询禁用验证。
安全感知解析器对签名验证的支持必须（MUST）包括对通配符 owner name 验证的支持。
安全感知解析器可以（MAY）为了执行验证而查询缺失的安全 RR；选择这样做的实现必须意识到，收到的应答可能不足以验证原始响应。例如，区更新可能在原始查询与后续查询之间更改（或删除）了所需信息。
当尝试获取位于区切口父侧、缺失的 NSEC RR 时，安全感知迭代模式解析器必须（MUST）查询父区的名称服务器，而非子区的。
当尝试获取缺失的 DS 时，安全感知迭代模式解析器必须（MUST）查询父区的名称服务器，而非子区的。如第 3.1.4.1 节所述，安全感知名称服务器需要对 DS RR 应用特殊处理规则，而在某些情况下，如果解析器还没有父区的 NS RRset，则可能也需要应用特殊规则来定位父区的名称服务器。为定位父区 NS RRset，解析器可以从委派名称开始，去掉最左侧标签，然后按该名称查询 NS RRset。如果该名称处不存在 NS RRset，解析器再去掉最左侧的剩余标签并重试对该名称的查询，如此沿树向上重复这一过程，直到找到 NS RRset 或用尽所有标签为止。
4.3. 确定数据的安全状态
安全感知解析器必须（MUST）能够确定它是否应当预期特定 RRset 已被签名。更准确地说，安全感知解析器必须能够区分四种情况：
安全（Secure）：解析器能够从受信任的安全锚到该 RRset 建立一条已签名 DNSKEY 与 DS RR 链的 RRset。在这种情况下，该 RRset 应当已被签名，并且如上所述应受签名验证的约束。
不安全（Insecure）：解析器知道它无法从任何受信任起点到该 RRset 建立已签名 DNSKEY 与 DS RR 链的 RRset。当目标 RRset 位于未签名区或未签名区的后代中时，就会发生这种情况。在这种情况下，该 RRset 可能已签名也可能未签名，但解析器将无法验证签名。
伪造（Bogus）：解析器认为它应当能够建立信任链、却因某种原因无法建立的 RRset——要么因为签名出于某种原因无法验证，要么因为相关 DNSSEC RR 表明应当存在的数据缺失。这种情况可能表明受到了攻击，但也可能表明配置错误或某种形式的数据损坏。
不确定（Indeterminate）：解析器无法确定该 RRset 是否应当已被签名的 RRset，因为解析器无法获取必要的 DNSSEC RR。当安全感知解析器无法联系相关区的安全感知名称服务器时，就会发生这种情况。
4.4. 已配置的信任锚
安全感知解析器必须（MUST）能够配置至少一把受信任的公钥或一条 DS RR，并应当（SHOULD）能够配置多把受信任的公钥或多条 DS RR。由于没有这样的已配置信任锚，安全感知解析器将无法验证签名，因此解析器应当（SHOULD）在启动时具备某种相当稳健的机制来获取此类密钥；此类机制的示例是某种形式的非易失性存储（如磁盘驱动器）或某种受信任的本地网络配置机制。
请注意，信任锚也涵盖以安全方式更新的密钥材料。这种安全方式可以是通过物理介质、密钥交换协议或其他某种带外手段。
4.5. 响应缓存
安全感知解析器应当（SHOULD）将每个响应缓存为包含整个应答（包括命名的 RRset 及任何关联的 DNSSEC RR）的单个原子条目。当其中任何 RR 过期时，解析器应当（SHOULD）丢弃整个原子条目。在大多数情况下，原子条目的适当缓存索引将是三元组 <QNAME, QTYPE, QCLASS>，但在诸如第 3.1.3.2 节所述响应形式的情况下，适当的缓存索引将是二元组 <QNAME, QCLASS>。
这些建议的原因是：在初始查询与数据从缓存中过期之间，权威数据可能已被更改（例如，通过动态更新）。
与此相关有两种情况：
- 通过使用 RRSIG 记录，可以推断出某个应答是从通配符合成的。安全感知递归名称服务器可以存储此通配符数据，并利用它为原始应答首次收到的名称之外的查询生成肯定响应。
- 为证明名称不存在而收到的 NSEC RR，可被安全感知解析器重复使用，以证明其覆盖的名称范围内任何名称的不存在。
理论上，解析器可以使用通配符或 NSEC RR 分别生成肯定与否定响应，直到相关记录的 TTL 或签名过期。但是，解析器避免阻止新的权威数据或自行合成新数据似乎是明智的。遵循这一建议的解析器将对名称空间拥有更一致的视图。
4.6. CD 与 AD 位的处理
安全感知解析器可以（MAY）置位查询的 CD 位，以表明解析器负责对响应中 RRset 执行其本地策略所要求的任何认证。该位对安全感知递归名称服务器行为的影响参见第 3.2 节。
安全感知解析器在构造查询报文时必须（MUST）清除 AD 位，以防那些盲目把不理解的头位从查询报文复制到响应报文的有缺陷名称服务器。
解析器必须（MUST）无视响应中 CD 与 AD 位的含义，除非该响应是通过安全信道获得的，或者解析器被专门配置为在不使用安全信道的情况下也考虑报文头位。
4.7. 缓存 BAD 数据
虽然许多验证错误是暂时的，但有些可能更持久，例如由管理错误（未能重新签署区、时钟偏差等）导致的错误。由于在这些情况下重新查询无济于事，验证型解析器可能会因反复查询验证持续失败的 RRset 而产生大量不必要的 DNS 流量。
为防止这种不必要的 DNS 流量，安全感知解析器可以（MAY）在有一些限制的条件下缓存签名无效的数据。
从概念上讲，缓存此类数据类似于消极缓存（[RFC2308]），只不过解析器缓存的不是有效的否定响应，而是某个特定应答未能通过验证这一事实。本文档将签名无效的数据缓存称为「BAD 缓存」。
实现 BAD 缓存的解析器必须（MUST）采取措施防止该缓存被用作拒绝服务攻击放大器，特别是以下几点：
- 由于未能通过验证的 RRset 没有可信的 TTL，实现必须（MUST）为其指定一个 TTL。该 TTL应当（SHOULD）较小，以减轻缓存攻击结果的影响。
- 为防止缓存暂时性的验证失败（可能是攻击的结果），解析器应当（SHOULD）跟踪导致验证失败的查询，并且应当（SHOULD）仅在针对该特定 <QNAME, QTYPE, QCLASS> 的查询响应未能通过验证的次数超过阈值之后，才从 BAD 缓存应答。
除非解析器按照本文档第 4.2 节给出的规则，不要求验证相关 RRset 的签名，否则解析器不得（MUST NOT）从 BAD 缓存返回 RRset。关于安全感知递归名称服务器返回的响应如何与 BAD 缓存交互的讨论，参见第 3.2.2 节。
4.8. 合成的 CNAME
验证型安全感知解析器必须（MUST）把一条有效已签名 DNAME RR 的签名视为同样覆盖可根据该 DNAME RR 合成的未签名 CNAME RR（如 [RFC2672] 所述），至少在不得仅因响应包含此类 CNAME RR 而拒绝该响应报文的程度上如此。解析器可以（MAY）在其缓存中或返回给应用程序的应答中保留此类 CNAME RR，但没有必要这样做。
4.9. 存根解析器
安全感知存根解析器必须（MUST）支持 DNSSEC RR 类型，至少在不得仅仅因为响应包含 DNSSEC RR 而错误处理响应的程度上如此。
4.9.1. DO 位的处理
非验证型安全感知存根解析器可以（MAY）把安全感知递归名称服务器返回的 DNSSEC RR 作为存根解析器交还给调用它的应用程序的数据的一部分，但没有必要这样做。寻求这样做的非验证型存根解析器需要置位 DO 位，以便从递归名称服务器接收 DNSSEC RR。
验证型安全感知存根解析器必须（MUST）置位 DO 位，因为否则它将无法收到执行签名验证所需的 DNSSEC RR。
4.9.2. CD 位的处理
非验证型安全感知存根解析器在发送查询时不应（SHOULD NOT）置位 CD 位，除非应用程序层要求这样做，因为按定义，非验证型存根解析器依赖安全感知递归名称服务器代为执行验证。
验证型安全感知存根解析器应当（SHOULD）置位 CD 位，因为否则安全感知递归名称服务器将使用名称服务器的本地策略来应答查询，而这可能阻止存根解析器收到按其自身本地策略本可接受的数据。
4.9.3. AD 位的处理
非验证型安全感知存根解析器可以（MAY）选择检查其收到的响应报文中 AD 位的设置，以确定发送响应的安全感知递归名称服务器是否声称已对响应报文 Answer 与 Authority 部分中的数据进行了密码学验证。但请注意，安全感知存根解析器收到的响应在很大程度上取决于安全感知递归名称服务器的本地策略。因此，检查 AD 位的状态可能没有多少实际价值，除非作为调试辅助手段。在任何情况下，安全感知存根解析器不得（MUST NOT）依赖据称代为执行的签名验证，除非安全感知存根解析器通过安全信道从受信任的安全感知递归名称服务器获得了相关数据。
验证型安全感知存根解析器不应（SHOULD NOT）检查响应报文中 AD 位的设置，因为按定义，无论 AD 位如何设置，存根解析器都会自行执行签名验证。
5. 认证 DNS 响应（Authenticating DNS Responses）
要使用 DNSSEC RR 进行认证，安全感知解析器需要配置性地了解至少一条已认证的 DNSKEY 或 DS RR。获取并认证这个初始信任锚的过程通过某种外部机制完成。例如，解析器可以使用某种离线的已认证交换来获取区的 DNSKEY RR，或获取一条标识并认证区 DNSKEY RR 的 DS RR。本节其余部分假定解析器已以某种方式获得了初始信任锚集合。
一条初始 DNSKEY RR 可用于认证区的区顶点 DNSKEY RRset。要使用初始密钥认证区顶点 DNSKEY RRset，解析器必须（MUST）：
- 验证该初始 DNSKEY RR 出现在区顶点 DNSKEY RRset 中，且该 DNSKEY RR 具有 Zone Key 标志（DNSKEY RDATA 第 7 位）置位；且
- 验证存在某条覆盖区顶点 DNSKEY RRset 的 RRSIG RR，且该 RRSIG RR 与初始 DNSKEY RR 的组合认证了该 DNSKEY RRset。使用 RRSIG RR 认证 RRset 的过程在第 5.3 节中描述。
一旦解析器使用初始 DNSKEY RR 认证了区顶点 DNSKEY RRset，就可以使用 DS RR 认证来自该区的委派。这允许解析器从初始密钥出发，使用 DS RRset 沿 DNS 树递归下行，获取其他区顶点 DNSKEY RRset。如果解析器配置了根 DNSKEY RR，并且每个委派都关联一条 DS RR，那么解析器就可以获取并验证任何区顶点 DNSKEY RRset。使用 DS RR 认证委派的过程在第 5.2 节中描述。
第 5.3 节展示了在解析器认证了区的区顶点 DNSKEY RRset 之后，解析器如何利用区顶点 DNSKEY RRset 中的 DNSKEY RR 与区中的 RRSIG RR 来认证区中任何其他 RRset。第 5.4 节展示了解析器如何利用区中经认证的 NSEC RRset 来证明某个 RRset 不在区中。
当解析器表明支持 DNSSEC（通过置位 DO 位）时，安全感知名称服务器应尝试在响应中提供必要的 DNSKEY、RRSIG、NSEC 与 DS RRset（参见第 3 节）。但是，安全感知解析器仍可能收到缺少适当 DNSSEC RR 的响应，无论是因为诸如上游安全无感递归名称服务器意外干扰 DNSSEC RR 之类的配置问题，还是因为对手伪造响应、从响应中剥离 DNSSEC RR 或修改查询使 DNSSEC RR 显得未被请求的蓄意攻击。响应中缺少 DNSSEC 数据本身不得（MUST NOT）被当作不存在认证信息的迹象。
解析器应当（SHOULD）预期来自已签名区的认证信息。如果解析器配置了该区的公钥信息，或者该区的父区已签名且来自父区的委派包含 DS RRset，则解析器应当（SHOULD）相信该区已签名。
5.1. 安全孤岛的特殊考虑
安全孤岛（参见 [RFC4033]）是这样一些已签名区：无法从其父区为该区构造通向该区的认证链。验证安全孤岛内的签名要求验证器有某种其他手段为该孤岛获取一条初始的已认证区密钥。如果验证器无法获得这样的密钥，它应当（SHOULD）改为按照仿佛安全孤岛中的区是未签名区的方式来运作。
所有正常的响应验证过程都适用于安全孤岛。正常验证与安全孤岛内验证的唯一区别在于验证器如何为认证链获取信任锚。
5.2. 认证委派
一旦已签名父区的区顶点 DNSKEY RRset 被认证，就可以使用 DS RRset 来认证通向已签名子区的委派。一条 DS RR 标识子区区顶点 DNSKEY RRset 中的一条 DNSKEY RR，并包含子区 DNSKEY RR 的密码学摘要。使用强密码学摘要算法可确保对手在计算上无法生成与摘要匹配的 DNSKEY RR。因此，认证摘要使解析器能够认证匹配的 DNSKEY RR。然后解析器可以使用该子区 DNSKEY RR 认证整个子区区顶点 DNSKEY RRset。
给定委派的 DS RR，如果以下所有条件都成立，则可认证子区的区顶点 DNSKEY RRset：
- 该 DS RR 已使用父区区顶点 DNSKEY RRset 中的某条 DNSKEY RR 认证（参见第 5.3 节）。
- DS RR 中的 Algorithm 与 Key Tag 匹配子区区顶点 DNSKEY RRset 中某条 DNSKEY RR 的 Algorithm 字段与密钥标签，并且当使用 DS RR 的 Digest Type 字段所指定的摘要算法对该 DNSKEY RR 的 owner name 与 RDATA 进行散列时，所得摘要值与 DS RR 的 Digest 字段匹配。
- 子区中匹配的 DNSKEY RR 具有 Zone 标志位置位，相应私钥已签署子区的区顶点 DNSKEY RRset，且所得 RRSIG RR 认证了子区的区顶点 DNSKEY RRset。
如果来自父区的委派不包含 DS RRset，则响应本应包含一条已签名的 NSEC RRset，证明被委派名称不存在 DS RRset（参见第 3.1.4 节）。如果委派既不包含 DS RRset，也不包含证明 DS RRset 不存在的 NSEC RRset，则安全感知解析器必须（MUST）查询父区的名称服务器以获取 DS RRset（参见第 4 节）。
如果验证器认证了一条证明本区不存在 DS RRset 的 NSEC RRset，那么就不存在从父区通向子区的认证路径。如果解析器拥有一条属于子区或子区以下任何委派的初始 DNSKEY 或 DS RR，则可以使用这条初始 DNSKEY 或 DS RR 重新建立认证路径。如果不存在这样的初始 DNSKEY 或 DS RR，验证器就无法认证子区中或子区以下的 RRset。
如果验证器不支持经认证 DS RRset 中列出的任何算法，则解析器没有从父区通向子区的受支持认证路径。解析器应当将此情况与上文所述的「经认证 NSEC RRset 证明不存在 DS RRset」的情况同等对待。
请注意，对于已签名委派，存在两条与被委派名称关联的 NSEC RR。一条 NSEC RR 位于父区，可用于证明被委派名称是否存在 DS RRset。第二条 NSEC RR 位于子区，标识子区区顶点处存在哪些 RRset。父侧 NSEC RR 与子侧 NSEC RR 始终可以区分，因为子侧 NSEC RR 的 SOA 位将被置位，而父侧 NSEC RR 的 SOA 位将被清除。安全感知解析器在尝试证明 DS RRset 不存在时必须（MUST）使用父侧 NSEC RR。
如果解析器不支持经认证 DS RRset 中列出的任何算法，则解析器将无法验证通向子区的认证路径。在这种情况下，解析器应当（SHOULD）把该子区当作未签名区对待。
5.3. 使用 RRSIG RR 认证 RRset
验证器可以使用 RRSIG RR 及其对应的 DNSKEY RR 尝试认证 RRset。验证器首先检查 RRSIG RR，以验证它覆盖该 RRset、具有有效的时间区间并标识一条有效的 DNSKEY RR。然后验证器通过把 RRSIG RDATA（不含 Signature 字段）与被覆盖 RRset 的规范形式（canonical form）相连接来构造已签名数据的规范形式。最后，验证器使用公钥与签名来认证已签名数据。第 5.3.1、5.3.2 与 5.3.3 节详细描述了每一步。
5.3.1. 检查 RRSIG RR 的有效性
如果以下所有条件都成立，安全感知解析器可以使用 RRSIG RR 来认证 RRset：
- RRSIG RR 与 RRset 必须（MUST）具有相同的 owner name 与相同的类。
- RRSIG RR 的 Signer's Name 字段必须（MUST）是包含该 RRset 的区的名称。
- RRSIG RR 的 Type Covered 字段必须（MUST）等于该 RRset 的类型。
- RRset owner name 中的标签数必须（MUST）大于或等于 RRSIG RR 的 Labels 字段中的值。
- 验证器对当前时间的判定必须（MUST）小于或等于 RRSIG RR 的 Expiration 字段中列出的时间。
- 验证器对当前时间的判定必须（MUST）大于或等于 RRSIG RR 的 Inception 字段中列出的时间。
- RRSIG RR 的 Signer's Name、Algorithm 与 Key Tag 字段必须（MUST）与区顶点 DNSKEY RRset 中某条 DNSKEY RR 的 owner name、算法与密钥标签匹配。
- 匹配的 DNSKEY RR 必须（MUST）存在于区顶点 DNSKEY RRset 中，且必须（MUST）具有 Zone 标志位（DNSKEY RDATA 第 7 位）置位。
可能有多条 DNSKEY RR 满足上述条件。在这种情况下，验证器无法预先确定使用哪条 DNSKEY RR 来认证签名，它必须（MUST）依次尝试每条匹配的 DNSKEY RR，直到签名被验证或验证器用完所有可尝试的匹配公钥为止。
请注意，只有在验证器使用 DNSKEY RR 验证签名之前先认证它，这个认证过程才有意义。在以下情况下，匹配的 DNSKEY RR 被认为是真实的：
- 包含该 DNSKEY RR 的区顶点 DNSKEY RRset 被认为是真实的；或
- RRSIG RR 覆盖的 RRset 就是区顶点 DNSKEY RRset 本身，且该 DNSKEY RR 要么匹配来自父区的一条已认证 DS RR，要么匹配一条信任锚。
5.3.2. 重建已签名数据
一旦 RRSIG RR 满足了第 5.3.1 节所述的有效性要求，验证器就必须重建原始已签名数据。原始已签名数据包括 RRSIG RDATA（不含 Signature 字段）与 RRset 的规范形式。除了按序排列之外，RRset 的规范形式还可能因 DNS 名称压缩、TTL 递减或通配符扩展而与收到的 RRset 不同。验证器应使用以下方法重建原始已签名数据：
signed_data = RRSIG_RDATA | RR(1) | RR(2)... where
"|" denotes concatenation
RRSIG_RDATA is the wire format of the RRSIG RDATA fields
with the Signature field excluded and the Signer's Name
in canonical form.
RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
name is calculated according to the function below
class is the RRset's class
type is the RRset type and all RRs in the class
OrigTTL is the value from the RRSIG Original TTL field
All names in the RDATA field are in canonical form
The set of all RR(i) is sorted into canonical order.
To calculate the name:
let rrsig_labels = the value of the RRSIG Labels field
let fqdn = RRset's fully qualified domain name in
canonical form
let fqdn_labels = Label count of the fqdn above.
if rrsig_labels = fqdn_labels,
name = fqdn
if rrsig_labels < fqdn_labels,
name = "*." | the rightmost rrsig_label labels of the
fqdn
if rrsig_labels > fqdn_labels
the RRSIG RR did not pass the necessary validation
checks and MUST NOT be used to authenticate this
RRset.
名称与 RRset 的规范形式在 [RFC4034] 中定义。
委派边界处的 NSEC RRset 需要特殊处理。与已签名被委派名称关联的 NSEC RRset 有两种。一种 NSEC RRset 位于父区，指明父区中存在哪些 RRset。第二种 NSEC RRset 位于子区，标识子区区顶点处存在哪些 RRset。父侧 NSEC RRset 与子侧 NSEC RRset 始终可以区分，因为只有子侧 NSEC RR 才会表明该名称处存在 SOA RRset。在从父区重建委派的原始 NSEC RRset 时，不得（MUST NOT）把 NSEC RR 与来自子区的 NSEC RR 合并。在重建子区区顶点的原始 NSEC RRset 时，不得（MUST NOT）把 NSEC RR 与来自父区的 NSEC RR 合并。
请注意，委派点处的两个 NSEC RRset 各有一条相应的 RRSIG RR，其 owner name 与被委派名称匹配，并且这些 RRSIG RR 各自是与相应 NSEC RRset 所在区关联的权威数据。如有必要，解析器可以通过检查 Signer's Name 字段来区分这些 RRSIG RR。
5.3.3. 检查签名
一旦解析器按照第 5.3.1 节所述验证了 RRSIG RR，并按照第 5.3.2 节所述重建了原始已签名数据，验证器就可以尝试使用密码学签名来认证已签名数据，从而（终于！）认证该 RRset。
RRSIG RR 中的 Algorithm 字段标识用于生成签名的密码学算法。签名本身包含在 RRSIG RDATA 的 Signature 字段中，用于验证签名的公钥包含在匹配的 DNSKEY RR（在第 5.3.1 节中找到）的 Public Key 字段中。[RFC4034] 提供了一份算法类型列表，并提供指向定义每种算法用法的文档的指针。
请注意，可能有多条 DNSKEY RR 匹配第 5.3.1 节的条件。在这种情况下，验证器只能通过依次尝试每条匹配的公钥来确定哪条 DNSKEY RR 是正确的，直到验证器成功验证签名或用完所有可尝试的密钥为止。
如果 RRSIG RR 的 Labels 字段不等于 RRset 完全限定 owner name 中的标签数，则该 RRset 要么无效，要么是通配符扩展的结果。在认为 RRset 是真实的之前，解析器必须（MUST）验证通配符扩展已被正确应用。第 5.3.4 节描述了如何确定通配符是否被正确应用。
如果其他 RRSIG RR 也覆盖此 RRset，则本地解析器安全策略决定解析器是否还必须测试这些 RRSIG RR，以及在这些 RRSIG RR 导致不同结果时如何解决冲突。
如果解析器接受该 RRset 为真实的，则验证器必须（MUST）将 RRSIG RR 与已认证 RRset 中每条 RR 的 TTL 设置为不大于以下各项最小值的值：
- 响应中收到的 RRset 的 TTL；
- 响应中收到的 RRSIG RR 的 TTL；
- RRSIG RR 的 Original TTL 字段中的值；以及
- RRSIG RR 的 Signature Expiration 时间与当前时间之差。
5.3.4. 认证通配符扩展 RRset 的肯定响应
如果 RRset owner name 中的标签数大于覆盖 RRSIG RR 的 Labels 字段，则该 RRset 及其覆盖 RRSIG RR 是通配符扩展的结果。一旦验证器按照第 5.3 节所述验证了签名，它就必须采取额外步骤来验证查询不存在精确匹配或更接近的通配符匹配。第 5.4 节讨论了这些步骤。
请注意，解析器收到的响应应包含认证该响应所需的所有 NSEC RR（参见第 3.1.3 节）。
5.4. 经认证的不存在证明
解析器可以使用经认证的 NSEC RR 来证明某个 RRset 不在已签名区中。安全感知名称服务器应在其对安全感知解析器的响应中自动包含已签名区所需的一切 NSEC RR。
不存在证明由下列规则确定：
- 如果所请求的 RR 名称与某条经认证 NSEC RR 的 owner name 匹配，则该 NSEC RR 的类型位图字段列出该 owner name 处存在的所有 RR 类型，解析器可以通过在位图中检查该 RR 类型来证明所请求的 RR 类型不存在。如果经认证 NSEC RR 的 owner name 中的标签数等于覆盖 RRSIG RR 的 Labels 字段，则该 NSEC RR 的存在证明不可能使用通配符扩展来匹配该请求。
- 如果所请求的 RR 名称按照 [RFC4034] 定义的规范 DNS 名称顺序，会出现在某条经认证 NSEC RR 的 owner name 之后、该 NSEC RR 的 Next Domain Name 字段所列名称之前，则区中不存在以该请求名称命名的 RRset。但是，通配符仍有可能被用来匹配所请求的 RR owner name 与类型，因此证明所请求 RRset 不存在还需要证明不存在任何本可用于生成肯定响应的可能的通配符 RRset。
此外，安全感知解析器必须（MUST）按照第 5.3 节所述认证构成不存在证明的 NSEC RRset。
为证明 RRset 不存在，解析器必须能够验证被查询的 RRset 不存在，并且不存在任何相关的通配符 RRset。证明这一点可能需要区中的不止一个 NSEC RRset。如果响应中不存在完整的一组必要 NSEC RRset（也许因为报文被截断），则安全感知解析器必须（MUST）重新发送查询，以尝试获取验证所请求 RRset 不存在所需的全套 NSEC RR。不过，与所有 DNS 操作一样，解析器必须（MUST）限制其为回答任何特定查询所投入的工作量。
由于一条已验证的 NSEC RR 证明其自身及其相应 RRSIG RR 的存在，验证器必须（MUST）忽略 NSEC RR 中 NSEC 与 RRSIG 位的设置。
5.5. 签名无法验证时解析器的行为
如果出于某种原因没有任何 RRSIG 能被验证，则该响应应当（SHOULD）被视为 BAD。如果执行验证是为了服务一个递归查询，名称服务器必须（MUST）向发起方客户端返回 RCODE 2。但是，当且仅当原始查询的 CD 位被置位时，它必须（MUST）返回完整响应。另请参见第 4.7 节关于缓存无法验证的响应的内容。
5.6. 认证示例
附录 C 展示了认证过程的示例。
6. IANA 考虑
[RFC4034] 包含对 DNSSEC 所引入 IANA 考虑的审查。以下是本文档讨论的额外 IANA 考虑：
[RFC2535] 在报文头中保留了 CD 与 AD 位。[RFC3655] 重新定义了 AD 位的含义，本文档则重申了 CD 与 AD 位两者的含义。本文档未在 DNS 报文头中定义任何新位。
[RFC2671] 引入了 EDNS，[RFC3225] 保留了 DNSSEC OK 位并定义其用途。本文档重申但未改变其用途。
7. 安全考虑
本文档描述了 DNS 安全扩展如何使用公钥密码学来签名与认证 DNS 资源记录集。关于与 DNSSEC 相关的术语与一般安全考虑，请参阅 [RFC4033]；关于特定于 DNSSEC 资源记录类型的考虑，请参阅 [RFC4034]。
能够在 DNS 查询报文中置位 CD 位、或在 DNS 响应报文中置位 AD 位的主动攻击者，可以利用这些位来破坏 DNSSEC 试图为安全无感递归模式解析器提供的保护。因此，安全感知递归模式解析器使用这些控制位需要安全信道。进一步讨论见第 3.2.2 与 4.9 节。
本文档描述的协议试图把 DNSSEC 的好处扩展到安全无感存根解析器。但是，由于从验证失败中恢复可能特定于具体应用，DNSSEC 为存根解析器提供的设施可能证明并不充分。安全感知递归名称服务器的运营者在选择本地验证策略时，必须密切关注使用其服务的应用程序的行为；否则很容易导致递归名称服务器意外地拒绝向本应支持它的客户端提供服务。
8. 致谢
本文档由 DNS 扩展工作组成员及工作组邮件列表的意见与想法汇集而成。编辑们对在修订这些安全扩展规范期间收到的评论与建议表示感谢。虽然要明确列出 DNSSEC 十年发展历程中的每一位贡献者是不可能的，但 [RFC4033] 包含了一份曾善意评论这些文档的部分参与者名单。
9. 参考文献
9.1. 规范性参考文献
- [RFC1034] Mockapetris, P., 《域名——概念与设施》, STD 13, RFC 1034, 1987 年 11 月。rfc-editor.org/rfc/rfc1034
- [RFC1035] Mockapetris, P., 《域名——实现与规范》, STD 13, RFC 1035, 1987 年 11 月。rfc-editor.org/rfc/rfc1035
- [RFC1122] Braden, R., 《Internet 主机要求——通信层》, STD 3, RFC 1122, 1989 年 10 月。rfc-editor.org/rfc/rfc1122
- [RFC2119] Bradner, S., 《用于在 RFC 中指示需求等级的关键词》, BCP 14, RFC 2119, 1997 年 3 月。rfc-editor.org/rfc/rfc2119
- [RFC2181] Elz, R. 与 R. Bush, 《对 DNS 规范的澄清》, RFC 2181, 1997 年 7 月。rfc-editor.org/rfc/rfc2181
- [RFC2460] Deering, S. 与 R. Hinden, 《Internet 协议第六版（IPv6）规范》, RFC 2460, 1998 年 12 月。rfc-editor.org/rfc/rfc2460
- [RFC2671] Vixie, P., 《DNS 的扩展机制（EDNS0）》, RFC 2671, 1999 年 8 月。rfc-editor.org/rfc/rfc2671
- [RFC2672] Crawford, M., 《非终端 DNS 名称重定向》, RFC 2672, 1999 年 8 月。rfc-editor.org/rfc/rfc2672
- [RFC3225] Conrad, D., 《表明解析器支持 DNSSEC》, RFC 3225, 2001 年 12 月。rfc-editor.org/rfc/rfc3225
- [RFC3226] Gudmundsson, O., 《DNSSEC 与 IPv6 A6 感知服务器/解析器的报文大小要求》, RFC 3226, 2001 年 12 月。rfc-editor.org/rfc/rfc3226
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., 与 S. Rose, 《DNS 安全扩展：引言与需求》, RFC 4033, 2005 年 3 月。rfc-editor.org/rfc/rfc4033
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., 与 S. Rose, 《DNS 安全扩展的资源记录》, RFC 4034, 2005 年 3 月。rfc-editor.org/rfc/rfc4034
9.2. 资料性参考文献
- [RFC2308] Andrews, M., 《DNS 查询的消极缓存（DNS NCACHE）》, RFC 2308, 1998 年 3 月。rfc-editor.org/rfc/rfc2308
- [RFC2535] Eastlake 3rd, D., 《域名系统安全扩展》, RFC 2535, 1999 年 3 月。rfc-editor.org/rfc/rfc2535
- [RFC3007] Wellington, B., 《安全域名系统（DNS）动态更新》, RFC 3007, 2000 年 11 月。rfc-editor.org/rfc/rfc3007
- [RFC3655] Wellington, B. 与 O. Gudmundsson, 《对 DNS 已认证数据（AD）位的重新定义》, RFC 3655, 2003 年 11 月。rfc-editor.org/rfc/rfc3655
附录 A. 已签名区示例
以下示例展示了一个（小型）完整的已签名区。
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1081539377
3600
300
3600000
3600
)
3600 RRSIG SOA 5 1 3600 20040509183619 (
20040409183619 38519 example.
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
jV7j86HyQgM5e7+miRAz8V01b0I= )
3600 NS ns1.example.
3600 NS ns2.example.
3600 RRSIG NS 5 1 3600 20040509183619 (
20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg= )
3600 MX 1 xx.example.
3600 RRSIG MX 5 1 3600 20040509183619 (
20040409183619 38519 example.
HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB
2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE
VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO
6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM
W6OISukd1EQt7a0kygkg+PEDxdI= )
3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
3600 RRSIG NSEC 5 1 3600 20040509183619 (
20040409183619 38519 example.
O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
jfFJ5arXf4nPxp/kEowGgBRzY/U= )
3600 DNSKEY 256 3 5 (
AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
)
3600 DNSKEY 257 3 5 (
AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
)
3600 RRSIG DNSKEY 5 1 3600 20040509183619 (
20040409183619 9465 example.
ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
3600 RRSIG DNSKEY 5 1 3600 20040509183619 (
20040409183619 38519 example.
eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
7z5OXogYVaFzHKillDt3HRxHIZM= )
a.example. 3600 IN NS ns1.a.example.
3600 IN NS ns2.a.example.
3600 DS 57855 5 1 (
B6DCD485719ADCA18E5F3D48A2331627FDD3
636B )
3600 RRSIG DS 5 2 3600 20040509183619 (
20040409183619 38519 example.
oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
3600 NSEC ai.example. NS DS RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba
U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2
039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I
BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g
sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )
ns1.a.example. 3600 IN A 192.0.2.5
ns2.a.example. 3600 IN A 192.0.2.6
ai.example. 3600 IN A 192.0.2.9
3600 RRSIG A 5 2 3600 20040509183619 (
20040409183619 38519 example.
pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
3600 HINFO "KLH-10" "ITS"
3600 RRSIG HINFO 5 2 3600 20040509183619 (
20040409183619 38519 example.
Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
3600 AAAA 2001:db8::f00:baa9
3600 RRSIG AAAA 5 2 3600 20040509183619 (
20040409183619 38519 example.
nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
sZM6QjBBLmukH30+w1z3h8PUP2o= )
3600 NSEC b.example. A HINFO AAAA RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
AhS+JOVfDI/79QtyTI0SaDWcg8U= )
b.example. 3600 IN NS ns1.b.example.
3600 IN NS ns2.b.example.
3600 NSEC ns1.example. NS RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
vhRXgWT7OuFXldoCG6TfVFMs9xE= )
ns1.b.example. 3600 IN A 192.0.2.7
ns2.b.example. 3600 IN A 192.0.2.8
ns1.example. 3600 IN A 192.0.2.1
3600 RRSIG A 5 2 3600 20040509183619 (
20040409183619 38519 example.
F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
v/iVXSYC0b7mPSU+EOlknFpVECs= )
3600 NSEC ns2.example. A RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
ns2.example. 3600 IN A 192.0.2.2
3600 RRSIG A 5 2 3600 20040509183619 (
20040409183619 38519 example.
V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
3600 NSEC *.w.example. A RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE
VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb
3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH
l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw
Ymx28EtgIpo9A0qmP08rMBqs1Jw= )
*.w.example. 3600 IN MX 1 ai.example.
3600 RRSIG MX 5 2 3600 20040509183619 (
20040409183619 38519 example.
OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
4kX18MMR34i8lC36SR5xBni8vHI= )
3600 NSEC x.w.example. MX RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
s1InQ2UoIv6tJEaaKkP701j8OLA= )
x.w.example. 3600 IN MX 1 xx.example.
3600 RRSIG MX 5 3 3600 20040509183619 (
20040409183619 38519 example.
Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
3600 NSEC x.y.w.example. MX RRSIG NSEC
3600 RRSIG NSEC 5 3 3600 20040509183619 (
20040409183619 38519 example.
aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
IjgiM8PXkBQtxPq37wDKALkyn7Q= )
x.y.w.example. 3600 IN MX 1 xx.example.
3600 RRSIG MX 5 4 3600 20040509183619 (
20040409183619 38519 example.
k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia
t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj
q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq
GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb
+gLcMZBnHJ326nb/TOOmrqNmQQE= )
3600 NSEC xx.example. MX RRSIG NSEC
3600 RRSIG NSEC 5 4 3600 20040509183619 (
20040409183619 38519 example.
OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
xx.example. 3600 IN A 192.0.2.10
3600 RRSIG A 5 2 3600 20040509183619 (
20040409183619 38519 example.
kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
kbIDV6GPPSZVusnZU6OMgdgzHV4= )
3600 HINFO "KLH-10" "TOPS-20"
3600 RRSIG HINFO 5 2 3600 20040509183619 (
20040409183619 38519 example.
GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0
t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq
BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8
3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+
RgNvuwbioFSEuv2pNlkq0goYxNY= )
3600 AAAA 2001:db8::f00:baaa
3600 RRSIG AAAA 5 2 3600 20040509183619 (
20040409183619 38519 example.
Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
xS9cL2QgW7FChw16mzlkH6/vsfs= )
3600 NSEC example. A HINFO AAAA RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY
9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k
mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi
asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W
GghLahumFIpg4MO3LS/prgzVVWo= )
区顶点 DNSKEY 集合包含两条 DNSKEY RR，DNSKEY RDATA 的 Flags 表明这两条 DNSKEY RR 都是区密钥。其中一条 DNSKEY RR 还置位了 SEP 标志，并已用于签署区顶点 DNSKEY RRset；这把密钥正是应被散列以生成插入父区的 DS 记录的密钥。另一条 DNSKEY 用于签署区中所有其他 RRset。
该区包含一个通配符条目 "*.w.example"。请注意，名称 "*.w.example" 被用于构造 NSEC 链，且覆盖 "*.w.example" MX RRset 的 RRSIG 的标签计数为 2。
该区还包含两个委派。对 "b.example" 的委派包含一条 NS RRset、glue 地址记录与一条 NSEC RR；请注意只有 NSEC RRset 被签名。对 "a.example" 的委派提供了一条 DS RR；请注意只有 NSEC 与 DS RRset 被签名。
附录 B. 示例响应
本节中的示例展示了使用附录 A 中已签名区示例的响应报文。
B.1. 应答
对权威服务器的成功查询。
;; Header: QR AA DO RCODE=0
;;
;; Question
x.w.example. IN MX
;; Answer
x.w.example. 3600 IN MX 1 xx.example.
x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 (
20040409183619 38519 example.
Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
;; Authority
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
example. 3600 RRSIG NS 5 1 3600 20040509183619 (
20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg= )
;; Additional
xx.example. 3600 IN A 192.0.2.10
xx.example. 3600 RRSIG A 5 2 3600 20040509183619 (
20040409183619 38519 example.
kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
kbIDV6GPPSZVusnZU6OMgdgzHV4= )
xx.example. 3600 AAAA 2001:db8::f00:baaa
xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
20040409183619 38519 example.
Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
xS9cL2QgW7FChw16mzlkH6/vsfs= )
ns1.example. 3600 IN A 192.0.2.1
ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 (
20040409183619 38519 example.
F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
v/iVXSYC0b7mPSU+EOlknFpVECs= )
ns2.example. 3600 IN A 192.0.2.2
ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 (
20040409183619 38519 example.
V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
B.2. 名称错误
权威的名称错误。NSEC RR 证明该名称不存在，且不存在覆盖它的通配符。
;; Header: QR AA DO RCODE=3
;;
;; Question
ml.example. IN A
;; Answer
;; (empty)
;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1081539377
3600
300
3600000
3600
)
example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
20040409183619 38519 example.
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
jV7j86HyQgM5e7+miRAz8V01b0I= )
b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
vhRXgWT7OuFXldoCG6TfVFMs9xE= )
example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
20040409183619 38519 example.
O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
jfFJ5arXf4nPxp/kEowGgBRzY/U= )
;; Additional
;; (empty)
B.3. 无数据错误
一个「无数据」响应。NSEC RR 证明该名称存在，而所请求的 RR 类型不存在。
;; Header: QR AA DO RCODE=0
;;
;; Question
ns1.example. IN MX
;; Answer
;; (empty)
;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1081539377
3600
300
3600000
3600
)
example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
20040409183619 38519 example.
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
jV7j86HyQgM5e7+miRAz8V01b0I= )
ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC
ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
;; Additional
;; (empty)
B.4. 对已签名区的委派
对已签名区的委派。DS RR 包含解析器验证子区区顶点中相应 DNSKEY RR 所需的数据。
;; Header: QR DO RCODE=0
;;
;; Question
mc.a.example. IN MX
;; Answer
;; (empty)
;; Authority
a.example. 3600 IN NS ns1.a.example.
a.example. 3600 IN NS ns2.a.example.
a.example. 3600 DS 57855 5 1 (
B6DCD485719ADCA18E5F3D48A2331627FDD3
636B )
a.example. 3600 RRSIG DS 5 2 3600 20040509183619 (
20040409183619 38519 example.
oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
;; Additional
ns1.a.example. 3600 IN A 192.0.2.5
ns2.a.example. 3600 IN A 192.0.2.6
B.5. 对未签名区的委派
对未签名区的委派。NSEC RR 证明父区中不存在此委派的 DS RR。
;; Header: QR DO RCODE=0
;;
;; Question
mc.b.example. IN MX
;; Answer
;; (empty)
;; Authority
b.example. 3600 IN NS ns1.b.example.
b.example. 3600 IN NS ns2.b.example.
b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
vhRXgWT7OuFXldoCG6TfVFMs9xE= )
;; Additional
ns1.b.example. 3600 IN A 192.0.2.7
ns2.b.example. 3600 IN A 192.0.2.8
B.6. 通配符扩展
一个通过通配符扩展回答的成功查询。应答 RRSIG RR 中的标签计数表明扩展了一个通配符 RRset 来产生此响应，NSEC RR 则证明区中不存在更接近的匹配。
;; Header: QR AA DO RCODE=0
;;
;; Question
a.z.w.example. IN MX
;; Answer
a.z.w.example. 3600 IN MX 1 ai.example.
a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 (
20040409183619 38519 example.
OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
4kX18MMR34i8lC36SR5xBni8vHI= )
;; Authority
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
example. 3600 RRSIG NS 5 1 3600 20040509183619 (
20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg= )
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
20040409183619 38519 example.
OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
;; Additional
ai.example. 3600 IN A 192.0.2.9
ai.example. 3600 RRSIG A 5 2 3600 20040509183619 (
20040409183619 38519 example.
pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
ai.example. 3600 AAAA 2001:db8::f00:baa9
ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
20040409183619 38519 example.
nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
sZM6QjBBLmukH30+w1z3h8PUP2o= )
B.7. 通配符无数据错误
对由通配符覆盖的名称的「无数据」响应。NSEC RR 证明匹配的通配符名称没有任何所请求类型的 RR，且区中不存在更接近的匹配。
;; Header: QR AA DO RCODE=0
;;
;; Question
a.z.w.example. IN AAAA
;; Answer
;; (empty)
;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1081539377
3600
300
3600000
3600
)
example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
20040409183619 38519 example.
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
jV7j86HyQgM5e7+miRAz8V01b0I= )
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
20040409183619 38519 example.
OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
*.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC
*.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
s1InQ2UoIv6tJEaaKkP701j8OLA= )
;; Additional
;; (empty)
B.8. DS 子区无数据错误
一个 QTYPE=DS 查询被错误地发送到子区名称服务器的「无数据」响应。
;; Header: QR AA DO RCODE=0
;;
;; Question
example. IN DS
;; Answer
;; (empty)
;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1081539377
3600
300
3600000
3600
)
example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
20040409183619 38519 example.
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
jV7j86HyQgM5e7+miRAz8V01b0I= )
example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
20040409183619 38519 example.
O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
jfFJ5arXf4nPxp/kEowGgBRzY/U= )
;; Additional
;; (empty)
附录 C. 认证示例
本节中的示例展示了附录 B 中的响应报文是如何被认证的。
C.1. 认证应答
附录 B.1 中的查询返回了 "x.w.example.com" 的 MX RRset。相应的 RRSIG 表明该 MX RRset 由一把算法为 5、密钥标签为 38519 的 "example" DNSKEY 签名。解析器需要相应的 DNSKEY RR 才能认证此应答。下面的讨论描述了解析器可能如何获取这条 DNSKEY RR。
RRSIG 表明 MX RRset 的原始 TTL 为 3600，并且为认证之目的，当前 TTL 被替换为 3600。RRSIG 标签字段值为 3，表明该应答不是通配符扩展的结果。"x.w.example.com" MX RRset 被置为规范形式，并且假定当前时间落在签名生效与过期日期之间，则签名被认证。
C.1.1. 认证示例 DNSKEY RR
此示例展示了从一条已配置的根 DNSKEY（或 DS RR）出发、沿树下行认证所需的 "example" DNSKEY RR 的逻辑认证过程。请注意，逻辑顺序是为清晰而呈现的。实现可以选择在收到委派时构造认证，或者只在获得所有 RRset 之后构造认证链，或以任何它认为合适的其他组合方式。此处的示例仅演示逻辑过程，不规定任何实现规则。
我们假定解析器以一条为根区配置的 DNSKEY RR（或一条为根区配置的 DS RR）开始。解析器检查这条已配置的 DNSKEY RR 是否存在于根 DNSKEY RRset 中（或该 DS RR 是否与根 DNSKEY RRset 中的某条 DNSKEY 匹配），这条 DNSKEY RR 是否已签署根 DNSKEY RRset，以及签名有效期是否有效。如果所有这些条件都满足，则 DNSKEY RRset 中的所有密钥都被认为是已认证的。然后解析器使用根 DNSKEY RRset 中的一条（或多条）DNSKEY RR 来认证 "example" DS RRset。请注意，解析器可能必须查询根区以获取根 DNSKEY RRset 或 "example" DS RRset。
一旦使用根 DNSKEY 认证了 DS RRset，解析器就在 "example" DNSKEY RRset 中查找与某条已认证 "example" DS RR 匹配的 "example" DNSKEY RR。如果找到这样一条匹配的 "example" DNSKEY，解析器检查这条 DNSKEY RR 是否已签署 "example" DNSKEY RRset，以及签名有效期是否有效。如果这些条件都满足，则 "example" DNSKEY RRset 中的所有密钥都被认为是已认证的。
最后，解析器检查 "example" DNSKEY RRset 中是否存在使用算法 5 且密钥标签为 38519 的 DNSKEY RR。这把 DNSKEY 被用来认证响应中包含的 RRSIG。如果有多条 "example" DNSKEY RR 匹配该算法与密钥标签，则依次尝试每条 DNSKEY RR，只要其中任何一条匹配的 DNSKEY RR 按上述方式验证了签名，应答即被认证。
C.2. 名称错误
附录 B.2 中的查询返回了证明所请求数据不存在且不适用任何通配符的 NSEC RR。通过验证两条 NSEC RR 来认证否定应答。NSEC RR 的认证方式与上文讨论的 MX RRset 完全相同。
C.3. 无数据错误
附录 B.3 中的查询返回了一条证明所请求名称存在、但所请求 RR 类型不存在的 NSEC RR。通过验证该 NSEC RR 来认证否定应答。该 NSEC RR 的认证方式与上文讨论的 MX RRset 完全相同。
C.4. 对已签名区的委派
附录 B.4 中的查询返回了对已签名 "a.example." 区的委派。该 DS RR 的认证方式与上文讨论的 MX RRset 完全相同。这条 DS RR 被用来认证 "a.example" DNSKEY RRset。
一旦使用 "example" DNSKEY 认证了 "a.example" DS RRset，解析器就在 "a.example" DNSKEY RRset 中查找与该 DS RR 匹配的 "a.example" DNSKEY RR。如果找到这样一条匹配的 "a.example" DNSKEY，解析器检查这条 DNSKEY RR 是否已签署 "a.example" DNSKEY RRset，以及签名有效期是否有效。如果所有这些条件都满足，则 "a.example" DNSKEY RRset 中的所有密钥都被认为是已认证的。
C.5. 对未签名区的委派
附录 B.5 中的查询返回了对未签名 "b.example." 区的委派。该 NSEC 证明不存在从 "example" 通向 "b.example" 的认证，且该 NSEC RR 的认证方式与上文讨论的 MX RRset 完全相同。
C.6. 通配符扩展
附录 B.6 中的查询返回了一个作为通配符扩展结果而产生的应答。Answer 部分包含一个按照传统 DNS 响应方式扩展的通配符 RRset，相应的 RRSIG 表明扩展后的通配符 MX RRset 由一把算法为 5、密钥标签为 38519 的 "example" DNSKEY 签名。RRSIG 表明 MX RRset 的原始 TTL 为 3600，并且为认证之目的，当前 TTL 被替换为 3600。RRSIG 标签字段值为 2，表明该应答是通配符扩展的结果，因为 "a.z.w.example" 名称包含 4 个标签。名称 "a.z.w.w.example" 被替换为 "*.w.example"，MX RRset 被置为规范形式，并且假定当前时间落在签名生效与过期日期之间，则签名被认证。
该 NSEC 证明不存在本可用来回答此查询的更接近匹配（精确或更接近的通配符），并且在应答被视为有效之前，也必须认证该 NSEC RR。
C.7. 通配符无数据错误
附录 B.7 中的查询返回了证明所请求数据不存在且不适用任何通配符的 NSEC RR。通过验证两条 NSEC RR 来认证否定应答。
C.8. DS 子区无数据错误
附录 B.8 中的查询返回了表明所请求项已由子服务器（"example" 服务器）应答的 NSEC RR。该 NSEC RR 表明存在一条 SOA RR，显示出该应答来自子区。对 "example" DS RRset 的查询应发送到父服务器（"root" 服务器）。
作者地址（Authors' Addresses）
Roy Arends
Telematica Instituut
Brouwerijstraat 1
7523 XC Enschede
NL
EMail: roy.arends@telin.nl
Rob Austein
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA
EMail: sra@isc.org
Matt Larson
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA
EMail: mlarson@verisign.com
Dan Massey
Colorado State University
Department of Computer Science
Fort Collins, CO 80523-1873
EMail: massey@cs.colostate.edu
Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899-8920
USA
EMail: scott.rose@nist.gov