CN111371920A - Dns前端解析方法及系统 - Google Patents

Abstract

本发明公开了一种DNS前端解析方法及系统，其中所述方法包括如下步骤：通过轮询确定数据链路层接收到的网络报文；获取所述网络报文所在缓存区的控制权并判断所述网络报文的类型；在所述网络报文属于指定类型的DNS请求时直接执行解析处理，否则按照网络报文类型选择备用流程处理。本发明可以提高网络收发包的速度，进而提升整体DNS解析的性能。

Description

DNS前端解析方法及系统

技术领域

本发明涉及计算机网络通信技术领域，尤其涉及一种DNS前端解析方法及系统。

背景技术

DNS（Domain Name System，域名系统）提供了互联网上的一个重要服务，其本质是建立了人的名字世界和底层的二进制协议地址世界的桥梁。它作为将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网，而不用去记住能够被机器直接读取的 IP地址数串，通过域名最终得到该域名对应的 IP 地址的过程叫做域名解析。然而，5G以及物联网的发展，带来了网络流量爆发式的增长，而DNS解析作为互联网的一项基础服务之一，其是否能够提供一个高性能的解析便直接影响到5G以及物联网的最终实现。

目前，现有技术中实现DNS解析的架构均采取内核态收发包的架构，而网络报文从网卡经过内核态最终到达用户态的过程存在很大的资源消耗，导致运行在内核态的DNS服务程序极限性能仅能达到200万QPS（Queries per second，每秒查询率）左右，这样的速度存在很大的瓶颈，完全无法满足5G以及物联网对DNS解析的要求。

发明内容

本发明的目的在于提供一种DNS前端解析方法及系统，解决了现有技术中网络收发包速度慢，DNS解析性能不佳的技术问题。

为了解决上述技术问题，本发明的一种DNS前端解析方法，包括如下步骤：

通过轮询确定数据链路层接收到的网络报文；

获取所述网络报文所在缓存区的控制权并判断所述网络报文的类型；

在所述网络报文属于指定类型的DNS请求时直接执行解析处理，否则按照网络报文类型选择备用流程处理。

作为本发明上述DNS前端解析方法的进一步改进，所述指定类型的DNS请求为UDP的DNS请求包。

作为本发明上述DNS前端解析方法的进一步改进，在所述网络报文为TCP的DNS请求包时，通过队列组件传输报文给内核协议栈，以与后端服务器进行TCP解析交互。

作为本发明上述DNS前端解析方法的进一步改进，在所述网络报文为异常报文或DNS应答包时，执行丢弃处理。

作为本发明上述DNS前端解析方法的进一步改进，在所述网络报文为DNS报文以外的普通报文时，通过队列组件传输报文给内核协议栈，以使操作系统进行处理。

作为本发明上述DNS前端解析方法的进一步改进，实现数据链路层收发报文的网卡，在具有若干对收发队列时，为成对的收包队列和发包队列设置对应的前端处理线程，前端处理线程之间采用独立的包括内存池在内的资源。

作为本发明上述DNS前端解析方法的进一步改进，操作系统通过队列组件连接所述网卡，以配置所述网卡的IP地址、网关及子网掩码。

为了解决上述技术问题，本发明的一种DNS前端解析系统，包括：

轮询单元，用于通过轮询确定数据链路层接收到的网络报文；

判断单元，用于获取所述网络报文所在缓存区的控制权并判断所述网络报文的类型；

执行单元，用于在所述网络报文属于指定类型的DNS请求时直接执行解析处理，否则按照网络报文类型选择备用流程处理。

作为本发明上述DNS前端解析系统的进一步改进，在所述执行单元中，所述指定类型的DNS请求为UDP的DNS请求包。

作为本发明上述DNS前端解析系统的进一步改进，实现数据链路层收发报文的网卡，在具有若干对收发队列时，为成对的收包队列和发包队列设置对应的前端处理线程，前端处理线程之间采用独立的包括内存池在内的资源。

