秦臻，肖春静，李乐民

（1.电子科技大学 通信与信息工程学院，四川 成都 610054；2.电子科技大学 计算机科学与工程学院，四川 成都 610054）

1 引言

域名解析系统（DNS）是重要的互联网基础设施，将网络域名（例如www.example.com）解析为与之相对应的IP地址（例如10.0.0.1）。基于互联网的各种Web服务、E-mail服务等都可能依赖DNS。现行的 DNS采用分布式层级结构设计，由域名解析器和一系列域名服务器构成。解析一个域名时，用户将域名解析请求发送给域名解析器，由其进行解析。如果域名解析器缓存中存有该请求的 DNS记录，则域名解析器立即响应用户的请求，将该DNS记录返回给用户。否则，域名解析器需要通过递归查询、访问各级域名服务器，获取该域名的DNS记录，再将其返回给用户[1～3]。然而，随着近10多年来互联网的发展，新出现的技术不断改变网络环境，传统的域名解析服务在性能和安全上逐渐显现出一些问题。

1) DNS查询延迟。由于网页往往嵌入多个链接，打开一个网页需要从多个域名中获取数据。DNS查询延迟成为影响打开网页所需时间的主要因素[4]。DNS记录在域名解析器的缓存有助于提高查询速度。为了解析一个未缓存的域名，域名解析器需要以递归查询的方式，访问各级域名服务器[5]。此外，由于服务器不可达、数据分组丢失等因素，域名解析请求的未响应率为 4%～6%。据统计，300～400ms为解析一个域名所需的平均时间[4]。

2) DNS更新延迟。TTL机制是现行的域名解析系统所采用的DNS记录更新方式。DNS记录中的TTL字段决定了DNS记录的更新延迟。TTL值的大小指示了该 DNS记录能缓存在域名解析器中时间的长短。对于域名解析器缓存中的 DNS记录，若域名服务器上该 DNS记录出现更新，该缓存的DNS记录则是冗余的信息。若此时解析该域名，则可能出现异常，需要等待域名解析器缓存中该域名DNS记录的TTL值过期后，域名解析器以“拉”的方式，访问相应的域名服务器以获取更新后的DNS记录。一个合适的TTL值是不易设置的。TTL值过大不利于服务搬迁和DNS记录更新。TTL值过小则不利于缩短 DNS查询延迟，同时增加网络和服务器的负载[6]。许多域名DNS记录的TTL值设置为几小时，但DNS记录往往稳定数月[5,7]，可见，TTL机制并不是很好地适用于DNS记录的更新。

3) 网络故障和DoS攻击的应变能力。DNS容易受到网络故障的影响，也容易受到DoS攻击。这是因为一个域名往往只由少数几个域名服务器来提供域名解析服务[1]。据研究[6]，只有 2个域名服务器的域名为78.32%，而且只有1个域名服务器的域名为0.82%。研究还发现，仅由3个或者更少的域名服务器来提供域名解析服务的域名超过90%。小规模的网络故障或网络攻击就可以使其不能正常服务。近期的研究报告表明[8]，尽管有87%～96%的域名有2个以上的域名服务器，但域名服务器在相同的自治域（autonomous system）内的域名为82%，域名服务器属于同一网段（据有相同的IP前缀）的域名为61%。这些都降低了域名解析服务对网络故障和DoS攻击的应变能力。

4) 配置错误和管理复杂度。域名DNS记录的管理是一项复杂的任务，很多性能上和安全上的问题都源自配置错误[5]。例如，一个典型的安全隐患就是域名服务器之间DNS记录的传输[8]。管理域名服务器的软件使用起来很复杂，并需要具有专业知识的人员进行服务器维护和配置。此外，在域名解析器端的不当配置也会造成一些问题[5]。

5) DNS滥用。DNS已经成为各种网络攻击的首选工具。例如，恶意的广告系统用一次性的域名来发布恶意或虚假的内容；匿名注册的域名被钓鱼网站用来窃取私人信息；Fast-Flux网络通过使用短TTL值的DNS记录来频繁地切换IP地址，以跳出防火墙黑名单等[9]。

本文研究了近年来学术界和产业界关于域名解析服务的相关工作，结合云的内容发布、存储特点和域名解析服务的具体需求，提出了一种新型的、可增量部署、现行 DNS兼容的、具有更好性能的域名解析服务模型。

2 相关研究

