DNS Data Management System and Management Method

Abstract

Disclose a DNS data management system and method. The system includes: a plurality of service nodes and a plurality of data nodes. The plurality of service nodes are used to receive DNS management requests and generate DNS data maintenance requests according to the DNS management requests; the plurality of data nodes are used to store DNS data and maintain the DNS data according to the data consistency protocol according to the DNS data maintenance requests. The embodiments of the present disclosure ensure the consistency of DNS data on each data node through the consistency protocol.

Description

Technical Field

[0001] The present disclosure relates to the field of the Internet, and in particular, to a DNS data management system and a management method. Background Art

[0002] DNS is an abbreviation for Domain Name System. The domain name system is one of the basic network services in the Internet. It establishes a hierarchical tree-like service system in the network and establishes DNS data that reflects the logical mapping relationship between IP addresses and domain names. Each time a user accesses, the DNS data is used to convert the domain name into the corresponding IP address.

[0003] The DNS data management service guarantees the high availability of the DNS data management service through the primary-backup mode + manual switching. As Figure 1 shown, the DNS data management service is respectively deployed on the primary server 11 and the backup server 13, the domain name system is respectively deployed on multiple DNS servers 12, the administrator user accesses the DNS data management service through the management terminal 1, and at the same time the network user obtains the domain name service through the request terminal 4. As shown in the figure, the DNS data is also respectively stored on the primary server 11 and the backup server 13, and the DNS data between the primary server 11 and the backup server 13 is synchronized regularly. Under normal circumstances, the DNS data management service deployed on the primary server 11 is responsible for managing the DNS data, and the domain name service accesses the DNS data on the primary server 11. When it fails, the DNS data management service deployed on the backup server 13 is manually enabled, and the domain name service accesses the DNS data on the backup server 13.

[0004] The pain points of the current architecture are as follows: 1) During the switching between the primary server and the backup server, the domain name system is unavailable; 2) There is an interval time for synchronizing the DNS data on the primary server and the DNS data on the backup server. If the primary server fails, there is a risk of data loss. Summary of the Invention

[0005] In view of this, the purpose of the present disclosure is to provide a DNS data management system and a management method to solve the problems existing in the prior art.

[0006] According to the first aspect of the present disclosure, a DNS data management system is provided, including: a plurality of service nodes and a plurality of data nodes,

[0007] The plurality of service nodes are configured to receive DNS management requests and generate DNS data maintenance requests according to the DNS management requests;

[0008] The plurality of data nodes are configured to store DNS data and maintain the DNS data according to the DNS data maintenance requests in accordance with the data consistency protocol.

[0009] Optionally, the multiple service nodes form a primary / backup mode. The primary service node and the backup service node have the same virtual IP address, and automatic switching between the primary service node and the backup service node is achieved through the virtual IP address.

[0010] Optionally, heartbeat information is established between the primary service node and the backup service node, and whether the primary service node fails is determined through the heartbeat information to decide whether to switch from the primary service node to the backup service node.

[0011] Optionally, the multiple service nodes form a cluster mode. The multiple service nodes include a primary service node. The primary service node forwards the DNS management request to one of the remaining service nodes according to a service list and a load balancing policy. Heartbeat information is established between the primary service node and the remaining service nodes. When a failed service node is detected according to the heartbeat information, the failed service node is deleted from the service list and added back to the service list after it recovers from the failure.

[0012] Optionally, when the primary service node fails, a new primary service node is generated through a cluster master election algorithm.

[0013] Optionally, the multiple data nodes form a cluster mode. The primary data node is responsible for receiving the DNS data maintenance request, recording the DNS data maintenance request as a log, and replicating it to the remaining data nodes. Then, the primary data node and the remaining data nodes submit the log to complete the consistency maintenance of the DNS data.

[0014] Optionally, the primary data node is generated through a cluster master election algorithm.

[0015] In a second aspect, an embodiment of the present disclosure provides a DNS data management method, including:

[0016] Using multiple service nodes to receive DNS management requests and generate DNS data maintenance requests according to the DNS management requests;

[0017] Using multiple data nodes to store DNS data and maintaining the DNS data according to the DNS data maintenance request in accordance with a data consistency protocol.

