CN113472855A

CN113472855A - DNS authoritative server distributed consensus method and system

Info

Publication number: CN113472855A
Application number: CN202110630784.6A
Authority: CN
Inventors: 刘岩; 李震
Original assignee: Guangzhou Root Chain International Network Research Institute Co ltd
Current assignee: Guangzhou Root Chain International Network Research Institute Co ltd
Priority date: 2021-06-07
Filing date: 2021-06-07
Publication date: 2021-10-01

Abstract

The invention discloses a distributed consensus method and a distributed consensus system for DNS authoritative servers, wherein the method comprises the following steps: the method comprises the steps that a plurality of peer authoritative server nodes are arranged in a distributed mode, the peer authoritative server nodes at least comprise a first node and a second node, the first node is set to trigger at random timing, and when a voting request of the second node is received before triggering, the voting result is stopped from being returned to the second node at regular time; and when a voting request is initiated after triggering and a determined vote that the peer node exceeds a first threshold value is received, the first node becomes a leading node and initiates resource record synchronization of all the peer nodes. The invention can keep the data of each node of the DNS consistent, and ensure the non-tamper property and high reliability of the DNS authority system.

Description

DNS authoritative server distributed consensus method and system

Technical Field

The invention relates to the technical field of computer network communication, in particular to a distributed consensus method and system for DNS authoritative servers.

Background

The DNS (Domain Name System) provides an important service on the internet, and essentially bridges the world of people's names and the underlying world of binary protocol addresses. The domain name and IP address mapping method is used as a distributed database for mapping the domain name and the IP address to each other, so that people can access the Internet more conveniently without remembering the IP address number string which can be directly read by a machine, and the process of finally obtaining the IP address corresponding to the domain name through the domain name is called domain name resolution.

In the DNS system, including a recursive server and an authoritative server, for the authoritative server, resource records of related domain name queries are locally stored, and the management of the resource records determines the accuracy and reliability of the whole domain name resolution system. Particularly, at present, in order to avoid weak risk resistance and rights abuse caused by high centralization, a distributed multi-node cluster system is gradually adopted, but if the number of cluster nodes is infinitely expanded, resource records of corresponding nodes are inconsistent in processing due to network problems, and further, when a user carries out domain name query, differences occur in probability, so that query inconsistency is caused to bring access accidents.

Disclosure of Invention

The invention aims to provide a distributed consensus method and a distributed consensus system for a DNS authoritative server, which solve the technical problems that a distributed DNS authoritative system in the prior art is not strong in reliability, is easy to be interfered by network abnormity, and the consistency of resource record data cannot be guaranteed.

In order to solve the technical problem, the distributed consensus method for the DNS authoritative server comprises the steps that a plurality of peer authoritative server nodes are arranged in a distributed mode and at least comprise a first node and a second node, the first node is set to trigger at random timing, and when a voting request of the second node is received before triggering, the timing is stopped to return a voting result to the second node;

and when a voting request is initiated after triggering and a determined vote that the peer node exceeds a first threshold value is received, the first node becomes a leading node and initiates resource record synchronization of all the peer nodes.

As a further improvement of the DNS authoritative server distributed consensus method of the present invention, when negotiating about the master node with other peer nodes, the first node interacts through a first formatted message, where the first formatted message includes a message type, a timestamp, a self node ID, a version number, and a node list.

As a further improvement of the DNS authoritative server distributed consensus method of the present invention, after the first node is determined to be the leading node, a hash value of a resource record of the peer node is obtained, and compared with the hash value of the resource record obtained by the first node.

As a further improvement of the DNS authoritative server distributed consensus method, the number of the compared hash values exceeds a second threshold value, resource record synchronization is implemented, and otherwise, operation is abandoned and the next data acquisition is waited.

As a further improvement of the DNS authoritative server distributed consensus method, resource record synchronization is interacted through a second formatted message, and the second formatted message comprises a message type, a version number, a hash value, a node ID, a timestamp and data content.

In order to solve the above technical problem, the distributed consensus system for DNS authoritative servers of the present invention is configured with a plurality of peer authoritative server nodes in a distributed manner, and the peer authoritative server nodes at least include a first node and a second node, wherein the first node is configured with a random timing trigger, and the system further includes:

the voting unit is used for stopping returning a voting result to the second node at a fixed time when receiving a voting request of the second node before triggering;

