DNS 域名信息主动获取及备份系统的设计和实现_mx052报文

　　目前13台根域名服务器且均在国外[3],我国互联网的核心域名资源面临着随时受制于人的窘境。我国虽于2003年后先后引进F、I、J三个根域名服务器的镜像,在一定程度上提高中国境内互联网用户连接相关网站的速度。但由于最终的数据仍然会被传送到位于国外的主根域名服务器上,在特殊情况下,我国互联网仍面临着因根域名服务器无法提供域名解析而导致瘫痪的问题[4]。

 

　　国际上已经开展了通过探索新型域名解析体系的方式,寻求现行域名解析体制的替代方法,如Open NIC[5]、New.NET[6]、Name.Space[7]等。1997年,增强域名系统(eDNS)进入试验阶段,它是现有DNS系统的替代品。这种系统使用自己定义的域名架构。1998年4月计算机专家Eugene Kashpureff也创建了一种新的域名解析系统AlterNIC。但这些系统目前多为试验产品,尚未推广使用。

 

　　开发并使用全新的替代域名系统代价较高,而要想马上完全摆脱国外在域名上的控制权是相当困难的。因此,当前可行的办法是,在现有域名解析体系的基础上,研究建立一个适合我国现状的DNS根/顶级域名服务器应急备份恢复系统,用于特殊时期在国外根/顶级域名服务器不能提供域名解析服务时,可以及时、高效、准确地解析国内DNS请求,确保国内用户能够正常使用互联网。该类工作在CERNET网已作了相关探索[8]。

 

　　本文所设计的DNS根/顶级域名应急备份恢复系统主要由DNS信息获取系统、DNS信息存储系统、DNS查询接管系统和DNS应答系统四大部分组成,通过大规模地收集国内及国外的DNS信息,以响应特殊时期国内对的DNS服务要求。如有异常,则迅速启用DNS应急备份方案。而后采取基于目的地址重定向的DNS请求接管方法,将DNS请求引导到应急备份系统中,通过DNS应答系统作出相应应答。该系统的基本架构如图1所示。

 

　　其中,DNS信息获取系统结合了在网络出入口进行监听被动捕包的方式[10],以及通过指定域名信息主动向特定域名服务器请求获取相应DNS信息的方式。因第一种方式与本文所介绍的处理应答包的方法类似,因此本文将重点介绍第二种方式。

 

　　1 域名信息获取主动系统设计与实现

 

　　1.1 总体结构

 

　　本系统分为以下几个模块:

 

　　a)DNS请求模块。从域名源获取待请求域名,DNS请求包的封装,请求域名服务器的选取,DNS请求包的发送和重发。

 

 

 

 

 

　b)DNS解析模块。DNS响应包的捕获,解析及各种响应包的处理。

 

　　c)请求管理模块。请求节点的插入和删除,超时请求的处理。

 

　　d)DNS信息存储模块。将解析后的资源记录有组织地存储到数据库中,以备恢复时使用。

 

　　DNS解析主要用于对其他应用协议(如HTTP、 FTP、E mail)的支持,请求频率不高,所以多数的DNS解析都是同步的。即在一个请求没有返回或者未作超时处理时,后续的解析就阻塞在那里。作为DNS应急备份系统的数据源和更新源,要求在单位时间内尽可能多地获取有效的DNS信息,因此本文采取了异步DNS解析方式,以便有效利用单个域名服务器在进行查询的空闲,发出更多的请求,其系统框图如图2所示。

 

　　域名请求发送(图3)和响应接收(图4)的主要流程为:从域名列表或域名数据库中取出一个域名,根据DNS协议的规定封装成DNS请求包,作为待发送请求,从域名服务器池中选则一个请求服务器,查看发送队列是否已满,是则等待,否则向该域名服务器发送新的请求;每发送一个DNS请求包,将其请求内容及相关信息构成一个请求节点插入到请求队列的尾部,这样在请求队列的头部则为时间轴上靠前的请求;每收到一个DNS应答包,通过其ID找到相应请求节点。若此应答包为非REF包,则删除相应节点。若此应答包为REF包,则根据REF包中的ref信息向下一跳域名服务器发出新的请求;在发送请求包和接收应答包的同时监视请求队列头部的请求节点是否超时,超时则作重传或删除处理。

 