[0018] Optionally, the multiple service nodes form a primary / backup mode, and the multiple service nodes have the same virtual IP address, and automatic switching between the primary service node and the backup service node is achieved through the virtual IP address.

[0019] Optionally, the multiple data nodes form a cluster mode. The primary data node is responsible for receiving the DNS data maintenance request, recording the DNS data maintenance request as a log, and replicating it to the remaining data nodes. Then, the primary data node and the remaining data nodes submit the log to complete the consistency maintenance of the DNS data.

[0020] In a third aspect, an embodiment of the present disclosure provides a DNS resolution method, including:

[0021] Receiving a domain name to be resolved;

[0022] Sending the domain name to be resolved to a domain name server, where the domain name server obtains the IP address corresponding to the domain name to be resolved from a first data node. The first data node is any one of the multiple data nodes accessible to the domain name server, and the multiple data nodes manage DNS data according to a data consistency protocol; and

[0023] Mapping the domain name to be resolved to an IP address.

[0024] According to the embodiment of the present disclosure, the consistency of DNS data on each data node is ensured through a consistency protocol. Further, the DNS data management service is deployed in a primary-backup mode. When the primary service node fails, the backup service node is enabled to provide the DNS data management service to achieve high availability of the DNS data management service. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Through the description of the embodiments of the present disclosure with reference to the following drawings, the above and other objects, features, and advantages of the present disclosure will become clearer. In the drawings:

[0026] Figure 1 Shows a schematic network structure diagram of an existing DNS data management system;

[0027] Figure 2 Shows a schematic network structure diagram of a DNS data management system provided by the first embodiment of the present disclosure;

[0028] Figure 3 Shows a schematic network structure diagram of a DNS data management system provided by the second embodiment of the present disclosure;

[0029] Figure 4 Shows a schematic network structure diagram of a DNS data management system provided by the third embodiment of the present disclosure;

[0030] Figure 5 Shows a flowchart of a DNS data management method provided by the first embodiment of the present disclosure. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0031] The present disclosure will be described based on embodiments, but the present disclosure is not limited to these embodiments. In the following detailed description of the present disclosure, some specific details are described in detail. Those skilled in the art can fully understand the present disclosure without the description of these details. In order to avoid obscuring the essence of the present disclosure, well-known methods, processes, and procedures are not described in detail. Additionally, the accompanying drawings are not necessarily drawn to scale.

[0032] Figure 2 The schematic diagram of the network structure of the DNS data management system provided by the first embodiment of the present disclosure is shown.

[0033] As shown in the figure, the system includes a primary service node 21 for deploying DNS data management services, a standby service node 24, a cluster 2 composed of multiple data nodes 22, and a DNS server 23 deployed with domain name services. The administrator user accesses the DNS data management service through the management terminal 1. The network user obtains the domain name service through the request terminal 4. For example, the network user can obtain the DNS service based on the web application of the request terminal 4. Specifically, first, the network user enters the domain name to be resolved through the browser, and the web application provides the domain name to be resolved to the DNS server 23. The DNS server 23 obtains the IP address mapped by the domain name to be resolved through a data node 22 and returns it to the web application. This data node 22 is any one of the multiple data nodes that the DNS server 23 can access. The web application maps the domain name to be resolved to the IP address, thereby obtaining the service provided by the IP address.

[0034] As shown in the figure, the primary service node 21 and the standby service node 24 work in the primary-standby mode. The standby service node 24 serves as a backup of the primary service node 21. Under normal circumstances, the standby service node 24 does not receive and process DNS management requests. When the primary service node 21 fails, the service is switched to the standby service node 24. In one embodiment, two service nodes are specified through a virtual IP address, with one service node as the primary service node and the other as the standby service node. A heartbeat message is established between the primary service node 21 and the standby service node 24, and whether the primary service node 21 fails is determined through the heartbeat message. When the primary service node 21 fails, the service node pointed to by the virtual IP address is switched to the standby service node 24.