and the synchronization unit is used for initiating a voting request after triggering and receiving a determined vote that the peer node exceeds a first threshold value, wherein the first node becomes a leading node and initiates resource record synchronization of all the peer nodes.

As a further improvement of the DNS authoritative server distributed consensus system of the present invention, when negotiating about the leader node with other peer nodes, the first node interacts through a first formatted message, where the first formatted message includes a message type, a timestamp, a self node ID, a version number, and a node list.

As a further improvement of the DNS authoritative server distributed consensus system of the present invention, the synchronization unit obtains a hash value of the resource record of the peer node after the first node is determined as the leading node, and compares the hash value with a hash value of the resource record obtained by the synchronization unit.

As a further improvement of the DNS authoritative server distributed consensus system, the number of the compared hash values exceeds a second threshold value, resource record synchronization is implemented, and otherwise, operation is abandoned and the next data acquisition is waited.

As a further improvement of the DNS authoritative server distributed consensus system, resource record synchronization is interacted through a second formatted message, and the second formatted message comprises a message type, a version number, a hash value, a node ID, a timestamp and data content.

Compared with the prior art, the invention determines one node in a plurality of peer authoritative servers as a leading node through a timer triggered by random time, and uniformly initiates resource record synchronization between peer nodes through the randomly determined leading node. The invention can keep the data of each node of the DNS consistent, and ensure the non-tamper property and high reliability of the DNS authority system.

Other features and advantages of the present invention will become more apparent from the detailed description of the embodiments of the present invention when taken in conjunction with the accompanying drawings.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to the drawings without creative efforts.

Fig. 1 is a schematic diagram of node state switching according to an embodiment of the present invention. .

Fig. 2 is a schematic diagram of the relationship between the master node and the slave nodes according to an embodiment of the present invention.

Fig. 3 is a first formatted message data structure according to an embodiment of the present invention.

Fig. 4 is a second formatted message data structure in accordance with an embodiment of the present invention.

Fig. 5 is a schematic diagram of a DNS authoritative server distributed consensus system according to an embodiment of the present invention.

Detailed Description

The present invention will be described in detail below with reference to embodiments shown in the drawings. These embodiments are not intended to limit the present invention, and variations in structure, method, or function that may be affected by one of ordinary skill in the art based on these embodiments are within the scope of the present invention.

It should be noted that the same reference numbers or symbols may be used in different embodiments, but these do not represent an absolute relationship in structure or function. Further, the references to "first" and "second" in the embodiments do not represent an absolutely distinct relationship in structure or function, and these are merely for convenience of description.

The DNS authority server is the server that actually holds and is responsible for DNS resource records, which is the server at the bottom of the DNS lookup chain that will respond with the resource records of the query, ultimately allowing the Web browser to issue the IP address needed to access the Web site or other Web resource. An authoritative server can satisfy queries from its own data without querying other sources, as it is the ultimate true source of some DNS records. Traditional DNS architectures often adopt a centralized management concept, for example, corresponding resource records are completely managed by a single party, which may result in rights abuse, so that a decentralized DNS architecture should be developed. The decentralized idea is to set a plurality of authoritative servers to form a cluster, each authoritative server can be managed by different managers, and the authoritative server cluster is managed by multiple parties through consensus. Here, there will be corresponding problems, for example, the information of the node may cause inconsistent message processing due to network problems, etc., after all, any authoritative server requires to provide a corresponding accurate resource record query result, and how to handle the interaction and synchronization between the authoritative server and the authoritative server in the cluster becomes the key point for the solution of the present invention.

Specifically, in the embodiment of the invention, in the DNS authoritative server distributed consensus method, a plurality of peer authoritative server nodes are distributed, and the authoritative server are not different in hardware setting and have the same status and network environment. In a cluster formed by a plurality of authoritative servers, a first node and a second node are selected to develop description, the first node and the second node have no essential difference, and the first node and the second node play the same role in the cluster as the authoritative servers holding the same type of DNS resource records. As shown in FIG. 1, any peer authoritative server in the cluster has different states according to a common algorithm, and taking the first node as an example, switching can be carried out among the leading node, the slave node and the candidate node. The master node and the slave nodes are used as working state nodes for carrying out normal data synchronization in the cluster, the slave nodes carry out data synchronization under the unification of the master node, and the master node is responsible for judging and processing the unification and the legality of the data. The candidate node is a state node between the leading node and the slave node, when the leading node does not exist or the expiration of the leading node determined last time exceeds a specified time period, the candidate node applies for the leading node based on a mode of respective random timing trigger, once the leading node is determined by other candidate nodes, the candidate node becomes a new leading node, and other candidate nodes automatically become the slave nodes and follow the processing of the leading node. Further, between the leading node and the candidate nodes, the leading node is automatically converted into the candidate nodes when the expiration time is up, the leading node application of the next round is performed, and if any one of the candidate nodes meets the voting requirement, for example, if confirmation of more than half of the nodes in the cluster is obtained, the leading node is converted into the leading node. Between the slave node and the candidate node, when the current leading node has expired, the slave node is also converted into the candidate node, the same chance is provided for the leading node, and when the corresponding candidate node finds that the leading node already exists in the cluster, the corresponding candidate node is automatically converted into the slave node. After determining as the master node, resource record synchronization with all slave nodes (i.e., all other peer nodes) is initiated by the master node.

