CN109347996A - 一种dns域名获取系统及方法 - Google Patents

Abstract

本发明公开了一种DNS域名获取系统及方法。包括：DNS请求包发送子系统、DNS管理子系统和DNS应答包接收与分析子系统，DNS请求包发送子系统、DNS管理子系统和DNS应答包接收与分析子系统多线程并行工作；DNS请求包发送子系统用于DNS请求数据包的发送与重发；DNS应答包接收与分析子系统用于接收DNS应答包，并判断DNS应答包是否为DNS请求包对应的应答包；DNS管理子系统用于管理域名解析服务的状态值，以及在DNS请求数据包发送后进行计时，根据DNS应答包接收与分析子系统接收到的DNS应答包确定需重发的DNS请求数据包，并当计时到设定时间时，触发DNS请求包发送子系统对需重发的DNS请求数据包进行重新发送。本发明提供的DNS域名获取系统及方法具有高效、准确的特点。

Description

一种DNS域名获取系统及方法

技术领域

本发明涉及DNS域名获取领域，特别是涉及一种DNS域名获取系统及方法。

背景技术

在短时间内获取大量的域名数据信息，最快的方法是去找服务器管理员拷贝，其次，就是通过实时监测域名服务器端口获取域名数据信息，这两种方法无疑会是最快和最简单的方法，但是，由于每天互联网上都有大量的域名解析请求，上述两种方法也很难高效的完成。

对于通过实时监测域名服务器端口获取域名数据信息这种方法，在现有方案中大致可分为同步和异步两大类。同步方案，获取数据是准确的，但是效率很慢，一次只能发送一个请求包并且只能等到应答包回来并解析之后才能发送下一条，这无疑会浪费大量的时间，无法在短时间内获取大量的信息。异步方案，能在短时间内获取大量的域名信息，但是，获取数据的正确率无法得到保证。

发明内容

本发明的目的是提供一种DNS域名获取系统及方法，具有高效、准确的特点。

为实现上述目的，本发明提供了如下方案：

一种DNS域名获取系统，包括：DNS请求包发送子系统、DNS管理子系统和DNS应答包接收与分析子系统，所述DNS请求包发送子系统、DNS管理子系统和DNS应答包接收与分析子系统多线程并行工作；

所述DNS请求包发送子系统用于DNS请求数据包的发送与重发；

所述DNS应答包接收与分析子系统用于接收DNS应答包，并判断DNS应答包是否为DNS请求包对应的应答包；

所述DNS管理子系统用于管理域名解析服务的状态值，以及在DNS请求数据包发送后进行计时，根据所述DNS应答包接收与分析子系统接收到的DNS应答包确定需重发的DNS请求数据包，并当计时到设定时间时，触发所述DNS请求包发送子系统对需重发的DNS请求数据包进行重新发送。

可选的，所述DNS请求包发送子系统包括：

读取模块，用于读取待查询域名的数据列表以及域名解析服务器的数据列表；

封装模块，用于将读入的域名数据列表中的各待查域名分别封装到DNS请求包；

域名解析服务器选取模块，用于选取域名服务器列表中状态值小于设定值的域名解析服务器，记为目的服务器；

发送模块，用于所述目的服务器发送DNS请求包，并当数据发送完毕之后，释放发送端口；

请求节点插入模块，用于记录发送时间，把由请求包的ID、目的服务器以及发送时间构成的请求节点插入到请求队列队尾。

可选的，所述DNS应答包接收与分析子系统包括：

网卡监测模块，用于监测网卡上的数据，捕获DNS数据包；

解析模块，用于对捕获的DNS数据包进行解析。

可选的，所述DNS管理子系统包括：

请求队列管理模块，用于管理DNS请求包发送线程的请求节点插入请求队列队尾，用于管理DNS应答包接收与分析线程对请求队列中与应答包对应ID的请求节点的查找与删除，用于管理DNS管理线程对请求队列的每个节点的超时监控；

域名服务器管理模块，用于获取设定时间内没有收到DNS应答包的请求节点的域名信息和解析服务器信息，将所述解析服务器的状态值加1，所述域名的发送请求次数加1；

重发模块，用于判断没有收到应答包的域名对应的发送请求次数是否大于预设值，如果是，则删除所述域名查询，如果否，则重发。

可选的，所述域名服务器管理模块还用于根据各解析服务器的状态值对解析服务器进行排序。

