非官方中文译本声明：本页为 IETF RFC 4033《DNS Security Introduction and Requirements》 的非官方中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布、不受版权限制；依据 BCP 78，本译本为署名翻译作品，译文力求忠实但不构成官方版本，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc4033。

RFC 4033《DNS 安全扩展：引言与需求》中文译本

IETF · RFC 4033 · 标准跟踪（Standards Track）· 2005 年 3 月

摘要

域名系统安全扩展（DNSSEC）为域名系统（DNS）增加了数据来源认证与数据完整性。本文档介绍这些扩展，并描述其能力与局限。本文档还讨论了 DNS 安全扩展所提供以及所不提供的各项服务。最后，本文档描述了共同刻画 DNSSEC 的各文档之间的相互关系。

1. 引言

本文档介绍域名系统安全扩展（DNSSEC）。本文档及其两篇配套文档（[RFC4034] 与 [RFC4035]）更新、澄清并细化 [RFC2535] 及其前身所定义的安全扩展。这些安全扩展由一组新的资源记录类型以及对现有 DNS 协议（[RFC1035]）的修改构成。新记录与协议修改并未在本文档中完整描述，而是在第 10 节所勾勒的一组文档中加以描述。第 3 节与第 4 节更为详细地描述了这些安全扩展的能力与局限。第 5 节讨论了该文档集的适用范围。第 6、7、8、9 节讨论了这些安全扩展将对解析器、存根解析器、区与名称服务器产生的影响。

本文档及其两篇配套文档取代 [RFC2535]、[RFC3008]、[RFC3090]、[RFC3445]、[RFC3655]、[RFC3658]、[RFC3755]、[RFC3757] 与 [RFC3845]。该文档集还更新（但不取代）[RFC1034]、[RFC1035]、[RFC2136]、[RFC2181]、[RFC2308]、[RFC3225]、[RFC3007]、[RFC3597] 以及 [RFC3226] 中与 DNSSEC 相关的部分。

DNS 安全扩展为 DNS 数据提供来源认证与完整性保护，并提供一种公钥分发的手段。这些扩展不提供机密性（confidentiality）。

2. 重要 DNSSEC 术语的定义

本节定义了本文档集所使用的一系列术语。由于本节旨在供阅读本文档集其余部分时作为参考使用，首次阅读的读者不妨快速浏览本节，先阅读本文档的其余部分，再回到本节。

认证链（Authentication Chain）：由 DNS 公钥（DNSKEY）RRset 与委派签名者（DS）RRset 交替组成的序列构成一条已签名数据链，链上的每一环都为下一环作担保。DNSKEY RR 用于验证覆盖某条 DS RR 的签名，使该 DS RR 得以被认证。DS RR 包含另一条 DNSKEY RR 的散列，而这条新的 DNSKEY RR 通过匹配 DS RR 中的散列得以被认证。这条新的 DNSKEY RR 继而认证另一条 DNSKEY RRset，进而该 RRset 中的某条 DNSKEY RR 又可用于认证另一条 DS RR，如此往复，直至该链最终止于一条其相应私钥签署所需 DNS 数据的 DNSKEY RR。例如，根 DNSKEY RRset 可用于认证 "example." 的 DS RRset。"example." 的 DS RRset 所含的散列与某条 "example." DNSKEY 相匹配，而该 DNSKEY 对应的私钥签署 "example." 的 DNSKEY RRset。"example." 的 DNSKEY RRset 的私钥副本则签署诸如 "www.example." 之类的数据记录，以及诸如 "subzone.example." 之类委派点的 DS RR。

认证密钥（Authentication Key）：一把经安全感知解析器验证过、因而可用于认证数据的公钥。安全感知解析器可以通过三种方式获得认证密钥。其一，解析器一般配置为至少知晓一把公钥；该配置数据通常是公钥本身，或者是 DS RR 中所载的公钥散列（参见「信任锚」）。其二，解析器可以使用一把已认证的公钥来验证 DS RR 以及该 DS RR 所指向的 DNSKEY RR。其三，解析器可以判定某把新公钥已由「与解析器已验证过的另一把公钥相对应的私钥」签名。请注意，在决定是否认证一把新公钥时，解析器必须始终受本地策略的指引，即便本地策略仅仅是不加区分地认证任何解析器能够验证其签名的公钥。

