什么是 DNSSEC?

DNSSEC 通过使用公钥加密来为授权区域数据进行数字签名，发挥作用让互联网社区免受伪造域名系统 (DNS) 数据的危害。DNSSEC 验证有助于向用户确保数据来自规定的来源，并且在传输过程中未遭修改。DNSSEC 还可以证明某个域名不存在。

尽管 DNSSEC 增强了 DNS 的安全性，但也不是一种全面的解决方案。它不能抵御分布式拒绝服务 (DDoS) 攻击，不能确保信息交换的机密性，不能加密网站数据以及防止 IP 地址欺骗或网络钓鱼。要使互联网更加安全，其它层次的防护也至关重要，例如 DDoS 缓解、安全情报、站点验证和安全套接字层 (SSL) 加密以及双重验证。这些机制可与 DNSSEC 组合使用。

DNSSEC 让互联网基础设施生态系统中的很多部分都能受益。要将其进行有效部署，需要互联网社区中许多利益相关者的参与。注册机构、注册商、域名注册人、软硬件供应商、互联网服务提供商 (ISP)、政府机构以及普通互联网用户都在其中发挥作用，才能确保 DNSSEC 获得成功，提高互联网的安全性。DNSSEC 旨在为以下各方提供以下益处：

• 互联网社区，提高已签名区域的安全性。
• 注册商，为客户提供域名签名服务。
• ISP，提高返回给客户的数据的安全性。
• 用户，保护他们免受缓存中毒和中间人攻击等 DNS 漏洞的危害。

在 DNSSEC 中，每个区域都有至少一个公钥/私钥对。区域公钥使用 DNS 发布，区域私钥通过离线方式安全、妥善的保管。区域私钥会为该区域中的个人 DNS 数据签名，同时创建同样由 DNS 发布的数字签名。DNSSEC 采用严格的信任模型，这条信任链贯穿了父区域和子区域。高等级（父）区域会为低等级（子）区域签署公钥。这些区域的授权名称服务器可由注册商、ISP、托管/云提供商或注册人管理。

当最终用户想访问互联网资源时，用户操作系统中的根解析器会向通常位于 ISP 或在企业网络内部的递归名称服务器请求域名记录。如果当前未缓存请求的信息，则递归名称服务器向相应的授权名称服务器发出请求。服务器请求该记录后，还会请求与该区域对应的 DNSSEC 公钥。该密钥允许递归服务器验证其接收的信息是否与授权名称服务器上的记录一致。

如果递归名称服务器确定地址记录已被授权名称服务器发送并且在传输过程中未遭修改，递归名称服务器就会解析该域名，之后用户就可以访问该网站。上述过程称为验证。如果地址记录被更改或者不是来自规定的来源，那么递归名称服务器就不会允许用户访问欺诈地址。

互联网安全是涉及众多方面的复杂问题。DNSSEC 可能会缓解“中间人”攻击和缓存中毒所带来的安全隐忧，但它还不是全面的安全解决方案。DNSSEC 无法解决多种常见的互联网安全威胁，例如欺骗或网络钓鱼。出于此原因，如果要让互联网变得更加安全，那么其它层面的保护（例如 SSL 证书和双重认证）同样至关重要。

2010 年 7 月，威瑞信与互联网数字分配机构 (IANA) 和美国商务部 (DoC) 合作，在根区域（DNS 层次结构的起点）完成了 DNSSEC 的部署。威瑞信还在 2010 年 7 月与 EDUCAUSE 合作启用了 .edu 上的 DNSSEC，并在 2010 年 12 月与 DoC 合作启用了 .net 上的 DoC，然后在 2011 年 3 月启用了 .com。

对于全球互联网社区来说，成功部署 DNSSEC 的意义深远，它将提升大量互联网活动的可信度，包括电子商务、网上银行、电子邮件、VoIP 以及在线软件分发。因此，整个互联网社区都有责任帮助 DNSSEC 取得成功。要取得成功，需要注册机构、注册商、注册人、托管公司、软件开发者、硬件供应商、政府以及互联网技术人员和互联网联盟的积极协作与参与。

互联网根区域、.gov、.org、.museum 等顶级域 (TLD) 以及大量国家代码 TLD (ccTLD) 都已为所管理的区域签名。.edu、.net 和 .com 等其它 TLD 在 2010 和 2011 年部署了 DNSSEC。这些 TLD 已经开始接受 DNSSEC 签名的二级域名。Comcast 等大型 ISP 以及来自威瑞信、谷歌、Quad9 和 Cloudflare 的公共递归解析器都对其用户进行了验证。此外，一些注册商已将 DNSSEC 实施纳入其安全解决方案。此外，互联网名称与数字地址分配机构 (ICANN) 已要求注册运营商为所有新的通用 TLD 实施 DNSSEC。

尽管 DNSSEC 和 SSL 都依赖于公钥加密，但它们作用各异且相互补充，并非互相取代的关系。

简单的说，DNSSEC 处理“在哪里”的问题，而 SSL 处理“谁”和“怎么做”的问题。

• 在哪里—DNSSEC 使用数字签名来验证 DNS 数据的完整性，从而确保用户可以到达预期的 IP 地址。用户登录该地址后 DNSSEC 的任务就结束了。DNSSEC 无法确保该地址对应实体的身份，也不会对用户同该站点之间的互动进行加密。
• 谁—SSL 使用数字证书来验证站点的身份。这些证书由规范的第三方授权机构 (CA) 发布，SSL 由此来让用户确定该网站所有者的身份。但是，SSL 不能确保用户登录的站点正确，所以它不能抵御那些能重定向用户的攻击。换而言之，SSL 站点验证十分有效，但前提是用户得先到达到目标站点。
• 怎么做—SSL 还使用数字证书来加密用户和站点之间的数据交换，从而保护金融交易、通信、电子商务和其它敏感互动行为的机密性。

DNSSEC 和 SSL 的共存可以让互联网更加安全可靠：用户可以确定要登录的地址、与之互动的人以及互动行为的机密性。

1994：可行性标准初稿发布
1997：RFC 2065 发布（DNSSEC 是一种 IETF 标准） 

1999：RFC 2535 发布（DNSSEC 标准被修订） 

2005 年：发布完全重写的标准 
RFC 4033（介绍和要求） 
RFC 4034（新的资源记录） 
以及 RFC 4035（协议更改） 

2010 年 7 月：根区域已签名 

2010 年 7 月：.edu 已签名 

2010 年 12 月：.net 已签名 

2011 年 3 月：.com 已签名 
 

2012 年 1 月：Comcast 宣布其客户正在使用 DNSSEC 验证解析程序 

2019 年：使用根区域的已签署委托签署 1,390 个 TLD。