DNSSEC 概述

域名系统 (DNS)，即国籍寻址系统，是互联网基础结构最关键的组成部分。没有它，互联网则无法工作。但是其设计却没有考虑安全性。结果容易受到中间人 (MITM) 攻击和缓存中毒。这些威胁使用伪造数据将互联网流量重新定位到欺诈网站和无法预见的网址。了解更多有关 DNS 的信息

一旦信任的用户或装置进入欺诈网站，网络罪犯能够提取信用卡数据，偷取用户密码，窃听 IP 语音 (VoIP) 通信，植入恶意软件或显示诋毁合法品牌名誉或提供误导信息的图像和文本。假设一个 DNS 域名服务器可以作为数千名用户的寻址名解析点，则 MITM 攻击或缓存中毒的潜在影响巨大。

DNSSEC 最终用户优势

DNSSEC 为互联网生态系统的所有成员带来了机遇。对最终用户产生直接而广泛的影响。

• 值得信赖的活动 - DNSSEC 通过加强 DNS 安全性，众多互联网活动的安全性增强，包括电子商务、网上银行、电子邮件、VoIP 以及在线软件分发。
• 客户与品牌保护 - DNSSEC 缓解客户尝试访问资源时无意间成为网络罪犯牺牲品的风险。
• 新型安全交易 - DNSSEC 为使用新型安全数据交易的 DNS 系统开启一扇大门。

互联网工程任务组 (IETF) 工作已经超过 15 年，为域名系统安全扩展 (DNSSEC) 开发可行的标准。DNSSEC 保护互联网社区，避免遭受伪造 DNS 数据侵犯，使用公钥加密数字签名进入系统的权威区域数据，然后在目的地进行校验。详细了解更多有关公钥加密

数字签名帮助确保用户数据来自于规定源并且在传输中未被修改。DNSSEC 也可以确认域名不存在。这些功能对保证互联网的信任度必不可少。

在 DNSSEC 中，每个区域都有一个公钥/私钥对。区域公钥使用 DNS 发布，区域私钥通过离线方式安全、妥善的保管。区域的密钥会为该区域中的个人 DNS 数据签名，同时也会通过 DNS 发行数字签名。

DNSSEC 采用严格的信任模型，这条信任链贯穿了父区域和子区域。高级（父区）区域签名或证明低级（子区）区域的公钥。这些不同区域的权威域名服务器可能由注册商、互联网服务提供商 (ISP)、web 主机托管公司或网站运营商（注册商）自己管理。

最终用户想要访问网站时，用户计算机上的存根从递归域名服务器请求网站 IP 地址。服务器请求该记录后，它还会请求与该区域对应的 DNSSEC 密钥。使用该密钥，服务器可以检查其接收的 IP 地址记录是否与权威域名服务器上的记录完全相同。

如果递归域名服务器确定地址记录已被授权域名服务器发送并且在传输过程中未遭修改，递归域名服务器就会解析该域名，之后用户就可以访问该网站。上述过程称为验证。如果地址记录被更改或者不是来自规定的来源，那么递归域名服务器就不会允许用户访问欺诈地址。DNSSEC 还可以证明某个域名不存在。因此，DNS 查询和响应防范“中间人 (MITM)”攻击和类似可能将互联网用户重新定位到钓鱼和域欺骗网站的伪造行为。

为确保 DNSSEC 在全球成功，威瑞信推行围绕三种核心原则解析的主动而谨慎的方法。

• DNSSEC 是特定互联网漏洞的可靠解决方案，但必须得到其他安全层的补充。
• DNSSEC 有控有序的推出是最安全的。
• 整个互联网生态系统分担 DNSSEC 的责任。

特定漏洞的可靠解决方案

尽管 DNSSEC 增强了 DNS 安全性，但只是互联网基础结构安全分层方法的一个组成部分。它不保护域名服务抵御分布式拒绝服务 (DDoS) 攻击，不确保信息交换的机密性，不加密网站数据以及阻止 IP 地址欺骗和钓鱼。要使互联网更加安全，其他层次的防护也至关重要，例如 DDoS 攻击缓解、安全智能、安全套接字层 (SSL) 加密和站点验证，以及双重验证。这些机制应当与 DNSSEC 组合使用。

有序有控的推出

大范围实施 DNSSEC 带来一系列复杂变化，影响整个互联网生态系统并需要更多资源、文档、测试和行业合作。只要推出 DNSSEC，则必须逐步展开，尤其要实现全球关键顶级域 (TLD)（如 .com 和 .net）的可靠运行。长期战略、计划和合作，不仅组织和行业内部或跨域实施，在国际上也要实行，为实施成功创造强大的基础。

