CN113709271A - 一种域名解析的方法及装置 - Google Patents

Abstract

本公开实施例提供一种域名解析的方法及装置，其中，所述方法包括：响应于接收到客户端发送的基于用户数据报协议UDP协议的域名系统DNS请求报文，向客户端反馈应答报文；接收客户端基于应答报文发送的传输控制协议TCP协议的DNS请求报文；将TCP协议的DNS请求报文转换为UDP协议的DNS请求报文，将转换后的UDP协议的DNS请求报文发送给DNS服务器；在接收到所述DNS服务器返回的UDP协议的回应报文后，将UDP协议的回应报文转换为TCP协议的回应报文，返回至客户端。通过本公开实施例的技术方案，可以解决相关技术中DNS服务器无法对TCP协议的DNS请求报文进行解析，而导致的用户访问网络异常的问题。

Description

一种域名解析的方法及装置

技术领域

本公开技术方案涉及网络技术领域，尤其涉及一种域名解析的方法及装置。

背景技术

DNS(Domain Name System,域名系统)是一种将域名和IP地址相互映射的分布式数据库，它使得用户不需要记住繁琐的IP数串，就可以便捷地访问互联网。

在实际应用中，DNS服务器不仅会接收到来自客户端的域名查询请求，还会接收到一些攻击者的域名查询请求来破坏DNS服务器的正常工作，我们将其称之为DNS QueryFlood(域名查询洪水攻击)。攻击者通常采用的攻击方式是向被攻击的DNS服务器发送大量的域名解析请求，这些请求解析的域名是随机生成的或者是网络上根本不存在的域名，被攻击的DNS服务器在接收到域名解析请求的时候首先会在DNS服务器上查找是否有对应的缓存，如果查找不到并且该域名无法直接由DNS服务器解析的时候，DNS服务器会向其上层DNS服务器递归查询域名信息。域名解析的过程会给DNS服务器带来很大的负载，每秒钟域名解析的请求超过一定的数量就会造成DNS服务器解析域名超时，从而使得DNS服务器不能解析正常的域名请求。

为了防护DNS Query Flood攻击，现有的技术方案通常采用TCP校验防护，TCP校验防护是基于正常交互行为来判断攻击的防护。当保护设备接收到客户端发送的UDP协议的DNS请求报文后会回应给客户端一个带有TC(Transmission Complete，发送完成)标志位的应答报文将此报文反弹回去，客户端接收到此报文后会重新发送TCP协议的DNS请求报文，保护设备对于TCP协议的DNS请求报文会直接将其转发给DNS服务器，而攻击者收到带有TC标识位的应答报文后，不会重新发送TCP协议的DNS请求报文，所以通过这种TCP校验防护方法可以达到防御DNS Query Flood攻击的目的。但是由于现阶段很多的DNS服务器在进行配置的时候，仅支持UDP协议的查询包，所以会出现用户发送基于TCP协议的DNS请求报文时解析失败，用户访问网络异常的问题。

发明内容

有鉴于此，本公开实施例提供一种域名解析的方法及装置。

具体地，本公开实施例是通过如下技术方案实现的：

根据本申请的第一方面，提出了一种域名解析的方法，所述方法包括：

响应于接收到客户端发送的基于用户数据报协议UDP协议的域名系统DNS请求报文，向所述客户端反馈应答报文；

接收所述客户端基于所述应答报文发送的传输控制协议TCP协议的DNS请求报文；

将所述TCP协议的DNS请求报文转换为UDP协议的DNS请求报文，并将转换后的UDP协议的DNS请求报文发送给DNS服务器；

在接收到所述DNS服务器返回的UDP协议的回应报文后，将所述UDP协议的回应报文转换为TCP协议的回应报文，返回至所述客户端。

根据本公开的第二方面，提出了一种域名解析的装置，所述装置包括：

反馈模块，用于响应于接收到客户端发送的基于用户数据报协议UDP协议的域名系统DNS请求报文，向所述客户端反馈应答报文；

接收模块，用于接收所述客户端基于所述应答报文发送的传输控制协议TCP协议的DNS请求报文；

第一转换模块，用于将所述TCP协议的DNS请求报文转换为UDP协议的DNS请求报文，并将转换后的UDP协议的DNS请求报文发送给DNS服务器；

第二转换模块，用于在接收到所述DNS服务器返回的UDP协议的回应报文后，将所述UDP协议的回应报文转换为TCP协议的回应报文，返回至所述客户端。