权威 RRset（Authoritative RRset）：在特定区的语境下，当且仅当 RRset 的所有者名称位于「自区顶点向下、直至将该区与子区（如有）分隔开的区切口为止（含两端）」的名称空间子集之内，该 RRset 才是「权威的」。区顶点处的所有 RRset 均为权威，但该域名下某些属于本区父区的 RRset（如存在）除外。这些 RRset 可能包括 DS RRset、引用该 DS RRset 的 NSEC RRset（「父侧 NSEC」）以及与这些 RRset 关联的 RRSIG RR，所有这些在父区中都是权威的。类似地，如果本区包含任何委派点，则只有父侧 NSEC RRset、DS RRset 以及与这些 RRset 关联的任何 RRSIG RR 对本区而言是权威的。

委派点（Delegation Point）：用于描述区切口父侧名称的术语。也就是说，"foo.example" 的委派点将是 "example" 区中的 foo.example 节点（与 "foo.example" 区的区顶点相对）。另见区顶点。

安全孤岛（Island of Security）：用于描述一个已签名、已委派、却未从其委派父区获得认证链的区。也就是说，在其委派父区中不存在包含该孤岛某条 DNSKEY RR 之散列的 DS RR（参见 [RFC4034]）。安全孤岛由安全感知名称服务器提供服务，并可以向任何已委派的子区提供认证链。来自安全孤岛或其后代的响应，只有当其认证密钥能够通过 DNS 协议之外的某种可信手段加以认证时，才能被认证。

密钥签名密钥（Key Signing Key，KSK）：一把与用于为某给定区签署一条或多条其他认证密钥的私钥相对应的认证密钥。通常，与密钥签名密钥对应的私钥将签署一条区签名密钥，而区签名密钥对应的私钥再签署其他区数据。本地策略可能要求频繁更换区签名密钥，而密钥签名密钥可以具有更长的有效期，以便为该区提供更稳定的安全入口点。将某条认证密钥指定为密钥签名密钥纯粹是一个运营问题：DNSSEC 验证并不区分密钥签名密钥与其他 DNSSEC 认证密钥，而且用单把密钥同时充当密钥签名密钥与区签名密钥是可能的。密钥签名密钥在 [RFC3757] 中有更详细的讨论。另见区签名密钥。

不验证的安全感知存根解析器（Non-Validating Security-Aware Stub Resolver）：一种信任一台或多台安全感知递归名称服务器代其执行本文档集所讨论的大多数任务的安全感知存根解析器。具体而言，不验证的安全感知存根解析器是这样一种实体：它发送 DNS 查询、接收 DNS 响应，并能够与一台将代表该安全感知存根解析器提供这些服务的、安全感知的递归名称服务器建立适当加固的信道。另见安全感知存根解析器、验证型安全感知存根解析器。

不验证存根解析器（Non-Validating Stub Resolver）：「不验证的安全感知存根解析器」的简略说法。

安全感知名称服务器（Security-Aware Name Server）：以名称服务器角色（[RFC1034] 第 2.4 节所定义）运作、并理解本文档集所定义 DNS 安全扩展的实体。具体而言，安全感知名称服务器是这样一种实体：它接收 DNS 查询、发送 DNS 响应、支持 EDNS0（[RFC2671]）报文大小扩展与 DO 位（[RFC3225]），并支持本文档集所定义的 RR 类型与报文头位。

安全感知递归名称服务器（Security-Aware Recursive Name Server）：同时以安全感知名称服务器与安全感知解析器两种角色运作的实体。一个更为冗长但等价的说法是「一台提供递归服务的安全感知名称服务器」。

安全感知解析器（Security-Aware Resolver）：以解析器角色（[RFC1034] 第 2.4 节所定义）运作、并理解本文档集所定义 DNS 安全扩展的实体。具体而言，安全感知解析器是这样一种实体：它发送 DNS 查询、接收 DNS 响应、支持 EDNS0（[RFC2671]）报文大小扩展与 DO 位（[RFC3225]），并能够使用本文档集所定义的 RR 类型与报文头位来提供 DNSSEC 服务。

