一种域名接管漏洞的检测方法和装置

【技术领域】

本发明涉及互联网技术领域，特别是涉及一种域名接管漏洞的检测方法和装置。

【背景技术】

随着云计算技术的不断发展和成熟，各种网络设施正在逐步迁移到云上面，传统的网络架构发生了巨大的变革。在传统的技术框架之下，公司如果要部署一个网站，往往需要自己来购买域名，配置DNS解析，购买IP地址或者网络空间服务，如果网站需要数据存储，则需要自己搭建数据库服务，如果需要处理大量并发访问，需要搭建负载均衡或者CDN网络。而现在随着虚拟化技术的发展，云计算公司提供各式各样的服务，几乎涵盖了所有的应用场景，举例来说，亚马逊云计算公司对外提供云服务器服务，DNS解析服务，负载均衡服务，CDN服务，数据库服务，存储桶服务等等，使得构建复杂的IT设施变得非常灵活和简单。一方面，IT基础设施迁移到云上之后，使用起来更便捷，更易扩展，健壮性更好；另一方面，随着各种基础组件越来越模块化，各种组件之间的交互越来越多，配置出错的概率越来越大。

域名接管本身是一种漏洞，它和域名劫持有相似的地方，但是也有显著的区别。

域名劫持，一般翻译为domain hijack，是指当用户访问一个域名时，攻击者利用自身对网络的控制，把针对此域名的访问重定向到虚假服务器上面。最常见的情况是，对域名进行DNS解析层面的劫持，比如域名真实的服务器IP地址为A，经过劫持之后，域名对应的服务器IP地址变为B。域名劫持一般是通过劫持DNS解析过程实现的，如DNS缓存投毒，DNS解析劫持等。

域名接管，一般翻译为domain takeover,是指攻击者利用目标域名DNS配置的一些错误，把针对目标域名的访问定向到虚假服务器上面。域名接管本身是一种漏洞，它产生的原因是目标域名自身的DNS系统配置出现了问题，针对这种漏洞可以进行攻击，达到控制域名的目的；而域名劫持，本身是一种攻击，这种攻击并不是基于某种漏洞，而是基于攻击者对网络有某种控制权限，如攻击者拥有网络设备控制权限，可以修改DNS流量报文，为受害者返回虚假DNS解析记录；或者是攻击者拥有DNS递归解析服务器的控制权限，可以修改DNS缓存记录。

域名劫持和域名接管的相似之处在于，最终表现出来的效果都是把目标域名解析到了攻击者控制的IP地址上面；不同之处在于，域名劫持往往要利用攻击者对网络设备的控制权限，如网关，路由器，DNS递归解析服务器等，域名接管不依赖对网络的控制权限，而是依赖于目标域名的DNS配置出现错误。如果不对目标域名进行域名劫持，那么目标域名不会出现任何解析错误和问题，DNS解析和访问都是正常的；如果不对目标域名进行域名接管，那么目标域名本身由于DNS解析配置的错误，也会出现不能正常解析的问题，只不过此时不会被恶意解析到攻击者控制的IP地址上面而已。

CNAME记录是DNS协议中的一种资源记录，也叫做别名记录，它存储的内容是当前域名的别名，此记录最常见的使用场景，是把流量导向第三方服务。CNAME的使用场景有很多，最常见的有两类应用，第一类是网络基础服务和产品，如CDN，负载均衡，基于云架构的WEB应用防火墙，基于云架构的防DDoS攻击产品等等；第二类是一些第三方的SaaS服务，比如主域名为example.com，它想使用第三方的聊天服务chat.com，那么它可以在第三方服务商那里申请一个服务入口example.chat.com,同时使用DNS CNAME记录为自身的子域名chat.example.com添加一个别名记录，指向example.chat.com，这样一来凡是访问chat.example.com的流量会全部导向example.chat.com。CNAME本身是把原始域名指向了另一个域名，这意味着同时把IP地址的解析权限也交给了新域名，CNAME本身是两种域名系统的衔接器，而一旦衔接出现问题，就会导致域名接管漏洞。最典型的漏洞场景为，目标域名使用了第三方的服务，所以使用CNAME记录指向到了第三方服务的域名，但是后来由于第三方服务到期终止，但是目标域名忘记在自身的DNS系统中及时修改此别名记录，这样就会导致一条悬空的CNAME记录。此种悬空的CNAME记录会造成域名接管漏洞，这种漏洞的表现形式直接和第三方的服务有关，在第三方服务过期之后，有些第三方服务会直接不再解析相关域名，有些则选择解析到一些默认的错误页面。

