CN100392650C

CN100392650C - 增强域名系统中的数据库性能的方法、系统及名称服务器

Info

Publication number: CN100392650C
Application number: CNB2004800104081A
Authority: CN
Inventors: 罗伊·利尔克维斯特; 朱哈·尤斯基
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2003-05-27
Filing date: 2004-05-24
Publication date: 2008-06-04
Anticipated expiration: 2024-05-24
Also published as: EP1627328B1; FI20030797A0; DE602004005035D1; WO2004107207A1; EP1627328A1; KR20060021836A; US20040243596A1; ATE355563T1; CN1777889A; KR100664005B1; DE602004005035T2

Abstract

本发明提出了一种增强域名系统(DNS)中的数据库性能的机制。为了优化当前的实际DNS名称服务器的用于请求与E.164号码有关的数据的查询的性能，将接收到的具有第一格式的域名变换成第二格式再提供给数据库操作。在第二格式中，域名的至少两个相继的标签被合并，以形成单个标签。这变换可以配合地域传送和配合随后的DNS查询进行。

Description

增强域名系统中的数据库性能的方法、系统及名称服务器

技术领域

本发明涉及分布式数据库，特别涉及作为用于因特网的分布式数据库的域名系统(DNS)。确切些说，本发明涉及改善当前实际DNS的名称服务器(name server)即DNS客户机服务器机制的服务器实体的性能的方法。

背景技术

众所周知，域名系统(DNS)是一种分层的分布式数据库，在诸如因特网之类的计算机网络内用来将域名转换成IP地址。存储在数据库内的数据单元由组织成称为域名空间的倒置树(inverted tree)结构的域名标识。树内每个节点给有标签(label)。节点的域名为由从本节点到树的根节点的路径上的各个标签组成的序列，用点将标签相互隔开。也就是说，域名标识了树内的节点。与每个域名关联的数据存储在一个或多个资源记录(RR)内。目前，有大约20种不同类型的RR在普遍使用。在下面，对DNS系统进行简要的说明，以解释与本发明有关的一些概念或组成部分。

为了分散管理域名空间，将域名空间分成一些称为地域(zone)的区域。每个地域开始于特定节点，延伸到树的叶节点或其他地域的开始节点。每个地域由负责本地域的称为特许名称服务器(authoritative name server)的至少一个名称服务器维护和服务。特许名称服务器含有它所负责的地域的全部信息。为了使DNS能耐受故障，地域通常具有超过一个的特许名称服务器。存储地域数据的原版拷贝的特许服务器称为主服务器，而同一地域的其他特许名称服务器称为从服务器或辅助服务器。每个从服务器从地域的其他特许名称服务器获取地域数据。这种复制过程通常称为地域传送(zone transfer)。本发明关心的主要是从服务器，如下面要较为详细说明的那样。

DNS也可以用来标识与作为标准E.164号码给出的特定电话号码关联的业务。如所周知，E.164号码在公用电信网内是诸如电话机或传真机之类的资源的全球性唯一标识符(即，国际电话号码)。所用的名称，E.164，来自定义标识符格式的国际电信联盟(ITU)建议E.164。

RFC(Requests for Comments)2916讨论了用DNS标识与E.164号码关联的可用业务。这个RFC文件规定了称为ENUM的将国际电话号码映射为因特网业务的协议。用于这种映射的基于DNS的系统在这个环境内称为ENUM系统。在终端用户进入或拨了E.164号码时，这个号码就变换为完全合格域名(Fully Qualified Domain Name：FQDN)提供给DNS，DNS返回与FQDN关联的所有名权限指针(NAPTR)记录。NAPTR为上面所说明的资源记录类型之一。与特定E.164号码关联的存储在DNS内的这些NAPTR包括可以用来联系与这个号码关联的一个或多个网络资源。

当前实际DNS服务器基于Berkeley因特网名称域(BIND)实现，其中数据库基于红-黑二进制树。与这些服务器有关的缺点是它们的性能对于ENUM系统没有最佳化，而上面所提到的将电话号码转换成FQDN降低了它们的性能。本发明旨在消除这个由于转换的性质引起的缺点，情况如下面所说明的。

发明内容

本发明旨在改善当前实际名称服务器的性能。本发明还旨在优化当前的实际名称服务器的用于ENUM系统或用于提供给域名系统的FQDN类似用于ENUM系统的FQDN的任何其他查询的性能。