根据本公开的第三方面，提供一种计算机可读存储介质，所述机器可读存储介质存储有机器可读指令，所述机器可读指令在被处理器调用和执行时，促使所述处理器实现本公开任一实施例的域名解析的方法。

根据本公开的第四方面，提供一种保护设备，包括通信接口、处理器、存储器和总线，所述通信接口、所述处理器和所述存储器之间通过总线相互连接；所述存储器中存储机器可读指令，所述处理器通过调用所述机器可读指令，执行本公开任一实施例的域名解析的方法。

本公开实施例提供的域名解析的方法及装置，针对实际的应用需求，利用保护设备实现TCP协议的DNS请求报文与UDP协议的DNS请求报文之间的转换,可以有效解决当保护设备开启TCP协议的DNS服务，而DNS服务器没有开启TCP协议的DNS服务时，用户使用TCP协议进行DNS解析失败的问题。

下面通过附图和实施方式，对本公开的技术方案做进一步的详细描述。

附图说明

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

图1是根据本公开一示例性实施例提供的一种系统架构图；

图2是根据本公开一示例性实施例提供的一种域名解析方法的流程图；

图3是根据本公开一示例性实施例提供的一种域名解析方法的三方交互图；

图4是根据本公开一示例性实施例提供的一种域名解析框图；

图5是根据本公开一示例性实施例提供的另一种域名解析框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。

在本申请使用的术语仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

本公开实施例提供一种域名解析的方法，解决相关技术在防护DNS Query Flood攻击中，当DNS服务器不支持基于TCP协议的DNS服务时，用户发送基于TCP协议的DNS请求报文解析失败的问题。

下面结合附图，对本公开实施例的域名解析的方法进行详细阐述。

图1为本公开一示例性实施例提供的一种域名解析系统的架构图，如图1所示，该系统可以包括客户端11、攻击者12、保护设备13以及服务器14。

在一个可选示例中，客户端11与保护设备13之间、攻击者12与保护设备13之间、保护设备与服务器之间可以通过网络实现信息的通信。本公开实施例并不限制该网络的具体形式。例如，所述网络可以是局域网、广域网、内部网、互联网、移动电话网络、虚拟专用网、蜂窝式或者其他移动通信网络、蓝牙、NFC或者其任何组合。

图2是本公开一示例性实施例提供的一种域名解析方法的流程图。如下结合图1的系统架构图，描述该方法的处理。例如，该方法可以由保护设备执行。如图2所示，该实施例方法可以包括如下处理：

步骤S201，响应于接收到客户端发送的基于用户数据报协议UDP协议的域名系统DNS请求报文，向所述客户端反馈应答报文。

如图1所示例的系统，其中，系统中的客户端11表示正常的客户端，攻击者12表示要对服务器14发送攻击的一方。保护设备13设置于客户端11与服务器14之间，所以客户端11与服务器14之间交互的报文经过该保护设备13。同样，攻击者12如果要向服务器14发送攻击，攻击报文也会经过该保护设备13，保护设备13可以对服务器进行保护，以保护服务器14避免受到攻击者12的攻击。

具体实施中，保护设备13在接收到DNS请求报文时，并不知道该报文是来自正常的客户端11还是来自攻击者12，而是可以通过对DNS请求报文进行风险检测，来确定该报文的来源，从而能够在确定报文来自攻击者12时，及时的进行风险阻断，避免服务器14遭到攻击。需要说明的是，在下文的描述中，若保护设备13还未确定DNS请求报文的来源时，本公开实施例的描述中暂且都将其称为“客户端”。

本实施例并不限制保护设备13进行上述风险检测的方式，保护设备13可以通过多种方式来检测DNS请求报文是否存在攻击风险。在一个可选示例中，保护设备13可以通过检测其接收到的同一客户端发送的DNS请求报文的数量，来判断该客户端是否是具有攻击风险的客户端。

例如，保护设备可以在检测到接收到的所述客户端发送的基于UDP协议的DNS请求报文的数量达到预设的告警数量阈值的情况下，向所述客户端反馈应答报文。

具体的，可以根据保护设备的性能好坏，为其设定一个告警数量阈值(例如，可以将告警数量阈值设定为80、100等)。该告警数量阈值用于表示保护设备在接收到同一客户端发送的DNS请求报文的数量达到该告警数量阈值时，该客户端可能是存在攻击风险的攻击端，保护设备可以据此进行进一步的风险检测。此外，可以为该告警数量阈值设置一个时间段，即在某个时间段内接收到该告警数量阈值的DNS请求报文，则认为存在攻击风险。