[0035] In this embodiment, different from the prior art, the primary / backup mode is implemented by applying the Virtual Router Redundancy Protocol. Those skilled in the art know that the Virtual Router Redundancy Protocol is a network layer protocol that designates multiple service nodes providing the same service as the same virtual IP address. If one of the service nodes fails, another service node can quickly take over its work to ensure the reliability and continuity of communication. The application based on the Virtual Router Redundancy Protocol is implemented at the application layer, that is, the automatic switching of the primary / backup service nodes is realized by using the network layer's Virtual Router Redundancy Protocol in the application program. That is, when the primary service node fails, the service automatically switches to the backup service node. Keepalived is an application program with such a function. When the Keepalived service is working properly, the primary service node continuously sends heartbeat information to the backup service node to tell the backup service node that it is still alive. When the primary service node fails, it cannot send heartbeat messages, and the backup service node cannot detect the heartbeat information from the primary service node. Then it calls its own takeover program to take over the IP resources and services of the primary service node. When the primary service node recovers, the backup service node releases the IP resources and services it took over when the primary service node failed and returns to its original standby role. When this embodiment is implemented using Keepalived, Keepalived is deployed on service nodes 21 and 24, and the service node 21 is specified as the primary service node in the Keepalived configuration of service node 21, and the service node 24 is specified as the backup service node in the Keepalived configuration of service node 24. At the same time, the same virtual IP address and heartbeat information interval are specified in both configurations. Then the DNS management requests sent over the network will be forwarded to the primary service node 21 and processed by the primary service node 21. And heartbeat information is sent between the primary service node 21 and the backup service node 24 via Keepalived. When the backup service node 24 does not receive the heartbeat information from the primary service node after the expiration, the backup service node 24 starts to take over the service.

[0036] The automatic switching between the primary service node and the backup service node in this embodiment is realized through the virtual IP address. It should be understood that although Figure 2 two primary / backup nodes are used to provide DNS management services in

[0037] Continuing with reference to the figure shown above, the DNS data is stored in Cluster 2, which includes multiple data nodes 22. Each data node 22 stores the same DNS data, and the data consistency protocol is used to achieve the consistency of DNS data among the nodes. When a data node fails, another data node can provide the DNS data, and at this time, the domain name service can still access the DNS data normally. It should be noted that resolving a host name to an IP address usually uses a hierarchical domain name resolution service. Each level of the domain name resolution service uses the DNS data at that level, and each data node in Cluster 2 stores the DNS data of all levels.

[0038] The data consistency protocol is used to solve the data consistency problem among multiple replicas. In one embodiment, the above-mentioned multiple data nodes include a primary data node and at least one secondary data node. The primary data node is responsible for receiving DNS data maintenance requests and processing the DNS data maintenance requests. The DNS data maintenance requests can also be sent to at least one secondary data node simultaneously. The primary data node and the secondary data nodes maintain their own DNS data according to the DNS data maintenance requests. This maintenance includes adding, deleting, and modifying the DNS data. In this way, the consistency of the DNS data on the primary data node and the secondary data nodes is achieved. It should be noted that there are differences in the strength of data consistency. Strong consistency can be understood as that at any moment, the data in each data node is the same. Weak consistency can only ensure that the data on each data node is eventually consistent, but it cannot ensure the time required to achieve consistency. Therefore, weak consistency is also called eventual consistency. The higher the strength of consistency, the higher the data security, but the execution efficiency will be relatively poor, and vice versa. In this embodiment, considering the usage scenario of DNS data, the DNS data is implemented as weak consistency.

[0039] In addition, if multiple data nodes are divided into master data nodes and slave data nodes, the cluster leader election problem will be involved, that is, how to select the master data node from multiple data nodes. The cluster leader election problem usually occurs when the master node of the cluster is down or the cluster has just started. At this time, there is no master node in the cluster, and the cluster leader election will be triggered. There are two common ways to elect a cluster leader: voting and competition. The voting cluster leader election is such as ZooKeeper. The specific voting process includes: after losing the master node, all nodes broadcast their own election values to all nodes in the first round of broadcasts. Each node will compare its own election value with the election values of all other nodes received, and select the largest election value. If the largest election value is not its own, it will broadcast the largest election value in the second round of broadcasts. After a node receives the second round of broadcasts, it counts more than half of the election values, and its corresponding node will become the new master node. The competitive cluster leader election needs to be implemented with the help of external storage services. For example, each node determines who is the master node by accessing a certain agreed key-value pair (Key-Value) data. Assuming that the KV data is the master node: UUID (a unique identifier generated before writing), the specific master grabbing logic is as follows: try to obtain the key-value pair data to determine whether the data exists; if the master node does not exist, write the master node identifier: UUID to the storage service and set its TTL (if the storage service does not support TTL, TTL can be written as part of the Value), save the UUID value locally, and the current process is the master node; if the master node identifier exists, determine whether it is expired through TTL. If expired, treat it as if the master node identifier does not exist, otherwise compare the UUID of the master node identifier and the locally stored UUID to see if they are consistent; if they are consistent, refresh the data, and the current process is the master node identifier; if they are inconsistent, do not do anything, and the current node is not the master node. Voting and competition each have their own characteristics, but voting is currently used more frequently in clusters. In the present disclosure, the cluster master selection method is not restricted.

