CN108933693B - 一种域名服务系统故障处理方法和系统 - Google Patents

一种域名服务系统故障处理方法和系统 Download PDF

Info

Publication number
CN108933693B
CN108933693B CN201710389043.7A CN201710389043A CN108933693B CN 108933693 B CN108933693 B CN 108933693B CN 201710389043 A CN201710389043 A CN 201710389043A CN 108933693 B CN108933693 B CN 108933693B
Authority
CN
China
Prior art keywords
fault
configuration file
dns server
authoritative dns
domain name
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201710389043.7A
Other languages
English (en)
Other versions
CN108933693A (zh
Inventor
符立佳
苗辉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guizhou Baishancloud Technology Co Ltd
Original Assignee
Guizhou Baishancloud Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guizhou Baishancloud Technology Co Ltd filed Critical Guizhou Baishancloud Technology Co Ltd
Priority to CN201710389043.7A priority Critical patent/CN108933693B/zh
Publication of CN108933693A publication Critical patent/CN108933693A/zh
Application granted granted Critical
Publication of CN108933693B publication Critical patent/CN108933693B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
    • H04L41/0661—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities by reconfiguring faulty entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0859—Retrieval of network configuration; Tracking network configuration history by keeping history of different configuration generations or by rolling back to previous configuration versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0859—Retrieval of network configuration; Tracking network configuration history by keeping history of different configuration generations or by rolling back to previous configuration versions
    • H04L41/0863—Retrieval of network configuration; Tracking network configuration history by keeping history of different configuration generations or by rolling back to previous configuration versions by rolling back to previous configuration versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明提供了一种域名服务系统故障处理方法和系统。涉及计算机网络领域；解决了现有故障处理方式大幅降低网络访问效率的问题。该方法包括：检测权威域名服务系统DNS服务器集群中各权威DNS服务器的工作状态；在检测到发生故障时，根据故障规模，对故障的权威DNS服务器进行隔离处理。本发明提供的技术方案适用于权威DNS集群，实现了快速有效的DNS解析故障响应。

Description

一种域名服务系统故障处理方法和系统
技术领域
本发明涉及计算机网络领域，尤其涉及一种域名服务系统(DNS)故障处理方法和系统。
背景技术
DNS解析作为互联网访问的入口，在整个互联网体系中占据非常重要的地位。如何保障DNS稳定运行至关重要。
“NXDOMAIN应答”的意思为“解析的域名不存在”，业务服务域名因为故障原因解析出NXDOMAIN的结果为DNS最主要的故障之一，会直接导致无法提供网络服务。
现有的DNS服务器故障响应，一般采用人工处理；而系统自动处理方式，只是由权威DNS服务器自动将所有NXDOMAIN包丢掉，后续还是需要人工处理才能解决故障，因而会造成大面积的业务长时间中断，大量域名在此期间不可用，极大的影响了网络访问效率。
发明内容
本发明旨在解决上面描述的问题。
根据本发明的第一方面，一种域名服务系统故障处理方法，包括：
检测权威域名服务系统DNS服务器集群中各权威DNS服务器的工作状态；
在检测到发生故障时，根据故障规模，对故障的权威DNS服务器进行隔离处理。
优选的，该方法还包括：
为权威DNS服务器分配探测域名。
优选的，所述检测权威DNS服务器集群中各权威DNS服务器的工作状态的步骤包括：
向所述权威DNS服务器发送对所述探测域名进行解析的请求；
接收返回的状态信息，所述状态信息至少包含以下信息中的任一项或任意多项：
探测时间，应答状态，线上配置文件版本；
根据所述状态信息，生成监控数据，所述监控数据至少包含以下任一或任意多个字段：
探测时间，权威DNS服务器IP，探测域名，域zone，应答状态，线上配置文件版本，
其中，所述zone字段指示权威DNS服务器对应的解析域；
对所述监控数据进行分析，判定是否发生故障。
优选的，对所述监控数据进行分析，判定是否发生故障的步骤包括：
在存在应答状态字段为NXDOMAIN的监控数据时，统计涉及的故障权威DNS服务器数量，得到表明故障范围的第一故障类型信息；
提取应答状态字段为NXDOMAIN的监控数据中的线上配置文件版本字段，对比所述线上配置文件版本与本地DNS配置文件列表中的最新配置文件版本，得到表明配置文件版本状态的第二故障类型信息。
优选的，在存在应答状态字段为NXDOMAIN的监控数据时，统计涉及的故障权威DNS服务器数量，得到表明故障范围的第一故障类型信息的步骤包括：
在故障的权威DNS服务器数量达到预置的故障类型定性阈值时，判定第一故障类型信息为“全平台故障类型”；
在故障的权威DNS服务器数量没有达到预置的故障类型定性阈值时，判定第一故障类型信息为“单设备故障类型”。
优选的，对所述监控数据进行分析，判定是否发生故障的步骤还包括：
在不存在应答状态字段为NXDOMAIN的监控数据时，判定系统正常。
优选的，在检测到发生故障时，根据故障规模，对故障的权威DNS服务器进行隔离处理的步骤包括：
在所述第一故障类型信息为“单设备故障类型”时，向故障的权威DNS服务器分别下发针对iptables 53端口的封禁指令，指示停止所述故障的权威DNS服务器的服务；
在第一故障类型信息为“全平台故障类型”时，暂停故障权威DNS服务器对域名解析请求的响应，根据之前缓存的历史应答结果响应归属于故障权威DNS服务器的域名解析请求。
优选的，该方法还包括：
通过以下方式中的任一或任意多种获取历史应答结果，添加到缓存中：
方式一、获取访问日志，从所述访问日志中提取以下字段，添加到缓存：
请求区域，域名，解析结果，
使用上述字段构造历史应答结果，并添加到缓存中；
方式二、复制传输历史应答结果，并添加到缓存中；
方式三、轮询扫描正常工作的权威DNS服务器的IP地址返回的解析结果，作为历史应答结果添加到缓存中。
优选的，提取应答状态字段为NXDOMAIN的监控数据中的线上配置文件版本字段，对比线上配置文件版本与本地DNS配置文件列表中的最新配置文件版本，得到表明配置文件版本状态的第二故障类型信息的步骤包括：
在所述线上配置文件版本为所述本地DNS配置文件列表中的最新版本时，判定第二故障类型信息为“配置文件版本正常”；
在所述线上配置文件版本不是所述本地DNS配置文件列表中的最新版本时，判定第二故障类型信息为“配置文件版本异常”。
优选的，在检测到发生故障时，根据故障规模，对故障的权威DNS服务器进行隔离处理的步骤之后，还包括：
在所述第二故障类型信息为“配置文件版本异常”时，向故障权威DNS服务器下发最新版本的配置文件，指示权威DNS服务器加载接收到的配置文件；
在所述第二故障类型信息为“配置文件版本正常”时，向故障权威DNS服务器下发故障前版本的配置文件，指示权威DNS服务器加载接收到的配置文件。
优选的，在所述第二故障类型信息为“配置文件版本异常”时，向故障权威DNS服务器下发最新版本的配置文件的步骤之后还包括：
在向故障权威DNS服务器下发最新版本的配置文件后，进行全网解析的本地轮询，检测故障是否已恢复，在检测结果为故障未恢复时，向故障权威DNS服务器下发故障前版本的配置文件，指示权威DNS服务器加载接收到的配置文件。
优选的，在加载故障前版本的配置文件失败后，重启故障的权威DNS服务器。
优选的，在所述进行故障恢复处理的步骤之后，还包括：
进行全网解析的本地轮询，检测故障是否已恢复；
在故障已恢复后，解除对所述故障的权威DNS服务器的隔离处理。
根据本发明的另一方面，提供了一种域名服务系统故障处理系统，包括：
故障检测模块，用于检测权威域名服务系统DNS服务器集群中各权威DNS服务器的工作状态；
故障隔离模块，用于在检测到发生故障时，根据故障规模，对故障的权威DNS服务器进行隔离处理。
优选的，该系统还包括：
配置管理模块，用于为权威DNS服务器分配探测域名。
优选的，所述故障检测模块包括：
请求发起单元，用于向所述权威DNS服务器发送对所述探测域名进行解析的请求；
信息收集单元，用于接收返回的状态信息，所述状态信息至少包含以下信息中的任一项或任意多项：
探测时间，应答状态，线上配置文件版本；
监控数据生成单元，用于根据所述状态信息，生成监控数据，所述监控数据至少包含以下任一或任意多个字段：
探测时间，权威DNS服务器IP，探测域名，域zone，应答状态，线上配置文件版本，
其中，所述zone字段指示权威DNS服务器对应的解析域；
故障分析单元，用于对所述监控数据进行分析，判定是否发生故障。
优选的，所述故障分析单元包括：
第一类型分析子单元，用于在存在应答状态字段为NXDOMAIN的监控数据时，统计涉及的故障权威DNS服务器数量，得到表明故障范围的第一故障类型信息；
第二类型分析子单元，用于提取应答状态字段为NXDOMAIN的监控数据中的线上配置文件版本字段，对比所述线上配置文件版本与本地DNS配置文件列表中的最新配置文件版本，得到表明配置文件版本状态的第二故障类型信息。
优选的，所述第一类型分析子单元，具体用于：
在故障的权威DNS服务器数量达到预置的故障类型定性阈值时，判定第一故障类型信息为“全平台故障类型”，
在故障的权威DNS服务器数量没有达到预置的故障类型定性阈值时，判定第一故障类型信息为“单设备故障类型”。
优选的，所述故障隔离模块包括：
封禁单元，用于在所述第一故障类型信息为“单设备故障类型”时，向故障的权威DNS服务器分别下发针对iptables 53端口的封禁指令，指示停止所述故障的权威DNS服务器的服务；
快速响应单元，用于在第一故障类型信息为“全平台故障类型”时，暂停故障权威DNS服务器对域名解析请求的响应，根据之前缓存的历史应答结果响应归属于故障权威DNS服务器的域名解析请求。
优选的，该系统还包括：
应急缓存模块，用于通过以下方式中的任一或任意多种获取历史应答结果，添加到缓存中：
方式一、获取访问日志，从所述访问日志中提取以下字段，添加到缓存：
请求区域，域名，解析结果，
使用上述字段构造历史应答结果，并添加到缓存中；
方式二、复制传输历史应答结果，并添加到缓存中；
方式三、轮询扫描正常工作的权威DNS服务器的IP地址返回的解析结果，作为历史应答结果添加到缓存中。
优选的，所述第二类型分析子单元，具体用于：
在所述线上配置文件版本为所述本地DNS配置文件列表中的最新版本时，判定第二故障类型信息为“配置文件版本正常”，
在所述线上配置文件版本不是所述本地DNS配置文件列表中的最新版本时，判定第二故障类型信息为“配置文件版本异常”。
优选的，该系统还包括：
第一故障恢复模块，用于在所述第二故障类型信息为“配置文件版本异常”时，向故障权威DNS服务器下发最新版本或故障发生前版本的的配置文件，指示权威DNS服务器加载接收到的配置文件；
第二故障恢复模块，用于在所述第二故障类型信息为“配置文件版本正常”时，向故障权威DNS服务器下发故障前版本的配置文件，指示权威DNS服务器加载接收到的配置文件。
优选的，所述故障检测模块，还用于在所述第一故障恢复模块在向故障权威DNS服务器下发最新版本或故障发生前版本的的配置文件后，进行全网解析的本地轮询，检测故障是否已恢复；
所述第一故障恢复模块，还用于在检测结果为故障未恢复时，向故障权威DNS服务器下发故障前版本的配置文件，指示权威DNS服务器加载接收到的配置文件。
优选的，所述第一故障恢复模块，还用于在加载故障前版本的配置文件失败后，重启故障的权威DNS服务器进程；
所述第二故障恢复模块，还用于在加载故障前版本的配置文件失败后，重启故障的权威DNS服务器进程。
优选的，所述故障检测模块，还用于在所述第一故障恢复模块或所述第二故障恢复模块处理完成后，进行全网解析的本地轮询，检测故障是否已恢复；
所述故障隔离模块，还用于在故障已恢复后，解除对所述故障的权威DNS服务器的隔离处理。
本发明的实施例提供了一种域名服务系统故障处理方法和系统，检测权威域名服务系统DNS服务器集群中各权威DNS服务器的工作状态，在检测到发生故障时，根据故障规模，对故障的权威DNS服务器进行隔离处理。进一步的，还可以进行故障的处理恢复。由系统自动完成对故障的发现、处理、恢复，解决了现有故障处理方式大幅降低网络访问效率的问题，实现了快速有效的DNS解析故障响应。
参照附图来阅读对于示例性实施例的以下描述，本发明的其他特性特征和优点将变得清晰。
附图说明
并入到说明书中并且构成说明书的一部分的附图示出了本发明的实施例，并且与描述一起用于解释本发明的原理。在这些附图中，类似的附图标记用于表示类似的要素。下面描述中的附图是本发明的一些实施例，而不是全部实施例。对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，可以根据这些附图获得其他的附图。
图1示例性地示出了本发明实施例一提供的一种DNS故障处理系统的架构；
图2示例性地示出了本发明实施例二提供的一种DNS故障处理方法的流程；
图3示例性地示出了本发明实施例三提供的一种DNS故障处理系统的架构；
图4示例性地示出了图3中故障检测模块301的结构；
图5示例性地示出了图3中故障隔离模块302的结构。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。
现有的DNS服务器故障响应，一般采用人工处理；而系统自动处理方式，只是由权威DNS服务器自动将所有NXDOMAIN包丢掉，后续还是需要人工处理才能解决故障，因而会造成大面积的业务长时间中断，大量域名在此期间不可用，极大的影响了网络访问效率。
为了解决上述问题，本发明的实施例提供了一种DNS故障处理方法和系统。通过对故障的检测，确认故障的发生及故障类型信息，进而确定处理方案，由系统自动进行故障的处理与服务的恢复，实现了高效自动的故障处理机制。
首先结合附图，对本发明的实施例一进行说明。
本发明实施例提供了一种DNS故障处理系统，自动检测权威DNS服务器集群中各权威DNS服务器的工作状态，通过工作状态信息判断所述权威域名服务系统是否存在故障的类型，并自动触发指定故障类型的故障隔离、故障快速处理、故障恢复机制。提高NXDOMAIN故障修复能力，降低故障影响的时间。
本发明实施例提供的系统架构如图1所示，包括配置管理模块、监控模块、故障定性模块、DNS模块、故障处理模块。
1、配置管理模块发送监控任务给监控模块，发送故障类型定性阈值和DNS配置文件列表给故障定性模块。
1)监控任务格式为：
权威DNS服务器IP，探测域名，域(zone)。
其中，探测域名为探测权威DNS服务器工作状态时使用的请求解析的域名，zone是权威DNS服务器解析的域。
2)故障类型定性阈值格式为：
全平台故障阈值n％。
该阈值的设置可根据实际DNS规模、设备可靠性、业务需求量等因素设置。
3)DNS配置文件列表：为所有DNS配置文件的版本号和下发时间，格式如下：
DNS配置文件版本号，下发时间。
2、监控模块探测DNS模块运行状态信息，读取监控任务里的信息，对权威服务器IP进行探测域名的请求，获取状态信息。
1)状态信息包括：
探测时间，应答状态，线上配置文件版本。
2)监控数据格式为：
探测时间，权威DNS服务器IP，探测域名，zone，应答状态，线上配置文件版本。
3、监控模块采集监控数据，并上报到故障定性模块。优选的，可每隔一个时间周期进行一次监控数据的采集上报。
4、故障定性模块接收监控模块上报的监控数据。
5、故障定性模块结合监控数据、故障类型定性阈值、DNS配置文件列表，判定是否存在故障，并对故障类型进行定性。
1)分析监控数据，如果本轮收集的所有监控数据中的应答状态均没有NXDOMAIN，则认为不存在发生故障的可能，直接结束故障判定，打印系统正常的日志；如果存在应答状态为NXDOMAIN的监控数据，可直接认定对应的权威DNS服务器发生故障；也可对NXDOMAIN信息涉及的权威DNS服务器进行进一步检测验证，最终确定发生故障的权威DNS服务器。
在确定发生故障后，继续进行判定是“单台故障”还是“全平台故障”，即，确认故障类型。
2)分析监控数据中应答状态为NXDOMAIN的部分，如果相同zone存在NXDOMAIN故障的权威DNS服务器数量小于故障类型定性阈值，则判定故障类型的第一故障类型信息为“单设备故障”；如果相同zone存在NXDOMAIN故障的权威DNS服务器数量大于等于故障类型定性阈值，则判定故障类型的第一故障类型信息为“全平台故障”。然后，继续判定故障类型，生成第二故障类型信息。
3)分析监控数据中应答为NXDOMAIN的部分，对比监控数据中线上配置文件版本和本地DNS配置文件列表，如果线上配置文件版本为本地DNS配置文件列表中的最新版本，则判定故障的第二故障类型信息为“配置文件版本正常”；如果线上配置文件版本为本地DNS配置文件列表中的非最新版本(即低于DNS配置文件列表中的最新版本)，则判定故障的第二故障类型信息为“配置文件版本异常”，优选的，还可以在该第二故障类型信息中添加最新配置文件版本号。
4)分析监控数据中应答为NXDOMAIN的部分，根据监控时间和DNS配置文件列表，确定第一次发生故障前的DNS配置文件版本。
5)故障定性模块发送故障类型信息给故障处理模块，故障类型信息包括：
权威DNS服务器IP，探测域名，zone，第一故障类型信息，第二故障类型信息，，故障前DNS配置文件版本。
6、故障处理模块接收故障定性模块发送的故障类型信息。
故障处理模块分析故障类型信息，并根据故障类型信息内容，进行故障隔离、故障快速处理、故障恢复的自动处理工作。
7、故障处理模块的故障处理过程如下：
1)故障隔离程序进行故障操作，如果第一故障类型信息为“单台故障”，进行故障对应权威DNS服务器的iptables 53端口封禁操作，停止故障设备的服务，并跳过故障快速处理逻辑，直接执行故障恢复程序。
如果故障类型为“全平台故障”，则进行故障对应权威DNS服务器IP的请求包透传工作，修改iptables策略将DNS模块收到的解析请求报文转发给故障处理模块的故障快速处理程序处理。
需要说明的是，iptables的端口封禁和请求数据包转发为其中一种实现方式，其目的是在发生小规模故障时，仅绕过不响应的故障权威DNS服务器，仍然能保证正常服务。在发生较大规模故障时，通过快速处理程序最大限度的保障部分解析功能，使故障恢复前对业务产生的不良影响最小化。本领域技术人员应当知晓，实际上还有其他的实现方式能够达到上述目的。
2)故障快速处理程序接收从DNS模块转发来的请求报文，使用预先缓存好的历史应答结果，对解析请求进行应答。如果缓存里的历史应答结果没有与请求域名匹配的任何结果，则直接丢弃请求报文。
3)故障快速处理程序缓存历史应答结果的方式主要包括以下三种：
方式一：为获取DNS模块的访问日志，从访问日志中提取“请求区域，域名，解析结果”字段，生成历史应答结果，并添加到缓存里，如果有新的“请求区域+域名”的访问日志，则使用新提取的字段覆盖原有的历史应答结果，进行数据更新。特殊的，当访问日志中的应答状态为NXDOMAIN时，则不进行缓存内容更新。
方式二：通过将DNS模块的应答包udpcopy到故障快速处理模块，进行缓存内容提取，以应答包作为历史应答结果添加到缓存中。
方式三：通过轮询扫描无故障权威服务器IP的解析结果，进行缓存内容提取。
4)故障快速处理程序处理完成后，故障恢复程序进行故障自动恢复工作。
步骤一：分析故障类型信息，如果配置文件版本异常，则直接向DNS模块触发一次配置文件更新和重新加载，加载完成后进行全网解析的本地轮询，如果故障恢复，则清除已有的防御策略，解除隔离；如果没有恢复则进行下一步。
如果配置文件版本正常，直接进行下一步。
步骤二：分析故障类型信息，重新给DNS模块下发并重新加载故障前DNS配置文件版本，加载完成后进行全网解析的本地轮询，如果故障恢复，则清除已有的防御策略，解除隔离；如果没有恢复则进行下一步。
步骤三：重启DNS模块进程，完成后进行全网解析的本地轮询，如果故障恢复，则清除已有的防御策略。
如果在重启后仍没有恢复，则退出故障处理程序，自动触发邮件、短信、电话告警给运营人员。
下面结合附图，对本发明的实施例二进行说明。
本发明实施例提供了一种DNS故障处理方法，使用该方法完成DNS中故障的自动处理的流程如图2所示，包括：
步骤201、为权威DNS服务器分配探测域名；
本步骤中，配置监控任务，为各个权威DNS服务器分配至少一个探测域名，通过向该权威DNS服务器请求该探测域名，对权威DNS服务器的工作状态进行检测。
步骤202、检测权威域名服务系统DNS服务器集群中各权威DNS服务器的工作状态。
本步骤具体包括：
1、向所述权威DNS服务器发送对所述探测域名进行解析的请求。
2、接收返回的状态信息，所述状态信息至少包含以下信息中的任一项或任意多项：
探测时间，应答状态，线上配置文件版本。
3、根据所述状态信息，生成监控数据，所述监控数据至少包含以下任一或任意多个字段：
探测时间，权威DNS服务器IP，探测域名，域zone，应答状态，线上配置文件版本，
其中，所述zone字段指示权威DNS服务器对应的解析域。
4、对所述监控数据进行分析，判定是否发生故障。
1)在不存在应答状态字段为NXDOMAIN的监控数据时，判定系统正常。
2)在存在应答状态字段为NXDOMAIN的监控数据时，首先需要统计涉及的故障权威DNS服务器数量，得到表明故障范围的第一故障类型信息。具体的，在故障的权威DNS服务器数量达到预置的故障类型定性阈值时，判定第一故障类型信息为“全平台故障类型”；在故障的权威DNS服务器数量没有达到预置的故障类型定性阈值时，判定第一故障类型信息为“单设备故障类型”。
3)进一步的，在获取第一故障类型信息后，还需要生成与配置文件版本相关的第二故障类型信息。提取应答状态字段为NXDOMAIN的监控数据中的线上配置文件版本字段，对比所述线上配置文件版本与本地DNS配置文件列表中的最新配置文件版本，得到表明配置文件版本状态的第二故障类型信息。
具体的，在所述线上配置文件版本为所述本地DNS配置文件列表中的最新版本时，判定第二故障类型信息为“配置文件版本正常”；在所述线上配置文件版本不是所述本地DNS配置文件列表中的最新版本时，判定第二故障类型信息为“配置文件版本异常”。
步骤203、在检测到发生故障时，根据故障规模，对故障的权威DNS服务器进行隔离处理。
本步骤具体包括两种处理在所述第一故障类型信息为“单设备故障类型”时，向故障的权威DNS服务器分别下发针对iptables 53端口的封禁指令，指示停止所述故障的权威DNS服务器的服务；
在第一故障类型信息为“全平台故障类型”时，暂停故障权威DNS服务器对域名解析请求的响应，根据之前缓存的历史应答结果响应归属于故障权威DNS服务器的域名解析请求。
本发明实施例中，在执行日常的解析任务时，会记录历史应答结果(可由运行于权威DNS服务器上的专用功能模块进行记录缓存)，保存在缓存中，并不断使用最新的解析结果对缓存内的历史应答结果进行更新。
具体的，可通过以下方式中的任一或任意多种获取历史应答结果，添加到缓存中：
方式一、获取访问日志，从所述访问日志中提取以下字段，添加到缓存：
请求区域，域名，解析结果，
使用上述字段构造历史应答结果，并添加到缓存中；
方式二、复制传输历史应答结果，并添加到缓存中；
方式三、轮询扫描正常工作的权威DNS服务器的IP地址返回的解析结果，作为历史应答结果添加到缓存中。
步骤204、对故障的权威DNS服务器进行故障恢复；
本步骤根据第二故障类型信息的不同，包含两种情况：
情况一、在所述第二故障类型信息为“配置文件版本异常”时，向故障权威DNS服务器下发最新版本的配置文件，指示权威DNS服务器加载接收到的配置文件。
之后通过全网轮询等手段进行检测，如故障已消除，则确定故障恢复完毕；否则，向故障的权威DNS服务器下发故障前版本的配置文件，指示权威DNS服务器加载接收到的配置文件。
然后，再通过全网轮询等手段进行检测，如故障已消除，则确定故障恢复完毕；否则，重新启动故障的权威DNS服务器进程(如重启权威DNS服务器上的DNS模块进程，对软件进行重启)。
情况二、在所述第二故障类型信息为“配置文件版本正常”时，向故障权威DNS服务器下发故障前版本的配置文件，指示权威DNS服务器加载接收到的配置文件。
之后通过全网轮询等手段进行检测，如故障已消除，则确定故障恢复完毕；否则，重新启动故障的权威DNS服务器进程。
步骤205、进行全网解析的本地轮询，检测故障是否已恢复。
本步骤中，根据最终的检测结果，如果故障已恢复，进入步骤206；否则，进入步骤207。
步骤206、在故障已恢复后，解除对所述故障的权威DNS服务器的隔离处理。
步骤207、在故障仍未恢复的情况下，发出告警。
下面结合附图，对本发明的实施例三进行说明。
本发明实施例提供了一种DNS故障处理系统，其架构如图3所示，包括：
故障检测模块301，用于检测权威域名服务系统DNS服务器集群中各权威DNS服务器的工作状态；
故障隔离模块302，用于在检测到发生故障时，根据故障规模，对故障的权威DNS服务器进行隔离处理。
优选的，该系统还包括：
配置管理模块303，用于为权威DNS服务器分配探测域名。
优选的，所述故障检测模块301的结构如图4所示，包括：
请求发起单元401，用于向所述权威DNS服务器发送对所述探测域名进行解析的请求；
信息收集单元402，用于接收返回的状态信息，所述状态信息至少包含以下信息中的任一项或任意多项：
探测时间，应答状态，线上配置文件版本；
监控数据生成单元403，用于根据所述状态信息，生成监控数据，所述监控数据至少包含以下任一或任意多个字段：
探测时间，权威DNS服务器IP，探测域名，域zone，应答状态，线上配置文件版本，
其中，所述zone字段指示权威DNS服务器对应的解析域；
故障分析单元404，用于对所述监控数据进行分析，判定是否发生故障。
优选的，所述故障分析单元404包括：
第一类型分析子单元4041，用于在存在应答状态字段为NXDOMAIN的监控数据时，统计涉及的故障权威DNS服务器数量，得到表明故障范围的第一故障类型信息；
第二类型分析子单元4042，用于提取应答状态字段为NXDOMAIN的监控数据中的线上配置文件版本字段，对比所述线上配置文件版本与本地DNS配置文件列表中的最新配置文件版本，得到表明配置文件版本状态的第二故障类型信息。
优选的，所述第一类型分析子单元4041，具体用于：
在故障的权威DNS服务器数量达到预置的故障类型定性阈值时，判定第一故障类型信息为“全平台故障类型”，
在故障的权威DNS服务器数量没有达到预置的故障类型定性阈值时，判定第一故障类型信息为“单设备故障类型”。
优选的，所述故障隔离模块302的结构如图5所示，包括：
封禁单元501，用于在所述第一故障类型信息为“单设备故障类型”时，向故障的权威DNS服务器分别下发针对iptables 53端口的封禁指令，指示停止所述故障的权威DNS服务器的服务；
快速响应单元502，用于在第一故障类型信息为“全平台故障类型”时，暂停故障权威DNS服务器对域名解析请求的响应，根据之前缓存的历史应答结果响应归属于故障权威DNS服务器的域名解析请求。
优选的，该系统还包括：
应急缓存模块304，用于通过以下方式中的任一或任意多种获取历史应答结果，添加到缓存中：
方式一、获取访问日志，从所述访问日志中提取以下字段，添加到缓存：
请求区域，域名，解析结果，
使用上述字段构造历史应答结果，并添加到缓存中；
方式二、复制传输历史应答结果，并添加到缓存中；
方式三、轮询扫描正常工作的权威DNS服务器的IP地址返回的解析结果，作为历史应答结果添加到缓存中。
优选的，所述第二类型分析子单元4042，具体用于：
在所述线上配置文件版本为所述本地DNS配置文件列表中的最新版本时，判定第二故障类型信息为“配置文件版本正常”，
在所述线上配置文件版本不是所述本地DNS配置文件列表中的最新版本时，判定第二故障类型信息为“配置文件版本异常”。
优选的，该系统还包括：
第一故障恢复模块305，用于在所述第二故障类型信息为“配置文件版本异常”时，向故障权威DNS服务器下发最新版本或故障发生前版本的的配置文件，指示权威DNS服务器加载接收到的配置文件；
第二故障恢复模块306，用于在所述第二故障类型信息为“配置文件版本正常”时，向故障权威DNS服务器下发故障前版本的配置文件，指示权威DNS服务器加载接收到的配置文件。
优选的，所述故障检测模块301，还用于在所述第一故障恢复模块305在向故障权威DNS服务器下发最新版本或故障发生前版本的的配置文件后，进行全网解析的本地轮询，检测故障是否已恢复；
所述第一故障恢复模块305，还用于在检测结果为故障未恢复时，向故障权威DNS服务器下发故障前版本的配置文件，指示权威DNS服务器加载接收到的配置文件。
优选的，所述第一故障恢复模块305，还用于在加载故障前版本的配置文件失败后，重启故障的权威DNS服务器进程；
所述第二故障恢复模块306，还用于在加载故障前版本的配置文件失败后，重启故障的权威DNS服务器进程。
优选的，所述故障检测模块301，还用于在所述第一故障恢复模块305或所述第二故障恢复模块306处理完成后，进行全网解析的本地轮询，检测故障是否已恢复；
所述故障隔离模块302，还用于在故障已恢复后，解除对所述故障的权威DNS服务器的隔离处理。
本发明的实施例提供了一种域名服务系统故障处理方法和系统，检测权威域名服务系统DNS服务器集群中各权威DNS服务器的工作状态，在检测到发生故障时，根据故障规模，对故障的权威DNS服务器进行隔离处理。进一步的，还可以进行故障的处理恢复。由系统自动完成对故障的发现、处理、恢复，解决了现有故障处理方式大幅降低网络访问效率的问题，实现了快速有效的DNS解析故障响应。能够第一时间自动处理异常NXDOMAIN故障，防止故障影响扩大；提供判定NXDOMAIN故障规模的方法，针对不同故障规模选择不同的自动处理方法；故障处理分层次进行，分为故障隔离、故障快速处理和故障恢复三个阶段，确保故障处理过程最高效，故障对业务影响最低。避免了直接进行故障恢复造成故障影响范围的扩大；提高NXDOMAIN故障修复能力，故障消除时间降低90％。
上面描述的内容可以单独地或者以各种方式组合起来实施，而这些变型方式都在本发明的保护范围之内。
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制。尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (22)