例如，保护设备每接收到一个DNS请求报文，就可以记录下该DNS请求报文的客户端源IP地址，并且还可以记录接收到来自该同一源IP地址的DNS请求报文的数量。以上述告警数量阈值设置为80为例，当保护设备记录的上述同一源IP地址的DNS请求报文的数量等于或大于80时，保护设备可以将所有的UDP协议的DNS请求报文拦截并丢弃，并向客户端反馈带有TC标志位的应答报文，该带TC标志位的应答报文可以触发客户端重新发送TCP协议的DNS请求报文。

步骤S202，接收所述客户端基于所述应答报文发送的传输控制协议TCP协议的DNS请求报文。

在一个可选示例中，客户端在接收到带有TC标志位的应答报文后，会再次发送TCP协议的DNS请求报文，但是当攻击者接收到带有TC标志位的应答报文以后，由于其主要的功能是向DNS服务器发送大量的攻击，所以正常情况下其性能无法支撑它再次发送TCP协议的DNS请求报文。因此，保护设备可以根据当接收到带有TC标志位的应答报文以后是否发送TCP协议的DNS请求报文来区分客户端和攻击者。

步骤S203，将所述TCP协议的DNS请求报文转换为UDP协议的DNS请求报文，并将转换后的UDP协议的DNS请求报文发送给DNS服务器。

本步骤中，保护设备在接收到客户端发送的基于TCP协议的DNS请求报文后，可以对该报文进行转换，将其转换为基于UDP协议的DNS请求报文后，再发给DNS服务器。

在一个可选示例中，保护设备在进行上述的报文格式转换时，可以将转换后的UDP协议的DNS请求报文的源IP地址设置为保护设备的出接口地址，并将UDP协议的DNS请求报文的目的IP地址设置为DNS服务器的IP地址。

步骤S204，在接收到所述DNS服务器返回的UDP协议的回应报文后，将所述UDP协议的回应报文转换为TCP协议的回应报文，返回至所述客户端。

本实施例中，DNS服务器在接收到保护设备发送的基于UDP协议的DNS请求报文，可以向保护设备反馈UDP协议的回应报文。保护设备在向客户端返回该UDP协议的回应报文之前，可以将该UDP协议的回应报文转换为TCP协议的回应报文。

例如，保护设备可以将DNS服务器发送的UDP协议的DNS回应报文转换为TCP协议的回应报文，并将转换得到的TCP协议的回应报文的目的IP地址设置为客户端的IP地址。

本实施例的域名解析的方法，通过利用保护设备实现TCP协议的DNS请求报文与UDP协议的DNS请求报文之间的转换,可以有效解决当保护设备开启TCP协议的DNS服务，而DNS服务器没有开启TCP协议的DNS服务时，用户使用TCP协议进行DNS解析失败的问题。

为了更好的理解本公开实施例，下面对域名解析的过程作进一步的描述。

图3是本公开一示例性实施例提供的一种域名解析方法的三方交互图。如下结合图一的系统架构图，描述该域名解析系统中各个设备之间的交互关系。

如图3所示，该实施例方法可以包括如下处理：

步骤S301，客户端发送UDP协议的DNS请求报文。

步骤S302，保护设备检测接收到的客户端发送的基于UDP协议的DNS请求报文的数量超过预设的告警数量阈值。

在一个可选示例中，保护设备可以通过检测在一定时间内，保护设备接收到的同一客户端发送的DNS请求报文的数量是否超过预设的告警阈值，来判断该客户端是否是具有攻击风险的客户端，从而采取相应的措施来达到保护服务器的目的。

在又一个可选示例中，保护设备与服务器之间的对应关系可以是一对一，也可以是一对多，具体应根据保护设备的性能状况来决定，本公开实施例对此不做限定。

步骤S303，保护设备向客户端发送带有TC标志位的应答报文。

在一个可选示例中，如果客户端发送的是TCP协议的DNS请求报文，不论此时请求报文的数量是否超过保护设备的告警数量阈值，保护设备都直接将该TCP协议的请求报文转发至DNS服务器。