传统的对于域名接管漏洞的检测思路一般是基于CNAME关键字和第三方服务厂商的默认错误页面关键字，即收集第三方服务的CNAME域名关键字列表，根据目标域名的CNAME别名记录是否匹配这些关键字列表，来判断目标域名是否使用了相关的第三方服务；同时收集第三方服务厂商的默认错误页面的显示信息，形成错误信息关键字列表，根据目标域名的默认网页内容是否匹配此错误信息关键字列表，来判断目标域名的第三方服务是否已经不可用。传统的基于CNAME的检测方法有一种缺陷，那就是此方法只能检测DNS解析正常的情况，如果域名本身不能解析，那么此方法就会失效。具体来说，由于此方法是匹配CNAME关键字和第三方的错误信息关键字，那么它要求目标域名必须能够解析到IP地址，进而从目标IP地址上获取网页文件，如此才能进一步匹配关键字。如果DNS解析不成功，无论是此域名不存在，或者是域名解析过程出错，此种方法都是不能处理的。针对此种情况，本发明提出了一种新的检测方法，此方法不依赖于CNAME关键字和第三方服务的错误信息关键字，而是通过检测DNS NS记录，以及DNS交互协议的响应状态码来检测域名接管漏洞。

NS记录是DNS资源记录的一种，是name server的缩写，表示域名的权威域名服务器，负责存储DNS资源记录的，是真正负责域名解析的服务器。NS记录一般是在域名服务商那里配置，它本身必须是域名，不能是IP地址。NS服务可以自己搭建，也可以使用第三方的服务，比如国内的DNSPod便是专业的DNS解析服务提供商。随着云计算的发展，越来越多的厂商对外提供DNS解析服务，亚马逊云计算厂商的Router53服务，微软云服务的Azure DNS服务等等。当使用第三方的DNS解析服务时，便会在第三方平台上存储DNS记录，这些DNS记录形成一个记录文件，这个文件叫做DNS Zone文件；当用户不再使用第三方DNS解析服务时，第三方平台则会删除此域名对应的DNS Zone文件，如果此时目标域名的NS记录并没有及时更新，则会出现域名接管漏洞，导致目标域名整个域的DNS解析权限被接管。当整个域的DNS解析权限被接管之后，导致的危害极大，因为这里不仅仅是接管了某个独立的域名，而是接管了整个域的解析权限，攻击者可以对此域下面的所有子域名进行解析，从而可以实施冒领证书，接收和发送此域名相关的邮件等等攻击行为。

鉴于此，克服该现有技术所存在的缺陷是本技术领域亟待解决的问题。

【发明内容】

本发明要解决的技术问题是如何实现对域名接管漏洞的检测。

本发明采用如下技术方案：

第一方面，本发明提供了一种域名接管漏洞的检测方法，包括：

向递归解析服务器查询目标域名DNS A记录；

获取DNS的响应报文，检查其DNS响应状态码是SERVFAIL时,向NS服务器查询目标域名DNS A记录；

获取第一NS服务器返回的查询到目标域名DNS A记录的结果，将所述第一NS服务器，记做NS_1；把NS_1服务器负责的域，记做DOMAIN_1；把所述第一NS服务器上一级的NS服务器记做NS_0；

其中，DOMAIN_1和NS_1会出现在NS_0服务器的DNS响应内容中，NS_0的DNS响应内容就是一条NS记录，表明DOMAIN_1的NS服务器是NS_1；

向NS_1服务器查询DOMAIN_1的DNS NS记录，并根据获取到的DNS NS记录和NS_1进行比对,若不匹配则认定为存在域名接管漏洞。

优选的，向NS_1服务器查询DOMAIN_1的DNS NS记录，如果返回的DNS响应状态码为REFUSED，则认定为存在域名接管漏洞。

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

向NS_0查询NS_1的DNS A记录，记做IP_0；

向NS_1查询NS_1的DNS A记录，记做IP_1；

检查IP_0是否等于IP_1，若一致，则说明无漏洞；若不一致，则说明存在域名接管漏洞。

优选的，所述向NS服务器查询目标域名DNS A记录，具体包括：

若查询的NS服务器是负责目标域名DNS A解析的NS服务器，那么作为第一NS服务器返回的查询到目标域名DNS A记录的结果；

