CN104468244B - Domain name analysis system calamity is for constructing method and device - Google Patents

Abstract

The present invention relates to a domain name resolution system disaster recovery construction method, which comprises the following steps: synchronizing the data of the target cluster providing DNS service to the disaster recovery cluster in real time, the data includes cache data for providing domain name resolution basis; receiving A domain name resolution request, using the cached data to perform domain name resolution in response to the domain name resolution request; responding to the domain name resolution request with a domain name resolution result. In addition, the invention also provides a domain name resolution system disaster recovery construction device. The construction method of the present invention can construct a disaster recovery system suitable for the existing domain name service system, and can temporarily and effectively play the role of domain name resolution service when the existing domain name service system or the network it depends on is paralyzed.

Description

Domain name resolution system disaster recovery construction method and device

technical field

The invention relates to Internet security technology, and relates to a domain name resolution system disaster recovery construction method and device.

Background technique

The disaster recovery system is a technology for backup and disaster recovery of business systems composed of network clusters, and is widely used in Internet service clusters. Usually, Internet services are provided by the normal operation of the business system, and the disaster recovery system performs real-time backup and fault detection on the normal operation of the business system, and after the business system fails or is attacked, the disaster recovery system can be used intelligently The system replaces the original business system and opens the same service to Internet users.

A disaster recovery system usually includes several major management logics of data synchronization, fault detection and business switching. Among them, the data synchronization management logic is to ensure the integrity, consistency and availability of data between the production center and the disaster recovery center; the fault detection management logic is to make fault assessment and judgment based on the data monitored by the data according to a certain strategy ;Business switching management logic, according to the fault detection results, when a major failure or disaster occurs in the business system of the production center, it is responsible for automatically or manually switching to the operation mode of using the disaster recovery system to open the service to replace the original business system.

Although the principle of the disaster recovery system has been widely used, the current DNS server and its related systems have not been taken seriously because the DNS service protocol is relatively simple, and the related technologies need to be improved.

Contents of the invention

In view of the problem in at least one aspect above, the purpose of the present invention is to provide a disaster recovery construction method for a domain name resolution system.

Correspondingly, according to the modular thinking, another object of the present invention is to provide a disaster recovery construction device for a domain name resolution system.

For realizing the purpose of the present invention, the present invention takes following technical scheme:

A domain name resolution system disaster recovery construction method of the present invention comprises the following steps:

Synchronize the data of the target cluster that provides DNS services to the disaster recovery cluster in real time, and the data includes cache data used to provide the basis for domain name resolution;

receiving a domain name resolution request, and using the cached data to perform domain name resolution in response to the domain name resolution request;

Responding to the domain name resolution request with a domain name resolution result.

In one embodiment, each step of the method is executed in at least one device of the disaster recovery cluster.

In another embodiment, each step of the method is executed by one or more processes of a single device of the disaster recovery cluster.

In yet another embodiment, the step of synchronizing data to the disaster recovery cluster in real time is performed in at least one device independent of the disaster recovery cluster, and the remaining steps are performed in the same device of the disaster recovery cluster.

In one embodiment, the cache data includes historical domain name resolution records, and the historical domain name resolution records are DNS domain name resolution records generated by DNS resolution during the normal execution of DNS services by the target cluster. When performing domain name resolution in this method , obtaining the corresponding domain name resolution result by retrieving the historical domain name resolution records.

Specifically, the historical domain name resolution record includes a mapping relationship from a domain name to a corresponding IP address.

In another embodiment, the cached data further includes an authorization information database, which stores authorization information of authorization servers at all levels of the domain name; when this method performs domain name resolution, it executes according to the corresponding authorization server information recorded in the authorization information database. Recursive query to obtain the domain name resolution result. Preferably, the authorization information database is implemented in the form of a distributed database.

Further, both the domain name resolution request and the domain name resolution result are transferred through the same network address.

Preferably, both the domain name resolution request and the domain name resolution result are encrypted for transmission.

A domain name resolution system disaster recovery construction device provided by the present invention includes:

The synchronization unit is used to synchronize the data of the target cluster that provides DNS services to the disaster recovery cluster in real time, and the data includes cache data for providing the basis for domain name resolution;

a query unit, configured to receive a domain name resolution request, and use the cached data to perform domain name resolution in response to the domain name resolution request;

The answering unit is configured to answer the domain name resolution request with a domain name resolution result.

In one embodiment, each unit of the device is configured to be executed in at least one device of the disaster recovery cluster.

In another embodiment, each unit of the device is configured to be executed by one or more processes in a single device of the disaster recovery cluster.

In yet another embodiment, the synchronization unit is configured to be executed in at least one device independent of the disaster recovery cluster, and the query unit and the response unit are configured to be executed in the same device of the disaster recovery cluster.

According to an embodiment of the present invention, the cache data includes historical domain name resolution records, which are DNS domain name resolution records generated by DNS resolution during the normal execution of DNS services by the target cluster, the When performing domain name resolution, the query unit obtains corresponding domain name resolution results by retrieving the historical domain name resolution records.

Preferably, the historical domain name resolution records include a mapping relationship from domain names to corresponding IP addresses.

According to another embodiment of the present invention, the cache data also includes an authorization information database, which stores the authorization information of the authorization server at each level of the domain name; when the query unit performs domain name resolution, it The authoritative server information, execute recursive query to obtain the domain name resolution result.

Preferably, the authorization information database is implemented in the form of a distributed database.

Further, both the domain name resolution request and the domain name resolution result are transferred through the same network address.

Preferably, both the domain name resolution request and the domain name resolution result are encrypted for transmission.

Compared with the prior art, the present invention has at least the following advantages:

1. The present invention realizes the construction of the disaster recovery system of the DNS service system. By synchronizing the data of the relevant clusters of the DNS service system in real time, it is more important to back up the history generated by the normal analysis services of these clusters during normal operations. The cache data formed by parsing records, thus, when the conventional DNS service system breaks down or is under attack, the disaster recovery system that implements the method can provide temporary and accurate DNS parsing services, build an isolated island response mode, and use disaster The backup system provides DNS resolution services for Internet users.

2. As a disaster recovery system, it is usually not directly exposed to the client. Instead, the DNS resolution server is used as the front-end service window. The DNS resolution server forwards the user's domain name resolution request to the disaster recovery system, and through the The domain name resolution result of the domain name is relayed to answer the request through the DNS resolution server, which can protect the disaster recovery system more effectively and enable the disaster recovery system to provide DNS resolution services for Internet users more smoothly.

In a nutshell, using the disaster recovery system construction method of the present invention can construct a disaster recovery system applicable to the existing domain name service system, and can temporarily and effectively play a role when the existing domain name service system or the network it depends on is paralyzed. The role of domain name resolution service.

Additional aspects and advantages of the invention will be set forth in part in the description which follows, and will become apparent from the description, or may be learned by practice of the invention.

Description of drawings

The above and/or additional aspects and advantages of the present invention will become apparent and easy to understand from the following description of the embodiments in conjunction with the accompanying drawings, wherein:

Fig. 1 is a schematic flow chart of the domain name resolution system disaster recovery construction method of the present invention;

FIG. 2 is a schematic diagram of a traditional DNS resolution service principle;

Fig. 3 is the functional block diagram of the domain name resolution system disaster recovery construction device of the present invention;

Fig. 4 is the schematic flow chart of the DNS disaster recovery system island response automatic switching method of the present invention;

Fig. 5 is a schematic flow chart of step S22 of the DNS disaster recovery system island response automatic switching method of the present invention;

Fig. 6 is the functional block diagram of the DNS disaster recovery system island response automatic switching device of the present invention;

Fig. 7 is a functional block diagram of the judging unit of the island response automatic switching device of the DNS disaster recovery system according to the present invention.

Detailed ways

Embodiments of the present invention are described in detail below, examples of which are shown in the drawings, wherein the same or similar reference numerals designate the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by referring to the figures are exemplary only for explaining the present invention and should not be construed as limiting the present invention.

Those skilled in the art will understand that unless otherwise stated, the singular forms "a", "an", "said" and "the" used herein may also include plural forms. It should be further understood that the word "comprising" used in the description of the present invention refers to the presence of said features, integers, steps, operations, elements and/or components, but does not exclude the presence or addition of one or more other features, Integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may also be present. Additionally, "connected" or "coupled" as used herein may include wireless connection or wireless coupling. The expression "and/or" used herein includes all or any elements and all combinations of one or more associated listed items.

Those skilled in the art can understand that, unless otherwise defined, all terms (including technical terms and scientific terms) used herein have the same meaning as commonly understood by those of ordinary skill in the art to which this invention belongs. It should also be understood that terms, such as those defined in commonly used dictionaries, should be understood to have meanings consistent with their meaning in the context of the prior art, and unless specifically defined as herein, are not intended to be idealized or overly Formal meaning to explain.