可选的，所述系统还包括数据存储子系统，用于对解析后DNS数据包进行存储。

本发明还提供了一种DNS域名获取方法，所述方法应用于一种服务器域名获取系统，所述系统包括DNS请求包发送子系统、DNS管理子系统和DNS应答包接收与分析子系统，所述DNS请求包发送子系统、DNS管理子系统和DNS应答包接收与分析子系统多线程并行工作，所述方法包括：

DNS请求包发送子系统将待查询域名列表中的待查询域名分别封装到查询请求包，得到多个域名查询请求包；

DNS请求包发送子系统选择域名解析服务器并将各域名查询请求包多线程并行发送至对应的域名解析服务器；

应答接收分析子系统接收应答包，并对所述应答包进行解析；

DNS管理子系统判断应答包是否为域名查询请求包对应的应答包；

如果是，则DNS管理子系统在重发列表中删除所述应答包对应的域名查询请求包，所述重发列表中包含的域名与所述待查询域名列表中包含的域名相同；

DNS管理子系统判断是否将所有域名查询请求包发送完毕，且距发送域名查询请求包的时间到达设定时间；

如果是，则DNS请求包发送子系统重新选择域名解析服务器，并对所述重发列表中的域名重新发送。

可选的，所述方法还包括：

所述DNS管理子系统根据各解析服务器的状态值对解析服务器进行排序；

所述DNS请求包发送子系统从解析服务器排序序列中优先选择状态值小的解析服务器。

可选的，所述DNS请求包发送子系统选择域名解析服务器，具体包括：

所述DNS请求包发送子系统选择多个状态值小于设定值的域名解析服务器。

可选的，所述DNS请求包发送子系统重新选择域名解析服务器，具体包括：

DNS请求包发送子系统选择状态值小于预设值，且未被选择过的域名解析服务器。

根据本发明提供的具体实施例，本发明公开了以下技术效果：本发明提供的DNS域名获取系统及方法，通过异步的主动捕获DNS数据包和主动请求两种方式，实现了高速和高效DNS获取。发送与接收通过DNS管理系统进行调控，使在高速发送查询请求的同时保证了高效性。对于没有收到应答包的查询，采取重发机制，若多次重发没收到应答包删除该域名，提高系统效率。有效的对故障服务器或不工作的服务器进行判断，提高系统的效率。而且，本发明对解析服务器列表中的服务器进行排序，对响应较快的服务器排在前面，多使用响应较快的域名服务器，提高了查询的速率。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例域名获取系统总体结构框图；

图2为本发明实施例DNS报文格式图；

图3为本发明实施例Flags报文格式图；

图4为本发明实施例Queries格式图；

图5为本发明实施例OPT-RR结构图；

图6为本发明实施例RDATA格式图；

图7为本发明实施例DNS请求发送系统线程图；

图8为本发明实施例超时监测流程图；

图9为本发明实施例域名服务器管理流程图；

图10为本发明实施例重发模块流程图；

图11为本发明实施例网卡监测模块流程图；

图12为本发明实施例RR格式图；

图13为本发明实施例解析存库模块流程图；

图14为本发明实施例DNS域名获取方法流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的目的是提供一种DNS域名获取系统及方法，具有高效、准确的特点。

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

图1为本发明实施例域名获取系统总体结构框图，如图1所示，本发明提供的域名获取系统包括：DNS请求包发送系统、DNS管理系统、DNS应答包接收与分析系统和数据存储系统四个子系统组成。系统的总体结构框图如图1所示。

DNS请求发送子系统1，负责完成域名查询列表和域名服务器列表读取操作，并根据域名查询列表中的顺序将需要查询的域名按照EDNS报文格式封装到DNS查询请求包中；然后，从域名服务器列表中选择合适的域名服务器作为指定的域名查询服务器；最后完成DNS请求数据包的发送，将其请求内容及相关信息和发送时的时间构成一个请求结点交给管理模块，并在需要时完成对请求数据包的重发。

DNS管理子系统2，负责对请求队列的增加和删除，以及域名服务器状态值的修改，对域名服务器响应速度计算，根据响应速度对域名服务器列表进行排序，对超过时间内没收到应答包的域名查询请求进行重发处理。

DNS应答接收与分析子系统3，主要完成对网卡上的数据进行检测，并判断网卡数据是否为DNS数据包，对收到的DNS应答包，由DNS应答包头部ID构成待解析结点保存到待解析队列的尾部，判断是否是请求包对应的应答包，对收到的正确的应答包进行数据的解析。