若查询的NS服务器，并不是负责目标域名DNS A解析的NS服务器，而是根服务器，或者顶级域名服务器，则会返回NS记录，以便DNS请求客户端根据所述NS记录向下一级NS服务器发送。

优选的，以递归的方式逐级获取NS服务器，直到抵达所述第一NS服务器，所述获取第一NS服务器返回的查询到目标域名DNS A记录的结果，具体为：如果正常解析，返回结果为目标域名的DNS A记录解析得到的IP地。

优选的，方法还包括：如果解析失败，返回结果为NXDOMAIN或SERVFAIL状态码。

优选的，所述状态码是SERVFAIL时，具体为：递归解析服务器不能联网、DNSSEC校验未通过、NS服务器不可达、NS服务器上没有对应域名的DNS ZONE文件中的一种或者多种。

优选的，所述向递归解析服务器查询目标域名DNS A记录，是由域名接管漏洞检测设备发起。

优选的，域名接管漏洞检测设备搜集有网络中的DNS记录，并通过周期性的向递归解析服务器逐条查询DNS记录方式完成域名接管漏洞的检测。

第二方面，本发明还提供了一种域名接管漏洞的检测装置，用于实现第一方面所述的域名接管漏洞的检测方法，所述装置包括：

至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述处理器执行，用于执行第一方面所述的域名接管漏洞的检测方法。

第三方面，本发明还提供了一种非易失性计算机存储介质，所述计算机存储介质存储有计算机可执行指令，该计算机可执行指令被一个或多个处理器执行，用于完成第一方面所述的域名接管漏洞的检测方法。

本发明通过当前级NS服务器，以及其上级NS服务器各自的数据维护特点，并在目标域名DNS A记录解析失败的情况下分析出域名接管漏洞的问题所在；克服了现有技术中对于此问题的发生时，通常会漏掉此种情形的问题。

【附图说明】

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

图1是本发明实施例提供的一种域名架构示意图；

图2是本发明实施例提供的一种域名接管漏洞的检测方法流程示意图；

图3是本发明实施例提供的一种域名接管漏洞的检测方法流程示意图；

图4是本发明实施例提供的一种上级NS胶水记录代码示意图；

图5是本发明实施例提供的一种域名接管漏洞的检测装置结构示意图。

【具体实施方式】

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

在DNS解析过程中，涉及到众多角色，包括：DNS客户端、转发DNS、递归DNS和权威DNS。

DNS客户端，就是发起DNS请求的角色，如浏览器。

转发DNS，本身不做DNS递归查询，而是把DNS请求转发给递归DNS，来进行查询；典型的转发DNS，如家用的路由器，IP地址往往是192.168.1.1。

递归DNS，也叫DNS resolver,递归解析服务器，负责递归查询DNS树形结构。

通常所说的为电脑配置DNS服务器，这里的DNS服务器严格来说叫法并不正确，应该叫做递归DNS，或者是转发DNS。

权威DNS服务器，也叫NS server,权威域名服务器，是DNS树形结构中的节点，负责某个域名区域的DNS记录。

此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。

在权威域名服务器中，记录了自身负责域名区域内所有的DNS解析记录，最常见的记录类型有：A记录，域名的IP地址；NS记录，域名的权威域名服务器地址；MX记录，域名的邮件服务器地址；TXT记录，域名的文本记录。

比如说，你的网站域名是www.testqqsg.tk,DNS递归请求流程如下：

找到根域名的NS服务器，根域名是.，得到13个根域名服务器，选择第一个a.root-servers.net；

向a.root-servers.net.发起目标域名www.testqqsg.tk的A记录请求，返回顶级域名tk.的NS记录为c.ns.tk；

向c.ns.tk发起目标域名www.testqqsg.tk的A记录请求，返回域名testqqsg.tk的NS记录ns.testqqsg.tk；

向ns.testqqsg.tk发起目标域名www.testqqsg.tk的A记录请求，得到www.testqqsg.tk的IP地址。

