域名解析系统灾备建构方法及装置制造方法
【专利摘要】本发明涉及一种域名解析系统灾备建构方法，其包括如下步骤：将提供DNS服务的目标机群的数据实时同步至灾备机群，所述数据中包含有用于提供域名解析基础的缓存数据；接收域名解析请求，响应于该域名解析请求而利用所述缓存数据进行域名解析；以域名解析结果应答所述的域名解析请求。此外本发明还提供了一种域名解析系统灾备建构装置。运用本发明的建构方法可以建构适用于现有的域名服务系统的灾备系统，在现有的域名服务系统或其所依赖的网络瘫痪时，可以临时且有效地发挥域名解析服务的作用。
【专利说明】域名解析系统灾备建构方法及装置
【技术领域】
[0001] 本发明涉及互联网安全技术，涉及一种域名解析系统灾备建构方法及装置。
【背景技术】
[0002] 灾备系统是用于对网络机群所构成的业务系统进行备份和容灾的技术，广泛应用 于互联网服务机群中。通常，以正常运行的业务系统提供互联网服务，而由灾备系统对正 常运行的业务系统进行实时的备份和故障检测等，而在业务系统产生故障或者受到攻击之 后，就能智能地使用灾备系统替换原业务系统向互联网用户开放相同的服务。
[0003] 灾备系统通常包括数据同步、故障检测和业务切换几大管理逻辑。其中，数据同步 管理逻辑，是为了保证生产中心和灾备中心两地之间数据的完整性、一致性和可用性；故障 检测管理逻辑是根据数据监控的数据依据一定的策略做出故障评估和判断；业务切换管理 逻辑，根据故障检测结果，当生产中心的业务系统发生重大故障或者灾难时，负责自动或者 手动切换到使用灾备系统开放服务以替代原来的业务系统的运行模式。
[0004] 尽管灾备系统的原理已经被非常普遍地应用，但是，目前的DNS服务器及其相关 系统，由于DNS服务协议较为简单，因此向来不受重视，相关技术有待完善。
【发明内容】
[0005] 有鉴于上述至少一个方面的问题，本发明的目的便在于提供一种域名解析系统灾 备建构方法。
[0006] 相应的，依据模块化思维，本发明的另一目的在于提供一种域名解析系统灾备建 构装置。
[0007] 为实现本发明的目的，本发明采取如下技术方案：
[0008] 本发明的一种域名解析系统灾备建构方法，包括如下步骤：
[0009] 将提供DNS服务的目标机群的数据实时同步至灾备机群，所述数据中包含有用于 提供域名解析基础的缓存数据；
[0010] 接收域名解析请求，响应于该域名解析请求而利用所述缓存数据进行域名解析；
[0011] 以域名解析结果应答所述的域名解析请求。
[0012] -种实施方式中，本方法各步骤在灾备机群的至少一台设备中执行。
[0013] 另一实施方式中，本方法的各步骤由所述灾备机群的单台设备的一个或多个进程 所执行。
[0014] 再一实施方式中，所述将数据实时同步至灾备机群的步骤在独立于灾备机群的至 少一台设备中执行，其余步骤在灾备机群的同一设备中执行。
[0015] -种实施例中，所述缓存数据包括历史域名解析记录，所述历史域名解析记录为 所述目标机群正常执行DNS服务过程中进行DNS解析而产生的DNS域名解析记录，本方法 进行域名解析时，通过检索所述历史域名解析记录而获得相应的域名解析结果。
[0016] 具体的，所述历史域名解析记录包含有从域名至相应的IP地址的映射关系。
[0017] 另一实施例中，所述缓存数据还包括授权信息数据库，其存储有域名各层级的授 权服务器的授权信息；本方法进行域名解析时，依照授权信息数据库所记录的相应的授权 服务器信息，执行递归查询以获得所述的域名解析结果。较佳的，所述授权信息数据库以分 布式数据库的形式实现。
[0018] 进一步，所述域名解析请求与所述域名解析结果均经过同一网络地址进行中转。
[0019] 较佳的，所述域名解析请求与所述域名解析结果均被加密传输。
[0020] 本发明提供的一种域名解析系统灾备建构装置，包括：
[0021] 同步单元，用于将提供DNS服务的目标机群的数据实时同步至灾备机群，所述数 据中包含有用于提供域名解析基础的缓存数据；
[0022] 查询单元，用于接收域名解析请求，响应于该域名解析请求而利用所述缓存数据 进行域名解析；
[0023] 应答单元，被配置为以域名解析结果应答所述的域名解析请求。
[0024] 一种实施例中，本装置所述各单元被配置为在灾备机群的至少一台设备中执行。
[0025] 另一实施例中，本装置所述各单元被配置为在所述灾备机群的单台设备中由一个 或多个进程执行。
[0026] 再一实施例中，所述同步单元被配置为在独立于灾备机群的至少一台设备中执 行，所述查询单元和应答单元被配置为在灾备机群的同一设备中执行。
[0027] 根据本发明的一个实施例所揭示，所述缓存数据包括历史域名解析记录，所述历 史域名解析记录为所述目标机群正常执行DNS服务过程中进行DNS解析而产生的DNS域名 解析记录，所述查询单元进行域名解析时，通过检索所述历史域名解析记录而获得相应的 域名解析结果。
[0028] 较佳的，所述历史域名解析记录包含有从域名至相应的IP地址的映射关系。
[0029] 根据本发明另一实施例所揭示，所述缓存数据还包括授权信息数据库，其存储有 域名各层级的授权服务器的授权信息；所述查询单元进行域名解析时，依照授权信息数据 库所记录的相应的授权服务器信息，执行递归查询以获得所述的域名解析结果。
[0030] 较佳的，所述授权信息数据库以分布式数据库的形式实现。
[0031] 进一步，所述域名解析请求与所述域名解析结果均经过同一网络地址进行中转。
[0032] 较佳的，所述域名解析请求与所述域名解析结果均被加密传输。
[0033] 相较于现有技术，本发明至少具有如下优点：
[0034] 1、本发明实现了DNS服务系统的灾备系统的构建，通过实时同步DNS服务系统的 相关机群的数据，其中较为重要的是备份了该些机群在正常作业时进行正常解析服务所产 生的历史解析记录所形成的缓存数据，由此，在常规的DNS服务系统发生故障或者遭受攻 击时，即可由实施了本方法的灾备系统提供临时而且准确的DNS解析服务，构建孤岛应答 模式，利用灾备系统为互联网用户提供DNS解析服务。
[0035] 2、作为灾备系统，通常并不直接对客户端暴露，而是以DNS解析服务器为前端服 务窗口，由DNS解析服务器将用户的域名解析请求转发给本灾备系统，并且通过将针对该 请求的域名解析结果经由该DNS解析服务器中转应答该请求，可以更有效地保护灾备系 统，使灾备系统能够更顺畅地为互联网用户提供DNS解析服务。
[0036] 概括而言，运用本发明的灾备系统建构方法可以建构适用于现有的域名服务系统 的灾备系统，在现有的域名服务系统或其所依赖的网络瘫痪时，可以临时且有效地发挥域 名解析服务的作用。
[0037] 本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变 得明显，或通过本发明的实践了解到。
【专利附图】
【附图说明】
[0038] 本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变 得明显和容易理解，其中：
[0039] 图1是本发明的域名解析系统灾备建构方法的流程示意图；
[0040] 图2是传统的DNS解析服务原理示意图；
[0041] 图3是本发明的域名解析系统灾备建构装置的原理框图；
[0042] 图4是本发明的DNS灾备系统孤岛应答自动切换方法的流程示意图；
[0043] 图5是本发明的DNS灾备系统孤岛应答自动切换方法的步骤S22的的流程示意 图；
[0044] 图6是本发明的DNS灾备系统孤岛应答自动切换装置的原理框图；
[0045] 图7是本发明的DNS灾备系统孤岛应答自动切换装置的判定单元的原理框图。
【具体实施方式】
[0046] 下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终 相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附 图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。
[0047] 本【技术领域】技术人员可以理解，除非特意声明，这里使用的单数形式"一"、"一 个"、"所述"和"该"也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措 辞"包括"是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加 一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元 件被"连接"或"耦接"到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在 中间元件。此外，这里使用的"连接"或"耦接"可以包括无线连接或无线耦接。这里使用 的措辞"和/或"包括一个或更多个相关联的列出项的全部或任一单元和全部组合。
[0048] 本【技术领域】技术人员可以理解，除非另外定义，这里使用的所有术语（包括技术 术语和科学术语），具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应 该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中 的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含 义来解释。
[0049] 本【技术领域】技术人员可以理解，这里所使用的"终端"、"终端设备"既包括无线信 号接收器的设备，其仅具备无发射能力的无线信号接收器的设备，又包括接收和发射硬件 的设备，其具有能够在双向通信链路上，执行双向通信的接收和发射硬件的设备。这种设备 可以包括：蜂窝或其他通信设备，其具有单线路显示器或多线路显示器或没有多线路显示 器的蜂窝或其他通信设备；PCS(PersonalCommunicationsService，个人通信系统），其可 以组合语音、数据处理、传真和/或数据通信能力；PDA(PersonalDigitalAssistant，个 人数字助理），其可以包括射频接收器、寻呼机、互联网/内联网访问、网络浏览器、记事本、 日历和/或GPS(GlobalPositioningSystem，全球定位系统）接收器；常规膝上型和/或 掌上型计算机或其他设备，其具有和/或包括射频接收器的常规膝上型和/或掌上型计算 机或其他设备。这里所使用的"终端"、"终端设备"可以是便携式、可运输、安装在交通工具 (航空、海运和/或陆地）中的，或者适合于和/或配置为在本地运行，和/或以分布形式， 运行在地球和/或空间的任何其他位置运行。这里所使用的"终端"、"终端设备"还可以是 通信终端、上网终端、音乐/视频播放终端，例如可以是PDA、MID(MobileInternetDevice， 移动互联网设备）和/或具有音乐/视频播放功能的移动电话，也可以是智能电视、机顶盒 等设备。
[0050] 本【技术领域】技术人员可以理解，这里所使用的服务器、云端、远端网络设备等概 念，具有等同效果，其包括但不限于计算机、网络主机、单个网络服务器、多个网络服务器集 或多个服务器构成的云。在此，云由基于云计算（CloudComputing)的大量计算机或网络 服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超 级虚拟计算机。本发明的实施例中，远端网络设备、终端设备与WNS服务器之间可通过任何 通信方式实现通信，包括但不限于，基于3GPP、LTE、WIMAX的移动通信、基于TCP/IP、UDP协 议的计算机网络通信以及基于蓝牙、红外传输标准的近距无线传输方式。
[0051] 本领域技术人员应当理解，本发明所称的"应用"、"应用程序"、"应用软件"以及类 似表述的概念，是业内技术人员所公知的相同概念，是指由一系列计算机指令及相关数据 资源有机构造的适于电子运行的计算机软件。除非特别指定，这种命名本身不受编程语言 种类、级别，也不受其赖以运行的操作系统或平台所限制。理所当然地，此类概念也不受任 何形式的终端所限制。
[0052] 本文即将揭示的涉及本发明的相关技术方案，包括两个方面，第一方面是如何实 现灾备系统的构建的服务开放，第二方面是如何实现灾害识别从而确保在正常DNS服务系 统及其灾备系统之间实现有效、及时、智能地切换，藉此两方面的披露，将有助于本领域技 术人员更为系统地理解本发明。
[0053] 有关本发明的相关技术方案的第一个方面，即提供一种域名解析系统建构方法和 装置，其中的装置是依据模块化思维对其中的方法的实例化，可以通过编程的方式将所述 的方法和装置实现为软件，安装到计算机设备中特别是专用的具有服务器能力的计算机设 备中进行运行，接入互联网开放其服务，而构造出一台本地DNS解析服务器，或者构造出实 现本地DNS解析服务器的机群，用于为客户端提供DNS域名解析服务，以便应答客户端。
[0054] 请参阅图1，本发明的域名解析系统灾备建构方法，实现为一个或多个可以安装于 诸如Windows系列操作系统（包括但不限于WindowsXP,Window7,Windows8的系列版本 等）或者Unix系列操作系统（包括但不限于Unix、Linux、IOS、Ubuntu等）的软件，由该 软件的运行，而实现相应的具体步骤。具体包括如下步骤：
[0055] 步骤S11，将提供DNS服务的目标机群的数据实时同步至灾备机群，所述数据中包 含有用于提供域名解析基础的缓存数据。
[0056] 通常，提供DNS服务的服务器，类似于云端架构，由多台服务器设备有机建构形成 机群，与DNS解析服务器相互配置，实现DNS解析服务。其中，DNS服务机群主要用于实现 递归系统，通过该递归系统向互联网中的对于于域名各层级的服务器递归调用以解析相应 的域名，获取IP地址，以构造域名解析结果，以响应于外部请求。而DNS解析服务器作为前 端应用窗口，负责接收发起请求的客户端的域名解析请求，并且将该请求提供给机群，要求 机群作出域名解析结果回应，然后以相应的域名解析结果应答相应的域名解析请求。
[0057] 本发明所构建的灾备系统，既是对互联网整个域名系统的灾备，又是基于对多个 本地DNS服务器的相关机群的灾备而实现的。灾备系统的实现，以数据同步为基础；以故障 检测为其切换运行的前提；以切换控制为管理逻辑。但灾备系统可以实时开放，其故障检测 及后续的切换控制可由第三方来实现，因此本本发明的第一方面并不涉及有关故障检测和 切换控制的技术。
[0058] 数据同步是本发明实现DNS服务系统的灾备的关键基础。实现数据同步管理逻 辑，通常采用数据备份手段。数据备份是系统、数据容灾的基础，也是低端容灾的实现，是高 端容灾（实时数据保护）的有力保障。目前备份技术主要有快照备份、离线备份、异地存储 备份。备份系统通过备份策略，对计算机信息系统的操作系统、文件系统、应用程序、数据 库系统等数据集，实现某一时间点的完整拷贝，拷贝的数据处在非在线状态，不能被立刻访 问，必须通过相应操作，如恢复等方式使用备份数据。在建设高端容灾系统的前提，一定要 做好本地系统的备份，这是容灾技术的起点。
[0059] 本发明实现数据同步时，采用高端容灾方式，以实现对DNS服务机群的实时数据 保护，具体而言，就是在多块磁盘上、多个阵列、多台服务器、多个数据中心实时地保存同一 份数据的多份存储，目的是为了避免物理故障。实时数据保护需要以数据备份作为前提，它 不能防范人为误操作和恶性操作。需要强调的是，容灾的目的是让数据在灾难发生时，还能 被访问，通过实时数据保护，保证数据的完整性，因此，本发明所建构的容灾系统并不能保 证数据的最新。
[0060] 如前所述，数据备份是容灾的手段，不是目的，容灾的目的是数据的访问，因此应 用的恢复和网络的恢复以及相关的切换控制，也是容灾的关键。具体而言，就是在灾难发生 后，数据库切换、应用重新启动、网络实现切换等等，容灾中心接管原生产中心的整个过程； 同时还包含了在原数据中心修复后，数据库、应用、网络需要重新切回来的整个过程。这些 过程，可以通过手工切换、也可以通过自动化过程完成；并且，如何据此而做出相应的评估， 也是技术人员需要解决的问题。本发明后续将通过另一方法和装置对该部分的实现进行详 细的揭示，因此暂按不表。
[0061] 由此可知，通过配置为本发明的方法的软件将提供DNS服务的目标机群的数据实 时同步至灾备机群，便成就了本发明容灾系统的实现基础。为了进一步说明被同步的所述 的数据，如下请先参阅一应用实例。
[0062] 请结合图2,如下以网易门户地址www. 163.com这一域名的解析过程为例，说明正 常情况下的DNS解析的主要过程：
[0063] 步骤1 :用户电脑向其系统上设置的本地DNS(解析）服务器发送解析www. 163. com的请求。所谓本地DNS服务器是指一个DNS服务IP地址，可以是从运营商自动获取的， 也可以是手动设置。
[0064] 步骤2:本地DNS服务器会在自己的空间里查看是否有这个域名的缓存，如果没 有，就会向根服务器发送WWW.163.com的域名解析请求。
[0065] 步骤3:根服务器接收到本地DNS服务器关于域名的解析请求后，分析请求的域 名，返回给本地服务器.com这个域名节点的服务器的IP地址。
[0066] 步骤4 :本地DNS服务器在接到?com顶级域的服务器IP地址后，向?com顶级域 发出查询www. 163.com的解析请求。
[0067] 步骤5com顶级域服务器在接收到关于www. 163.com的解析请求后，返回给本地 DNS服务器关于163这个二级域的DNS服务器的IP地址。
[0068] 步骤6 :本地DNS服务器继续向163这个二级域的DNS服务器发起关于www. 163. com的解析请求。
[0069] 步骤7 :163这个域的管理服务器管理163.com下的所有的子域名。它的域名空间 中有www这个子域名，其对应的IP地址为111. 1. 53. 220,因此163.com域的DNS服务器会 返回www. 163.com对应的IP地址111. 1. 53. 220给本地DNS服务器。
[0070] 步骤8 :本地DNS服务器接收到163.com这个域服务器关于www. 163.com解析结 果后，返回给用户对应的IP地址111. 1. 53. 220,同时会将这个结果保留一段时间，以备其 他用户的查询。
[0071] 步骤9 :用户电脑在获得www. 163.com域名对应的IP地址111. 1. 53. 220后，就开 始向111. 1. 53. 220这个IP请求网页内容。至此，DNS的一个完整请求解析流程结束。
[0072] 上述的示例中，本地DNS服务器被简化为一台服务器，实际上，通常情况下，其后 台可能由多台服务器共同构成的前述的机群所实现。DNS解析服务器，无论何种情况，都需 要充当应用前端的DNS服务器。本领域技术人员对此应当知晓。
[0073] 上述的示例中，步骤2会首先在本地DNS服务器的空间中查看是否有域名解析请 求中的域名的请求，而步骤8中则介绍了会将域名解析结果保存一段时间以备其他用户查 询的事实。由此可以知晓，目标机群的数据中，必然包含一些缓存数据，这些缓存数据通常 以日志类型的格式进行存储，在本发明中也可以以数据库的形式加以改进。
[0074] 本发明有关缓存数据的实现的一个实施例中，可以沿用正常提供DNS服务的服务 机群的格式，使所述缓存数据包括历史域名解析记录，所述历史域名解析记录为所述目标 机群正常执行DNS服务过程中进行DNS解析而产生的DNS域名解析记录，通常是以日志文 件的格式存储的。每条域名解析记录均至少包括有域名、与域名相应的IP地址，这里的域 名与IP地址之间的相应性，主要是指它们彼此之间映射关系。进一步，可以为缓存数据库 中的每条域名解析记录赋予一个生命周期，在该生命周期内，该记录有效，超过该生命周 期，则可由本发明予以删除或者忽略。本发明在需要使用该缓存数据库用于解析域名时，优 先依据请求数据中的域名，从历史域名解析记录中检索所述的缓存数据库，找到相应的有 效的记录，获得相应的IP地址，然后应答相应的域名解析请求。当然，如果超过所述的生命 周期，或者缓存数据中不存在相应的记录，则仍需通过递归系统来实现查询（如果启用灾 备系统时公网上的各层级域名服务器仍能正常访问的话）。由于同一个终端设备一般由同 一用户使用，其上网行为表现出一定的惯性，惯于访问部分特定网站，因此，通过这一缓存 数据及其相关技术，可以为用户提高更高效更快速的DNS解析服务，并且可以节省一些移 动终端设备的流量消耗，对于域名各层级服务器已经瘫痪导致无法递归查询的情况而言， 这些缓存数据将发挥至关重要的解析作用。
[0075] 本发明有关缓存数据的实现的另一实施例中，所述缓存数据包括一授权信息数据 库，这一数据库可以使用公知的Anycast(任播）技术分布进行构建。所述授权信息数据库 存储有域名各层级的授权服务器的授权信息；可以在进行域名解析时，依照授权信息数据 库所记录的相应的授权服务器信息，执行递归查询以获得所述的域名解析结果，适用于作 为DNS递归查询机群瘫痪的场景使用。
[0076] 所述的授权信息数据库也是利用所述的历史域名解析记录为基础进行构建的。众 所周知的，域名服务机群在执行递归查询的过程中，能获得域名各层级相对应的授权服务 器的授权信息，利用这些授权信息便可构造所述的授权信息数据库，用于实现虚拟根节点， 向互联网开放虚拟根节点服务，实现更为系统的灾备解析效果。在这种情况下，依据本发明 所实备系统，还可以结合虚拟根节点技术提供安全服务，当根节点出现DNS解析故障时，虚 拟根节点能够代替根节点实现DNS解析功能。当然，授权信息数据库中必须存储有足够的 信息，即，授权信息数据库中存储指定区域内的所有DNS请求及对应的授权信息，这样虚拟 根节点才能够有足够的资源对DNS请求进行应答。因此，虚拟根节点的实现是在授权信息 数据库的基础上实现的。结合新增的授权信息数据库以及虚拟根节点，能够在根节点解析 故障的时候为客户端提供DNS解析功能，能够降低DNS单点故障和提高DNS防御攻击能力， 同时还可以对虚拟根节点设置访问权限控制，屏蔽DNS的攻击数据，提高DNS解析的安全性 及稳定性。对于危险DNS攻击，从授权信息数据库中查询不到具体的授权信息，则虚拟根节 点不会为其提供解析服务等。
[0077] 依据前述揭示的关于实现所述缓存数据的两种实施例以及其相应的扩展功能，本 领域技术人员理应知晓，关于缓存数据的更多具体实现形式以及其扩充应用，是本领域技 术人员可以根据本发明的需要而灵活实现的。例如，所述的缓存数据也可以理解为同时包 括前述两个实施例中的历史域名解析记录与所述授权信息数据库，并且，不仅可以将所述 历史域名解析记录作为临时缓存，还可以将所述历史域名解析记录作为具有更长生命周期 的数据存储于授权信息数据库的相关独立数据表中，在临时缓存达到一定时间长度被高频 率使用时，即可将临时缓存的历史域名解析记录转化为具有更长生命周期的历史域名解析 记录存储于该数据表中，并且在后续进行域名解析时被作为查询对象优先于递归系统进行 查询。
[0078] 有关DNS服务机群的拓扑及其层次架构，以及灾备系统的拓扑及层次架构，可以 由本领域技术人员根据公知的网络原理加以实现，本发明中更为关注两者之间的数据和控 制关系，因此，涉及其拓扑与层次架构关系，恕不赘述。
[0079] 如前所述，将DNS服务机群上的数据，尤其是其中的缓存数据同步到灾备机群之 后，灾备机群即具备相应的解析能力，可以在后续步骤中进一步开放其解析服务。
[0080] 步骤S12、接收域名解析请求，响应于该域名解析请求而利用所述缓存数据进行域 名解析。
[0081] 本发明灾备系统，由于其高效地利用了缓存数据，实现了虚拟根节点的功能，因此 拥有独立的虚拟根节点。具体而言便是通过一个授权信息数据库起到虚拟根域的作用。当 根域或顶级域服务器发生故障不能正常服务时，甚至当外部所有其他的授权服务器都出现 故障时，本地DNS系统或许成为解析孤岛，这种情况下，理论上应当允许这种系统实现类似 的灾备模式，启动灾备紧急应答模式，保障互联网在根域服务器或授权服务器修复之前基 本正常运行，为系统抢修和恢复留下足够的时间。
[0082] 借助本发明后续将揭示的切换方法，应用了本发明的相关技术方案的相关系统， 在灾难发生后，相关的DNS服务功能将被切换到指向灾备中心，也即本发明所构建的灾备 机群。然而，客户端需要重新访问容灾节点的服务，带来另外一个问题，网络如何切换。具 体而言就是DNS服务器的本地应用访问路径（网络地址）如何由指向原生产中心改为指向 容灾中心。在灾难修复后，又要反过来需要指向原生产中心。最简单得方法就是更改DNS 解析服务器的IP映射关系，由原来的目的地址改为灾备系统的提供DNS服务的网络地址。 在灾难发生前，IP地址映射为生产中心服务器；在灾难发生后，IP地址由映射为容灾中心 得服务器；在灾难修复后，IP又映射为生产中心得服务器。
[0083] 关于实现这种智能切换的细节将在本发明的第二个方面中详述，本发明的第一方 面暂以能够实现这种智能切换为前提进行说明。在第一方面中，客户端将其域名解析请求 转发给DNS解析服务器，DNS解析服务器将该域名解析请求转发给灾备系统的服务，由灾备 系统的服务执行解析，向DNS解析服务器返回域名解析结果，再由DNS解析服务器将该域名 解析结果应答原来被中转的域名解析请求。
[0084] 因此，本发明的灾备系统，当其接收到DNS解析服务器转发来的域名解析请求后， 将需要对其作为解析。其解析方案可以结合前述的多种变例灵活实现不同的解析机制，例 如：
[0085] 第一种解析机制中，对应于缓存数据仅仅包括历史域名解析记录的情况，则灾备 系统可以从所述的域名解析请求中提取域名之后，优先从其存储的缓存数据的海量历史域 名解析记录中检索是否存在与该域名相对应的记录，当存在时，则以该记录中与该域名存 在映射关系的IP地址作为域名解析结果。当然，也可以考虑有关为历史域名解析记录设置 生命周期的因素，对于超过预设的生命周期的历史域名解析记录不再考虑。但通常不推荐 使用这一策略，因为如果灾备系统是基于公网瘫痪或者域名各层级服务器瘫痪的原因，可 能已经无法通过公网向域名对应各层级的服务器进行递归查询获得实际的域名了，应用这 一策略的意义也便不大了。考虑到域名各层级服务器可能还有效，只是DNS服务器的机群 出现了故障，这种情况下，如果从缓存数据中不能获得IP地址，则可进一步由本发明的灾 备系统执行递归查询，如果能够获得有效的解析，则同理可生成更为准确的域名解析结果。
[0086] 第二种解析机制，对应于缓存数据包括授权信息数据库的情况。可以先由灾备系 统从所述的域名解析请求中提取域名之后，优先利用授权信息执行查询，如果能获得有效 的IP解析结果，则以此应答。如果授权信息数据库中包括有历史域名解析记录相应的数据 表，则可以沿用第一种解析机制，先从该数据表中尝试获取结果，如果不能获得结果，再利 用授权信息数据库中的授权信息进行查询；或者反之，先利用授权信息进行查询，查询不得 再利用历史域名解析记录进行查询。
[0087] 第三种解析机制，是对应于既有缓存数据中既有授权信息数据库，又有作为缓存 数据的历史域名解析记录，且授权信息数据库中也有优选的历史域名解析记录的情况。这 种情况下，也可以结合前述两种机制灵活运用。例如，先从缓存历史域名解析记录中查询， 查询不得再从数据表的历史域名解析记录中查询，再查询不得便进一步利用授权信息进行 查询；或者反之。
[0088] 由以上的多种解析机制的分析可以看出，只要在前一步骤中利用缓存数据搭建了 有效的存储表达体系，则在本步骤中便可以灵活地对之加以有效利用，最终获得相应的域 名解析结果。
[0089] 步骤S13、以域名解析结果应答所述的域名解析请求。
[0090] 在前一步获得域名解析结果后，本步骤便可以将域名解析结果按照域名解析请求 的转发方地址反馈给DNS解析服务器进行中转，由DNS解析服务器将域名解析结果应答原 始的域名解析请求发起方，完成域名解析过程。
[0091] 需要指出的是，本发明的灾备系统，可以不直接接收客户端发起的域名解析请求， 也不直接向客户端应答域名解析结果，而是通过同一网络地址，主要是指IP地址所指向的 DNS解析服务器来实现域名解析请求和域名解析结果的中转。由于灾备系统具有更高的安 全要求，域名解析请求和域名解析结果在DNS解析服务器与灾备系统机群之间传输之前， 可以先行加密，加密的方式多种多样，优先推荐公钥加密（非对称加密）的方式。
[0092] 尽管以上说明的内容，是以灾备机群为主体来进行描述的，然而，依据本发明第一 方面所实现的软件，却可以灵活安装于多台设备中。可以考虑以如下几种方式安全本发明 第一方面的软件，以构成实现本发明第一方面的方法和装置的体系：
[0093] 一种方式中，将本发明的各个步骤实现于同一软件中，并且安装于本发明的灾备 机群的单独一台设备中，而灾备机群的其它设备则只需配备与该单独一台设备进行通信的 客户端模块，以此形成类似于C/S架构的模式，来实现机群的集中控制。作为这种方式的变 化实例，表现在运行层面，相应的软件可以运行单独一个服务进程或多个相配合的进程来 执行本方法，单独一个服务进程相对便于理解，至于多个进程的情况，例如，可以将本发明 的步骤S11实现为一个进程，而将步骤S12、S13实现为一个进程，两个进程分别独立工作， 完成各自的任务。两个进程均可设置为系统服务进程。
[0094] 另一种方式，考虑到步骤S11与其余两个步骤的相互独立性，可以考虑将步骤S11 的数据同步功能实现成单独一个软件安装于独立于灾备机群的一台独立设备中，例如所述 的DNS(解析）服务器中，而其余两个步骤仍然实现为同一软件安装于灾备机群的一台前端 服务设备中，两者分装于两台设备中，并行不悖又互相配合，同理也可满足本发明的需求。
[0095] 因此，可以知晓，涉及本发明应用过程中系统搭建和软件实现方面的知识，可以结 合本领域的公知技术进行灵活实现，本领域技术人员不应以此限制对本发明第一方面技术 方案的理解。
[0096] 请参阅图3,本发明的域名解析系统灾备建构装置，在前述方法的基础上，依据模 块化思维改进实现，具体包括同步单元11、查询单元12、应答单元13通过同步而得的缓存 数据：
[0097] 所述的同步单元11，用于将提供DNS服务的目标机群的数据实时同步至灾备机 群，所述数据中包含有用于提供域名解析基础的缓存数据。
[0098] 通常，提供DNS服务的服务器，类似于云端架构，由多台服务器设备有机建构形成 机群，与DNS解析服务器相互配置，实现DNS解析服务。其中，DNS服务机群主要用于实现 递归系统，通过该递归系统向互联网中的对于于域名各层级的服务器递归调用以解析相应 的域名，获取IP地址，以构造域名解析结果，以响应于外部请求。而DNS解析服务器作为前 端应用窗口，负责接收发起请求的客户端的域名解析请求，并且将该请求提供给机群，要求 机群作出域名解析结果回应，然后以相应的域名解析结果应答相应的域名解析请求。
[0099] 本发明所构建的灾备系统，既是对互联网整个域名系统的灾备，又是基于对多个 本地DNS服务器的相关机群的灾备而实现的。灾备系统的实现，以数据同步为基础；以故障 检测为其切换运行的前提；以切换控制为管理逻辑。但灾备系统可以实时开放，其故障检测 及后续的切换控制可由第三方来实现，因此本本发明的第一方面并不涉及有关故障检测和 切换控制的技术。
[0100] 数据同步是本发明实现DNS服务系统的灾备的关键基础。实现数据同步管理逻 辑，通常采用数据备份手段。数据备份是系统、数据容灾的基础，也是低端容灾的实现，是高 端容灾（实时数据保护）的有力保障。目前备份技术主要有快照备份、离线备份、异地存储 备份。备份系统通过备份策略，对计算机信息系统的操作系统、文件系统、应用程序、数据 库系统等数据集，实现某一时间点的完整拷贝，拷贝的数据处在非在线状态，不能被立刻访 问，必须通过相应操作，如恢复等方式使用备份数据。在建设高端容灾系统的前提，一定要 做好本地系统的备份，这是容灾技术的起点。
[0101] 本发明实现数据同步时，采用高端容灾方式，以实现对DNS服务机群的实时数据 保护，具体而言，就是在多块磁盘上、多个阵列、多台服务器、多个数据中心实时地保存同一 份数据的多份存储，目的是为了避免物理故障。实时数据保护需要以数据备份作为前提，它 不能防范人为误操作和恶性操作。需要强调的是，容灾的目的是让数据在灾难发生时，还能 被访问，通过实时数据保护，保证数据的完整性，因此，本发明所建构的容灾系统并不能保 证数据的最新。
[0102] 如前所述，数据备份是容灾的手段，不是目的，容灾的目的是数据的访问，因此应 用的恢复和网络的恢复以及相关的切换控制，也是容灾的关键。具体而言，就是在灾难发生 后，数据库切换、应用重新启动、网络实现切换等等，容灾中心接管原生产中心的整个过程； 同时还包含了在原数据中心修复后，数据库、应用、网络需要重新切回来的整个过程。这些 过程，可以通过手工切换、也可以通过自动化过程完成；并且，如何据此而做出相应的评估， 也是技术人员需要解决的问题。本发明后续将通过另一方法和装置对该部分的实现进行详 细的揭示，因此暂按不表。
[0103] 由此可知，通过配置为本发明的装置的软件将提供DNS服务的目标机群的数据实 时同步至灾备机群，便成就了本发明容灾系统的实现基础。为了进一步说明被同步的所述 的数据，如下请先参阅一应用实例。
[0104] 请结合图2,如下以网易门户地址www. 163. com这一域名的解析过程为例，说明正 常情况下的DNS解析的主要过程：
[0105] 步骤1:用户电脑向其系统上设置的本地DNS(解析）服务器发送解析www. 163. com的请求。所谓本地DNS服务器是指一个DNS服务IP地址，可以是从运营商自动获取的， 也可以是手动设置。
[0106] 步骤2:本地DNS服务器会在自己的空间里查看是否有这个域名的缓存，如果没 有，就会向根服务器发送WWW.163.com的域名解析请求。
[0107] 步骤3:根服务器接收到本地DNS服务器关于域名的解析请求后，分析请求的域 名，返回给本地服务器.com这个域名节点的服务器的IP地址。
[0108] 步骤4:本地DNS服务器在接到.com顶级域的服务器IP地址后，向.com顶级域 发出查询www. 163. com的解析请求。
[0109] 步骤5 com顶级域服务器在接收到关于www. 163. com的解析请求后，返回给本地 DNS服务器关于163这个二级域的DNS服务器的IP地址。
[0110] 步骤6 :本地DNS服务器继续向163这个二级域的DNS服务器发起关于WWW. 163. com的解析请求。
[0111] 步骤7 :163这个域的管理服务器管理163.com下的所有的子域名。它的域名空间 中有www这个子域名，其对应的IP地址为111. 1. 53. 220,因此163.com域的DNS服务器会 返回www. 163.com对应的IP地址111. 1. 53. 220给本地DNS服务器。
[0112] 步骤8 :本地DNS服务器接收到163.com这个域服务器关于www. 163.com解析结 果后，返回给用户对应的IP地址111. 1. 53. 220,同时会将这个结果保留一段时间，以备其 他用户的查询。
[0113] 步骤9 :用户电脑在获得www. 163.com域名对应的IP地址111. 1. 53. 220后，就开 始向111. 1. 53. 220这个IP请求网页内容。至此，DNS的一个完整请求解析流程结束。
[0114] 上述的示例中，本地DNS服务器被简化为一台服务器，实际上，通常情况下，其后 台可能由多台服务器共同构成的前述的机群所实现。DNS解析服务器，无论何种情况，都需 要充当应用前端的DNS服务器。本领域技术人员对此应当知晓。
[0115] 上述的示例中，步骤2会首先在本地DNS服务器的空间中查看是否有域名解析请 求中的域名的请求，而步骤8中则介绍了会将域名解析结果保存一段时间以备其他用户查 询的事实。由此可以知晓，目标机群的数据中，必然包含一些缓存数据，这些缓存数据通常 以日志类型的格式进行存储，在本发明中也可以以数据库的形式加以改进。
[0116] 本发明有关缓存数据的实现的一个实施例中，可以沿用正常提供DNS服务的服务 机群的格式，使所述缓存数据包括历史域名解析记录，所述历史域名解析记录为所述目标 机群正常执行DNS服务过程中进行DNS解析而产生的DNS域名解析记录，通常是以日志文 件的格式存储的。每条域名解析记录均至少包括有域名、与域名相应的IP地址，这里的域 名与IP地址之间的相应性，主要是指它们彼此之间映射关系。进一步，可以为缓存数据库 中的每条域名解析记录赋予一个生命周期，在该生命周期内，该记录有效，超过该生命周 期，则可由本发明予以删除或者忽略。本发明在需要使用该缓存数据库用于解析域名时，优 先依据请求数据中的域名，从历史域名解析记录中检索所述的缓存数据库，找到相应的有 效的记录，获得相应的IP地址，然后应答相应的域名解析请求。当然，如果超过所述的生命 周期，或者缓存数据中不存在相应的记录，则仍需通过递归系统来实现查询（如果启用灾 备系统时公网上的各层级域名服务器仍能正常访问的话）。由于同一个终端设备一般由同 一用户使用，其上网行为表现出一定的惯性，惯于访问部分特定网站，因此，通过这一缓存 数据及其相关技术，可以为用户提高更高效更快速的DNS解析服务，并且可以节省一些移 动终端设备的流量消耗，对于域名各层级服务器已经瘫痪导致无法递归查询的情况而言， 这些缓存数据将发挥至关重要的解析作用。
[0117] 本发明有关缓存数据的实现的另一实施例中，所述缓存数据包括一授权信息数据 库，这一数据库可以使用公知的BGPAnycast(任播）技术分布进行构建。所述授权信息数 据库存储有域名各层级的授权服务器的授权信息；可以在进行域名解析时，依照授权信息 数据库所记录的相应的授权服务器信息，执行递归查询以获得所述的域名解析结果，适用 于作为DNS递归查询机群瘫痪的场景使用。
[0118] 所述的授权信息数据库也是利用所述的历史域名解析记录为基础进行构建的。众 所周知的，域名服务机群在执行递归查询的过程中，能获得域名各层级相对应的授权服务 器的授权信息，利用这些授权信息便可构造所述的授权信息数据库，用于实现虚拟根节点， 向互联网开放虚拟根节点服务，实现更为系统的灾备解析效果。在这种情况下，依据本发明 所实备系统，还可以结合虚拟根节点技术提供安全服务，当根节点出现DNS解析故障时，虚 拟根节点能够代替根节点实现DNS解析功能。当然，授权信息数据库中必须存储有足够的 信息，即，授权信息数据库中存储指定区域内的所有DNS请求及对应的授权信息，这样虚拟 根节点才能够有足够的资源对DNS请求进行应答。因此，虚拟根节点的实现是在授权信息 数据库的基础上实现的。结合新增的授权信息数据库以及虚拟根节点，能够在根节点解析 故障的时候为客户端提供DNS解析功能，能够降低DNS单点故障和提高DNS防御攻击能力， 同时还可以对虚拟根节点设置访问权限控制，屏蔽DNS的攻击数据，提高DNS解析的安全性 及稳定性。对于危险DNS攻击，从授权信息数据库中查询不到具体的授权信息，则虚拟根节 点不会为其提供解析服务等。
[0119] 依据前述揭示的关于实现所述缓存数据的两种实施例以及其相应的扩展功能，本 领域技术人员理应知晓，关于缓存数据的更多具体实现形式以及其扩充应用，是本领域技 术人员可以根据本发明的需要而灵活实现的。例如，所述的缓存数据也可以理解为同时包 括前述两个实施例中的历史域名解析记录与所述授权信息数据库，并且，不仅可以将所述 历史域名解析记录作为临时缓存，还可以将所述历史域名解析记录作为具有更长生命周期 的数据存储于授权信息数据库的相关独立数据表中，在临时缓存达到一定时间长度被高频 率使用时，即可将临时缓存的历史域名解析记录转化为具有更长生命周期的历史域名解析 记录存储于该数据表中，并且在后续进行域名解析时被作为查询对象优先于递归系统进行 查询。
[0120] 有关DNS服务机群的拓扑及其层次架构，以及灾备系统的拓扑及层次架构，可以 由本领域技术人员根据公知的网络原理加以实现，本发明中更为关注两者之间的数据和控 制关系，因此，涉及其拓扑与层次架构关系，恕不赘述。
[0121] 如前所述，将DNS服务机群上的数据，尤其是其中的缓存数据同步到灾备机群之 后，灾备机群即具备相应的解析能力，可以在后续进一步开放其解析服务。
[0122] 所述的查询单元12,用于接收域名解析请求，响应于该域名解析请求而利用所述 缓存数据进行域名解析。
[0123] 本发明灾备系统，由于其高效地利用了缓存数据，实现了虚拟根节点的功能，因此 拥有独立的虚拟根节点。具体而言便是通过一个授权信息数据库起到虚拟根域的作用。当 根域或顶级域服务器发生故障不能正常服务时，甚至当外部所有其他的授权服务器都出现 故障时，本地DNS系统或许成为解析孤岛，这种情况下，理论上应当允许这种系统实现类似 的灾备模式，启动灾备紧急应答模式，保障互联网在根域服务器或授权服务器修复之前基 本正常运行，为系统抢修和恢复留下足够的时间。
[0124] 借助本发明后续将揭示的切换方法，应用了本发明的相关技术方案的相关系统， 在灾难发生后，相关的DNS服务功能将被切换到指向灾备中心，也即本发明所构建的灾备 机群。然而，客户端需要重新访问容灾节点的服务，带来另外一个问题，网络如何切换。具 体而言就是DNS服务器的本地应用访问路径（网络地址）如何由指向原生产中心改为指向 容灾中心。在灾难修复后，又要反过来需要指向原生产中心。最简单得方法就是更改DNS 解析服务器的IP映射关系，由原来的目的地址改为灾备系统的提供DNS服务的网络地址。 在灾难发生前，IP地址映射为生产中心服务器；在灾难发生后，IP地址由映射为容灾中心 得服务器；在灾难修复后，IP又映射为生产中心得服务器。
[0125] 关于实现这种智能切换的细节将在本发明的第二个方面中详述，本发明的第一方 面暂以能够实现这种智能切换为前提进行说明。在第一方面中，客户端将其域名解析请求 转发给DNS解析服务器，DNS解析服务器将该域名解析请求转发给灾备系统的服务，由灾备 系统的服务执行解析，向DNS解析服务器返回域名解析结果，再由DNS解析服务器将该域名 解析结果应答原来被中转的域名解析请求。
[0126] 因此，本发明的灾备系统，当其接收到DNS解析服务器转发来的域名解析请求后， 将需要对其作为解析。其解析方案可以结合前述的多种变例灵活实现不同的解析机制，例 如：
[0127] 第一种解析机制中，对应于缓存数据仅仅包括历史域名解析记录的情况，则灾备 系统可以从所述的域名解析请求中提取域名之后，优先从其存储的缓存数据的海量历史域 名解析记录中检索是否存在与该域名相对应的记录，当存在时，则以该记录中与该域名存 在映射关系的IP地址作为域名解析结果。当然，也可以考虑有关为历史域名解析记录设置 生命周期的因素，对于超过预设的生命周期的历史域名解析记录不再考虑。但通常不推荐 使用这一策略，因为如果灾备系统是基于公网瘫痪或者域名各层级服务器瘫痪的原因，可 能已经无法通过公网向域名对应各层级的服务器进行递归查询获得实际的域名了，应用这 一策略的意义也便不大了。考虑到域名各层级服务器可能还有效，只是DNS服务器的机群 出现了故障，这种情况下，如果从缓存数据中不能获得IP地址，则可进一步由本发明的灾 备系统执行递归查询，如果能够获得有效的解析，则同理可生成更为准确的域名解析结果。
[0128] 第二种解析机制，对应于缓存数据包括授权信息数据库的情况。可以先由灾备系 统从所述的域名解析请求中提取域名之后，优先利用授权信息执行查询，如果能获得有效 的IP解析结果，则以此应答。如果授权信息数据库中包括有历史域名解析记录相应的数据 表，则可以沿用第一种解析机制，先从该数据表中尝试获取结果，如果不能获得结果，再利 用授权信息数据库中的授权信息进行查询；或者反之，先利用授权信息进行查询，查询不得 再利用历史域名解析记录进行查询。
[0129] 第三种解析机制，是对应于既有缓存数据中既有授权信息数据库，又有作为缓存 数据的历史域名解析记录，且授权信息数据库中也有优选的历史域名解析记录的情况。这 种情况下，也可以结合前述两种机制灵活运用。例如，先从缓存历史域名解析记录中查询， 查询不得再从数据表的历史域名解析记录中查询，再查询不得便进一步利用授权信息进行 查询；或者反之。
[0130] 由以上的多种解析机制的分析可以看出，只要在同步单元11中利用缓存数据搭 建了有效的存储表达体系，则在本查询单元12中便可以灵活地对之加以有效利用，最终获 得相应的域名解析结果。
[0131] 所述的应答单元13,被配置为以域名解析结果应答所述的域名解析请求。
[0132] 在查询单元12获得域名解析结果后，本应答单元13便可以将域名解析结果按照 域名解析请求的转发方地址反馈给DNS解析服务器进行中转，由DNS解析服务器将域名解 析结果应答原始的域名解析请求发起方，完成域名解析过程。
[0133] 需要指出的是，本发明的灾备系统，可以不直接接收客户端发起的域名解析请求， 也不直接向客户端应答域名解析结果，而是通过同一网络地址，主要是指IP地址所指向的DNS解析服务器来实现域名解析请求和域名解析结果的中转。由于灾备系统具有更高的安 全要求，域名解析请求和域名解析结果在DNS解析服务器与灾备系统机群之间传输之前， 可以先行加密，加密的方式多种多样，优先推荐公钥加密（非对称加密）的方式。
[0134] 尽管以上说明的内容，是以灾备机群为主体来进行描述的，然而，依据本发明第一 方面所实现的软件，却可以灵活安装于多台设备中。可以考虑以如下几种方式安全本发明 第一方面的软件，以构成实现本发明第一方面的方法和装置的体系：
[0135] 一种方式中，将本发明的同步单元11、查询单元12以及应答单元13由同一软件 构造，并且该软件安装于本发明的灾备机群的单独一台设备中，而灾备机群的其它设备则 只需配备与该单独一台设备进行通信的客户端模块，以此形成类似于C/S架构的模式，来 实现机群的集中控制。作为这种方式的变化实例，表现在运行层面，相应的软件可以运行单 独一个服务进程或多个相配合的进程来执行本所述的单元，单独一个服务进程相对便于理 解，至于多个进程的情况，例如，可以将本发明的同步单元11实现为一个进程，而将步骤查 询单元12和应答单元13实现为一个进程，两个进程分别独立工作，完成各自的任务。两个 进程均可设置为系统服务进程。
[0136] 另一种方式，考虑到同步单元11与其余两个单元的相互独立性，可以考虑将同步 单元11的数据同步功能采用单独一个软件进行构造，将该软件安装于独立于灾备机群的 一台独立设备中，例如所述的DNS(解析）服务器中，而其余两个单元仍然采用同一软件来 构造，将该软件安装于灾备机群的一台前端服务设备中，两者分装于两台设备中，并行不悖 又互相配合，同理也可满足本发明的需求。
[0137] 因此，可以知晓，涉及本发明应用过程中系统搭建和软件实现方面的知识，可以结 合本领域的公知技术进行灵活实现，本领域技术人员不应以此限制对本发明第一方面技术 方案的理解。
[0138] 进一步，请继续了解本发明第二方面的技术方案。同理，本发明的第二方面的技术 方案，也可以实现了相关的软件，安装于具有服务器能力的计算机设备中，与便于服务器搭 建的操作系统相配合，提供相应的服务。
[0139] 本发明的第二方面技术方案的任务，在于实现灾备系统的故障检测和智能切换控 制逻辑，但是可以独立于本发明第一方面技术方案而独立安装于其它设备中。通常，依据 本发明第二方面技术方案所涉的方法和装置，被安装于作为业务前端的DNS(解析）服务 器中，以便在第一时间识别到提供DNS服务的机群或者相关网络故障，而快速地将提供DNS 服务的机群定位到前述第一方面技术方案构建的灾备机群。而在所述的故障清除时，又能 快速地回切。需要指出的是，前述有关本发明第一方面技术方案所采用的内容，也将在以下 有关本发明第二方面技术方案的揭示中被引用，本领域技术人员不应割裂这两个方面的联 系。
[0140] 请参阅图4,本发明为此而提供的一种DNS灾备系统孤岛应答自动切换方法，包括 如下步骤：
[0141] 步骤S21、接收并采集提供DNS服务的机群的运行数据。
[0142] 作为实现了本发明的自动切换方法的作为应用前端的DNS服务器，其与DNS提供 DNS服务的机群之间建构有通信关系，能够通过预定的通信端口包括约定的TCP或UDP协议 端口等采集这些机群中的每台设备的运行数据，这些运行数据选用的类型非常灵活，并且 也可以被灵活使用。以下列举一些运行数据供参考：
[0143] 1、性能数据，用于表征所述机群每秒钟进行DNS解析的吞吐量信息。通常，每台机 器在正常使用的情况下，其能执行的DNS解析数量的有限且相对恒定的，因此，通过一个预 设定的吞吐量阈值，便可以判断某台设备，或者判定整个机群的吞吐量是否正常。这里所称 的吞吐量是指接收域名解析请求并返回相应的域名解析结果进行应答的次数。
[0144] 2、机器数据，用于表征机群中每台设备的至少一个硬件的运行信息。机器数据主 要是指机器运行时的CPU和/或内存的占用状态，例如，CPU长期处于高利用率如100%运 行的状态，以及可用内存长期较低的状态，可能意味着某种不必要的繁忙。理论上也可通过 这些机器数据来判定单台设备或整个机群的运行质量。
[0145] 3、应用数据，用于表征域名解析记录的日志信息。这里所称的日志信息，主要是指 用于形成本发明第一方面的缓存数据的历史域名解析记录的原始信息。这些信息既可以 在灾备系统中被后续开发出授权信息进行利用，也可以仅仅是在本方法中充当判断依据之 用。利用这些日志信息，至少可以看出是否存在大范围的解析异常，例如大量域名解析请求 不能获得相应的正常解析等，因此应用数据显然也可作为一个运行数据加以使用。
[0146] 4、告警数据，用于表征机群所产生的告警信息。这里所称的告警数据，主要是机群 中的设备的系统监控功能产生的告警数据，例如Windows系统"管理"组件所产生的告警数 据，利用这些数据，也可判定单台设备或者机群的运行状态。
[0147] 5、差异数据，用于表征缓存池与数据库之间的差异信息。这里所称的缓冲池，是指 缓冲历史域名解析记录的缓冲空间中的数据，而这里所称的数据库，则是指已经将历史域 名解析记录从缓冲空间中提取出成规范的存储格式的专用文件中。记录这些差异数据，主 要是为了提供关于已经临时缓存数据与规范缓存数据之间的差异。
[0148] 上述给出各种类型的运行数据，只是运行数据具体类型的列举，并不是对运行数 据做全面限定。这些运行数据被收集后，还要视其不同的作用进行进一步的利益，在不同的 情况下，所用到的运行数据的类型可能不同，这些灵活变化将在后续进一步介绍。
[0149] 步骤S22、依据预设的配置信息对所述运行数据进行运算，以形成所述DNS服务机 群的运行状态判定结果。
[0150] DNS服务器在收集了有关提供DNS服务的机群的大量的运行数据的基础上，可以 进行智能的数据挖掘，结合机器学习的原理，对正常机群的运行状态做出更为智能准确的 判定。为了达到这一目的，请参阅图5,本步骤采用如下具体步骤实现：
[0151] 步骤S221、建立作为判定基准的指标数据集。
[0152] 所述的指标数据集的建立，需要结合所述运行数据的选用而定的，而选用运行数 据，则依赖于预设的配置信息。以下给出对应所述表格中的四种情况的指标数据集供参 考：
[0153] 1、性能数据：1000,机器数据：90%
[0154] 2、告警数据：危险，机器数据：10%
[0155] 3、差异数据：90%，应用数据：file,log
[0156] 4、应用数据：file,log
[0157] 依照上述四项指标数据集，可以对本发明建立的指标做如下的相应理解：
[0158] 1、当性能数据达到1000次的吞吐量但机器数据（CPU和/或内存占比）便已经到 达90 %时，便构成了本发明的判定基准。
[0159] 2、当机器数据（CPU和/或内存占比）仅使用了 10%便出现"危险"状态的告警数 据时，便构成了本发明的判定基准。
[0160] 3、当应用数据为file,log的文件中的差异数据达到90%时，便构成了本发明的 判定基准。
[0161] 4、仅仅采用应用数据file,log文件作为实时判定基准。
[0162] 在构建了上述的指标数据集的基础上，便可在后续基于这些指标数据集做进一步 的处理。需要注意的是，这些指标数据集既可以是在软件安装之前便已给定的，也可以通过 软件提供的用户界面进行按需维护。这些指标数据集可以存储于一个文件中以供验证本发 明的实施。
[0163] 尽管以上给出了四组指标数据集，但是，某些实施例中，也可以将所述指标数据集 理解为仅仅一组标准指标，用于表征提供DNS服务的机群的正常状态，以此简化软件编程 难度。
[0164] 步骤S222、依据预设的配置信息，选定或生成相应的算法。
[0165] 所述的配置信息，某些情况下，可能与指标数据集之间存在一一对应关系，但如果 指标数据集仅为标准的一组，则只需对应到该组指标数据集即可。配置信息通常是遵守由 本发明所规范的一定格式进行表达的策略配置信息。例如，本发明中，针对前述具有多组指 标数据集的示例，可以制定如下的策略配置信息，其所相应表征的含义也在下表中给出：
[0166]
【权利要求】
1. 一种域名解析系统灾备建构方法，其特征在于，包括如下步骤： 将提供DNS服务的目标机群的数据实时同步至灾备机群，所述数据中包含有用于提供 域名解析基础的缓存数据； 接收域名解析请求，响应于该域名解析请求而利用所述缓存数据进行域名解析； W域名解析结果应答所述的域名解析请求。
2. 根据权利要求1所述的域名解析系统灾备建构方法，其特征在于：本方法各步骤在 灾备机群的至少一台设备中执行。
3. 根据权利要求1所述的域名解析系统灾备建构方法，其特征在于：本方法的各步骤 由所述灾备机群的单台设备的一个或多个进程所执行。
4. 根据权利要求1所述的域名解析系统灾备建构方法，其特征在于：所述将数据实时 同步至灾备机群的步骤在独立于灾备机群的至少一台设备中执行，其余步骤在灾备机群的 同一设备中执行。
5. 根据权利要求1所述的域名解析系统灾备建构方法，其特征在于：所述缓存数据包 括历史域名解析记录，所述历史域名解析记录为所述目标机群正常执行DNS服务过程中进 行DNS解析而产生的DNS域名解析记录，本方法进行域名解析时，通过检索所述历史域名解 析记录而获得相应的域名解析结果。
6. 根据权利要求5所述的域名解析系统灾备建构方法，其特征在于：所述历史域名解 析记录包含有从域名至相应的IP地址的映射关系。
7. 根据权利要求1所述的域名解析系统灾备建构方法，其特征在于：所述缓存数据还 包括授权信息数据库，其存储有域名各层级的授权服务器的授权信息；本方法进行域名解 析时，依照授权信息数据库所记录的相应的授权服务器信息，执行递归查询W获得所述的 域名解析结果。
8. 根据权利要求1所述的域名解析系统灾备建构方法，其特征在于：所述域名解析请 求与所述域名解析结果均经过同一网络地址进行中转。
9. 根据权利要求1所述的域名解析系统灾备建构方法，其特征在于：所述域名解析请 求与所述域名解析结果均被加密传输。
10. -种域名解析系统灾备建构装置，其特征在于，包括： 同步单元，用于将提供DNS服务的目标机群的数据实时同步至灾备机群，所述数据中 包含有用于提供域名解析基础的缓存数据； 查询单元，用于接收域名解析请求，响应于该域名解析请求而利用所述缓存数据进行 域名解析； 应答单元，被配置为W域名解析结果应答所述的域名解析请求。
【文档编号】H04L12/24GK104468244SQ201410852629
【公开日】2015年3月25日 申请日期:2014年12月31日 优先权日:2014年12月31日
【发明者】濮灿, 周鸿祎, 谭晓生 申请人:北京奇虎科技有限公司, 奇智软件（北京）有限公司