数据存储子系统4，将解析出的查询响应的数据内容分别存储到数据库的相应数据表中，以备后续的处理使用。

为了构造DNS请求包和解析DNS应答包，需要深入理解DNS报文格式以及DNS传输协议。下面简要介绍本发明涉及的DNS和EDNS报文格式内容。

DNS报文格式

在DNS协议中通常采用UDP传输协议进行报文传递。DNS的报文格式(如图2)由12Byte长的首部(Header)和4个长度可变的字段(Question、Answer、Authority和Addition)所组成，如图2所示。其中，头部(Header)指明了DNS报文中将包含哪些段以及此DNS报文是请求还是响应、是标准请求还是其他的类型。Queries(查询问题区)包含向域名服务器查询的信息，其中，Answers(回答区)、Authoritative nameservers(授权区)和Additional record(附加区)均采用一种称为资源记录RR(Resource Record)的相同格式。Answers中包含直接回答问题段的资源记录，Authoritative nameservers包含可以指向权威服务器的RRs(基本上是NS记录)，Additionalrecord包含和请求相关的信息，但不是直接回答问题(如NS，MX记录对应的A记录)。在请求报文中没有回答区、授权区和附加区。

ID(会话标识)：这是DNS查询程序指定的16位请求标识符，每次查询均会随机分配一个标识符。该标识符也被随后的应答报文所用，也就是应答报文中的标识符与其对应的请求报文中的标识符是一样的，这样即可区分应答消息所对应的请求消息。

Flags格式如图3所示。

QR(1bit)：查询/响应标志，0为查询，1为响应；

OPCODE(4bit)：0表示标准查询，1表示反向查询，2表示服务器状态请求；

AA(1bit)：授权回答；

TC(1bit)：表示可截断；

RD(1bit)：表示期望递归；

RA(1bit)：表示可用递归；

ZERO(3bit)：为保留字节；

RCODE(4bit)：表示返回码，0表示没有差错，3表示名字差错，2表示服务器错误。

Queries格式如图4所示。在数据包中，以“.”为分隔符，把域名的各个段分别保存在各个labels中。每个labels包含一个字节表示后续字符串的长度，以及这个字符串。最后的根“.”是一个字节的全0表示。接下来分别是两个字节的Type和Class。以www.baidu.com为例，DNS报文的Queries区域。

但随着DNS服务器的需求，RFC1035中定义的DNS消息格式和它支持的消息内容已经不足以应对DNS的复杂化和多样化。

RFC1035中DNS协议头部的16位Flags已经被用的差不多了，需要添加新的返回类型(ECODE)和标记(FLAGS)来支持其他需求；DNS协议头部的3位预留位为了表示domain类型(00表示字符串类型，11表示压缩类型)已经用掉了两位，无法支持更多的标签类型；最初DNS协议中设计的用UDP包传输时，UDP包的大小限制在512字节之内，现如今很多主机具备重组大数据包的能力，所以需要一种机制允许DNS请求方通知DNS服务器让其返回大数据包。

为了解决上述问题，引入了一种扩展DNS机制——ENDS0(Extension MechanismsforDNS Version 0，是在RFC1035基础上对DNS协议的扩展)。

EDNS中引入了一种新的伪资源记录OPT(Resource Record)，之所以叫伪资源记录是因为它不包含任何DNS数据，OPT RR不能被cache、不能被转发、不能被存储在zone文件中。OPT被要求放在DNS通信双方(requestor和responsor)DNS消息的Additional record区域中。DNS的扩展机制允许DNS请求者公布其UDP数据包的大小，并且能传输大于512字节的数据包(RFC1035规定DNS数据包的大小不能超过512字节)。DNS服务器通过UDP传输层接收请求时，它对来自OPT资源记录(RR)的请求者的UDP数据包大小进行标识，测量其响应，以包含请求者指定的最大UDP数据包大小中允许的多个资源记录。

EDNS0的作用：

1.扩展DNS使用UDP传输时的最大报文限制，可以超过512字节；

2.扩展RCODE，由4为增加到12位；

3.建议利用域名标签类型的剩余的10和01(00表示字符串类型，11表示压缩类型)。

EDNS0相对于DNS协议变化：

1.增加OPT RR结构

2.交互流程的变化