与现有技术相比，本发明采用轮询的方式接管网卡收发的网络报文，并对网络报文进行分类处理，直接响应其中相应的DNS请求，因为旁路了操作系统中部分关于数据收发的机制，最大化地利用了硬件的潜能。本发明可以提高网络收发包的速度，进而提升整体DNS解析的性能。

结合附图阅读本发明实施方式的详细描述后，本发明的其他特点和优点将变得更加清楚。

附图说明

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

图1为本发明一实施方式中DNS前端解析方法流程图。

图2为本发明一实施方式中数据处理的内核旁路方式示意图。

图3为本发明一实施方式中网络报文分类处理流程图。

图4为本发明一实施方式中实现DNS解析的流程图。

图5为本发明一实施方式中向内核协议栈传输报文的示意图。

图6为本发明一实施方式中从内核协议栈接收报文的示意图。

图7为本发明一实施方式中DNS前端解析系统示意图。

具体实施方式

以下将结合附图所示的各实施方式对本发明进行详细描述。但这些实施方式并不限定本发明，本领域的普通技术人员根据这些实施方式所做出的结构、方法或功能上的变化均包含在本发明的保护范围内。

需要说明的是，在不同的实施方式中，可能使用相同的标号或标记，但这些并不代表结构或功能上的绝对联系关系。并且，各实施方式中所提到的“第一”、“第二”也并不代表结构或功能上的绝对区分关系，这些仅仅是为了描述的方便。

对于DNS解析而言，它的作用就是根据域名查出对应的IP地址，它是HTTP（HyperText Transfer Protocol，超文本传输协议）等协议的前提。通常情况下，终端在需要发起DNS解析时，会向特定的DNS解析服务器发起查询，而相应的DNS解析服务器则会根据接收到的相应DNS请求来实现一定的查询过程，从而返回相应的DNS应答。因此，DNS解析服务器的报文收发及查询效率，直接决定着DNS解析的性能。

如图1所示，本发明一实施方式中DNS前端解析方法流程图。DNS前端解析方法，具体包括如下步骤：

步骤S1、通过轮询确定数据链路层接收到的网络报文。作为DNS解析服务器等计算机设备，会从网络中接收到外部发来的各种网络报文，对于DNS解析服务器而言，主要以DNS报文为主。但是计算机设备并不知道何时能收到上述网络报文，因此则需要设计一个机制去响应未知到达的网络报文。轮询是指通过周期性地询问来主动确定网络报文有没有到达，而中断则是通过一定的硬件结构配合来被动响应，这种被动响应需要打断当前工作的连续性，比如一次中断处理需要将CPU(Central Processing Unit，中央处理器)的状态寄存器保存在堆栈，并运行中断服务程序，最后再将保存的状态寄存器信息从堆栈中恢复，整个过程需要至少300个处理器时钟周期，这也就是中断相对于轮询的最大缺点。