[0040] In this embodiment, automatic switching between the primary service node and the backup service node is achieved through virtual IP addresses, thereby achieving high availability of the DNS data management service, and the consistency of the DNS data on each data node is ensured through the consistency protocol, thereby achieving high availability of the DNS data.

[0041] Figure 3Shows a schematic network structure diagram of the DNS data management system provided by the second embodiment of the present disclosure. As shown in the figure, the system includes a primary service node 31 and multiple standby service nodes 32 in a primary-standby mode. The DNS data management service and DNS data are deployed on both the primary service node 31 and the standby service nodes 32. The administrator user accesses the DNS data management service through the management terminal 1, and at the same time, the network user obtains the domain name service through the request terminal 4. Under normal circumstances, the primary service node 31 provides the DNS data management service to the management terminal 1. When the primary service node 31 fails, the standby service node 32 provides the DNS data management service to the management terminal 1. As can be seen from the figure, each service node serves as both a service node and a data node at the same time, which is a difference between it and Figure 2 One difference, and another difference is that there are two standby service nodes 32. In addition, the consistency protocol is also adopted between the data nodes to ensure the consistency of the DNS data.

[0042] In Figure 3 , the primary-standby mode is adopted to provide the DNS data management service. In this mode, multiple copies of the DNS data and the DNS data management service are deployed. Each DNS data management service can equally provide the DNS data management. Even if one of the service nodes fails, it does not affect the use of the DNS management service and the DNS data. The advantage of doing so is that both the service and the data have high availability.

[0043] At the same time, the service nodes 31 and 32 can also be specified through the virtual IP address, and the service node 31 is specified as the primary service node, and the other two service nodes 32 are used as standby service nodes. Heartbeat information is established between the primary service node 31 and the standby service nodes 32 to determine whether the primary service node 31 has failed through the heartbeat information. When the primary service node 31 fails, the service node pointed to by the virtual IP address is switched to a standby service node 32. The primary-standby mode in this embodiment can also be implemented through the Keepalived application. When using Keepalived to implement the primary-standby mode, Keepalived is deployed on each service node, and in the Keepalived configuration of the primary service node 31, this service node is specified as the primary service node 31, and in the Keepalived configuration of the standby service node 32, this service node is specified as the standby service node 32. At the same time, the same virtual IP address and the heartbeat information interval are specified in the configurations of both. The DNS management request sent via the network will be forwarded to the primary service node 31 and processed by the primary service node 31. Heartbeat information is sent between the primary service node 31 and the standby service nodes 32. When the standby service node 32 does not receive the heartbeat information of the primary service node 31 after the expiration, the standby service node 32 starts to take over the service.

[0044] Figure 4The figure shows a schematic network structure diagram of the DNS data management system provided by the third embodiment of the present disclosure. As described above, the system includes a plurality of master service nodes 41 and slave service nodes 42 in a cluster mode. The DNS data management service and DNS data are deployed on both the master service nodes 41 and the slave service nodes 42. The administrator user accesses the DNS data management service through the management terminal 1, and at the same time, the network user obtains the domain name service through the request terminal 4. The consistency protocol is also adopted between the data nodes to ensure the consistency of the DNS data.