(1)客户端发起DNS请求，在Additional部分增加OPT RR；

(2)服务器端解析并记录下客户端能够处理的最大UDP报文的大小；

(3)服务器端生成相应报文，若大于最大值，则置truncated位，否则可发送大于512且小于最大值报文。

OPT-RR结构如图5所示。图5中最下面的Rdata和RDLength是可变部分，其余的部分都是固定部分。

FieldName FieldType Description

NAME domainname empty(root domain)

Type u_int16_t OPT(41)

Class u_int16_t sender’s UDPpayload size

TTL u_int32_t extended RCODE andFlags

RDLength u_int16_t describes Rdata

Rdata octet stream pairs

Edns-client-subnet的详细格式存在RDATA中，如图6所示，OPTION-CODE：2个字节，

OPTION-LENGTH：2个字节，描述它之后的内容长度(BYTE)，

FAMILY：2个字节，1表示ipv4，2表示ipv6，

ADDRESS：实际存放IP地址的地方，ipv4长度为4。

在请求DNS服务器发送查询之前，它会检查其缓存以确定响应的DNS服务器是否支持EDNS0。如果响应的DNS服务器支持EDNS0，则请求的DNS服务器将OPT资源记录附加到它发送的查询的附加部分。如果，响应的DNS服务器不支持EDNS0，请求的DNS服务器将不会附加OPT资源记录发送之前的查询。当DNS服务器接收包含OPT记录的主机的请求或响应时，DNS服务器会缓存该主机支持的EDNS版本(例如EDNS0)。如果来自主机的请求或响应中没有OPT记录，DNS服务器的高速缓存会指出主机不支持EDNS。如果高速缓存已经支持该主机支持EDNS，则不会更改高速缓存。缓存主句的EDNS支持信息的时间的默认值为25200(以秒为单位指定的一周)。

OPT记录不包含实际的DNS数据，其内容仅与UDP传输层消息相关。OPT记录将发送方的UDP有效负载大小存储在其CLASS字段中，并列出请求方可在请求方网络中提供的最大UDP有效负载中的八位字节数。

当DNS服务器收到包含公布的最大UDP数据包大小的OPT记录的查询时，它将截断任何大于OPT记录中指定的限制的UDP响应大小。默认情况下，DNS服务器包括OPT资源记录，指示对包含OPT资源记录的查询的响应中的UDP最大值。

如果DNS服务器收到不包含OPT资源记录的查询，则它假定请求者的服务器不支持EDNS0并且将响应请求者，假设发送者不接受大于512个八位字节的UDP数据包。在这种情况下，DNS服务器将其UDP响应大小截断为最多512个八位字节。

DNS请求包发送子系统线程如下：

本系统主要完成DNS请求包的封装，请求结点构建以及向选定的域名服务器发送DNS请求包。

DNS请求包发送系统线程如图7所示。第一步：把需要查询域名的数据列表以及域名解析服务器的数据列表读取到程序中，并建立域名指针QP和服务器指针SP(其目的是为了更方便的访问域名数据列表和服务器数据列表)；第二步：从读入的域名数据列表中选取QP所指向的待查域名，根据DNS和ENDS报文格式的规定封装到DNS请求数据包；第三步：从域名服务器列表中选取SP所指向的DNS服务器，并判断目的DNS服务器的状态值是否大于等于5，若状态值大于5，表示目的DNS服务器无法正常工作，则需要通过修改SP(服务器指针)的值来选取下一个目的DNS服务器，若状态值小于等于5，表示该DNS服务器可以正常工作，则根据UDP(UserDatagram Protocol)数据协议的规定封装DNS请求包；第四步，判断请求队列和解析队列是否已满，若两个队列其中任何个满了，则等待，直到两个队列都不为满进行下一步；第五步：向目的服务器发送DNS请求包，当数据发送完毕之后，立即释放发送端口，为别的发送线程提供端口；第六步：记录发送时间，把由请求包的ID、DNS请求数据包、目的DNS服务器以及发送时间构成的请求结点插入到请求队列队尾；第七步：判断域名数据指针QP是否指向域名数据列表底部，若没有，表示该域名数据列表还未查询完，把域名数据指针QP+1指向下一条待查询域名，返回到第二步开始查询下一条域名；第八步：若是，表示该待查域名数据列表已经初次查询完成，结束DNS请求包发送线程。

DNS管理子系统2包括请求队列管理模块、域名服务器管理模块和重发模块。