在又一个可选示例中，如果客户端事先知道DNS回应报文的长度会大于512字节，则会直接发送TCP协议的DNS请求报文；如果客户端事先不知道DNS回应报文的长度，一般会先发送UDP协议的DNS请求报文，如果DNS服务器发现DNS回应报文的长度大于512字节，并且多出来的部分被UDP协议的回应报文抛弃，DNS服务器就会把被抛弃的DNS回应报文首部中的TC标志位置为1，以通知客户端该DNS报文已经被截断。客户端收到DNS回应报文之后会重新发起一次TCP协议的DNS请求报文，从而使得它将来能够从DNS服务器接收到完整的响应报文。因此，如果DNS服务器接收到的是TCP协议的DNS请求报文，那么它应是DNS服务器要求客户端发送的，所以，保护设备不对其进行处理，直接将TCP协议的请求报文转发至DNS服务器。

步骤S304，客户端与保护设备通过三次握手建立连接。

在一个可选示例中，客户端首先发送TCP SYN(synchronous，建立联机)报文，目标IP是DNS服务器IP地址，目的端口号是53。

保护设备接收到客户端发送的TCP SYN报文，目的端口是53，目的IP地址在保护对象中，保护设备直接给客户端回应TCP SYN+ACK(acknowledgement，确认)报文，报文的源IP地址是客户端请求DNS服务器的地址，目的IP地址是客户端地址；

客户端收到DNS服务器IP地址回应的TCP SYN+ACK报文，向DNS服务器IP地址回应TCP ACK报文，完成三次握手。以此来防止已失效的连接请求报文段突然又传送到服务器，从而产生错误。

在又一个可选示例中，如果报文的目的端口号不是53，由于DNS服务器只占据53号端口，所以此时保护设备不对其做任何处理，直接放通报文。

步骤S305，客户端向保护设备发送基于TCP协议的DNS请求报文。

步骤S306，保护设备将TCP协议的DNS请求报文转换为UDP协议的DNS请求报文并将转换后的UDP协议的DNS请求报文发送给DNS服务器。

在一个可选示例中，保护设备将TCP协议的DNS请求报文转换为UDP协议的DNS请求报文，同时可以将转换后的UDP协议的DNS请求报文的源IP地址设置为保护设备的出接口地址，并将UDP协议的DNS请求报文的目的IP地址设置为DNS服务器的IP地址。

步骤S307，DNS服务器经过域名查找后将查找结果以UDP协议的回应报文的形式发送至保护设备。

在一个可选示例中，DNS服务器接收到由保护设备转发的UDP协议的DNS请求报文后，可以在其本地的DNS缓存对接收到的DNS请求报文中的域名信息进行查询，并基于从缓存中查询到的解析信息向保护设备发送回应报文。如果在DNS缓存中未查询到域名解析请求对应的解析信息，DNS服务器向其上层DNS服务器递归查询域名信息直至获取到域名信息对应的解析信息，并基于查询到的解析信息向保护设备发送回应报文。

步骤S308，保护设备将UDP协议的回应报文转换为TCP协议的回应报文并将TCP协议的回应报文转发至客户端。

在一个可选示例中，保护设备将DNS服务器发送的UDP协议的DNS回应报文转换为TCP协议的DNS回应报文，并将转换得到的TCP协议的DNS回应报文的目的IP地址设置为客户端的IP地址。

在又一个可选示例中，在将TCP协议的回应报文转发至客户端时，需要重新计算TCP的序列号、确认号、校验和。

步骤S309，客户端发起TCP FIN(finish，结束)请求。

步骤S310，保护设备将客户端的IP地址加入白名单。

步骤S311，客户端发送下一个UDP协议的DNS请求报文。

步骤S312，保护设备将接收到的UDP协议的DNS请求报文的IP地址与白名单中的IP地址进行比对。

在一个可选示例中，当保护设备接收到下一个报文时，将该报文的IP地址与白名单中的IP地址进行比对，如果该报文的IP地址在白名单内，保护设备不再对其进行处理，DNS服务器可以直接响应该客户端发送的DNS请求。

在一个可选示例中，如果保护设备经过比对以后发现接收到的报文的IP地址不在白名单内，保护设备便向该报文的源IP地址发送带有TC标志位的回应报文，要求其重新发送基于TCP协议的DNS请求报文，后续对该报文的处理过程同S306至S310,在此不再赘述。

在一个可选示例中，还可以为白名单设置老化机制，记录IP地址加入白名单的时间，经过预设时长后，老化白名单中对应的IP地址。经老化处理后的客户端IP地址再次发送UDP协议的DNS请求时，需要经上述步骤再次检测。