In a specific embodiment, the first node sets a random timing trigger, the random time is set to ensure that there is no conflict between each node when applying for the leading node, the priority of applying for the leading node is determined by the sequence of the random time, and the chances of each node becoming the leading node are equal. The first node generates a random time to carry out timing, the timing is finished to carry out triggering, when the corresponding timing is not finished and the voting request of other nodes (such as a second node) is received, the first node stops triggering at the moment, when the voting request of the second node is received before triggering, the timing is stopped, the voting result is returned to the second node, if the second node is agreed to be used as a leading node, the confirmation voting is particularly returned, otherwise, the rejection voting is returned.

In the above description, the voting request of the second node is received within the random trigger time set by the first node, and in another case, after the random timing set by the first node is timed out, the voting request of other nodes may not be received, which indicates that the first node determines, through the respective random timing, to be the authoritative server that first applies for the leader node, and at this time, initiates the voting request to other peer nodes in the cluster, and how to determine the peer node list in the cluster, and details will be described below on how the corresponding field of the first formatting message may be determined. After sending out the voting request, the main purpose is to inform other peer nodes that the corresponding node has entered the pending process of the leader node, and there is no need for another node to reapply for the leader node. In addition, the node that receives the voting request needs to return a corresponding voting result, and for the first node that sends the voting request, it needs to count the voting results returned by each node, and determine whether the first node is qualified to become the leading node according to the corresponding voting result. It should be noted that, in order to improve the efficiency of the voting process, a voting waiting time is also set, and if the voting result returned by the corresponding node is not received in time within the voting waiting time, the voting is determined to be a confirmation voting or a negative voting by default. After determining to become the master node, resource record synchronization of all peer nodes may be initiated, and in further embodiments, a master node success confirmation message is also sent to all nodes in the cluster.

Further, when peer nodes in a cluster negotiate to determine a leading node, maintain node identities, determine that nodes are online, and the like, message interaction needs to be performed based on a certain mechanism, two requirements need to be provided here, one requirement is standardization, and compatibility and unification between an authoritative server and the authoritative server are guaranteed. In this embodiment, as shown in fig. 3, when a first node negotiates a master node with other peer nodes, interaction is performed through a first formatted message. The first formatted MESSAGE includes a MESSAGE TYPE (MESSAGE-TYPE), a timestamp (TIMESTAMP), a self node id (hostid), a VERSION number (VERSION), a node list (peer), and in further embodiments, a reserved field (RESERVE) for subsequent upgrade use of the first formatted MESSAGE, specifically specifying a 2-byte length. Further, the message type may specify a 2-byte length, whose values may include 0 (representing a request message for the master node), 1 (representing a response message for the slave node), or other values. The timestamp field may specify a length of 4 bytes for indicating the time point at which the message is sent, and a subsequent version number field may be used in conjunction to determine whether the corresponding message is expired. Specifically in the Unix timestamp format, such as 2021-04-2916: 23:28, denoted as 1619684608. The self node ID is used to store the ID of the corresponding node, the node ID may be represented by a character string of 46 bytes, and is a unique identifier of the corresponding node, and is used to identify the identity of the node, and the corresponding node may determine the source of the message by the self node ID in the first formatted message, such as qmqvrvvofjubqgwxlfm3 Hk8Egy4 gvjgdtdwkzfwv 2 oebauw. The version number may take the form of a 2 byte length field for storing the version number of the first formatted message, the version number increasing with increasing number of transmissions, and as described above, a timestamp field may be used along with the determination of whether the current message is expired. The node list can be regarded as the message body of the first formatted message, the length is variable, and the field contents with different lengths are stored according to the actual contents. The node list stores the IDs of all the nodes in the cluster, and the leading node can determine the first formatted message which is not received according to the comparison between the node IDs stored in the node list and the self node IDs of the received messages so as to maintain the normal operation of the whole cluster system. The slave nodes can also know the existence of other nodes in the cluster according to the node list, and can be used as the master node to continue to be responsible for monitoring the functions of the internal network of the whole cluster when the slave nodes are applied to become the master node next time.