DNS树形结构如图1所示，每一层的一个节点，代表着一个DNS区域，负责对本区域内的所有子域名做解析，如果本层节点还有下一个层级节点，那么由下一级的节点负责对相应的子域名做解析。举例如下，目标域名如果是www.example.com,那么负责解析它的是第三级的节点example.com；目标域名如果是www.test.example.com,那么负责对它进行解析的是第四级节点test.example.com；如果目标域名是abc.test2.test.example.com,那么负责对它进行解析的是第五级节点test2.test.example.com。换句话说，example.com负责解析*.example.com，除非是有下级节点明确承担了一部分子域名解析工作，比如这里就是存在一个下级节点test.example.com，它负责对*.test.example.com进行解析。如果一个域名的NS记录是本域名的子域名时，递归服务器在解析域名时，会陷入循环中。比如说的域名为example.com,对应的NS服务器是ns.example.com，那么在递归解析服务器对example.com进行递归解析的过程中，它会先询问com对应的NS服务器，此时com对应的NS服务器告诉递归解析服务器，example.com对应的NS服务器是ns.example.com,然后递归解析服务器在定位ns.example.com的IP地址时，又会重新走到这一步，就形成了循环。为了解决这个问题，胶水记录就产生了，胶水记录是一条特殊的DNS资源记录，它存在的目的就是打破一个域名的NS记录是自身的一个子域名这种情况产生的循环死锁。举例来说，胶水记录就是存在com对应的NS服务器中的一条记录，它直接记录了ns.example.com的IP地址，当递归解析服务器向com对应的NS服务器查询时，com的NS服务器不仅返回example.com的NS是ns.example.com，同时也返回ns.example.com的IP地址。NS记录连接了DNS树形结构的上下两级节点，并且和胶水记录密切相关，example.com的NS记录会同时存在example.com的NS服务器中，以及com的NS服务器中，正常情况下两者应该保持一致，如果不一致，在DNS递归解析过程中，只有com的NS服务器中的记录会起作用。

本发明提出的检测方法，主要有以下几个步骤。首先，向递归解析服务器发起DNS查询，查询目标域名的DNS A记录，此时观察DNS响应报文中的状态码字段，查看是否是SERVFAIL；其次，在DNS树形系统中定位本层级域名，同时找到本层级域名的权威域名服务器；然后，向本层级域名的权威域名服务器，发起DNS请求，查询目标是本层级域名的DNS NS记录；最后检查收到的DNS响应报文，一方面查看DNS响应状态码是否是REFUSED，另一方面对比目标域名的NS服务器返回的NS记录和A记录，以及从上一级节点返回的NS记录和A记录，综合来判断是否存在域名接管漏洞。举例如下，假如要检查的目标域名是test2.test.example.com,首先需要向递归解析服务器查询目标域名的DNS A记录，这里的递归解析服务器就是通常所说的DNS服务器，比如公共的114.114.114.114，谷歌的8.8.8.8，或者是各大运营商提供的默认DNS服务器。然后检查DNS的响应报文，观察其DNS响应状态码是否是SERVFAIL,如果是的话，则开始定位目标域名在DNS树形系统中的本层级域名。具体操作是，首先向根服务器发起针对目标域名的DNS A记录查询，根服务器会返回com域名的NS记录，记做NS_com，然后向NS_com发起查询，会返回example.com的NS记录，记录NS_example.com，然后向NS_example.com发起查询，会返回test.example.com的NS记录，记做NS_test.example.com,然后向NS_test.example.com发起查询，如果一切正常则会返回test2.test.example.com的IP地址，如果目标域名存在DNS配置错误，这里可能会返回DNS错误信息，如REFUSED。在所有的查询中，DNS请求都是请求目标域名test2.test.example.com的A记录，当整个查询过程结束，得到了以下信息，在DNS树形系统中，目标域名test2.test.example.com在DNS系统树形结构中的节点域名为test.example.com,或者叫做DNS Zone域为test.example.com，本级节点域名的NS为NS_test.example.com,上级域名为example.com,上级域名NS为NS_example.com。接下来，向NS_test.example.com查询test.example.com的DNS NS记录，查看其返回结果中DNS响应状态码是否为REFUSED，如果是的话，则说明存在域名接管漏洞；如果不是的话，则进一步对比DNS响应内容的值是否是NS_test.example.com，如果不是，则说明NS记录在DNS树形结构中的上下两级节点中的值不一致，说明存在配置错误，存在域名接管漏洞；反之则进一步检查胶水记录。胶水记录的检查，首先获取目标域名的NS服务器域名以及负责解析的DNS ZONE域名，然后检查NS域名是否是DNS ZONE域名的一个子域名，如果是的话，就进一步检查胶水记录。方法是，从上级NS节点获取胶水记录，然后从本级NS节点获取NS域名的A记录，对二者进行比较，如果一致则说明没问题，反之则说明存在DNS配置错误，存在域名接管漏洞。