在本发明中，在实际的数据库接口前修改在名称服务器接收到的FQDN，然后再将经修改的FQDN提供给这个接口。如下面所说明的，修改配合地域传送和配合随后的DNS查询执行。在这里，数据库接口指的是名称服务器内在实际的数据库操作前的点，即地域数据和DNS查询通过其被提供给诸如插入、删除或搜索之类的数据库操作的那个接口。

因此，本发明的实施例是提供一种增强域名系统(DNS)中的数据库性能的方法。这种方法包括下列步骤：接收要提供给数据库操作的数据，所述数据包括含有多个相继标签的至少一个域名，所述至少一个域名具有第一格式；将所述至少一个域名中的至少一个变换成第二格式，其中所述至少一个域名中的至少一个的至少两个相继标签被合并，以形成单个标签。这种方法还包括将数据提供给数据库操作，所提供的数据包括第二格式的至少一个域名。

在另一个实施例中，本发明提供了一种增强域名系统中的数据库性能的系统。这种系统包括：第一装置，用来接收要提供给数据库操作的数据，所述数据包括含有多个相继标签的至少一个域名，所述至少一个域名具有第一格式；第二装置，用来将所述至少一个域名中的至少一个变换成第二格式，其中所述至少一个域名中的至少一个的至少两个相继标签被合并，以形成单个标签；以及第三装置，用来将数据提供给数据库操作，所提供的数据包括第二格式的至少一个域名。

在另一个实施例中，本发明提供了一种用于域名系统的名称服务器。这种名称服务器包括：第一接口，用来接收要提供给数据库操作的数据，所述数据包括含有多个相继标签的至少一个域名，所述至少一个域名具有第一格式；在操作上连接到第一接口上的修改模块，用来将所述至少一个域名中的至少一个变换成第二格式，其中所述至少一个域名中的至少一个的至少两个相继标签形成单个标签；以及在操作上连接到修改模块上的第二接口，用来将数据提供给数据库操作，所提供的数据包括第二格式的至少一个域名。

在又一个实施例中，本发明提供了一种计算机程序产品。这种计算机程序产品包括计算机可读代码，设计成在由计算机执行时使这个计算机基本上执行上面所提到的方法的步骤。

利用本发明的解决方案，可以显著地提高ENUM系统的性能，因为由上面所提到的变换所引起的主要内部延迟可以在名称服务器内消除。

本发明的另一个优点是可以用一种简单的低成本方式提高DNS名称服务器的性能。这是因为可以继续使用现有的服务器软件(BIND)和不需要修改实际数据库(即搜索树)。

从以下详细说明和附图中可以清楚地看到本发明的其他特征和优点。

附图说明

下面将结合图1至6所示的例子对本发明及其实施例进行较为详细的说明，在这些附图中：

图1通过示出在从普通的电话机发起呼叫时DNS的使用情况例示了ENUM系统；

图2例示了在当前的DNS系统内域名的格式；

图3例示了在本发明中对图2的域名格式修改的情况；

图4为例示本发明的名称服务器的体系结构的原理图；

图5为例示配合地域传送修改域名的流程图；以及

图6为例示配合DNS查询修改域名的流程图。

具体实施方式

为了例示本发明应用的环境，图1示出了使用ENUM系统的例子。在图1中假设用户从普通电话机100向国际电话号码(即，E.164号码)为+358-60-111-2222的另一用户(未示出)发起呼叫。首先，电话网120将这个呼叫请求路由给为这个E.164号码的业务代理(serviceagent)的网关130。接收到呼叫请求，网关将这个E.164号码变换成FQDN。这个变换是，首先将E.164号码内的数字倒转，然后将点插入数字之间，最后将域“e164.arpa”附加到串的末端。在这种情况下，因此得到的FQDN为2.2.2.2.1.1.1.0.6.8.5.3.e164.arpa。然后，网关将包括刚才形成的FQDN的标准DNS查询发送给DNS。接收到查询的名称服务器执行搜索，在DNS响应中返回与FQDN相应的所有NAPTR记录。这些记录列出了映射到所考虑的E.164号码的因特网业务。为此，NAPTR记录包括例如：次序字段，指出处理多个NAPTR记录的次序；以及业务字段，指出需使用的解析协议和业务，即一些怎样继续进行对这个呼叫请求的处理的指令。根据在这组NAPTR记录内接收到的信息，网关于是确定接下来需使用的解析服务。这样，按照从DNS接收到的信息继续处理这个呼叫请求。由于本发明并不涉及过程的这个阶段，而只是与以上所说明的名称服务器有关，因此在这里就没有讨论呼叫请求的完成情况。