For the whole cluster, the method can be roughly divided into an election state and a consensus state, as described above, the election state is that a node in the cluster is in a candidate node, a leading node is determined through a random timing mechanism, and the consensus state is a concept opposite to the election state, that is, after the election state is finished, after a leading node is successfully confirmed, other nodes automatically become slave nodes. The election state and the consensus state are two states which alternate with each other and have a certain time periodicity, so that the leading node is ensured not to be fixedly implemented by a specific node, the leading node becomes relatively random and unpredictable, and the defects caused by high centralization are avoided. As shown in fig. 2, after the master node determines to enter the consensus state, two forms of a master node and a plurality of slave nodes are formed in the cluster, the master node and the slave nodes respectively obtain data from the data source, and the master node initiates resource record synchronization of all the slave nodes. In a specific embodiment, the master node notifies all nodes (including the slave node and the self node) to acquire data from a data source, and the acquired data can be stored and synchronized between peer nodes only after being recognized by consensus. Further, the leading node initiates a Byzantine comparison request to the secondary node, then the secondary node and the leading node calculate the acquired data by using a hash algorithm to generate a corresponding hash value, correspondingly, the secondary node sends the generated hash value to the leading node, and the final judgment process is implemented by the leading node. And the leading node compares the received hash value of each node with the hash value of the resource record acquired by the leading node to determine whether the leading node has corresponding consensus authority to update the resource record to the corresponding cluster. More specifically, the corresponding resource records are synchronized by judging whether the number of the hash values which are consistent with each other by comparison exceeds a second threshold, for example, the number of the hash values which are consistent with each other is greater than two thirds of the total number of the cluster nodes, and if the number of the hash values which are consistent with each other is less than two thirds of the total number of the cluster nodes, the operation is abandoned, that is, the resource records to be updated are not updated in the cluster, and the data is waited to be reacquired next time. And finally, the master node completes the resource record synchronization of all the nodes.

In the consensus state, different from the identity and state of the node concerned more in the election state, the main content of interaction at this time focuses on the validity and the uniformity of the resource record, for example, it is possible that a certain node performs an illegal operation and does not obtain data from a legal source, and at this time, the first formatted MESSAGE does not satisfy the corresponding interaction content, and at this time, the resource record is synchronized to interact through the second formatted MESSAGE, as shown in fig. 4, where the second formatted MESSAGE includes a MESSAGE TYPE (MESSAGE-TYPE), a VERSION number (VERSION), a hash value (MD5), a self node id (hostid), a timestamp (TIMESTAMP), and a data content (MESSAGE termination). The message type adopts a 2-byte length field, and defines field values such as 0 (indicating that a master node initiates a hash value query message to a slave node), 1 (indicating that the slave node sends a hash value message to the master node), 2 (indicating that a hash value is inconsistent), 3 (indicating that a data message is carried), and the like. The version number field may be 2 bytes, storing the version number of the message sent, incremented as the number of second formatted message sent increases, along with the timestamp content to determine whether the message is valid. The length of the hash value field can be 32 bytes, and the hash value field is determined according to a corresponding hash algorithm and is used for storing a hash value generated by the hash algorithm on data, so that the leading node determines an important basis for determining whether the data is correct. The length of the ID of the self node is 46 bytes, the ID of the self node is stored, and the ID is the unique identification of the node. The timestamp field may be 4 bytes, and is used to indicate the time when the message is sent, and determine whether the message is valid according to the version number, and the specific format may refer to the relevant timestamp description of the first formatted message. The data content field is used for storing data content, is a field which needs to be read when each node receives data, is not fixed in length and is determined according to actual content.