1.一种域名服务系统故障处理方法，其特征在于，包括：
检测权威域名服务系统DNS服务器集群中各权威DNS服务器的工作状态；
在检测到发生故障时，根据故障规模，对故障的权威DNS服务器进行隔离处理；
所述故障规模为单设备故障类型时，停止故障的权威DNS服务器的服务；
所述故障规模为全平台故障类型时，暂停故障权威DNS服务器对域名解析请求的响应。
2.根据权利要求1所述的域名服务系统故障处理方法，其特征在于，该方法还包括：
为权威DNS服务器分配探测域名。
3.根据权利要求2所述的域名服务系统故障处理方法，其特征在于，所述检测权威DNS服务器集群中各权威DNS服务器的工作状态的步骤包括：
向所述权威DNS服务器发送对所述探测域名进行解析的请求；
接收返回的状态信息，所述状态信息至少包含以下信息中的任一项或任意多项：
探测时间，应答状态，线上配置文件版本；
根据所述状态信息，生成监控数据，所述监控数据至少包含以下任一或任意多个字段：
探测时间，权威DNS服务器IP，探测域名，域zone，应答状态，线上配置文件版本，
其中，所述zone字段指示权威DNS服务器对应的解析域；
对所述监控数据进行分析，判定是否发生故障。
4.根据权利要求3所述的域名服务系统故障处理方法，其特征在于，对所述监控数据进行分析，判定是否发生故障的步骤包括：
在存在应答状态字段为NXDOMAIN的监控数据时，统计涉及的故障权威DNS服务器数量，得到表明故障范围的第一故障类型信息；
提取应答状态字段为NXDOMAIN的监控数据中的线上配置文件版本字段，对比所述线上配置文件版本与本地DNS配置文件列表中的最新配置文件版本，得到表明配置文件版本状态的第二故障类型信息。
5.根据权利要求4所述的域名服务系统故障处理方法，其特征在于，在存在应答状态字段为NXDOMAIN的监控数据时，统计涉及的故障权威DNS服务器数量，得到表明故障范围的第一故障类型信息的步骤包括：
在故障的权威DNS服务器数量达到预置的故障类型定性阈值时，判定第一故障类型信息为“全平台故障类型”；
在故障的权威DNS服务器数量没有达到预置的故障类型定性阈值时，判定第一故障类型信息为“单设备故障类型”。
6.根据权利要求5所述的域名服务系统故障处理方法，其特征在于，在检测到发生故障时，根据故障规模，对故障的权威DNS服务器进行隔离处理的步骤包括：
在所述第一故障类型信息为“单设备故障类型”时，向故障的权威DNS服务器分别下发针对iptables 53端口的封禁指令，指示停止所述故障的权威DNS服务器的服务；
在第一故障类型信息为“全平台故障类型”时，暂停故障权威DNS服务器对域名解析请求的响应，根据之前缓存的历史应答结果响应归属于故障权威DNS服务器的域名解析请求。
7.根据权利要求6所述的域名服务系统故障处理方法，其特征在于，该方法还包括：
通过以下方式中的任一或任意多种获取历史应答结果，添加到缓存中：
方式一、获取访问日志，从所述访问日志中提取以下字段，添加到缓存：
请求区域，域名，解析结果，
使用上述字段构造历史应答结果，并添加到缓存中；
方式二、复制传输历史应答结果，并添加到缓存中；
方式三、轮询扫描正常工作的权威DNS服务器的IP地址返回的解析结果，作为历史应答结果添加到缓存中。
8.根据权利要求4所述的域名服务系统故障处理方法，其特征在于，提取应答状态字段为NXDOMAIN的监控数据中的线上配置文件版本字段，对比线上配置文件版本与本地DNS配置文件列表中的最新配置文件版本，得到表明配置文件版本状态的第二故障类型信息的步骤包括：
在所述线上配置文件版本为所述本地DNS配置文件列表中的最新版本时，判定第二故障类型信息为“配置文件版本正常”；
在所述线上配置文件版本不是所述本地DNS配置文件列表中的最新版本时，判定第二故障类型信息为“配置文件版本异常”。
9.根据权利要求8所述的域名服务系统故障处理方法，其特征在于，在检测到发生故障时，根据故障规模，对故障的权威DNS服务器进行隔离处理的步骤之后，还包括：
在所述第二故障类型信息为“配置文件版本异常”时，向故障权威DNS服务器下发最新版本的配置文件，指示权威DNS服务器加载接收到的配置文件；
在所述第二故障类型信息为“配置文件版本正常”时，向故障权威DNS服务器下发故障前版本的配置文件，指示权威DNS服务器加载接收到的配置文件。
10.根据权利要求9所述的域名服务系统故障处理方法，其特征在于，在所述第二故障类型信息为“配置文件版本异常”时，向故障权威DNS服务器下发最新版本的配置文件的步骤之后还包括：
在向故障权威DNS服务器下发最新版本的配置文件后，进行全网解析的本地轮询，检测故障是否已恢复，在检测结果为故障未恢复时，向故障权威DNS服务器下发故障前版本的配置文件，指示权威DNS服务器加载接收到的配置文件。
11.根据权利要求10所述的域名服务系统故障处理方法，其特征在于，在所述进行故障恢复处理的步骤之后，还包括：
进行全网解析的本地轮询，检测故障是否已恢复；
在故障已恢复后，解除对所述故障的权威DNS服务器的隔离处理。
12.一种域名服务系统故障处理系统，其特征在于，包括：
故障检测模块，用于检测权威域名服务系统DNS服务器集群中各权威DNS服务器的工作状态；
故障隔离模块，用于在检测到发生故障时，根据故障规模，对故障的权威DNS服务器进行隔离处理；
故障隔离模块，还用于所述故障规模为单设备故障类型时，停止故障的权威DNS服务器的服务；
所述故障规模为全平台故障类型时，暂停故障权威DNS服务器对域名解析请求的响应。
13.根据权利要求12所述的域名服务系统故障处理系统，其特征在于，该系统还包括：
配置管理模块，用于为权威DNS服务器分配探测域名。
14.根据权利要求13所述的域名服务系统故障处理系统，其特征在于，所述故障检测模块包括：
请求发起单元，用于向所述权威DNS服务器发送对所述探测域名进行解析的请求；
信息收集单元，用于接收返回的状态信息，所述状态信息至少包含以下信息中的任一项或任意多项：
探测时间，应答状态，线上配置文件版本；
监控数据生成单元，用于根据所述状态信息，生成监控数据，所述监控数据至少包含以下任一或任意多个字段：
探测时间，权威DNS服务器IP，探测域名，域zone，应答状态，线上配置文件版本，
其中，所述zone字段指示权威DNS服务器对应的解析域；
故障分析单元，用于对所述监控数据进行分析，判定是否发生故障。
15.根据权利要求14所述的域名服务系统故障处理系统，其特征在于，所述故障分析单元包括：
第一类型分析子单元，用于在存在应答状态字段为NXDOMAIN的监控数据时，统计涉及的故障权威DNS服务器数量，得到表明故障范围的第一故障类型信息；
第二类型分析子单元，用于提取应答状态字段为NXDOMAIN的监控数据中的线上配置文件版本字段，对比所述线上配置文件版本与本地DNS配置文件列表中的最新配置文件版本，得到表明配置文件版本状态的第二故障类型信息。
16.根据权利要求15所述的域名服务系统故障处理系统，其特征在于，所述第一类型分析子单元，具体用于：
在故障的权威DNS服务器数量达到预置的故障类型定性阈值时，判定第一故障类型信息为“全平台故障类型”，
在故障的权威DNS服务器数量没有达到预置的故障类型定性阈值时，判定第一故障类型信息为“单设备故障类型”。
17.根据权利要求16所述的域名服务系统故障处理系统，其特征在于，所述故障隔离模块包括：
封禁单元，用于在所述第一故障类型信息为“单设备故障类型”时，向故障的权威DNS服务器分别下发针对iptables 53端口的封禁指令，指示停止所述故障的权威DNS服务器的服务；
快速响应单元，用于在第一故障类型信息为“全平台故障类型”时，暂停故障权威DNS服务器对域名解析请求的响应，根据之前缓存的历史应答结果响应归属于故障权威DNS服务器的域名解析请求。
18.根据权利要求17所述的域名服务系统故障处理系统，其特征在于，该系统还包括：
应急缓存模块，用于通过以下方式中的任一或任意多种获取历史应答结果，添加到缓存中：
方式一、获取访问日志，从所述访问日志中提取以下字段，添加到缓存：
请求区域，域名，解析结果，
使用上述字段构造历史应答结果，并添加到缓存中；
方式二、复制传输历史应答结果，并添加到缓存中；
方式三、轮询扫描正常工作的权威DNS服务器的IP地址返回的解析结果，作为历史应答结果添加到缓存中。
19.根据权利要求15所述的域名服务系统故障处理系统，其特征在于，所述第二类型分析子单元，具体用于：
在所述线上配置文件版本为所述本地DNS配置文件列表中的最新版本时，判定第二故障类型信息为“配置文件版本正常”，
在所述线上配置文件版本不是所述本地DNS配置文件列表中的最新版本时，判定第二故障类型信息为“配置文件版本异常”。
20.根据权利要求19所述的域名服务系统故障处理系统，其特征在于，该系统还包括：
第一故障恢复模块，用于在所述第二故障类型信息为“配置文件版本异常”时，向故障权威DNS服务器下发最新版本或故障发生前版本的的配置文件，指示权威DNS服务器加载接收到的配置文件；
第二故障恢复模块，用于在所述第二故障类型信息为“配置文件版本正常”时，向故障权威DNS服务器下发故障前版本的配置文件，指示权威DNS服务器加载接收到的配置文件。
21.根据权利要求20所述的域名服务系统故障处理系统，其特征在于，
所述故障检测模块，还用于在所述第一故障恢复模块在向故障权威DNS服务器下发最新版本或故障发生前版本的的配置文件后，进行全网解析的本地轮询，检测故障是否已恢复；
所述第一故障恢复模块，还用于在检测结果为故障未恢复时，向故障权威DNS服务器下发故障前版本的配置文件，指示权威DNS服务器加载接收到的配置文件。
22.根据权利要求21所述的域名服务系统故障处理系统，其特征在于，
所述故障检测模块，还用于在所述第一故障恢复模块或所述第二故障恢复模块处理完成后，进行全网解析的本地轮询，检测故障是否已恢复；
所述故障隔离模块，还用于在故障已恢复后，解除对所述故障的权威DNS服务器的隔离处理。
CN201710389043.7A 2017-05-26 2017-05-26 一种域名服务系统故障处理方法和系统 Active CN108933693B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710389043.7A CN108933693B (zh) 2017-05-26 2017-05-26 一种域名服务系统故障处理方法和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710389043.7A CN108933693B (zh) 2017-05-26 2017-05-26 一种域名服务系统故障处理方法和系统