如图2所示，负责数据链路层报文收发的一般是网卡，网卡为主要工作在数据链路层的网络器件，被设计用来允许计算机设备在计算机网络上进行通讯。在计算机设备上运行的操作系统，以Linux操作系统为例，包括用户态空间和内核态空间。传统的网络报文收发如图2中的左边流程，在内核态空间中通过网卡驱动来完成操作系统与网卡之间的数据传送，网卡通过中断方式通知内核协议栈对报文进行处理，内核协议栈先会对报文的合法性进行必要的校验，然后判断报文目标是否为本机的Socket，满足条件则会将报文拷贝一份向上递交到用户态空间的Socket来处理，进一步由上层的业务应用调用Socket接口最终获得。如上所述，中断及内核态、用户态之间的切换都给整个收发过程带来不必要的消耗，因此，在图2右边流程中，本发明采用了轮询架构作为另一种收发机制，通过绕过内核协议栈的I/O技术，截断网卡触发的中断，并重设中断回调行为。具体地，在内核态空间设置用户态IO，来支持用户态空间的轮询模式驱动，用户态IO主要屏蔽网卡发出的中断信号，同时还为用户态提供共享内存的内存映射条件，然后由轮询模式驱动采用主动轮询的方式去感知报文到达，用户态空间的DNS应用在实现DNS解析时，可以直接对网卡到达的网络报文进行处理。网卡接收到网络报文后，可以通过DMA（Direct Memory Access，直接内存存取）方式传输到预分配的内存中，在DDIO（Direct Data I/O，数据直接传输技术）技术兼容的情况下，还可以直接将报文保存到CPU的Cache中，轮询模式驱动通过不断轮询来感知上述缓存区是否收到相应报文，并可在缓存区中直接处理报文，直接处理报文的过程以下将进一步描述。整个过程完全取代现有的中断架构的处理过程，DNS应用可以在此基础上实现相应的报文处理及DNS解析等工作，因此可以大大地优化DNS解析性能。需要补充的是，在更多的实施方式中，也可以综合上述两种架构处理方式，具体可以根据网卡的数量及数据收发的需求进行合理配置，比如可以将大多数网卡绑定在轮询架构中以服务DNS应用，而其他网卡采用传统的中断架构处理服务业务应用。

步骤S2、获取所述网络报文所在缓存区的控制权并判断所述网络报文的类型。在步骤S1中，主要是确定到网络报文的到达，但是对网络报文的处理才是实现DNS解析的另一个关键。对于DNS解析服务器而言，其最主要的工作就是对DNS请求做出响应。在本发明实施方式中，可以对网卡到达的网络报文进行直接处理，其是对存储网络报文的缓存区进行接管处理，不需要额外的拷贝直接对缓存区的网络报文进行管理。相应地，先是对网络报文的类型进行分类判断，如上所述，缓存区的网络报文是通过网卡从外部的网络获取到的，主要是来自于终端的DNS查询请求等DNS报文，但是外部的网络报文除了DNS报文以外，还可能存在非DNS报文。对于DNS报文可以分为DNS请求和DNS应答，具体地可以通过DNS报文结构的QR字段来识别，进一步针对DNS报文还可以是基于TCP协议或者UDP协议等进行收发的。对于DNS报文以外的网络报文，可以包括ARP协议包、ICMP协议包在内的控制消息等。对上述网络报文的判断，可以通过网络报文内容中的相关特征进行确定。

由于DNS解析服务器完全公开地处于网络中，很有可能受到不明攻击，比如DDOS(Distributed denial of service attack，分布式拒绝服务攻击)攻击，因此在接收到的网络报文中还可能存在一定的异常报文。在优选的实施方式中，还需要识别出网络报文中的异常报文，异常报文包括不属于DNS解析服务器处理的报文或者不合理的冗余请求等。进一步，可以基于多种策略对异常报文进行确定，具体的可以有报文源地址（客户端IP地址）的过滤策略、报文目的地址（服务端IP地址）的过滤策略、请求域名的过滤策略、请求类型的过滤策略等，根据上述的不同策略可以是基于单位时间内的请求量阈值分析，亦或者黑名单管理等，采取的策略应对可以是直接丢弃相应报文，亦或者进行定向限速。上述策略的选择可以根据实际情况下的人工配置，亦或者是通过策略优先级的动态调整，具体的优先级关系也可以通过配置文件指定，配置文件中的优先级也可以根据实际情况进行修改，通过配置重载的方式重新更新优先级即可。