由于多播技术的发展和磁盘存储技术的进步，Kangasharju和Ross在INFOCOM会议上提出了一种新型的 DNS记录发布方式[10]，在全球分布的服务器上广泛地复制 DNS记录。为了同步和更新各服务器上DNS记录，该设计提出使用者IP多播或卫星信道的方式来发布 DNS记录。该设计思想实现了将 DNS记录复制到广泛分布的副本服务器概念，但却受限于TTL机制，高频率更新的DNS记录（尤其是小TTL值的DNS记录）給系统带来巨大的通信压力。

Cooperative domain name system（CoDNS）是Ramasubramanian和Sirer[6]在SIGCOMM会议上提出的一种新型的DNS构架。该架构通过将DNS记录缓存在分布式散列表上，降低 DNS查询延迟，实现高性能的DNS查询。但是，CoDNS未能解决动态域名技术带来的问题，即域名服务器根据内容服务器和网络的状况来动态地匹配域名和IP地址。此外，该架构不适用于小TTL值的DNS记录（比如，小于30s），因为它会产生极高的系统开销。所以，当面临用户请求解析小TTL值DNS记录时，CoDNS会将用户定向到现行的域名解析系统，造成额外的 DNS查询延迟。此外，在解析某个域名之前，如何确定该域名DNS记录TTL值的大小也是有待解决的问题。

为提高域名服务对网络故障和 DoS攻击的应变能力，Handley等[11]提出了P2P传输的方式，在全球分布的服务器上复制 DNS记录。该方法实现了在众多网络实体中共享 DNS记录，各实体协作提供域名解析服务。该方法需要一组能够协同合作、相互信任的网络实体（分布的服务器），才能保证域名解析服务的高效、安全和可靠。

通过全面、系统地分析了当前的 DNS架构，Deegan等[5]指出了其中的不足。他们提出一个集中的发布机制能更有效地适合于发布 DNS记录。实际上，在维持域名的 DNS记录不变这一前提下，可以通过任何合适的方式来取代目前的 DNS记录发布机制。

综上所述，学术界展开了一系列关于大规模发布和缓存 DNS记录的研究，它们将 DNS记录以“拉”的方式复制到各个分布的服务器上。在域名解析器端（或其附近）的服务器上复制DNS记录，能够缩短 DNS查询延迟、提高域名解析服务的可靠性；在域名服务器端复制 DNS记录时，则能够提高域名解析服务对网络故障和 DoS攻击的应变能力。然而，由于受限于TTL机制，以“拉”的方式在域名解析器端复制的DNS记录是非权威的DNS记录，当 TTL值过期后，需要再次更新该DNS记录。可见，在域名解析器端这样的更新会造成高额的系统开销（尤其是小TTL值的DNS记录，需要频繁地更新）。这也是上述研究没能解决的问题。

由于缺少激励机制，上述学术界的改进方案未能得到广泛的应用和部署。近年来，在商业利益驱使下，为了获取域名解析服务背后的用户信息，许多公司开始提供新型的域名解析服务，例如，Google Public DNS和OpenDNS[12,13]。基于云技术，它们通过共享缓存、提前获取 DNS记录等方法，提高了DNS请求的cache-hit rate（域名解析器缓存中存有该DNS请求的几率），缩短了DNS查询延迟。使用这类域名解析服务，平均 DNS查询延迟为 100～200ms。事实上，Google Public DNS和OpenDNS也是[13]以“拉”的方式主动复制DNS记录，同样受限于TTL机制，故仅对一小部分的域名实施共享缓存,提前获取DNS记录的方法。

本文的研究则在公共域名解析器的基础上更进一步，基于云技术，利用云及其网络架构，构建一套完整的域名解析服务模型，包括域名解析器和域名服务器的功能。

3 模型设计

解析一个域名所需要的时间取决于域名解析器访问各级域名服务器的往返通信延迟（RTT）[14]。若结合域名解析器和域名服务器的功能于某网络实体，能将极大地提高域名解析服务的效率。本节将提出基于云的域名解析服务模型，它将域名解析器和域名服务器的功能结合于云的节点服务器上，实现高性能的域名解析。

基于云的域名解析服务模型设计的核心思想是:由广泛分布的云节点服务器组成系统，利用云的内容发布和存储机制，以“推”的方式，在广泛分布的节点服务器上发布所有域名的权威DNS记录；同时，各节点服务器可以取代现行DNS架构中的域名解析器和域名服务器。在此服务模型中，节点服务器将维持所有域名的DNS记录。在具体介绍此服务模型的架构之前，先简单估算维持所有域名的 DNS记录对节点服务器存储空间的要求。