本发明提出的检测方法和传统的检测方法相比有以下几个特点，一是基于DNS的NS记录来检测，而不是基于CNAME记录。传统的基于CNAME的检测方法是站在DNS客户端的角度，只是单纯的向递归解析服务器请求把域名解析到IP地址，具体的递归解析过程都是由递归解析服务器来完成的，本身并不直接和DNS树形结构打交道；本方法是站在递归解析服务器的角度，会直接向DNS树形结构系统发起查询，会大量涉及到NS记录。在传统的检查域名接管漏洞的方法中，有一种针对NS记录的检查方法，此方法是检查NS域名的有效性，域名是否过期，是否可以被注册，如果NS域名可以被攻击者恶意注册，自然可以接管对应的域名，不过这种方法和本发明中对NS记录的使用方法有着本质的区别。二是对DNS不能正常解析的情况进行检测，传统方法只是针对DNS正常解析的情况进行检测。DNS响应状态码有四种，NXDOMAIN表示域名不存在，NOERROR表示解析正常，SERVFAIL表示服务器出错，REFUSED表示拒绝服务，传统的检测方式只能处理解析正常的情况，如果DNS解析出现了错误，就不能处理了；本方法针对DNS解析出现错误的情况，进一步区分错误的详细类型，进而检测是否存在域名接管漏洞；三是对胶水记录和NS记录的理解和使用上。胶水记录是一种特殊的记录，只有域名的NS记录是自己的子域名时，才存在胶水记录；比胶水记录更重要的是NS记录，它连接了DNS树形结构的上下级节点。对于NS记录和胶水记录来说，它们实际上会同时存在两份，一份在本级节点域名的权威域名服务器上，另一份在上级节点域名的权威域名服务器上，而且真正起作用的是上级节点域名的权威域名服务器中的配置，而本级节点域名权威域名服务器的配置虽然存在，也可以查询，但是在正常的DNS解析流程中并不发挥作用。正常DNS解析流程中，是不会向本级域名NS服务器查询本级域名的NS记录的，举个通俗的例子，正常的DNS解析流程就像是，你会向张三的上级询问“谁是张三”，但是却不会向张三本人询问“谁是张三”，但是“谁是张三”这个记录同时存在于张三本人和张三上级两个人的记录档案里。本文的检测流程中会向张三上级和张三本人询问，如果发现答案不一致，则说明存在DNS配置错误，存在域名接管的风险。

本发明实施例1提供了一种域名接管漏洞的检测方法，如图2所示，包括：

在步骤201中，向递归解析服务器查询目标域名的DNS A记录。

在步骤202中，获取DNS的响应报文，检查其DNS响应状态码是SERVFAIL时,向NS服务器查询目标域名的DNS A记录。

其中，所述状态码是SERVFAIL，表明递归解析服务器不能联网、DNSSEC校验未通过、NS服务器不可达、NS服务器上没有对应域名的DNS ZONE文件中的一种或者多种。

在步骤203中，获取第一NS服务器返回的查询到目标域名的DNS A记录的结果，将所述第一NS服务器，记做NS_1；把NS_1服务器负责的域，记做DOMAIN_1；把所述第一NS服务器上一级的NS服务器记做NS_0。

其中，DOMAIN_1和NS_1会出现在NS_0服务器的DNS响应内容中，NS_0的DNS响应内容就是一条NS记录，表明DOMAIN_1的NS服务器是NS_1。

在步骤204中，向NS_1服务器查询DOMAIN_1的DNS NS记录，并根据获取到的DNS NS记录和NS_1进行比对,若不匹配则认定为存在域名接管漏洞。

其中，向NS_1服务器查询DOMAIN_1的DNS NS记录，如果返回的DNS响应状态码为REFUSED，则认定为存在域名接管漏洞。

本发明通过当前级NS服务器，以及其上级NS服务器各自的数据维护特点，并在目标域名的DNS A记录解析失败的情况下分析出域名接管漏洞的问题所在；克服了现有技术中对于此问题的发生时，通常会漏掉此种情形的问题。

