Domain Name System Security Extensions (DNSSEC)DNS安全扩展，是由IETF提供的一系列DNS安全认证的机制（可参考RFC2535）。它提供了一种来源鉴定和数据完整性的扩展，但不去保障可用性、加密性和证实域名不存在。

若要通过互联网联系他人，就必须在计算机中键入一个地址（以名称或数字表示）。该地址必须是唯一的，这样计算机才能确定彼此的位置。 ICANN负责在全球范围内协调此类唯一标识符。如果没有这种协调，我们就不会拥有统一的全球互联网。 在键入名称时，必须首先由某个系统将该名称转换为数字，然后才能建立连接。该系统称为域名系统 (Domain Name System, DNS) ，它将类似于 www. icann. org的名称转换为数字，这些数字称为互联网协议 (Internet Protocol, IP) 地址。 ICANN 对寻址系统进行协调，以确保所有地址都是唯一的。

最近，人们在 DNS 中发现了一些漏洞，攻击者可以利用这些漏洞劫持这一使用名称在 互联网 上搜寻某个人或某个站点的过程。这种攻击的目的是取得对会话的控制以实施某种操作，例如使用户进入劫持者自己设立的欺骗性网站，以便收集用户的帐户和密码。

由于这些漏洞的存在，人们越来越希望引入一种称为 DNS 安全扩展 (DNS Security Extensions, DNSSEC) 的技术，以保护 互联网 的这一部分基础 设施 。

下面的问题和答案试图说明 DNSSEC 是什么以及为什么说它的实施很重要。

(1) 首先，什么是根区域？

DNS 将人们可以记住的域名转换为计算机使用的数字以寻找其目的地（有点类似于用来查找电话号码的电话簿）。它分阶段完成此项工作。它“查找”的第一个地方是目录服务的顶级域，即“根区域”。以 www. google. com 为例，您的计算机将“询问”根区域目录（即顶级域）到何处去查找有关“ .com ”的信息。在得到答复后，它将询问由根区域目录标识的“ .com ”目录服务 到何处查找有关 . google. com （第二级）的信息，并最终询问由“ .com ”标识的 google. com 目录服务 www. google. com 的地址是什么（第三级）。在执行该过程以后（该过程几乎瞬间完成），您的计算机就可以获得完整的地址。这些目录服务分别由不同的实体 i 进行 管理： google. com 由 Google 管理，“ .com ”由 VeriSign Corporation 管理（其他顶级域由其他组织管理），而根区域由 ICANN 管理。

(2) 为什么我们需要“对根区域进行签名”？

通过将最近在 DNS 中发现的漏洞与技术进步相结合，攻击者已经大大缩短了劫持 DNS 查找过程的任一步骤所需的时间，从而可以更快地取得对会话的控制以实施某种恶意操作（例如，使用户进入劫持者自己设立的欺骗性网站，以便收集用户的帐户和密码）。若要在长期内消除此漏洞，唯一的解决方案是以端到端的形式部署一种称为 DNS 安全扩展 (DNS Security Extensions, DNSSEC) 的安全协议。

(3) 什么是 DNSSEC ？

开发 DNSSEC 技术的目的之一是通过对数据进行数字“签名”来抵御此类攻击，从而使您确信数据有效。但是，为了从互联网中消除该漏洞，必须在从根区域到最终域名（例如， www. icann. org ）的查找过程中的每一步部署该项技术。对根区域进行签名（在根区域部署 DNSSEC ）是整个过程中的 必要步骤。需要说明的是，该技术并不对数据进行加密。它只是验证您所访问的站点地址是否有效。

(4) 哪些因素能够阻止寻址链的所有其他部分利用 DNSSEC ？

什么因素都无法阻止。但是，像任何依赖于其他部分来发挥作用的链一样，如果您不对根区域进行签名，就会存在重大缺陷。即，寻址链的某些部分可以信任，而其他部分可能无法信任。

(5) 对于普通用户而言，该技术将如何提高安全性？

完全部署 DNSSEC 可以确保最终用户连接到与特定域名相对应的实际网站或其他服务。尽管这不会解决 互联网 的所有安全问题，但它确实保护了 互联网 的关键部分（即目录查找），从而对 SSL (https:) 等其他保护“会话”的技术进行了补充，并且为尚待开发的安全改进技术提供了平台。

(6) 在对根区域进行签名时，实际发生了什么事情？

使用 DNSSEC “对根区域进行签名”时，将在根区域文件中为每个顶级域再添加几条记录。所添加的内容是一个密钥以及一个验证该密钥是否有效的签名。

DNSSEC 为记录提供了验证途径。它不会加密数据或更改数据的管理方式，并且与当前的 DNS 和应用程序“向后兼容”。这意味着它不会更改 互联网 的寻址系统所基于的现有协议。它将一系列数字签名结合到 DNS 层次结构中，并使每个级别都拥有其自己的签名生成密钥。这意味着，对于类似于 www. icann. org 的域名，该路径上的每个组织都必须对低于它的组织的密钥进行签名。例如， .org 对 icann. org 的密钥进行签名，根区域对 .org 的密钥进行签名。在验证过程中， DNSSEC 沿着该信任链一直追溯到根区域，并自动使用该路径上的“父”密钥验证“子”密钥。因为每个密钥都可以由它上面的一个密钥进行验证，所以验证整个域名所需的唯一密钥是最顶层的父密钥（即根密钥）。

