创新

域名系统安全扩展 (DNSSEC)

从端到端验证互联网

有关 DNSSEC 的常见问题

DNSSEC 的作用是什么?

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

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

DNSSEC 的受益者是谁?

DNSSEC 影响着互联网基础设施生态系统的每一个部分。要将其进行有效部署,需要互联网社区中许多利益相关者的参与。注册机构、注册商、域名注册人、软硬件供应商、ISP、政府机构以及普通互联网用户都在其中发挥作用,才能确保 DNSSEC 获得成功,提高互联网的安全性。DNSSEC 可帮助:

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

DNSSEC 的工作原理是什么?

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

当最终用户想访问网站时,用户操作系统中的根解析器会向 ISP 处的递归名称服务器请求域名记录。服务器请求该记录后,还会请求与该区域对应的 DNSSEC 密钥。该密钥允许服务器验证其接收的信息是否与授权名称服务器上的记录一致。

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

DNSSEC 在多大程度上能够解决总体互联网安全问题?

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

用户如何得知自己受到攻击?

互联网社区还没有制定出可以通知用户其被攻击的标准化系统。一个可能的解决方案是开发“DNSSEC-识别”浏览器来通知用户其已被定向到经过验证的地址。

实施 DNSSEC 时威瑞信将做什么?

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

威瑞信的 DNSSEC 部署策略是什么?

我们的 DNSSEC 的部署策略是:从小型区域开始,从每一次的部署中吸取经验,然后再部署下一个区域。因为 .com 区域是最大的,我们将最后为它部署 DNSSEC。我们希望获取尽可能多的经验,然后再涉足这个区域,毕竟该区域涉及全世界如此之多的互联网商务和通信。

DNSSEC 要想成功,需要什么条件?

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

谁已采用或部署 DNSSEC?

互联网根区域、.gov、.org、.museum 等顶级域 (TLD) 以及大量国家代码 TLD (ccTLD) 都已为所管理的区域签名。.edu、.net 和 .com 等其他 TLD 在 2010 和 2011 年部署了 DNSSEC。这些 TLD 已经开始接受 DNSSEC 签名的二级域名。Comcast 等大型 ISP 已在递归名称服务器上启用验证机制来响应用户查询,同时,一些注册商已经在他们的规划蓝图中加入了 DNSSEC 部署。此外,互联网名称与数字地址分配机构 (ICANN) 已为新 TLD 开放申请,有可能会在审批新 TLD 申请时将 DNSSEC 部署作为通过条件之一。

部署 DNSSEC 后,我还需要安全套接字层 (SSL) 吗?

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

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

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

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

DNSSEC 是法律或行业标准强制要求的吗?

在美国,行政管理和预算局 (OMB) 备忘录 08-23 规定,2009 年 1 月前应将 DNSSEC 部署到顶级 .gov 域中,并规定美国联邦机构于 2009 年 12 月前在外部站点部署 DNSSEC。.gov 在 2009 年初已部署了 DNSSEC。美国国防信息系统局也准备在 .mil 域中遵循 OMB DNSSEC 要求。美国联邦信息安全管理法案 (FISMA) 要求机构于 2010 年年中之前在他们的内网部署 DNSSEC。目前,没有规定要求公共网站运营商在其域中部署 DNSSEC。

DNSSEC 的发展历史?

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 年 2 月:向威瑞信转移已启用 DNSSEC 的 .gov 注册表 

2011 年 3 月:.com 已签名 

2011 年 3 月:Verisign Managed DNS 服务增强,完全支持 DNSSEC 合规性 

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

2012 年 3 月:所部署的 TLD 数量增加至 90