安全感知存根解析器（Security-Aware Stub Resolver）：以存根解析器角色（[RFC1034] 第 5.3.1 节所定义）运作、并对本文档集所定义的 DNS 安全扩展有足够理解、以提供安全无感存根解析器所不具备的附加服务的实体。安全感知存根解析器可以是「验证型」或「不验证型」，取决于该存根解析器是自行尝试验证 DNSSEC 签名，还是信任一台友好的安全感知名称服务器代为验证。另见验证型存根解析器、不验证型存根解析器。

安全无感<任何事物>（Security-Oblivious <anything>）：不具备「安全感知」能力的<任何事物>。

已签名区（Signed Zone）：其 RRset 均已签名、并包含构造正确的 DNSKEY、资源记录签名（RRSIG）、下一安全（NSEC）以及（可选）DS 记录的区。

信任锚（Trust Anchor）：一条已配置的 DNSKEY RR，或某条 DNSKEY RR 的 DS RR 散列。验证型安全感知解析器以这把公钥或散列为起点，建立通向已签名 DNS 响应的认证链。一般而言，验证型解析器必须通过 DNS 协议之外的某种安全或可信手段获得其信任锚的初始值。信任锚的存在还意味着解析器应当预期信任锚所指的区是已签名的。

未签名区（Unsigned Zone）：未签名的区。

验证型安全感知存根解析器（Validating Security-Aware Stub Resolver）：一种以递归模式发送查询、但自行执行签名验证而非盲目信任上游安全感知递归名称服务器的安全感知解析器。另见安全感知存根解析器、不验证的安全感知存根解析器。

验证型存根解析器（Validating Stub Resolver）：「验证型安全感知存根解析器」的简略说法。

区顶点（Zone Apex）：用于描述区切口子侧名称的术语。另见委派点。

区签名密钥（Zone Signing Key，ZSK）：一把与用于签署某个区的私钥相对应的认证密钥。通常，区签名密钥将与其密钥签名密钥处于同一条 DNSKEY RRset 中——该 DNSKEY RRset 由密钥签名密钥对应的私钥签署——但区签名密钥用于略有不同的目的，并可能在其他方面（例如有效使用期限）与密钥签名密钥不同。将某条认证密钥指定为区签名密钥纯粹是一个运营问题；DNSSEC 验证并不区分区签名密钥与其他 DNSSEC 认证密钥，而且用单把密钥同时充当区签名密钥与密钥签名密钥是可能的。另见密钥签名密钥。

3. DNS 安全所提供的服务

域名系统（DNS）安全扩展为 DNS 数据提供来源认证与完整性保障服务，包括对 DNS 数据不存在的经认证否定机制。这些机制在下面描述。

这些机制需要对 DNS 协议进行修改。DNSSEC 新增了四种资源记录类型：资源记录签名（RRSIG）、DNS 公钥（DNSKEY）、委派签名者（DS）与下一安全（NSEC）。它还新增了两个报文头位：禁用检查（CD）与已认证数据（AD）。为了支持因加入 DNSSEC RR 而产生的更大 DNS 报文，DNSSEC 还要求支持 EDNS0（[RFC2671]）。最后，DNSSEC 要求支持 DNSSEC OK（DO）EDNS 头位（[RFC3225]），以便安全感知解析器能够在查询中表明希望在响应报文中收到 DNSSEC RR。

这些服务针对 [RFC3833] 所描述的针对域名系统的大多数威胁提供保护。有关这些扩展之局限的讨论，请参见第 12 节。

3.1. 数据来源认证与数据完整性

DNSSEC 通过把以密码学方式生成的数字签名与 DNS RRset 相关联来提供认证。这些数字签名存储在新资源记录 RRSIG 记录中。通常将有一把私钥签署某个区的数据，但多把密钥也是可能的。例如，可能有分别用于若干不同数字签名算法的密钥。如果安全感知解析器可靠地获知某个区的公钥，它就可以认证该区的已签名数据。DNSSEC 的一个重要概念是：签署区数据的密钥与该区本身相关联，而非与该区的权威名称服务器相关联。（用于 DNS 事务认证机制的公钥也可能出现在区中，如 [RFC2931] 所述，但 DNSSEC 本身关注的是 DNS 数据的对象安全（object security），而非 DNS 事务的信道安全（channel security）。与事务安全相关联的密钥可能存储在不同的 RR 类型中。详见 [RFC3755]。）