　　1.2 DNS请求模块的设计与实现

 

　　本模块任务是:根据DNS协议规定,封装DNS请求包;域名服务器池的建立,分配及其维护;向选定的域名服务器发送DNS请求包。

 

　　1.2.1 DNS请求数据包的封装

 

　　为了构造DNS请求包和解析DNS数据包,需了解DNS报文格式。请求和应答采用UDP协议传送。下面简要介绍本文涉及的DNS报文格式内容,其他可参照RFC[1035][2]。

 

　　1)DNS请求报文格式

 

　　在DNS协议中所有的通信都是通过一种简短格式的报文传递的。该报文由12 Byte长的首部(header)和4个长度可变的字段(question、answer、authority和additional)组成。其中,首部指明了接下来报文中将包含哪些段以及此报文是请求还是响应、是标准请求还是其他的类型。Question(问题)段包含向域名服务器提出请求的信息,answer(答案)段、authority(权威)段、additional (附加)段均采用一种称为资源记录RR(resource record)的相同格式。答案段中包含直接回答问题段的资源记录,权威段包含可以指向权威服务器的RRs(基本上是NS记录),附加段包含和请求相关的信息,但不是直接回答的问题(如NS,MX记录对应的A记录)。

 

　　首部格式如图5所示。

 

　　ID

 

　　OROPCODATCRDRAZRCODE

 

　　QDCOUNT

 

　　ANCOUNT

 

　　NSCOUNT

 

　　ARCOUNT

 

　　图5 DNS报文首部格式

 

　　ID:16位,请求报文中的ID将复制到应答包中,可用于响应与请求的匹配。

 

　　接下来的两字节为Flag位:

 

　　QR:1位,0表示是请求报文,1表示是响应报文。

 

　　OPCODE:4位,表示请求类型(本项目发送标准请求,OPCODE=0)。

 

　　RD:1位,值为1时表明要求递归解析。

 

　　RCODE :4位。表明应答状态及各种错误。0为无错误有效应答。

 

　　QCOUNT、ANCOUNT、NACOUNT、ARCOUNT都是16位,表明相应段中含有RRs记录的个数。

 

　　构造DNS请求包时,应将待请求的域名和请求的类别按照DNS数据包的格式要求加入到Question段,而后再加上首部,封装成DNS报文。

 

　　Question段主要由以下三个字段组成:

 

　　a)QNAME。待请求的域名,要按照规定将点分制的域名转换成多个标志符的队列。每个标志符=一个字节的字符数+标志符。整个域名以0结尾。规定字符数的最高位为0(表示非压缩域名),所以每个标志符的最大字符数为63。

 

　　b)QTYPE。16位,表示DNS协议所支持的查询类型。查询常用的类型和相应的编码为如表1所示。#p#分页标题#e#

 

　　表1 QTYPE类型

 

　　A1IP地址

 

　　NS2权威域名服务器

 

　　CNAME5规范名称

 

　　SOA6域权威开始记录

 

　　PTR12域名指针(提供IP向域名解析)

 

　　c)QCLASS。16位,IN(1) 表示面向Internet。

 

　　2)构造DNS请求报文举例

 

　　下面以请求www.google.com的IP地址为例,说明构造DNS请求报文的实现方法:

 

　　a)构建question段

 

　　①QNAME:将www.google.com转换成3www6google3com0;

 

　　②QTYPE:预获得IP地址,则请求类型应为A,QTYPE=1;

 

　　③QCLASS =1;

 

　　b)构建首部

 

　　ID,FLAG=0x0100,QCOUNT=1,ANCOUNT=0,NACOUNT=0,ARCOUNT=0。

 

　　于是构建的DNS报文如图6所示。

 

　　1.2.2 DNS请求数据包的发送

 

　　DNS数据包的发送利用Libnet库完成。Libnet是UNIX系统上网络安全工具开发的接口库[12],提供一系列的接口函数,实现和封装了数据包的构造和发送过程。利用它可以构造DNS数据包的封装,并将其以UDP方式发送出去。

 