向单个DNS域名服务器大规模的发送查询请求，服务器会负载过重，应答效率会降低，更有甚者会屏蔽系统的请求。选择多个DNS域名服务器发送查询请求，将请求分散，进而降低服务器的负载。

DNS管理系统统筹控制整个系统，合理的管理整个系统运行，提高系统的效率。帮助DNS应答包接收与分析系统快速的查找相应ID的请求结点，管理请求队列以及根据各个域名服务器响应速度对域名服务器列表进行快速排序。DNS管理系统主要由请求队列管理模块、域名服务器管理模块以及重发模块组成。

请求队列管理模块：

如图8所示，请求队列由DNS请求包发送线程、DNS管理线程和DNS应答包接收与分析线程共同管理，DNS请求包发送线程主要是向请求队列队尾插入请求节点，DNS应答包接收与分析线程主要查找队列中与应答包对应ID的请求结点以及计算对应域名服务器响应时间之后删除查找到的对应结点，DNS管理线程则完成对请求队列的每个结点超时监控，当某个请求结点超时，需要把超时请求结点从请求队列中取出。

队列的存储结构为双向链表，主要功能是实现请求与应答的异步匹配，控制发送速率，以提高请求效率的同时保证应答的质量，处理过时请求。

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

高速发送DNS请求，请求队列长度会不断增长，DNS应答包接收与分析线程在查找ID的时间会不断增加，严重影响系统的效能。为了实现高速精确查找，为请求队列创建一个索引表，以ID作为索引的关键词。为了方便队列的插入与删除，索引表采用二叉树的结构形式。

该队列同时有三个线程对其进行操作，分别如下：

DNS请求包发送线程查看队列是否已满，是则等待，否则发送新请求，没发送一个DNS请求包，把结点插入到队列的尾部。

DNS应答包接收与分析线程每收到一个DNS应答包，根据应答包的ID查找相应的请求结点，若找不到，接收线程删除此应答包；若找到，计算相应服务器的响应时间之后并删除请求结点。

DNS管理线程监测队列头部的请求结点是否超时，超时则把结点中取出并删除。

域名服务器管理模块：

如图9所示，对于没有收到DNS应答包的请求，可能是目的域名服务器故障或者没有工作，也有可能该域名不存在，域名服务器列表管理模块主要完成对上面第一种情况进行处理。超时请求结点，把结点中的查询域名信息和目的服务器信息取出，并且把域名服务器的状态值加1，为查询域名创建一个查询次数变量Qcount，并把查询次数值加1。域名服务器管理模块还有一个功能就是根据服务器响应的平均速度对域名服务器进行快速排序。

重发模块：

如图10所示，对于没有收到应答包的域名需要重新发送请求查询。首先判断该域名查询几次，若查询次数大于5，则删除该域名查询，否则重发。重发模块与请求线程大部分相同，主要不同点是选择域名服务器，重发时的域名服务器不仅要求状态值小于5，还要求服务器不能是前几次查询使用的域名服务器。

DNS应答包接收与分析系统3主要完成对网卡数据包监测，查找请求队列中请求结点，计算服务器响应的时间，解析DNS应答包以及把解析出来的数据存储到DNS数据库中。DNS应答包接收与分析系统分别由网卡监测模块和解析存库模块组成。为了匹配应答包接收速度和解析速度，采用缓存机制进行速度匹配，采用队列形式缓存机制。网卡模块把接收到的DNS应答包插入到待解析队列的尾部，解析存库模块从队列的头部取出DNS应答包进行数据解析与存库。

DNS应答包接收与分析系统3包括网卡监测模块和解析存库模块。

网卡监测模块主动去监测网卡上的数据，首先判断数据包是否为UDP数据包，若不是UDP数据包，丢弃数据包，接着监测，若是UDP数据包，接着判断是不是从服务器的53端口发送过来的数据包，若不是，丢弃数据包，若是，则把数据包插入到待解析队列的尾部。网卡监测模块流程如图11所示。本模块采用伯克利数据包过滤机制，设计了端口号识别函数，实现DNS数据包的捕获。因DNS靠UDP协议传输，故根据UDP传输协议设计了根据传输协议(UPD)作为过滤条件的过滤函数。这样，当有数据包流入网卡时，自动调用过滤函数和端口识别函数对数据包识别，为DNS数据包插入解析队列。

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