安全感知解析器既可以通过在解析器中配置信任锚，也可以通过正常的 DNS 解析来获知某个区的公钥。为允许后者，公钥存储在新类型的资源记录 DNSKEY RR 中。请注意，用于签署区数据的私钥必须妥善保管，并在可行时应离线存储。要通过 DNS 解析可靠地发现公钥，目标密钥本身必须由一条已配置的认证密钥或另一把此前已认证的密钥签名。安全感知解析器通过建立认证链来认证区信息：从新学到的公钥追溯到先前已知的认证公钥，而后者要么已配置到解析器中，要么必须此前已学到并验证过。因此，解析器必须至少配置一条信任锚。

如果配置的信任锚是区签名密钥，则它将认证相关联的区；如果配置的密钥是密钥签名密钥，则它将认证一条区签名密钥。如果配置的信任锚是某把密钥的散列而非密钥本身，则解析器可能必须通过 DNS 查询获得该密钥。为帮助安全感知解析器建立这条认证链，安全感知名称服务器会尝试在 DNS 应答报文中连同公钥本身一起发送认证某区公钥所需的签名——前提是报文中留有空间。

委派签名者（DS）RR 类型简化了跨组织边界签署委派时涉及的一些管理任务。DS RRset 位于父区的委派点处，并指明与「用于对委派子区区顶点处的 DNSKEY RRset 进行自签名的私钥」相对应的公钥。子区管理员转而使用该 DNSKEY RRset 中一把或多把公钥所对应的私钥来签署子区的数据。因此，典型的认证链是 DNSKEY->[DS->DNSKEY]* ->RRset，其中 "*" 表示零个或多个 DS->DNSKEY 子链。DNSSEC 允许更复杂的认证链，例如在区内的其他 DNSKEY RR 之上再加一层层 DNSKEY RR 来签署。

安全感知解析器通常基于对根公钥的配置性了解，从 DNS 层级结构的根部向下直至叶区来构建这条认证链。不过，本地策略也可能允许安全感知解析器使用根公钥之外的一把或多把已配置公钥（或公钥的散列），可能不提供对根公钥的配置性了解，或者可能出于任意原因阻止解析器使用特定公钥——即便这些公钥带有可验证的有效签名。DNSSEC 提供了相应机制，使安全感知解析器能够判定某 RRset 的签名在 DNSSEC 意义下是否「有效」。但归根结底，认证 DNS 密钥与数据都是本地策略问题，本地策略可以扩展甚至覆盖本文档集所定义的协议扩展。进一步讨论见第 5 节。

3.2. 认证名称与类型的不存在

第 3.1 节所述的安全机制只提供对区内既有 RRset 签名的方式。以同等认证与完整性级别提供否定应答的问题，需要再使用一种新的资源记录类型——NSEC 记录。NSEC 记录使安全感知解析器能够使用与认证其他 DNS 应答相同的机制，认证针对名称不存在或类型不存在的否定应答。使用 NSEC 记录需要对区中的域名采用规范表示与排序。NSEC 记录链显式描述区内域名之间的空隙（即「空位」），并列出既有名称处存在的 RRset 类型。每条 NSEC 记录都使用第 3.1 节所述机制签名并认证。

4. DNS 安全不提供的服务

DNS 最初设计时假定：无论查询由谁发出，DNS 对任何给定查询都会返回相同的答案，因此 DNS 中的所有数据都是可见的。相应地，DNSSEC 并非为提供机密性、访问控制列表或其他区分查询者的手段而设计。

DNSSEC 不提供针对拒绝服务攻击的保护。安全感知解析器与安全感知名称服务器易遭受一类额外的、基于密码学操作的拒绝服务攻击。详情请参见第 12 节。