[0045] and Figure 3 The difference is that the DNS management request sent by the management terminal 1 is always sent to the master service node 41 in the cluster. The master service node 41 is used to distribute the DNS management request to one of the remaining slave service nodes according to the service list and the load balancing policy. The master service node and the slave service node are managed through the cluster management software. The cluster management software manages an active service list, detects whether each slave node fails according to the heartbeat information, and deletes the failed slave node from the service list. When the failed slave node recovers, it is added to the service list again. When the master service node fails or the cluster is just started, the master node is selected through the cluster master selection method. The specific master selection method can refer to the cluster master selection method described above.

[0046] In this embodiment, load balancing is achieved through the cluster mode. Since complete data and services are stored on each peer service node, the access traffic of users can be diverted to different service nodes.

[0047] Corresponding to the above network structure diagram, the present disclosure provides a DNS data management method. As Figure 5 shown, the method includes steps S501 and S502.

[0048] In step S501, a plurality of service nodes are adopted to receive the DNS management request and generate a DNS data maintenance request according to the DNS management request.

[0049] In step S502, a plurality of data nodes are adopted to store the DNS data and maintain the DNS data according to the DNS data maintenance request in accordance with the data consistency protocol.

[0050] The working mode of multiple service nodes can be the primary / standby mode. In the primary / standby mode, under normal circumstances, the primary service node works, and the standby service node is in an idle state. When the primary service node fails, the standby service node starts to work. To achieve the automatic conversion between the primary service node and the standby service node, it can be realized through the application of the Virtual Router Redundancy Protocol (VRRP). This application can be an existing application based on the VRRP or a newly constructed application. Those skilled in the art know that the VRRP is a network layer protocol that designates multiple service nodes providing the same service as the same virtual IP address, and then the requests can be distributed to one of the multiple service nodes according to the virtual IP address. Therefore, as long as the service nodes deployed with the DNS data management service are set as the same virtual IP address in the application, the automatic switching of the DNS data service can be achieved. Further, heartbeat information is established between the primary service node and the standby service node, and whether the primary service node has failed is determined through the heartbeat information to decide whether to perform the automatic switching of the primary / standby nodes.

[0051] The working mode of multiple service nodes can also be the cluster mode. Since a new primary service node will be selected when the primary service node fails, as long as it is ensured that DNS management requests are always received through the primary service node and distributed to multiple slave service nodes, the high availability of the service can be ensured. Load balancing can also be achieved through the cluster mode.

[0052] Multiple data nodes are implemented in the cluster mode. Each data node stores the same DNS data, and the consistency of the DNS data of each node is achieved through the data consistency protocol. When a data node fails, other data nodes can provide the DNS data, and at this time, the domain name service 3 can still access the DNS data normally. In one embodiment, multiple data nodes form a cluster mode. The primary data node is responsible for receiving DNS data maintenance requests, recording the DNS data maintenance requests as logs, and replicating them to the slave data nodes. The primary data node and the slave data nodes will submit the logs at an appropriate time to complete the maintenance of the DNS data.

[0053] In the embodiments of the present disclosure, the consistency of the DNS data on each data node is ensured through a consistency algorithm. Further, the DNS data management service is deployed in the primary / standby mode. When the primary service node fails, the standby service node is enabled to provide the DNS data management service to ensure the high availability of the DNS data management service.

[0054] Those skilled in the art can understand that the present disclosure can be implemented as a system, a method, and a computer program product. Therefore, the present disclosure can be specifically implemented in the following forms, namely, complete hardware, complete software (including firmware, resident software, microcode), and can also be implemented in the form of a combination of software and hardware. In addition, in some embodiments, the present disclosure can also be implemented in the form of a computer program product in one or more computer-readable media, which contain computer-readable program code.

[0055] Any combination of one or more computer-readable media can be adopted. The computer-readable media can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium is, for example but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the computer-readable storage medium include: an electrical connection of one or more specific wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical memory, a magnetic memory, or any suitable combination of the above. In this article, the computer-readable storage medium can be any tangible medium that contains or stores a program, and the program can be used by or in combination with a processing unit, apparatus, or device.

[0056] The computer-readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any other suitable combination. The computer-readable signal medium can also be any computer-readable medium other than the computer-readable storage medium, and this computer-readable medium can send, propagate, or transmit a program for use by or in combination with an instruction system, apparatus, or device.

[0057] The program code contained on the computer-readable medium can be transmitted by any suitable medium, including but not limited to wireless, wire, optical cable, RF, etc., and any suitable combination of the above.