3.1 节点服务器维持所有DNS记录的可行性

这里，本文将估算节点服务器维持所有域名的DNS记录对存储空间的需求。在少数情况下，一个域名可能对应多个IP地址，为了简单起见，假设每个域名对应一个IP地址。据到2010年第三季度的统计[15]，全球注册的域名数量为近201800000个。域名的长度一般为10～20个字符，可估算，存储一条A类DNS记录所需要的空间约为40byte（其中，域名约占20byte，一个IP地址占4byte，其他信息占16byte）。这样，8GB的空间即可存储2亿个域名的A类DNS记录。

上述估计，只考虑了域名的A类DNS记录，而域名的DNS记录中还包含了CNAME类DNS记录、SOA类DNS记录、MX类DNS记录、PTR类DNS记录和NS类DNS记录。这里要指出的是，所有域名的A类DNS记录都维持在节点服务器上，NS类DNS记录不必再使用；此外，绝大部分域名也未使用CNAME类DNS记录，保守估计约40GB的存储空间即可维持所有域名的 DNS记录。就目前的缓存技术和磁盘存储技术而言，节点服务器完全有能力维持所有域名的 DNS记录，所以节点服务维持所有域名的DNS记录是可行的。

3.2 模型架构

图1所示的为基于云的域名解析服务模型，此服务模型包括了现行 DNS架构中权威域名服务器和域名解析器的功能，是一个完整的架构。权威域名服务器维持域名权威的 DNS记录，域名解析器响应用户的域名解析请求。

图1 基于云的域名解析服务模型

在此服务模型中，DNS记录以“推”的方式发布。通过云的内容管理服务器，域名所有者将DNS记录发布到广泛分布的云节点服务器上。这样，云的节点服务器就可以发挥现行 DNS架构中二级域名服务器（权威域名服务器）的功能，其维持的DNS记录是权威的DNS记录，由域名所有者直接管理。由于任何更新的 DNS记录都将由内容发布服务器在第一时间发布到各节点服务器，故节点服务器上的DNS记录可不必使用TTL字段，不受TTL机制的限制，。

在解析域名方面，现行 DNS架构中的域名解析器由云的节点服务器取代（基于IP Anycast路由技术[16]，使用相同的IP地址），用户的域名解析请求将被指向到附近的任何一个正常工作的节点服务器。当解析一个域名时，由于节点服务器上维持了所有域名的 DNS记录，不需要访问任何额外的服务器，可立即响应用户的域名解析请求。用户到节点服务器的往返延迟决定了解析一个域名所需的时间。大型的云架构拥有广泛分布的节点服务器，既可缩短用户到节点服务器的往返延迟，又可避免某个节点服务器出现负载过重的情况。5.1节将通过实验评估此服务模型域名解析的效率，即DNS查询延迟。

在上述模型中，结合了域名解析器和域名服务器功能的云的节点服务器将使用2个公网IP地址:一个为原云架构所配置的IP地址，用于云架构内部数据的传输和同步[17,18]（本文的设计则是利用该IP地址在云架构中发布和更新DNS记录）；另一个为云的节点服务器共用的 IP地址，基于 IP Anycast路由技术[16]，用于对外提供域名解析服务。

3.3 管理、发布和更新DNS记录

图2所示为基于云的域名解析服务模型管理、发布和更新 DNS记录的方式。域名所有者将维护域名服务器的工作外包给云，仅需使用客户端软件来管理 DNS记录。为避免假冒攻击，保证每个域名的 DNS记录只能由其域名所有者修改，只有在认证后，云的内容管理服务器才会将更新的 DNS记录发布到各节点服务器。此外，由于所有域名的A类DNS记录都维持于节点服务器上，不再需要配置NS类DNS记录。这种管理方式可极大地降低错误配置对域名解析服务造成的不利影响。

图2 管理、发布和更新DNS记录

在发布 DNS记录方面，基于云的域名解析服务模型利用云的内容发布机制，以“推”的方式发布 DNS记录。在通过认证和授权后，云的内容管理服务器将权威的DNS记录发布到各节点服务器。既然是权威的DNS记录，则不受TTL机制的限制，可不必使用TTL字段。