　　如图7所示,首先对Libnet初始化,将发送方式选为基于IP层的IPV4_RAW的数据包,参数为LIBNET_RAW4, 通信所用的设备选择eth0(可根据主机实际使用网卡选择);调用libnet_build_dnsv4()函数,构造DNS包(参数设定见1.2.1节);DNS标准请求用UDP协议发送,调用libnet_build_udp()函数,并将端口号指定为53;而后调用libnet_build_ipv4()函数,并将请求的域名服务器的IP参数传入,完成DNS的IP数据包构造;最后调用libnet_write()函数将请求包发送出去。由于每次数据包发送时需要的libnet的初始化参数相同,只调用一次libnet_init()初始化函数,在每次发送之后调用libnet_clean_packet()将协议块和发送缓存清空,为下一次数据包的发送做准备。

 

　　1.2.3 域名服务器池的建立与维护

 

　　向一个域名服务器大规模的发送查询请求,会导致域名服务器负载过重,应答效率将低。所以本文在全国范围内选取多个公共域名服务器,将请求分散,进而避免对单一域名服务器请求过量,同时当某域名在一个域名服务器得不到应答时,可以从域名服务池中选取其他域名服务器继续请求。

 

　　具体实现为:将选取的域名服务器IP地址存储在一个servername.dat文件中,在系统初始化时读取servername.dat中的IP地址,并为每一个IP维护一个状态结构体。其中包括域名服务器服务状态量state(1为可用,0为不可用),失败应答计数器。每个结构体以双向链表的形式构成域名服务器池,循环挑选可服务状态的域名服务器作为DNS请求对象。

 

　　当对于一个域名服务器的多个请求没有响应时,可认为该域名服务器已不能正常工作,便将其标记为不可服务,不再为其分配请求,直到此域名服务器又恢复响应能力。为检测域名服务器是否重启,本系统采用了重复检测及检测间隔时间指数级退让的算法[14]。具体流程如图8所示。

 

 

 

 

 

　1.3 DNS解析模块的设计与实现

 

　　本模块完成的任务是:捕获DNS响应包,解析及各种响应包的处理。

 

　　1.3.1 DNS应答包的捕获

 

　　本系统采用伯克利数据包过滤机制,并利用基于BPF(Berkeley packet filter)过滤机制的Libnids数据包捕获工具实现DNS数据包的捕获[12]。

 

　　首先进行Libnids的初始化,通过以下三个参数的设定,达到捕捉DNS包的目的。

 

　　a)nids_params.pcap_filter = port 53,将LIBNIDS的过滤端口号设为53。

 

　　b)nids_params.device = eth0,接收网卡为eth0。

 

　　c)nids_params.promisc = 1, 把网卡设为混杂模式。

 

　　因DNS靠UDP协议传输,故声明一个udp_callback()函数,并注册到libnids环境中。这样,当有目的端口号或源端口号为53的DNS数据包经过eth0网卡时,将自动调用udp_callback()函数,完成此函数内用户自定义的DNS解析功能。

 

　　1.3.2 DNS应答包的解析

 

　　1)应答包格式说明

 

　　在DNS请求包的封装部分已介绍了DNS数据包首部和问题段的格式。在DNS应答包的解析部分主要是对DNS数据包答案段、权威段、附加段的解析。在答案段、权威段和附加段中,DNS信息统一由一种称做资源记录(RR)的格式组织。RR的格式[2]如图9所示。

 

　　0123456789101112131415

 

　　NAME

 

　　TYPE

 

　　CLASS

 

　　TTL

 

　　RDLENGTH

 

　　RDATA

 

　　图9 RR格式

 

　　其中:NAME是按照前文所描述的格式的域名;TYPE和CLASS的意义也与问题域所提及的意义相同。只是TYPE要比QTYPE的类型多一些;TTL是一个32位的有符号数,代表此条资源记录的生存期,若TTL为0表明此条资源记录是易变的或过期的,不适于缓存;RDLENGTH是一个16位无符号数,表明下一字段RDATA的字节长度。对于不同类型的资源记录,RDATA字段的格式也各有不同。

 

　　2)应答包的分类

 

　　首部RCODE的值反映了DNS应答的情况,其值[2]如表2所示。

 

　　表2 RCODE值对应表

 

　　RCODE描述

 

　　0无错误

 

　　1格式错误域名服务器无法解析该请求

 