步骤S3、在所述网络报文属于指定类型的DNS请求时直接执行解析处理，否则按照网络报文类型选择备用流程处理。经过步骤 S2对网络报文的类型判断，进一步就可以对特定类型的网络报文采取特定的处理。如图3所示，在所述网络报文属于指定类型的DNS请求时，在本实施方式中，是在所述网络报文属于UDP的DNS请求时，即基于UDP协议传输的DNS请求包，此时可以直接执行解析处理。UDP的DNS请求是收到的网络报文中最多的类型，因此对其高效率地执行DNS解析是整个过程的关键，同时对于其他类型的网络报文也会做出不同的处理。在网络报文属于TCP的DNS的请求时，转发给后端服务器解析处理，进一步也可以选择是否对TCP的DNS请求进行正常的解析应答，比如设置不支持TCP的DNS请求，可以直接将确定为TCP的DNS请求进行丢弃。对于ARP协议包、ICMP协议包等，由于属于操作系统中的业务软件需要处理的报文，比如涉及DNS解析的配置管理等，因此需要转发给内核协议栈传递给操作系统进行处理。对于DNS应答包、异常报文等，由于它们对于DNS解析服务器来说，属于没有用处的网络报文，因此相应地可以做丢弃处理，这样可以大大增加系统的稳定性和抗攻击性。

进一步对直接执行解析处理的过程进行描述，如上所述，由于上述存储网络报文的缓存区可以通过映射直接由用户态进行处理，因此解析处理过程也不需要对相应报文进行拷贝处理，直接访问缓存区。优选地，虚拟内存按页管理的默认页大小配置是4K，为了减少虚拟内存到物理内存地址的转换时间，从而提高访问缓存区的效率，可以增加页的大小以适应DNS解析请求的大批量需求。解析处理的过程实际是一个类似查表的过程，相应地会设置一个存储DNS资源记录的DNS缓存，DNS缓存可以是预先申请的内存块，相关内容可以是预先存储进去的或者在运行过程中通过后端服务器返回的结果更新的。DNS资源记录具体地可以是A记录或AAAA记录，说明一个域名对应的IP地址，根据相应的域名可以查询到对应的IP地址，在优选的实施方式中，支持IPv4和IPv6双协议。

如图4所示，当确定属于UDP的DNS请求时，对相应的网络报文进行解码，具体地得到中间信息结构对象，然后根据相应的域名去到DNS缓存中进行查找，即匹配缓存获得目标结果。当命中相应的结果时，则编码形成返回的应答包，通过网卡发送到以太网中。如果在DNS缓存中未命中，说明DNS缓存中没有相应的资源记录，此时需要向后端服务器查询，通信方式可以采用内核态收发包的架构，直接调用Socket接口实现，进一步可以通过epoll系统调用来对Socket进行接收管理。查询方式一种可以是自身具有递归程序，直接向权威DNS服务器等后端服务器发起递归查询，另一种采用转发的方式，转发给有能力实现域名解析的后端服务器进行查询。优选地，自身具有负载均衡程序，通过对多个后端服务器的评价，基于合适的策略选择适宜的后端服务器进行转发查询，比如服务性能最优、基于流量的分配或者基于IP地址等的随机分配等策略。在更多的实施方式中，负载均衡程序是运行在第一跳转发的后端服务器中实施的，即在未命中DNS缓存时，只将相应的DNS请求转发给设定的后端服务器，其他完全由后端服务器进行处理。当后端服务器获得相关的DNS应答时返回给本机，由本机重组应答包同样通过网卡发送到以太网中的对应终端，具体是调用Socket接口将相应报文传递给内核协议栈，通过如下所述的网卡虚拟模块与轮询架构绑定的网卡实现对外发送。进一步，对于后端服务器返回的DNS应答也会同步更新在DNS缓存中，因此DNS缓存会不断地完善资源记录，保证大多数的DNS请求可以直接命中并快速地返回给相应的请求终端。

需要补充的是，对于存储DNS资源记录的DNS缓存，为了提高查询的效率，可以采用自定义hash表的数据结构，进一步可以结合LRU(Least Recently Used，最近最少使用)架构，以提高最常被访问到节点的响应速度。具体地，对相应的DNS资源记录提取相应的特征关键词进行hash运算，根据计算确定的hash值来分配到不同的hash桶中，对于由于hash值相同而分配到同一hash桶中的多个DNS资源记录，可以采用链表的方式进行串联，当确定hash值后在对应hash桶中查询特定DNS资源记录时，可以从对应hash桶首地址对应的节点开始查找，沿着链表顺序顺次查找。进一步为了提高hash桶中线性查找速度，对于最近一次查找的DNS资源记录，自动更新到链表的首地址位置，这样可以保证经常查找的DNS资源记录始终处于链表的前部位置。