通过上述实施例，保护设备将通过检测的客户端的IP地址加入白名单，在后续保护设备接收到该客户端发送的UDP协议的DNS请求报文并且在预设时间内时，保护设备不对其进行处理，直接由DNS服务器响应，从而加快报文的处理速度。

与前述域名解析的方法的实施例相对应，本申请还提供了域名解析装置的的实施例。图4是根据本公开一示例性实施例中的一种域名解析装置的结构示意图，如图4所示，该域名解析装置可以包括：

反馈模块41，用于响应于接收到客户端发送的基于用户数据报协议UDP协议的域名系统DNS请求报文，向所述客户端反馈应答报文。

接收模块42，用于接收所述客户端基于所述应答报文发送的传输控制协议TCP协议的DNS请求报文。

第一转换模块43，用于将所述TCP协议的DNS请求报文转换为UDP协议的DNS请求报文，并将转换后的UDP协议的DNS请求报文发送给DNS服务器。

第二转换模块44，用于在接收到所述DNS服务器返回的UDP协议的回应报文后，将所述UDP协议的回应报文转换为TCP协议的回应报文，返回至所述客户端。

图5是根据本公开另一示例性实施例中的一种域名解析装置的结构示意图，如图5所示，该域名解析装置包括：反馈模块51，接收模块52，第一转换模块53，第二转换模块54，上述各个模块的作用详见图四所示域名解析过程的详细介绍。

可选的，所述反馈模块，在用于响应于接收到客户端发送的基于用户数据报协议UDP协议的域名系统DNS请求报文，向所述客户端反馈应答报文时，包括：

响应于检测到接收到的所述客户端发送的基于UDP协议的DNS请求报文的数量达到预设的告警数量阈值，向所述客户端反馈应答报文。

可选的，所述第一转换模块，在用于将所述TCP协议的DNS请求报文转换为UDP协议的DNS请求报文，并将转换后的UDP协议的DNS请求报文发送给DNS服务器时，包括：

将所述TCP协议的DNS请求报文转换为UDP协议的DNS请求报文，并将所述UDP协议的DNS请求报文的源IP地址设置为所述保护设备的出接口地址，设置所述UDP协议的DNS请求报文的目的IP地址为所述DNS服务器的IP地址；

所述第二转换模块，在用于将所述UDP协议的回应报文转换为TCP协议的回应报文时，包括：

将所述UDP协议的回应报文转换为TCP协议的回应报文，并将转换得到的所述TCP协议的回应报文的目的IP地址设置为所述客户端的IP地址。

可选的，还包括：

添加模块55，用于将所述客户端的IP地址添加到白名单。

可选的，还包括：

比对模块56，用于在所述添加模块将所述客户端的IP地址添加到白名单之后，响应于接收到所述客户端发送的所述UDP协议的另一DNS请求报文，将所述另一DNS请求报文中的源IP地址与所述白名单中的IP地址进行比对；响应于所述白名单中包括所述另一DNS请求报文中的源IP地址，将所述另一DNS请求报文发送至所述DNS服务器。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本公开技术方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

虽然本说明书包含许多具体实施细节，但是这些不应被解释为限制任何发明的范围或所要求保护的范围，而是主要用于描述特定发明的具体实施例的特征。本说明书内在多个实施例中描述的某些特征也可以在单个实施例中被组合实施。另一方面，在单个实施例中描述的各种特征也可以在多个实施例中分开实施或以任何合适的子组合来实施。此外，虽然特征可以如上所述在某些组合中起作用并且甚至最初如此要求保护，但是来自所要求保护的组合中的一个或多个特征在一些情况下可以从该组合中去除，并且所要求保护的组合可以指向子组合或子组合的变型。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种域名解析的方法，其特征在于，所述方法包括：

响应于接收到客户端发送的基于用户数据报协议UDP协议的域名系统DNS请求报文，向所述客户端反馈应答报文；

接收所述客户端基于所述应答报文发送的传输控制协议TCP协议的DNS请求报文；

将所述TCP协议的DNS请求报文转换为UDP协议的DNS请求报文，并将转换后的UDP协议的DNS请求报文发送给DNS服务器；

在接收到所述DNS服务器返回的UDP协议的回应报文后，将所述UDP协议的回应报文转换为TCP协议的回应报文，返回至所述客户端。

2.根据权利要求1所述的方法，其特征在于，所述响应于接收到客户端发送的基于用户数据报协议UDP协议的域名系统DNS请求报文，向所述客户端反馈应答报文，包括：