Fig. 5 is a schematic diagram of a DNS authoritative server distributed consensus system according to an embodiment of the present invention. The DNS authoritative server distributed consensus system specifically comprises a voting unit U1 and a synchronization unit U2. In the whole cluster system, a plurality of peer authoritative server nodes are distributed, and corresponding resource records can be directly inquired through any authoritative server node. The essence of this embodiment is that the authoritative server and the authoritative server are decentralized and relatively flat. The cluster comprises an authoritative server serving as a first node and an authoritative server serving as a second node, wherein the first node determines whether the authoritative server can be used as a leading node to organize the synchronization of resource records in the cluster or not by setting a random timing trigger. Therefore, for the first node, there are two cases, one is that the first node applies for a successful master node, and the other is that the second node applies for a successful master node, and the first node becomes a slave node. The two conditions are not determined in a fixed mode, but are triggered at random timing to ensure that the application of the leading node is in complete randomness, so that the defect of high centralization cannot be caused no matter whether the network is normal or not at a certain fixed time. For any node in the cluster, no matter the first node or the second node, the same opportunity exists to apply for the leading node, and then the leading node implements corresponding data synchronization work.

The first case is mainly implemented by the synchronization unit U2, while the second case is implemented by the voting unit U1, because the first node does not obtain the role of the leading node according to the consensus algorithm, and thus only the designated voting process is completed. In a specific embodiment, the voting unit U1 is configured to stop timing to return a voting result to the second node when receiving a voting request from the second node before triggering. When receiving a voting request of a second node, the random triggering time of the second node is earlier at the moment, and at the moment, if the voting request is applied again, a conflict is generated, the second node should be allowed to preferentially apply for a leading node according to a consensus algorithm, so that the first node should stop a corresponding timing triggering process at the moment and respond to the voting request initiated by the second node, so as to ensure that only one leading node can generate in a cluster at the same time. Preferably, when negotiating the master node with other peer nodes, the first node interacts through a first formatted message, where the first formatted message includes a message type, a timestamp, a self node ID, a version number, and a node list. In further embodiments, a reserved field is also reserved in the first formatted message to ensure extended use by subsequent implementations.

And the synchronization unit U2, configured to, when initiating a voting request after the trigger and receiving a certain vote that a peer node exceeds a first threshold, the first node becomes a leading node, and initiates resource record synchronization of all peer nodes. The synchronization unit U2 mainly has two tasks, one of which is to count the returned confirmation votes after initiating the voting request, and the other is to initiate specific data synchronization after meeting the conditions of the leader node, so that the leader node synchronizes the resource records of all nodes in the cluster, and specifically, the validity of the resource records can be judged. As described above, after the voting request is sent out, other nodes in the cluster return corresponding voting results according to a consensus algorithm, some are confirmation votes indicating agreement to become the leading node, and some are denial votes indicating refuting back to become the leading node. When determining what voting result is returned, each node may determine according to its own condition, for example, whether to conflict with its own leading node application flow. And the resource record synchronization of all peer nodes can be further initiated only if the validity of the leading node can be met when the number of votes is confirmed to exceed the first threshold value.

Further, after the first node is determined as the leading node, the synchronization unit U2 obtains a hash value of the resource record of the peer node, where the hash values of different nodes are generated by using a specified hash algorithm according to the resource record data obtained by the synchronization unit U2. The synchronization unit U2 compares the hash value fed back by other nodes with the hash value of the resource record obtained by itself to determine the validity of the resource record to be updated. Specifically, if the number of the hash values which are consistent in comparison exceeds a second threshold, resource record synchronization is implemented, otherwise, operation is abandoned, and the next data acquisition is waited. When information is exchanged between authoritative servers, a second formatted message is adopted, wherein the second formatted message comprises a message type, a version number, a hash value, a self node ID, a timestamp and data content.

In the embodiment, a random timing trigger mechanism is used, on the basis of ensuring the random property of the leading node, the system can perform election again no matter whether the network is normal or not at a certain fixed time, and the complete random property of the leading node is ensured. A first formatted message protocol for maintaining a multi-node cluster system is designed for maintaining normal operation of the system. The method uses a few majority-compliant consensus method of Byzantine to ensure that data in the multi-node cluster system is consistent (even if the data is abnormal at a certain time, the latest data can be synchronized after the system is recovered to be normal).

The implementation mode of the invention has the following characteristics: 1. non-tamper-proof, if the change data must intrude 2/3 nodes of the multi-node cluster system.

2. The reliability is high, and the normal work of the system cannot be influenced by the abnormity of part of nodes.

3. And the data of the multi-node cluster system is always consistent.