本发明的发明者发现将E.164号码转换成FQDN的本性降低了实际名称服务器的性能。如以上所说明的那样，在ENUM系统内域名包括多个只是一字符(一字节)长的标签。在实际名称服务器内，搜索算法对域名的处理是从根目录起逐标签地遍历域名，而每当遇到点时，在根节点与标签的已遍历域名相应的新的子树内继续搜索。这意味着使用ENUM系统会转换为在更多个子树中执行搜索。在这里假设有一百万个电话号码需映射到相应的因特网业务。如果使用允许长标签的传统系统，这可以实现为包括一百万个节点的单树。然而，在标签只包括一个号码的ENUM情况下，必需在六个各包括10个节点(标为0到9)的不同的树(电话号码的每个数字一个树)内搜索。由于树可以有10个标签(数字值从0到9)，因此树的数目为：

Σ_{n = 1}^{k} 10^{(n - 1)}

其中k为一个数字的标签的数目。在这种情况下，k等于6，从而可能的树的数目等于111111。

要从红-黑二进制树找出某个节点的时间等于O(log n)，其中n为树内的节点数，而O(.)为通常使用的O标记法。因此，在传统的情况下，搜索时间等于O(log 1000000)＝6。在相应的ENUM情况下，在树内的搜索时间等于O(log10)＝1。由于一百万电话号码必须用6个树，因此总搜索时间等于6，即在这两种情况下搜索时间是相等的。然而，在ENUM情况下从一个二进制树移到另一个二进制树形成总搜索时间的重要部分，因为从一个树切换到另一个树的任务实际上比在一个二进制树内搜索复杂。

在当前的实际名称服务器中，域名通常以未经压缩的线格式(wire format)存储。在DNS查询内域名也以这种格式出现。在这种格式中，每个标签之前是1字节的计数(count)，这个计数规定了这个域名为域名内下一个标签承载的字节数。域名以值为零的字节结束，这是这个根的标签。图2示出了域名5.3.2.2.2.2.e164.arpa以这种格式存储的情况。可以看到，所存储的域名包括6个为1的计数值，与6个1字节的标签相应。

所存储的名称数据的结构还可以表示为：

struct dns_name{

unsigned int magic；

unsigned char＊ ndata；

unsigned int length；

unsigned int labels；

unsigned int attributes；

unsigned char＊ offsets；

isc_buffer_t＊ buffer；

ISC_LINK(dns_name_t) link；

ISC_LIST(dns_rdataset_t) list；

}；

其中，ndata指的是处于未经压缩的线格式的域名数据，labels指出ndata内的标签数，而offsets指出标号x的计数字节偏移量。对标签的计数从与根标签相反的那侧开始，第一标签具有为零的值。

在图2这个例子中，labels和offsets的值如下：

-labels＝9，

-offsets：offsets[label＝0]＝0，offsets[label＝1]＝2，offsets[label＝2]＝4，offsets[label＝3]＝6等，

-具有以上offsets的ndata值为：ndata[offsets＝0]＝1，ndata[offsets＝2]＝1，ndata[offsets＝4]＝1等。

在本发明的这个例子中，通过修改域名，以至一定数量的标签组合形成单个标签，来提高名称服务器的性能。修改从给定的原点(origin)开始，使得线格式的第一计数值(即ndata[offset＝0])改变为与在要合并的标签内和在所述标签之间的计数内的字节数之和相应的值。也就是说，第一计数改变为与在经合并的标签内的字节的总数相应的值。图3示出了图2所示的域名在所希望的原点为e164.arpa的假设下的修改情况。在这种情况下，在要合并的标签内的字节的总数为6(5.3.2.2.2.2)，而在中间的计数内的字节的数目为5。因此，名称内的第一计数的值为11，指出下面11个字节形成在第一计数后的标签。

在上面这个例子中，labels和offsets的值因此修改成：

-labels＝4，

-offsets：offsets[label＝0]＝0，offsets[label＝1]＝12，offsets[label＝2]＝17，offsets[label＝3]＝22，