Those skilled in the art can understand that the "terminal" and "terminal equipment" used here not only include wireless signal receiver equipment, which only has wireless signal receiver equipment without transmission capabilities, but also include receiving and transmitting hardware. A device having receiving and transmitting hardware capable of performing bi-directional communication over a bi-directional communication link. Such equipment may include: cellular or other communication equipment, which has a single-line display or a multi-line display or a cellular or other communication equipment without a multi-line display; PCS (Personal Communications Service, personal communication system), which can combine voice, data Processing, facsimile and/or data communication capabilities; PDA (Personal Digital Assistant, Personal Digital Assistant), which may include radio frequency receiver, pager, Internet/Intranet access, web browser, notepad, calendar and/or GPS (Global Positioning System (Global Positioning System) receiver; a conventional laptop and/or palmtop computer or other device having and/or including a radio frequency receiver. As used herein, a "terminal", "terminal device" may be portable, transportable, installed in a vehicle (air, sea, and/or land), or adapted and/or configured to operate locally, and/or In distributed form, the operation operates at any other location on Earth and/or in space. The "terminal" and "terminal equipment" used here can also be communication terminals, Internet terminals, music/video playback terminals, such as PDAs, MIDs (Mobile Internet Devices, mobile Internet devices) and/or with music/video playback terminals. Functional mobile phones, smart TVs, set-top boxes and other devices.

Those skilled in the art can understand that the concepts of server, cloud, and remote network equipment used here have equivalent effects, including but not limited to computers, network hosts, single network servers, multiple network server sets, or multiple servers. Composed of clouds. Here, the cloud is composed of a large number of computers or network servers based on cloud computing (Cloud Computing), wherein cloud computing is a kind of distributed computing, a super virtual computer composed of a group of loosely coupled computer sets. In the embodiment of the present invention, the communication between the remote network equipment, the terminal equipment and the WNS server can be realized through any communication method, including but not limited to, mobile communication based on 3GPP, LTE, WIMAX, based on TCP/IP, UDP protocol Computer network communication and short-distance wireless transmission methods based on Bluetooth and infrared transmission standards.

Those skilled in the art should understand that the concepts of "application", "application program", "application software" and similar expressions referred to in the present invention are the same concepts well known to those skilled in the art, and refer to a series of computer instructions and related Computer software that is organically constructed from data resources and suitable for electronic operation. Unless otherwise specified, this naming itself is not limited by the type of programming language, level, or the operating system or platform on which it runs. Naturally, such concepts are also not limited by any form of terminal.

The relevant technical solutions related to the present invention that this article will disclose include two aspects. The first aspect is how to realize the service opening of the construction of the disaster recovery system, and the second aspect is how to realize disaster identification so as to ensure that the normal DNS service system and its disaster recovery Effective, timely, and intelligent switching between standby systems, the disclosure of these two aspects will help those skilled in the art to understand the present invention more systematically.

The first aspect of the related technical solution of the present invention is to provide a domain name resolution system construction method and device, wherein the device is an instantiation of the method based on modular thinking, and the described The method and device are implemented as software, installed in computer equipment, especially dedicated computer equipment with server capabilities, for operation, accessing the Internet to open its services, and constructing a local DNS resolution server, or constructing a local DNS resolution server. The cluster of servers is used to provide DNS domain name resolution services for clients so as to answer clients.

Referring to Fig. 1, the domain name resolution system disaster recovery construction method of the present invention is implemented as one or more operating systems such as Windows series (including but not limited to Windows XP, Window 7, Windows 8 series versions, etc.) or Unix The software of a series of operating systems (including but not limited to Unix, Linux, IOS, Ubuntu, etc.), the corresponding specific steps are realized by the operation of the software. Specifically include the following steps:

Step S11 , synchronizing the data of the target cluster providing DNS service to the disaster recovery cluster in real time, the data includes cache data for providing the basis for domain name resolution.

Usually, the server that provides DNS service is similar to the cloud architecture, which is organically constructed by multiple server devices to form a cluster, and is mutually configured with the DNS resolution server to realize DNS resolution service. Among them, the DNS service cluster is mainly used to realize the recursive system, through which the recursive calls are made to the servers at each level of the domain name in the Internet to resolve the corresponding domain name, obtain the IP address, and construct the domain name resolution result in response to external requests . As the front-end application window, the DNS resolution server is responsible for receiving the domain name resolution request from the requesting client, and providing the request to the cluster, requiring the cluster to respond with the domain name resolution result, and then responding to the corresponding domain name resolution request with the corresponding domain name resolution result.

The disaster recovery system constructed by the present invention is not only the disaster recovery of the entire domain name system of the Internet, but also based on the disaster recovery of the relevant clusters of multiple local DNS servers. The realization of the disaster recovery system is based on data synchronization; fault detection is the premise of switching operation; switching control is the management logic. However, the disaster recovery system can be opened in real time, and its fault detection and subsequent switching control can be realized by a third party. Therefore, the first aspect of the present invention does not involve technologies related to fault detection and switching control.

Data synchronization is the key basis for realizing the disaster recovery of the DNS service system in the present invention. Realize data synchronization management logic, usually adopt data backup means. Data backup is the foundation of system and data disaster recovery, the realization of low-end disaster recovery, and the powerful guarantee of high-end disaster recovery (real-time data protection). Currently, backup technologies mainly include snapshot backup, offline backup, and remote storage backup. The backup system realizes a complete copy at a certain point in time of the operating system, file system, application program, database system and other data sets of the computer information system through the backup strategy. The copied data is in an offline state and cannot be accessed immediately. Use the backup data through corresponding operations, such as restoring. On the premise of building a high-end disaster recovery system, the backup of the local system must be done well, which is the starting point of disaster recovery technology.

When the present invention realizes data synchronization, a high-end disaster recovery method is adopted to realize real-time data protection for DNS service clusters. Multiple copies of the same data are stored to avoid physical failures. Real-time data protection requires data backup as a premise, and it cannot prevent human misoperation and malicious operations. It should be emphasized that the purpose of disaster recovery is to allow data to be accessed when a disaster occurs, and to ensure data integrity through real-time data protection. Therefore, the disaster recovery system constructed by the present invention cannot guarantee the latest data.

As mentioned above, data backup is a means of disaster recovery, not an end. The purpose of disaster recovery is data access. Therefore, application recovery, network recovery and related switching control are also the key to disaster recovery. Specifically, after the disaster occurs, the disaster recovery center takes over the entire process of the original production center, such as database switching, application restart, network switching, etc. The whole process of switching back again. These processes can be manually switched or completed through an automated process; and how to make a corresponding assessment based on this is also a problem that technicians need to solve. The implementation of this part will be disclosed in detail through another method and device later in the present invention, so it will not be listed for the time being.

It can be seen that the data of the target cluster providing DNS service is synchronized to the disaster recovery cluster in real time through the software configured as the method of the present invention, which is the basis for realizing the disaster recovery system of the present invention. In order to further illustrate the synchronized data, please refer to an application example as follows.

Please combine with Figure 2, and take the resolution process of the domain name www.163.com as an example to illustrate the main process of DNS resolution under normal circumstances:

Step 1: The user computer sends a request to resolve www.163.com to the local DNS (analysis) server set on its system. The so-called local DNS server refers to a DNS service IP address, which can be obtained automatically from the operator or manually set.

Step 2: The local DNS server will check whether there is a cache of this domain name in its own space, and if not, it will send a domain name resolution request of www.163.com to the root server.

Step 3: After receiving the resolution request of the local DNS server for the domain name, the root server analyzes the requested domain name and returns the IP address of the server of the domain name node of the local server .com.

Step 4: After receiving the server IP address of the .com top-level domain, the local DNS server sends a resolution request for www.163.com to the .com top-level domain.

Step 5: After receiving the resolution request about www.163.com, the .com top-level domain server returns to the local DNS server the IP address of the DNS server about the second-level domain 163.

Step 6: The local DNS server continues to initiate a resolution request for www.163.com to the DNS server of the secondary domain 163.

Step 7: The management server of the domain 163 manages all subdomain names under 163.com. Its domain name space has the subdomain name www, and its corresponding IP address is 111.1.53.220, so the DNS server of the 163.com domain will return the IP address 111.1.53.220 corresponding to www.163.com to the local DNS server.

Step 8: After receiving the resolution result of www.163.com from the domain server 163.com, the local DNS server returns the corresponding IP address 111.1.53.220 to the user, and will keep the result for a period of time for other users to query .

Step 9: After obtaining the IP address 111.1.53.220 corresponding to the www.163.com domain name, the user's computer starts to request webpage content from the IP address 111.1.53.220. At this point, a complete DNS request resolution process ends.

In the above example, the local DNS server is simplified as one server. In fact, usually, its background may be realized by the aforementioned cluster composed of multiple servers. The DNS resolution server, in any case, needs to act as the front-end DNS server of the application. Those skilled in the art should know this.

In the above example, step 2 will first check whether there is a request for the domain name in the domain name resolution request in the space of the local DNS server, and step 8 introduces the fact that the domain name resolution result will be saved for a period of time for other users to query . It can be known from this that the data of the target cluster must contain some cached data, and these cached data are usually stored in a log format, which can also be improved in the form of a database in the present invention.

In an embodiment of the present invention related to the realization of the cached data, the format of the server cluster that normally provides DNS services can be used, so that the cached data includes historical domain name resolution records, and the historical domain name resolution records are the normal execution of DNS by the target cluster. The DNS domain name resolution records generated by DNS resolution during the service process are usually stored in the format of log files. Each domain name resolution record includes at least a domain name and an IP address corresponding to the domain name. The correspondence between the domain name and the IP address here mainly refers to the mapping relationship between them. Further, each domain name resolution record in the cache database can be given a life cycle, within the life cycle, the record is valid, and if it exceeds the life cycle, it can be deleted or ignored by the present invention. When the present invention needs to use the cache database for resolving domain names, it first retrieves the cache database from the historical domain name resolution records based on the domain name in the request data, finds the corresponding valid records, obtains the corresponding IP address, and then responds The corresponding domain name resolution request. Of course, if the life cycle is exceeded, or there is no corresponding record in the cached data, the query still needs to be realized through the recursive system (if the domain name servers at all levels on the public network can still be accessed normally when the disaster recovery system is enabled). Since the same terminal device is generally used by the same user, their online behavior shows a certain inertia and is used to visiting some specific websites. Therefore, through this cache data and related technologies, more efficient and faster DNS resolution can be improved for users. service, and can save the traffic consumption of some mobile terminal devices. For the situation where the server at each level of the domain name has been paralyzed and cannot be recursively queried, these cached data will play a crucial role in parsing.

In another embodiment of the present invention related to the implementation of cached data, the cached data includes an authorization information database, which can be constructed using the known Anycast (Anycast) technology distribution. The authorization information database stores the authorization information of the authorization server at each level of the domain name; when performing domain name resolution, according to the corresponding authorization server information recorded in the authorization information database, a recursive query can be performed to obtain the domain name resolution result, applicable It is used in the scenario where DNS recursive query cluster is paralyzed.

The authorization information database is also constructed on the basis of the historical domain name resolution records. As we all know, in the process of performing recursive query, the domain name service cluster can obtain the authorization information of the authorization server corresponding to each level of the domain name, and use the authorization information to construct the authorization information database, which is used to realize the virtual root node and send The Internet opens the virtual root node service to achieve a more systematic disaster recovery analysis effect. In this case, according to the system implemented in the present invention, the virtual root node technology can also be combined to provide security services. When the root node has a DNS resolution failure, the virtual root node can replace the root node to realize the DNS resolution function. Of course, enough information must be stored in the authorization information database, that is, all DNS requests and corresponding authorization information in the specified area are stored in the authorization information database, so that the virtual root node can have enough resources to answer the DNS requests. Therefore, the realization of the virtual root node is realized on the basis of the authorization information database. Combined with the newly added authorization information database and virtual root node, it can provide DNS resolution function for the client when the root node resolves the failure, which can reduce DNS single point of failure and improve DNS defense attack capability, and can also set up access to the virtual root node Authority control, shielding DNS attack data, improving the security and stability of DNS resolution. For dangerous DNS attacks, if no specific authorization information can be queried from the authorization information database, the virtual root node will not provide resolution services for it.

According to the two embodiments disclosed above for realizing the cached data and their corresponding extended functions, those skilled in the art should know that more specific implementation forms of the cached data and their extended applications can be obtained by those skilled in the art according to The needs of the present invention are realized flexibly. For example, the cached data can also be understood as including the historical domain name resolution records and the authorization information database in the above two embodiments at the same time, and not only the historical domain name resolution records can be used as a temporary cache, but also the The above-mentioned historical domain name resolution records are stored in the relevant independent data tables of the authorization information database as data with a longer life cycle. When the temporary cache reaches a certain length of time and is frequently used, the temporary cached historical domain name resolution records can be converted into Historical domain name resolution records with a longer life cycle are stored in the data table, and are used as query objects prior to the recursive system in the subsequent domain name resolution.

The topology and hierarchical structure of the DNS service cluster, and the topology and hierarchical structure of the disaster recovery system can be realized by those skilled in the art according to known network principles. In the present invention, more attention is paid to the data and control relationship between the two. Therefore, the relationship between its topology and hierarchical structure will not be described in detail.

As mentioned above, after synchronizing the data on the DNS service cluster, especially the cached data, to the disaster recovery cluster, the disaster recovery cluster will have the corresponding resolution capability, and its resolution service can be further opened in the subsequent steps.

Step S12, receiving a domain name resolution request, and using the cached data to perform domain name resolution in response to the domain name resolution request.

The disaster recovery system of the present invention has an independent virtual root node because it efficiently utilizes cached data and realizes the function of a virtual root node. Specifically, an authorization information database acts as a virtual root domain. When the root domain or top-level domain server fails and cannot serve normally, or even when all other external authoritative servers fail, the local DNS system may become an island of resolution. In this case, in theory, this system should be allowed to achieve a similar Disaster recovery mode, start the disaster recovery emergency response mode, to ensure that the Internet is basically running normally before the root zone server or authorization server is repaired, leaving enough time for system repair and recovery.

With the help of the switching method that will be disclosed later in the present invention, the relevant system that applies the related technical solution of the present invention, after the disaster occurs, the relevant DNS service function will be switched to point to the disaster recovery center, that is, the disaster recovery system constructed by the present invention fleet. However, the client needs to revisit the service of the disaster recovery node, which brings another problem, how to switch the network. Specifically, it is how the local application access path (network address) of the DNS server is changed from pointing to the original production center to pointing to the disaster recovery center. After the disaster recovery, it needs to point to the original production center in turn. The easiest way is to change the IP mapping relationship of the DNS resolution server, from the original destination address to the network address of the disaster recovery system that provides DNS services. Before the disaster, the IP address is mapped to the server of the production center; after the disaster, the IP address is mapped to the server of the disaster recovery center; after the disaster is restored, the IP is mapped to the server of the production center.

The details of realizing such intelligent switching will be described in detail in the second aspect of the present invention, and the first aspect of the present invention will be described on the premise that such intelligent switching can be realized. In the first aspect, the client forwards its domain name resolution request to the DNS resolution server, and the DNS resolution server forwards the domain name resolution request to the service of the disaster recovery system, and the service of the disaster recovery system executes the resolution and returns the domain name to the DNS resolution server The resolution result, and then the DNS resolution server responds to the original domain name resolution request with the domain name resolution result.

Therefore, after the disaster recovery system of the present invention receives the domain name resolution request forwarded by the DNS resolution server, it needs to resolve it. Its parsing scheme can flexibly implement different parsing mechanisms in combination with the aforementioned variants, for example:

In the first resolution mechanism, corresponding to the case where the cached data only includes historical domain name resolution records, the disaster recovery system can extract the domain name from the domain name resolution request and prioritize the massive historical domain name resolution records stored in the cache data Search whether there is a record corresponding to the domain name, and if it exists, use the IP address in the record that has a mapping relationship with the domain name as the domain name resolution result. Of course, factors related to setting a life cycle for historical domain name resolution records can also be considered, and historical domain name resolution records beyond the preset life cycle will not be considered. However, this strategy is generally not recommended, because if the disaster recovery system is based on the failure of the public network or servers at all levels of the domain name, it may not be possible to obtain the actual domain name by recursively querying the servers at each level of the domain name through the public network. There is little point in applying this strategy. Considering that the servers at all levels of the domain name may still be effective, but the cluster of DNS servers has broken down, in this case, if the IP address cannot be obtained from the cached data, then the disaster recovery system of the present invention can further perform recursive query, if the IP address can be obtained Effective resolution can generate more accurate domain name resolution results in the same way.

The second parsing mechanism corresponds to the case where the cached data includes the authorization information database. After the disaster recovery system extracts the domain name from the domain name resolution request, the authorization information is used first to execute the query, and if a valid IP resolution result can be obtained, it is answered accordingly. If the authorization information database includes a data table corresponding to the historical domain name resolution records, the first resolution mechanism can be used to try to obtain the result from the data table first, and if the result cannot be obtained, then use the authorization information in the authorization information database. Inquiry; or vice versa, first use authorization information to inquire, and then inquire cannot use historical domain name resolution records to inquire.

The third resolution mechanism corresponds to the situation that the existing cache data includes both the authorization information database and the historical domain name resolution records as the cache data, and the authorization information database also has preferred historical domain name resolution records. In this case, it can also be flexibly used in combination with the aforementioned two mechanisms. For example, query from the cached historical domain name resolution records first, and then query from the historical domain name resolution records in the data table, and then query cannot further use authorization information for query; or vice versa.

From the above analysis of various resolution mechanisms, it can be seen that as long as an effective storage expression system is built using cached data in the previous step, it can be flexibly and effectively used in this step, and finally the corresponding domain name can be obtained parse the result.

Step S13, responding to the domain name resolution request with a domain name resolution result.

After the domain name resolution result is obtained in the previous step, in this step, the domain name resolution result can be fed back to the DNS resolution server for forwarding according to the forwarder address of the domain name resolution request, and the DNS resolution server will reply the domain name resolution result to the originator of the original domain name resolution request. Complete the domain name resolution process.

It should be pointed out that the disaster recovery system of the present invention may not directly receive the domain name resolution request initiated by the client, nor directly respond to the domain name resolution result to the client, but through the same network address, mainly referring to the domain name pointed to by the IP address. The DNS resolution server implements the transfer of domain name resolution requests and domain name resolution results. Due to the higher security requirements of the disaster recovery system, domain name resolution requests and domain name resolution results can be encrypted before being transmitted between the DNS resolution server and the disaster recovery system cluster. There are various encryption methods, and public key encryption is preferred (non symmetric encryption).

Although the content described above is based on the disaster recovery cluster, the software implemented according to the first aspect of the present invention can be flexibly installed in multiple devices. The software of the first aspect of the present invention can be considered to be secured in the following ways to form a system for realizing the method and device of the first aspect of the present invention:

In one mode, each step of the present invention is implemented in the same software, and installed in a single device of the disaster recovery cluster of the present invention, while other devices of the disaster recovery cluster only need to be equipped with the single device The client module for communication forms a mode similar to the C/S architecture to realize centralized control of the cluster. As a variation example of this method, it is shown at the operation level that the corresponding software can run a single service process or multiple coordinated processes to execute the method. A single service process is relatively easy to understand. As for the situation of multiple processes, for example , step S11 of the present invention can be implemented as a process, and steps S12 and S13 can be implemented as a process, and the two processes work independently to complete their respective tasks. Both processes can be set as system service processes.

In another way, considering the mutual independence between step S11 and the other two steps, it can be considered to implement the data synchronization function of step S11 as a single piece of software installed in an independent device independent of the disaster recovery cluster, such as the In the DNS (analysis) server, the other two steps are still implemented as the same software installed in a front-end service device of the disaster recovery cluster, and the two are installed in two devices, which are not contradictory and cooperate with each other. The same reason can also be used meet the requirements of the present invention.

Therefore, it can be known that the knowledge related to system construction and software implementation in the application process of the present invention can be flexibly implemented in combination with known technologies in this field, and those skilled in the art should not limit their understanding of the technical solution of the first aspect of the present invention.

Please refer to FIG. 3 , the domain name resolution system disaster recovery construction device of the present invention, on the basis of the aforementioned method, is improved and implemented according to the modular thinking, and specifically includes the cache data obtained by synchronizing the synchronization unit 11, the query unit 12, and the response unit 13 :

The synchronization unit 11 is used for synchronizing the data of the target cluster providing DNS service to the disaster recovery cluster in real time, and the data includes the cache data used to provide the basis for domain name resolution.

Usually, the server that provides DNS service is similar to the cloud architecture, which is organically constructed by multiple server devices to form a cluster, and is mutually configured with the DNS resolution server to realize DNS resolution service. Among them, the DNS service cluster is mainly used to realize the recursive system, through which the recursive calls are made to the servers at each level of the domain name in the Internet to resolve the corresponding domain name, obtain the IP address, and construct the domain name resolution result in response to external requests . As the front-end application window, the DNS resolution server is responsible for receiving the domain name resolution request from the requesting client, and providing the request to the cluster, requiring the cluster to respond with the domain name resolution result, and then responding to the corresponding domain name resolution request with the corresponding domain name resolution result.

The disaster recovery system constructed by the present invention is not only the disaster recovery of the entire domain name system of the Internet, but also based on the disaster recovery of the relevant clusters of multiple local DNS servers. The realization of the disaster recovery system is based on data synchronization; fault detection is the premise of switching operation; switching control is the management logic. However, the disaster recovery system can be opened in real time, and its fault detection and subsequent switching control can be realized by a third party. Therefore, the first aspect of the present invention does not involve technologies related to fault detection and switching control.

Data synchronization is the key basis for realizing the disaster recovery of the DNS service system in the present invention. Realize data synchronization management logic, usually adopt data backup means. Data backup is the foundation of system and data disaster recovery, the realization of low-end disaster recovery, and the powerful guarantee of high-end disaster recovery (real-time data protection). Currently, backup technologies mainly include snapshot backup, offline backup, and remote storage backup. The backup system realizes a complete copy at a certain point in time of the operating system, file system, application program, database system and other data sets of the computer information system through the backup strategy. The copied data is in an offline state and cannot be accessed immediately. Use the backup data through corresponding operations, such as restoring. On the premise of building a high-end disaster recovery system, the backup of the local system must be done well, which is the starting point of disaster recovery technology.

When the present invention realizes data synchronization, a high-end disaster recovery method is adopted to realize real-time data protection for DNS service clusters. Multiple copies of the same data are stored to avoid physical failures. Real-time data protection requires data backup as a premise, and it cannot prevent human misoperation and malicious operations. It should be emphasized that the purpose of disaster recovery is to allow data to be accessed when a disaster occurs, and to ensure data integrity through real-time data protection. Therefore, the disaster recovery system constructed by the present invention cannot guarantee the latest data.

As mentioned above, data backup is a means of disaster recovery, not an end. The purpose of disaster recovery is data access. Therefore, application recovery, network recovery and related switching control are also the key to disaster recovery. Specifically, after the disaster occurs, the disaster recovery center takes over the entire process of the original production center, such as database switching, application restart, network switching, etc. The whole process of switching back again. These processes can be manually switched or completed through an automated process; and how to make a corresponding assessment based on this is also a problem that technicians need to solve. The implementation of this part will be disclosed in detail through another method and device later in the present invention, so it will not be listed for the time being.

It can be seen from this that the data of the target cluster providing DNS service is synchronized to the disaster recovery cluster in real time through the software configured as the device of the present invention, which is the basis for realizing the disaster recovery system of the present invention. In order to further illustrate the synchronized data, please refer to an application example as follows.

Please combine with Figure 2, and take the resolution process of the domain name www.163.com as an example to illustrate the main process of DNS resolution under normal circumstances:

Step 1: The user computer sends a request to resolve www.163.com to the local DNS (analysis) server set on its system. The so-called local DNS server refers to a DNS service IP address, which can be obtained automatically from the operator or manually set.

Step 2: The local DNS server will check whether there is a cache of this domain name in its own space, and if not, it will send a domain name resolution request of www.163.com to the root server.

Step 3: After receiving the resolution request of the local DNS server for the domain name, the root server analyzes the requested domain name and returns the IP address of the server of the domain name node of the local server .com.

Step 4: After receiving the server IP address of the .com top-level domain, the local DNS server sends a resolution request for www.163.com to the .com top-level domain.

Step 5: After receiving the resolution request about www.163.com, the .com top-level domain server returns to the local DNS server the IP address of the DNS server about the second-level domain 163.

Step 6: The local DNS server continues to initiate a resolution request for www.163.com to the DNS server of the secondary domain 163.

Step 7: The management server of the domain 163 manages all subdomain names under 163.com. Its domain name space has the subdomain name www, and its corresponding IP address is 111.1.53.220, so the DNS server of the 163.com domain will return the IP address 111.1.53.220 corresponding to www.163.com to the local DNS server.

Step 8: After receiving the resolution result of www.163.com from the domain server 163.com, the local DNS server returns the corresponding IP address 111.1.53.220 to the user, and will keep the result for a period of time for other users to query .

Step 9: After obtaining the IP address 111.1.53.220 corresponding to the www.163.com domain name, the user's computer starts to request webpage content from the IP address 111.1.53.220. At this point, a complete DNS request resolution process ends.

In the above example, the local DNS server is simplified as one server. In fact, usually, its background may be realized by the aforementioned cluster composed of multiple servers. The DNS resolution server, in any case, needs to act as the front-end DNS server of the application. Those skilled in the art should know this.

In the above example, step 2 will first check whether there is a request for the domain name in the domain name resolution request in the space of the local DNS server, and step 8 introduces the fact that the domain name resolution result will be saved for a period of time for other users to query . It can be known from this that the data of the target cluster must contain some cached data, and these cached data are usually stored in a log format, which can also be improved in the form of a database in the present invention.

In an embodiment of the present invention related to the realization of the cached data, the format of the server cluster that normally provides DNS services can be used, so that the cached data includes historical domain name resolution records, and the historical domain name resolution records are the normal execution of DNS by the target cluster. The DNS domain name resolution records generated by DNS resolution during the service process are usually stored in the format of log files. Each domain name resolution record includes at least a domain name and an IP address corresponding to the domain name. The correspondence between the domain name and the IP address here mainly refers to the mapping relationship between them. Further, each domain name resolution record in the cache database can be given a life cycle, within the life cycle, the record is valid, and if it exceeds the life cycle, it can be deleted or ignored by the present invention. When the present invention needs to use the cache database for resolving domain names, it first retrieves the cache database from the historical domain name resolution records based on the domain name in the request data, finds the corresponding valid records, obtains the corresponding IP address, and then responds The corresponding domain name resolution request. Of course, if the life cycle is exceeded, or there is no corresponding record in the cached data, the query still needs to be realized through the recursive system (if the domain name servers at all levels on the public network can still be accessed normally when the disaster recovery system is enabled). Since the same terminal device is generally used by the same user, their online behavior shows a certain inertia and is used to visiting some specific websites. Therefore, through this cache data and related technologies, more efficient and faster DNS resolution can be improved for users. service, and can save the traffic consumption of some mobile terminal devices. For the situation where the server at each level of the domain name has been paralyzed and cannot be recursively queried, these cached data will play a crucial role in parsing.

In another embodiment of the present invention related to the realization of the cached data, the cached data includes an authorization information database, and this database can be constructed using the known BGP Anycast (Anycast) technology distribution. The authorization information database stores the authorization information of the authorization server at each level of the domain name; when performing domain name resolution, according to the corresponding authorization server information recorded in the authorization information database, a recursive query can be performed to obtain the domain name resolution result, applicable It is used in the scenario where DNS recursive query cluster is paralyzed.

The authorization information database is also constructed on the basis of the historical domain name resolution records. As we all know, in the process of performing recursive query, the domain name service cluster can obtain the authorization information of the authorization server corresponding to each level of the domain name, and use the authorization information to construct the authorization information database, which is used to realize the virtual root node and send The Internet opens the virtual root node service to achieve a more systematic disaster recovery analysis effect. In this case, according to the system implemented in the present invention, the virtual root node technology can also be combined to provide security services. When the root node has a DNS resolution failure, the virtual root node can replace the root node to realize the DNS resolution function. Of course, enough information must be stored in the authorization information database, that is, all DNS requests and corresponding authorization information in the specified area are stored in the authorization information database, so that the virtual root node can have enough resources to answer the DNS requests. Therefore, the realization of the virtual root node is realized on the basis of the authorization information database. Combined with the newly added authorization information database and virtual root node, it can provide DNS resolution function for the client when the root node resolves the failure, which can reduce DNS single point of failure and improve DNS defense attack capability, and can also set up access to the virtual root node Authority control, shielding DNS attack data, improving the security and stability of DNS resolution. For dangerous DNS attacks, if no specific authorization information can be queried from the authorization information database, the virtual root node will not provide resolution services for it.

According to the two embodiments disclosed above for realizing the cached data and their corresponding extended functions, those skilled in the art should know that more specific implementation forms of the cached data and their extended applications can be obtained by those skilled in the art according to The needs of the present invention are realized flexibly. For example, the cached data can also be understood as including the historical domain name resolution records and the authorization information database in the above two embodiments at the same time, and not only the historical domain name resolution records can be used as a temporary cache, but also the The above-mentioned historical domain name resolution records are stored in the relevant independent data tables of the authorization information database as data with a longer life cycle. When the temporary cache reaches a certain length of time and is frequently used, the temporary cached historical domain name resolution records can be converted into Historical domain name resolution records with a longer life cycle are stored in the data table, and are used as query objects prior to the recursive system in the subsequent domain name resolution.

The topology and hierarchical structure of the DNS service cluster, and the topology and hierarchical structure of the disaster recovery system can be realized by those skilled in the art according to known network principles. In the present invention, more attention is paid to the data and control relationship between the two. Therefore, the relationship between its topology and hierarchical structure will not be described in detail.

As mentioned above, after synchronizing the data on the DNS service cluster, especially the cached data, to the disaster recovery cluster, the disaster recovery cluster will have the corresponding resolution capability, and its resolution service can be further opened in the future.

The query unit 12 is configured to receive a domain name resolution request, and use the cached data to perform domain name resolution in response to the domain name resolution request.

The disaster recovery system of the present invention has an independent virtual root node because it efficiently utilizes cached data and realizes the function of a virtual root node. Specifically, an authorization information database acts as a virtual root domain. When the root domain or top-level domain server fails and cannot serve normally, or even when all other external authoritative servers fail, the local DNS system may become an island of resolution. In this case, in theory, this system should be allowed to achieve a similar Disaster recovery mode, start the disaster recovery emergency response mode, to ensure that the Internet is basically running normally before the root zone server or authorization server is repaired, leaving enough time for system repair and recovery.

With the help of the switching method that will be disclosed later in the present invention, the relevant system that applies the related technical solution of the present invention, after the disaster occurs, the relevant DNS service function will be switched to point to the disaster recovery center, that is, the disaster recovery system constructed by the present invention fleet. However, the client needs to revisit the service of the disaster recovery node, which brings another problem, how to switch the network. Specifically, it is how the local application access path (network address) of the DNS server is changed from pointing to the original production center to pointing to the disaster recovery center. After the disaster recovery, it needs to point to the original production center in turn. The easiest way is to change the IP mapping relationship of the DNS resolution server, from the original destination address to the network address of the disaster recovery system that provides DNS services. Before the disaster, the IP address is mapped to the server of the production center; after the disaster, the IP address is mapped to the server of the disaster recovery center; after the disaster is restored, the IP is mapped to the server of the production center.

The details of realizing such intelligent switching will be described in detail in the second aspect of the present invention, and the first aspect of the present invention will be described on the premise that such intelligent switching can be realized. In the first aspect, the client forwards its domain name resolution request to the DNS resolution server, and the DNS resolution server forwards the domain name resolution request to the service of the disaster recovery system, and the service of the disaster recovery system executes the resolution and returns the domain name to the DNS resolution server The resolution result, and then the DNS resolution server responds to the original domain name resolution request with the domain name resolution result.

Therefore, after the disaster recovery system of the present invention receives the domain name resolution request forwarded by the DNS resolution server, it needs to resolve it. Its parsing scheme can flexibly implement different parsing mechanisms in combination with the aforementioned variants, for example:

In the first resolution mechanism, corresponding to the case where the cached data only includes historical domain name resolution records, the disaster recovery system can extract the domain name from the domain name resolution request and prioritize the massive historical domain name resolution records stored in the cache data Search whether there is a record corresponding to the domain name, and if it exists, use the IP address in the record that has a mapping relationship with the domain name as the domain name resolution result. Of course, factors related to setting a life cycle for historical domain name resolution records can also be considered, and historical domain name resolution records beyond the preset life cycle will not be considered. However, this strategy is generally not recommended, because if the disaster recovery system is based on the failure of the public network or servers at all levels of the domain name, it may not be possible to obtain the actual domain name by recursively querying the servers at each level of the domain name through the public network. There is little point in applying this strategy. Considering that the servers at all levels of the domain name may still be effective, but the cluster of DNS servers has broken down, in this case, if the IP address cannot be obtained from the cached data, then the disaster recovery system of the present invention can further perform recursive query, if the IP address can be obtained Effective resolution can generate more accurate domain name resolution results in the same way.

The second parsing mechanism corresponds to the case where the cached data includes the authorization information database. After the disaster recovery system extracts the domain name from the domain name resolution request, the authorization information is used first to execute the query, and if a valid IP resolution result can be obtained, it is answered accordingly. If the authorization information database includes a data table corresponding to the historical domain name resolution records, the first resolution mechanism can be used to try to obtain the result from the data table first, and if the result cannot be obtained, then use the authorization information in the authorization information database. Inquiry; or vice versa, first use authorization information to inquire, and then inquire cannot use historical domain name resolution records to inquire.

The third resolution mechanism corresponds to the situation that the existing cache data includes both the authorization information database and the historical domain name resolution records as the cache data, and the authorization information database also has preferred historical domain name resolution records. In this case, it can also be flexibly used in combination with the aforementioned two mechanisms. For example, query from the cached historical domain name resolution records first, and then query from the historical domain name resolution records in the data table, and then query cannot further use authorization information for query; or vice versa.

From the above analysis of various analysis mechanisms, it can be seen that as long as an effective storage expression system is built using cached data in the synchronization unit 11, it can be flexibly and effectively used in the query unit 12, and finally the corresponding The domain name resolution result of .

The response unit 13 is configured to respond to the domain name resolution request with a domain name resolution result.

After the query unit 12 obtains the domain name resolution result, the response unit 13 can feed back the domain name resolution result to the DNS resolution server for transfer according to the forwarder address of the domain name resolution request, and the DNS resolution server will respond to the original domain name resolution request with the domain name resolution result The initiator completes the domain name resolution process.

It should be pointed out that the disaster recovery system of the present invention may not directly receive the domain name resolution request initiated by the client, nor directly respond to the domain name resolution result to the client, but through the same network address, mainly referring to the domain name pointed to by the IP address. The DNS resolution server implements the transfer of domain name resolution requests and domain name resolution results. Due to the higher security requirements of the disaster recovery system, domain name resolution requests and domain name resolution results can be encrypted before being transmitted between the DNS resolution server and the disaster recovery system cluster. There are various encryption methods, and public key encryption is preferred (non symmetric encryption).

Although the content described above is based on the disaster recovery cluster, the software implemented according to the first aspect of the present invention can be flexibly installed in multiple devices. The software of the first aspect of the present invention can be considered to be secured in the following ways to form a system for realizing the method and device of the first aspect of the present invention:

In one mode, the synchronization unit 11, the query unit 12 and the response unit 13 of the present invention are constructed by the same software, and this software is installed in a single device of the disaster recovery cluster of the present invention, while other equipment of the disaster recovery cluster It only needs to be equipped with a client module that communicates with the single device, so as to form a mode similar to the C/S architecture to realize centralized control of the cluster. As a variation example of this method, it is shown at the operation level that the corresponding software can run a single service process or multiple coordinated processes to execute the units described herein. A single service process is relatively easy to understand. As for multiple processes In this case, for example, the synchronization unit 11 of the present invention can be implemented as a process, and the step query unit 12 and the response unit 13 can be implemented as a process, and the two processes work independently to complete their respective tasks. Both processes can be set as system service processes.

In another way, considering the mutual independence of the synchronization unit 11 and the other two units, it can be considered that the data synchronization function of the synchronization unit 11 is constructed using a single software, and the software is installed on a computer independent of the disaster recovery cluster. In an independent device, such as the DNS (analysis) server mentioned above, while the other two units are still constructed with the same software, the software is installed in a front-end service device of the disaster recovery cluster, and the two are distributed in two In the equipment, parallelism does not interfere with each other and cooperates with each other, and the requirements of the present invention can also be met in the same way.

Therefore, it can be known that the knowledge related to system construction and software implementation in the application process of the present invention can be flexibly implemented in combination with known technologies in this field, and those skilled in the art should not limit their understanding of the technical solution of the first aspect of the present invention.

Further, please continue to understand the technical solution of the second aspect of the present invention. Similarly, the technical solution of the second aspect of the present invention can also implement related software, which can be installed in a computer device with server capabilities, and cooperate with an operating system that is convenient for server construction to provide corresponding services.

The task of the technical solution of the second aspect of the present invention is to realize the fault detection and intelligent switching control logic of the disaster recovery system, but it can be independently installed in other devices independently of the technical solution of the first aspect of the present invention. Usually, according to the method and device involved in the technical solution of the second aspect of the present invention, it is installed in the DNS (analysis) server as the front end of the business, so as to identify the cluster or related network faults that provide DNS services at the first time, and quickly The cluster that provides the DNS service is positioned to the disaster recovery cluster constructed by the aforementioned technical solution of the first aspect. And when the fault is cleared, it can be switched back quickly. It should be pointed out that the above-mentioned content adopted in the technical solution of the first aspect of the present invention will also be cited in the following disclosure of the technical solution of the second aspect of the present invention, and those skilled in the art should not separate the connection between these two aspects .

Please refer to Fig. 4, a kind of DNS disaster recovery system island answer automatic switching method that the present invention provides for this purpose, comprises the following steps:

Step S21 , receiving and collecting operation data of the machine cluster providing DNS service.

As the application front-end DNS server that realizes the automatic switching method of the present invention, it has a communication relationship with the clusters that DNS provides DNS services, and can collect these clusters through predetermined communication ports including agreed TCP or UDP protocol ports, etc. The operating data of each device in the system, the type of operating data selected is very flexible, and can also be used flexibly. Here are some running data for reference:

1. Performance data, which is used to represent the DNS resolution throughput information of the cluster per second. Usually, under normal use, the number of DNS resolutions that each machine can perform is limited and relatively constant. Therefore, through a preset throughput threshold, it is possible to judge a certain device or determine the status of the entire cluster. Is the throughput normal. The throughput referred to here refers to the number of times of receiving domain name resolution requests and returning corresponding domain name resolution results as responses.

2. Machine data, which is used to represent the operation information of at least one hardware of each device in the cluster. Machine data mainly refers to the CPU and/or memory usage status when the machine is running. For example, if the CPU is in a state of high utilization such as 100% for a long time, and the state of available memory is low for a long time, it may mean that some unnecessary busy. In theory, these machine data can also be used to determine the operating quality of a single device or the entire fleet.

3. Application data, which is used to represent the log information of domain name resolution records. The log information referred to here mainly refers to the original information used to form the historical domain name resolution records of the cache data in the first aspect of the present invention. Such information can be used in the subsequent development of authorization information in the disaster recovery system, or it can only be used as a basis for judgment in this method. Using these log information, it can at least be seen whether there are large-scale parsing exceptions, such as a large number of domain name resolution requests that cannot obtain corresponding normal resolution, etc. Therefore, application data can obviously also be used as a running data.

4. Alarm data, which is used to represent the alarm information generated by the fleet. The alarm data referred to here is mainly the alarm data generated by the system monitoring function of the equipment in the cluster, such as the alarm data generated by the "management" component of the Windows system. Using these data, the operating status of a single device or cluster can also be determined .

5. Difference data, which is used to represent the difference information between the cache pool and the database. The buffer pool referred to here refers to the data in the buffer space for buffering historical domain name resolution records, while the database referred to here refers to a dedicated database that has extracted historical domain name resolution records from the buffer space into a standardized storage format. in the file. These difference data are recorded mainly to provide information about the difference between the temporarily cached data and the canonical cached data.

The various types of operating data given above are just enumerations of specific types of operating data, and do not make a comprehensive limitation on the operating data. After these operating data are collected, further benefits should be carried out depending on their different functions. In different situations, the types of operating data used may be different. These flexible changes will be further introduced later.

Step S22 , performing calculations on the operation data according to preset configuration information to form an operation state determination result of the DNS service cluster.

On the basis of collecting a large amount of operating data about the clusters that provide DNS services, the DNS server can carry out intelligent data mining, combined with the principle of machine learning, to make more intelligent and accurate judgments on the operating status of the normal clusters. In order to achieve this purpose, please refer to Figure 5, this step is implemented by the following specific steps:

Step S221, establishing an index data set as a judgment criterion.

The establishment of the index data set needs to be determined in conjunction with the selection of the operation data, and the selection of the operation data depends on the preset configuration information. The indicator data sets corresponding to the four situations in the table are given below for reference:

1. Performance data: 1000, machine data: 90%

2. Alarm data: danger, machine data: 10%

3. Difference data: 90%, application data: file.log

4. Application data: file.log

According to the above four index data sets, the index established by the present invention can be understood as follows:

1. When the performance data reaches the throughput of 1000 times but the machine data (CPU and/or memory ratio) has reached 90%, it constitutes the judgment criterion of the present invention.

2. When only 10% of the machine data (CPU and/or memory ratio) is used and the alarm data of "dangerous" state appears, it constitutes the judgment criterion of the present invention.

3. When the difference data in the file whose application data is file.log reaches 90%, it constitutes the judgment criterion of the present invention.

4. Only use the application data file.log file as the real-time judgment benchmark.

On the basis of constructing the above-mentioned indicator data sets, further processing can be performed based on these indicator data sets. It should be noted that these indicator data sets can be given before the software is installed, or can be maintained on demand through the user interface provided by the software. These metrics data sets can be stored in a file for verification of the practice of the invention.

Although four sets of indicator data sets are given above, in some embodiments, the indicator data sets can also be understood as only a set of standard indicators, which are used to characterize the normal state of the cluster that provides DNS services, so as to simplify Difficulty of software programming.

Step S222: Select or generate a corresponding algorithm according to preset configuration information.

In some cases, there may be a one-to-one correspondence between the configuration information and the indicator dataset, but if the indicator dataset is only a standard set, it only needs to correspond to this set of indicator datasets. Configuration information is usually policy configuration information expressed in a certain format specified by the present invention. For example, in the present invention, for the aforementioned example with multiple sets of indicator data sets, the following policy configuration information can be formulated, and the corresponding meanings are also given in the following table:

serial number first element second element algorithm representational meaning 1 performance data machine data A Algorithm A for performance and machine data 2 Alarm data machine data B Algorithm B applies to alarms and machine data 3 difference data application data C Apply Algorithm C to diff and apply data 4 application data no response D. Algorithm D is applied to the unresponsive part of the application data

The above policy configuration information is just for example. In fact, there are very flexible configuration methods. In theory, as long as the indicator data set can be associated with the algorithm, the configuration information of the present invention can be constituted, regardless of the specific configuration information. Expression form and number of elements, etc. Usually, a set of policy configuration information should correspond to a set of indicator data sets, so as to distinguish different situations and apply different algorithms. Operational data and metrics datasets under the influence of other Group Policy configuration information. However, as mentioned above, the indicator data sets can also be unified into a standard indicator data set, and each policy configuration information corresponds to the same standard indicator data set.

It can be seen that through policy configuration information, known algorithms in the system can be selected, and the whole process is very intelligent. Furthermore, in the algorithm item of the policy configuration information, corresponding expressions can be given to dynamically give the basis for algorithm generation, and then the software can use the basis given by the policy configuration information to generate the corresponding algorithm according to the agreed rules. The generated algorithm applies to it. It can be seen that the present invention associates the relationship between the index data set and the existing or unknown algorithm through the configuration information, and provides a machine learning model, which has highly intelligent features and can dynamically identify various operating conditions. Intelligent disaster recovery switching control.

Similarly, the configuration information, especially the policy configuration information, and/or the dynamically given algorithm can be provided to the user for input and maintenance by providing a graphical user interface, and the corresponding data can be stored in In a data table or file, the software of the present invention is used. Further, the user interface for inputting or improving the indicator data set and the user interface for setting or changing the policy configuration information and/or algorithm may be the same user interface, which can be flexibly designed by programmers according to needs.

Step S223 , using the index data set as a reference, using the algorithm to operate on the operation data, and determine whether the operation state represented by the operation data is abnormal.

After determining the indicator data set and configuration information, specifically the policy configuration information, you can use the algorithm options given by the policy configuration information to determine the corresponding algorithm, and use the algorithm to compare the elements given in the configuration information to compare the operating data. The corresponding elements in the benchmark and the index data set are mathematically operated, such as statistics, comparison, induction, etc., to obtain the final calculation results, and to make the operation of the equipment in the fleet or the entire fleet represented by the operating data. Whether the status is abnormal or not.

In some cases, the configuration information can also provide an execution option, such as an option to indicate that the data packet is discarded and not responded. In this case, when the corresponding algorithm is used to make an unfavorable judgment result, it can be applied This option does not respond to subsequent domain name resolution requests, and directly discards packets.

In order to understand the present invention more vividly, an example of identifying DNS attacks through the above-mentioned machine learning model of the present invention is given as follows.

In this example, the indicator data set can give a time of 100ms, and the number of resolution requests for the same domain name within 100ms in the application data is 5000 times. Policy configuration information adopts Algorithm K for the combination of application data and unit time. In this case, when the DNS resolution server configured with software implementing this method recognizes the collected application data and generates more than 5,000 domain name resolution requests for the same domain name within a unit time range of 100 ms, it does not meet the historical requirements. Behavioral habits. In this case, algorithm K is triggered for further calculation and verification. Algorithm K obtains historical usage habits based on the statistics of historical domain name resolution requests. In this case, Algorithm K can further make a judgment that a network attack is taking place at that time, so it can make a judgment that the operation status is abnormal. In this example, the implementation of Algorithm K is relatively complicated. In fact, an additional statistical process can also be used to collect statistics on the historical behavior habits of each domain name, so as to generate the number of requests in the indicator data set. In this case, Algorithm K only needs to compare the current number of visits to the domain name with the number of requests in the indicator data set to make a decision.

In another embodiment, the application data may be specified as a certain log file in the indicator data set, and the policy configuration information specifies that the algorithm X is applicable to the non-response situation of the log file. When Algorithm X is running, count the non-response records of the log file. When all the log records generated within a predetermined time period, such as 100 minutes, are all non-response records, it can be directly determined that the corresponding device or cluster that provides DNS services appears Faults, so it can also be concluded that the operating state is abnormal.

For the above two cases, in the description, for the sake of simplicity, the cluster providing DNS service is simplified to a single machine for illustration. However, those skilled in the art should understand that in these examples, of course, the organic judgment of the cluster can also or should be considered. And these are the combination of mathematics and programming technology, which should be reasonably grasped by those skilled in the art. For example, it can be considered in the algorithm that as many as several devices have the same type of situation, it is regarded as the overall paralysis of the cluster or the domain name on the public network. The unreachability of DNS servers at each level is used to further determine that the operating status is abnormal. In view of the fact that similar situations are changeable and cannot be exhaustive, and the present invention has revealed the relationship between the cluster and the single machines therein, so that those skilled in the art are flexible enough, so details are not repeated here.

When the algorithm is used to determine the operating status of the DNS service cluster, the corresponding operating status results will be formed, and the final switching control can be made based on this.

Step 23. When the judgment result represents an abnormal operation state, modify the destination address of the DNS service to the network address of the disaster recovery system; when the judgment result represents a normal operation state, modify the destination address of the DNS service to Point to the original destination address.

It can be known that the essence of the operation state determination result is a binary option, which either indicates that the operation state is normal, that is, the DNS service cluster is operating normally; or indicates that the operation state is abnormal, that is, the DNS service cluster is operating abnormally. Therefore, different switching can be made corresponding to these two situations.

When the judgment result represents an abnormal operating state, the DNS resolution server knows that the cluster that originally provided the DNS service has been unable or difficult to continue to provide the DNS resolution service. The logic implemented in this step requires a corresponding switching operation, so that the subsequent DNS resolution request can be forwarded to the disaster recovery system realized by the technical solution of the first aspect of the present invention, and the disaster recovery system uses the technology disclosed above. DNS. After the disaster recovery system obtains the domain name resolution result and forwards it to the DNS resolution server, the DNS resolution server responds to the client that initiates the domain name resolution request with the domain name resolution result. In this process, the DNS resolution server only acts as a relay. In order to avoid security attacks, it is appropriate to encrypt and transmit domain name resolution requests and domain name resolution results, whether it is to the DNS resolution server and the client that initiated the request, or DNS The transmission between the analysis server and the disaster recovery system adopts an encryption mechanism, which can make the DNS data more secure and improve the traditional DNS protocol.

When the determination result represents a normal operating state, the DNS resolution server knows that the cluster of DNS services originally provided has cleared the failure and resumed normal service. Therefore, the DNS resolution server needs to perform a switchback operation according to the logic realized in this step, so that Subsequent DNS resolution requests are no longer resolved by the disaster recovery system, but by the cluster system that originally provided DNS services, and the disaster recovery system replied that although its DNS service is open, it is in a standby state because it has not received domain name resolution requests .

In the process of completing the above two reverse switching processes, the DNS server can also push instant messages to user groups who have installed its client (such as a certain type of mobile terminal security software) through a user database. After the client software receives the instant message, it can also automatically modify and switch its DNS server address to point to the more secure DNS server provided by the disaster recovery system; or display the instant message to the user to decide on his own.

In the DNS resolution server, the action of switching is realized by modifying its internal parameters. Specifically, it is a network address parameter expressed in the form of an IP address. By default, the network address is the IP address (destination address) designated by the cluster that originally provided the DNS service to open its DNS resolution service, but the result of the judgment is abnormal operation state, it is modified by this step to the IP address of the disaster recovery system for opening its DNS resolution service. Conversely, when the cluster that originally provided DNS service returns to normal service, it is necessary to modify the network address parameter from the IP address of the disaster recovery system back to the IP address of the cluster that originally provided DNS service and opened its DNS resolution service. This network parameter can be configured in a file or registry, and can be manually modified through the corresponding system setting interface or the user interface provided by the present invention. The specific implementation form of the former depends on different operating systems.

Referring to FIG. 6 , the present invention provides an island response automatic switching device for a DNS disaster recovery system, which includes a collecting unit 21 , a judging unit 22 and a switching unit 23 .

The collection unit 21 is used to receive and collect the operation data of the cluster providing DNS service.

As the front-end DNS server that realizes the automatic switching device of the present invention, it has a communication relationship with the clusters that DNS provides DNS services, and can collect these clusters through predetermined communication ports including agreed TCP or UDP protocol ports, etc. The operating data of each device in the system, the type of operating data selected is very flexible, and can also be used flexibly. Here are some running data for reference:

1. Performance data, which is used to represent the DNS resolution throughput information of the cluster per second. Usually, under normal use, the number of DNS resolutions that each machine can perform is limited and relatively constant. Therefore, through a preset throughput threshold, it is possible to judge a certain device or determine the status of the entire cluster. Is the throughput normal. The throughput referred to here refers to the number of times of receiving domain name resolution requests and returning corresponding domain name resolution results as responses.

2. Machine data, which is used to represent the operation information of at least one hardware of each device in the cluster. Machine data mainly refers to the CPU and/or memory usage status when the machine is running. For example, if the CPU is in a state of high utilization such as 100% operation for a long time, and the state of available memory is low for a long time, it may mean that some unnecessary busy. In theory, these machine data can also be used to determine the operating quality of a single device or the entire fleet.

3. Application data, which is used to represent the log information of domain name resolution records. The log information referred to here mainly refers to the original information used to form the historical domain name resolution records of the cache data in the first aspect of the present invention. These information can be used in the subsequent development of authorization information in the disaster recovery system, or can only be used as a basis for judgment in the device. Using these log information, it can at least be seen whether there are large-scale parsing exceptions, such as a large number of domain name resolution requests that cannot obtain corresponding normal resolution, etc. Therefore, application data can obviously also be used as a running data.

4. Alarm data, which is used to represent the alarm information generated by the fleet. The alarm data referred to here is mainly the alarm data generated by the system monitoring function of the equipment in the cluster, such as the alarm data generated by the "management" component of the Windows system. Using these data, the operating status of a single device or cluster can also be determined .

5. Difference data, which is used to represent the difference information between the cache pool and the database. The buffer pool referred to here refers to the data in the buffer space for buffering historical domain name resolution records, while the database referred to here refers to a dedicated database that has extracted historical domain name resolution records from the buffer space into a standardized storage format. in the file. These difference data are recorded mainly to provide information about the difference between the temporarily cached data and the canonical cached data.

The various types of operating data given above are just enumerations of specific types of operating data, and do not make a comprehensive limitation on the operating data. After these operating data are collected, further benefits should be carried out depending on their different functions. In different situations, the types of operating data used may be different. These flexible changes will be further introduced later.

The determination unit 22 is configured to perform calculations on the operation data according to preset configuration information to form an operation state determination result of the DNS service cluster.

On the basis of collecting a large amount of operating data about the clusters that provide DNS services, the DNS server can carry out intelligent data mining, combined with the principle of machine learning, to make more intelligent and accurate judgments on the operating status of the normal clusters. In order to achieve this purpose, please refer to FIG. 7 , the determination unit 22 specifically includes an index establishment module 221 , an algorithm generation module 222 and an operation determination module 223 .

The index establishment module 221 is used to establish an index data set as a criterion for determination.

The establishment of the index data set needs to be determined in conjunction with the selection of the operation data, and the selection of the operation data depends on the preset configuration information. The indicator data sets corresponding to the four situations in the table are given below for reference:

1. Performance data: 1000, machine data: 90%

2. Alarm data: danger, machine data: 10%

3. Difference data: 90%, application data: file.log

4. Application data: file.log

According to the above four index data sets, the index established by the present invention can be understood as follows:

1. When the performance data reaches the throughput of 1000 times but the machine data (CPU and/or memory ratio) has reached 90%, it constitutes the judgment criterion of the present invention.

2. When only 10% of the machine data (CPU and/or memory ratio) is used and the alarm data of "dangerous" state appears, it constitutes the judgment criterion of the present invention.

3. When the difference data in the file whose application data is file.log reaches 90%, it constitutes the judgment criterion of the present invention.

4. Only use the application data file.log file as the real-time judgment benchmark.

On the basis of constructing the above-mentioned indicator data sets, further processing can be performed based on these indicator data sets. It should be noted that these indicator data sets can be given before the software is installed, or can be maintained on demand through the user interface provided by the software. These metrics data sets can be stored in a file for verification of the practice of the invention.

Although four sets of indicator data sets are given above, in some embodiments, the indicator data sets can also be understood as only a set of standard indicators, which are used to characterize the normal state of the cluster that provides DNS services, so as to simplify Difficulty of software programming.

The algorithm generation module 222 is configured to select or generate a corresponding algorithm according to preset configuration information.

In some cases, there may be a one-to-one correspondence between the configuration information and the indicator dataset, but if the indicator dataset is only a standard set, it only needs to correspond to this set of indicator datasets. Configuration information is usually policy configuration information expressed in a certain format specified by the present invention. For example, in the present invention, for the aforementioned example with multiple sets of indicator data sets, the following policy configuration information can be formulated, and the corresponding meanings are also given in the following table:

serial number first element second element algorithm representational meaning 1 performance data machine data A Algorithm A for performance and machine data 2 Alarm data machine data B Algorithm B applies to alarms and machine data 3 difference data application data C Apply Algorithm C to diff and apply data 4 application data no response D. Algorithm D is applied to the unresponsive part of the application data

The above policy configuration information is just for example. In fact, there are very flexible configuration methods. In theory, as long as the indicator data set can be associated with the algorithm, the configuration information of the present invention can be constituted, regardless of the specific configuration information. Expression form and number of elements, etc. Usually, a set of policy configuration information should correspond to a set of indicator data sets, so as to distinguish different situations and apply different algorithms. Operational data and metrics datasets under the influence of other Group Policy configuration information. However, as mentioned above, the indicator data sets can also be unified into a standard indicator data set, and each policy configuration information corresponds to the same standard indicator data set.

It can be seen that through policy configuration information, known algorithms in the system can be selected, and the whole process is very intelligent. Furthermore, in the algorithm item of the policy configuration information, corresponding expressions can be given to dynamically give the basis for algorithm generation, and then the software can use the basis given by the policy configuration information to generate the corresponding algorithm according to the agreed rules. The generated algorithm applies to it. It can be seen that the present invention associates the relationship between the index data set and the existing or unknown algorithm through the configuration information, and provides a machine learning model, which has highly intelligent features and can dynamically identify various operating conditions. Intelligent disaster recovery switching control.

Similarly, the configuration information, especially the policy configuration information therein, and/or the dynamically given algorithm can be provided to the user for input and maintenance through a graphical user interface provided by a setting unit of the present invention , and the corresponding data can be stored in a data table or file for use by the software of the present invention. Further, the user interface for inputting or improving the indicator data set and the user interface for setting or changing the policy configuration information and/or algorithm may be the same user interface, which can be flexibly designed by programmers according to needs.

The operation determination module 223 is configured to use the index data set as a reference, use the algorithm to perform calculations on the operation data, and determine whether the operation state represented by the operation data is abnormal.

After determining the indicator data set and configuration information, specifically the policy configuration information, you can use the algorithm options given by the policy configuration information to determine the corresponding algorithm, and use the algorithm to compare the elements given in the configuration information to compare the operating data. The corresponding elements in the benchmark and the index data set are mathematically operated, such as statistics, comparison, induction, etc., to obtain the final calculation results, and to make the operation of the equipment in the fleet or the entire fleet represented by the operating data. Whether the status is abnormal or not.

In some cases, the configuration information can also provide an execution option, such as an option to indicate that the data packet is discarded and not responded. In this case, after using the corresponding algorithm to make an unfavorable judgment result, it can be applied This option does not respond to subsequent domain name resolution requests, and directly discards packets.

In order to understand the present invention more vividly, an example of identifying DNS attacks through the above-mentioned machine learning model of the present invention is given as follows.

In this example, the indicator data set can give a time of 100ms, and the number of resolution requests for the same domain name within 100ms in the application data is 5000 times. Policy configuration information adopts Algorithm K for the combination of application data and unit time. In this case, when the DNS resolution server configured with the software used to construct this device recognizes that the collected application data has generated more than 5,000 domain name resolution requests for the same domain name within a unit time range of 100 ms, it does not comply with the history. Behavioral habits. In this case, algorithm K is triggered for further calculation and verification. Algorithm K obtains historical usage habits based on the statistics of historical domain name resolution requests. In this case, Algorithm K can further make a judgment that a network attack is taking place at that time, so it can make a judgment that the operation status is abnormal. In this example, the implementation of Algorithm K is relatively complicated. In fact, an additional statistical process can also be used to collect statistics on the historical behavior habits of each domain name, so as to generate the number of requests in the indicator data set. In this case, Algorithm K only needs to compare the current number of visits to the domain name with the number of requests in the indicator data set to make a decision.

In another embodiment, the application data may be specified as a certain log file in the indicator data set, and the policy configuration information specifies that the algorithm X is applicable to the non-response situation of the log file. When Algorithm X is running, count the non-response records of the log file. When all the log records generated within a predetermined time period, such as 100 minutes, are all non-response records, it can be directly determined that the corresponding device or cluster that provides DNS services appears Faults, so it can also be concluded that the operating state is abnormal.

For the above two cases, in the description, for the sake of simplicity, the cluster providing DNS service is simplified to a single machine for illustration. However, those skilled in the art should understand that in these examples, of course, the organic judgment of the cluster can also or should be considered. And these are the combination of mathematics and programming technology, which should be reasonably grasped by those skilled in the art. For example, it can be considered in the algorithm that as many as several devices have the same type of situation, it is regarded as the overall paralysis of the cluster or the domain name on the public network. The unreachability of DNS servers at each level is used to further determine that the operating status is abnormal. In view of the fact that similar situations are changeable and cannot be exhaustive, and the present invention has revealed the relationship between the cluster and the single machines therein, so that those skilled in the art are flexible enough, so details are not repeated here.

When the algorithm is used to determine the operating status of the DNS service cluster, the corresponding operating status results will be formed, and the final switching control can be made based on this.

The switching unit 23 is configured to modify the destination address of the DNS service to the network address of the disaster recovery system when the judgment result represents an abnormal operation state; when the judgment result represents a normal operation state, it will provide The destination address of the DNS service is changed to point to the original destination address.

It can be known that the essence of the operation state determination result is a binary option, which either indicates that the operation state is normal, that is, the DNS service cluster is operating normally; or indicates that the operation state is abnormal, that is, the DNS service cluster is operating abnormally. Therefore, different switching can be made corresponding to these two situations.

When the judgment result represents an abnormal operating state, the DNS resolution server knows that the cluster that originally provided the DNS service has been unable or difficult to continue to provide the DNS resolution service. The logic implemented by the switching unit 23 needs to perform a corresponding switching operation, so that the subsequent DNS resolution request can be forwarded to the disaster recovery system realized by the technical solution of the first aspect of the present invention, and the disaster recovery system uses the aforementioned disclosure technology for domain name resolution. After the disaster recovery system obtains the domain name resolution result and forwards it to the DNS resolution server, the DNS resolution server responds to the client that initiates the domain name resolution request with the domain name resolution result. In this process, the DNS resolution server only acts as a relay. In order to avoid security attacks, it is appropriate to encrypt and transmit domain name resolution requests and domain name resolution results, whether it is to the DNS resolution server and the client that initiated the request, or DNS The transmission between the analysis server and the disaster recovery system adopts an encryption mechanism, which can make the DNS data more secure and improve the traditional DNS protocol.

When the determination result represents a normal operating state, the DNS resolution server knows that the cluster of the DNS service provided originally has cleared the failure and resumed normal service, thus, the DNS resolution server needs to perform a switchback operation according to the logic realized by the switching unit 23 , so that the subsequent DNS resolution request is no longer resolved by the disaster recovery system, but by the cluster system that originally provided the DNS service, and the disaster recovery system replies that although its DNS service is open, it is in a state of failure because it has not received the domain name resolution request. Standby.

In the process of completing the above two reverse switching processes, the DNS server can also push instant messages to user groups who have installed its client (such as a certain type of mobile terminal security software) through a user database. After the client software receives the instant message, it can also automatically modify and switch its DNS server address to point to the more secure DNS server provided by the disaster recovery system; or display the instant message to the user to decide on his own.

In the DNS resolution server, the action of switching is realized by modifying its internal parameters. Specifically, it is a network address parameter expressed in the form of an IP address. By default, the network address is the IP address (destination address) designated by the cluster that originally provided the DNS service to open its DNS resolution service, but the result of the judgment is abnormal operation state, it is modified by the switching unit 23 to be the IP address of the disaster recovery system for opening its DNS resolution service. Once the network address is modified, switching between different systems is completed. Conversely, when the cluster that originally provided DNS service returns to normal service, it is necessary to modify the network address parameter from the IP address of the disaster recovery system back to the IP address of the cluster that originally provided DNS service and opened its DNS resolution service. This network parameter can be configured in a file or registry, and can be manually modified through a corresponding system setting interface, or through a user interface provided by a setting unit of the present invention. The specific implementation form of the former depends on different operating systems.

According to the disclosure of the above multiple embodiments of the method and device involved in the technical solution of the second aspect of the present invention, it can be seen that one of the essences of the present invention is to realize the function of intelligent attack behavior judgment by combining machine learning technology, although this article only Some examples are given, but according to the same principle as the present invention, those skilled in the art can continue to change a variety of determination methods on the basis of this article. This behavior judgment function, combined with the underlying implementation, can achieve a more secure defense effect for the DNS server.

For example, in one embodiment of the present invention, for the network data packet corresponding to each domain name resolution request received, the DNS behavior type corresponding to the network data packet can be judged in a manner similar to the aforementioned machine learning, and based on the determined The DNS behavior type determines the processing subject for processing the network data packet, and then transfers the network data packet to the determined processing subject for processing. In the embodiment of the present invention, the processing body may be composed of two layers, namely a kernel layer and an application layer. The kernel layer includes the network layer, driver layer, etc., which can implement functions such as high-speed cache and attack protection, while the application layer can perform basic analysis of network data packets, including the address after domain name analysis, and the acquisition of data storage addresses. Compared with the processing method of DNS behavior in the prior art, network data packets are divided into kernel layer and application layer for processing, and DNS requests can be processed according to actual requests. If there are millions of DNS request attacks per second , it can also be processed by the kernel with strong processing capability, and DNS requests with relatively low timeliness requirements can be processed by the application layer. The kernel and the application layer are used to process DNS requests separately. Considering the huge processing capacity of the kernel, DNS queries with large traffic can be realized. Moreover, when the modification caused by the DNS request or the loading caused by the startup, since the kernel and the application layer are processed separately, one of them can be used to process the current DNS request, while the other continues to provide external services. Therefore, the embodiment of the present invention improves the business processing capability of a single machine, greatly improves the processing capability and security protection capability of the system, and at the same time realizes fast domain name dynamic management and configuration, and further realizes many customized complex functional requirements.

When the DNS behavior type is determined to be an attack behavior, then it can be determined that the processing subject is the kernel, and when the DNS behavior type is domain name resolution behavior, it can be determined that the processing subject is the application layer. In order to improve the response speed, processing performance and security protection capabilities of domain name resolution services, according to the DNS resolution principle, high-speed cache and security protection can be implemented in the kernel module. Under normal circumstances, the kernel module can efficiently and stably process 98% of resolution requests and Protection against most attacks. The processing logic is relatively complex, and the basic analysis and management functions that do not have such high performance requirements are implemented at the application layer.

Therefore, when the processing subject is the kernel, the kernel detects the network data packet, filters the DNS attack behavior carried in the network data packet; and forwards the filtered network data packet to the application layer for processing. When the kernel detects network packets, strategies such as anti-DDOS attack strategy, IP speed limit strategy, and domain name speed limit strategy can be activated. Correspondingly, independent internal modules can be set for each strategy in the kernel to implement different strategies.

What needs to be explained here is that each network data packet has a feature code, and each feature code is unique. Therefore, the attribute of the DNS request of the network data packet can be judged according to the feature code, and the fake data packet masquerading as a normal data packet can be detected. DNS attack operations. Now judge whether the network data packet carries DNS attack behavior according to the following steps:

Step A, calculating the characteristic code of the network data packet;

Step B, determine whether the characteristic code is a characteristic code of DNS attack behavior, if so, perform step C, if not, perform step D;

Step C, if yes, then determine that the DNS attack behavior is carried in the network data packet;

Step D. If not, it is determined that the network data packet does not carry DNS attack behavior.

Among them, the database usually stores a collection of signatures of known DNS attack behaviors. When verification is required, the signatures calculated in step A are matched with the collection of databases. If the signatures calculated in step A exist In the above set, it is a DNS attack behavior, and vice versa.

Among them, the feature code can be determined according to domain name information such as IP or domain name, for example, calculate the number of network data packets received from the same IP within a specified time to obtain the feature code, and/or calculate the network data packets received from the same domain name within a specified time number. If the number of network data packets received from the same IP or the same domain name within 1 second is far greater than the number of packets that should be received, it proves that the IP address or domain name has become an attack source. This is also the basic principle of IP speed limit strategy and domain name speed limit strategy. The IP address or domain name that has been proven to be the source of the attack, and then receive the network data packets from this source, can be directly discarded or filtered out to avoid being attacked by it, and improve system security performance and processing efficiency.

After the kernel filters the attack behavior, it sends the network data packet to the application layer for processing. The application layer can analyze the network data packets to obtain the address information corresponding to the domain name, so as to obtain relevant data and feed it back to the client. And, the application layer can manage data such as domain name information to realize a data management function.

In combination with the description of the full text of the present invention, it can be seen that the method and device involved in the technical solution of the first aspect of the present invention construct a disaster recovery system, so that the disaster recovery system can provide isolated domain name resolution services; and the present invention The method and device involved in the technical solution of the second aspect can perform intelligent fault detection and switching control between the disaster recovery cluster and the common cluster. Therefore, the DNS service system constructed by the present invention can support DNS services on the Internet Safety has made a more significant contribution.

To sum up, the implementation of the present invention is beneficial to construct a disaster recovery system, and make the disaster recovery system serve the security management and control of the traditional DNS service cluster.

It should be noted that the algorithms and formulas presented herein are not inherently related to any particular computer, virtual system, or other device. Various general systems can also be used with the examples based here. The structure required to construct such a system is apparent from the above description. Furthermore, the present invention is not specific to any particular programming language. It should be understood that various programming languages can be used to implement the content of the present invention described herein, and the above description of specific languages is for disclosing the best mode of the present invention.

In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure the understanding of this description.

Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, in order to streamline the present invention and to facilitate an understanding of one or more of its various aspects, various features of the invention are sometimes grouped together into a single embodiment , figure, or description of it. This disclosed method and apparatus, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the Detailed Description are hereby expressly incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of this invention.

Those skilled in the art can understand that the modules in the device in the embodiment can be adaptively changed and arranged in one or more devices different from the embodiment. Modules or units or components in the embodiments may be combined into one module or unit or component, and furthermore may be divided into a plurality of sub-modules or sub-units or sub-assemblies. All features disclosed in this specification (including accompanying claims, abstract and drawings) and any method or method so disclosed may be used in any combination, except that at least some of such features and/or processes or units are mutually exclusive. All processes or units of equipment are combined. Each feature disclosed in this specification (including accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.

Furthermore, those skilled in the art will understand that although some embodiments described herein include some features included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of the invention. and form different embodiments. .

The various component embodiments of the present invention may be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. Those skilled in the art should understand that a microprocessor or a digital signal processor (DSP) can be used in practice to implement some or all functions of some or all components in the website security detection device according to the embodiment of the present invention. The present invention can also be implemented as an apparatus or an apparatus program (for example, a computer program and a computer program product) for performing a part or all of the methods described herein. Such a program for realizing the present invention may be stored on a computer-readable medium, or may be in the form of one or more signals. Such a signal may be downloaded from an Internet site, or provided on a carrier signal, or provided in any other form.

The above descriptions are only part of the embodiments of the present invention. It should be pointed out that those skilled in the art can make some improvements and modifications without departing from the principles of the present invention. It should be regarded as the protection scope of the present invention.

Claims (18)

1. A domain name resolution system disaster recovery construction method, is characterized in that, comprises the steps: Synchronize the authorization information database of the target cluster that provides DNS services to the disaster recovery cluster constructed with a virtual root node in real time, and the authorization information database stores the authorization information of the authorization server at each level of the domain name; receiving a domain name resolution request, in response to the domain name resolution request, using the authorization information database and the virtual root node of the disaster recovery cluster, and performing a recursive query according to the corresponding authorization server information recorded in the authorization information database to obtain all The above domain name resolution results; Responding to the domain name resolution request with a domain name resolution result. 2. The domain name resolution system disaster recovery construction method according to claim 1, characterized in that each step of the method is executed in at least one device of the disaster recovery cluster. 3. The domain name resolution system disaster recovery construction method according to claim 1, characterized in that: each step of the method is executed by one or more processes of a single device of the disaster recovery cluster. 4. The domain name resolution system disaster recovery construction method according to claim 1, characterized in that: the step of synchronizing the authorization information database to the disaster recovery cluster with a virtual root node in real time is independent of the disaster recovery cluster Execute in at least one device, and execute the remaining steps in the same device of the disaster recovery cluster. 5. The domain name resolution system disaster recovery construction method according to claim 1, characterized in that: the authorization information database also stores historical domain name resolution records, and the historical domain name resolution records are the normal execution of the DNS service process by the target cluster The DNS domain name resolution record generated by performing DNS resolution in the method, when the method performs domain name resolution, obtains the corresponding domain name resolution result by retrieving the historical domain name resolution record. 6. The domain name resolution system disaster recovery construction method according to claim 5, characterized in that: said historical domain name resolution records include mapping relationships from domain names to corresponding IP addresses. 7. The domain name resolution system disaster recovery construction method according to claim 1, characterized in that: the authorization information database is realized in the form of a distributed database. 8. The method for constructing disaster recovery of a domain name resolution system according to claim 1, characterized in that: the domain name resolution request and the domain name resolution result are transferred through the same network address. 9. The domain name resolution system disaster recovery construction method according to claim 1, characterized in that: both the domain name resolution request and the domain name resolution result are encrypted for transmission. 10. A domain name resolution system disaster recovery construction device, characterized in that it comprises: The synchronization unit is used to synchronize the authorization information database of the target cluster that provides DNS services to the disaster recovery cluster configured with a virtual root node in real time, and the authorization information database stores the authorization information of the authorization server at each level of the domain name; The query unit is configured to receive a domain name resolution request, and in response to the domain name resolution request, use the authorization information database and the virtual root node of the disaster recovery cluster to execute according to the corresponding authorization server information recorded in the authorization information database. Recursive query to obtain the domain name resolution results; The answering unit is configured to answer the domain name resolution request with a domain name resolution result. 11. The domain name resolution system disaster recovery construction device according to claim 10, characterized in that each unit of the device is configured to be executed in at least one device of the disaster recovery cluster. 12. The domain name resolution system disaster recovery construction device according to claim 10, characterized in that: one or more processes of a single device of the disaster recovery cluster are configured to be executed in each unit of the device. 13. The domain name resolution system disaster recovery construction device according to claim 10, characterized in that: the synchronization unit is configured to be executed in at least one device independent of the disaster recovery cluster, and the query unit and the response unit are Configured to execute on the same device in the disaster recovery cluster. 14. The domain name resolution system disaster recovery construction device according to claim 10, characterized in that: the authorization information database also stores historical domain name resolution records, and the historical domain name resolution records are the normal execution of the DNS service process by the target cluster The DNS domain name resolution record generated by performing DNS resolution in the system, when the query unit performs domain name resolution, obtains the corresponding domain name resolution result by retrieving the historical domain name resolution record. 15. The domain name resolution system disaster recovery construction device according to claim 14, characterized in that: the historical domain name resolution records include a mapping relationship from domain names to corresponding IP addresses. 16. The domain name resolution system disaster recovery construction device according to claim 10, characterized in that: the authorization information database is realized in the form of a distributed database. 17. The domain name resolution system disaster recovery construction device according to claim 10, characterized in that: the domain name resolution request and the domain name resolution result are transferred through the same network address. 18. The domain name resolution system disaster recovery construction device according to claim 10, characterized in that: both the domain name resolution request and the domain name resolution result are encrypted for transmission.