DNS 安全扩展为 DNS 数据提供数据认证与来源认证。上述机制并非为保护区传送和动态更新（[RFC2136]、[RFC3007]）等操作而设计。[RFC2845] 与 [RFC2931] 所描述的报文认证方案处理与这些事务相关的安全操作。

5. DNSSEC 文档集的适用范围与最后一跳问题

本文档集中的规范以这样的方式定义了区签名者、安全感知名称服务器与解析器的行为：验证实体能够无歧义地判定数据的状态。

验证型解析器可以判定以下 4 种状态：

安全（Secure）：验证型解析器拥有信任锚与信任链，并且能够验证响应中的所有签名。

不安全（Insecure）：验证型解析器拥有信任锚与信任链，并且在某个委派点处存在「DS 记录不存在」的已签名证明。这表明树中后续分支可证明是不安全的。验证型解析器可以设置本地策略，将域名空间的某些部分标记为不安全。

伪造（Bogus）：验证型解析器拥有信任锚，并拥有表明附属数据已签名的安全委派，但响应出于某种原因未能通过验证：签名缺失、签名过期、签名使用不受支持的算法、相关 NSEC RR 声称应存在的数据缺失，等等。

不确定（Indeterminate）：不存在任何会表明树中特定部分是安全的信任锚。这是默认的工作模式。

本规范只定义了安全感知名称服务器如何向不验证的存根解析器发出「数据被发现是伪造的」的信号（使用 RCODE=2「服务器失败」；参见 [RFC4035]）。

有一种机制可供安全感知名称服务器向安全感知存根解析器发出「数据被发现是安全的」的信号（使用 AD 位；参见 [RFC4035]）。

本规范未定义用于传达「响应为何被发现是伪造的或为何被标记为不安全」的格式。当前的信令机制不区分不确定与不安全状态。

在安全感知存根解析器与安全感知递归名称服务器之间传达高级错误码与策略的方法，是未来工作的主题；安全感知解析器与使用它的应用之间的接口同样如此。但请注意，缺乏此类通信的规范并不妨碍已签名区的部署，也不妨碍部署那些禁止将伪造数据传播给应用的安全感知递归名称服务器。

6. 解析器考虑

安全感知解析器必须能够执行使用至少是「强制实现」算法验证数字签名所需的密码学功能。安全感知解析器还必须能够如上述那样，从新学到的区建立通向认证密钥的认证链。该过程可能需要额外的查询，访问中间 DNS 区以获取必要的 DNSKEY、DS 与 RRSIG 记录。安全感知解析器应至少配置一条信任锚，作为其尝试建立认证链的起点。

如果安全感知解析器与相关权威名称服务器之间隔着一台递归名称服务器或任何充当 DNS 代理的中介设备，而该递归名称服务器或中介设备并非安全感知的，那么安全感知解析器可能无法以安全模式运作。例如，如果安全感知解析器的数据包经由一台包含非安全感知 DNS 代理的网络地址转换（NAT）设备路由，安全感知解析器可能难以甚至无法获取或验证已签名的 DNS 数据。在这种情况下，安全感知解析器获取 DS RR 可能尤其困难，因为 DS RR 不遵循区切口处 RR 归属的常规 DNS 规则。请注意，该问题并非 NAT 所特有：任何位于安全感知解析器与权威名称服务器之间的、任何形式的无安全感知 DNS 软件都会干扰 DNSSEC。

如果安全感知解析器必须依赖未签名的区或非安全感知的名称服务器，则解析器可能无法验证 DNS 响应，并需要本地策略来决定是否接受未经验证的响应。

安全感知解析器在确定缓存中数据的 TTL 时应考虑签名的验证期，以避免将已签名数据缓存在签名有效期之外。但它也应考虑到解析器自身时钟可能出错的可能性。因此，作为安全感知递归名称服务器一部分的安全感知解析器必须密切关注 DNSSEC「禁用检查」（CD）位（[RFC4034]）。这是为了避免阻止有效签名送达作为该递归名称服务器客户端的其他安全感知解析器。关于安全递归服务器如何处理置位 CD 位的查询，参见 [RFC4035]。

7. 存根解析器考虑