[0058] The computer program code for implementing the embodiments of the present disclosure may be written in one or more programming languages or combinations thereof. The programming languages include object-oriented programming languages such as JAVA and C++, and may also include conventional procedural programming languages such as C. The program code may be executed entirely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (for example, by connecting through the Internet using an Internet service provider).

[0059] The above are only the preferred embodiments of the present disclosure and are not intended to limit the present disclosure. For those skilled in the art, various modifications and changes can be made to the present disclosure. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present disclosure shall be included within the protection scope of the present disclosure.

Claims

1. A DNS data management system, comprising: Multiple service nodes and multiple data nodes, The multiple service nodes are used to receive DNS management requests and generate DNS data maintenance requests according to the DNS management requests; The multiple service nodes form a cluster mode. The multiple service nodes include a primary service node. The primary service node forwards the DNS management request to one of the remaining service nodes according to a service list and a load balancing policy. Heartbeat information is established between the primary service node and the remaining service nodes. When a failed service node is detected according to the heartbeat information, the failed service node is deleted from the service list and added to the service list again after it recovers from the failure; The multiple data nodes are used to store DNS data and maintain the DNS data according to the DNS data maintenance request in accordance with a data consistency protocol.

2. The DNS data management system according to claim 1, wherein the multiple service nodes form a primary-backup mode, the primary service node and the backup service node have the same virtual IP address, and automatic switching between the primary service node and the backup service node is achieved through the virtual IP address.

3. The DNS data management system according to claim 2, wherein, Heartbeat information is established between the primary service node and the backup service node, and whether the primary service node fails is determined through the heartbeat information to decide whether to switch from the primary service node to the backup service node.

4. The DNS data management system according to claim 1, wherein, When the primary service node fails, a new primary service node is generated through a cluster master election algorithm.

5. The DNS data management system according to claim 1, wherein the multiple data nodes form a cluster mode, the primary data node is responsible for receiving the DNS data maintenance request, recording the DNS data maintenance request as a log, and replicating it to the remaining data nodes, and then the primary data node and the remaining data nodes submit the log to complete the consistency maintenance of the DNS data.

6. The DNS data management system according to claim 5, wherein the primary data node is generated through a cluster master election algorithm.

7. A DNS data management method, comprising: Using multiple service nodes to receive DNS management requests and generate DNS data maintenance requests according to the DNS management requests; The multiple service nodes form a cluster mode. The multiple service nodes include a primary service node. The primary service node forwards the DNS management request to one of the remaining service nodes according to a service list and a load balancing policy. Heartbeat information is established between the primary service node and the remaining service nodes. When a failed service node is detected according to the heartbeat information, the failed service node is deleted from the service list and added to the service list again after it recovers from the failure; Using multiple data nodes to store DNS data and maintain the DNS data according to the DNS data maintenance request in accordance with a data consistency protocol.

8. The DNS data management method according to claim 7, wherein the multiple service nodes form a primary-backup mode, and the multiple service nodes have the same virtual IP address, and automatic switching between the primary service node and the backup service node is achieved through the virtual IP address.

9. The DNS data management method according to claim 7, wherein, The multiple data nodes form a cluster mode. The primary data node is responsible for receiving the DNS data maintenance request, recording the DNS data maintenance request as a log, and replicating it to the remaining data nodes. Then, the primary data node and the remaining data nodes submit the log to complete the consistency maintenance of the DNS data.

10. A DNS resolution method, comprising: Receiving a domain name to be resolved; Sending the domain name to be resolved to a domain name server, where the domain name server obtains the IP address corresponding to the domain name to be resolved from a first data node. Herein, the first data node is any one of the multiple data nodes accessible by the domain name server, and the multiple data nodes manage DNS data according to a data consistency protocol; and Mapping the domain name to be resolved to an IP address; the multiple data nodes form a cluster mode, the multiple data nodes include a primary data node, the primary data node forwards a DNS management request to one of the remaining data nodes according to a service list and a load balancing policy, a heartbeat message is established between the primary data node and the remaining data nodes, and when a failed data node is detected according to the heartbeat message, the failed data node is deleted from the service list and added to the service list again after it recovers from the failure.

Images