　　2服务器失败

 

　　3域名不存在

 

　　4没有完成

 

　　5拒绝服务

 

　　由于域名服务器实现的多样性,RCODE值配置的反映错误情况也不尽相同,例如RCODE=3通常表示请求域名不存在,而在ref应答包中RCODE也等于3。所以本系统未采用RCODE值作为区分应答包类型的标准,而是根据各段的资源记录数分类。

 

　　当答案段不为空时,此应答为有效应答,将应答包中所携带的资源记录都解析出来并储存在数据库中。当答案段为空,权威段不为空时,此应答为ref应答,将作迭代查询处理。

 

　　3)有效应答包的处理

 

　　在有效应答包中,除在答案段有相应的答案外,权威段和附加段中也会有与此域名所在域相关的信息。若将所解出的资源记录直接存到数据库中,将破坏这些资源记录的相关性,不利于后期区文件的恢复。因此,在DNS资源记录解析时,解出权威段中NS资源记录的NAME的同时,将此NAME作为这个包中所有资源记录的域,储存在数据库的相应列中。这样,将具有相同域的资源记录组织在一起,使得大量的资源记录可以恢复成一个区文件,便于恢复时加载到BIND[8]解析系统中,提供DNS查询服务。#p#分页标题#e#

 

　　4)ref应答的处理

 

　　对于ref应答,系统提供迭代查询功能。对于权威段不为空的情况,权威段携带的资源记录通常有两类,即SOA记录和NS记录。SOA指出迭代查询下一跳的所在域,NS指出迭代查询下一跳的域名服务器。可根据应答包中和NS匹配的A记录的IP,向下一个域名服务器进行请求。

 

　　有些ref应答包,不含有和NS相关的IP信息。为了处理这种情况,本系统建立了一个搜索表,记录域和对应的域名服务器的IP,用SOA和NS记录反映出的域,在搜索表中找到相应的域名服务器的IP地址。迭代查询流程如图10所示。

 

　　1.4 请求管理模块的设计与实现

 

　　1.4.1 请求队列的创建

 

　　如前文提到的,若大规模向域名服务器发出DNS请求,会增加DNS服务器负担,并占用大量的网络资源。为了对DNS请求包的发送速率和接收速率进行调节,本系统设置请求队列管理模块,由发送线程和接收线程共同控制,以提高请求效率的同时保证应答的质量。同时,该队列维护的各参数也可反映出当前系统的运行状态。

 

　　存储结构:双向队列,索引表。

 

　　请求队列中各节点包括ID、请求内容、发送时间、迭代请求数refcount。

 

　　功能:应答与请求的匹配,控制发送速率,处理过时请求,记录运行状态。

 

　　其中,ID作为应答与请求匹配的标准。正如前文所述,DNS请求包的ID在域名服务器作出应答时会原封不动的拷贝到DNS应答包中。所以当本系统收到应答包后,将解析出的ID作为关键字,在队列中查找具有相同ID的请求,进行匹配。

 

　　随着队列长度的增大,ID查找时间将会增加,严重影响系统的性能。所以实现时为请求队列创建了一个索引表,以ID为索引关键词,节点地址作为索引项。当查询时先用ID在索引表中查找到对应的地址,然后通过地址访问进行相应请求节点的处理。

 

　　索引表通常采用二叉树和Hash表两种形式,鉴于二叉树对动态插入和删除的良好支持,本索引表采用二叉树方案。利用C函数库中的tsearch()、tfind()、twalk()、tdelete(),创建和维护请求队列的搜索表。

 

　　1.4.2 请求队列的管理

 

　　该队列同时有三个线程对其操作,即发送请求时插入节点、取得应答时删除相应节点和超时请求处理。

 

　　具体流程如下:

 

　　a)查看发送队列是否已满,是则等待,否则发送新请求。

 

　　b)每发送一个DNS请求包,将其请求内容及相关信息构成一个请求节点插入到请求队列的尾部,这样在请求队列的头部则为时间轴上靠前的请求。

 

　　c)每收到一个DNS应答包,通过其ID找到相应请求节点。若此应答包为非REF包,则删除相应节点;若此应答包为REF包,则取得此节点的refcount后删除此节点,将refcount+1后,与REF包中的请求段等其他信息构成新节点加入队列的尾部。

 

