域名系统的安全协议DNSSEC全面解析

　　 
　　现在看来，Internet基础结构之一的域名系统（DNS）是一个不安全的协议，因此也就导致了Internet上域名安全问题逐渐为人们所重视。
　　

　　DNS是一个层次化的数据库，它包括一系列记录，描述了名称、IP地址和其他关于主机的信息。这些数据库驻留在DNS服务器中，DNS服务器和Internet或Intranet互连。简单地说，DNS就是为需要定位指定服务器的网络应用提供一个名称到地址的目录服务。例如，用户每发送一个电子邮件或者访问一个Web网页，都必须有一个DNS名。
　　
　　问题在于用户无法知道DNS应答的来源是否正确或者是否包含正确的数据。只要稍微学习一下，甚至一个十几岁的黑客都可以用错误数据来破坏DNS服务器，而Web客户机却识别不出错误数据。这样就带来很大的麻烦，因为DNS经常被用作默认的认证系统。
　　
　　例如，当一个用户在浏览器上点击一家报纸的网站时，他期望看到的网页是那家报纸的。但是，DNS协议并不包含任何可以证明该网页正确的机制，即该网页确实是他期望的那家报纸的网页。还会有一种更危险的情况出现，某些组织为了达到某种目的，把毫无防范的用户引导到一个对该报纸进行批评、或者蓄意篡改该报纸内容甚至以诽谤的方式对事件进行错误报道的Web 服务器上。
　　
　　为了解决这一问题，IETF正在着手在DNS协议里加入安全扩展协议，也就是所谓的域名系统的安全协议（Domain Name System SECurity，DNSSEC）。
　　
　　DNS的产生
　　
　　在DNS之前，每个新的主机都必须添加到位于斯坦福研究院的网络信息中心（Stanford Reseach Institute's Network Information Center，SRI-NIC）的中央存储设备里。直到90年代初，一直由该中心负责维护这些信息。SRI-NIC经常发布主机信息的文件，Arpanet（Internet的前身）上的所有主机就拷贝这些文件。这种机制在Internet上只有少量主机时是可以运作的，但是随着Internet的增长，这种机制就不稳定了。
　　
　　此外，这种机制中域名管理的结构非常简单。因此，每一个在SRI-NIC注册的主机名都必须是惟一的。例如，那时侯在Internet上，无论在哪里都不可能有2个主机同时叫做www。后来，SRI-NIC终于让位给DNS。
　　
　　DNS对Internet最重要的贡献之一就是它可以在全球范围内把可以识别的主机名惟一地映射成IP地址，即所谓的前向映射。DNS还有一些其他功能，包括反向映射（IP地址到主机名的解析）、邮件交换信息（给一个给定主机或者域确定一个邮件交换器）以及规范命名（系统化的命名方案）。
　　
　　DNS的结构和缺陷
　　
　　DNS采用层次化结构，使得主机名可以惟一化。DNS的结构为反向树结构，由树叶走向树根就可以形成一个全资格域名（Fully Qualified Domain Name，FQDN），每个FQDN是惟一的。在树中，由根到叶给出主机名查询结果，以便于找到属于这台主机的IP地址。对于反向映射也有类似的树存在，在树中检索查询IP地址的目的是为了找到属于这个IP地址的主机名或者FQDN。
　　
　　反向树的顶端是DNS的根，通常以“.”表示，并且是FQDN中的最后一个字符。根下面的第一级划分为大组，例如组织类（org）、工商类（com）和教育类（edu）等等。再下面一级通常表示一个特定的直接在org、edu和com域下面的组织或者公司。例如isc.org 或者 vix.com。“isc”和“vix”也都被认为是域名。
　　
　　这种划分域名的方式使得每个主机都可以在其归属的域（或者子域）内有惟一的定义。这样本地管理员就可以管理（增加、删除或者改动）DNS主机名和地址。DNS可以进行主机名本地管理的能力提供了巨大的灵活性和可扩展性。
　　
　　DNS所做的另一项改进是提高每个域中包含信息的可用性。除了主服务器外，其余的都成为二级或从服务器。每个域都有一个以上的从服务器。这些从服务器负责检验主服务器的数据更新，如果检测到有一个数据更新，从服务器就传送域的数据，也就是所谓的域传递。
　　
　　每个域都有一个序列号，当主服务器上的域数据更新时，就要调整这个序列号。这种调整使得在服务器上检测到数据更新变得很容易。而能够同时拥有一个以上域备份的能力可以冗余分配负载，使数据非常可靠。
　　
　　DNS高效率的设计同时也带来了负面影响，那就是众多的安全性漏洞。例如，当一个远程系统连接了一个应用程序后，该应用程序使用IP地址向DNS服务器查询DNS域名，如果返回的域名被该应用程序所认可，那么该远程系统也具备访问权限。
　　
　　实际上，一个恶意使用者能够非常轻松地抢占到一个很小的IP地址空间，同时在DNS服务器上注册，获取这些IP地址的反向映射。
　　
　　密码签名
　　
　　由于DNS协议的局限，IETF已成立了DNSSEC工作组，目的是在现有的协议上增添附加的DNSSEC部分，从而解决DNS缺乏安全性的问题。伯克利Internet域名保护协议（Berkeley Internet Name Daemon，BIND） 8.2中包含了一些DNSSEC的功能。
　　
　　DNSSEC的目标就是为在DNS内部的信息同时提供权限认证和信息完整性（参看附图）。DNSSEC通过密码可以实现这些目标。
　　
　　附图显示的是一对DNS询问和应答过程的示例，一个没有采用DNSSEC协议，另一个采用了DNSSEC协议。注意，在采用DNSSEC协议的例子中，应答信息中不仅包含了验证信息所需的签名和关键字，而且包含了原始的询问。这就是所谓的“事务处理和请求认证”。这种方式向询问者保证所得到的应答确实是针对其原始问题的。
　　
　　DNSSEC主要依靠公钥技术对于包含在DNS中的信息创建密码签名。密码签名通过计算出一个密码hash数来提供DNS中数据的完整性，并将该hash 数封装进行保护。私/公钥对中的私钥用来封装hash数，然后可以用公钥把hash数译出来。如果这个译出的hash值匹配接收者刚刚计算出来的hash树，那么表明数据是完整的。
　　
　　不管译出来的hash数和计算出来的hash数是否匹配，对于密码签名这种认证方式都是绝对正确的，因为公钥仅仅用于解密合法的hash数，所以只有拥有私钥的拥有者可以加密这些信息。因此，对于任何系统，开发保护私钥的公钥技术是至关重要的。DNSSEC工作组定义的RFC 2541中解释了这个问题。
　　
　　DNSSEC的缺点
　　
　　标记和校验DNS数据显然会产生额外的开销，从而影响网络和服务器的性能。签名的数据量很大，这就加重了DNS对Internet骨干网以及一些非骨干连接的负担。产生和校验签名也占用了很多CPU的时间。有时候，不得不把单处理器的DNS服务器换成多处理器的DNSSEC服务器。签名和密钥占用的磁盘空间和RAM容量达到它们表示的数据所占容量的10倍。同时数据库和管理系统也不得不进行相应的升级和扩容。
　　
　　使用DNSSEC还有若干种直接的损失。相对于老的、只有DNS的软件，DNSSEC软件又庞大又复杂，许多软件还很新，需要进行实际操作和测试。DNSSEC还没有和Internet的迅速发展同步，仍然有一些疑点，可能需要进一步检查。
　　
　　开发DNSSEC也有一定的风险。谨慎的选择是在DNSSEC RFC提升为标准状态后再等一两年。到1999年12月，只有ISC的BIND 8.2完全使用了TSIG并部分使用了DNSSEC。其他销售商（包括微软）在未来版本中都将使用各种形式的TSIG。ISC的BIND 9.0将于2000年第一季度发表，它完全采用了DNSSEC。
　　
　　工作进展
　　
　　对于DNSSEC在可操作方面的工作正在进行之中，比如com管理者如何正确地签发公钥。为了解决这个问题，一个新的协议即将出现。此外，在同时发生的应用中支持多个公/私钥对也是必要的，但是如何实现还有待进一步的工作。如果一个私钥被破坏，那么就需要取消，可是目前还没有一个设备可以检测出来有错误的密钥。还有私钥的安全问题，该密钥从表面上讲是全球Internet企业的密钥，但是目前有关服务器的管理正在变化之中。
　　
　　尽管DNSSEC还处在开发过程中，但是任何依赖于Internet的组织都应该把DNSSEC作为系统安全结构里的关键部件，因为DNS协议会因为恶意使用而遭到破坏，只有通过DNSSEC强大的加密技术才可以给所有方面的DNS提供整体的授权。

原文转自：http://www.ltesting.net