如上所述，在所述网络报文为TCP DNS请求包时，需要与后端服务器进行TCP解析交互，此时轮询架构需要通过内核协议栈与后端服务器建立TCP连接，发送相应的DNS请求及接收相应的DNS应答。同样，在所述网络报文为ARP协议包、ICMP协议包等DNS报文以外的普通报文时，这里的普通报文特指的是DNS报文以外与异常报文相对的报文，也需要通过内核协议栈将相应的报文内容传递给操作系统。对于上述情况，由于对数据链路层网络报文的直接收发，已经通过用户态IO对内核协议栈进行了旁路，此时则需要通过在内核协议栈与本实施方式中的轮询架构之间建立一个虚拟网卡模块以实现通信，具体地，通过队列组件重新与内核协议栈建立关系，从而可以适应如上所述类型网络报文的处理。如图5、图6所示，为了和内核协议栈进行通信，可以在内核协议栈侧模拟一个与内核协议栈对接的虚拟网口，扮演网卡的角色，另一侧则是对接轮询架构的收发接口，而在收发接口与虚拟网口之间设置队列组件来实现报文的传递。

如图5所示，当需要向内核协议栈传递报文时，比如操作系统需要收到ARP协议包、ICMP协议包，报文原来存放在存储器缓存区mbuf中，为了传递给内核协议栈的套接字缓存区sk_buf中，通过第一队列将指定报文的mbuf指针，即报文对应存储器缓存区mbuf的地址，发送至虚拟网口，这样内核协议栈侧就可以根据第一队列提供的指针把存储器缓存区mbuf中的报文存入套接字缓存区sk_buf中，内核协议栈就可以利用内核态空间的套接字缓存区sk_buf进行处理，同时，虚拟网口还需要通过第二队列向收发接口发送未承载报文的mbuf指针，即通知轮询架构可回收的存储器缓存区mbuf的区域。进一步，操作系统可以正常地与轮询架构及相应的网卡进行通信、操作，从而可以支持配置本地授权信息，并且支持多视图配置，具体地还可以查看运行状态、日志管理等

如图6所示，当内核协议栈需要向轮询架构发送报文信息或者通过轮询架构绑定的网卡转发报文时，先在套接字缓存区sk_buf中存有待发送的报文，首先从第三队列中获得未承载报文的mbuf指针，即可以在存储器缓存区mbuf中存入报文的空闲区域地址，将套接字缓存区sk_buf中待发送的报文存入存储器缓存区mbuf中的对应地址，然后将指定报文的mbuf指针通过第四队列发送给收发接口，从而可以通过存储器缓存区mbuf获取发送的报文，以实现相应的转发。进一步，根据以上的队列组件的通信机制，当操作系统反馈信息或者后端服务器返回的应答报文需要向原网卡路径返回特定的报文，此时就可以递交给内核协议栈，由内核协议栈通过队列组件与轮询架构绑定的网卡进行通信，将指定的报文发送到外部网络。在更多的实施方式中，操作系统还可以通过队列组件连接所述网卡，以配置网卡的IP地址、网卡、子网掩码等配置信息。

在更多的实施方式中，为了适应网卡的多收发队列及CPU的多核处理的高效利用，为成对的收包队列和发包队列设置对应的前端处理线程，前端处理线程之间采用独立的包括内存池在内的资源。具体地，可以为每个网卡的收包队列和发包队列分别进行编号，收包队列或发包队列的数量和设置的前端处理线程数量一致，且同一编号的收包队列和发包队列由同一个前端处理线程负责处理，包括报文收发、DNS解析等。对于多网卡多收发包队列的情况，对应前端处理线程负责每个网卡相同编号的收包队列及发包队列，每个前端处理线程会轮询每个网卡和自己线程对应的收包队列。进一步，每个前端处理线程都拥有独立的一个DNS缓存，独立地实现DNS解析的匹配缓存。通过上述的设置，前端处理线程和前端处理线程之间实施的资源相对独立，因此极大地减少了锁竞争带来的资源消耗。更优选地，结合多核CPU的亲和机制，将不同的特定线程（例如不同的前端处理线程）绑定在特定的CPU核上运行，而不被迁移到其他核上运行，减少相互之间切换带来的不必要处理开销。