解析程序根据上面的RR格式，对DNS应答包进行数据解析，在应答包中，除在答案区有相应的答案外，权威区和附加区中也会有与此域名所在域相关的信息。若将所解出的资源记录直接存到数据库中，将破坏这些资源记录的相关性，不利于后期区文件的恢复。因此，在DNS资源记录解析时，解出权威区中NS资源记录的NAME的同时，将此NAME作为这个包中所有资源记录的域，储存在数据库的相应列中。这样，将具有相同域的资源记录组织在一起，使得大量的资源记录可以恢复成一个区文件，便于恢复。解析存库模块流程图如图13所示。

本系统主要应用于DNS数据的捕获、更新和备份，在实现性能上，要求系统应该在单位时间内尽可能多的获取有效DNS信息。本发明采用异步DNS收发模式，有效利用单个域名服务器在进行查询的空闲，通过采用多线程并行请求-接收的模式，极大的缩短了DNS数据获取的时间，实现了在更短时间内获取更多特定DNS域名服务器下的数据信息。在发送请求包和接收应答包的同时监视请求队列头部的请求节点是否超时，对超时没收到应答包的请求，本设计还采用了重发的机制。在查询域名过程中，若多次没收到某个域名服务器的DNS应答包，认为该服务器故障或不工作。

本发明通过对DNS系统及协议的分析，设计并实现了一种高效的DNS信息备份及恢复系统。为了提高系统的效率，通过异步的主动捕获DNS数据包和主动请求两种方式；实现了高速和高效DNS获取。发送与接收通过DNS管理系统进行调控，使在高速发送查询请求的同时保证了高效性。对于没有收到应答包的查询，采取重发机制，若多次重发没收到应答包删除该域名，提高系统效率。有效的对故障服务器或不工作的服务器进行判断，提高系统的效率。根据不同服务器平均响应速度的快慢，对服务器列表快速排序，对响应较快的服务器排在前面，多使用响应较快的域名服务器，以提高查询的速率。为了获取更多的DNS相关信息内容，在每次查询中都采用ENDS0协议进行查询，不仅能得到IPv4地址还有得到IPv6地址、记录该域名的权威名称服务器以及与DNS安全相关信息。

本文根据DNS查询基本原理，实现了连续的发包、收包和解析的过程，实现了高效的DNS信息获取。同时对多个DNS服务器进行访问查询，避免对单一的DNS服务器进行查询访问时造成服务器端认为是DDOS攻击，还能避免给服务器造成过大的负担，让查询效率降低。该方案能保证收到的应答包的正确率。

本发明还提供了一种DNS域名获取方法，如图14所示，该方法包括：

步骤101：DNS请求包发送子系统将待查询域名列表中的待查询域名分别封装到查询请求包，得到多个域名查询请求包；

步骤102：DNS请求包发送子系统选择域名解析服务器并将各域名查询请求包多线程并行发送至对应的域名解析服务器；

步骤103：应答接收分析子系统接收应答包，并对应答包进行解析；

步骤104：DNS管理子系统判断应答包是否为域名查询请求包对应的应答包；

步骤105：如果应答包为域名查询请求包对应的应答包，则DNS管理子系统在重发列表中删除应答包对应的域名查询请求包，重发列表中包含的域名与待查询域名列表中包含的域名相同；

步骤106：DNS管理子系统判断是否将所有域名查询请求包发送完毕，且距发送域名查询请求包的时间到达设定时间；

步骤107：如果所有域名查询请求包发送完毕，且距发送域名查询请求包的时间到达设定时间，则DNS请求包发送子系统重新选择域名解析服务器，并对重发列表中的域名重新发送。

其中，本发明提供的方法还包括：DNS管理子系统根据各解析服务器的状态值对解析服务器进行排序；DNS请求包发送子系统从解析服务器排序序列中优先选择状态值小的解析服务器。

步骤102中DNS请求包发送子系统选择的域名解析服务器为多个，且状态值小于设定值。

步骤107中DNS请求包发送子系统选择的域名解析服务器为状态值小于预设值，且未被选择过的域名解析服务器。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处。综上，本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种DNS域名获取系统，其特征在于，包括：DNS请求包发送子系统、DNS管理子系统和DNS应答包接收与分析子系统，所述DNS请求包发送子系统、DNS管理子系统和DNS应答包接收与分析子系统多线程并行工作；

所述DNS请求包发送子系统用于DNS请求数据包的发送与重发；