响应于检测到接收到的所述客户端发送的基于UDP协议的DNS请求报文的数量达到预设的告警数量阈值，向所述客户端反馈应答报文。

3.根据权利要求1所述的方法，其特征在于，所述方法由保护设备执行；

所述将所述TCP协议的DNS请求报文转换为UDP协议的DNS请求报文，并将转换后的UDP协议的请求报文发送给DNS服务器，包括：

将所述TCP协议的DNS请求报文转换为UDP协议的DNS请求报文，并将所述UDP协议的DNS请求报文的源IP地址设置为所述保护设备的出接口地址，设置所述UDP协议的DNS请求报文的目的IP地址为所述DNS服务器的IP地址；

所述将所述UDP协议的回应报文转换为TCP协议的回应报文，包括：

将所述UDP协议的回应报文转换为TCP协议的回应报文，并将转换得到的所述TCP协议的回应报文的目的IP地址设置为所述客户端的IP地址。

4.根据权利要求1所述的方法，其特征在于，

所述方法还包括：将所述客户端的IP地址添加到白名单；

所述将所述客户端的IP地址添加到白名单之后，所述方法还包括：

响应于接收到所述客户端发送的所述UDP协议的另一DNS请求报文，将所述另一DNS请求报文中的源IP地址与所述白名单中的IP地址进行比对；

响应于所述白名单中包括所述另一DNS请求报文中的源IP地址，将所述另一DNS请求报文发送至所述DNS服务器。

5.一种域名解析的装置，其特征在于，所述装置包括：

反馈模块，用于响应于接收到客户端发送的基于用户数据报协议UDP协议的域名系统DNS请求报文，向所述客户端反馈应答报文；

接收模块，用于接收所述客户端基于所述应答报文发送的传输控制协议TCP协议的DNS请求报文；

第一转换模块，用于将所述TCP协议的DNS请求报文转换为UDP协议的DNS请求报文，并将转换后的UDP协议的DNS请求报文发送给DNS服务器；

第二转换模块，用于在接收到所述DNS服务器返回的UDP协议的回应报文后，将所述UDP协议的回应报文转换为TCP协议的回应报文，返回至所述客户端。

6.根据权利要求5所述的装置，其特征在于，

所述反馈模块，在用于响应于接收到客户端发送的基于用户数据报协议UDP协议的域名系统DNS请求报文，向所述客户端反馈应答报文时，包括：

响应于检测到接收到的所述客户端发送的基于UDP协议的DNS请求报文的数量达到预设的告警数量阈值，向所述客户端反馈应答报文。

7.根据权利要求5所述的装置，其特征在于，所述第一转换模块，在用于将所述TCP协议的DNS请求报文转换为UDP协议的DNS请求报文，并将转换后的UDP协议的DNS请求报文发送给DNS服务器时，包括：

将所述TCP协议的DNS请求报文转换为UDP协议的DNS请求报文，并将所述UDP协议的DNS请求报文的源IP地址设置为所述保护设备的出接口地址，设置所述UDP协议的DNS请求报文的目的IP地址为所述DNS服务器的IP地址；

所述第二转换模块，在用于将所述UDP协议的回应报文转换为TCP协议的回应报文时，包括：

将所述UDP协议的回应报文转换为TCP协议的回应报文，并将转换得到的所述TCP协议的回应报文的目的IP地址设置为所述客户端的IP地址。

8.根据权利要求5所述的装置，其特征在于，所述装置还包括：

添加模块，用于将所述客户端的IP地址添加到白名单；

比对模块，用于在所述添加模块将所述客户端的IP地址添加到白名单之后，响应于接收到所述客户端发送的所述UDP协议的另一DNS请求报文，将所述另一DNS请求报文中的源IP地址与所述白名单中的IP地址进行比对；响应于所述白名单中包括所述另一DNS请求报文中的源IP地址，将所述另一DNS请求报文发送至所述DNS服务器。

9.一种计算机可读存储介质，其特征在于，所述机器可读存储介质存储有机器可读指令，所述机器可读指令在被处理器调用和执行时，促使所述处理器实现权利要求1至4任一项所述的方法。

10.一种保护设备，其特征在于，包括通信接口、处理器、存储器和总线，所述通信接口、所述处理器和所述存储器之间通过总线相互连接；

所述存储器中存储机器可读指令，所述处理器通过调用所述机器可读指令，执行如权利要求1至4任一项所述的方法。

Images