基于双重检索修正域名系统的最长匹配规则

周 聪,陶 静,赵宝康,李安艺

(国防科技大学计算机学院,湖南 长沙 410073)

1 引言

随着互联网的快速发展,为了方便人们利用域名形式访问网络中的主机,域名服务系统DNS(Domain Name System)应运而生。RFC1034[1]取代之前的RFC882系统地描述了DNS的基本思想(标志着DNS的诞生),其原理是客户端根据查询得到的资源记录类型和关联数据进行下一步的通信。

Linux系统的DNS服务由BIND (Berkeley Internet Name Domain)软件实现,目前95%以上的DNS服务器都是由其搭建的[2]。中小型企业也可以选择微软公司的Windows server系列搭建域名服务器。目前对域名解析系统的研究主要集中在安全性方面[3-6],也有文献将其与大数据方法结合后实现数据可视化[7],还有去中心化架构的DNS系统设计[8]。

在安全性方面,针对隐私保护问题,由于DNS基于明文传输数据,使用加密技术将DNS请求与响应的数据包进行加密,从而保证数据包不被监听和利用,其代表性技术包括DoT(DNS-over-TLS)[9]、DoH(DNS-over-HTTPS)[10]、DNS-over-QUIC(Quick UDP Internet Connections)[11]和DNSCrypt[12]。在性能优化设计方面,张伟等[13]设计了一种支持多进程共享的高效哈希表,用于存储域名数据、实现域名快速查询和解决缓存大量域名时的哈希冲突问题;还依据域名和资源记录类型预先构建应答数据,对重复域名数据进行压缩,加快DNS请求处理时构建应答报文的速度,提高缓存服务器的处理性能。秦丰林等[14]根据双栈环境的特点,设计了IPv6协议的地址自动配置机制,为用户终端无感知地自动配置DNSv6服务器,通过增加DNS配置的冗余方式来提高DNS服务的可靠性。

DNSSEC(Domain Name System SECurity extensions)[15]协议引入了数字签名技术,通过对响应数据进行签名可以验证响应结果的正确性。针对实施条件中存在的安全隐患,Bau等[16]模拟了DNSSEC中的加解密操作并成功发现了一些伪造的漏洞。Herzberg等[17]分析了DNSSEC面临的挑战和存在的不足。Goldberg等[18]的研究表明DNSSEC部署很容易受到区域枚举攻击。

DNS技术旨在帮忙用户以容易记忆的方式检索网络资源,从互联网出现之初使用IP地址通信,到目前的计算机网络寻访定位方式,该项技术已取得了很大的发展,DNS域名服务被应用于更多的领域。彭巍等[19]基于Hadoop技术分析运营商的DNS海量数据,并对分析的结果进行阐述,通过报表、图形等多种方式进行呈现,实现DNS数据多维度分析。蔡荣彦等[20]提出了基于域名关联的恶意移动应用检测方法,以DNS域名为检测分析对象识别网络流量中的恶意域名,利用DNS请求流量的时间特征寻找恶意域名的关联域名,并将关联域名与文本分类样本库进行对比,确定恶意移动应用的名称。Cui等[21]利用数据挖掘的方法对域名的日志数据进行分析,从而检测出异常。

在DNS去中心化设计方面,朱国库等[22]设计了根域去中心化的方案,从而形成联盟来对根服务器的数据进行解析;朱建明等[23]提出了利用区块链来构建数据动态认证的模型;赵赫等[24]提出用区块链来保护数据。

ENUM(Electronic Numbers to URI Mapping)是电话号码映射工作组制定的协议[25,26],它定义了将E.164号码映射为域名的规则,以及在互联网DNS系统中存储该域名信息的方法。每个E.164号码转化成的域名对应系统的唯一资源标识,从而使其成为可以在互联网中使用的网络地址。采用ENUM技术,通过电话号码可以获得用户邮件、IP传真和个人网页等多种信息。

ENUM技术是当前计算机网络资源寻址方式的热点,在三网融合中被大量应用[27]。该技术的核心分为3部分:电话号码预处理、DNS配置和ENUM解析。

