如何应对来自DNSSEC的挑战

henry2000888

对DNS安全的所有问题而言，域名系统安全协议（DNSSEC）是不能包治百病的。它不能够终止路过式（drive-by）攻击、拒绝服务攻击或其他任何类型的利用社会工程学和基于顶端DNS保护服务的攻击。但它确实可以有效阻止病毒攻击和DNS骑劫，而这正是互联网电子商务的一个重大的威胁。DNSSEC正在稳步发展，早期的采用者已经开始不断发展制订技术标准和培训资料，以用来升级系统和对设备进行适当配置以适应DNSSEC。那些属于.gov域的联邦机构都必须在2009年年底前使用DNSSEC。而.Org是第一个应用了DNSSEC的域。截至到本周，已有6000个使用.edu类域名的教育机构注册了DNSSEC的服务。预计在2011年.net和.com类域名也会注册DNSSEC的解析服务。在这次采访中，PIR的管理总监（负责管理.org域名和Ram Mohan）Lance Wolak表示，他和Afilias公司的执行副总裁Ram Mohan共同分享他们在此项目上的经验，并展望了今后的DNSSEC部署的道路。 对DNS安全的所有问题而言，域名系统安全协议（DNSSEC）是不能包治百病的。它不能够终止路过式（drive-by）攻击、拒绝服务攻击或其他任何类型的利用社会工程学和基于顶端DNS保护服务的攻击。但它确实可以有效阻止病毒攻击和DNS骑劫，而这正是互联网电子商务的一个重大的威胁。DNSSEC正在稳步发展，早期的采用者已经开始不断发展制订技术标准和培训资料，以用来升级系统和对设备进行适当配置以适应DNSSEC。那些属于.gov域的联邦机构都必须在2009年年底前使用DNSSEC。而.Org是第一个应用了DNSSEC的域。截至到本周，已有6000个使用.edu类域名的教育机构注册了DNSSEC的服务。预计在2011年.net和.com类域名也会注册DNSSEC的解析服务。在这次采访中，PIR的管理总监（负责管理.org域名和Ram Mohan）Lance Wolak表示，他和Afilias公司的执行副总裁Ram Mohan共同分享他们在此项目上的经验，并展望了今后的DNSSEC部署的道路。

问：.org是第一个登录到DNSSEC的顶级域名。该项目是从什么时候开始的？为什么.org会成为第一个？

Lance Wolak：我们于6月2日成功的在.gov域实施DNSSEC，这是我们在实施中迈出的第一步，也是DNSSEC测试阶段的开端，.Gov最近也开始部署DNSSEC。虽然.Gov和.org属于通用顶级域名（GTLD），但它们却是受到高度限制的GTLD。作为首个开放式的GTLD，.org正处于蓬勃发展中。1050万个已注册的域名对于通用顶级域这个领域来说，这个数字实在是一个重要的里程碑。

Ram Mohan：对于全球超过25个地点的.org类域名的解析服务器来说，都必须有效地回应来自任何地方符合DNSSEC规范的解析请求，同时还要对请求进行通畅的响应。此外，.org还会在.org之下的空间加入其他域名。我们需要确保这些工作能够顺利的进行，而且我们已经开始开发一个程序，该程序能够确保处理域名的事务不会受到影响。我们也需要确保能够与今天操作域名一样，达到顺畅地从一个注册商的域名转到另一种域名的目的。

问：Afilias已经提供了.gov的援助？

Mohan：有人要求我们提供一些专业的意见，以及共享自己与美国政府合作的经验。为此我们将提供一些具体的意见，这些意见来自于我们委员会里的专家，以及我们同公共注册部门的合作中实施.org所积累的专业技术知识。需要学习的东西很多：例如，我们了解到，NSEC3数据是非常好的顶级域名基础，因为你不愿看见不明身分的人士提取你所有的文件，并对这些文件进行恶意的操作。我们还了解到，实施DNSSEC是以付出DNS查询和响应时间性能的降低为代价的，因为数据包比原来要大得多。所以，我们建议在提供域名解析的根（root）服务器中，改用NSEC代替NSEC3作为，因为大家都知道这个根服务器。他们也知道所有根服务器服务的顶级域名。 NSEC3增加了额外的加密文件校验操作（hash），使得你不能真正猜测出下一个条目的区域文件，并且不能为任何目的而无视任何法律约束或协议地使用它。但在根区域，大家都知道这只会包含国家代码（如cn，jp）和其他顶级域名。提高这个已经具有很好的加密标准的做法是没有额外价值的。

问：NSEC和NSEC3是否会增加带宽的需求呢？

Mohan:的确是这样，但有一个显著性差异，这个差异仅仅是因为NSEC3增加了额外的关于NSEC顶层的hash算法。和NSEC相比，NSEC3对带宽的要求更高一些。我们在自己的实验室测试中发现，NSEC增加了约5％的查询时正常响应负荷。但我们发现NSEC3则达到了15％。不同的人可能会有不同的看法，15％的可能会是一个很大的数字。在我们的实际观测中，我们得到了部署DNSSEC的.org类域名的测试结果，并且真正看到了传输控制协议（TCP）查询的显著增加，超过了一个用户数据报协议（UDP）数据包的大小。这与我们的预期基本相符，这是由于某些DNS解析服务器在配置上存在缺陷。而在NSEC3下，我们看到，TCP的流量相比于UDP通信增加了600倍。对于解析.org的域名解析服务器来说，这的确有些应付不过来。而作为测试结果而言，这其实与NSEC没有多大的区别。为此我们的已经给美国政府提出了一些意见，要小心地分配顶级的域名解析服务器，具体来说就是满足NSEC3与NSEC的较量的各自需求。