　　d)扫描队列的头部的请求节点是否超时,超时则重传或删除。

 

　　通过此队列的管理,可维持在网络中的请求数小于队列的最大长度,同时又可以保证有应答返回后,立即会有新的请求发出。

 

　　1.4.3 超时处理(图11)

 

　　因网络状况不佳,域名服务器无响应等原因,在DNS请求中不可避免地会出现请求有去无回的现象。如果对此类超时请求不作及时处理,很快就会堵塞请求队列,使新的请求无法发送出去。所以本系统建立超时处理线程,当发现请求队列中有超时节点时就将其重传或删除。在设计发送队列时已考虑超时处理的需要,每次只在发送队列的队尾插入新的请求,这样队列的头部一定是在时间轴上排在前面的请求,如果其未超时,那么队列中则未超时。

 

　　本系统实现时超时时间设为5 s(参考Windows 2000 DNS服务设置)。

 

　　1.4.4 重传

 

　　DNS协议通过客户服务器交互的形式实现请求与响应。因DNS数据包采用非可靠的UDP协议传输,为处理域名服务器没有响应而在客户端设置重传机制是很有必要的。虽然可以为DNS数据包添加序列号,但由于数据包会在网络中重排列或者在域名服务器中打乱处理顺序,并不能像TCP协议一样依据序列顺序判断是否丢包或重传。在RFC1034和RFC1035中并没有重传机制的规定,但是RFC1035建议最佳的重传机制原则应根据客户端的需要和网络的性能而定。基本原则为:客户端应避免重复地向同一服务器地址发送同一个请求,而应该先尝试其他的服务器。

 

 

 

　重传的时间间隔应基于预先的统计计算。频繁的重传会导致整体的响应效率明显下降。可根据客户端与服务器的连接情况调整重传时间间隔。通常最小的重传时间间隔应为2～5 s。本系统统实现时将超时重传时间设为5 s,当检测到请求超时后则进行重传。最大重传次数为3。

 

　　1.4.5 请求队列管理对发送速率的影响

 

　　下面通过MATLAB计算仿真请求队列的管理对发送速率的影响。

 

　　设一个请求响应的往返时间为rtt,超时时间为timeout,接收率为p,请求队列长度为L,设发送速率函数为SEND(t/rtt),观察T时间内的发送速率SEND的情况。

 

　　假定在理想情况下,当发送队列较小时,请求的域名服务器稳定响应,网络也未出现拥塞状况,丢包率完全因为采用UDP传输造成,则丢包率为定值,接收率也为定值P

 

　　并假定每个请求的往返时间相同为rtt, 忽略发送时间,即接收到响应后立刻发出新的请求:

 

　　在t=0时发出L个请求包,则

 

　　SEND(0)=L

 

　　当t=rtt时,有LP个应答包收到,并立即发送出新的请求,则

 

　　SEND(1)=LP

 

　　此时队列中的等待处理请求为L(1-P),即SEND(0)(1-P);

 

　　当t=2rtt时,有前一次发出去的请求包的一部分应答到,SEND(1)P个应答包接收到,则

 

　　SEND(2)=SEND(1)P

 

　　依此类推,在未作超时处理之前的第i个rtt时间段发出的请求数为

 

　　 SEND(i)=SEND(i-1)P(1)

 

　　当t=timeout=Mrtt时,在第一个rtt内所产生的待处理的请求达到超时时间,将被删除,则此时发出的请求数应为因上一次发出的请求而收到的应答和删除超时请求后队列所产生的空余位置的总和。所以发出的请求数为

 

　　 SEND(M)=SEND(M-1)p+SEND(0)(1-P)

 

　　当t=timeout+rtt=(M+1)rtt

 

　　 SEND(M+1)=SEND(M)+SEND(1)(1-P)

 

　　即当ttimeout时,#p#分页标题#e#

 

　　SEND(i)=SEND(i-1)P+SEND(i-M)(1-P)(2)

 

　　根据式(1)(2),设rtt=500 ms,L=2 000,P=0.7,用MATLAB计算每个时间段的请求包的发送数,画图得发送速率的变化趋势如图12所示。

 