-具有以上offsets的ndata值为：ndata[offsets＝0]＝11，ndata[offsets＝12]＝4，ndata[offsets＝17]＝4，ndata[offsets＝22]＝0。

图4为本发明的名称服务器的例子的体系结构的示意图。在本发明中，在名称服务器内引入独立的修改模块40，使得这个模块处在诸如分别标以43、44和45的添加、删除和搜索之类的实际数据库操作之前。如上面所提到的，实际数据库42通常为红-黑二进制树。修改模块接收要执行的数据库操作的输入数据，输入数据例如是随地域传送或DNS查询接收到的。如果必要的话，修改模块以上面所说明的方式改变包含在输入数据内的域名。修改模块因此检验是否需要修改，在需要修改的情况下执行修改。否则，模块将输入数据保持原状，即名称服务器以传统的方式进行操作。

在从数据库(即从模块46)接收到查询响应时，修改模块将经修改的域名恢复为它原来的格式。实际上，修改模块可以实现成它位于普通的BIND实现内，即在入局数据的情况下在修改前还执行一定的BIND功能。这些功能包括在正常地域传送情况下的dns_db_beginload()和beginload()、在增量地域传送情况下的xfrin_recv_done()和xfr_rr()、在DNS查询情况下的client_request和ns_query_start()和在lwresd查询情况下的lookup_find()和view_find()。从数据库接收到的DNS查询响应转给的功能为continue_query_find()。这个在修改模块之前的级在这里称为预处理级。修改模块可以作为补丁文件添加给BIND软件的源程序。

本发明可以配合地域传送和随后的DNS查询使用。这将在下面说明。

图5为例示修改模块配合地域传送即在将整个地域传送给名称服务器时的基本操作的例子的流程图。在这种情况下，修改模块因此修改如图3所示的地域数据，以便保证地域数据存储在二进制树内。这从而消除了如上面所说明的性能问题，因为随后的搜索可以在一个搜索树内执行。

在接收和预处理地域数据的同时，修改模块一次一个地即时(on-the-fly)检验NAPTR记录，以检查其是否满足为修改设置的预定条件(步骤51)。为此，修改模块用NAPTR记录的标准格式在到来的记录内寻找有关的数据。这个为NAPTR记录设置的预定条件通常是域名必须包括“越过”地域的原点的至少特定数量的1字节标签，以使修改能够发生。例如，修改模块只有在域名包括“越过”原点的至少三个1字节标签时才可以合并标签。用上面的域名(5.3.2.2.2.2.e164.arpa)作为例子，假设地域原点为2.2.2.e164.arpa，修改模块会合并上面这个域名内的前三个标签(5.3.2)，但不会为只有两个标签(4.4)超出原点的域名4.4.2.2.2.e164执行合并。因此，对于每个NAPTR记录，修改模块定义地域原点与域名之“差”，将“差”的标签合并在一起，如果它们满足预定的条件。

在步骤51的检查和在步骤52的可能修改后，将数据添加给数据库(步骤53)。

图6为例示修改模块配合到来DNS查询的基本操作的例子的流程图。在预处理级处理查询数据时，修改模块在步骤601、602和603执行预检查，确定域名配合这个查询是否需修改。首先，修改模块检查在名称服务器内是否可以发现域名的原点(步骤601)。其次，修改模块检查是否有所考虑的ENUM查询(步骤602)，然后修改模块再检查名称服务器是否为所考虑的地域的特许名称服务器(步骤603)。

如果所有以上三个条件都满足，修改模块将超出所考虑的域原点的标签合并在一起(步骤606)，如果域名满足在步骤605检查的一个或多个预定条件的话。这个检查与图5中的步骤52相应，即它检查标签是否具有足够多的超出原点的1字节标签。

然后将这个查询提供给数据库操作，即图4中的模块45(步骤607)。在修改模块从数据库接收到响应时(步骤608/yes)，它检验输入的域名的标签是否配合查询先前受到合并(步骤609)。如果是，修改模块就分离这些标签(步骤610)，即通过将域名内的第一计数改回它的原来值将域名恢复为它原来的格式。然后，修改模块将响应转给预处理级(步骤611)。如果检测到在数据库操作前输入域名的标签没有合并，就不分离标签。在这里需指出的是，以上面的方式处理响应，无论它是否含有应答，即步骤609至611保持相同，即使发现没有来自数据库的应答。