It should be noted that, the specific implementation of the distributed consensus system of the DNS authoritative server may also refer to the specific implementation of the distributed consensus method of the DNS authoritative server.

In connection with the technical solutions disclosed in the present Application, the present invention may be directly embodied as hardware, a software module executed by a control unit, or a combination of the two, that is, one or more steps and/or one or more combinations of steps, and may correspond to each software module of a computer program flow, or may correspond to each hardware module, for example, an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other Programmable logic device, a discrete Gate or crystal logic device, a discrete hardware component, or any suitable combination thereof. For convenience of description, the above-mentioned apparatuses are described as being divided into various modules by functions, and of course, the functions of the modules may be implemented in one or more software and/or hardware when implementing the present application.

From the above description of the embodiments, it is clear to those skilled in the art that the present application can also be implemented by software plus necessary general hardware platform. Based on this understanding, the technical solutions of the present application may also be embodied in the form of software products, which essentially or partially contribute to the prior art. The software may be executed by a micro-control unit, and may include one or more micro-control units of any type, depending on the desired configuration, including but not limited to a microcontroller, a DSP (Digital Signal Processor), or any combination thereof. The software is stored in a memory, such as a volatile memory (e.g., random access memory, etc.), a non-volatile memory (e.g., read-only memory, flash memory, etc.), or any combination thereof.

In summary, in the present invention, a timer triggered by a random time is used to determine one node of a plurality of peer-to-peer authoritative servers as a leading node, and the randomly determined leading node is used to uniformly initiate resource record synchronization between peer-to-peer nodes. The invention can keep the data of each node of the DNS consistent, and ensure the non-tamper property and high reliability of the DNS authority system.

It should be understood that although the present description refers to embodiments, not every embodiment contains only a single technical solution, and such description is for clarity only, and those skilled in the art should make the description as a whole, and the technical solutions in the embodiments can be appropriately combined to form other embodiments understood by those skilled in the art.

The above-listed detailed description is only a specific description of a possible embodiment of the present invention, and they are not intended to limit the scope of the present invention, and equivalent embodiments or modifications made without departing from the technical spirit of the present invention should be included in the scope of the present invention.

Claims

1. A DNS authoritative server distributed consensus method is characterized in that a plurality of peer authoritative server nodes are arranged in a distributed mode and at least comprise a first node and a second node, the first node is set to trigger at random timing, and when a voting request of the second node is received before triggering, the timing is stopped to return a voting result to the second node;

2. The DNS authority server distributed consensus method according to claim 1, wherein the first node interacts with other peer nodes through a first formatted message when negotiating about a master node, wherein the first formatted message comprises a message type, a timestamp, a self node ID, a version number, and a node list.

3. The distributed consensus method of the DNS authoritative server according to claim 1, wherein after the first node is determined as the leading node, a hash value of a resource record of a peer node is obtained and compared with the hash value of the resource record obtained by the first node.

4. The distributed consensus method for the DNS authoritative server according to claim 3, wherein the number of the compared hash values exceeds a second threshold, resource record synchronization is performed, otherwise, the operation is abandoned, and the next data acquisition is waited.

5. The distributed consensus method for DNS authoritative servers according to claim 1, wherein resource record synchronization is interacted through a second formatted message, said second formatted message comprising message type, version number, hash value, self node ID, timestamp, data content.

6. A DNS authoritative server distributed consensus system is characterized in that a plurality of peer authoritative server nodes are arranged in a distributed mode, the authoritative server nodes at least comprise a first node and a second node, the first node is set to trigger at random timing, and the system further comprises:

7. The DNS authority server distributed consensus system according to claim 6, wherein the first node interacts with other peer nodes when negotiating about the master node through a first formatted message, the first formatted message comprising a message type, a timestamp, a self node ID, a version number, a node list.

8. The distributed consensus system of claim 6, wherein the synchronization unit obtains a hash value of the resource record of the peer node after the first node is determined to be the master node, and compares the hash value with a hash value of the resource record obtained by the synchronization unit.

9. The distributed consensus system of claim 8, wherein the number of hash value comparisons exceeds a second threshold, performing resource record synchronization, and otherwise abandoning the operation and waiting for the next data acquisition.

10. The DNS authoritative server distributed consensus system as claimed in claim 6, wherein resource record synchronization is interacted via a second formatted message comprising message type, version number, hash value, self node ID, timestamp, data content.