　　如图12所示,通过请求队列的管理,可以根据当时的接收率使发送速率在短时间内稳定在一个合适的值。

 

　　由上述推导公式中可以看出,SEND与L为一次方关系,即在接收率不变的情况下,平稳时的发送速率与队列长度成正比。所以在发送速率不影响接收率的情况下尽量增大队列长度,可提高系统DNS信息的接收效率。

 

　　若当系统运行中t=t2时,接收率发生变化,p=P2,那么:

 

　　当t-timeout

 

　　SEND(i)=SEND(i-1)P2+SEND(i-M+1)(1-P)(3)

 

　　而当t-timeoutt2时,超时处理的同为在接收率是P2下的待处理请求,所以

 

　　SEND(i)=SEND(i-1)P2+SEND(i-M+1)(1-P2)(4)

 

　　根据式(1)~(4),当接收率由P=0.7变为P=0.6时发送速率变化趋势如图13所示。

 

　　1.5 DNS信息存储模块的设计与实现

 

　　为满足存储大量DNS信息的需求,DNS信息存储模块对性能有很高的要求。既要考虑添加数据时频繁的插入和更新操作,又要考虑到存储结构以便区文件的恢复和DNS的查询响应。

 

　　1.5.1 结构设计

 

　　采集到的DNS数据包中主要有A、NS、MX、SOA、CNAME和PTR等DNS记录类型。根据这些记录类型中存储信息的不同和后期DNS信息备份还原的需要,本系统采用如图14所示的数据组织方式。

 

　　1.5.2 性能优化

 

　　在DNS数据存储过程中,主要是对旧的、重复的资源记录的删除操作和对新记录的插入。随着数据量的增大,数据库的删除,插入动作将占用大量资源和时间,成为系统的瓶颈。本系统实现时采用添加索引和为表分区两种方式提高数据库的性能。

 

　　本系统在经常需查询的数据,建立索引。如在where子句出现的host、name等在各表处都添加了索引,性能显著提高。

 

　　数据库分区是一种物理数据库设计技术,可以使特定的SQL操作减少数据读写的总量以缩减响应时间。例如在select语句扫描操作中,若知道哪个分区中才包含特定查询中需要的数据,它就能直接去扫描那些分区的数据,而不必全表扫描。分区是否能有效地提高效率关键是分区表达式和SQL语句的关联程度。以dnsA为例,在DNS数据存储过程中主要是对某主机的新旧信息进行更新,所以主机名host为主要查询变量。本系统采用hash分区方式将表按照host分为10个区。本数据库采用MySQL5.1[15]支持的hash分区方式,但该现版本的数据库系统对分区函数支持有限,只支持少量关于数字和时间的分区函数。所以在dnsA中增加一列hostascii,其值为host的第一个字符的ASCII码,以此数据作为hash函数的变量。相应地在查询、删除SQL语句的where语句中也加入hostascii标准。对于有惟一键的表,分区表达式必须包含所有惟一键(对于符合键,包含其中一部分即可)。所以将hostascii与dnsA_ID一起共同设为主键。

 

　　2 数据分析与系统测试

 

　　1)测试环境 硬件平台为曙光天阔620R服务器;网络平台为服务器所在网络为千兆网络;操作系统为Linux RedHat AS5;数据库系统为MySQL 5.10。

 

　　2)测试测试1 同步DNS解析与异步DNS解析性能对比

 

　　将请求队列大小设为1,则相当于同步DNS解析。以此与请求队列大小为64的异步DNS解析对比。表3为以上两种模式下在10 min内对同一域名列表发送请求的发送速率、接收率和成功率。其中,接收率=接收应答包数/发送请求包数;成功率=接收到的有答案的应答包数/发送的原请求包数,此参数可反映解析的准确率。

 

　　表3 同步模式与异步模式性能对比表

 

　　请求队列大小164倍率

 

　　原请求数27617 41563.1

 

　　ref请求数321 13735.53

 

　　总请求数30818 55260.23

 

　　有答案应答包15910 45065.72

 

　　Ref应答包331 25438

 

　　总应答包20212 38961.33

 

　　接收率65.5866.78+2%

 

　　成功率57.6160+4%

 