在电话号码预处理阶段:当用户输入的号码为“+86-01-234567”时,去掉数字以外的其它符号,并在数字之前加“.”,得到“8.6.0.1.2.3.4.5.6.7”,将其反转并添加后缀得到符号串“7.6.5.4.3.2.1.0.6.8.e164.arpa”。在DNS配置阶段:上述字符串按NAPTR(Naming Authority PoinTeR)记录[1]的格式存储于区域文件。在ENUM解析阶段:当用户使用支持ENUM技术的设备输入电话号码后,该设备完成号码预处理,并将字符串按DNS协议发出,从DNS服务器得到与此ENUM相应的唯一资源标识集合,用户根据自身的需求选择相关的资源,继续执行相应的协议完成操作。如:用户在Outlook Express输入“+86-01-234567”,DNS服务器将对应的“Sip:xxx”和“Mailto:xxx”等资源标识给用户,用户若选择“Mailto:xxx”,可与电话号码为“+86-01-234567”的使用者进行邮件沟通。

2 最长匹配规则

ENUM支持在NAPTR记录中使用符号“*”,以实现解析过程模糊匹配。模糊匹配过程依据最长匹配策略,如下所示:

以BIND(版本9.7.3)为例,在DNS配置阶段,使用4个号码:1*,12,13*,141。注册NAPTR记录如下:

*.1.e164.arpa.IN NAPTR 1 1 “U” “sip+E2U” “resolving result:A”

2.1.e164.arpa.IN NAPTR 1 1 “U” “sip+E2U” “resolving result:B”

*.3.1.e164.arpa.IN NAPTR 1 1 “U” “sip+E2U” “resolving result:C”

1.4.1.e164.arpa.IN NAPTR 1 1 “U” “sip+E2U” “resolving result:D”

当用户需要查询号码1311时,按最长匹配规则,域名系统BIND返回解析结果C;当用户查询号码13,14或者142时,域名系统BIND返回“无结果”,以号码142为例,按最长匹配规则,用户应该收到解析结果A。

为进一步验证RFC关于最长匹配规则的定义,在Windows server 2003上注册相同号码进行解析,两者的解析结果之间存在差异,详细如表1所示。由此可知:BIND系统的最长匹配规则功能不符合RFC描述。

Table 1 BIND and Windows server’s domain name resolution

通过比较不同的版本BIND-9.8、BIND-9.9和BIND-9.17.18,其解析的结果与BIND-9.7.3的一致,即后续版本的最长匹配规则功能亦不符合RFC描述。

3 双重检索规则

根据表1的解析过程,可将结果分为4类:

(1)Ⅰ类(表1的第2个和第8个用例):在DNS系统中明确注册的记录,如号码12和141,BIND与Windows server均能得到正确的解析结果。

(2)Ⅱ类(表1的第6个和第7个用例):在DNS系统中注册通配符“*”记录,可匹配变长的号码,如果已注册13*,则131和1311将被解析为其结果。

(3)Ⅲ类(表1的第3个、第4个和第9个用例):按RFC1034关于通配符的定义,当出现“*”时,解析结果应满足模糊检索的要求,但BIND与Windows server的解析结果存在差异。

从用户的角度来看,最长匹配规则更趋向于认同Windows server的解析结果,与RFC1034的描述一致。

(4)Ⅳ类(表1的第1个和第5个用例):不满足上述3种场景,即未注册的记录。

针对第Ⅲ类情况,本文提出了双重检索匹配算法,即:在BIND系统中,当号码E无法获得解析结果时,系统生成一个新的号码E′,以E′重新进行检索,最终结果返回至用户,具体流程如图1所示。

Figure 1 Search process comparison

图1a为原BIND系统的检索流程,图1b为改进后的检索流程。从图1可知,当号码E的解析结果不存在时,将生成新号码E′再次检索,故称为双重检索规则。

由于系统在检索前,需要保存检索的内容,所以在第2次检索时,需要先保持原号码的检索条件,重置新的检索状态,执行新号码检索后,恢复原号码的检索条件,并返回给用户。

为提高2次检索的效率,本文设计新号码生成算法,如算法1所示。

算法1生成双重检索号码E′

输入：待检测的号码E。

输出：新的号码E′。

步骤1若号码E不包含*,退出;否则执行步骤2。

步骤2根据号码E获取区域文件名。

步骤3获取区域文件中所有记录,形成2个链表ts与tn,其中ts以“*” 开头,tn以数字开头。若ts为*.1和*.3.1,则分别对应号码1*和13*;若tn为2.1和1.4.1,则分别对应号码12和141。

步骤4若tn不为空,依次删除号码E的最低位,并与链表tn各项比较,如若存在相同项,则置E′为空,跳转至步骤6。若号码E为123*,则与tn比较的字符串依次为2.1和1。