如图7所示，本发明一实施方式中DNS前端解析系统示意图。DNS前端解析系统具体包括轮询单元U1、判断单元U2及执行单元U3。

轮询单元U1，用于通过轮询确定数据链路层接收到的网络报文。参照DNS前端解析方法的实施方式，轮询的方式是不同于传统的中断响应机制的架构，轮询架构通过在内核态空间设置一个与用户态空间对接的IO直接与用户态进行交互，用户态IO可以对绑定的网卡进行中断截取，而用户态空间设置对应的轮询模式驱动，通过轮询主动地去确定网卡到达的新报文，从而对新报文进行直接处理。

判断单元U2，用于获取所述网络报文所在缓存区的控制权并判断所述网络报文的类型。在数据链路层通过网卡到达的网络报文是存放在指定的缓存区内，缓存区可以由用户态空间接管而对其管理的，具体地，对缓存区内的网络报文进行类型判定。如上所述，网络报文主要以DNS报文为主，具体如图3所示，收到的网络报文大致分为DNS请求报文、非DNS请求报文及异常报文，不同的报文类型都设置了对应的处理流程。其中DNS请求报文可以进一步确定为TCP DNS请求包和UDP DNS请求包，其中UDP DNS请求包是发起DNS解析的主要方式。非DNS请求报文具体可以包括DNS应答包、ARP 协议包、ICMP协议包等，这些报文通常不是对应终端发起DNS解析的报文。另外还有一种网络报文类型就是异常报文，通常是因为受到攻击或者其他异常情况下收到的没有意义的报文，相应地可以直接做丢弃处理。

执行单元U3，用于在所述网络报文属于指定类型的DNS请求时直接执行解析处理，否则按照网络报文类型选择备用流程处理。判断单元U2采用零拷贝的方式对接收到的网络报文进行处理，确定了对应的网络报文的类型，进一步就是对网络报文的处理。如上所述UDP的DNS请求包是DNS解析的主要报文类型，因此在所述网络报文属于UDP的DNS请求包，直接执行解析处理，通过上述的轮询架构可以非常高效地实施DNS解析，具体的DNS解析是与设置的DNS缓存进行匹配，DNS缓存中的资源记录采用hash桶的数据结构支持快速查询，进一步可以参照DNS前端解析方法的具体实施方式。而对于其他类型的网络报文，也需要采取一定的备用流程进行处理，具体在在所述网络报文为TCP的DNS请求包时，通过队列组件传输报文给内核协议栈，通过内核协议栈与后端服务器进行TCP解析交互。在所述网络报文为DNS报文以外的普通报文时，通过队列组件传输报文给内核协议栈，以使操作系统进行处理。在所述网络报文为异常报文或DNS应答包时，如上所述执行丢弃处理。

需要说明的是，本实施方式主要采用轮询架构对UDP的DNS请求包为主的DNS请求进行快速响应，提高整个DNS解析的性能。但是介于轮询架构的局限性，对于部分网络报文并不能完全依靠自身的架构资源进行处理，如上所述，相应地会需要与既有的操作系统及接口、外部的后端服务器进行协同工作，因此轮询架构就需要与内核协议栈之间进行通信。在本发明实施方式中，在轮询架构和内核协议栈之间采取的是构建一个虚拟网卡模块作为数据通道，具体是通过队列组件来传输报文，这样就可以满足将相应的报文注入到内核协议栈的需求，从而实现向操作系统上层应用或后端服务器传递报文的目标，反之还可以将内核协议栈处理的报文传递给轮询架构绑定的网卡上发送出去。