　　从表3可看出,异步DNS解析模式的效率大大高于同步模式,且接收率和准确率都未有下降。从与原请求率的倍率基本看出,发送速率几乎与队列长度呈线性增长的关系。

 

　　测试2 请求队列的长度对性能的影响

 

　　为研究请求队列的长度对发送速率、接收率、成功率的影响,令队列长度在500~7 000(步长为500)范围内变化,时间长度为5 min,对同一域名文件内的域名进行解析。

 

　　各队列长度发送速率稳定过程如图15所示。从图15可以看出,发送速率的变化规律基本与仿真结果相同。请求队列越大,平衡建立初期发送速率的波动越大,平衡建立时间越长。这说明请求队列越大,队列建立初期对网络的冲击越大。

 

　　同时可以发现,发送队列越大,发送速率越快。200 s之后,各队列发送速率已经稳定,求出各队列长度200~300 s的平均发送速率,数值如表4所示。

 

 

 

 

 

　表4 各队列长度稳定期发送请求的平均速率

 

　　队列长度平均速率/个/s队列长度平均速率/个/s

 

　　500246.111 000532.8

 

　　1 500731.482 000927.82

 

　　2 5001 405.153 0001 492.07

 

　　3 5001 864.084 0002 112.76

 

　　4 5002 289.635 0002 491.86

 

　　5 5002 547.26 0002 536.31

 

　　7 5002 672.78 0002 879.39

 

　　为更好地反映发送速率与队列长度的关系,以请求队列长度为X轴,5 min内各参数为Y轴绘图,如图16所示。

 

　　从图16可以看出,在同一网络环境下,对于队列长度request_length存在一个最佳值L(在本测试条件下是4 500)。

 

　　在request_length4 500时,5 min内的发送数和接收数都基本上呈线性增长,发送速率和接收速率与队列长度成正比,丢包率较小,在可接收范围内变化。这是因为,较少的请求没有对网络和系统带来负担,丢包率基本上由于UDP传输所导致,丢包率一定。请求队列中超时请求所占的比例较少,一直保持大比例的活跃状态。发送速率基本上由队列长度决定,而接收速率由发送速率决定。

 

　　当4 500

 

　　当request_length6 000时,有答案数和接收的数据包数都有所下降,接收速率的减少使得队列中超时过多的应答包的带来使系统不能维持原有的性能,使性能更加恶化。此时大的丢包率使得请求队列中超时请求占了大部分,由于队列长度本身已经很大,每次删除超时队列中的超时请求后,同时会有大量请求发出,加剧了对网络和域名服务器的冲击。此时,请求队列已经失去了对发送速率的控制,发送速率极度的不稳定,忽快忽慢,造成系统性能严重恶化。#p#分页标题#e#

 

　　由上可以得出,请求队列对发送速率的自适应控制是以较低的丢包率为前提的,所以当丢包率增大时要通过减小队列长度,减小对网络及域名服务器的冲击,保持系统的高效稳定。

 

　　测试3 24 h系统运行情况

 

　　将队列长度固定为4 500,24 h运行异步DNS解析模块的程序。图中X轴为时间轴,从18:00运行到次日18:00,Y轴为1 min内的各参数值,趋势如图17所示。

 

　　图17中每分钟接收数和接收率在凌晨0:00～6:00有明显的提高,这是由于夜间的网络负载较低,网络状态较好导致。同时也说明请求队列的设置本身有一定自适应调节发送速率的能力,网络状态较好时,发送速率就高一些,网络情况较差时,发送速率就较低。各参数统计值如表5所示。

 

　　表5 24 h运行各参数统计

 

　　项目数值

 

　　原始请求发送数1.66 292108

 

　　ref信息发送数1.20 593107

 

　　总发送数1.78 351108

 

　　有答案应答接收数4.27 736107

 

　　ref信息接收数6.03 007107

 

　　总接收数1.11 736108

 

　　每秒请求发送数2 052

 

　　每秒应答接收数1 286

 

　　每秒有效应答接收数492

 

　　平均接收率0.6 237

 

　　测试4 针对ref信息的迭代查询的效率

 

　　在软件测试阶段发现,在选取的域名服务器中,虽然所有的域名服务器对请求都有应答,但部分域名服务器并不提供递归查询服务[11]。对于非递归域名服务器,其将返回ref信息。为了解ref信息所占的比例及其对性能的影响,作了如下测试:

 