步骤5若ts不为空,依次将号码E的最低位置为“*”,并与链表ts各项比较,若存在相同项,则置E′为ts的当前值,跳转至步骤6。若号码E为123*,则与ts比较的字符串依次为*.2.1和*.1。

步骤6清空链表ts和tn,关闭区域文件,返回E′。

4 双重检索过程实现

图1b中的阴影部分通过调用原系统函数实现,其它部分均在BIND系统的函数query_find中实现。

(1)存在记录判断。

此处为双重检索的入口,判断记录是否存在的标志为变量result与type。第1次检索完成后,result变量返回检索结果。经实验发现,当值为196611(针对141注册后无法解析142的场景)或65628(针对141注册后无法解析14的场景),且变量type的值为35(ENUM记录类型的值)时,需进入图1b的双重检索流程。

(2)保护号码E的检索条件。

号码E的内容(变量名为client→query.qname→ndate)与长度(变量名为client→query.qname→length)分别存入临时变量数据组t中。

(3)重置检索状态。

①清空第1次的检索结果,将变量fname→ndata,fname→length,fname→label和fname→attributes置空或置零。

②将号码E′的内容和长度分别赋值检索变量client→query.qname→ndate和client→query.qname→length。

③为检索数量(变量名为segment)、标识位(变量名为client→query.qname→label)、偏移量(变量名为client→query.qname→offsets)赋初值。

(4)以号码E′执行检索。

调用原BIND的检索方法dns_db_find(),但当前状态下检索的内容从第1次的号码E变成为E′。

(5)恢复号码E检索状态。

以E′完成检索,恢复至号码E时的状态,将临时变量t的内容分别赋值给lient→query.qname→ndate和client→query.qname→length。

双重检索实际上是通过算法1找到了与号码E最长匹配的另一个新号码E′,重新调用BIND的检索方法得到新的结果,并恢复到原号码E的情景返回给用户,这一过程对用户透明。

为了满足BIND系统应用DNSSEC[15]的要求,在重置初始化检索状态过程中将2个变量置为NULL即可,即node与rdateset→methods;其它变量与非DNSSEC处理过程一致。

5 实验验证

本文在BIND-9.7.3基础上完成双重检索修改最长匹配规则,对比前后2次的解析结果,如表2所示。

Table 2 Domain name resolutions of BIND after being modified

从表2可知,使用双重检索修正后,BIND的解析结果与Windows server 2003的解析结果一致,同时符合标准文献RFC1034对通配符最长匹配的定义。

使用DNS性能测试工具dnsperf对双重检索修正后的BIND服务进行测试,其每秒查询次数(并发数)、响应时间2项指标与修正前的基本一致,因此,修正过程对性能影响可忽略不计,详细数据如表3所示。

Table 3 Performance of BIND before and after being modified

表3的前1～6列为dnsperf配置的参数:C指定客户端数量;Q限制每秒查询数量;i指定查询的间隔;符号“√”表示当前参数值有效,且值为表头第2行的方框内容。表3的后2列为dnsperf测试结果,在上述3个参数选定的前提下,每个场景运行100次,分别计算查询消耗时间和每秒查询次数的平均值。由于某些场景的查询消耗时间为0,符号“/”表示查询结果无法计算。

从表3可以看出,基于修改后的双重检索BIND服务与原服务性能在同一个量级,两者数值相差不大。

通过计算每秒查询次数的两者之差与两者之和的比值,比较两者在每秒查询次数上的相对偏差,其结果如图2所示。

Figure 2 Relative deviation of query times per second

从图2可知,3个场景的偏差非常小,如〈c,i,Q〉=〈1,10,1000〉、〈c,i,Q〉=〈100,1,1〉、〈c,i,Q〉=〈100,10,1〉;2个场景的偏差较大,如〈c,i,Q〉=〈100,1,1000〉、〈c,i,Q〉=〈100,10,1000〉。

在用户并发数与查询总量增加的情况下,由于基于二次检索的BIND服务查询次数增加,性能与原BIND的偏差有所增长,相应的性能有所下降,但都处于15%以下,性能影响不大。

6 结束语

BIND软件在域名服务系统中占比很高,但实现最长匹配功能时与RFC描述存在偏差,需要通过对比Windows server 解析结果进一步确认。本文在保持BIND原有架构不变的基础上,使用双重检索规则,修正后的BIND解析结果更符合RFC中关于最长匹配规则的定义,同时不影响软件性能。这种修改策略将为标准服务更多定制化需求提供了一种可行的方案。同时,该系统已在实网中部署应用。