在更多的实施方式中，实现数据链路层收发报文的网卡，在具有若干对收发队列时，为成对的收包队列和发包队列设置对应的前端处理线程，前端处理线程之间采用独立的包括内存池在内的资源。进一步，操作系统通过队列组件连接所述网卡，以配置所述网卡的IP地址、网关及子网掩码。需要说明的是，DNS前端解析系统的具体实施方式还可以参照DNS前端解析方法的具体实施方式。

结合本申请所公开的技术方案，可以直接体现为硬件、由控制单元执行的软件模块或二者组合，即一个或多个步骤和/或一个或多个步骤组合，既可以对应于计算机程序流程的各个软件模块，亦可以对应于各个硬件模块。为了描述的方便，描述上述装置时以功能分为各种模块分别描述，当然，在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。

通过以上实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请也可以借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分也可以以软件产品的形式体现出来。该软件可以由微控制单元执行，依赖于所需要的配置，支持上述架构所需要的机制，也可以包括任何类型的一个或多个微控制单元。该软件存储在存储器，例如，易失性存储器（例如随机读取存储器等）、非易失性存储器（例如只读存储器、闪存等）或其任意组合。

综上所述，本发明采用轮询的方式接管网卡收发的网络报文，并对网络报文进行分类处理，直接响应其中相应的DNS请求，因为旁路了操作系统中部分关于数据收发的机制，最大化地利用了硬件的潜能。本发明可以提高网络收发包的速度，进而提升整体DNS解析的性能。

应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为了清楚起见，本领域技术人员应当将说明书作为一个整体，各实施方式中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

Claims (10)

1.一种DNS前端解析方法，其特征在于，包括如下步骤：

通过轮询确定数据链路层接收到的网络报文；

获取所述网络报文所在缓存区的控制权并判断所述网络报文的类型；

在所述网络报文属于指定类型的DNS请求时直接执行解析处理，否则按照网络报文类型选择备用流程处理。

2.根据权利要求1所述的DNS前端解析方法，其特征在于，所述指定类型的DNS请求为UDP的DNS请求包。

3.根据权利要求1所述的DNS前端解析方法，其特征在于，在所述网络报文为TCP的DNS请求包时，通过队列组件传输报文给内核协议栈，以与后端服务器进行TCP解析交互。

4.根据权利要求1所述的DNS前端解析方法，其特征在于，在所述网络报文为异常报文或DNS应答包时，执行丢弃处理。

5.根据权利要求1所述的DNS前端解析方法，其特征在于，在所述网络报文为DNS报文以外的普通报文时，通过队列组件传输报文给内核协议栈，以使操作系统进行处理。

6.根据权利要求1所述的DNS前端解析方法，其特征在于，实现数据链路层收发报文的网卡，在具有若干对收发队列时，为成对的收包队列和发包队列设置对应的前端处理线程，前端处理线程之间采用独立的包括内存池在内的资源。

7.根据权利要求6所述的DNS前端解析方法，其特征在于，操作系统通过队列组件连接所述网卡，以配置所述网卡的IP地址、网关及子网掩码。

8.一种DNS前端解析系统，其特征在于，包括：

轮询单元，用于通过轮询确定数据链路层接收到的网络报文；

判断单元，用于获取所述网络报文所在缓存区的控制权并判断所述网络报文的类型；

执行单元，用于在所述网络报文属于指定类型的DNS请求时直接执行解析处理，否则按照网络报文类型选择备用流程处理。

9.根据权利要求8所述的DNS前端解析系统，其特征在于，在所述执行单元中，所述指定类型的DNS请求为UDP的DNS请求包。

10.根据权利要求8所述的DNS前端解析系统，其特征在于，实现数据链路层收发报文的网卡，在具有若干对收发队列时，为成对的收包队列和发包队列设置对应的前端处理线程，前端处理线程之间采用独立的包括内存池在内的资源。

Images