尽管协议并未严格如此要求，但大多数 DNS 查询都源自存根解析器。按定义，存根解析器是最小化的 DNS 解析器，使用递归查询模式将 DNS 解析的大部分工作转交给递归名称服务器。鉴于存根解析器的广泛使用，DNSSEC 架构不得不把存根解析器纳入考虑，但存根解析器所需的安全特性在某些方面不同于安全感知迭代解析器所需的特性。

即便是安全无感存根解析器，只要其所用的递归名称服务器是安全感知的，也可能受益于 DNSSEC；但存根解析器若要真正依赖 DNSSEC 服务，就必须既信任所涉的递归名称服务器，也信任其自身与这些名称服务器之间的通信信道。第一个问题是本地策略问题：本质上，安全无感存根解析器别无选择，只能听凭其所用递归名称服务器摆布，因为它不自行执行 DNSSEC 有效性检查。第二个问题需要某种信道安全机制；妥善使用 SIG(0)（[RFC2931]）或 TSIG（[RFC2845]）之类的 DNS 事务认证机制即可满足，恰当使用 IPsec 亦可。特定实现可能还有其他的可用选择，例如操作系统特有的进程间通信机制。此信道不需要机密性，但需要数据完整性与报文认证。

确实信任其递归名称服务器以及其通向这些名称服务器的通信信道的安全感知存根解析器，可以选择检视其收到的响应报文报文头中「已认证数据」（AD）位的设置。存根解析器可以将该标志位用作提示，了解递归名称服务器是否能够验证响应中 Answer 与 Authority 部分所有数据的签名。

如果由于某种原因，安全感知存根解析器无法与其所用的递归名称服务器建立有效的信任关系，它还可以再进一步：在查询报文中设置「禁用检查」（CD）位，自行执行签名验证。由此，验证型存根解析器能够把 DNSSEC 签名视为区管理员与存根解析器之间的信任关系。

8. 区考虑

已签名区与未签名区之间有几处区别。已签名区将包含额外的安全相关记录（RRSIG、DNSKEY、DS 与 NSEC 记录）。RRSIG 与 NSEC 记录可以在提供服务之前由签名过程生成。伴随区数据的 RRSIG 记录具有定义好的生效（inception）与过期（expiration）时间，为这些签名及其所覆盖的区数据确立有效期。

8.1. TTL 值与 RRSIG 有效期

注意 RRset 的 TTL 值与覆盖该 RRset 的 RRSIG RR 所指定的签名有效期之间的区别，这一点很重要。DNSSEC 不改变 TTL 值的定义或功能，TTL 旨在维持缓存中数据库的一致性。缓存解析器最迟在这些 RRset 的 TTL 字段所指定的时间段结束时将其从缓存中清除，无论该解析器是否安全感知。

另一方面，RRSIG RR（[RFC4034]）中的生效与过期字段指定了该签名可用于验证所覆盖 RRset 的时间段。与已签名区数据相关联的签名，仅在相关 RRSIG RR 中这些字段所指定的时间段内有效。TTL 值不能延长解析器缓存中已签名 RRset 的有效期，但解析器可以将「已签名 RRset 签名有效期届满前的剩余时间」作为该 RRset 及其关联 RRSIG RR 在缓存中 TTL 的上限。

8.2. 区的新的时间依赖问题

已签名区中的信息具有原始 DNS 协议所没有的时间依赖。已签名区需要定期维护，以确保区中的每个 RRset 都有一条当前有效的 RRSIG RR。RRSIG RR 的签名有效期是一个时间段，在该时间段内，特定已签名 RRset 的签名可被视为有效，而区中不同 RRset 的签名可能在不同时间过期。重新签署区中的一个或多个 RRset 将改变一条或多条 RRSIG RR，这又要求递增区的 SOA 序列号以表明发生了区变更，并重新签署 SOA RRset 本身。因此，重新签署区中的任何 RRset 都可能触发 DNS NOTIFY 报文与区传送操作。

9. 名称服务器考虑