问：如何进行一次DNSSEC部署的测试？你怎么来进行测试呢？

Mohan:当你拥有自己域名的时候，一个比较大的问题是，部署DNSSEC并不方便。这不容易理解，因为还没有很好地描述DNSSEC的意义，而网络供应商的那些更容易理解的DNSSEC计划还没有付诸实施。在我们的测试和部署的规划中，我们所做的是编制手册和具体的培训计划，目的是允许一个域名所有者可以简单地按一下按钮，就能使用DNSSEC。字面上来讲只是点击一个按钮，但在注册端后台里实际有一个脚本在运行，域名的关键字（key）被加载，并且立即传播它。为了确保这种单点击能够正确实现DNSSEC的无缝部署，我们还计划做一个大的、有足够规模的测试。该测试即将在今年秋天举行。

问：对于.gov网站而言，部署DNSSEC似乎会更容易些。真是这样吗？

Mohan:我认为这个问题要从两个方面来看。第一，你如何确定你的域名注册级别。在你注册级别中，.gov域是一个较小的区域，它们对谁能得到一个.gov以及谁将使用这个.gov域名的地步有更多的控制权。但是，当涉及到网络服务提供商和互联网服务提供商（ISP）时，每个人都将面对同等难度的问题。即，他们都必须确保他们的DNS解析器是以适当的方式发送和转发处理一个DNSSEC的要求。第二，这些网络服务供应商和互联网供应商还必须知道如何处理一个域名被撤销的情况。现在的DNS是完全不安全的。你可以通过它驾驭Mac这个“大卡车”，而我们正在做的事就是DNS中增加这个卡车的锁和钥匙，但在DNS解析端的人开始学习如何改变自己的程序和方法，这样即使某个钥匙发生了改变，也可以有新的钥匙能够快速准确的添加到自己的域名解析服务器中。

问：现在关键字的管理问题仍未得到解决？

Mohan:是的。在域名注册的级别上，虽然我们已经对关键字的管理掌握得炉火纯青了，但在网络服务层次上，某些方面仍然存在些许问题没有解决。

问：采用何种方法来解决这个问题呢？

Mohan: PIR已开始与网络注册安全组（RISG）展开了一项不错的计划。我们的系统管理员和网络工程师已经着手这件事，他们知道如何才能做到这一点。但是，如果他们正在运行着BIND，那么必须先转到DNSSEC的决议。首先，DNSSEC能理解和执行配置的更改。其次，当缺乏足够的培训时，没有民间社会组织或IT主管会讨论是否有必要花50万美元为整个基础设施购买一台新的路由器，或者是否有必要将针对带宽的基础设施从T1升级到一个T3水平。事实上，除了这些实际情况以外，人们还有很多不必要的恐惧、不安和疑虑。我们正在试图让事实说话，它将不会消耗更多的带宽，或要求用户进行一个较大的硬件升级（事实上，一般而言，它没有任何硬件升级），而在大多数情况下，它只是一个配置更改或软件升级。

问：你们每隔多久会不得不淘汰或者更换设备呢？

Mohan:关于这个问题，我们已经有了很多经验。我也与瑞典的朋友们谈过这个问题。瑞典是世界上第一个部署DNSSEC的国家，在域名的注册级别上没有升级需要，而在注册级别也确实没做什么重大的升级，只是做了一些寻常的升级和首要的替代程序。同样，对于ISP来说也不需要升级。但是，如果一些地方出现了问题，那么我预计可能有升级的需要，比如家庭路由器。那些在2003年以前购入的家庭老式路由器虽然能够支持DNS协议，并对DNS请求进行解析，但在很多情况下这种路由器必须进行更换，从而支持现在的网络要求。当然，话又说回来，我们还没有看到任何超出家庭承受能力的巨大升级需要。

http://netsecurity.51cto.com/art/200909/153883_1.htm

【推荐】

对DNS安全的所有问题而言，域名系统安全协议（DNSSEC）是不能包治百病的。它不能够终止路过式（drive-by）攻击、拒绝服务攻击或其他任何类型的利用社会工程学和基于顶端DNS保护服务的攻击。当涉及到网络服务提供商和互联网服务提供商（ISP）时，每个人都将面对同等难度的问题。即，他们都必须确保他们的DNS解析器是以适当的方式发送和转发处理一个DNSSEC的要求。第二，这些网络服务供应商和互联网供应商还必须知道如何处理一个域名被撤销的情况。现在的DNS是完全不安全的。你可以通过它驾驭Mac这个“大卡车”，而我们正在做的事就是DNS中增加这个卡车的锁和钥匙，但在DNS解析端的人开始学习如何改变自己的程序和方法，这样即使某个钥匙发生了改变，也可以有新的钥匙能够快速准确的添加到自己的域名解析服务器中。