现有的技术依赖对CNAME关键字和网页信息关键字的匹配，前提是要求域名可以正常解析，如果域名不能解析，就不能继续进行处理。现有的技术需要获取到目标域名的DNS CNAME记录和目标域名的DNS A记录，而要获取到这两个记录，需要DNS响应状态码必须是NOERROR，而不能是NXDOMAIN，SERVFAIL，REFUSED等。只有当DNS响应状态码是NOERROR时，才意味着域名可以正常解析，其它情况下意味着域名解析出错。传统的检测技术中，对域名解析部分都是依靠递归解析服务器来完成，并不会直接和DNS树形结构系统交互，本文提出的方法除了查询递归DNS服务器，同时也查询DNS树形结构系统，直接和NS服务器进行交互，从而可以检测出来一些隐蔽的DNS配置错误导致的域名接管漏洞。

在本发明实施例，所述向NS服务器查询目标域名的DNS A记录，具体包括两种情况：

第一、若查询的NS服务器是负责目标域名的DNS A解析的NS服务器，那么作为第一NS服务器返回的查询到目标域名的DNS A记录的结果。

第二、若查询的NS服务器，并不是负责目标域名DNS A解析的NS服务器，而是根服务器，或者顶级域名服务器，则会返回NS记录，以便DNS请求客户端根据所述NS记录向下一级NS服务器发送。

在本发明实施例中，通常会涉及以递归的方式逐级获取NS服务器，直到抵达所述第一NS服务器，所述获取第一NS服务器返回的查询到目标域名的DNS A记录的结果，具体为：如果正常解析，返回结果为目标域名的DNS A记录解析得到的IP地；如果解析失败，返回结果为NXDOMAIN，SERVFAIL等状态码。

结合本发明实施例，还存在一种优选的扩展方案，所述方法还包括：

向NS_0查询NS_1的DNS A记录，记做IP_0；

向NS_1查询NS_1的DNS A记录，记做IP_1；

检查IP_0是否等于IP_1，若一致，则说明无漏洞；若不一致，则说明存在域名接管漏洞。

所述向递归解析服务器查询目标域名的DNS A记录，是由域名接管漏洞检测设备发起；其中，域名接管漏洞检测设备搜集有网络中的DNS记录，并通过周期性的向递归解析服务器逐条查询DNS记录方式完成域名接管漏洞的检测。

本发明实施例基于实施例1提出的解决方案基础上，从一个较为完整的分析逻辑，将几种可能域名接管漏洞集中到了一个完整的分析逻辑中进行呈现，如图3所示，包括以下步骤：

步骤S101，向递归解析服务器查询目标域名的DNS A记录；

这里的递归解析服务器是指DNS Resolver，比如公共的114.114.114.114，谷歌的8.8.8.8，或者是各大运营商提供的默认DNS解析服务器。

这里需要对概念和名词做出澄清，我们平时上网给电脑配置的DNS服务器，虽然也称作“DNS服务器”，但是严格来说这种叫法是错误的，按照DNS规范应该叫做递归解析服务器(或者叫做DNS Resolver)，而DNS系统里面的权威域名服务器，在DNS系统规范中叫做DNSServer(也叫做NS服务器)。所以本发明实施例中，递归解析服务器就是指DNS Resolver,权威域名服务器就是指NS服务器，也叫做DNS Server。

步骤S102，获取DNS的响应报文，检查其DNS响应状态码是否是SERVFAIL,如果是的话，表示递归解析服务器在向DNS树形系统查询时发生错误，进入S103步骤，否则的话，直接返回无漏洞。

此步骤是检查步骤S101中，递归解析服务器返回的DNS响应内容，DNS响应内容中有一项为状态码，这里是要检查状态码是否是SERVFAIL，这个状态码表示递归解析服务器在查询DNS系统时，发生了错误，有多种情况可能会引发这种错误，比如递归解析服务器不能联网，DNSSEC校验未通过，NS服务器不可达，NS服务器上没有对应域名的DNS ZONE文件等等。

步骤S103，向根域名服务器查询目标域名的DNS A记录。

此步骤是直接向DNS系统的根域名服务器发起DNS查询请求，查询目标域名的DNSA记录，也就是把目标域名解析到IP地址。根域名服务器，是DNS系统树形结构中的根节点，本质上是NS服务器。

DNS系统是一个树形结构，其中每个节点都是一个NS服务器，也叫做权威域名服务器，其中的第一层节点叫做根服务器，root name server,第二层节点叫做顶级域名服务器，top level domain name server。比如根域名服务器负责解析的域就是一个点“.”,顶级域名服务器负责解析的域是“com.”,“net.”等等。

步骤S104，检查DNS响应是否是NS记录。