　　考虑到不同域名服务器对不同域名的回应能力不同,本测试只选取一个域名服务器,通过向其发送非递归请求以模拟域名服务器不支持递归请求的情况,即将请求包的RD位置0。测试数据为:域名文件中域名数有1 000个,域名服务器IP地址为202.138.96.2。测试结果如图18所示。

 

　　其中:A为客户端不支持迭代查询;B为客户端支持迭代查询,域名服务器不支持递归查询;C为客户端支持迭代查询,域名服务器支持递归查询。

 

　　从图18可以看出,若域名服务器不支持递归请求,而单一的依靠客户端做迭代查询,将大大增加请求包和应答包的数量,且应答的质量也大大下降。所以应尽量选取支持递归服务的域名服务器,才能达到高效、高质量的要求。

 

　　3 结束语

 

　　本文通过对DNS系统及协议的分析,设计并实现了一种高效的DNS信息备份及恢复系统。通过结合被动捕获DNS数据包和主动请求两种方式,并利用异步请求模式可以高效得到大量DNS解析信息。同时,本文设计的基于请求队列管理的发送速率控制方法可有效地实现接收速率和发送速率的匹配,使整个系统更加高效、稳定。

 

　　目前该系统可以在10 h内解析出和3 358 427个域名相关的DNS信息,包括4 827 349个A、NS、MX记录,823 512个SOA记录。这些DNS信息样例,有代表性地体现了现行DNS系统和网络中常见的DNS类型及其相关性。此系统的高效性已可满足为DNS应急备份系统提供数据源和更新源的要求。此DNS信息获取系统已成功地运行在相关课题中,其采集到的第一批数据已作为DNS系统分布研究的统计分析数据。并将这些大量的DNS信息重新组建,恢复成与BIND兼容的ZONE文件形式,通过配置好的BIND,响应客户端的DNS请求。基本上完成了DNS应急备份系统的功能。

 

　　除此之外,由本系统获得的DNS数据还可用于其他项目,如针对基于Netflow的大规模网络异常事件检测、骨干网监测、事件自动报告等系统,对网络的安全运行具有重大的意义。

 

　　参考文献:

 

　　[1]MOCKAPETRIS P. RFC 1034, Domain names-concepts and facili-tiess[S]. 1987.

 

　　[2]MOCKAPETRIS P. RFC 1035, Domain-implementation and specification[S]. 1987.

 

　　[3]BROWNLEE N, CLAFFY K C, NEMETH E. DNS measurements at a root server [C]//Proc of IEEE Global Telecommunications Conference. 2001:1672-1676.

 

　　[4]王垚,胡铭曾,李斌,等.域名系统安全研究综述[J].通信学报. 2007, 28(9):91-103.

 

　　[5]OpenNIC [EB/OL]. http://www.opennicproject.org/.

 

　　[6]NEW.NET [EB/OL]. http://www.new.net/.

 

　　[7]NAME.SPACE. [EB/OL]. http://name-space.com/.

 

　　[8]陈刚,吕绪康,王宗敏. CERNET省域网后备域名系统的设计与实现[J]. 通信学报, 2006, 27(z1):140-142.

 

　　[9]ALBITZ P, LIU C. DNS and BIND [M]. 4th ed. Canberra: OReilly  Associates Inc, 2001.

 

　　[10]WEIMER F. Passive DNS replication[C]// Proc of the 17th Annual FIRST Conference. 2005:1-13.

 

　　[11]BONANNO T, KIM H J, PARK J.Design and implementation of recursive DNS server [C]//Proc of IEEE ICACT. 2006:641-644.

 

　　[12]刘文涛. 网络安全开发包详解[M].北京:电子工业出版社, 2005.

 

　　[13]MATTHEW N, STONES R. Linux程序设计[M].北京:人民邮电出版社, 2007.

 

　　[14]CORMEN T H, LEISERSON C E, RIVEST R L, et al.Introduction to algorithms [M]. 2nd ed. Cambridge: The MIT Press, 2001.

 

　　[15]MySQL 5.1 reference manual[EB/OL]. (2009). http://dev.mysql.com/doc/refman/5.1/en/.