所述DNS应答包接收与分析子系统用于接收DNS应答包，并判断DNS应答包是否为DNS请求包对应的应答包；

所述DNS管理子系统用于管理域名解析服务的状态值，以及在DNS请求数据包发送后进行计时，根据所述DNS应答包接收与分析子系统接收到的DNS应答包确定需重发的DNS请求数据包，并当计时到设定时间时，触发所述DNS请求包发送子系统对需重发的DNS请求数据包进行重新发送。

2.根据权利要求1所述的DNS域名获取系统，其特征在于，所述DNS请求包发送子系统包括：

读取模块，用于读取待查询域名的数据列表以及域名解析服务器的数据列表；

封装模块，用于将读入的域名数据列表中的各待查域名分别封装到DNS请求包；

域名解析服务器选取模块，用于选取域名服务器列表中状态值小于设定值的域名解析服务器，记为目的服务器；

发送模块，用于所述目的服务器发送DNS请求包，并当数据发送完毕之后，释放发送端口；

请求节点插入模块，用于记录发送时间，把由请求包的ID、目的服务器以及发送时间构成的请求节点插入到请求队列队尾。

3.根据权利要求1所述的DNS域名获取系统，其特征在于，所述DNS应答包接收与分析子系统包括：

网卡监测模块，用于监测网卡上的数据，捕获DNS数据包；

解析模块，用于对捕获的DNS数据包进行解析。

4.根据权利要求1所述的DNS域名获取系统，其特征在于，所述DNS管理子系统包括：

请求队列管理模块，用于管理DNS请求包发送线程的请求节点插入请求队列队尾，用于管理DNS应答包接收与分析线程对请求队列中与应答包对应ID的请求节点的查找与删除，用于管理DNS管理线程对请求队列的每个节点的超时监控；

域名服务器管理模块，用于获取设定时间内没有收到DNS应答包的请求节点的域名信息和解析服务器信息，将所述解析服务器的状态值加1，所述域名的发送请求次数加1；

重发模块，用于判断没有收到应答包的域名对应的发送请求次数是否大于预设值，如果是，则删除所述域名查询，如果否，则重发。

5.根据权利要求4所述的DNS域名获取系统，其特征在于，所述域名服务器管理模块还用于根据各解析服务器的状态值对解析服务器进行排序。

6.根据权利要求1所述的DNS域名获取系统，其特征在于，所述系统还包括数据存储子系统，用于对解析后DNS数据包进行存储。

7.一种DNS域名获取方法，其特征在于，所述方法应用于一种服务器域名获取系统，所述系统包括DNS请求包发送子系统、DNS管理子系统和DNS应答包接收与分析子系统，所述DNS请求包发送子系统、DNS管理子系统和DNS应答包接收与分析子系统多线程并行工作，所述方法包括：

DNS请求包发送子系统将待查询域名列表中的待查询域名分别封装到查询请求包，得到多个域名查询请求包；

DNS请求包发送子系统选择域名解析服务器并将各域名查询请求包多线程并行发送至对应的域名解析服务器；

应答接收分析子系统接收应答包，并对所述应答包进行解析；

DNS管理子系统判断应答包是否为域名查询请求包对应的应答包；

如果是，则DNS管理子系统在重发列表中删除所述应答包对应的域名查询请求包，所述重发列表中包含的域名与所述待查询域名列表中包含的域名相同；

DNS管理子系统判断是否将所有域名查询请求包发送完毕，且距发送域名查询请求包的时间到达设定时间；

如果是，则DNS请求包发送子系统重新选择域名解析服务器，并对所述重发列表中的域名重新发送。

8.根据权利要求7所述的DNS域名获取方法，其特征在于，所述方法还包括：

所述DNS管理子系统根据各解析服务器的状态值对解析服务器进行排序；

所述DNS请求包发送子系统从解析服务器排序序列中优先选择状态值小的解析服务器。

9.根据权利要求7所述的DNS域名获取方法，其特征在于，所述DNS请求包发送子系统选择域名解析服务器，具体包括：

所述DNS请求包发送子系统选择多个状态值小于设定值的域名解析服务器。

10.根据权利要求7所述的DNS域名获取方法，其特征在于，所述DNS请求包发送子系统重新选择域名解析服务器，具体包括：

DNS请求包发送子系统选择状态值小于预设值，且未被选择过的域名解析服务器。