此步骤是，检查NS服务器返回的DNS响应，如果NS服务器是负责目标域名解析的权威域名服务器，那么返回的DNS响应内容就是针对A记录请求的答案；如果查询的NS服务器，并不是目标域名的NS服务器，而是根服务器，或者顶级域名服务器等等，那么则会返回NS记录，目的是告诉DNS请求客户端，下一步应该去找谁去查询。如果DNS响应返回的是NS记录，则进入步骤S105，否则进入步骤S107，表明当前级的NS服务器是目标域名DNS A记录所属的NS服务器。

步骤S105，获取下一级NS服务器。

此步骤是解析步骤S104中的DNS响应内容，如果响应内容是NS记录，那么则说明，当前的NS服务器并不是目标域名的NS服务器，当前NS服务器把指引到了下一级的NS服务器，此步骤就是获取到下一级的NS服务器。

步骤S106，向下一级NS服务器查询目标域名的DNS A记录。

此步骤是向步骤S105种获取到的NS服务器发起DNS请求，查询目标域名的DNS A记录，也就是把目标域名解析到IP地址。步骤S106和步骤S105组成了递归解析的过程。

步骤S107，获取当前的NS服务器，记做NS_1；把NS_1服务器负责的域，记做DOMAIN_1；把上一级的NS服务器记做NS_0。能够进入此步骤说明DNS响应内容已经不是NS记录，此时响应的NS服务器，已经是目标域名的权威域名服务器，也就是NS服务器，把此值记做NS_1，同时把此NS服务器负责的域记做DOMAIN_1，把上级节点的NS服务器记做NS_0。DOMAIN_1和NS_1会出现在NS_0服务器的DNS响应内容中，NS_0的DNS响应内容就是一条NS记录，表明DOMAIN_1的NS服务器是NS_1。

步骤S108，向NS_1服务器查询DOMAIN_1的DNS NS记录。这里的NS_1就是指步骤S107中获取到的目标域名的NS服务器，也就是目标域名的权威域名服务器，此时向NS_1查询DOMAIN_1的DNS NS记录，其实就是向目标域名的NS服务器查询DNS ZONE域名的NS记录，在正常的DNS递归解析过程中，是不会出现这个查询步骤的，正常的查询流程中，是由上一级的NS服务器告知DNS ZONE域名的NS服务器的。

步骤S109，检查DNS响应是否是REFUSED。这里是检查步骤S108中的DNS响应内容，查看其DNS状态码是否是REFUSED，如果是的话，直接返回高风险；否则进入步骤S110。这个步骤背后的技术原理是，每个域的NS服务器中，都有此域的DNS ZONE文件，如果向此NS服务器查询它不负责解析的域的DNS记录，那么就会返回REFUSED，表示拒绝服务。

如果到达这个步骤，说明在DNS系统中，树形节点还在，上一层级的节点仍然指向本级节点，但是本级节点内部，已经删除了目标域的配置。这种情况本质上属于一种配置错误，上层级节点指向本层级的记录是保存在上层级节点中的，这个配置信息，是在域名服务商那里进行配置，就是配置域名的NS记录，而具体的DNS资源记录是在NS服务器里面进行配置的，NS记录指向了NS服务器的域名。

步骤S110，获取DNS响应中NS的值，记做NS_2。这里是对步骤S108中的DNS响应内容做解析，因为步骤S108是查询的NS记录，所以DNS响应内容也是NS记录，把这个NS值记做NS_2。

此步骤背后的原理是，域名的NS记录在DNS树形系统中会存在两份，一份在上一级NS服务器中，一份在本层级NS服务器中。比如目标域名是www.example.com,对应的域是example.com,对应的NS是ns.example.com；上一级NS是ns.com，负责的域是com.，那么这一条NS记录“example.com IN NS ns.example.com”会同时出现在ns.com这台NS服务器的配置中，以及ns.example.com这台NS服务器的配置中。我们获取的NS_1就是从ns.com这台NS服务器中获取到的NS记录，这里的NS_2就是从ns.example.com这台NS服务器中获取到的NS记录，使用dig工具执行的命令如下所示：

获取NS_1:dig example.com ns@ns.com

获取NS_2:dig example.com ns@ns.example.com

在一些英文技术文献中，把NS_1叫做parent NS,把NS_2叫做local NS。其中NS_2记录是很特殊的一条记录，它必须配置，而且要和NS_1保持一致，但是在正常的DNS解析过程中并不发挥作用，也就是说如果NS_2和NS_1不一致，那么DNS解析时是以NS_1为准的。