但是，此层次结构意味着，即使对根区域进行了签名，跨所有域名完全部署 DNSSEC 也将是一个相当耗时的过程，因为下面的每个域也都需要由其各自的运营商进行签名，以便完成特定的信任链。对根区域进行签名只是一个起点。但它是至关重要的。最近， TLD 运营商已经加快了在 其区域（ .se 、 .bg 、 .br 、 .cz 、 .pr do now with .gov 、 .uk 、 .ca 和其他即将出现的区域）上部署 DNSSEC 的工作进度，而其他运营商预计也将这样做。

(7) 根区域文件是如何管理的？

根区域的管理由以下四个实体共同完成：

(i) ICANN 履行 “ IANA ” 职能 ， 这是一家与美国 商务 部签 有 合同的国际非营利性公司。 IANA 表示互联网编号分配机构 ( Internet Assigned Numbers Authority ) 。 ICANN 接收和审查来自顶级域 (TLD) 运营商 （ 例如 ，“ com ”） 的信息。

(ii) 国家电讯管理中心 ( National Telecommunications and Information Administration, NTIA) 对根区域的变更进行授权 ， 这是美国商务部内部的一个政府机关。

(iii) VeriSign 是一家总部设在美国的营利性公司 ， 该公司与美国政府签订了合同 ， 负责使用由 ICANN 提供和验证且由美国商务部授权的变更信息对根区域进行编辑 ， 并对包含有关到何处查找有关 TLD （ 例如 ，“ com ”） 的信息的根区域文件进行分发 ；

(iv) 一组国际性根服务器运营商，这些运营商志愿运行和拥有遍布全球的 200 台以上的服务器， 而这些服务器负责在整个 互联网 中分发来自根区域文件的根信息。按字母编号，根服务器的运营商为：

(8) 为什么由一家组织对信息进行审查、编辑和签名对于 DNSSEC 安全很重要？

对于 DNSSEC 而言，信任链中每个链路的作用都基于用户对于为该链路审查密钥和其他 DNS 信息的组织所具有的信任。为了保证这些信息的完整性以及维持这一信任，在对数据进行验证之后 必须立即采取措施，防止其出现错误（无论是恶意的还是偶然的） — 在跨组织边界交换重要数据时， 随时都可能引入错误。让同一个组织和系统将经过验证的材料直接纳入已签名的区域中，可以一直维持信任，直到发布为止。这种方式只是更加安全。

随着人们对于 DNSSEC 将带来的 DNS 安全越来越有信心，将对于从 ICANN 验证和鉴别 TLD 信任支持材料的过程中获得的信任一直维持到已签名的根区域文件就变得越发重要。

(9) 在 DNSSEC 中 ， 什么是 KSK 和 ZSK ？

KSK 表示密钥签名密钥 (Key Signing key) （一种长期密钥）， ZSK 表示区域签名密钥 (Zone Signing Key) （一种短期密钥）。如果有足够的时间和数据，加密密钥最终都会被破解。对于 DNSSECv 中使用的非对称密钥或公钥密码系统而言，这意味着攻击者可通过强力攻击方法或其他方法确定公钥 - 私钥对的私钥部分（该部分用于创建对 DNS 记录的有效性进行验证的签名），从而使 DNSSEC 提供的保护失效。 DNSSEC 使用短期密钥（即区域签名密钥 (ZSK) ） 来定期计算 DNS 记录的签名，同时使用长期密钥（即密钥签名密钥 (KSK) ） 来计算 ZSK 上的签名，以使其可以得到验证，从而挫败了这些破解企图。 ZSK 被频繁更改或滚动，以使攻击者难以“猜测”，而期限较长的 KSK 则经过一个长得多的时段之后才更改（当前的最佳做法是以年为单位设置此时段）。由于 KSK 对 ZSK 进行签名而 ZSK 对 DNS 记录进行签名，因此只需具有 KSK 即可对区域中的 DNS 记录进行验证。 它是以 授权签名者 (Delegation Signer, DS) 记录形式传递到“父”区域的一个 KSK 示例 。父区域（例如，根区域）使用其自己的、由其自己的 KSK 签名的 ZSK 对子区域（例如， .org ）的 DS 记录进行签名。

这意味着，如果 DNSSEC 被完全采用，则根区域的 KSK 将是每个经 DNSSEC 验证的域名（或尚待开发的应用程序）的验证链的一部分。

(10) 谁管理这些密钥？

根据此提案， ICANN 将保持密钥基础设施，但用于实际生成 KSK 的凭据将由外方持有。要使此过程在全球得到全面接受，这是一个很重要的因素。 ICANN 未就各实体在持有凭据时所应采用的具体解决方案提出建议，而是认为，像上述所有问题一样，此问题的解决应向公众征求意见，并由美国商务部作出决定。

1. 路由器必须能够处理什么样的信息

路由器必须能够处理大于正常大小的DNS包。原因在于新的授权规定，DNS当前所用的是512字节的UDP包，DNSSEC响应的大小大于512字节。这会带来一些问题。某些路由器的程序设定会拒绝大于512字节的DNS包。

2. 确认路由器是否兼容DNSSEC

3. 其他一些DNS安全测试

拒绝非初始DNS查询

随机分配DNS查询端口

4. 固件升级

升级网关设备上固件永远都没有错，而且现在比以往更为重要。

5. 上游互联网提供商是否做好准备