Publications (2)

Publication Number Publication Date
CN108933693A CN108933693A (zh) 2018-12-04
CN108933693B true CN108933693B (zh) 2021-06-22

Family

ID=64450634

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710389043.7A Active CN108933693B (zh) 2017-05-26 2017-05-26 一种域名服务系统故障处理方法和系统

Country Status (1)

Country Link
CN (1) CN108933693B (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109218050B (zh) * 2017-06-30 2021-07-13 贵州白山云科技股份有限公司 一种域名系统故障处理方法和系统
CN110149421B (zh) * 2019-05-30 2021-11-26 世纪龙信息网络有限责任公司 域名系统的异常监测方法、系统、装置和计算机设备
CN110691234B (zh) * 2019-09-09 2021-09-10 北京达佳互联信息技术有限公司 故障处理方法、装置、服务器及存储介质
TWI738253B (zh) * 2020-03-18 2021-09-01 華南商業銀行股份有限公司 網域名稱系統服務之客戶端連線方法
CN113905017B (zh) * 2021-10-14 2023-03-24 牙木科技股份有限公司 域名解析缓存方法、dns服务器及计算机可读存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103546590A (zh) * 2013-10-18 2014-01-29 北京奇虎科技有限公司 一种dns服务器的选择方法与装置
CN105391818A (zh) * 2015-11-26 2016-03-09 中国互联网络信息中心 一种基于递归服务器的权威域名应急解析系统及方法
CN106571981A (zh) * 2016-11-15 2017-04-19 中国互联网络信息中心 一种dns服务器自动化测试方法与系统
CN106657050A (zh) * 2016-12-15 2017-05-10 迈普通信技术股份有限公司 一种域名解析异常检测方法、探测管理服务器及网关设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103546590A (zh) * 2013-10-18 2014-01-29 北京奇虎科技有限公司 一种dns服务器的选择方法与装置
CN105391818A (zh) * 2015-11-26 2016-03-09 中国互联网络信息中心 一种基于递归服务器的权威域名应急解析系统及方法
CN106571981A (zh) * 2016-11-15 2017-04-19 中国互联网络信息中心 一种dns服务器自动化测试方法与系统
CN106657050A (zh) * 2016-12-15 2017-05-10 迈普通信技术股份有限公司 一种域名解析异常检测方法、探测管理服务器及网关设备

Also Published As

Publication number Publication date
CN108933693A (zh) 2018-12-04

Similar Documents

Publication Publication Date Title
CN108933693B (zh) 一种域名服务系统故障处理方法和系统
CN106789306B (zh) 通信设备软件故障检测收集恢复方法和系统
CN107544839B (zh) 虚拟机迁移系统、方法及装置
US20020194319A1 (en) Automated operations and service monitoring system for distributed computer networks
JP2008217735A (ja) 障害解析システム、方法、及び、プログラム
WO2018214928A1 (zh) 一种定位解析故障的方法和装置及其计算机可读存储介质和计算机设备
JP5342082B1 (ja) ネットワーク障害解析システムおよびネットワーク障害解析プログラム
CN113347037B (zh) 一种数据中心访问方法及装置
CN108429656A (zh) 一种监控物理机网卡连接状态的方法
CN114363151A (zh) 故障检测方法和装置、电子设备和存储介质
CN112583648A (zh) 一种基于dns的智能服务故障处理方法
CN109218050B (zh) 一种域名系统故障处理方法和系统
CN107769957B (zh) 一种域名系统故障原因分析方法和装置
CN107453888B (zh) 高可用性的虚拟机集群的管理方法及装置
CN112615848B (zh) 漏洞修复状态检测方法及系统
CN103731315A (zh) 一种服务器故障检测方法
CN115712521A (zh) 一种集群节点故障处理方法、系统及介质
US20060248531A1 (en) Information processing device, information processing method and computer-readable medium having information processing program
KR100887874B1 (ko) 인터넷 망의 장애 관리 시스템 및 그 방법
CN112486750A (zh) 主机故障处理方法、装置、控制系统及存储介质
CN107864057B (zh) 一种基于联网状态的联机自动检查及告警方法
CN112202712A (zh) 云防护领域中基于分布式健康状态检测的业务恢复方法
CN111224841B (zh) 一种政务云平台网站应用的运维方法和系统
JP4286594B2 (ja) 障害解析データ採取装置およびその方法
CN110225543B (zh) 基于网络请求数据的移动端软件质量态势感知系统及方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
CB02 Change of applicant information
CB02 Change of applicant information

Address after: 550003 Building No. 12 in the Southern Park of Gui'an High-end Equipment Industrial Park, Guizhou Province

Applicant after: Guizhou Baishan cloud Polytron Technologies Inc

Address before: 100015 5 floor, block E, 201 IT tower, electronic city, 10 Jiuxianqiao Road, Chaoyang District, Beijing.

Applicant before: Guizhou white cloud Technology Co., Ltd.

SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant