CN104639366A - Dns灾备系统孤岛应答自动切换方法及装置 - Google Patents

Abstract

本发明涉及一种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服务的机群的运行数据。

进一步，所述判定单元，包括：

指标建立模块，用于建立作为判定基准的指标数据集；

算法生成模块，用于依据预设的配置信息，选定或生成相应的算法；

运算判定模块，被配置为以指标数据集为基准，利用所述的算法对所述的运行数据进行运算，判定运行数据所表征的运行状态是否异常。

进一步，本装置还包括第一设定单元，用于提供用户界面以供设定所述网络地址。

具体的，所述配置信息包含有一个或多个不同遵守相同格式的策略配置信息。

较佳的，不同组策略配置信息作用下，参与运算的所述运行数据与所述指标数据集均不同于其他组策略配置信息作用下所涉的运行数据和指标数据集。

进一步，本装置还包括第二设定单元，用于提供用户界面以供设定所述策略配置信息、算法、指标数据集中的一种或任意多种数据。

相较于现有技术，本发明至少具有如下优点：

1、本发明在实现了DNS服务系统的灾备系统的构建的基础上，能够结合机器学习技术，智能化地对提供DNS服务的机群的运行状态做出及时的判定并做出响应，因此可以在常规的DNS服务系统发生故障或者遭受攻击时，快速地转向由灾备系统提供临时而且准确的DNS解析服务，构建了孤岛应答模式，利用灾备系统为互联网用户提供DNS解析服务。

2、本发明适宜在DNS服务器上实现，因此使得灾备系统通常并不直接对客户端暴露，而是以DNS解析服务器为前端服务窗口，由DNS解析服务器将用户的域名解析请求转发给本灾备系统，并且通过将针对该请求的域名解析结果经由该DNS解析服务器中转应答该请求，可以更有效地保护灾备系统，使灾备系统能够更顺畅地为互联网用户提供DNS解析服务。

概括而言，本发明能够快速识别传统的DNS服务机群的运行状态，实现传统的DNS服务网络与其灾备系统网络之间的智能快速地切换，在现有的域名服务系统或其所依赖的网络瘫痪时，可以利用灾备系统构建孤岛应答模式，确保互联网用户的使用有效的域名解析服务，使互联网更为安全。

本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1是本发明的域名解析系统灾备建构方法的流程示意图；

图2是传统的DNS解析服务原理示意图；

图3是本发明的域名解析系统灾备建构装置的原理框图；

图4是本发明的DNS灾备系统孤岛应答自动切换方法的流程示意图；

图5是本发明的DNS灾备系统孤岛应答自动切换方法的步骤S22的的流程示意图；

图6是本发明的DNS灾备系统孤岛应答自动切换装置的原理框图；

图7是本发明的DNS灾备系统孤岛应答自动切换装置的判定单元的原理框图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

本技术领域技术人员可以理解，这里所使用的“终端”、“终端设备”既包括无线信号接收器的设备，其仅具备无发射能力的无线信号接收器的设备，又包括接收和发射硬件的设备，其具有能够在双向通信链路上，执行双向通信的接收和发射硬件的设备。这种设备可以包括：蜂窝或其他通信设备，其具有单线路显示器或多线路显示器或没有多线路显示器的蜂窝或其他通信设备；PCS(Personal Communications Service，个人通信系统)，其可以组合语音、数据处理、传真和/或数据通信能力；PDA(PersonalDigital Assistant，个人数字助理)，其可以包括射频接收器、寻呼机、互联网/内联网访问、网络浏览器、记事本、日历和/或GPS(Global PositioningSystem，全球定位系统)接收器；常规膝上型和/或掌上型计算机或其他设备，其具有和/或包括射频接收器的常规膝上型和/或掌上型计算机或其他设备。这里所使用的“终端”、“终端设备”可以是便携式、可运输、安装在交通工具(航空、海运和/或陆地)中的，或者适合于和/或配置为在本地运行，和/或以分布形式，运行在地球和/或空间的任何其他位置运行。这里所使用的“终端”、“终端设备”还可以是通信终端、上网终端、音乐/视频播放终端，例如可以是PDA、MID(Mobile Internet Device，移动互联网设备)和/或具有音乐/视频播放功能的移动电话，也可以是智能电视、机顶盒等设备。

本技术领域技术人员可以理解，这里所使用的服务器、云端、远端网络设备等概念，具有等同效果，其包括但不限于计算机、网络主机、单个网络服务器、多个网络服务器集或多个服务器构成的云。在此，云由基于云计算(Cloud Computing)的大量计算机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。本发明的实施例中，远端网络设备、终端设备与WNS服务器之间可通过任何通信方式实现通信，包括但不限于，基于3GPP、LTE、WIMAX的移动通信、基于TCP/IP、UDP协议的计算机网络通信以及基于蓝牙、红外传输标准的近距无线传输方式。

本领域技术人员应当理解，本发明所称的“应用”、“应用程序”、“应用软件”以及类似表述的概念，是业内技术人员所公知的相同概念，是指由一系列计算机指令及相关数据资源有机构造的适于电子运行的计算机软件。除非特别指定，这种命名本身不受编程语言种类、级别，也不受其赖以运行的操作系统或平台所限制。理所当然地，此类概念也不受任何形式的终端所限制。

本文即将揭示的涉及本发明的相关技术方案，包括两个方面，第一方面是如何实现灾备系统的构建的服务开放，第二方面是如何实现灾害识别从而确保在正常DNS服务系统及其灾备系统之间实现有效、及时、智能地切换，藉此两方面的披露，将有助于本领域技术人员更为系统地理解本发明。

有关本发明的相关技术方案的第一个方面，即提供一种域名解析系统建构方法和装置，其中的装置是依据模块化思维对其中的方法的实例化，可以通过编程的方式将所述的方法和装置实现为软件，安装到计算机设备中特别是专用的具有服务器能力的计算机设备中进行运行，接入互联网开放其服务，而构造出一台本地DNS解析服务器，或者构造出实现本地DNS解析服务器的机群，用于为客户端提供DNS域名解析服务，以便应答客户端。

请参阅图1，本发明的域名解析系统灾备建构方法，实现为一个或多个可以安装于诸如Windows系列操作系统(包括但不限于Windows XP,Window 7,Windows 8的系列版本等)或者Unix系列操作系统(包括但不限于Unix、Linux、IOS、Ubuntu等)的软件，由该软件的运行，而实现相应的具体步骤。具体包括如下步骤：

步骤S11，将提供DNS服务的目标机群的数据实时同步至灾备机群，所述数据中包含有用于提供域名解析基础的缓存数据。

通常，提供DNS服务的服务器，类似于云端架构，由多台服务器设备有机建构形成机群，与DNS解析服务器相互配置，实现DNS解析服务。其中，DNS服务机群主要用于实现递归系统，通过该递归系统向互联网中的对于于域名各层级的服务器递归调用以解析相应的域名，获取IP地址，以构造域名解析结果，以响应于外部请求。而DNS解析服务器作为前端应用窗口，负责接收发起请求的客户端的域名解析请求，并且将该请求提供给机群，要求机群作出域名解析结果回应，然后以相应的域名解析结果应答相应的域名解析请求。

本发明所构建的灾备系统，既是对互联网整个域名系统的灾备，又是基于对多个本地DNS服务器的相关机群的灾备而实现的。灾备系统的实现，以数据同步为基础；以故障检测为其切换运行的前提；以切换控制为管理逻辑。但灾备系统可以实时开放，其故障检测及后续的切换控制可由第三方来实现，因此本本发明的第一方面并不涉及有关故障检测和切换控制的技术。

数据同步是本发明实现DNS服务系统的灾备的关键基础。实现数据同步管理逻辑，通常采用数据备份手段。数据备份是系统、数据容灾的基础，也是低端容灾的实现，是高端容灾(实时数据保护)的有力保障。目前备份技术主要有快照备份、离线备份、异地存储备份。备份系统通过备份策略，对计算机信息系统的操作系统、文件系统、应用程序、数据库系统等数据集，实现某一时间点的完整拷贝，拷贝的数据处在非在线状态，不能被立刻访问，必须通过相应操作，如恢复等方式使用备份数据。在建设高端容灾系统的前提，一定要做好本地系统的备份，这是容灾技术的起点。

本发明实现数据同步时，采用高端容灾方式，以实现对DNS服务机群的实时数据保护，具体而言，就是在多块磁盘上、多个阵列、多台服务器、多个数据中心实时地保存同一份数据的多份存储，目的是为了避免物理故障。实时数据保护需要以数据备份作为前提，它不能防范人为误操作和恶性操作。需要强调的是，容灾的目的是让数据在灾难发生时，还能被访问，通过实时数据保护，保证数据的完整性，因此，本发明所建构的容灾系统并不能保证数据的最新。

如前所述，数据备份是容灾的手段，不是目的，容灾的目的是数据的访问，因此应用的恢复和网络的恢复以及相关的切换控制，也是容灾的关键。具体而言，就是在灾难发生后，数据库切换、应用重新启动、网络实现切换等等，容灾中心接管原生产中心的整个过程；同时还包含了在原数据中心修复后，数据库、应用、网络需要重新切回来的整个过程。这些过程，可以通过手工切换、也可以通过自动化过程完成；并且，如何据此而做出相应的评估，也是技术人员需要解决的问题。本发明后续将通过另一方法和装置对该部分的实现进行详细的揭示，因此暂按不表。

由此可知，通过配置为本发明的方法的软件将提供DNS服务的目标机群的数据实时同步至灾备机群，便成就了本发明容灾系统的实现基础。为了进一步说明被同步的所述的数据，如下请先参阅一应用实例。

请结合图2，如下以网易门户地址www.163.com这一域名的解析过程为例，说明正常情况下的DNS解析的主要过程：

步骤1：用户电脑向其系统上设置的本地DNS(解析)服务器发送解析www.163.com的请求。所谓本地DNS服务器是指一个DNS服务IP地址，可以是从运营商自动获取的，也可以是手动设置。

步骤2：本地DNS服务器会在自己的空间里查看是否有这个域名的缓存，如果没有，就会向根服务器发送www.163.com的域名解析请求。

步骤3：根服务器接收到本地DNS服务器关于域名的解析请求后，分析请求的域名，返回给本地服务器.com这个域名节点的服务器的IP地址。

步骤4：本地DNS服务器在接到.com顶级域的服务器IP地址后，向.com顶级域发出查询www.163.com的解析请求。

步骤5：.com顶级域服务器在接收到关于www.163.com的解析请求后，返回给本地DNS服务器关于163这个二级域的DNS服务器的IP地址。

步骤6：本地DNS服务器继续向163这个二级域的DNS服务器发起关于www.163.com的解析请求。

步骤7：163这个域的管理服务器管理163.com下的所有的子域名。它的域名空间中有www这个子域名，其对应的IP地址为111.1.53.220，因此163.com域的DNS服务器会返回www.163.com对应的IP地址111.1.53.220给本地DNS服务器。

步骤8：本地DNS服务器接收到163.com这个域服务器关于www.163.com解析结果后，返回给用户对应的IP地址111.1.53.220，同时会将这个结果保留一段时间，以备其他用户的查询。

步骤9：用户电脑在获得www.163.com域名对应的IP地址111.1.53.220后，就开始向111.1.53.220这个IP请求网页内容。至此，DNS的一个完整请求解析流程结束。

上述的示例中，本地DNS服务器被简化为一台服务器，实际上，通常情况下，其后台可能由多台服务器共同构成的前述的机群所实现。DNS解析服务器，无论何种情况，都需要充当应用前端的DNS服务器。本领域技术人员对此应当知晓。

上述的示例中，步骤2会首先在本地DNS服务器的空间中查看是否有域名解析请求中的域名的请求，而步骤8中则介绍了会将域名解析结果保存一段时间以备其他用户查询的事实。由此可以知晓，目标机群的数据中，必然包含一些缓存数据，这些缓存数据通常以日志类型的格式进行存储，在本发明中也可以以数据库的形式加以改进。

本发明有关缓存数据的实现的一个实施例中，可以沿用正常提供DNS服务的服务机群的格式，使所述缓存数据包括历史域名解析记录，所述历史域名解析记录为所述目标机群正常执行DNS服务过程中进行DNS解析而产生的DNS域名解析记录，通常是以日志文件的格式存储的。每条域名解析记录均至少包括有域名、与域名相应的IP地址，这里的域名与IP地址之间的相应性，主要是指它们彼此之间映射关系。进一步，可以为缓存数据库中的每条域名解析记录赋予一个生命周期，在该生命周期内，该记录有效，超过该生命周期，则可由本发明予以删除或者忽略。本发明在需要使用该缓存数据库用于解析域名时，优先依据请求数据中的域名，从历史域名解析记录中检索所述的缓存数据库，找到相应的有效的记录，获得相应的IP地址，然后应答相应的域名解析请求。当然，如果超过所述的生命周期，或者缓存数据中不存在相应的记录，则仍需通过递归系统来实现查询(如果启用灾备系统时公网上的各层级域名服务器仍能正常访问的话)。由于同一个终端设备一般由同一用户使用，其上网行为表现出一定的惯性，惯于访问部分特定网站，因此，通过这一缓存数据及其相关技术，可以为用户提高更高效更快速的DNS解析服务，并且可以节省一些移动终端设备的流量消耗，对于域名各层级服务器已经瘫痪导致无法递归查询的情况而言，这些缓存数据将发挥至关重要的解析作用。

本发明有关缓存数据的实现的另一实施例中，所述缓存数据包括一授权信息数据库，这一数据库可以使用公知的Anycast(任播)技术分布进行构建。所述授权信息数据库存储有域名各层级的授权服务器的授权信息；可以在进行域名解析时，依照授权信息数据库所记录的相应的授权服务器信息，执行递归查询以获得所述的域名解析结果，适用于作为DNS递归查询机群瘫痪的场景使用。

所述的授权信息数据库也是利用所述的历史域名解析记录为基础进行构建的。众所周知的，域名服务机群在执行递归查询的过程中，能获得域名各层级相对应的授权服务器的授权信息，利用这些授权信息便可构造所述的授权信息数据库，用于实现虚拟根节点，向互联网开放虚拟根节点服务，实现更为系统的灾备解析效果。在这种情况下，依据本发明所实备系统，还可以结合虚拟根节点技术提供安全服务，当根节点出现DNS解析故障时，虚拟根节点能够代替根节点实现DNS解析功能。当然，授权信息数据库中必须存储有足够的信息，即，授权信息数据库中存储指定区域内的所有DNS请求及对应的授权信息，这样虚拟根节点才能够有足够的资源对DNS请求进行应答。因此，虚拟根节点的实现是在授权信息数据库的基础上实现的。结合新增的授权信息数据库以及虚拟根节点，能够在根节点解析故障的时候为客户端提供DNS解析功能，能够降低DNS单点故障和提高DNS防御攻击能力，同时还可以对虚拟根节点设置访问权限控制，屏蔽DNS的攻击数据，提高DNS解析的安全性及稳定性。对于危险DNS攻击，从授权信息数据库中查询不到具体的授权信息，则虚拟根节点不会为其提供解析服务等。

依据前述揭示的关于实现所述缓存数据的两种实施例以及其相应的扩展功能，本领域技术人员理应知晓，关于缓存数据的更多具体实现形式以及其扩充应用，是本领域技术人员可以根据本发明的需要而灵活实现的。例如，所述的缓存数据也可以理解为同时包括前述两个实施例中的历史域名解析记录与所述授权信息数据库，并且，不仅可以将所述历史域名解析记录作为临时缓存，还可以将所述历史域名解析记录作为具有更长生命周期的数据存储于授权信息数据库的相关独立数据表中，在临时缓存达到一定时间长度被高频率使用时，即可将临时缓存的历史域名解析记录转化为具有更长生命周期的历史域名解析记录存储于该数据表中，并且在后续进行域名解析时被作为查询对象优先于递归系统进行查询。

有关DNS服务机群的拓扑及其层次架构，以及灾备系统的拓扑及层次架构，可以由本领域技术人员根据公知的网络原理加以实现，本发明中更为关注两者之间的数据和控制关系，因此，涉及其拓扑与层次架构关系，恕不赘述。

如前所述，将DNS服务机群上的数据，尤其是其中的缓存数据同步到灾备机群之后，灾备机群即具备相应的解析能力，可以在后续步骤中进一步开放其解析服务。

步骤S12、接收域名解析请求，响应于该域名解析请求而利用所述缓存数据进行域名解析。

本发明灾备系统，由于其高效地利用了缓存数据，实现了虚拟根节点的功能，因此拥有独立的虚拟根节点。具体而言便是通过一个授权信息数据库起到虚拟根域的作用。当根域或顶级域服务器发生故障不能正常服务时，甚至当外部所有其他的授权服务器都出现故障时，本地DNS系统或许成为解析孤岛，这种情况下，理论上应当允许这种系统实现类似的灾备模式，启动灾备紧急应答模式，保障互联网在根域服务器或授权服务器修复之前基本正常运行，为系统抢修和恢复留下足够的时间。

借助本发明后续将揭示的切换方法，应用了本发明的相关技术方案的相关系统，在灾难发生后，相关的DNS服务功能将被切换到指向灾备中心，也即本发明所构建的灾备机群。然而，客户端需要重新访问容灾节点的服务，带来另外一个问题，网络如何切换。具体而言就是DNS服务器的本地应用访问路径(网络地址)如何由指向原生产中心改为指向容灾中心。在灾难修复后，又要反过来需要指向原生产中心。最简单得方法就是更改DNS解析服务器的IP映射关系，由原来的目的地址改为灾备系统的提供DNS服务的网络地址。在灾难发生前，IP地址映射为生产中心服务器；在灾难发生后，IP地址由映射为容灾中心得服务器；在灾难修复后，IP又映射为生产中心得服务器。

关于实现这种智能切换的细节将在本发明的第二个方面中详述，本发明的第一方面暂以能够实现这种智能切换为前提进行说明。在第一方面中，客户端将其域名解析请求转发给DNS解析服务器，DNS解析服务器将该域名解析请求转发给灾备系统的服务，由灾备系统的服务执行解析，向DNS解析服务器返回域名解析结果，再由DNS解析服务器将该域名解析结果应答原来被中转的域名解析请求。

因此，本发明的灾备系统，当其接收到DNS解析服务器转发来的域名解析请求后，将需要对其作为解析。其解析方案可以结合前述的多种变例灵活实现不同的解析机制，例如：

第一种解析机制中，对应于缓存数据仅仅包括历史域名解析记录的情况，则灾备系统可以从所述的域名解析请求中提取域名之后，优先从其存储的缓存数据的海量历史域名解析记录中检索是否存在与该域名相对应的记录，当存在时，则以该记录中与该域名存在映射关系的IP地址作为域名解析结果。当然，也可以考虑有关为历史域名解析记录设置生命周期的因素，对于超过预设的生命周期的历史域名解析记录不再考虑。但通常不推荐使用这一策略，因为如果灾备系统是基于公网瘫痪或者域名各层级服务器瘫痪的原因，可能已经无法通过公网向域名对应各层级的服务器进行递归查询获得实际的域名了，应用这一策略的意义也便不大了。考虑到域名各层级服务器可能还有效，只是DNS服务器的机群出现了故障，这种情况下，如果从缓存数据中不能获得IP地址，则可进一步由本发明的灾备系统执行递归查询，如果能够获得有效的解析，则同理可生成更为准确的域名解析结果。

第二种解析机制，对应于缓存数据包括授权信息数据库的情况。可以先由灾备系统从所述的域名解析请求中提取域名之后，优先利用授权信息执行查询，如果能获得有效的IP解析结果，则以此应答。如果授权信息数据库中包括有历史域名解析记录相应的数据表，则可以沿用第一种解析机制，先从该数据表中尝试获取结果，如果不能获得结果，再利用授权信息数据库中的授权信息进行查询；或者反之，先利用授权信息进行查询，查询不得再利用历史域名解析记录进行查询。

第三种解析机制，是对应于既有缓存数据中既有授权信息数据库，又有作为缓存数据的历史域名解析记录，且授权信息数据库中也有优选的历史域名解析记录的情况。这种情况下，也可以结合前述两种机制灵活运用。例如，先从缓存历史域名解析记录中查询，查询不得再从数据表的历史域名解析记录中查询，再查询不得便进一步利用授权信息进行查询；或者反之。

由以上的多种解析机制的分析可以看出，只要在前一步骤中利用缓存数据搭建了有效的存储表达体系，则在本步骤中便可以灵活地对之加以有效利用，最终获得相应的域名解析结果。

步骤S13、以域名解析结果应答所述的域名解析请求。

在前一步获得域名解析结果后，本步骤便可以将域名解析结果按照域名解析请求的转发方地址反馈给DNS解析服务器进行中转，由DNS解析服务器将域名解析结果应答原始的域名解析请求发起方，完成域名解析过程。

需要指出的是，本发明的灾备系统，可以不直接接收客户端发起的域名解析请求，也不直接向客户端应答域名解析结果，而是通过同一网络地址，主要是指IP地址所指向的DNS解析服务器来实现域名解析请求和域名解析结果的中转。由于灾备系统具有更高的安全要求，域名解析请求和域名解析结果在DNS解析服务器与灾备系统机群之间传输之前，可以先行加密，加密的方式多种多样，优先推荐公钥加密(非对称加密)的方式。

尽管以上说明的内容，是以灾备机群为主体来进行描述的，然而，依据本发明第一方面所实现的软件，却可以灵活安装于多台设备中。可以考虑以如下几种方式安全本发明第一方面的软件，以构成实现本发明第一方面的方法和装置的体系：

一种方式中，将本发明的各个步骤实现于同一软件中，并且安装于本发明的灾备机群的单独一台设备中，而灾备机群的其它设备则只需配备与该单独一台设备进行通信的客户端模块，以此形成类似于C/S架构的模式，来实现机群的集中控制。作为这种方式的变化实例，表现在运行层面，相应的软件可以运行单独一个服务进程或多个相配合的进程来执行本方法，单独一个服务进程相对便于理解，至于多个进程的情况，例如，可以将本发明的步骤S11实现为一个进程，而将步骤S12、S13实现为一个进程，两个进程分别独立工作，完成各自的任务。两个进程均可设置为系统服务进程。

另一种方式，考虑到步骤S11与其余两个步骤的相互独立性，可以考虑将步骤S11的数据同步功能实现成单独一个软件安装于独立于灾备机群的一台独立设备中，例如所述的DNS(解析)服务器中，而其余两个步骤仍然实现为同一软件安装于灾备机群的一台前端服务设备中，两者分装于两台设备中，并行不悖又互相配合，同理也可满足本发明的需求。

因此，可以知晓，涉及本发明应用过程中系统搭建和软件实现方面的知识，可以结合本领域的公知技术进行灵活实现，本领域技术人员不应以此限制对本发明第一方面技术方案的理解。

请参阅图3，本发明的域名解析系统灾备建构装置，在前述方法的基础上，依据模块化思维改进实现，具体包括同步单元11、查询单元12、应答单元13通过同步而得的缓存数据：

所述的同步单元11，用于将提供DNS服务的目标机群的数据实时同步至灾备机群，所述数据中包含有用于提供域名解析基础的缓存数据。

通常，提供DNS服务的服务器，类似于云端架构，由多台服务器设备有机建构形成机群，与DNS解析服务器相互配置，实现DNS解析服务。其中，DNS服务机群主要用于实现递归系统，通过该递归系统向互联网中的对于于域名各层级的服务器递归调用以解析相应的域名，获取IP地址，以构造域名解析结果，以响应于外部请求。而DNS解析服务器作为前端应用窗口，负责接收发起请求的客户端的域名解析请求，并且将该请求提供给机群，要求机群作出域名解析结果回应，然后以相应的域名解析结果应答相应的域名解析请求。

本发明所构建的灾备系统，既是对互联网整个域名系统的灾备，又是基于对多个本地DNS服务器的相关机群的灾备而实现的。灾备系统的实现，以数据同步为基础；以故障检测为其切换运行的前提；以切换控制为管理逻辑。但灾备系统可以实时开放，其故障检测及后续的切换控制可由第三方来实现，因此本本发明的第一方面并不涉及有关故障检测和切换控制的技术。

数据同步是本发明实现DNS服务系统的灾备的关键基础。实现数据同步管理逻辑，通常采用数据备份手段。数据备份是系统、数据容灾的基础，也是低端容灾的实现，是高端容灾(实时数据保护)的有力保障。目前备份技术主要有快照备份、离线备份、异地存储备份。备份系统通过备份策略，对计算机信息系统的操作系统、文件系统、应用程序、数据库系统等数据集，实现某一时间点的完整拷贝，拷贝的数据处在非在线状态，不能被立刻访问，必须通过相应操作，如恢复等方式使用备份数据。在建设高端容灾系统的前提，一定要做好本地系统的备份，这是容灾技术的起点。

本发明实现数据同步时，采用高端容灾方式，以实现对DNS服务机群的实时数据保护，具体而言，就是在多块磁盘上、多个阵列、多台服务器、多个数据中心实时地保存同一份数据的多份存储，目的是为了避免物理故障。实时数据保护需要以数据备份作为前提，它不能防范人为误操作和恶性操作。需要强调的是，容灾的目的是让数据在灾难发生时，还能被访问，通过实时数据保护，保证数据的完整性，因此，本发明所建构的容灾系统并不能保证数据的最新。

如前所述，数据备份是容灾的手段，不是目的，容灾的目的是数据的访问，因此应用的恢复和网络的恢复以及相关的切换控制，也是容灾的关键。具体而言，就是在灾难发生后，数据库切换、应用重新启动、网络实现切换等等，容灾中心接管原生产中心的整个过程；同时还包含了在原数据中心修复后，数据库、应用、网络需要重新切回来的整个过程。这些过程，可以通过手工切换、也可以通过自动化过程完成；并且，如何据此而做出相应的评估，也是技术人员需要解决的问题。本发明后续将通过另一方法和装置对该部分的实现进行详细的揭示，因此暂按不表。

由此可知，通过配置为本发明的装置的软件将提供DNS服务的目标机群的数据实时同步至灾备机群，便成就了本发明容灾系统的实现基础。为了进一步说明被同步的所述的数据，如下请先参阅一应用实例。

请结合图2，如下以网易门户地址www.163.com这一域名的解析过程为例，说明正常情况下的DNS解析的主要过程：

步骤1：用户电脑向其系统上设置的本地DNS(解析)服务器发送解析www.163.com的请求。所谓本地DNS服务器是指一个DNS服务IP地址，可以是从运营商自动获取的，也可以是手动设置。

步骤2：本地DNS服务器会在自己的空间里查看是否有这个域名的缓存，如果没有，就会向根服务器发送www.163.com的域名解析请求。

步骤3：根服务器接收到本地DNS服务器关于域名的解析请求后，分析请求的域名，返回给本地服务器.com这个域名节点的服务器的IP地址。

步骤4：本地DNS服务器在接到.com顶级域的服务器IP地址后，向.com顶级域发出查询www.163.com的解析请求。

步骤5：.com顶级域服务器在接收到关于www.163.com的解析请求后，返回给本地DNS服务器关于163这个二级域的DNS服务器的IP地址。

步骤6：本地DNS服务器继续向163这个二级域的DNS服务器发起关于www.163.com的解析请求。

步骤7：163这个域的管理服务器管理163.com下的所有的子域名。它的域名空间中有www这个子域名，其对应的IP地址为111.1.53.220，因此163.com域的DNS服务器会返回www.163.com对应的IP地址111.1.53.220给本地DNS服务器。

步骤8：本地DNS服务器接收到163.com这个域服务器关于www.163.com解析结果后，返回给用户对应的IP地址111.1.53.220，同时会将这个结果保留一段时间，以备其他用户的查询。

步骤9：用户电脑在获得www.163.com域名对应的IP地址111.1.53.220后，就开始向111.1.53.220这个IP请求网页内容。至此，DNS的一个完整请求解析流程结束。

上述的示例中，本地DNS服务器被简化为一台服务器，实际上，通常情况下，其后台可能由多台服务器共同构成的前述的机群所实现。DNS解析服务器，无论何种情况，都需要充当应用前端的DNS服务器。本领域技术人员对此应当知晓。

上述的示例中，步骤2会首先在本地DNS服务器的空间中查看是否有域名解析请求中的域名的请求，而步骤8中则介绍了会将域名解析结果保存一段时间以备其他用户查询的事实。由此可以知晓，目标机群的数据中，必然包含一些缓存数据，这些缓存数据通常以日志类型的格式进行存储，在本发明中也可以以数据库的形式加以改进。

本发明有关缓存数据的实现的一个实施例中，可以沿用正常提供DNS服务的服务机群的格式，使所述缓存数据包括历史域名解析记录，所述历史域名解析记录为所述目标机群正常执行DNS服务过程中进行DNS解析而产生的DNS域名解析记录，通常是以日志文件的格式存储的。每条域名解析记录均至少包括有域名、与域名相应的IP地址，这里的域名与IP地址之间的相应性，主要是指它们彼此之间映射关系。进一步，可以为缓存数据库中的每条域名解析记录赋予一个生命周期，在该生命周期内，该记录有效，超过该生命周期，则可由本发明予以删除或者忽略。本发明在需要使用该缓存数据库用于解析域名时，优先依据请求数据中的域名，从历史域名解析记录中检索所述的缓存数据库，找到相应的有效的记录，获得相应的IP地址，然后应答相应的域名解析请求。当然，如果超过所述的生命周期，或者缓存数据中不存在相应的记录，则仍需通过递归系统来实现查询(如果启用灾备系统时公网上的各层级域名服务器仍能正常访问的话)。由于同一个终端设备一般由同一用户使用，其上网行为表现出一定的惯性，惯于访问部分特定网站，因此，通过这一缓存数据及其相关技术，可以为用户提高更高效更快速的DNS解析服务，并且可以节省一些移动终端设备的流量消耗，对于域名各层级服务器已经瘫痪导致无法递归查询的情况而言，这些缓存数据将发挥至关重要的解析作用。

本发明有关缓存数据的实现的另一实施例中，所述缓存数据包括一授权信息数据库，这一数据库可以使用公知的BGP Anycast(任播)技术分布进行构建。所述授权信息数据库存储有域名各层级的授权服务器的授权信息；可以在进行域名解析时，依照授权信息数据库所记录的相应的授权服务器信息，执行递归查询以获得所述的域名解析结果，适用于作为DNS递归查询机群瘫痪的场景使用。

所述的授权信息数据库也是利用所述的历史域名解析记录为基础进行构建的。众所周知的，域名服务机群在执行递归查询的过程中，能获得域名各层级相对应的授权服务器的授权信息，利用这些授权信息便可构造所述的授权信息数据库，用于实现虚拟根节点，向互联网开放虚拟根节点服务，实现更为系统的灾备解析效果。在这种情况下，依据本发明所实备系统，还可以结合虚拟根节点技术提供安全服务，当根节点出现DNS解析故障时，虚拟根节点能够代替根节点实现DNS解析功能。当然，授权信息数据库中必须存储有足够的信息，即，授权信息数据库中存储指定区域内的所有DNS请求及对应的授权信息，这样虚拟根节点才能够有足够的资源对DNS请求进行应答。因此，虚拟根节点的实现是在授权信息数据库的基础上实现的。结合新增的授权信息数据库以及虚拟根节点，能够在根节点解析故障的时候为客户端提供DNS解析功能，能够降低DNS单点故障和提高DNS防御攻击能力，同时还可以对虚拟根节点设置访问权限控制，屏蔽DNS的攻击数据，提高DNS解析的安全性及稳定性。对于危险DNS攻击，从授权信息数据库中查询不到具体的授权信息，则虚拟根节点不会为其提供解析服务等。

依据前述揭示的关于实现所述缓存数据的两种实施例以及其相应的扩展功能，本领域技术人员理应知晓，关于缓存数据的更多具体实现形式以及其扩充应用，是本领域技术人员可以根据本发明的需要而灵活实现的。例如，所述的缓存数据也可以理解为同时包括前述两个实施例中的历史域名解析记录与所述授权信息数据库，并且，不仅可以将所述历史域名解析记录作为临时缓存，还可以将所述历史域名解析记录作为具有更长生命周期的数据存储于授权信息数据库的相关独立数据表中，在临时缓存达到一定时间长度被高频率使用时，即可将临时缓存的历史域名解析记录转化为具有更长生命周期的历史域名解析记录存储于该数据表中，并且在后续进行域名解析时被作为查询对象优先于递归系统进行查询。

有关DNS服务机群的拓扑及其层次架构，以及灾备系统的拓扑及层次架构，可以由本领域技术人员根据公知的网络原理加以实现，本发明中更为关注两者之间的数据和控制关系，因此，涉及其拓扑与层次架构关系，恕不赘述。

如前所述，将DNS服务机群上的数据，尤其是其中的缓存数据同步到灾备机群之后，灾备机群即具备相应的解析能力，可以在后续进一步开放其解析服务。

所述的查询单元12，用于接收域名解析请求，响应于该域名解析请求而利用所述缓存数据进行域名解析。

本发明灾备系统，由于其高效地利用了缓存数据，实现了虚拟根节点的功能，因此拥有独立的虚拟根节点。具体而言便是通过一个授权信息数据库起到虚拟根域的作用。当根域或顶级域服务器发生故障不能正常服务时，甚至当外部所有其他的授权服务器都出现故障时，本地DNS系统或许成为解析孤岛，这种情况下，理论上应当允许这种系统实现类似的灾备模式，启动灾备紧急应答模式，保障互联网在根域服务器或授权服务器修复之前基本正常运行，为系统抢修和恢复留下足够的时间。

借助本发明后续将揭示的切换方法，应用了本发明的相关技术方案的相关系统，在灾难发生后，相关的DNS服务功能将被切换到指向灾备中心，也即本发明所构建的灾备机群。然而，客户端需要重新访问容灾节点的服务，带来另外一个问题，网络如何切换。具体而言就是DNS服务器的本地应用访问路径(网络地址)如何由指向原生产中心改为指向容灾中心。在灾难修复后，又要反过来需要指向原生产中心。最简单得方法就是更改DNS解析服务器的IP映射关系，由原来的目的地址改为灾备系统的提供DNS服务的网络地址。在灾难发生前，IP地址映射为生产中心服务器；在灾难发生后，IP地址由映射为容灾中心得服务器；在灾难修复后，IP又映射为生产中心得服务器。

关于实现这种智能切换的细节将在本发明的第二个方面中详述，本发明的第一方面暂以能够实现这种智能切换为前提进行说明。在第一方面中，客户端将其域名解析请求转发给DNS解析服务器，DNS解析服务器将该域名解析请求转发给灾备系统的服务，由灾备系统的服务执行解析，向DNS解析服务器返回域名解析结果，再由DNS解析服务器将该域名解析结果应答原来被中转的域名解析请求。

因此，本发明的灾备系统，当其接收到DNS解析服务器转发来的域名解析请求后，将需要对其作为解析。其解析方案可以结合前述的多种变例灵活实现不同的解析机制，例如：

第一种解析机制中，对应于缓存数据仅仅包括历史域名解析记录的情况，则灾备系统可以从所述的域名解析请求中提取域名之后，优先从其存储的缓存数据的海量历史域名解析记录中检索是否存在与该域名相对应的记录，当存在时，则以该记录中与该域名存在映射关系的IP地址作为域名解析结果。当然，也可以考虑有关为历史域名解析记录设置生命周期的因素，对于超过预设的生命周期的历史域名解析记录不再考虑。但通常不推荐使用这一策略，因为如果灾备系统是基于公网瘫痪或者域名各层级服务器瘫痪的原因，可能已经无法通过公网向域名对应各层级的服务器进行递归查询获得实际的域名了，应用这一策略的意义也便不大了。考虑到域名各层级服务器可能还有效，只是DNS服务器的机群出现了故障，这种情况下，如果从缓存数据中不能获得IP地址，则可进一步由本发明的灾备系统执行递归查询，如果能够获得有效的解析，则同理可生成更为准确的域名解析结果。

第二种解析机制，对应于缓存数据包括授权信息数据库的情况。可以先由灾备系统从所述的域名解析请求中提取域名之后，优先利用授权信息执行查询，如果能获得有效的IP解析结果，则以此应答。如果授权信息数据库中包括有历史域名解析记录相应的数据表，则可以沿用第一种解析机制，先从该数据表中尝试获取结果，如果不能获得结果，再利用授权信息数据库中的授权信息进行查询；或者反之，先利用授权信息进行查询，查询不得再利用历史域名解析记录进行查询。

第三种解析机制，是对应于既有缓存数据中既有授权信息数据库，又有作为缓存数据的历史域名解析记录，且授权信息数据库中也有优选的历史域名解析记录的情况。这种情况下，也可以结合前述两种机制灵活运用。例如，先从缓存历史域名解析记录中查询，查询不得再从数据表的历史域名解析记录中查询，再查询不得便进一步利用授权信息进行查询；或者反之。

由以上的多种解析机制的分析可以看出，只要在同步单元11中利用缓存数据搭建了有效的存储表达体系，则在本查询单元12中便可以灵活地对之加以有效利用，最终获得相应的域名解析结果。

所述的应答单元13，被配置为以域名解析结果应答所述的域名解析请求。

在查询单元12获得域名解析结果后，本应答单元13便可以将域名解析结果按照域名解析请求的转发方地址反馈给DNS解析服务器进行中转，由DNS解析服务器将域名解析结果应答原始的域名解析请求发起方，完成域名解析过程。

需要指出的是，本发明的灾备系统，可以不直接接收客户端发起的域名解析请求，也不直接向客户端应答域名解析结果，而是通过同一网络地址，主要是指IP地址所指向的DNS解析服务器来实现域名解析请求和域名解析结果的中转。由于灾备系统具有更高的安全要求，域名解析请求和域名解析结果在DNS解析服务器与灾备系统机群之间传输之前，可以先行加密，加密的方式多种多样，优先推荐公钥加密(非对称加密)的方式。

尽管以上说明的内容，是以灾备机群为主体来进行描述的，然而，依据本发明第一方面所实现的软件，却可以灵活安装于多台设备中。可以考虑以如下几种方式安全本发明第一方面的软件，以构成实现本发明第一方面的方法和装置的体系：

一种方式中，将本发明的同步单元11、查询单元12以及应答单元13由同一软件构造，并且该软件安装于本发明的灾备机群的单独一台设备中，而灾备机群的其它设备则只需配备与该单独一台设备进行通信的客户端模块，以此形成类似于C/S架构的模式，来实现机群的集中控制。作为这种方式的变化实例，表现在运行层面，相应的软件可以运行单独一个服务进程或多个相配合的进程来执行本所述的单元，单独一个服务进程相对便于理解，至于多个进程的情况，例如，可以将本发明的同步单元11实现为一个进程，而将步骤查询单元12和应答单元13实现为一个进程，两个进程分别独立工作，完成各自的任务。两个进程均可设置为系统服务进程。

另一种方式，考虑到同步单元11与其余两个单元的相互独立性，可以考虑将同步单元11的数据同步功能采用单独一个软件进行构造，将该软件安装于独立于灾备机群的一台独立设备中，例如所述的DNS(解析)服务器中，而其余两个单元仍然采用同一软件来构造，将该软件安装于灾备机群的一台前端服务设备中，两者分装于两台设备中，并行不悖又互相配合，同理也可满足本发明的需求。

因此，可以知晓，涉及本发明应用过程中系统搭建和软件实现方面的知识，可以结合本领域的公知技术进行灵活实现，本领域技术人员不应以此限制对本发明第一方面技术方案的理解。

进一步，请继续了解本发明第二方面的技术方案。同理，本发明的第二方面的技术方案，也可以实现了相关的软件，安装于具有服务器能力的计算机设备中，与便于服务器搭建的操作系统相配合，提供相应的服务。

本发明的第二方面技术方案的任务，在于实现灾备系统的故障检测和智能切换控制逻辑，但是可以独立于本发明第一方面技术方案而独立安装于其它设备中。通常，依据本发明第二方面技术方案所涉的方法和装置，被安装于作为业务前端的DNS(解析)服务器中，以便在第一时间识别到提供DNS服务的机群或者相关网络故障，而快速地将提供DNS服务的机群定位到前述第一方面技术方案构建的灾备机群。而在所述的故障清除时，又能快速地回切。需要指出的是，前述有关本发明第一方面技术方案所采用的内容，也将在以下有关本发明第二方面技术方案的揭示中被引用，本领域技术人员不应割裂这两个方面的联系。

请参阅图4，本发明为此而提供的一种DNS灾备系统孤岛应答自动切换方法，包括如下步骤：

步骤S21、接收并采集提供DNS服务的机群的运行数据。

作为实现了本发明的自动切换方法的作为应用前端的DNS服务器，其与DNS提供DNS服务的机群之间建构有通信关系，能够通过预定的通信端口包括约定的TCP或UDP协议端口等采集这些机群中的每台设备的运行数据，这些运行数据选用的类型非常灵活，并且也可以被灵活使用。以下列举一些运行数据供参考：

1、性能数据，用于表征所述机群每秒钟进行DNS解析的吞吐量信息。通常，每台机器在正常使用的情况下，其能执行的DNS解析数量的有限且相对恒定的，因此，通过一个预设定的吞吐量阈值，便可以判断某台设备，或者判定整个机群的吞吐量是否正常。这里所称的吞吐量是指接收域名解析请求并返回相应的域名解析结果进行应答的次数。

2、机器数据，用于表征机群中每台设备的至少一个硬件的运行信息。机器数据主要是指机器运行时的CPU和/或内存的占用状态，例如，CPU长期处于高利用率如100％运行的状态，以及可用内存长期较低的状态，可能意味着某种不必要的繁忙。理论上也可通过这些机器数据来判定单台设备或整个机群的运行质量。

3、应用数据，用于表征域名解析记录的日志信息。这里所称的日志信息，主要是指用于形成本发明第一方面的缓存数据的历史域名解析记录的原始信息。这些信息既可以在灾备系统中被后续开发出授权信息进行利用，也可以仅仅是在本方法中充当判断依据之用。利用这些日志信息，至少可以看出是否存在大范围的解析异常，例如大量域名解析请求不能获得相应的正常解析等，因此应用数据显然也可作为一个运行数据加以使用。

4、告警数据，用于表征机群所产生的告警信息。这里所称的告警数据，主要是机群中的设备的系统监控功能产生的告警数据，例如Windows系统“管理”组件所产生的告警数据，利用这些数据，也可判定单台设备或者机群的运行状态。

5、差异数据，用于表征缓存池与数据库之间的差异信息。这里所称的缓冲池，是指缓冲历史域名解析记录的缓冲空间中的数据，而这里所称的数据库，则是指已经将历史域名解析记录从缓冲空间中提取出成规范的存储格式的专用文件中。记录这些差异数据，主要是为了提供关于已经临时缓存数据与规范缓存数据之间的差异。

上述给出各种类型的运行数据，只是运行数据具体类型的列举，并不是对运行数据做全面限定。这些运行数据被收集后，还要视其不同的作用进行进一步的利益，在不同的情况下，所用到的运行数据的类型可能不同，这些灵活变化将在后续进一步介绍。

步骤S22、依据预设的配置信息对所述运行数据进行运算，以形成所述DNS服务机群的运行状态判定结果。

DNS服务器在收集了有关提供DNS服务的机群的大量的运行数据的基础上，可以进行智能的数据挖掘，结合机器学习的原理，对正常机群的运行状态做出更为智能准确的判定。为了达到这一目的，请参阅图5，本步骤采用如下具体步骤实现：

步骤S221、建立作为判定基准的指标数据集。

所述的指标数据集的建立，需要结合所述运行数据的选用而定的，而选用运行数据，则依赖于预设的配置信息。以下给出对应所述表格中的四种情况的指标数据集供参考：

1、性能数据：1000，机器数据：90％

2、告警数据：危险，机器数据：10％

3、差异数据：90％，应用数据：file.log

4、应用数据：file.log

依照上述四项指标数据集，可以对本发明建立的指标做如下的相应理解：

1、当性能数据达到1000次的吞吐量但机器数据(CPU和/或内存占比)便已经到达90％时，便构成了本发明的判定基准。

2、当机器数据(CPU和/或内存占比)仅使用了10％便出现“危险”状态的告警数据时，便构成了本发明的判定基准。

3、当应用数据为file.log的文件中的差异数据达到90％时，便构成了本发明的判定基准。

4、仅仅采用应用数据file.log文件作为实时判定基准。

在构建了上述的指标数据集的基础上，便可在后续基于这些指标数据集做进一步的处理。需要注意的是，这些指标数据集既可以是在软件安装之前便已给定的，也可以通过软件提供的用户界面进行按需维护。这些指标数据集可以存储于一个文件中以供验证本发明的实施。

尽管以上给出了四组指标数据集，但是，某些实施例中，也可以将所述指标数据集理解为仅仅一组标准指标，用于表征提供DNS服务的机群的正常状态，以此简化软件编程难度。

步骤S222、依据预设的配置信息，选定或生成相应的算法。

所述的配置信息，某些情况下，可能与指标数据集之间存在一一对应关系，但如果指标数据集仅为标准的一组，则只需对应到该组指标数据集即可。配置信息通常是遵守由本发明所规范的一定格式进行表达的策略配置信息。例如，本发明中，针对前述具有多组指标数据集的示例，可以制定如下的策略配置信息，其所相应表征的含义也在下表中给出：

序号	第一要素	第二要素	算法	表征意义
					1	性能数据	机器数据	A	对于性能和机器数据适用算法A
2	告警数据	机器数据	B	对于告警和机器数据适用算法B
					3	差异数据	应用数据	C	对差异和应用数据适用算法C
4	应用数据	无应答	D	对应用数据无应答部分适用算法D

以上的策略配置信息仅仅用于示例，实际上有非常灵活的配置方式，理论上，只要能够将指标数据集与算法建立起关联，便可以构成本发明的配置信息，而不论这些配置信息的具体表达形式和要素个数等。通常，一组策略配置信息应当对应于一组指标数据集，以便区分不同的情形适用不同的算法，不同组策略配置信息作用下，参与运算的所述运行数据与所述指标数据集均不同于其他组策略配置信息作用下所涉的运行数据和指标数据集。但是也可以如前所述将指标数据集统一成一个标准指标数据集，而各策略配置信息对应到该同一标准指标数据集。

由此可见，通过策略配置信息，便可选定系统中已知的算法，整个过程非常智能。进一步，也可以在策略配置信息的算法项中，给出相应的表达式来动态地给出算法生成依据，再由软件依照约定规则利用这些由策略配置信息给出的依据生成相应的算法，采用生成的算法适用之。可见，本发明通过配置信息关联起指标数据集与已经或未知算法之间的关系，给出了机器学习模型，具有高度智能特征，能够动态识别各种运行状况，由此在后续做出更为智能的灾备切换控制。

同理，所述配置信息，尤其是其中的策略配置信息，和/或所述动态给定的算法，可以通过提供一个图形用户界面来提供给用户进行输入和维护，相应的数据则可存储于一个数据表或文件中，以备本发明的软件使用。进一步，用于输入或改进指标数据集的用户界面以及用于设定或改变所述策略配置信息和/可算法的用户界面，可以是同一用户界面，可以由编程人员根据需要灵活设计。

步骤S223、以指标数据集为基准，利用所述的算法对所述的运行数据进行运算，判定运行数据所表征的运行状态是否异常。

在前述确定了指标数据集以及配置信息，具体指策略配置信息之后，便可以利用策略配置信息给出的算法选项，确定相应的算法，利用该算法对照配置信息中给出的要素，将运行数据中的相应要素与指标数据集这一基准进行数学上的运行，诸如统计、比较、归纳等等，获得最终的运算结果，做出所述运行数据所表征的机群中的设备或者整个机群的运行状态是否异常的判定。

某些情况下，所述的配置信息还可以给出一个执行选项，例如表征丢弃数据包不予应答的选项，这种情况下，当运用相应的算法做出不利的判定结果之后，便可适用该选项而对后续的域名解析请求不予应答，直接丢包处理。

为了更形象地理解本发明，如下给出一个通过本发明的上述机器学习模型识别DNS攻击的实例。

在本实例中，指标数据集可以给出时间为100ms，应用数据中在100ms内针对同一域名的解析请求数量为5000次。策略配置信息对应用数据、单位时间相结合的情形采用算法K。这种情况下，当配置有实现了本方法的软件的DNS解析服务器识别到所采集的应用数据，在100ms的单位时间内范围针对同一域名产生了超过5000次的域名解析请求时，不符合历史行为习惯，这种情况下，触发算法K加以进一步运算和验证，由算法K依据历史域名解析请求统计而得出历史使用习惯中，该域名在100ms内被访问的次数远低于5000次，这种情况下，算法K可以进一步做出判定，判定该时间正在发生网络攻击，于是便可做出运行状态异常的判定。在这个示例中，算法K的实现相对复杂，实际上，也可以通过一个额外的统计进程对各域名的历史行为习惯进行统计，以此生成指标数据集中的所述请求数量，这种情况下，算法K只需要将当前针对该域名的访问数量与指标数据集中的请求数量进行比对即可做出判定。

另一实施例中，可以在指标数据集中指定应用数据为某个日志文件，而策略配置信息中指定对该日志文件的无应答情况适用算法X。算法X运行时，统计该日志文件的无应答记录，当预定时间内，例如100分钟内，所产生的日志记录均为无应答记录时，则可直接判定相应的提供DNS服务的设备或者机群出现故障，从而也可做出运行状态异常的结论。

以上的两种情况，在叙述时，为了简便，将提供DNS服务的机群简化为单机进行阐述，然而本领域技术人员应当理解，这些实例中，当然也可以或者应当考虑机群的有机判断的情况，而这些均属于数学与编程技术的结合，也是本领域技术人员所应当合理掌握的，例如可以是在算法中考虑多达若干台设备出现同类型情况即视为机群的整体瘫痪或公网上的域名各层级DNS服务器的不可到达，据此进一步判定运行状态异常。鉴于类似的情况多变，无法穷举，而本发明又已经揭示了机群与其中的单机之间的关系，使得本领域技术人员足以灵活应变，因此恕不赘述。

当运用算法实现了DNS服务机群的运行状态判定后，便形成相应的运行状态结果，可以据此做出最终的切换控制。

步骤23、当所述判定结果表征异常运行状态时，将提供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解析服务器中，做出切换的动作，则是通过修改其内部参数实现的。具体是一个以IP地址形式表达的网络地址参数，默认情况下，该网络地址为原来提供DNS服务的机群所指定的开放其DNS解析服务的IP地址(目的地址)，但在判定结果为异常运行状态时，则被本步骤修改为灾备系统的用于开放其DNS解析服务的IP地址。反之，当原来提供DNS服务的机群恢复正常服务时，则需要将该网络地址参数从灾备系统的IP地址修改回原来提供DNS服务的机群的开放其DNS解析服务的IP地址。这一网络参数可以配置于一个文件或注册表中，并且可以通过相应的系统设置界面，或者本发明提供的用户界面进行手动修改。前者的具体实现形式依据不同的操作系统而定。

请参阅图6，本发明为此而提供的一种DNS灾备系统孤岛应答自动切换装置，包括采集单元21、判定单元22以及切换单元23。

所述的采集单元21，用于接收并采集提供DNS服务的机群的运行数据。

作为实现了本发明的自动切换装置的作为应用前端的DNS服务器，其与DNS提供DNS服务的机群之间建构有通信关系，能够通过预定的通信端口包括约定的TCP或UDP协议端口等采集这些机群中的每台设备的运行数据，这些运行数据选用的类型非常灵活，并且也可以被灵活使用。以下列举一些运行数据供参考：

1、性能数据，用于表征所述机群每秒钟进行DNS解析的吞吐量信息。通常，每台机器在正常使用的情况下，其能执行的DNS解析数量的有限且相对恒定的，因此，通过一个预设定的吞吐量阈值，便可以判断某台设备，或者判定整个机群的吞吐量是否正常。这里所称的吞吐量是指接收域名解析请求并返回相应的域名解析结果进行应答的次数。

2、机器数据，用于表征机群中每台设备的至少一个硬件的运行信息。机器数据主要是指机器运行时的CPU和/或内存的占用状态，例如，CPU长期处于高利用率如100％运行的状态，以及可用内存长期较低的状态，可能意味着某种不必要的繁忙。理论上也可通过这些机器数据来判定单台设备或整个机群的运行质量。

3、应用数据，用于表征域名解析记录的日志信息。这里所称的日志信息，主要是指用于形成本发明第一方面的缓存数据的历史域名解析记录的原始信息。这些信息既可以在灾备系统中被后续开发出授权信息进行利用，也可以仅仅是在本装置中充当判断依据之用。利用这些日志信息，至少可以看出是否存在大范围的解析异常，例如大量域名解析请求不能获得相应的正常解析等，因此应用数据显然也可作为一个运行数据加以使用。

4、告警数据，用于表征机群所产生的告警信息。这里所称的告警数据，主要是机群中的设备的系统监控功能产生的告警数据，例如Windows系统“管理”组件所产生的告警数据，利用这些数据，也可判定单台设备或者机群的运行状态。

5、差异数据，用于表征缓存池与数据库之间的差异信息。这里所称的缓冲池，是指缓冲历史域名解析记录的缓冲空间中的数据，而这里所称的数据库，则是指已经将历史域名解析记录从缓冲空间中提取出成规范的存储格式的专用文件中。记录这些差异数据，主要是为了提供关于已经临时缓存数据与规范缓存数据之间的差异。

上述给出各种类型的运行数据，只是运行数据具体类型的列举，并不是对运行数据做全面限定。这些运行数据被收集后，还要视其不同的作用进行进一步的利益，在不同的情况下，所用到的运行数据的类型可能不同，这些灵活变化将在后续进一步介绍。

所述的判定单元22，被配置为依据预设的配置信息对所述运行数据进行运算，以形成所述DNS服务机群的运行状态判定结果。

DNS服务器在收集了有关提供DNS服务的机群的大量的运行数据的基础上，可以进行智能的数据挖掘，结合机器学习的原理，对正常机群的运行状态做出更为智能准确的判定。为了达到这一目的，请参阅图7，本判定单元22具体包括指标建立模块221、算法生成模块222以及运算判定模块223。

所述的指标建立模块221，用于建立作为判定基准的指标数据集。

所述的指标数据集的建立，需要结合所述运行数据的选用而定的，而选用运行数据，则依赖于预设的配置信息。以下给出对应所述表格中的四种情况的指标数据集供参考：

1、性能数据：1000，机器数据：90％

2、告警数据：危险，机器数据：10％

3、差异数据：90％，应用数据：file.log

4、应用数据：file.log

依照上述四项指标数据集，可以对本发明建立的指标做如下的相应理解：

1、当性能数据达到1000次的吞吐量但机器数据(CPU和/或内存占比)便已经到达90％时，便构成了本发明的判定基准。

2、当机器数据(CPU和/或内存占比)仅使用了10％便出现“危险”状态的告警数据时，便构成了本发明的判定基准。

3、当应用数据为file.log的文件中的差异数据达到90％时，便构成了本发明的判定基准。

4、仅仅采用应用数据file.log文件作为实时判定基准。

在构建了上述的指标数据集的基础上，便可在后续基于这些指标数据集做进一步的处理。需要注意的是，这些指标数据集既可以是在软件安装之前便已给定的，也可以通过软件提供的用户界面进行按需维护。这些指标数据集可以存储于一个文件中以供验证本发明的实施。

尽管以上给出了四组指标数据集，但是，某些实施例中，也可以将所述指标数据集理解为仅仅一组标准指标，用于表征提供DNS服务的机群的正常状态，以此简化软件编程难度。

所述的算法生成模块222，用于依据预设的配置信息，选定或生成相应的算法。

所述的配置信息，某些情况下，可能与指标数据集之间存在一一对应关系，但如果指标数据集仅为标准的一组，则只需对应到该组指标数据集即可。配置信息通常是遵守由本发明所规范的一定格式进行表达的策略配置信息。例如，本发明中，针对前述具有多组指标数据集的示例，可以制定如下的策略配置信息，其所相应表征的含义也在下表中给出：

序号	第一要素	第二要素	算法	表征意义
					1	性能数据	机器数据	A	对于性能和机器数据适用算法A
2	告警数据	机器数据	B	对于告警和机器数据适用算法B
					3	差异数据	应用数据	C	对差异和应用数据适用算法C
4	应用数据	无应答	D	对应用数据无应答部分适用算法D

以上的策略配置信息仅仅用于示例，实际上有非常灵活的配置方式，理论上，只要能够将指标数据集与算法建立起关联，便可以构成本发明的配置信息，而不论这些配置信息的具体表达形式和要素个数等。通常，一组策略配置信息应当对应于一组指标数据集，以便区分不同的情形适用不同的算法，不同组策略配置信息作用下，参与运算的所述运行数据与所述指标数据集均不同于其他组策略配置信息作用下所涉的运行数据和指标数据集。但是也可以如前所述将指标数据集统一成一个标准指标数据集，而各策略配置信息对应到该同一标准指标数据集。

由此可见，通过策略配置信息，便可选定系统中已知的算法，整个过程非常智能。进一步，也可以在策略配置信息的算法项中，给出相应的表达式来动态地给出算法生成依据，再由软件依照约定规则利用这些由策略配置信息给出的依据生成相应的算法，采用生成的算法适用之。可见，本发明通过配置信息关联起指标数据集与已经或未知算法之间的关系，给出了机器学习模型，具有高度智能特征，能够动态识别各种运行状况，由此在后续做出更为智能的灾备切换控制。

同理，所述配置信息，尤其是其中的策略配置信息，和/或所述动态给定的算法，可以通过本发明的一个设定单元提供的一个图形用户界面来提供给用户进行输入和维护，相应的数据则可存储于一个数据表或文件中，以备本发明的软件使用。进一步，用于输入或改进指标数据集的用户界面以及用于设定或改变所述策略配置信息和/可算法的用户界面，可以是同一用户界面，可以由编程人员根据需要灵活设计。

所述运算判定模块223，被配置为以指标数据集为基准，利用所述的算法对所述的运行数据进行运算，判定运行数据所表征的运行状态是否异常。

在前述确定了指标数据集以及配置信息，具体指策略配置信息之后，便可以利用策略配置信息给出的算法选项，确定相应的算法，利用该算法对照配置信息中给出的要素，将运行数据中的相应要素与指标数据集这一基准进行数学上的运行，诸如统计、比较、归纳等等，获得最终的运算结果，做出所述运行数据所表征的机群中的设备或者整个机群的运行状态是否异常的判定。

某些情况下，所述的配置信息还可以给出一个执行选项，例如表征丢弃数据包不予应答的选项，这种情况下，当运用相应的算法做出不利的判定结果之后，便可适用该选项而对后续的域名解析请求不予应答，直接丢包处理。

为了更形象地理解本发明，如下给出一个通过本发明的上述机器学习模型识别DNS攻击的实例。

在本实例中，指标数据集可以给出时间为100ms，应用数据中在100ms内针对同一域名的解析请求数量为5000次。策略配置信息对应用数据、单位时间相结合的情形采用算法K。这种情况下，当配置有用于构造本装置的软件的DNS解析服务器识别到所采集的应用数据，在100ms的单位时间内范围针对同一域名产生了超过5000次的域名解析请求时，不符合历史行为习惯，这种情况下，触发算法K加以进一步运算和验证，由算法K依据历史域名解析请求统计而得出历史使用习惯中，该域名在100ms内被访问的次数远低于5000次，这种情况下，算法K可以进一步做出判定，判定该时间正在发生网络攻击，于是便可做出运行状态异常的判定。在这个示例中，算法K的实现相对复杂，实际上，也可以通过一个额外的统计进程对各域名的历史行为习惯进行统计，以此生成指标数据集中的所述请求数量，这种情况下，算法K只需要将当前针对该域名的访问数量与指标数据集中的请求数量进行比对即可做出判定。

另一实施例中，可以在指标数据集中指定应用数据为某个日志文件，而策略配置信息中指定对该日志文件的无应答情况适用算法X。算法X运行时，统计该日志文件的无应答记录，当预定时间内，例如100分钟内，所产生的日志记录均为无应答记录时，则可直接判定相应的提供DNS服务的设备或者机群出现故障，从而也可做出运行状态异常的结论。

以上的两种情况，在叙述时，为了简便，将提供DNS服务的机群简化为单机进行阐述，然而本领域技术人员应当理解，这些实例中，当然也可以或者应当考虑机群的有机判断的情况，而这些均属于数学与编程技术的结合，也是本领域技术人员所应当合理掌握的，例如可以是在算法中考虑多达若干台设备出现同类型情况即视为机群的整体瘫痪或公网上的域名各层级DNS服务器的不可到达，据此进一步判定运行状态异常。鉴于类似的情况多变，无法穷举，而本发明又已经揭示了机群与其中的单机之间的关系，使得本领域技术人员足以灵活应变，因此恕不赘述。

当运用算法实现了DNS服务机群的运行状态判定后，便形成相应的运行状态结果，可以据此做出最终的切换控制。

所述的切换单元23，被配置为当所述判定结果表征异常运行状态时，将提供DNS服务的目的地址修改为灾备系统的网络地址；当所述判定结果表征正常运行状态时，将提供DNS服务的目的地址修改为指向原来的目的地址。

可以知晓，所述的运行状态判定结果的实质是一个二值选项，或者表征运行状态正常，即DNS服务机群正常运行；或者表征运行状态异常，即DNS服务机群异常运行。因此，对应这两种情况可以做出不同的切换。

当所述判定结果表征异常运行状态时，DNS解析服务器知悉原来提供DNS服务的机群已经无法或者难以继续提供DNS解析服务，无论其原因是出于DNS攻击，还是因为网络不可到达，DNS解析服务器依据本切换单元23实现的逻辑，均需要做出相应的切换操作，使得后续的DNS解析请求能够转发给本发明的第一方面的技术方案所实现的灾备系统，由灾备系统运用前述揭示的技术进行域名解析。当灾备系统获得域名解析结果并转发给本DNS解析服务器之后，再由本DNS解析服务器以该域名解析结果应答发起该域名解析请求的客户端。在这个过程中，DNS解析服务器仅起中转作用，为了避免安全攻击，适宜将域名解析请求和域名解析结果进行加密传输，无论是向DNS解析服务器与发起请求的客户端之间的传输，还是DNS解析服务器与灾备系统之间的传输，均采用加密机制，便可使DNS数据更为安全，完善了传统的DNS协议。

当所述判定结果表征正常运行状态时，DNS解析服务器知悉原来提供的DNS服务的机群已经清除故障恢复正常服务，由此，DNS解析服务器依据本切换单元23实现的逻辑，需要做出回切操作，使得后续的DNS解析请求不再由灾备系统进行解析，而是由原来提供DNS服务的机群系统进行解析，而灾备系统则回复到虽开放其DNS服务却由于未接收域名解析请求而处于待命状态。

在完成上述两种相逆的切换的过程中，DNS服务器也可以通过一个用户数据库向安装有其客户端(例如某种类型的移动终端安全软件)的用户群推送即时消息，用户所安装的相应客户端软件接收到该即时消息后，也可自动修改并切换其DNS服务器地址使其指向灾备系统提供的更为安全的DNS服务器；或者将该即时消息显示给用户自行决策。