分担的责任

因为缓存中毒可以在互联网上随处发生，DNSSEC 广泛实施时最为有效，从根区域和顶级域 (TLD) 开始，向下移至个人域名。维护互联网状态的注册机构、注册商、注册人、主机托管公司、软件开发人员、硬件提供商、政府、企业和机构全部对这种巨大努力承担责任。

由于政府、金融机构、互联网服务提供商 (ISP)、企业和其他组织愈发意识到 DNS 相关威胁，DNSSEC 的采用日益广泛。

互联网根区域、顶级域 (TLD)（如 .net、.com、.gov、.org、.museum 和 .edu）和大量国家代码 TLD (ccTLD) 均已完成 DNSSEC 的全面部署。这些 TLD 已经开始接受 DNSSEC 签名的二级域名。某些 ISP 宣布拟定启用响应用户查询的递归域名服务器验证，同时，某些注册商采纳了在他们的规划图中实施 DNSSEC。此外，ICANN 已开启对新 TLD 的申请，并且 ICANN 可能会要求新 TLD 成功的申请人为 DNSSEC 的实施提出计划。

DNSSEC 时间表

1990	发现 DNS 中的主要缺陷并开始关于 DNS 安全的对话。
1995	DNSSEC 成为 IETF 中的正式主题。
1999	完成 DNSSEC 协议 (RFC2535) 并开发 BIND9 作为第一次具有 DNSSEC 功能的实施。
2001	密钥处理产生运行问题，使 DNSSEC 部署无法用于大型网络。IETF 决定改写协议。
2005	在多个 RFC — 4033、4034 和 4035 中改写了 DNSSEC 标准。10 月，瑞典 (.se) 在其区域启用了 DNSSEC。
2007	7 月，ccTLD .pr (Puerto Rico) 启用了 DNSSEC，之后，巴西在 9 月启用了 .br，保加利亚在 10 月启用了 .bg。
2008	发行 NSEC3 标准 (RFC 5155)。9 月，ccTLD .cz（捷克共和国）启用了 DNSSEC。
2009	威瑞信和 EDUCAUSE 创建了 DNSSEC 试验台来选择 .edu 注册者。威瑞信和 ICANN 将根区域标记用于内部使用。ICANN 和威瑞信使用 KSK 签署了 ZSK。
2010	第一个根服务器开始采用 DURZ（特定畸形数据根区域）方法提供已部署的根区域。所有根服务器均采用 DURZ 方法提供已部署的根区域。ICANN 在美国维吉尼亚州的库帕尔举办了第一届 KSK 典礼。ICANN 发行根区域信方公钥且根区域操作员开始使用实际关键字提供已部署的根区域 — 已部署的根区域可用。威瑞信和 EUDCAUSE 启用 DNSSEC 用于 .edu 域。威瑞信启用 DNSSEC 用于 .net 域。
2011	2 月，向威瑞信转移已启用 DNSSEC 的 .gov 域名。3 月，部署 .com，并强化完全支持 DNSSEC 合规性的威瑞信托管的 DNS 服务。部署根区域中带有信方公钥的 59 TLD。
2012	1 月，Comcast 宣布其客户正在使用 DNSSEC 验证解析程序。自 3 月开始，所部署的 TLD 数量增加至 90。

威瑞信的作用

威瑞信参与 DNSSEC 开发始于 2000 年，我们的工程师在 NSEC3 协议的制定方面做出突出贡献。我们会随着 DNSSEC 测试、实施和改进的向前推移，一如既往地与互联网技术社区合作。例如，我们是 DNSSEC 联盟的积极成员，是专门促进 DNSSEC 改进的行业组织。同时，为确保我们使用最佳实践，我们分享在 DNSSEC 部署中所学到的经验并支持在整个注册机构间采用一致的 DNSSEC 方法。

2010 年 7 月，威瑞信与互联网编号分配机构 (IANA) 和商务部 (DoC) 合作， 在根区域（DNS 层次结构的起点）完成了 DNSSEC 的部署。威瑞信还在 7 月与 EUCAUSE 合作启用了 .edu，并在 2010 年 12 月与 DoC 合作启用了 .net，然后在 2011 年 3 月启用了 .com。此外，大量顶级域 (TLD) 已由其他注册机构签名，包括 .gov、.org 和巴西、保加利亚、捷克共和国、 波多黎各和瑞典的国家代码 TLD 名称。

我们还采取多项措施帮助互联网生态系统的成员利用好 DNSSEC。这些措施包括：发行技术资料、提供操作测试环境、开设培训课程、参加行业论坛、开发 DNSSEC 管理简化工具以及与互操作性实验室一同协助社区。