在更新 DNS记录方面，一般只有在进行服务搬迁或重新分配内容服务器资源时，域名服务器上的DNS记录才会更新，故域名的DNS记录往往稳定数月不变[5,7]。在基于云的域名解析服务模型中，只有当域名所有者需要更新 DNS记录（即进行服务搬迁或重新分配内容服务器资源）时，内容管理服务器才会将该域名更新的 DNS记录发布到各节点服务器，以取代原来冗余的信息。可见，以“推”的方式，在节点服务器上维持所有域名的权威DNS记录，并不会给系统带来通信压力。对于现行的Google Public DNS和OpenDNS[12,13]，则是以“拉”的方式在节点服务器上维持域名非权威的 DNS记录，受限于TTL机制，若要维持所有域名非权威的DNS记录则会造成大量的系统开销。

实际上，在没有域名解析系统的互联网初期，网络信息中心（network information center）也是以“推”的方式发布HOST.TXT文件（用户记录DNS信息）。但是，随着互联网的发展，其规模不断扩大，维持大小不断增加的HOST.TXT文件的同步和更新变得越加困难。尽管也是采用“推”的方式，由于各域名DNS记录的发布和更新过程相互独立，基于云的域名解析服务模型并不需要使用一个类似于HOST.TXT的文件来统一发布和更新DNS记录。

为了评估基于云的域名解析服务模型中 DNS记录发布和更新机制产生的通信量，本文进行了为期20天的实验，每天对265262个域名（域名来源见第5节）的A类DNS记录进行查询。实验结果显示每天只有1.3%～1.6%的域名更新了DNS记录。这里，假定DNS记录以每天1.6%的更新率，云的节点服务器上维持有40G的DNS记录。由此，可以计算出每个节点服务器只需要维持一个7.77kbit/s（这一数量级）的数据流就可以实现DNS记录的发布和更新。

现阶段，团结乡乡村旅游发展依然停留在低层次的“做农家事，吃农家饭，住农家房”的农家乐发展模式。经营者大多将垂钓休闲、采摘水果和农业观光作为主打产品。在某种程度上，旅游项目相对来说是十分单一的，没有充分挖掘农业文化和民俗文化的内涵，缺乏新的旅游特色[2]。

3.4 增量部署能力和兼容性

任何系统若要取代现行系统，增量部署能力是必须的。基于云的域名解析服务部署需要域名所有者的配合，通过云的内容发布机制，将域名的DNS记录发布到各分布的节点服务器。然而，这样的服务迁移不可能一蹴而就，针对只有部分用户和域名所有者使用此域名解析服务模型的情况，本文提出了可增量部署的服务模型。

图3所示为可增量部署的服务模型，实现基于云的域名解析服务模型与现行 DNS的兼容。若用户使用云的节点服务器作为域名解析器，对于通过此架构发布和更新DNS记录的域名，如3.2节所述，可立即将所查询域名的 DNS记录返回给用户；对于未使用此架构的域名，节点服务器作为域名解析器，可查询其缓存中非权威的 DNS记录，或以递归查询的方式访问现行 DNS架构中的各级域名服务器，解析该域名，最后将该域名的 DNS记录返回给用户，流程如图3中a1→a2→a3→a4→a5所示。若用户使用现行 DNS架构中的域名解析器，对于通过此架构发布和更新 DNS记录的域名，节点服务器作为二级域名服务器注册于现行DNS架构下，响应域名解析器的查询请求，流程如图3中b1→b2→b3→b4→b5所示。

图3 可增量部署的服务模型

由此可见，基于云的域名解析服务模型虽然采用了新颖的方法来提供域名解析服务，但它可很好地兼容于现行的域名解析系统，实现增量部署。在增量部署此服务模型的过程中，不论用户选取何种域名解析器，域名所有者以何种方式发布 DNS记录，它不会对域名解析服务造成任何不利的影响，同时还能在性能和安全上（第4节将具体分析）提高域名解析服务的质量。故此服务模型可逐渐吸引用户和域名所有者，进而可渐进地取代现行的域名解析系统。

4 特性分析

引言介绍了现行 DNS存在性能或安全上的问题，下面结合本文的设计，对它们进行对比分析。

1) 降低查询延迟。在现行DNS架构下，若要解析一个未缓存的 DNS记录，域名解析器需要以递归查询的方式访问多个域名服务器以获取该DNS记录。域名解析器到用户和各级域名服务器的往返延迟决定了 DNS查询延迟。在本文提出的服务模型下，节点服务器上维持所有域名的权威DNS记录，同时也是域名解析器，可直接响应域名解析请求而不需要访问其他服务器，DNS查询延迟仅取决于用户到节点服务器的往返延迟。第5节的实验证明，用户到节点服务器的往返延迟远小于域名解析器到用户和各级域名服务器的往返延迟。

2) 解决更新延迟问题。TTL机制是造成 DNS更新延迟的根本原因。DNS记录TTL值的大小，指示了其可缓存在域名解析器中的时间长短。在TTL值有效期内，域名解析器会直接将缓存中的DNS记录返回给用户，若在这段时间内权威域名服务器上更新了 DNS记录，则域名解析器缓存中的DNS记录成为冗余信息。本文的设计将权威的DNS记录发布到广泛分布的节点服务器上，不受TTL机制的限制，从根本上解决了这一问题。

3) 提高对网络故障和DoS攻击的应变能力。在现行DNS架构中，一个域名的域名服务器往往不多于3个，而且这些域名服务器往往位于同一个IP网段或自治域（autonomous system），网络故障和DoS攻击很容易影响域名解析服务。本文的设计可使所有域名的权威DNS记录在全球范围内广泛分布的节点服务器上发布和更新。即使某个节点服务器遇到网络故障或受到DoS攻击，在本文提出的模型中，通过IP Anycast路由，用户的域名解析请求仍可被定向到其他正常工作的节点服务器，完成域名解析。该模型具有较强的应对网络故障和DoS攻击能力。

4) 降低管理复杂性。域名服务器上的DNS记录的管理是一项复杂的工作，需要管理人员据有专业的知识使用域名服务器软件进行维护和配置。维护和配置不当，会造成一系列的问题。对于本文提出的设计，在维护方面，域名所有者将域名服务器的维护工作外包给云，不需要对域名服务器进行维护；在配置方面，由于不必使用NS类DNS记录，且DNS记录不必使用TTL字段，可降低出现人为配置错误的可能性。

钓鱼网站攻击主要是通过伪造非权威的 DNS记录，污染域名解析器缓存，进而实施的攻击。为降低这类攻击的威胁，可对访问域名解析器的 IP地址进行限制，但白名单中的IP地址仍可实施该攻击。然而，由于管理和配置上的疏忽，互联网上大量的域名解析器存在该攻击漏洞。对于 Google Public DNS这类公共的域名解析器，它们没有限制用户IP地址，而是使用IETF RFC 5452[19]中的方法，降低域名解析器缓存被污染的机率。在本文提出的设计中，对于用户的域名解析请求，返回的都是权威的DNS记录，从根本上解决了钓鱼网站攻击这类以伪造DNS记录、污染缓存而实施攻击的问题。

为在互联网上发布虚假的、非法的信息，Fast-Flux网络以快速更变域名的 IP地址方式来跳出防火墙黑名单。在 Fast-Flux网络的域名服务器端，DNS记录使用很小的TTL值，以Round-Robin方法频繁更换IP地址。在本文提出的设计中，任何更新的 DNS记录都是由云的内容管理服务器发布到各节点服务器。内容管理服务器可轻易检测和限制恶意或可疑的行为（例如，Fast-Flux网络）。

5 实验评估

下面通过大规模实验对基于云的域名解析服务模型性能进行评估。实验使用的域名集合来自于美国西北大学连续4个月的DNS查询日志中一段为期24 h的片段。这组24 h的DNS查询日志片段一共包含了13884065次DNS查询，解析了265262个不同域名。

实验平台为PlanetLab[20]，通过使用不同的域名解析服务，对上述域名集合进行解析，比较各域名解析服务的性能。PlanetLab平台由1074个节点组成，分布于530个不同地理位置[20]。本实验一共使用了其中的 140个位于不同地理位置PlanetLab节点，其中，北美洲78个，欧洲35个，亚洲16个，其他地区11个。这样，每个PlanetLab节点可代表不同地理位置的用户群体，分别使用 4种域名解析器（ISP提供的域名解析器、Google Public DNS、OpenDNS和云的节点服务器）来解析上述的265262个域名。实验结果显示，基于云的域名解析服务模型在查询延迟、更新延迟、可靠性等各方面都体现出优越性，下面逐一分析。

5.1 DNS查询延迟

已有研究利用域名解析服务递归查询的DNS查询延迟来估算互联网上2节点之间的RTT[14]；这里，本文是利用互联网上2节点之间的RTT来估算DNS查询延迟。若域名解析器缓存中存有与DNS请求相应的DNS记录，DNS查询延迟可以很准确地用域名解析器到用户的 RTT来估算；DNS递归查询的延迟也可通过域名解析器到用户和各级域名服务器的RTT来估算。笔者通过实验验证，对于域名解析器缓存中维持的DNS记录，平均 DNS查询延迟仅比域名解析器到用户的RTT大2ms左右。

在基于云的域名解析服务模型中，云的节点服务器上维持有所有域名的 DNS记录，域名解析过程中不必再进行递归查询，用户仅需访问云的节点服务器即可获取DNS记录。因此，基于云的域名解析服务模型的DNS查询可以通过测量云的节点服务器到用户的RTT来评估。这里，实验通过测量Google Public DNS云架构的节点服务器到PlanetLab节点的RTT来估算基于云的域名解析服务模型的DNS查询延迟。对于其他3种情况，各PlanetLab节点依次使用3种域名解析器，通过现行DNS架构，解析上述的265262个域名。

图4所示为4种域名解析服务DNS查询延迟的累积分布。可以注意到，相对于其他3种域名解析服务，基于云的域名解析服务模型的 DNS查询延迟明显较低。具体来说，Google Public DNS云架构的节点服务器到各PlanetLab节点RTT的中位数约为50ms；使用Google Public DNS和OpenDNS这类公共的域名解析器，DNS查询延迟的中位数约为100ms；而使用ISP的域名解析器，DNS查询延迟的中位数约为230ms。由此可见，若基于云的域名解析服务模型应用于Google Public DNS的云架构上，可将DNS查询延迟缩短2～4倍。随着Google Public DNS云架构规模的扩大（目前，Google Public DNS云架构的节点服务器仅为40个左右）或将此服务模型应用于其他更大规模的云架构上，DNS查询效率可得到进一步的提高。

图4 DNS查询延迟的累积分布

5.2 DNS更新延迟

在现行DNS架构中，TTL机制造成了DNS记录的更新延迟[5]。TTL值的大小决定了DNS记录更新延迟的长短。实验使用的域名集合中全部265262个域名TTL值的累积分布如图5所示。可以注意到，TTL值的中位数约为2h。也就是说，若域名所有者需要重新分配内容服务器资源，则需要承受近 2h的延迟。在 DNS记录发布方式上，本文提出的模型采用的是“推”机制，不必采用TTL机制，从根本上解决了这个问题，使域名所有者可以“无缝”地重新分配内容服务器资源。

图5 TTL值的累积分布

5.3 DNS可靠性

下面将比较4种域名解析服务的可靠性（通过连续24h的测量）。对基于云的域名解析服务模型，实验测量的是其网络和节点服务器的可靠性。网络的可靠性（分组丢失率）可以通过ICMP PING节点服务来测量，节点服务器的可靠性则通过 TCP PING节点服务器来测量。在 5s的时隙内，如果ICMP PING和TCP PING都收到了节点服务器的响应，则认为域名解析服务在这5s时隙内是可靠的。对于其他3种域名解析服务，实验采用文献[21]中的方法，每隔5s发送一次DNS查询请求。将时间间隔设置为 5s是因为一般域名解析器默认的超时重传为 5s。如果在5s内没有收到响应，则认为出现异常，这5s时隙内域名解析服务不可靠。最后，统计24h内可靠的5s时隙的数量，并计算出各域名解析服务的可靠性。

如图6所示是可靠性实验的测量结果。对基于云的域名解析服务模型，其可靠性明显高于其他 3种域名解析服务。在所有140个PlanetLab节点中，50%节点的可靠性达到了99.99%（其他域名解析服务的这一指标只有99.9%或99%）。这主要是因为对于未缓存的DNS记录，其他3种域名解析服务需要以递归查询的方式访问各级域名服务器，域名服务器间歇性无响应、网络传输过程中 UDP分组丢失都会降低域名解析服务的可靠性。此外，可以注意到，当使用ISP的域名解析器时，有近20个节点的可靠性为 0。这是因为那些节点配置的主域名解析器出现故障，切换到备用域名解析器的时间超出5s或没有备用域名解析器。基于云的域名解析服务模型、Google Public DNS和OpenDNS则未出现这一状况，通过IP Anycast路由技术，它们可将用户快速地重定向到附近的其他正常工作的域名解析器上。

图6 可靠性

6 结束语

本文分析了现行 DNS存在的问题。针对这些问题，本文结合云的内容发布、存储特点和域名解析服务的需求，提出了基于云的域名解析服务模型。设计采取了“推”机制，在全球广泛分布的云的节点服务器上发布各域名权威的 DNS记录，使节点服务器实现现行 DNS架构中二级域名服务器功能。这将极大提高域名解析服务对DoS攻击和网络故障的应变能力，同时可降低域名管理的复杂性，还能有效地限制 DNS滥用。更重要的是，节点服务器也作为域名解析器，响应域名解析请求。这样的设计使得节点服务器结合了域名服务器和域名解析器的功能，DNS查询将不再需要以递归查询的方式访问各级域名服务器，节点服务器能直接响应用户的域名解析请求，极大地提高了查询效率。本文通过实验证明了基于云的域名解析服务模型在查询延迟、更新延迟、可靠性等各方面的性能都有显著提高。最后，此服务模型可与现行 DNS兼容，通过增量部署，可以实现渐进地取代现行的域名解析系统。

[1]MOCKAPETRIS P.Domain Names:Concepts and Facilities[S].RFC 1034, 1987.

[2]MOCKAPETRIS P.Domain Names:Implementation and Specification[S].RFC 1035, 1987.

[3]MOCKAPETRIS P, DUNLOP K.Development of the domain name system[A].SIGCOMM'98[C].Stanford, CA, USA, 1988.123-133.

[4]A DNS number for faster browsing[EB/OL].http://www.infoq.com/news/2009/12/Public-DNS-Google,2009.

[5]DEEGAN T, CROWCROFT J, WARFIELD A.The main name system:an exercise in centralized computing[J].ACM Sigcomm Computer Communication Review, 2005, 35(5):5-14.

[6]RAMASUBRAMANIAN V, SIRER E G.The design and implementation of a next generation name service for the internet[A].SIGCOMM'04[C].Portland, OR, USA, 2004.331-342.

[7]LISTON R, SRINIVASAN S, ZEGURA E.Diversity in DNS performance measures[A].ACM IMW'02[C].New York, USA, 2002.19-31.

[8]KALAFUT A, SHUE C, GUPTA M.Understanding implications of dns zone provisioning[A].IMC'08[C].New York, USA, 2002.19-31.

[9]ANTONAKAKIS M, PERDISCI R, DAGON D, et al.Building a dynamic reputation system for DNS[A].USENIX Security'10[C].Washington.DC, USA, 2010.1-17.

[10]KANGASHARJU J, ROSS K.A replicated architecture for the domain name system[A].INFOCOM'00[C].Tel Aviv, Israel, 2000.660-669.

[11]HANDLEY M, GREENHALGH A.The case for pushing DNS[A].HotNets'05[C].College Park, MD, USA, 2005.1-6.

[12]Google public DNS[EB/OL].http://code.google.com/speed/publicdns/.

[13]Open DNS[EB/OL].http://www.opendns.com/.

[14]GUMMADI K, SAROIU S, GRIBBLE S.King:estimating latency between arbitrary Internet and hosts[A].ACM IMW'02[C].Marseille,France, 2002.1-14.

[15]The total number of Web domains[EB/OL].http://www.labnol.org/internet/total-web-domain-names/18395/,2010.

[16]KATABI D, WROCLAWSKI J.A framework for scalable global IP-anycast[A].SIGCOMM'00[C].New York, USA, 2000.3-15.

[17]KEAHEY K, FIGUEIRDO R, FORTES J, et al.Science clouds:early experiences in cloud computing for scientific applications[J].Cloud Computing and Applications, 2008, 2008:825-830.

[18]BERNSTEIN D, LUDVIGSON E, SANKAR K, et al.Blueprint for the intercloud-protocols and formats for cloud computing interoperability[A].ICIW'09[C].Venice/Mestre, Italy, 2009.328-336.

[19]HUBERT A, MOOK R.Measures for Making Dns More Resilient Against Forged Answers[S].RFC 5452, 2009.

[20]PlanetLab[EB/OL].http://www.planet-lab.org/,2007.

[21]PARK K, PAI V, PERTERSON L, et al.CoDNS:improving DNS performance and reliability via cooperative lookups[A].OSDI'04[C].San Francisco, CA, USA, 2004.1-16.