安全感知名称服务器应在对「已通过使用 EDNS 头中的 DO 位表明愿意接收此类记录」的解析器之查询的所有响应中，加入适当的 DNSSEC 记录（RRSIG、DNSKEY、DS 与 NSEC），但受报文大小限制的约束。由于加入这些 DNSSEC RR 很容易导致 UDP 报文截断并回退到 TCP，安全感知名称服务器还必须支持 EDNS「发送方 UDP 负载大小」机制。

如有可能，每个 DNSSEC 密钥对的私钥部分应离线保存，但对于已启用 DNS 动态更新的区而言，这一点不可能做到。在动态更新情形下，区的主主服务器（primary master server）在更新时必须重新签署该区，因此与区签名密钥对应的私钥必须保持在线。这是「将区的 DNSKEY RRset 区分为区签名密钥与密钥签名密钥的能力可能有用」的一个例子，因为此类情形下密钥签名密钥仍可离线保存，并且可以具有比区签名密钥更长的有效使用寿命。

仅靠 DNSSEC 本身不足以在区传送操作期间保护整个区的完整性，因为即便是已签名区，如果该区有任何子区，也会包含一些未签名的非权威数据。因此，区维护操作需要一些额外机制（很可能是某种形式的信道安全，例如 TSIG、SIG(0) 或 IPsec）。

10. DNS 安全文档族

DNSSEC 文档集可以划分成几个主要组，统归于 DNS 基础协议文档的大伞之下。

「DNSSEC 协议文档集」指构成 DNS 安全扩展核心的三份文档：

  1. DNS 安全扩展：引言与需求（本文档）
  2. DNS 安全扩展的资源记录 [RFC4034]
  3. DNS 安全扩展的协议修改 [RFC4035]

此外，任何会增补或改变核心 DNS 安全扩展的文档都将归入此类别。这包括未来关于安全感知存根解析器与上游安全感知递归名称服务器之间通信的任何工作。

「数字签名算法规范」文档集指一组描述特定数字签名算法应如何实现以适配 DNSSEC 资源记录格式的文档。该集中的每份文档处理一种特定的数字签名算法。撰写本核心规范时已定义的算法清单，请参见 [RFC4034] 中关于「DNSSEC 算法与摘要类型」的附录。

「事务认证协议」文档集指一组处理 DNS 报文认证（包括秘密密钥的建立与验证）的文档。虽然严格来说这组文档并非本文档集所定义的 DNSSEC 规范的一部分，但鉴于其与 DNSSEC 的关系，在此加以说明。

最后一组文档集「新安全用途」指寻求将拟议的 DNS 安全扩展用于其他安全相关目的的文档。DNSSEC 不直接为这些新用途提供安全，但可用于支持它们。归入此类的文档包括描述在 DNS 中存储与分发证书之用途的文档（[RFC2538]）。

11. IANA 考虑

本综述文档不引入任何新的 IANA 考虑。关于 DNSSEC 所引入 IANA 考虑的完整审查，请参见 [RFC4034]。

12. 安全考虑

本文档介绍 DNS 安全扩展，并描述包含新安全记录与 DNS 协议修改的文档集。这些扩展使用资源记录集上的数字签名提供数据来源认证与数据完整性。本节讨论这些扩展的局限。

为使安全感知解析器能够验证 DNS 响应，从可信起点到包含响应区的区这一路径上的所有区都必须签名，并且解析过程中涉及的所有名称服务器与解析器都必须如本文档集所定义的那样是安全感知的。安全感知解析器无法验证来自未签名区、来自非安全感知名称服务器所服务的区、或解析器只能通过非安全感知递归名称服务器获得的任何 DNS 数据的响应。如果认证链出现断裂，致使安全感知解析器无法获取并验证其所需的认证密钥，那么安全感知解析器就无法验证受影响的 DNS 数据。

本文档简要讨论了为 DNS 查询增加安全性的其他方法，例如使用 IPsec 加固的信道，或使用 TSIG（[RFC2845]）或 SIG(0)（[RFC2931]）之类的 DNS 事务认证机制，但事务安全本身并非 DNSSEC 的一部分。