而在DNS解析服务器中，做出切换的动作，则是通过修改其内部参数实现的。具体是一个以IP地址形式表达的网络地址参数，默认情况下，该网络地址为原来提供DNS服务的机群所指定的开放其DNS解析服务的IP地址(目的地址)，但在判定结果为异常运行状态时，则被本切换单元23修改为灾备系统的用于开放其DNS解析服务的IP地址。网络地址一旦被修改，便完成了不同系统之间的切换。反之，当原来提供DNS服务的机群恢复正常服务时，则需要将该网络地址参数从灾备系统的IP地址修改回原来提供DNS服务的机群的开放其DNS解析服务的IP地址。这一网络参数可以配置于一个文件或注册表中，并且可以通过相应的系统设置界面，或者通过本发明的一个设定单元提供的用户界面进行手动修改。前者的具体实现形式依据不同的操作系统而定。

根据本发明第二方面技术方案所涉的方法和装置的上述多个实施例的揭示可以看出，本发明的其中一个实质是通过结合机器学习技术实现了智能攻击行为判定的功能，尽管本文仅给出部分实施例，但依据与本发明的相同的原理，本领域技术人员可以在本文的基础上继续变化出多种判定方法。这种行为判定功能，再结合底层实现，可以实现DNS服务器的更安全的防御效果。

例如，在本发明的一种实施例中，对于接收的每个域名解析请求相对应的网络数据包，可以以类似前述机器学习的方式判断出该网络数据包对应的DNS行为类型，并根据确定的DNS行为类型确定对该网络数据包进行处理的处理主体，进而将该网络数据包转至确定的处理主体进行处理。在本发明实施例中，处理主体可以由两层组成，分别是内核层、应用层。内核层包括网络层、驱动层等，可以实现高速缓存、攻击防护等功能，而应用层可以对网络数据包进行基本解析，包括域名解析后的地址、数据存储地址的获取等。与现有技术中的DNS行为的处理方法相比较，将网络数据包分别划分至内核层和应用层处理，可以将DNS请求根据实际请求处理，若遇到一秒几百万次的DNS请求攻击，也可以由处理能力较强的内核对其进行处理，而遇见时效性要求相对较低的DNS请求，则可以由应用层处理。采用内核和应用层分别处理DNS请求，考虑到内核的巨大的处理能力，能够实现大流量的DNS查询。并且，因DNS请求所导致的修改或启动导致加载时，因内核和应用层是分别处理的，因此可以利用其中之一处理当前DNS请求，另一继续对外提供服务。因此，本发明实施例提高了单机的业务处理能力，大大提高系统的处理能力和安全防护能力的同时，还能实现快速域名动态管理和配置，进而实现很多定制化的复杂功能需求。

当DNS行为类型确定为攻击行为时，那么，可以确定处理主体为内核，而当DNS行为类型为域名解析行为时，可以确定处理主体为应用层。为了提升域名解析服务的响应速度、处理性能及安全防护能力，根据DNS的解析原理，在内核模块中可以实现高速缓存和安全防护，正常情况内核模块能高效、稳定地处理98％的解析请求和绝大部分的攻击防护。而处理逻辑相对复杂，对性能要求并不是那么高的基础解析和管理功能放在应用层实现。

因此，处理主体为内核时，由内核检测所述网络数据包，过滤将网络数据包中携带的DNS攻击行为；以及，将过滤后的网络数据包转发至应用层进行处理。内核检测网络数据包时，可以启动防DDOS攻击策略、IP限速策略、域名限速策略等策略，相应的，可以在内核中为每个策略设置独立的内部模块，用于实现不同策略。

此处需要说明的是，每个网络数据包都具备一个特征码，且每个特征码是独一无二的，因此，可以根据特征码判断网络数据包的DNS请求的属性，识破伪装成正常数据包的DNS攻击操作。现根据如下步骤判断所述网络数据包中是否携带有DNS攻击行为：

步骤A、计算网络数据包的特征码；

步骤B、判断特征码是否是DNS攻击行为的特征码，若是，执行步骤C，若否，执行步骤D；

步骤C、若是，则确定网络数据包中携带有DNS攻击行为；

步骤D、若否，则确定网络数据包中未携带有DNS攻击行为。

其中，数据库中通常存储有已知DNS攻击行为的特征码的集合，当需要校验时，将步骤A中计算出的特征码与数据库的集合进行匹配，若步骤A计算出的特征码存在所述集合中，则是DNS攻击行为，反之则不是。

其中，特征码可以根据IP或域名等域名信息确定，例如，计算指定时间内接收的来自同一IP的网络数据包数得到特征码，和/或计算指定时间内接收的来自同一域名的网络数据包数。若1秒内从同一IP或同一域名接收的网络数据包数远远大于应该接收的包数，就证明该IP地址或域名已被变成攻击源。这也是IP限速策略、域名限速策略的基本原理。被证明变为攻击源的IP地址或域名，之后再接收到来自这一源头的网络数据包，可以直接舍弃或过滤掉，避免被其攻击，提高系统安全性能及处理效率。

内核对攻击行为进行过滤之后，将网络数据包发至应用层进行处理。应用层可以对网络数据包进行解析，获取域名对应的地址信息，从而获取相关数据反馈给客户端。以及，应用层可以对域名信息等数据进行管理，实现数据管理功能。

结合本发明全文的说明，可以看出，本发明的第一方面的技术方案所涉的方法和装置，构造出了灾备系统，使得灾备系统能够提供孤岛式的域名解析服务；而本发明的第二方面的技术方案所涉的方法和装置，则可以在灾备机群与普通机群之间做出智能的故障检测和切换控制，因此，由本发明构造的DNS服务系统，对互联网的DNS服务安全做出了较为显著的贡献。

综上所述，本发明的实施，有利于构建灾备系统，并且使灾备系统服务于传统的DNS服务机群的安全管控。

应当注意，在此提供的算法和公式不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示例一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本发明并帮助理解本发明各个方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法和装置解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如权利要求书所反映，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的网站安全检测设备中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种DNS灾备系统孤岛应答自动切换方法，其特征在于，包括如下步骤：

接收并采集提供DNS服务的机群的运行数据；

依据预设的配置信息对所述运行数据进行运算，以形成所述DNS服务机群的运行状态判定结果；

当所述判定结果表征异常运行状态时，将提供DNS服务的目的地址修改为灾备系统的网络地址；当所述判定结果表征正常运行状态时，将提供DNS服务的目的地址修改为指向原来的目的地址。

2.根据权利要求1所述的域名解析系统灾备建构方法，其特征在于，所述运行数据包括如下至少一种或任意多种数据类型：

性能数据，用于表征所述机群每秒钟进行DNS解析的吞吐量信息；

机器数据，用于表征机群中每台设备的至少一个硬件的运行信息；

应用数据，用于表征域名解析记录的日志信息；

告警数据，用于表征机群所产生的告警信息；

差异数据，用于表征缓存池与数据库之间的差异信息。

3.根据权利要求1所述的DNS灾备系统孤岛应答自动切换方法，其特征在于，通过预定通信端口接收构成所述机群的设备的运行数据，以采集提供DNS服务的机群的运行数据。

4.根据权利要求1所述的DNS灾备系统孤岛应答自动切换方法，其特征在于，所述依据预设的配置信息对所述运行数据进行运算的步骤，包括如上具体步骤：

建立作为判定基准的指标数据集；

依据预设的配置信息，选定或生成相应的算法；

以指标数据集为基准，利用所述的算法对所述的运行数据进行运算，判定运行数据所表征的运行状态是否异常。

5.根据权利要求1所述的DNS灾备系统孤岛应答自动切换方法，其特征在于，本方法还包括提供用户界面用于设定所述网络地址的步骤。

6.根据权利要求4所述的DNS灾备系统孤岛应答自动切换方法，其特征在于，所述配置信息包含有一个或多个不同遵守相同格式的策略配置信息。

7.根据权利要求6所述的DNS灾备系统孤岛应答自动切换方法，其特征在于，不同组策略配置信息作用下，参与运算的所述运行数据与所述指标数据集均不同于其他组策略配置信息作用下所涉的运行数据和指标数据集。

8.根据权利要求4所述的DNS灾备系统孤岛应答自动切换方法，其特征在于，本方法还包括提供用户界面用于设定所述策略配置信息、算法、指标数据集中的一种或任意多种数据的步骤。

9.一种DNS灾备系统孤岛应答自动切换装置，其特征在于，包括：

采集单元，用于接收并采集提供DNS服务的机群的运行数据；

判定单元，被配置为依据预设的配置信息对所述运行数据进行运算，以形成所述DNS服务机群的运行状态判定结果；

切换单元，被配置为当所述判定结果表征异常运行状态时，将提供DNS服务的目的地址修改为灾备系统的网络地址；当所述判定结果表征正常运行状态时，将提供DNS服务的目的地址修改为指向原来的目的地址。

10.根据权利要求9所述的DNS灾备系统孤岛应答自动切换装置，其特征在于，所述判定单元，包括：

指标建立模块，用于建立作为判定基准的指标数据集；

算法生成模块，用于依据预设的配置信息，选定或生成相应的算法；

运算判定模块，被配置为以指标数据集为基准，利用所述的算法对所述的运行数据进行运算，判定运行数据所表征的运行状态是否异常。