如果在步骤601的第一检查指出在名称服务器内不能发现原点，这个查询就转给另一个服务器(步骤604)。如果在步骤602的检查指出查询不是ENUM查询，就跳过修改，将查询提供给数据库操作。因此，在这种情况下名称服务器以传统的方式操作。如果在步骤603的第三检查指出修改模块对于所考虑的地域不是特许的，则跳过修改，将查询提供给数据库操作。在这种情况下，查询是名称服务器已经高速缓存的递归查询，即名称服务器作为高速缓存服务器进行操作。

如上面所说明的名称服务器通常是从服务器。也就是说，这个名称服务器从主服务器接收地域数据。然而，本发明的变型也可以在将地域数据发送给从服务器前在主服务器内执行，在这种情况下，在从服务器内不需要修改。然而，在这种情况下，主、从之间的地域传送不是完全按照标准过程的(因为经修改的域名在网络上传送)。

虽然上面结合附图所示的例子对本发明作了说明，但显然本发明不局限于这些例子，而是可以由熟悉该技术的人员在不背离本发明的专利保护范围和精神实质的情况下加以修改。例如，本发明的解决方案可以与ENUM业务之外的其他业务结合使用，倘若这些应用产生象FQDN那样具有许多短标签的话。此外，这种方法不局限于合并一些1字节长的标签，也可以以同样方式合并不同长度的标签。在这种情况下，在上面所说明的检查(步骤51)指出域名包括超出给定原点至少预定数量的标签而且所述标签具有预定最大长度(现在是大于一字节)时执行修改。此外，不是必要合并所有超出原点的标签，也可以只合并部分这样的标签。

Claims

1.一种增强域名系统DNS中的数据库性能的方法，所述方法包括下列步骤：

接收要提供给数据库操作的数据，所述数据包括含有多个相继标签的至少一个域名，所述至少一个域名具有第一格式；

将所述至少一个域名中的至少一个变换成第二格式，其中所述至少一个域名中的至少一个的至少两个相继标签被合并，以形成单个标签；以及

将数据提供给数据库操作，所提供的数据包括第二格式的至少一个域名。

2.按照权利要求1所述的方法，所述方法还包括检验域名在第一格式中是否满足预定条件的步骤。

3.按照权利要求2所述的方法，其中所述检验步骤包括检验所述域名是否包括超出给定原点的至少预定数量的标签，所述标签具有预定的最大长度。

4.按照权利要求3所述的方法，其中在检验步骤指出域名包括超出给定原点的至少预定数量的标签、所述标签具有预定的最大长度时，针对所述域名执行所述变换步骤，并且在检验步骤指出域名不包括至少预定数量的标签时，不执行所述变换步骤。

5.按照权利要求3所述的方法，其中所述预定数量的标签是三个标签。

6.按照权利要求3所述的方法，其中预定的最大长度是一字节。

7.按照权利要求5所述的方法，其中预定的最大长度是一字节。

8.按照权利要求1所述的方法，所述方法还包括下列步骤：

接收包括第二格式的另一域名的数据；以及

将以第二格式接收的另一域名变换回第一格式。

9.一种增强域名系统中的数据库性能的系统，所述系统包括：

第一装置，用来接收要提供给数据库操作的数据，所述数据包括含有多个相继标签的至少一个域名，所述至少一个域名具有第一格式；

第二装置，用来将所述至少一个域名中的至少一个变换成第二格式，其中所述至少一个域名中的至少一个的至少两个相继标签被合并，以形成单个标签；以及

第三装置，用来将数据提供给数据库操作，所提供的数据包括第二格式的至少一个域名。

10.按照权利要求9所述的系统，所述系统还包括第四装置，用来检验域名是否满足预定条件，所述第二装置被配置为在域名满足预定条件时将域名变换成第二格式。

11.一种用于域名系统的名称服务器，所述名称服务器包括：

第一接口，用来接收要提供给数据库操作的数据，所述数据包括含有多个相继标签的至少一个域名，所述至少一个域名具有第一格式；

在操作上连接到第一接口上的修改模块，用来将所述至少一个域名中的至少一个变换成第二格式，其中所述至少一个域名中的至少一个的至少两个相继标签形成单个标签；以及

在操作上连接到修改模块上的第二接口，用来将数据提供给数据库操作，所提供的数据包括第二格式的至少一个域名。