按定义，不验证的安全感知存根解析器不自行执行 DNSSEC 签名验证，因此既容易遭受针对（以及来自）代其执行这些检查的安全感知递归名称服务器的攻击，也容易遭受针对其与这些安全感知递归名称服务器通信的攻击。不验证的安全感知存根解析器应当使用某种形式的信道安全来抵御后一类威胁。抵御前一类威胁的已知唯一防御手段，是让安全感知存根解析器自行执行签名验证——到了那一步，同样按定义，它就不再是不验证的安全感知存根解析器了。

DNSSEC 不提供针对拒绝服务攻击的保护。DNSSEC 使 DNS 易受一类新的、针对安全感知解析器与安全感知名称服务器、基于密码学操作的拒绝服务攻击，因为攻击者可以尝试利用 DNSSEC 机制消耗受害者的资源。此类攻击至少有两种形式。攻击者可以通过篡改响应报文中的 RRSIG RR，或构造过于复杂的签名链，来消耗安全感知解析器签名验证代码中的资源。攻击者还可以通过发送一连串更新报文、迫使支持 DNS 动态更新的安全感知名称服务器以比原本必要的频率更频繁地重新签署区中的某些 RRset，从而消耗该名称服务器的资源。

出于一个刻意的设计选择，DNSSEC 不提供机密性。

DNSSEC 引入了恶意方通过循行 NSEC 链枚举区中所有名称的能力。NSEC RR 通过沿区内所有名称的规范排序、从既有名称连接到既有名称，来断言区中哪些名称不存在。因此，攻击者可以依次查询这些 NSEC RR，以获得区中的所有名称。尽管这不是对 DNS 本身的攻击，但它可能使攻击者能够通过枚举区的内容来绘制网络主机或其他资源的图谱。

DNSSEC 给 DNS 带来了显著的额外复杂性，因此也带来了许多实现错误与错误配置区的新的机会。特别地，在解析器中启用 DNSSEC 签名验证，可能因 DNSSEC 配置错误或缺陷而使整个合法的区实际上变得不可达。

DNSSEC 不提供针对篡改未签名区数据的保护。区切口处的非权威数据（父区中的粘合记录（glue）与 NS RR）不签名。这在验证认证链时不会造成问题，但这确实意味着非权威数据本身在区传送操作期间容易遭到篡改。因此，尽管 DNSSEC 可以为 RRset 提供数据来源认证与数据完整性，但它无法为区提供这些保证，必须使用其他机制（例如 TSIG、SIG(0) 或 IPsec）来保护区传送操作。

其他安全考虑请参见 [RFC4034] 与 [RFC4035]。

13. 致谢

本文档由 DNS 扩展工作组成员的意见与想法汇集而成。虽然把 DNSSEC 十年发展历程中的每一位贡献者都一一列出是不可能的，但编辑们特别感谢以下人员对本文档集的贡献与评论：Jaap Akkerhuis、Mark Andrews、Derek Atkins、Roy Badami、Alan Barrett、Dan Bernstein、David Blacka、Len Budney、Randy Bush、Francis Dupont、Donald Eastlake、Robert Elz、Miek Gieben、Michael Graff、Olafur Gudmundsson、Gilles Guette、Andreas Gustafsson、Jun-ichiro Itojun Hagino、Phillip Hallam-Baker、Bob Halley、Ted Hardie、Walter Howard、Greg Hudson、Christian Huitema、Johan Ihren、Stephen Jacob、Jelte Jansen、Simon Josefsson、Andris Kalnozols、Peter Koch、Olaf Kolkman、Mark Kosters、Suresh Krishnaswamy、Ben Laurie、David Lawrence、Ted Lemon、Ed Lewis、Ted Lindgreen、Josh Littlefield、Rip Loomis、Bill Manning、Russ Mundy、Thomas Narten、Mans Nilsson、Masataka Ohta、Mike Patton、Rob Payne、Jim Reid、Michael Richardson、Erik Rozendaal、Marcos Sanz、Pekka Savola、Jakob Schlyter、Mike StJohns、Paul Vixie、Sam Weiler、Brian Wellington 与 Suzanne Woolf。

毫无疑问，上述名单并不完整。我们向任何被遗漏的人致歉。

14. 参考文献

14.1. 规范性参考文献

14.2. 资料性参考文献

作者地址（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