步骤S111，检查NS_1和NS_2是否相同，如果相同，则进入步骤S112，否则返回中风险。这里的NS_1和NS_2都代表了目标域名的权威域名服务器，也就是NS服务器，不过NS_1是通过在DNS系统树形结构中递归查询时，查询上级节点得到的，而NS_2是直接向目标域名的NS服务器查询得到的。如果这两个值相同，则说明NS记录配置没有问题，进入步骤S112继续进行其它检查，反之则说明有配置错误，这里正常情况下，NS_1和NS_2是一致的，如果不一致，则说明出现了配置错误，NS_1是在域名服务商那里进行配置的NS记录，NS_2是在自己负责的NS服务器里配置的NS记录。

步骤S112，检查NS_1是否是DOMAIN_1的子域名，此步骤是确定目标域名的NS服务器域名是否是NS服务器所负责的DNS ZONE域的子域名。举例来说，如果example.com的NS记录是ns.example.com，那么就属于这种情况，如果example.com的NS记录是ns.nowhere.com，那么就不属于这种情况。如果是的话，则进入步骤S113继续检查，否则返回无风险。这里背后的原理是，如果一个域名的NS记录是自己的子域名，那么就会引入胶水记录，就要检查胶水记录在上级节点中和当前节点中的配置是否一致，如果不一致则说明有配置错误，有域名接管漏洞。

举例来说，目标域名为www.example.com对应的NS服务器域名是ns.example.com，NS服务器的IP地址是1.1.1.1，负责的域是example.com,上级NS是ns.com,负责的域是com.,此时胶水记录是“ns.example.com IN A1.1.1.1”，这条DNS记录同时存在于ns.com这台NS服务器上，和ns.example.com这台NS服务器上。

步骤S113，向NS_0查询NS_1的DNS A记录，记做IP_0。此步骤就是向上级节点，查询本级节点的胶水记录，举例来说，如果example.com的NS记录是ns.example.com，上级节点com的NS记录是ns.com，这里执行的操作就是向ns.com查询ns.example.com的IP地址,使用dig工具的命令为“dig ns.example.com@ns.com”。

步骤S114，向NS_1查询NS_1的DNS A记录，记做IP_1。此步骤就是向本级节点，查询本级节点的IP地址，举例来说，如果example.com的NS记录是ns.example.com，这里执行的操作就是向ns.example.com查询ns.example.com的IP地址。步骤S113种的IP_0其实就是胶水记录，而这里的IP_1其实就是在本级NS服务器查询对应的胶水记录，使用dig命令查询为“dig ns.example.com@ns.example.com”。需要注意的是，向本级NS查询NS的目标域名的DNS A记录，返回结果中会自动携带上级NS的胶水记录，参考图4所示代码，因为在确定NS的IP地址的过程中会有一个递归查询过程，此过程会查询上级NS服务器。

步骤S115，检查IP_0是否等于IP_1，这里是比较从步骤S113中获取的IP_0和步骤S114中的IP_1是否相等。IP_0来源于上级NS节点的胶水记录，IP_1来源于本级NS节点的配置记录，IP_0和IP_1如果数量是多个的话，则进行集合比较，即比较两个集合是否相等。正常情况下二者应该是一致的，返回无漏洞；如果二者不一致，说明出现了DNS配置错误，存在域名接管漏洞。

如图5所示，是本发明实施例的域名接管漏洞的检测装置的架构示意图。本实施例的域名接管漏洞的检测装置包括一个或多个处理器21以及存储器22。其中，图5中以一个处理器21为例。

处理器21和存储器22可以通过总线或者其他方式连接，图5中以通过总线连接为例。

存储器22作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序和非易失性计算机可执行程序，如实施例1中的域名接管漏洞的检测方法。处理器21通过运行存储在存储器22中的非易失性软件程序和指令，从而执行域名接管漏洞的检测方法。

存储器22可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器22可选包括相对于处理器21远程设置的存储器，这些远程存储器可以通过网络连接至处理器21。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

所述程序指令/模块存储在所述存储器22中，当被所述一个或者多个处理器21执行时，执行上述实施例1中的域名接管漏洞的检测方法，例如，执行以上描述的图2和图3所示的各个步骤。

值得说明的是，上述装置和系统内的模块、单元之间的信息交互、执行过程等内容，由于与本发明的处理方法实施例基于同一构思，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。

本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取存储器(RAM，Random AccessMemory)、磁盘或光盘等。

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