An abstract verification method, device and related equipment

Abstract

The application discloses a digest verification method and device and related equipment, and relates to the technical field of communication. A DNS slave server receives target digest and change information of zone data, the change information being used for indicating addition, deletion or modification of the zone data, a check digest being generated through one-level operation according to the change information and a reference digest, and verification being passed when the check digest is consistent with the target digest. A DNS master server obtains change information of zone data, generates a target digest according to the change information and a reference digest, and sends the change information and the target digest, so that the DNS slave server verifies the target digest. In this way, the target digest is generated by the DNS master server and verified by the slave server based on the check digest generated based on the change information, the DNS master server and the DNS slave server do not need to recalculate the digest for the changed full data, thereby reducing the calculation overhead of the digest verification process and improving the verification efficiency in the zone data incremental update scenario.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a digest verification method, apparatus and related equipment. Background Technology

[0002] The Domain Name System (DNS), as an infrastructure of the Internet, typically employs a DNS master-slave server architecture and uses a zone data transfer mechanism to synchronize zone data between the DNS master server and the DNS slave server. Zone data includes all resource records within a DNS zone, and during operation and maintenance, it undergoes frequent addition, deletion, or modification operations to respond to needs such as domain name registration changes, Internet Protocol (IP) updates, or policy adjustments.

[0003] During zone data synchronization, the DNS slave server needs to verify the integrity of the acquired zone data and whether it has been corrupted during storage or transmission. To do this, the DNS master server can normalize the resource records in the zone data and generate a digest, which is then sent to the DNS slave server along with the zone data. After receiving the zone data, the DNS slave server performs the same normalization process and generates its own digest. It then compares the digest generated by the DNS slave server with the digest provided by the DNS master server. If they match, it is determined that the zone data received by the DNS slave server is consistent with the zone data corresponding to the digest generated by the DNS master server.

[0004] However, with the expansion of DNS deployment and the increase in the frequency of zone data synchronization, the volume of zone data continues to grow, which makes the computational overhead of the digest verification process large and the verification efficiency low. Summary of the Invention

[0005] In view of this, this application provides a digest verification method, apparatus and related equipment, which can reduce the computational overhead of digest verification and improve the verification efficiency of regional data digests during the process of regional data synchronization.

[0006] Firstly, this application provides a digest verification method applied to a DNS slave server. The DNS slave server receives a target digest and change information for zone data. The zone data includes all resource records within the DNS zone. The change information includes change indication information or change data. The change indication information indicates the addition, deletion, or modification of the zone data. The change data refers to data added to the zone data, data deleted from the zone data, or data modified within the zone data during the current change process. The DNS slave server generates a verification digest based on the change information and a base digest. The base digest is a digest generated based on the zone data stored in the DNS slave server. The verification digest is obtained by performing a first-level operation between the base digest and an incremental digest generated based on the change data. The modification operation is broken down into deleting the data before modification and adding the data after modification, and the incremental digest is generated in the same manner as when adding or deleting data. When the verification digest matches the target digest, the DNS slave server determines that the target digest has passed verification.

[0007] In this way, after receiving the change information and target digest of the zone data, the DNS slave server can calculate the check digest based on the base digest corresponding to the zone data before the change and the current change information, and then compare the check digest with the target digest for consistency. Since the check digest is obtained by a single-level operation between the base digest and the incremental digest, and the incremental digest can be generated based on the newly added, deleted, or modified data indicated by the change information, the DNS slave server does not need to recalculate the digest for all the changed zone data. Instead, it can calculate the check digest based on the incremental digest involved in the current change information, thereby reducing the computational overhead of the digest verification process and improving the verification efficiency in the scenario of incremental update of zone data.

[0008] In one possible implementation, the DNS slave server can also update the locally stored zone data based on the change information after the target digest has been verified. Verification of the target digest indicates that the checksum generated by the DNS slave server based on the local base digest and the change information is consistent with the target digest provided by the DNS master server. In this case, the DNS slave server can assume that the received change information matches the zone data change information used by the DNS master server when generating the target digest, and then write the data indicated by the change information into its local zone data. Thus, the DNS slave server only updates the local zone data with the data indicated by the change information after confirming that the target digest has been verified, avoiding the direct writing of incomplete, erroneous, or inconsistent change data with the DNS master server into its local zone data.

[0009] In one possible implementation, the DNS can also obtain a first identifier and a second identifier from the server, and associate and store the first identifier, the second identifier, and the incremental digest corresponding to the current zone data change to obtain an incremental digest record. The first identifier is used to distinguish the zone data before the change, and the second identifier is used to distinguish the zone data after the change. Both can be zone data version numbers, sequence numbers, generation times, or other information that can uniquely identify the zone data status. In this way, the zone data before and after the change corresponding to each incremental digest can be clearly identified, establishing the association between adjacent zone data versions and providing a data foundation for abnormal version location and historical digest recovery of the zone data change process.

[0010] In one possible implementation, before receiving the target digest and zone data change information, the DNS slave server can first receive the initial zone data and its corresponding initial digest. The initial zone data may include all resource records of the DNS zone in its initial state. The DNS slave server can use the same digest generation rules as the DNS master server to independently generate a local digest based on the received initial zone data and compare the local digest with the initial digest. When the local digest matches the initial digest, it can be determined that the initial zone data received by the DNS slave server is consistent with the zone data corresponding to the initial digest generated by the DNS master server. The DNS slave server can save this local digest and use it as the base digest for subsequent verification digest generation. In this way, a verified initial zone data state can be established before entering the incremental digest verification process, avoiding the use of erroneous or incomplete zone data digests as the starting point for subsequent incremental verification calculations.

[0011] In one possible implementation, when the checksum generated by the DNS slave server is inconsistent with the target digest provided by the DNS master server, the DNS slave server can also send a full data transfer request to request all resource records in the DNS zone. The DNS slave server re-receives all zone data and their corresponding digests for the current version through the full data transfer, thereby re-establishing the base digest used for subsequent incremental verification. In this way, a full data transfer can be requested when incremental verification is inconsistent, restoring the consistency between the DNS master server and the DNS slave server.

[0012] In one possible implementation, the DNS slave server can also normalize the data indicated by the change information, map the normalized data to a mapping result, and then generate an incremental digest based on the mapping result. Normalization is used to represent the data to be processed according to uniform rules, reducing the possibility of different mapping results for the same resource record due to different representations. Mapping is used to convert the normalized data into data objects that can participate in digest calculations; the mapping result is data that can participate in first-level calculations. In this way, data with the same semantics but different representations can obtain consistent or comparable mapping results, providing a unified data processing foundation for the DNS slave server to independently generate digests according to the same rules, reducing the possibility of digest verification failure due to differences in data representation.

[0013] In one possible implementation, when the DNS slave server obtains the mapping result based on change information, it can specifically determine the changed data based on the change information. The changed data includes data added to the zone data or data deleted from the zone data. For directly added resource records, the DNS slave server can determine the corresponding resource record as added data; for directly deleted resource records, the DNS slave server can determine the corresponding resource record as deleted data; for resource records that have been modified, the DNS slave server can convert the modification process into data before deletion and data after addition / modification. The DNS slave server can normalize the determined added and deleted data separately and map the normalized data to the corresponding mapping result. In this way, the three types of zone data changes—addition, deletion, and modification—can be uniformly converted into added data processing and deleted data processing, enabling different change types to use a consistent normalization and mapping process.

[0014] In one possible implementation, the mapping result includes a first sub-mapping result and a second sub-mapping result. The first sub-mapping result is obtained based on data added to the zone data, and the second sub-mapping result is obtained based on data deleted from the zone data. When the DNS slave server generates an incremental summary based on the mapping result, it may specifically perform a single-level operation on the first and second sub-mapping results to obtain the incremental summary. In this way, the incremental summary is generated directly based on the data that has been added and deleted, limiting the summary calculation to the data that has actually changed, without having to reprocess other unchanged resource records in the zone data.

[0015] Secondly, embodiments of this application provide a digest verification method, which can be applied to a DNS master server. The DNS master server obtains change information for zone data, including all resource records within the DNS zone. The change information indicates the addition, deletion, or modification of the zone data, and includes change indication information and / or change data. The change indication information indicates the operation type, and the change data is the specific data involved in the change. The DNS master server generates a target digest based on the change information and a base digest. The base digest is a digest generated based on the zone data before the change stored in the DNS master server. The target digest is obtained by performing a first-level operation between the base digest and an incremental digest generated based on the change data. The incremental digest characterizes the change in the digest caused by the current zone data change. The DNS master server sends the change information and the target digest to a DNS slave server for verification.

[0016] In this way, the DNS master server can generate a target summary based on the base summary corresponding to the zone data before the change and the current change information, according to the change information of the zone data. The target summary is obtained by a first-level operation from the base summary and the incremental summary generated based on the newly added, deleted, or modified data indicated by the change information. Since the calculation of the target summary only involves the data that has changed in this operation, it is not necessary to re-traverse and calculate all zone data. Therefore, it can reduce the computational overhead of the master server in generating the target summary and improve the summary update efficiency in scenarios where DNS zone data is frequently updated.

[0017] In one possible implementation, before obtaining change information for the zone data, the DNS master server can generate an initial digest based on the initial zone data and send the initial zone data and initial digest to the DNS slave server. The initial zone data includes all resource records when the DNS zone is in its initial version. The DNS master server generates the initial digest using the digest generation rules used for incremental digest calculation. In this way, the DNS slave server can obtain complete initial zone data and the corresponding digest verification basis, establishing a consistent initial state for subsequent incremental digest verification.

[0018] In one possible implementation, the DNS master server can also receive full data transmission requests from the DNS slave server and send the full data and target digest corresponding to the current DNS zone to the DNS slave server. This allows the DNS slave server to restore a zone data state consistent with the DNS master server when it is unable to continue incremental verification based on the original baseline digest, improving the anomaly recovery capability of the master-slave synchronization process.

[0019] In one possible implementation, the DNS master server can also normalize the data indicated by the change information based on the change information, map the normalized data to a mapping result, and then generate an incremental digest based on the mapping result. The normalization rules and mapping rules used by the DNS master server are the same as those used by the DNS slave server. In this way, the same changed data can obtain consistent or comparable mapping results on the DNS master server and DNS slave server, providing a consistent calculation basis for digest generation on both sides and reducing the possibility of digest differences due to different processing rules.

[0020] In one possible implementation, when the DNS master server obtains the mapping result based on change information, it may specifically determine the changed data based on the change information. The changed data includes at least one of data added to the zone data and data deleted from the zone data. For modification operations, the DNS master server determines the data before modification as deleted data and the data after modification as added data, and performs normalization and mapping processing on each respectively. In this way, add, delete, and modify operations can be uniformly converted into processing for added and deleted data, enabling the incremental summary generation process to cover different forms of zone data changes.

[0021] In one possible implementation, the mapping result obtained by the DNS master server includes a first sub-mapping result and a second sub-mapping result. The first sub-mapping result is obtained based on newly added data, and the second sub-mapping result is obtained based on deleted data. When generating an incremental digest based on the mapping result, the DNS master server may specifically perform a single-level operation on the first and second sub-mapping results to obtain the incremental digest. In this way, the DNS master server only generates an incremental digest based on the newly added and deleted data, and then applies the incremental digest to the base digest to generate the target digest, avoiding the need to re-traverse and recalculate all resource records every time the zone data changes.

[0022] Thirdly, embodiments of this application provide a digest verification device, which can be applied to a DNS slave server. The digest verification device may include a receiving module, a generating module, and a determining module. The receiving module can be used to receive a target digest and change information of zone data; the generating module can be used to generate an incremental digest based on the change information, and generate a verification digest based on the incremental digest and a baseline digest stored in the DNS slave server; the determining module can be used to compare the verification digest with the target digest, and determine that the target digest has passed verification when the verification digest matches the target digest. Specifically, after the receiving module receives the target digest and change information, the generating module generates the verification digest through a first-level operation based on the change information and the baseline digest, and the determining module determines that the verification has passed when the verification digest matches the target digest.

[0023] In one possible implementation, the digest verification device further includes an update module for updating the zone data stored by the DNS from the server based on change information if the target digest passes verification.

[0024] In one possible implementation, the digest verification device further includes an acquisition module and a storage module. The acquisition module is used to acquire a first identifier and a second identifier. The first identifier is used to identify the area data before the change, and the second identifier is used to identify the area data after the change. The storage module is used to associate and store the incremental digest, the first identifier, and the second identifier to obtain an incremental digest record.

[0025] In one possible implementation, the receiving module is further configured to receive initial zone data and an initial digest corresponding to the initial zone data, wherein the initial zone data includes all resource records initially in the DNS zone; the generating module is further configured to generate a local digest based on the initial zone data; and the storage module is further configured to save the local digest in the DNS slave server if the local digest is consistent with the initial digest, wherein the base digest is the local digest.

[0026] In one possible implementation, the digest verification device further includes a sending module for sending a full data transmission request when the verification digest is inconsistent with the target digest. The full data transmission request is used to request the transmission of all resource records in the DNS zone.

[0027] In one possible implementation, the digest verification device further includes an acquisition module for obtaining a mapping result based on the change information, wherein the mapping result is obtained by mapping the data indicated by the change information after normalization; and a generation module for generating an incremental digest based on the mapping result.

[0028] In one possible implementation, the acquisition module is used to determine the changed data based on the change information. The changed data is either data added to the area data or data deleted from the area data. In the case of data modification in the area data, the data before modification is the data deleted from the area data, and the data after modification is the data added to the area data. The module then performs normalization processing on the changed data and maps the normalized changed data to obtain a mapping result.

[0029] In one possible implementation, the mapping result includes a first sub-mapping result and a second sub-mapping result, the first sub-mapping result being obtained based on data added to the region; the acquisition module is used to perform a first-level operation on the first sub-mapping result and the second sub-mapping result to obtain an incremental summary.

[0030] Since the abstract verification apparatus provided in the third aspect corresponds to the abstract verification method provided in the first aspect, the technical effects of the third aspect and its embodiments can be found in the corresponding first aspect and its embodiments, and will not be repeated here.

[0031] Fourthly, embodiments of this application provide a digest verification device that can be applied to a DNS master server. The digest verification device may include an acquisition module, a generation module, and a sending module. The acquisition module can be used to acquire change information of zone data in the DNS master server; the generation module can be used to generate an incremental digest based on the change information, and generate a target digest based on the incremental digest and a base digest; the sending module can be used to send the change information and the target digest, enabling the DNS slave server to independently generate a verification digest based on the change information and complete consistency verification using the target digest. Specifically, after the acquisition module acquires the change information, the generation module generates the target digest through a first-level operation based on the change information and the base digest, and the sending module sends the change information and the target digest to the DNS slave server for verification of the target digest by the DNS slave server.

[0032] In one possible implementation, the generation module is further configured to generate an initial digest corresponding to the initial zone data based on the initial zone data in the DNS master server, wherein the initial zone data includes all the initial resource records in the DNS zone; the sending module is further configured to send the initial zone data and the initial digest.

[0033] In one possible implementation, the digest verification device further includes a receiving module for receiving a full data transmission request, the full data transmission request being used to request the transmission of all resource records within the DNS zone; and a sending module for sending the full data and the target digest to the DNS slave server that sent the full data transmission request.

[0034] In one possible implementation, the acquisition module is further configured to obtain a mapping result based on the change information, wherein the mapping result is obtained by mapping the data indicated by the change information after normalization; the generation module is further configured to generate an incremental summary based on the mapping result.

[0035] In one possible implementation, the acquisition module is used to determine the changed data based on the change information. The changed data is either data added to the area data or data deleted from the area data. In the case of data modification in the area data, the data before modification is the data deleted from the area data, and the data after modification is the data added to the area data. The module then performs normalization processing on the changed data and maps the normalized changed data to obtain a mapping result.

[0036] In one possible implementation, the mapping result includes a first sub-mapping result and a second sub-mapping result. The first sub-mapping result is obtained based on the data added to the region. The generation module is used to perform a first-level operation on the first sub-mapping result and the second sub-mapping result to obtain an incremental summary.

[0037] Since the abstract verification apparatus provided in the fourth aspect corresponds to the abstract verification method provided in the second aspect, the technical effects of the fourth aspect and its embodiments can be found in the corresponding second aspect and its embodiments, and will not be repeated here.

[0038] Fifthly, this application provides a computing device including a processor and a memory. The processor and the memory communicate with each other. The processor executes instructions stored in the memory to cause the computing device to perform a digest verification method as described in the first aspect, the second aspect, or any implementation thereof. It should be noted that the memory may be integrated into the processor or may be independent of the processor. The computing device may also include a bus. The processor is connected to the memory via the bus. The memory may include readable storage memory and random access memory.

[0039] Sixthly, this application provides a computer-readable storage medium storing instructions that, when executed on a computing device, cause the computing device to perform the operation steps of the digest verification method in the first aspect, the second aspect, or any implementation thereof.

[0040] In a seventh aspect, this application provides a computer program product, which includes instructions that, when executed on a computing device, cause the computing device to perform the operation steps of the digest verification method in the first aspect, the second aspect, or any implementation thereof.

[0041] Furthermore, the technical effects of any of the implementation methods in aspects five through seven can be found in the technical effects of different implementation methods in aspect one, and will not be repeated here.

[0042] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0044] Figure 1 This is a schematic diagram of the structure of a digest verification system provided in an embodiment of this application; Figure 2 This application provides a schematic diagram of the interaction process between a DNS master server and a DNS slave server in an embodiment of the present application. Figure 3 A flowchart for DNS slave server digest verification is provided as an embodiment of this application; Figure 4 A flowchart for DNS master server digest verification is provided as an embodiment of this application; Figure 5 A schematic diagram illustrating a DNS version tracing record from a server, provided as an embodiment of this application; Figure 6 A schematic diagram of a digest verification device applied to a DNS slave server is provided in an embodiment of this application; Figure 7 A schematic diagram of a digest verification device applied to a DNS master server is provided in an embodiment of this application; Figure 8 This is a schematic diagram of the hardware structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0045] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate; this is merely a method of distinction used in describing objects with the same attributes in the embodiments of this application.

[0046] For ease of understanding and explanation, some of the technical terms mentioned in this application will be explained by example below.

[0047] DNS can divide a domain name space into multiple DNS zones, each managed by a corresponding server. Zone data is a set of resource records contained in a DNS zone at a specific state, used to describe the domain names within that DNS zone and their corresponding resolution information. Zone data may include start of authority (SOA) resource records.

[0048] SOA resource records can be used to record management information for DNS zones. SOA resource records can include sequence numbers, which identify the zone data version. After the DNS master server makes a valid change to the zone data, it can change the SOA sequence number accordingly, so that different SOA sequence numbers correspond to different versions of the zone data.

[0049] DNS typically uses a master-slave server architecture to store zone data. The master DNS server stores and manages the current version of the zone data, while the slave DNS server retrieves the zone data from the master. The slave server can determine whether the version of the zone data in the master DNS server differs from the version of the zone data stored locally based on the SOA sequence number. If the versions are inconsistent, the slave server initiates a zone data transfer to ensure consistency between the zone data stored by the master and slave servers. This zone data transfer can include full zone transfer (AXFR) and incremental zone transfer (IXFR).

[0050] AXFR can be used to transmit all resource records of a DNS zone in the current version. When a DNS slave server has not yet saved the zone data for that DNS zone, cannot determine the trustworthiness of the zone data, or needs to rebuild complete zone data, it can use AXFR to obtain all zone data from the DNS master server in the current version.

[0051] IXFRs can be used to transmit data that has changed between two versions of zone data. When a DNS slave server already stores a version of zone data, and the DNS master server can obtain the changes between that version and the current version, IXFRs can be used to transmit data that has been added, deleted, or modified between adjacent versions or multiple consecutive versions, without having to retransmit other unchanged resource records.

[0052] Change information can be used to characterize changes that occur in zone data during a change process. Change information can include change indication information or change data. Change indication information can indicate that zone data has been added, deleted, or modified. Change data can include data added to the zone data, data deleted from the zone data, or, alternatively, data before and after the modification. Change information is primarily used to identify the data involved in this zone data change and serves as the data input for the DNS master server and DNS slave servers to generate incremental summaries.

[0053] A baseline digest can be a digest generated based on the zone data before the change. DNS master and DNS slave servers can each store a baseline digest corresponding to the current zone data. The baseline digest can be an initial digest corresponding to the initial zone data or a digest saved after the previous zone data change. The baseline digest is primarily used to characterize the currently confirmed state of the zone data and serves as the basis for calculating the target digest or checksum.

[0054] An incremental summary is a summary generated based on the data involved in the current zone data change. It characterizes the changes to the overall zone data summary caused by added, deleted, or modified data. The incremental summary can be fixed-length data, elements of a finite group, elliptic curve points, or other data objects that can participate in the summary calculation. The incremental summary is primarily used to combine with the base summary, allowing the DNS master server and DNS slave server to generate summaries corresponding to the changed zone data without reprocessing all resource records in the zone data.

[0055] The target digest is a digest generated by the DNS master server for the changed zone data. The DNS master server can generate the target digest based on the base digest and the incremental digest, and then send the target digest to the DNS slave servers. The target digest is mainly used to characterize the changed zone data state on the DNS master server side, and serves as a reference digest for the DNS slave servers to perform digest consistency comparisons.

[0056] The checksum can be a digest generated by the DNS slave server based on the locally stored base digest and the received change information. The DNS slave server can generate a local incremental digest based on the change information, and then generate a checksum based on the local incremental digest and the base digest. The checksum is mainly used to characterize the changed zone data status inferred by the DNS slave server based on the local zone data status and the current change information.

[0057] Level 1 operations can be digest combination operations adapted to digest algorithms, including addition and subtraction operations.

[0058] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0059] See Figure 1 The diagram below is a schematic diagram of the structure of an exemplary digest verification system 100. The digest verification system 100 may include a DNS master server 110 and a DNS slave server 120. The DNS master server 110 and the DNS slave server 120 may communicate with each other via wired or wireless means.

[0060] The DNS master server 110 can be the master node of a DNS zone, the primary authoritative server, the data maintenance node, or other computing devices capable of storing and managing DNS zone data. The DNS master server 110 can store the zone data corresponding to the DNS zone and the digest corresponding to the zone data, and can also obtain change information of the zone data.

[0061] DNS slave server 120 can be a slave node of a DNS zone, a secondary authoritative server, a data replica node, or other computing device capable of synchronizing zone data from DNS master server 110. DNS slave server 120 can store verified zone data and corresponding base summaries.

[0062] In the existing DNS zone data digest verification process, the DNS master server 110 can send the digest corresponding to the modified zone data to the DNS slave server 120. After receiving the zone data sent by the DNS master server 110, the DNS slave server 120 can perform digest calculation on the modified zone data according to the same digest calculation method as the DNS master server 110 to obtain a local digest. Then, the DNS slave server 120 compares the calculated local digest with the digest sent by the DNS master server 110 to determine whether the zone data received by the DNS slave server 120 is consistent with the zone data sent by the DNS master server 110.

[0063] However, zone data includes all resource records within the DNS zone. When DNS server 120 needs to regenerate a digest based on the changed zone data, the digest calculation needs to process all resource records in the changed zone data. The computational load is affected by the overall size of the zone data. As the number of resource records in the DNS zone increases, the digest verification process requires more computational resources, resulting in low digest verification efficiency.

[0064] To address the aforementioned issues, this application provides a digest verification method applied to a DNS slave server 120. The DNS slave server 120 receives a target digest and change information for zone data. Simultaneously, the DNS slave server 120 stores a base digest generated based on the current zone data. The DNS slave server 120 generates an incremental digest based on the added, deleted, or modified data indicated by the change information, and performs a first-level operation on the base digest and incremental digest to obtain a verification digest. Subsequently, the DNS slave server 120 compares the verification digest with the target digest. If they match, the target digest is determined to have passed verification.

[0065] Therefore, DNS server 120 can reuse the base digest corresponding to the zone data before the change and generate an incremental digest only based on the data involved in this zone data change. The check digest is then obtained using the base digest and the incremental digest, without needing to recalculate the digest for all the changed data. Thus, the computational cost of the digest verification process mainly depends on the amount of data that has changed, rather than directly on the overall size of the zone data, thereby reducing the computational overhead of digest verification and improving the efficiency of zone data digest verification.

[0066] Figure 1Only one DNS master server 110 and one DNS slave server 120 are shown in the illustration. In other possible implementations, one DNS master server 110 may communicate with multiple DNS slave servers 120, and the multiple DNS slave servers 120 may perform zone data synchronization and digest verification on the zone data according to the same digest verification rules. Alternatively, the DNS master server 110 and the DNS slave servers 120 may communicate through one or more network devices, load balancing devices or security gateways. This application does not limit the scope of the invention.

[0067] For ease of understanding, embodiments of the abstract verification method provided in this application are described below with reference to the accompanying drawings.

[0068] like Figure 2 As shown, this application embodiment provides a digest verification interaction process between a DNS master server 110 and a DNS slave server 120. This interaction process may include initial state establishment, target digest generation, verification digest generation, digest matching, and matching result processing, such as... Figure 2 Steps S201 to S210 in the process.

[0069] S201: DNS primary server 110 generates the initial digest corresponding to the initial zone data.

[0070] The initial zone data can be all resource records contained in the initial version of the DNS zone. The initial version can be the version corresponding to the initial establishment of the DNS zone, or the version selected when the DNS slave server 120 first synchronizes zone data or re-establishes zone data. The DNS master server 110 can first divide the initial zone data into multiple data elements, which can be a single resource record or a resource record set (RRset). The DNS master server 110 can normalize each data element separately, then map the normalized data elements into mapping results that can participate in the first-level operation, and finally perform the first-level operation on all mapping results to obtain the initial digest. Then, the DNS master server 110 sends the initial zone data and the initial digest to the DNS slave server 120.

[0071] S202: DNS server 120 generates a local digest based on the initial zone data.

[0072] After receiving the initial zone data and initial digest sent by the DNS master server 110, the DNS slave server 120 can divide the received initial zone data into multiple data elements. The data elements can be a single resource record or an RRset.

[0073] In this embodiment, the following methods for dividing area data are provided.

[0074] In one possible implementation, the DNS slave server 120 may use a single resource record as a data element, and may treat each resource record in the initial zone data as a separate data element.

[0075] In another possible implementation, the DNS slave server 120 can group the resource records in the initial zone data according to the owner name, resource record type, and resource record category, so that resource records with the same owner name, resource record type, and resource record category constitute an RRset. Here, the owner name is used to indicate the object described by the resource record, the resource record type is used to indicate the meaning and format of the resource data in the resource record, and the resource record category is used to indicate the protocol category or namespace category to which the resource record belongs.

[0076] It should be noted that the above-described method of partitioning zone data is merely an illustrative example and is not intended to limit the scope. In other embodiments, the DNS slave server 120 may also employ other methods capable of partitioning zone data.

[0077] After determining each data element, DNS server 120 can perform normalization processing on each data element. Normalization processing is used to convert data with the same content but different representations into a unified data format. For example, it can unify the character format of domain names, the order of fields, and the character encoding method. When the data element is an RRset, it can also arrange the resource records in the RRset according to a unified sorting rule and combine the sorted resource records into a normalized data object.

[0078] DNS server 120 can map each normalized data element to a mapping result that can participate in the first-level operation. In an implementation using elliptic curve multiset hash (ECMH), the mapping result can be an elliptic curve point. For example, after normalization and mapping, data element R_i can be obtained as an elliptic curve point Point(R_i).

[0079] DNS server 120 can perform first-level operations on the mapping results of all data elements to obtain a local digest.

[0080] S203: If the local digest is consistent with the initial digest, the DNS slave server 120 saves the local digest as the base digest.

[0081] In one possible implementation, when the local digest matches the initial digest, the DNS slave server 120 can determine that the received initial zone data is consistent with the zone data generated by the DNS master server 110 when the initial digest was generated. The DNS slave server 120 can save the local digest and use it as a base digest for subsequent incremental digest verification. Thus, the DNS master server 110 and the DNS slave server 120 can establish a consistent initial zone data state.

[0082] S204: DNS primary server 110 obtains change information and generates a target digest.

[0083] DNS master server 110 can generate an incremental digest based on the data indicated by the change information, and perform a first-level operation on the base digest and incremental digest to obtain the target digest corresponding to the changed zone data. For data modifications, the modification process can be transformed into deleting the data before the modification and adding the modified data.

[0084] S205: DNS master server 110 sends the change information and target summary to DNS slave server 120.

[0085] Change information and target digest can be carried in the same transport message or in separate transport messages. The target digest is used to provide the DNS slave server 120 with a basis for comparing the digests corresponding to the changed zone data.

[0086] In this embodiment, the following non-limiting implementations of change information are provided.

[0087] This change information may include change instructions or change data.

[0088] In the first specific implementation, the change information can be change instruction information. The change instruction information can include the change operation type and the corresponding data identifier. The change operation type can include adding, deleting, or modifying, and the data identifier indicates the data for which the corresponding change operation is performed. The DNS slave server 120 can determine the data to be changed and the corresponding change method based on the change operation type and the data identifier. For example, the DNS slave server 120 stores the resource record "www.example.com A 192.0.2.10" before the change. The change instruction information sent by the DNS master server 110 can indicate: the change operation type is modification, the data identifier is the resource record with the owner name "www.example.com" and resource record type A, and the change parameter is to modify the network address in the resource record to 192.0.2.20. The DNS slave server 120 can determine the resource record before the change "www.example.com A 192.0.2.10" based on the data identifier, and determine the resource record after the change as "www.example.com A 192.0.2.20" based on the change parameter. Furthermore, DNS server 120 can convert this modification operation into deleting the resource record before the change and adding the resource record after the change.

[0089] In the second specific implementation, the change information can be change data. The change data can directly include the specific data involved in this zone data change. For example, the resource record was "www.example.com A192.0.2.10" before the change and "www.example.com A 192.0.2.20" after the change. The change data sent by the DNS master server 110 can directly include the resource record to be deleted, "www.example.com A 192.0.2.10", and the resource record to be added, "www.example.com A 192.0.2.20". After receiving the change data from server 120, the DNS can directly identify "www.example.com A 192.0.2.10" as deleted data and "www.example.com A192.0.2.20" as added data.

[0090] It should be noted that the above-described implementation method of change information is illustrative and not intended to limit the scope. In other embodiments, the DNS master server 110 may also use other methods capable of representing changes in zone data to generate or send change information.

[0091] S206: DNS server 120 generates a checksum based on change information and baseline summary.

[0092] DNS slave server 120 can generate incremental digests based on the newly added, deleted, or modified data indicated by the change information, according to the same data processing rules as DNS master server 110, and perform first-level operations on the locally stored base digest and incremental digests to obtain a check digest.

[0093] Since DNS master server 110 and DNS slave server 120 perform digest calculations based on the same change information and their respective stored base digests, the check digest generated by DNS slave server 120 should be consistent with the target digest sent by DNS master server 110 if the base zone data status of DNS slave server 120 and DNS master server 110 is consistent, the change information is complete, and the digest generation rules are the same.

[0094] S207: DNS server 120 matches the checksum with the target digest. If the checksum and target digest match, proceed to step S208; if they do not match, proceed to step S209.

[0095] S208: DNS server 120 makes corresponding changes to the zone data stored locally based on the change information.

[0096] After completing the changes to the local zone data, the DNS server 120 saves the checksum as a new base digest for use in verifying the digest corresponding to the next zone data change.

[0097] For example, when the change information indicates the addition of data, DNS slave server 120 can write the new data into its local data set; when the change information indicates the deletion of data, DNS slave server 120 can remove the corresponding data from its local data set; when the change information indicates the modification of data, DNS slave server 120 can delete the data before modification and write the modified data. By modifying the local data only after a successful digest match, unverified changes can be avoided from being directly written to DNS slave server 120.

[0098] S209: DNS slave server 120 sends a full rebuild request to DNS master server 110.

[0099] In one possible implementation, DNS slave server 120 compares the check digest with the target digest. When DNS slave server 120 determines that the check digest and the target digest are inconsistent, DNS slave server 120 can send a full reconstruction request to DNS master server 110. The full reconstruction request can be a full data transmission request for DNS slave server 120 to request DNS master server 110 to transmit all resource records in the current DNS zone.

[0100] S210: DNS master server 110 responds to the full rebuild request, sending the full data and target digest.

[0101] After receiving the full data, DNS slave server 120 can regenerate a local digest based on the full data. DNS slave server 120 can compare the regenerated local digest with the target digest to re-establish a zone data state consistent with that of DNS master server 110.

[0102] Through the above interaction process, DNS slave server 120 can generate a verification digest using the locally stored baseline digest and the data involved in the current change, without having to recalculate the digest for all resource records every time the zone data changes, thereby reducing the computational overhead of the digest verification process. If the verification digest does not match the target digest, DNS slave server 120 can request the full data to avoid adding subsequent changes to an uncertain zone data state.

[0103] The following is combined Figure 3 The summary verification process performed by DNS server 120 is described further below. See [link to documentation]. Figure 3 The diagram illustrates a flowchart of a summary verification method. Figure 3 The method shown can be derived from Figure 1 The DNS execution can be performed by the DNS slave server 120, or by a data processing device that is communicatively connected to the DNS slave server 120. Figure 3 Step S301 can be used to establish the initial calculation basis for incremental digest verification, steps S302 to S307 can be used to generate and verify the verification digest, and steps S308 to S309 can be used to process the local data based on the verification results.

[0104] S301: DNS saves the local digest as a base digest from server 120.

[0105] In one possible implementation, DNS slave server 120 can receive initial zone data and the corresponding initial digest via AXFR. The initial zone data can be all resource records contained in a DNS zone in a given initial version, and the initial digest can be generated by DNS master server 110 based on the same initial zone data.

[0106] For example, after receiving the initial zone data, DNS slave server 120 can independently generate a local summary using the same summary generation method as DNS master server 110, and can compare the local summary with the initial summary. If the local summary matches the initial summary, it can be determined that the initial zone data received by DNS slave server 120 is consistent with the zone data used by DNS master server 110 when generating the initial summary. DNS slave server 120 can save the local summary and use it as the base summary. If the two are inconsistent, DNS slave server 120 can choose not to load the received initial zone data and can request the full data again.

[0107] The initial digest can be the digest field in a zone message digest (ZONEMD) record. Furthermore, the existing record format of the ZONEMD resource record can be maintained, and the new value of the digest scheme field can indicate whether ECMH is used to generate the digest. For example, when the scheme value is 3, it can indicate that ECMH-P256 is used to generate the digest; when the scheme value is 4, it can indicate that ECMH-P384 is used. When the DNS slave server 120 uses ECMH-P256 to generate the digest, the digest can be a 33-byte elliptic curve compression point, corresponding to 128-bit security strength; when the DNS slave server 120 uses ECMH-P384 to generate the digest, the digest can be a 49-byte elliptic curve compression point, corresponding to 192-bit security strength. Existing scheme values ​​can continue to be used to indicate existing digest algorithms, thus supporting the generation of digests using homomorphic digest algorithms without changing the overall format of the ZONEMD resource record. The DNS slave server 120 can independently generate a digest based on the full data and compare it with the digest field in the ZONEMD record. This full verification process can establish a reliable initial computational foundation for subsequent incremental digest verification, and can also be performed when it is necessary to rebuild the local data from DNS server 120.

[0108] In one implementation using ECMH to generate digests, the DNS slave server 120 can divide the initial zone data into multiple independent data elements, where each data element can be a single resource record or an RRset. The DNS slave server 120 can map each data element to a point in an elliptic curve finite group, and then perform point addition on each point to obtain the digest corresponding to the initial zone data. Point addition can be a group operation between two points within the same elliptic curve group. After performing point addition on two elliptic curve points, the result is still a point in that elliptic curve group; therefore, the result of point addition can continue to be used to perform point addition on other elliptic curve points. For example, the first data element, after mapping, yields an elliptic curve point P, and the second data element, after mapping, yields an elliptic curve point Q. Performing point addition on elliptic curve points P and Q yields an elliptic curve point R.

[0109] The data elements included in the initial region can be represented as follows: , ... Then the local summary can be represented as: ; When storing or transmitting the digest, the DNS slave server 120 can also compress the dot addition result to reduce the storage space or number of bytes transmitted. The compression encoding can include an x-coordinate and a y-coordinate identifier. The y-coordinate identifier can be used to indicate the y-coordinate or other information that can distinguish between the two possible y-coordinate values. After reading the x-coordinate, the decoding device can calculate the two possible y-coordinate values ​​according to the elliptic curve equation, and then select one of the possible values ​​based on the y-coordinate identifier to reconstruct the point. For example, when using a P-256 elliptic curve, the x-coordinate can occupy 32 bytes, and the compression encoding can also include a 1-byte format identifier and a y-coordinate identifier; therefore, an elliptic curve point can be represented using 33 bytes. When using a P-384 elliptic curve, the x-coordinate can occupy 48 bytes, and with the addition of a 1-byte format identifier and a y-coordinate identifier, an elliptic curve point can be represented using 49 bytes.

[0110] It is worth noting that ECMH is only one specific implementation of the digest algorithm. Other algorithms that can generate a modified digest based on the baseline digest and the data involved in this modification can also be used in the embodiments of this application.

[0111] Therefore, when the DNS server 120 has already saved the verified zone data and corresponding digest, it can directly use the digest as the base digest, without having to regenerate the full digest before each incremental digest verification.

[0112] S302: DNS receives change information about the target digest and zone data from server 120.

[0113] In one possible implementation, the target summary and change information can be sent through different fields of the same message, or they can be sent separately through different messages or different transmission processes.

[0114] For example, in an implementation employing IXFR, the DNS master server 110 can send the newly added and deleted data related to the current zone data change via an IXFR response. The DNS master server 110 can also send a target digest via additional information in the IXFR response, options in the Extended DNS mechanism, a ZONEMD resource record, or a separate verification message. For instance, the DNS master server 110 can set the target digest in the additional information section of the IXFR response, and the DNS slave server 120 extracts the target digest from the additional information section after resolving the IXFR incremental data. Alternatively, the DNS master server 110 can define an option for carrying the target digest in the Extended DNS mechanism and send the option via an optional resource record in the DNS message; the DNS slave server 120 obtains the target digest by resolving the optional resource record.

[0115] In another example, DNS master server 110 can also carry the target digest via the ZONEMD resource record. When the zone data changes and a new target digest is generated, DNS master server 110 can modify the ZONEMD resource record accordingly and send the modified ZONEMD resource record as part of the IXFR incremental data. DNS slave server 120 can extract the digest field from the received ZONEMD resource record to obtain the target digest.

[0116] It should be noted that the above transmission methods are only used to illustrate different ways of carrying target digests and change information, and do not limit them to being sent using the same message or specific fields. As long as the DNS can obtain the target digest and change information for the same zone data change from server 120, subsequent incremental digest generation and digest verification can be performed.

[0117] DNS server 120 can also determine whether the current change is consistent with the locally stored zone data state based on the version information carried in the change information. For example, the change information can carry the zone data sequence numbers before and after the change. This version determination can be used to detect missing incremental data or version jumps, but it does not limit the change information to use a specific version field.

[0118] S303: DNS server 120 determines the changed data based on the change information.

[0119] The changed data can be the data that needs to participate in the incremental summary calculation during this district data change process, and can include at least one of the newly added data to the district data and the deleted data deleted from the district data.

[0120] When the change information indicates an add operation, the DNS slave server 120 can identify the data added to the zone data as new data. When the change information indicates a delete operation, the DNS slave server 120 can identify the data deleted from the zone data as deleted data. When the change information indicates a modify operation, the DNS slave server 120 can convert the modification process into deleting the data before the modification and adding the modified data. For example, the original address resource record in the zone data was "www.example.com A 192.0.2.10", and the address resource record after this change is "www.example.com A192.0.2.100".

[0121] DNS slave server 120 can identify the original resource record containing address 192.0.2.10 as deleted data, and DNS slave server 120 can also identify the new resource record containing address 192.0.2.100 as added data. Therefore, the three types of changes—adding, deleting, and modifying—can be uniformly converted into the processing procedures for adding and deleting data.

[0122] S304: DNS server 120 normalizes and maps the changed data to obtain the mapping result.

[0123] Normalization can be used to represent changed data according to uniform rules, reducing the possibility of semantically identical data obtaining different mapping results due to different representation forms. DNS master server 110 and DNS slave server 120 can use the same normalization rules to ensure that the same changed data forms the same normalized data in DNS master server 110 and DNS slave server 120.

[0124] Normalization rules can be rules for handling domain name case sensitivity, domain name end-of-domain identifier processing, resource record field arrangement rules, character encoding rules, numeric field encoding rules, sorting rules for similar resource records, or other rules that can unify the data representation format. For example, the domain names WWW.EXAMPLE.COM and www.example.com can semantically point to the same owner name; normalization can convert them to a uniform case. As another example, multiple resource records in the same RRset may be stored in different order; normalization can first arrange the resource records according to a unified sorting rule, and then generate a normalized data sequence, thereby avoiding the influence of record order on the mapping result.

[0125] In one possible implementation, the normalized data can be represented using a uniform linear byte string format. For a single resource record, the owner name, resource record type, category, time to life, and resource data can be concatenated in a pre-defined order to form a mapping input. For an RRset, multiple records with the same owner name and resource record type can be sorted and combined according to a uniform rule to form the mapping input corresponding to that RRset.

[0126] Mapping can be used to convert normalized, varied data into data objects that can participate in summary operations. The mapping result can be fixed-length data, elements of a finite group, or elliptic curve points, etc., which can be used for summary data in the first-level operation.

[0127] In one possible implementation, the mapping process can employ a hash-to-curve (HashToCurve) method, mapping the normalized data to points in an elliptic curve finite group. The HashToCurve method can be the simplified Shallue-van de Woestijne-Ulas method, or it can employ a trial-and-error incremental method, the Elligator 2 method, the standardized HashToCurve method, or other methods capable of stably mapping the data to the target group. The standardized HashToCurve method can be the one specified in RFC 9380 to ensure the mapping process conforms to uniform standardized processing rules.

[0128] For example, the mapping process can employ mapping to a P-256 elliptic curve, with the mapping result being points on the P-256 curve, or a P-384 curve or other finite group structures. The data structure and security parameters used for the mapping result can be determined based on the digest length, security strength, and computational performance requirements. When generating ECMH digests using elliptic curve finite groups, the collision resistance of the ECMH digest can be reduced to the difficulty of solving the elliptic curve discrete logarithm problem (ECDLP). Using a P-256 curve provides approximately 128 bits of security strength; using a P-384 curve provides approximately 192 bits of security strength.

[0129] Furthermore, to differentiate mapping results across different protocols or application scenarios, a domain separation tag (DST) can be used as an additional input to HashToCurve. For example, a dedicated string corresponding to the DNS zone data digest scenario can be used as the DST, ensuring that the same data yields isolated mapping results in different application scenarios. In the specific implementation using P-256 curves and SHA-256 to generate mapping results, the DST can be set to "DNS-ZONE-ECMH-P256-SHA256". This string is used to separate the DNS zone data digest scenario from other HashToCurve application scenarios, reducing the possibility of the same input data sharing mapping results across different protocols or application scenarios.

[0130] It should be noted that the above mapping implementation examples are for illustrative purposes only and are not intended to limit the scope of protection of this application. Other mapping methods that can convert normalized data into data objects that can participate in first-level operations can also be used in the embodiments of this application.

[0131] S305: DNS server 120 generates an incremental digest based on the mapping results.

[0132] The incremental summary is used to characterize the changes that this change in the district data has brought to the overall summary of the district data, without having to repeat the characterization of other unchanged resource records in the district data. The mapping result may include a first sub-mapping result based on the newly added data and a second sub-mapping result based on the deleted data.

[0133] DNS server 120 can perform corresponding first-level operations on the first and second sub-mapping results to obtain incremental digests. The specific form of the first-level operation can be determined by the digest algorithm used.

[0134] When using a digest algorithm that satisfies the additive homomorphic property, DNS slave server 120 can perform addition on the first sub-mapping result corresponding to newly added data and subtraction on the second sub-mapping result corresponding to deleted data. The incremental digest can be calculated using the following formula: ; Where ΔH represents the incremental summary corresponding to this change. This indicates newly added data. This indicates that data has been deleted. This indicates the mapping result obtained after DNS server 120 performs normalization and mapping processing on the corresponding data.

[0135] When the change only includes newly added data, the incremental summary can be obtained by summing the mapping results corresponding to each newly added data. When the change only includes deleted data, the incremental summary can be obtained by reverse operation of the mapping results corresponding to each deleted data. When the change includes both newly added and deleted data, the mapping results corresponding to the newly added data can be summed first, and then the mapping results corresponding to the deleted data can be subtracted.

[0136] For modification operations, DNS server 120 can use the mapping result corresponding to the data before the modification as the deleted item and the mapping result corresponding to the data after the modification as the added item. For example, the old resource record... Modified to new resource record The corresponding incremental digest can be calculated using the following formula: ; When a change involves multiple RRsets, the DNS slave server 120 can calculate the mapping results corresponding to each changed RRset separately and then add or subtract them. Therefore, the amount of data processed in the incremental summary calculation depends primarily on the amount of data that has changed, rather than on the total number of resource records in the DNS zone.

[0137] S306: DNS server 120 performs a first-level operation on the base digest and incremental digest to generate a check digest.

[0138] Level 1 operations can be performed on the mathematical operands corresponding to the digest. For example, when the digest is stored or transmitted in the form of elliptic curve compressed points, the DNS slave server 120 can first decode the compressed points into elliptic curve points, perform point addition or point subtraction, and then compress and encode the operation result into a check digest.

[0139] In one possible implementation, the verification digest can be calculated using the following formula: ; in, Represents the verification summary. This represents the baseline summary corresponding to the data in the area before the change. This indicates the incremental summary corresponding to this change.

[0140] Based on the calculation relationship in step S305, the verification digest can also be calculated using the following formula: ; For example, the base digest currently stored by DNS slave server 120 corresponds to zone data version 100, and this change is used to change the zone data to version 101. DNS slave server 120 can add the mapping result corresponding to the newly added data to the base digest corresponding to version 100, and subtract the mapping result corresponding to the deleted data to obtain the check digest corresponding to version 101.

[0141] It should be noted that the first-level operation can also be any operation that can obtain the corresponding digest of the changed zone data based on the baseline digest and the incremental digest, and is not limited to elliptic curve point addition or subtraction. For example, in addition to ECMH, the digest algorithm can also use other hash functions that support incremental changes to the set and satisfy the additive homomorphic property. For example, it can use multi-set hashing based on Boneh-Lynn-Shacham (BLS) signatures, or post-quantum homomorphic hashing based on lattice cryptography. When using different digest algorithms, different values ​​can be configured in the scheme field of the ZONEMD resource record to indicate the corresponding digest generation rules and the data format of the digest field.

[0142] S307: The DNS server 120 compares the checksum with the target digest to determine if they match. If they match, proceed to step S308; if they do not match, proceed to step S309.

[0143] The comparison can be a byte sequence comparison, numerical comparison, finite group element comparison, or other comparison that can determine whether the two digests are equivalent. When the digest uses compressed encoding, the compressed encoding results can be compared; when other encoding forms are used, they can be converted to a unified form before comparison.

[0144] In one specific implementation using ZONEMD, the DNS slave server 120 can compare the generated checksum with the digest field in the received ZONEMD record. The DNS slave server 120 can also check whether the algorithm identifier, digest length, or security parameters used in the target digest match the local digest generation rules to avoid direct comparison of results obtained using different digest rules.

[0145] Since the DNS master server 110 and the DNS slave server 120 process the same change information and use the same normalization rules, mapping rules, and first-level operation rules, the checksum generated by the DNS slave server 120 should be consistent with the target digest sent by the DNS master server 110, provided that the base zone data status of both parties is consistent and the change information is complete.

[0146] When the checksum and target digest are inconsistent, it may indicate that the incrementally transmitted data is missing or incorrect, or that the zone data or base digest currently stored by the DNS slave server 120 is abnormal, or that the zone data state before the change used by the DNS master server 110 and the DNS slave server 120 is inconsistent, or that there are differences in the data processing rules between the two sides. The above situations are only used to illustrate the possible states corresponding to the digest inconsistency and do not limit the specific reasons for the inconsistency.

[0147] In further possible implementations, this embodiment may also include the following steps.

[0148] S308: DNS server 120 modifies the locally stored zone data based on the change information.

[0149] When the DNS slave server 120 determines that the checksum and target digest are consistent, it can write the new data to its local database when the change information indicates that new data has been added; it can remove the corresponding data from its local database when the change information indicates that data has been deleted; and it can delete the data before modification and write the modified data when the change information indicates that data has been modified. For example, when the address resource record changes from 192.0.2.10 to 192.0.2.100, the DNS slave server 120 can delete the original resource record containing 192.0.2.10 from its local database and write a new resource record containing 192.0.2.100.

[0150] Change information can indicate a change to a single resource record at a time, or it can indicate a batch change to multiple resource records or multiple RRsets. For batch changes, DNS server 120 can execute the operations in the order specified in the change information, or it can apply all the changes as a whole to the local data after confirming that each change has passed digest verification.

[0151] After completing the local data change, DNS slave server 120 can save the checksum or the verified target digest as a new local digest and use it as the base digest for the next incremental digest verification. Since the checksum and target digest have been determined to be consistent, both can characterize the zone data state of DNS slave server 120 after this change. For example, the base digest before the change is H_local_old, and the checksum generated by DNS slave server 120 this time is H_local_new. After successful verification and completion of the zone data change, DNS slave server 120 can save H_local_new, so that the next zone data change can continue to be calculated based on H_local_new.

[0152] Therefore, by verifying whether to change the local data, DNS slave server 120 can reduce the possibility of incomplete, erroneous, or inconsistent changed data from DNS master server 110 entering the valid zone data of DNS slave server 120.

[0153] S309: DNS requests a full rebuild from server 120.

[0154] DNS slave server 120 can send a full data transmission request to DNS master server 110, requesting to obtain all resource records and corresponding summaries in the current DNS zone.

[0155] In one possible implementation, the DNS slave server can also trigger a verification failure alarm when sending a full data transfer request. The alarm information may include at least one of the following: the SOA sequence number corresponding to the zone data before the change, the SOA sequence number corresponding to the zone data after the change, the target digest, the checksum, the incremental digest, and the time of the anomaly. Recording alarm information provides a data basis for locating missing incremental data, incorrect incremental data, abnormal baseline digests, or inconsistencies in the data states of the master and slave server zones.

[0156] After receiving the full data and the corresponding target digest from server 120, DNS can re-perform normalization, mapping, and digest generation on the full data to obtain a new local digest. This new local digest is then compared with the target digest. If they match, the received full data can be saved, and the new local digest can be used as the new base digest.

[0157] In one possible implementation, in addition to performing a full AXFR verification when the initial state is established or when the digest verification is inconsistent, the DNS slave server 120 can also re-perform a full verification during subsequent periodic AXFR processes. The DNS slave server 120 can recalculate the ECMH full digest based on the currently received full zone data and compare the recalculated ECMH full digest with the digest in the ZONEMD record to detect data anomalies generated outside the incremental change process. If they match, the DNS slave server 120 can continue to use the current zone data; if they do not match, the DNS slave server 120 can refuse to load the current full zone data and re-establish a trusted baseline digest.

[0158] pass Figure 3The method shown allows DNS slave server 120 to generate a verification digest representing the changed zone data based on the locally stored baseline digest and the current change information, and to complete consistency verification using the target digest sent by DNS master server 110. In the incremental verification path, DNS slave server 120 only needs to perform normalization, mapping, and digest operations on the newly added, deleted, or modified data, without needing to reprocess all resource records in the zone data. Therefore, the digest calculation workload is mainly related to the amount of data that has changed, which can reduce the digest verification overhead in scenarios with frequent changes to large-scale zone data.

[0159] Meanwhile, DNS slave server 120 can modify its local zone data only after the verification digest matches the target digest. DNS slave server 120 can request a full reconstruction when the two are inconsistent, which can avoid the continued accumulation of subsequent changes on the unverified zone data state and enable DNS slave server 120 to re-establish a zone data state consistent with DNS master server 110.

[0160] Understandable Figure 3 The DNS server digest verification method shown is merely an example of a method provided in this application embodiment. In other possible implementations, where the corresponding digest verification can be completed, some steps can be combined, split, or the execution order can be adjusted. Steps S301, S308, and S309 are optional steps.

[0161] The following is combined Figure 4 The target digest generation process performed on DNS master server 110 is described in further detail. See [link to documentation]. Figure 4 The diagram illustrates a flowchart of a DNS master server summary generation method.

[0162] Figure 4 The method shown can be derived from Figure 1 The DNS master server 110 can be used to execute the command, or it can be executed by a data processing device that is connected to the DNS master server 110. Figure 4 Step S401 can be used to establish initial zone data and corresponding initial digest; steps S402 to S407 can be used to generate target digest based on the change information of zone data; step S408 can be used to provide the DNS slave server 120 with the digest and change information required for digest verification; and step S409 can be used to respond to the full data transmission request initiated by the DNS slave server 120.

[0163] S401: DNS master server 110 generates an initial digest based on the initial zone data and sends the initial zone data and initial digest. The base digest is the initial digest.

[0164] The initial zone data can be all resource records contained in the DNS zone when it is in its initial version. The initial version can be the version corresponding to the initial establishment of the DNS zone, or the version selected when the DNS slave server 120 first synchronizes zone data or re-establishes zone data. The DNS master server 110 can first divide the initial zone data into multiple data elements, which can be a single resource record or an RRset. The DNS master server 110 can normalize each data element separately, then map the normalized data elements into mapping results that can participate in the first-level operation, and finally perform the first-level operation on all mapping results to obtain the initial digest.

[0165] In one possible implementation, when the data elements of the DNS master server 110 are RRsets, the DNS master server 110 can traverse each RRset in the initial zone data, normalize and map each RRset, and perform a first-level operation on the mapping results to generate an initial digest. When using ECMH, the initial digest can be calculated using the following formula: ; in, Indicates the initial summary. to This represents each data element in the initial data region. This indicates that DNS primary server 110 is paired with... The mapping result is obtained after normalization and mapping processing. When the summary needs to be stored or transmitted, the calculation result can also be compressed and encoded.

[0166] DNS master server 110 can send the initial zone data and initial digest to DNS slave server 120. The initial zone data and initial digest can be sent during the same full data transfer, or they can be sent separately via different messages or transmission messages. For example, in an AXFR implementation, the initial zone data and the corresponding ZONEMD record can be sent together to DNS slave server 120.

[0167] DNS master server 110 can also save the initial digest and use it as the base digest for the current zone data. When the zone data changes subsequently, DNS master server 110 can directly use the base digest to generate the changed target digest without having to regenerate a digest for all resource records in the initial zone data.

[0168] S402: DNS primary server 110 obtains change information on zone data.

[0169] Change information can come from data generated when DNS master server 110 performs zone data changes, or from zone data management devices, dynamic change interfaces, zone file processing modules, operation logs, incremental logs, or other data sources that can characterize zone data changes.

[0170] For example, after receiving a configuration instruction to add a domain name record, the zone data management device can provide the DNS master server 110 with the addition instruction and the resource record to be added; when the DNS master server 110 deletes an invalid resource record, it can identify the deletion instruction and the deleted resource record as change information; when the zone file is replaced by another version, the DNS master server 110 can also obtain the change information by comparing the two versions of zone data.

[0171] Change information can include a single resource record change, or a batch change of multiple resource records or multiple RRsets. For batch changes, the DNS master server 110 can retrieve all change information at once, or retrieve each change information sequentially and merge multiple changes within the same version change process.

[0172] In one specific implementation, the change information may further include the region data identifiers before and after the change, such as the sequence number before and after the change in the SOA resource record. The sequence numbers before and after the change can be used to identify the starting and target versions of this change, but the change information is not limited to using SOA sequence numbers to identify versions.

[0173] S403: DNS primary server 110 determines the changed data based on the change information.

[0174] The changed data may include at least one of the data added to the zone data and the data deleted from the zone data. The DNS master server 110 can generate new data sets and deleted data sets respectively based on the change type and specific data in the change information.

[0175] When the change information indicates an add operation, the DNS master server 110 can determine the data to be added as add data; when the change information indicates a delete operation, the DNS master server 110 can determine the data to be deleted as delete data; when the change information indicates a modify operation, the DNS master server 110 can determine the data before modification as delete data and the data after modification as add data.

[0176] For example, address resource records in the area data: Before the change: "www.example.com A 192.0.2.10"; After the change: "www.example.com A 192.0.2.100"; DNS master server 110 can identify the original resource record at address 192.0.2.10 as deleted data and the new resource record at address 192.0.2.100 as added data. Therefore, modification processing can be converted into deletion and addition processing, allowing all three types of changes (addition, deletion, and modification) to use a unified incremental digest generation process.

[0177] For example, when using RRsets as the data elements to be processed, if a resource record in the same RRset changes, the entire RRset before the change can be identified as deleted data, and the entire RRset after the change can be identified as newly added data. For instance, when a certain A record set changes from {address 1, address 2} to {address 1, address 3}, the A record set before the change can be identified as deleted data, and the A record set after the change can be identified as newly added data.

[0178] S404: DNS primary server 110 performs normalization processing on changed data.

[0179] DNS master server 110 can process changed data according to the same normalization rules as DNS slave server 120, ensuring that the same changed data yields consistent normalization results on both the master and slave servers. The normalization rules can employ... Figure 3 The normalization rules in the corresponding embodiments will not be repeated here.

[0180] For a change involving multiple data changes, the DNS master server 110 can normalize each data change separately, or it can first group the data according to the added and deleted data, and then perform normalization on the data changes in each group separately.

[0181] In one specific implementation, the DNS master server 110 can convert the normalized change data into a uniform line-formatted byte string. When using RRsets as the data elements for mapping, resource records in the same RRset can be sorted according to a uniform rule and combined into a single mapping input to reduce the impact of record order differences on subsequent mapping results. For example, two RRsets with identical content but different record order can form the same normalized data after being uniformly sorted, enabling the DNS master server 110 and the DNS slave server 120 to generate consistent mapping results for the same change.

[0182] S405: DNS primary server 110 maps the normalized changed data.

[0183] DNS master server 110 can use the same mapping rules as DNS slave server 120 to convert normalized changed data into mapping results that can participate in first-level calculations. Specific mapping rules can be adopted... Figure 3 The mapping rules in the corresponding embodiments will not be repeated here.

[0184] In one specific implementation using ECMH, the DNS master server 110 can map normalized changing data to elliptic curve points using the HashToCurve method. HashToCurve can employ the Simplified SWU method or other methods capable of mapping input data to a target finite group.

[0185] DNS master server 110 can also use the same DST, elliptic curve parameters, and data encoding methods as DNS slave server 120. For example, DNS master server 110 can use the P-256 curve to generate the corresponding mapping result, or DNS master server 110 can use the P-384 curve to generate the corresponding mapping result.

[0186] The mapping result can include a first sub-mapping result corresponding to the newly added data and a second sub-mapping result corresponding to the deleted data. If the change involves multiple newly added data or multiple deleted data, both the first and second sub-mapping results can include one or more data objects.

[0187] For example, regarding the modification of resource records for the aforementioned addresses, the DNS master server 110 can normalize and map the original resource records to obtain the mapping results corresponding to the deleted data. Similarly, the DNS master server 110 can normalize and map the new resource records to obtain the mapping results corresponding to the newly added data.

[0188] S406: DNS primary server 110 generates an incremental digest based on the mapping results.

[0189] DNS master server 110 can perform a first-level operation on the first sub-mapping result corresponding to the newly added data and the second sub-mapping result corresponding to the deleted data to obtain the incremental summary corresponding to the current zone data change.

[0190] When using a digest algorithm that satisfies the additive homomorphic property, the DNS master server 110 can perform addition operations on the mapping results corresponding to newly added data and subtraction operations on the mapping results corresponding to deleted data. The incremental digest can be calculated using the following formula: ; in, This indicates the incremental summary corresponding to this change. This indicates newly added data. This indicates that data has been deleted.

[0191] When this change only includes adding data, the DNS master server 110 can accumulate the mapping results corresponding to each added data to obtain an incremental digest; when this change only includes deleting data, the DNS master server 110 can perform a subtraction operation on the mapping results corresponding to each deleted data to obtain an incremental digest; when this change includes both adding and deleting data, the DNS master server 110 can accumulate the mapping results corresponding to the added data and subtract the mapping results corresponding to the deleted data.

[0192] For modification operations, the incremental digest can be calculated using the following formula: ; in, This represents the data before the modification. This indicates the modified data.

[0193] For example, when the address corresponding to www.example.com changes from 192.0.2.10 to 192.0.2.100, the DNS master server 110 can subtract the mapping result corresponding to the resource record of the original address from the incremental summary and add the mapping result corresponding to the resource record of the new address.

[0194] For a batch change involving multiple RRset changes, the DNS master server 110 can generate mapping results for each changed RRset separately, and add or subtract them according to the addition and deletion relationships. Therefore, the amount of data processed in the incremental summary generation process is mainly related to the amount of data in this change, without needing to process other unchanged resource records in the zone data.

[0195] Furthermore, in the implementation that uses RRset as the mapping granularity, δ represents the number of RRsets involved in this zone data change, and the computational overhead of the DNS master server 110 in generating the incremental summary can be expressed as O(δ).

[0196] S407: DNS primary server 110 generates a target digest based on the base digest and incremental digest.

[0197] The baseline summary can be a summary of the zone data before the change. The DNS master server 110 can read the baseline summary from the local summary storage area, zone data version records, incremental logs, or other storage structures. To ensure that the target summary can correctly represent the changed zone data, the zone data version corresponding to the baseline summary corresponds to the initial version of this change.

[0198] DNS master server 110 can perform first-level operations on the base digest and incremental digest to obtain the target digest. When using a digest algorithm that satisfies the additive homomorphic property, the target digest can be calculated using the following formula: ; in, This represents a summary of the target. This represents the baseline summary corresponding to the data in the area before the change. This indicates the incremental summary corresponding to this change.

[0199] Based on the calculation relationships in S406, the target summary can also be calculated using the following formula: ; For example, the baseline digest corresponds to the zone data represented by SOA sequence number 100. This change changes the zone data to the version corresponding to SOA sequence number 101. The DNS master server 110 can add the mapping result corresponding to the newly added data to the baseline digest corresponding to sequence number 100 and subtract the mapping result corresponding to the deleted data to obtain the target digest corresponding to sequence number 101.

[0200] The DNS master server 110 can save the generated target digest as a digest corresponding to the changed zone data, and can write the target digest into the ZONEMD record. When using ECMH, the DNS master server 110 can compress and encode the elliptic curve point operation results, and use the compressed and encoded results as the digest field in the ZONEMD record.

[0201] In one specific implementation, the DNS master server 110 can change the sequence number in the SOA resource record so that the target digest, change information, and changed zone data can correspond to the same zone data version. For example, serial_new can be set to serial_old plus 1, or the changed sequence number can be determined in other ways that conform to DNS version management rules.

[0202] After generating the target digest, the DNS master server 110 can save the target digest as a new base digest for use in the next zone data change. The replacement of the base digest can be processed as a single task along with zone data changes and version information changes to reduce the possibility of inconsistencies between the digest version and the zone data version.

[0203] S408: DNS master server 110 sends change information and target digest to DNS slave server 120.

[0204] In one possible implementation, the DNS master server 110 can send the change information and the target digest through the same transmission process, or they can be sent separately through different messages or packets. The change information can be transmitted as IXFR incremental data, while the target digest can be implemented according to a specific protocol, appended to an IXFR response, carried in an Extension Mechanisms for DNS (EDNS) option, set in a ZONEMD resource record, or sent through a separate verification message. Three possible implementation examples are provided below.

[0205] In the first specific implementation example, the DNS master server 110 can use the change information as IXFR incremental data and set the target digest in the additional field or additional data segment of the same IXFR response. After receiving the IXFR response from server 120, the DNS can obtain the data involved in this zone data change and the target digest corresponding to the changed zone data.

[0206] In the second specific implementation example, the DNS master server 110 can send change information via IXFR incremental data and carry the target digest via the EDNS option. The EDNS option may include information such as the digest algorithm identifier, digest length, and target digest, so that the DNS slave server 120 can perform digest comparison according to the corresponding digest generation rules.

[0207] In the third specific implementation example, the DNS master server 110 can send change information via IXFR incremental data and set the target digest in the modified ZONEMD resource record. The ZONEMD resource record can be sent along with the IXFR incremental operation, and the DNS slave server 120 can extract the target digest from the received ZONEMD resource record. Therefore, the DNS master server 110 can reuse the existing zone data incremental transmission mechanism without establishing a separate target digest transmission process. For DNS zones with DNS Security Extensions (SLE) signatures enabled, the DNS master server 110 can preferentially adopt the method of sending the ZONEMD resource record along with the IXFR incremental operation. Since ZONEMD participates in the transmission as an intra-zone resource record, this method facilitates the use of existing signature and verification processing for intra-zone resource records and eliminates the need to add a new target digest carrying structure for IXFR. The target digest can also be sent via a separate verification message to accommodate implementations where the target digest and zone data are transmitted separately.

[0208] In addition, the DNS master server 110 can also send the zone data identifiers before and after the change to the DNS slave server 120 along with the change information. For example, the DNS master server 110 can send serial_old and serial_new to the DNS slave server 120, respectively identifying the zone data version before and after the change, so that the DNS slave server 120 can determine whether the received change information is consistent with the zone data version stored locally, and determine the zone data version corresponding to the target digest.

[0209] It should be noted that regardless of the transmission method used, the DNS master server 110 can establish an association between the change information, the target digest, and the corresponding zone data version. The change information can be sent before the target digest, simultaneously with the target digest, or separately through different messages. As long as the DNS slave server 120 can obtain the corresponding change information and target digest before performing the digest comparison, it can generate a check digest based on the locally stored baseline digest and perform a consistency comparison between the check digest and the target digest.

[0210] S409: DNS primary server 110 receives a full data transmission request and sends the full data and target digest.

[0211] When the checksum generated by DNS slave server 120 is inconsistent with the target digest, DNS slave server 120 can send a full data transmission request. After receiving the full data transmission request, DNS master server 110 can determine the valid zone data version of the current DNS zone and obtain the full data and target digest corresponding to that version.

[0212] In one possible implementation, the full data transfer request can be an AXFR request. The DNS master server 110 can send all resource records of the current valid version to the DNS slave server 120 via AXFR, and also send the target digest corresponding to the current valid version.

[0213] The target digest sent can be the target digest generated and saved in step S407, or it can be a digest regenerated by the DNS master server 110 based on the current full data. When the DNS master server 110 regenerates the full digest, it can use the full digest to check whether the target digest saved locally is consistent with the current zone data.

[0214] After receiving the full data and target digest from server 120, DNS can regenerate a local digest and compare it with the target digest. If they match, DNS server 120 can save the full data and local digest to re-establish the baseline state used for incremental digest verification.

[0215] DNS master server 110 can also respond to full data transmission requests sent by multiple DNS slave servers 120. Each DNS slave server 120 can obtain the same full data and target digest, or it can obtain the corresponding version of zone data and digest based on its current version status.

[0216] pass Figure 4 The method shown allows the DNS master server 110 to determine changed data based on zone data change information. The DNS master server 110 can perform normalization, mapping, and digest operations on the newly added, deleted, or modified data to generate an incremental digest. The DNS master server can then generate a target digest based on the incremental digest and the baseline digest corresponding to the zone data before the change. Since generating the target digest does not require re-traversing all resource records in the zone data, the computational cost of the target digest is mainly related to the amount of data that has changed, thereby reducing the digest generation overhead in scenarios with frequent zone data changes.

[0217] Meanwhile, DNS master server 110 can send change information and target digest to DNS slave server 120, enabling DNS slave server 120 to independently generate a verification digest based on the local baseline digest and use the target digest to complete consistency verification; when incremental verification fails, DNS master server 110 can also send full data and target digest to support DNS slave server 120 in re-establishing a zone data state consistent with DNS master server 110.

[0218] The following is combined Figure 5 This describes the process of version tracing and anomaly location for DNS server 120 based on incremental digest records. See also... Figure 5 DNS server 120 can establish a trusted initial zone data version after the initial full verification is passed, and in each subsequent zone data change process, it will associate and save the incremental summary with the zone data version before and after the change, thus forming a continuous version relationship.

[0219] DNS slave server 120 can receive the initial full data and the corresponding ZONEMD digest via AXFR, and independently calculate the local digest based on the received full data. When the local digest matches the ZONEMD digest, DNS slave server 120 can determine that the initial full data has been verified and establish the initial zone data version V0.

[0220] The initial zone data version V0 may include the SOA sequence number serial0, zone data D0, and full digest H0. The SOA sequence number serial0 identifies the initial zone data version, zone data D0 represents the set of resource records included in this version, and the full digest H0 can be a digest from the ZONEMD record. DNS slave server 120 can use H0 as the initial base digest for subsequent incremental digest verification and version tracing.

[0221] When the data version V0 of a region undergoes its first change, this data change can be represented as ΔD1. ΔD1 can include newly added data, deleted data, or modified data. Modified data can be further divided into the data before deletion and the data after addition / modification.

[0222] DNS slave server 120 can calculate incremental digest ΔH1 based on the added and deleted data in ΔD1. For example, when using a digest algorithm that satisfies the additive homomorphic property, It can be calculated using the following formula: ; in, This indicates the newly added data in the first change. This indicates the data deleted during the first change. This represents the mapping result obtained after performing normalization and mapping on the corresponding data.

[0223] DNS server 120 can establish the first Journal (J) incremental summary record. and in The serial number before the change is saved in the middle. Serial number after change Incremental summary and timestamp The incremental summary record J1 can be represented as: ; also, You can also save the current addition, deletion, or modification operations for later use. Recalculate the incremental summary, or locate the specific resource record where the anomaly occurred.

[0224] DNS from server 120 can be based on the initial baseline digest. and incremental summary Full summary of data version V1 in the computation area , It can be calculated using the following formula: ; Zone data version V1 may include SOA serial number District data D1 and full summary DNS from server 120 can Compare with the target digest sent by DNS master server 110, in If the target digest matches, DNS server 120 can determine that zone data version V1 has been verified and will... Save as a baseline summary.

[0225] When zone data version V1 undergoes a second change, this zone data change can be represented as ΔD2. DNS server 120 can calculate the incremental digest corresponding to the second change in the same way. And establish a second Journal incremental abstract record. : ; ; The DNS server 120 can calculate the full digest corresponding to zone data version V2 using the following formula. :

[0226] Zone data version V2 may include SOA serial number District data D2 and full summary DNS is saved sequentially from server 120. and This allows for the formation of a region data version relationship from V0 to V1, and then from V1 to V2. In practical applications, the Journal can store more incremental summary records, thus forming a version chain that includes multiple region data versions.

[0227] DNS slave server 120 can also recover the digest corresponding to historical versions using incremental digest records in the Journal. For example, when it is necessary to trace back from zone data version V2 to zone data version V1, DNS slave server 120 can... Location Incremental Summary Record And based on the current full summary Perform the inverse operation on the incremental summary ΔH2:

[0228] When further tracing back to zone data version V0 is required, DNS can be used from server 120 based on... Location Incremental Summary Record And continue to calculate using the following formula. :

[0229] Therefore, DNS server 120 can recover the summaries corresponding to different historical versions step by step along the version chain. Historical summary recovery can be used to determine which version the anomaly started from, and also to check whether the currently saved summary is consistent with the historical incremental change relationship.

[0230] For example, the SOA sequence numbers for the zone data versions are 100, 101, and 102. When the zone data corresponding to sequence number 100 changes to the zone data corresponding to sequence number 101, DNS slave server 120 can generate and save the record (100, 101, ΔH1, t1); when the zone data corresponding to sequence number 101 further changes to the zone data corresponding to sequence number 102, DNS slave server 120 can generate and save the record (101, 102, ΔH2, t2). If it is necessary to trace back from sequence number 102 to sequence number 100, DNS slave server 120 can subtract ΔH2 and ΔH1 sequentially to obtain the corresponding historical summary.

[0231] Journal incremental summary records can also be used to check the integrity of the Journal itself. When the checksum corresponding to a certain zone data version is inconsistent with the target summary, the DNS slave server 120 can recalculate the incremental summary corresponding to that zone data version based on the addition, deletion, or modification operations stored in the Journal. For example, the DNS slave server 120 can recalculate ΔH1′ based on the change operations recorded in J1, and then compare ΔH1′ with ΔH1 stored in J1.

[0232] When ΔH1′ is inconsistent with ΔH1, the DNS slave server 120 can determine that the Journal records corresponding to sequence numbers serial0 to serial1 are abnormal. This abnormality may include missing change operations in the Journal, modified change content, or corrupted stored incremental digests. The DNS slave server 120 can identify serial0 to serial1 as the abnormal version range to be checked, thereby narrowing down the scope of anomaly investigation.

[0233] When ΔH1′ matches ΔH1, the DNS server 120 can determine that the Journal incremental summary record is consistent in its internal calculation relationship and can continue to check the correspondence between other incremental summary records, base summary records, or zone data versions.

[0234] pass Figure 5As shown, DNS slave server 120 can associate and save the incremental digest corresponding to each zone data change with the SOA sequence number before and after the change, forming a continuous version chain. Based on this version chain, DNS slave server 120 can perform historical digest recovery, version relationship tracing, and journal integrity checks, and can locate the anomaly between adjacent zone data versions when an anomaly occurs in digest verification, without having to re-examine all historical zone data.

[0235] The above combination Figures 1 to 5 The digest verification method provided in the embodiments of this application will be introduced. Next, the structure of the DNS master server digest verification device, the DNS slave server digest verification device, and the computing device provided in the embodiments of this application will be described in conjunction with the accompanying drawings.

[0236] This application also provides a DNS slave server digest verification device. See also Figure 6 , Figure 6 This illustration shows a schematic diagram of a digest verification device applied to a DNS slave server according to an embodiment of this application. The DNS slave server digest verification device 600 can be applied to a DNS slave server or deployed in a computing device used for digest verification. The DNS slave server digest verification device 600 may include a receiving module 610, a generating module 620, and a determining module 630.

[0237] The receiving module 610 is used to receive change information of the target digest and the zone data. The target digest is the digest corresponding to the changed zone data. The zone data includes all resource records in the DNS zone. The change information includes change instruction information or change data. The change instruction information is used to indicate the addition, deletion or modification of the zone data during the change process. The change data is the data added to the zone data, the data deleted from the zone data or the data modified in the zone data during the change process.

[0238] The generation module 620 is used to generate a verification digest based on the change information and the baseline digest. The baseline digest is a digest generated from the zone data stored in the server by DNS. The verification digest is obtained by performing a first-level operation on the baseline digest and the incremental digest. The incremental digest is generated based on the data added, deleted, or modified in the zone data as indicated by the change information.

[0239] The determination module 630 is used to determine that the target digest has passed verification if the verification digest is consistent with the target digest.

[0240] In one possible implementation, the digest verification device further includes an update module for updating the zone data stored by the DNS from the server based on change information if the target digest passes verification.

[0241] In one possible implementation, the digest verification device further includes an acquisition module and a storage module. The acquisition module is used to acquire a first identifier and a second identifier. The first identifier is used to identify the area data before the change, and the second identifier is used to identify the area data after the change. The storage module is used to associate and store the incremental digest, the first identifier, and the second identifier to obtain an incremental digest record.

[0242] In one possible implementation, the receiving module 610 is further configured to receive initial zone data and an initial digest corresponding to the initial zone data, wherein the initial zone data includes all resource records initially in the DNS zone; the generating module 620 is further configured to generate a local digest based on the initial zone data; and the storage module is further configured to save the local digest in the DNS slave server when the local digest is consistent with the initial digest, wherein the base digest is the local digest.

[0243] In one possible implementation, the digest verification device further includes a sending module for sending a full data transmission request when the verification digest is inconsistent with the target digest. The full data transmission request is used to request the transmission of all resource records in the DNS zone.

[0244] In one possible implementation, the acquisition module is further configured to obtain a mapping result based on the change information, wherein the mapping result is obtained by mapping the data indicated by the change information after normalization; the generation module is further configured to generate an incremental summary based on the mapping result.

[0245] In one possible implementation, the acquisition module is used to determine the changed data based on the change information. The changed data is either data added to the area data or data deleted from the area data. In the case of data modification in the area data, the data before modification is the data deleted from the area data, and the data after modification is the data added to the area data. The module then performs normalization processing on the changed data and maps the normalized changed data to obtain a mapping result.

[0246] In one possible implementation, the mapping result includes a first sub-mapping result and a second sub-mapping result, the first sub-mapping result being obtained based on data added to the region; the acquisition module is used to perform a first-level operation on the first sub-mapping result and the second sub-mapping result to obtain an incremental summary.

[0247] The DNS slave server digest verification device 600 provided in this embodiment corresponds to the above-mentioned Figure 2 , Figure 3 and Figure 5 The DNS server digest verification method in the illustrated embodiment is described above. Therefore, the functions of each module and its technical effects in this embodiment can be found in the foregoing. Figure 2 , Figure 3 and Figure 5The relevant descriptions in the illustrated embodiments will not be repeated here.

[0248] Furthermore, embodiments of this application also provide a DNS master server digest verification device. See also Figure 7 , Figure 7 This illustration shows a schematic diagram of a digest verification device applied to a DNS master server according to an embodiment of this application. The DNS master server digest verification device 700 can be applied to a DNS master server or deployed in a computing device used for digest verification. The DNS master server digest verification device 700 may include an acquisition module 710, a generation module 720, and a sending module 730.

[0249] The acquisition module 710 is used to acquire change information of zone data in the DNS master server. Zone data includes all resource records in the DNS zone. Change information includes change indication information or change data. Change indication information is used to indicate the addition, deletion or modification of zone data during the process of changing zone data. Change data is data added to the zone data, data deleted from the zone data or data modified in the zone data during the process of changing zone data.

[0250] The generation module 720 is used to generate a target summary based on the change information and the base summary. The base summary is a summary generated based on the zone data stored in the DNS master server. The target summary is obtained by performing a first-level operation on the base summary and the incremental summary. The incremental summary is generated based on the data added, deleted, or modified in the zone data as indicated by the change information.

[0251] The sending module 730 is used to send change information and target digest, the change information being used to verify the target digest transmitted to the DNS slave server.

[0252] In one possible implementation, the generation module 720 is further configured to generate an initial digest corresponding to the initial zone data based on the initial zone data in the DNS master server, wherein the initial zone data includes the initial full set of resource records within the DNS zone.

[0253] The sending module 730 is also used to send initial area data and initial digest.

[0254] In one possible implementation, the digest verification apparatus further includes a receiving module for receiving a full data transmission request, the full data transmission request being used to request the transmission of all resource records within a DNS zone. The sending module 730 is also configured to send the full data and the target digest to the DNS slave server that sent the full data transmission request.

[0255] In one possible implementation, the generation module 720 is further configured to obtain a mapping result based on the change information, wherein the mapping result is obtained by mapping the data indicated by the change information after normalization; the generation module is further configured to generate an incremental summary based on the mapping result.

[0256] In one possible implementation, the generation module 720 is used to determine the changed data based on the change information. The changed data is either data added to the area data or data deleted from the area data. In the case of data modification in the area data, the data before modification is the data deleted from the area data, and the data after modification is the data added to the area data. The module then performs normalization processing on the changed data and maps the normalized changed data to obtain a mapping result.

[0257] In one possible implementation, the mapping result includes a first sub-mapping result and a second sub-mapping result. The first sub-mapping result is obtained based on the data added to the region. The generation module 720 is used to perform a first-level operation on the first sub-mapping result and the second sub-mapping result to obtain an incremental summary.

[0258] The DNS master server digest verification device 700 provided in this embodiment corresponds to the above-mentioned Figure 2 and Figure 4 The DNS master server digest verification method in the illustrated embodiment is described above. Therefore, the functions and technical effects of each module in this embodiment can be found in the foregoing. Figure 2 and Figure 4 The relevant descriptions in the illustrated embodiments will not be repeated here.

[0259] Figure 8 This is a schematic diagram of the hardware structure of a computing device provided in this application. Figure 8 As shown, the computing device 800 includes a processor 810, a memory 820, a communication interface 830, and a bus 840. The processor 810, memory 820, and communication interface 830 communicate via the bus 840. The bus 840 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The symbol is represented by only one thick line, but this does not indicate that there is only one bus or one type of bus. The communication interface 830 is used for external communication.

[0260] It should be understood that in the embodiments of this application, the processor 810 may be a CPU, or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete device assemblies, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0261] The memory 820 may include read-only memory and random access memory, and provides instructions and data to the processor 810. The memory 820 may also include non-volatile random access memory.

[0262] The memory 820 can be volatile memory or non-volatile memory, or both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0263] The memory 820 stores executable code, and the processor 810 executes the executable code to perform the aforementioned actions. Figure 2 The method performed by DNS master server 110 or DNS slave server 120 in the illustrated embodiment.

[0264] It should be understood that the computing device 800 in this application embodiment may correspond to the DNS master server 110 in this application embodiment, and may correspond to the execution of the implementation in this application embodiment. Figure 2 and Figure 4The method executed by the DNS master server 110 in the illustrated method; the computing device 800 can also correspond to the DNS slave server 120 in this embodiment, and can correspond to the execution of the method in this embodiment. Figure 2 , Figure 3 and Figure 5 The DNS method shown is executed by server 120. The above and other operations or functions implemented by computing device 800 can be achieved. Figure 2 and Figure 4 The method flow executed by the DNS master server 110 in the illustrated method; or, the above and other operations or functions implemented by the computing device 800 can also be implemented. Figure 2 , Figure 3 and Figure 5 The method flow executed by DNS server 120 shown is omitted here for the sake of brevity.

[0265] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct a computing device to perform the above-described digest verification method.

[0266] This application also provides a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computing device, all or part of the processes or functions described in this application are generated.

[0267] The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, or data center to another website, computer, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0268] The computer program product can be a software installation package. When it is necessary to use either the aforementioned DNS master server digest verification method or the DNS slave server digest verification method, the computer program product can be downloaded and executed on a computing device.

[0269] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0270] The terminology used in the above embodiments is for the purpose of describing specific embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to also include expressions such as “one or more,” unless the context clearly indicates otherwise. It should also be understood that in the embodiments of this application, “one or more” refers to one, two, or more; the character “ / ” generally indicates that the preceding and following objects are in an “or” relationship. In the embodiments of this application, “simultaneously” refers to the same time period, including situations where they are at the same moment.

[0271] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0272] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for validating abstracts, characterized in that, The method is applied to a Domain Name System (DNS) slave server and includes: Receive target digest and zone data change information, wherein the target digest is the digest corresponding to the changed zone data, the zone data includes all resource records in the DNS zone, and the change information includes change instruction information or change data. The change instruction information is used to indicate the addition, deletion or modification of the zone data during the change of the zone data, and the change data is data added to the zone data, data deleted from the zone data or data modified in the zone data during the change of the zone data. Based on the change information and the baseline digest, a verification digest is generated. The baseline digest is a digest generated based on the zone data stored in the DNS server. The verification digest is obtained by performing a first-level operation on the baseline digest and the incremental digest. The incremental digest is generated based on the data added, deleted, or modified in the zone data as indicated by the change information. If the verification digest matches the target digest, the target digest is determined to have passed verification.

2. The method according to claim 1, characterized in that, The method further includes: If the target digest passes verification, the zone data stored by the DNS server is updated according to the change information.

3. The method according to claim 1, characterized in that, The method further includes: Obtain a first identifier and a second identifier, wherein the first identifier is used to identify the area data before the change, and the second identifier is used to identify the area data after the change; The incremental digest, the first identifier, and the second identifier are associated and stored to obtain an incremental digest record.

4. The method according to claim 1, characterized in that, Before receiving change information for the target digest and area data, the method further includes: Receive initial zone data and the initial digest corresponding to the initial zone data, wherein the initial zone data includes the initial full set of resource records within the DNS zone; A local summary is generated based on the initial region data; If the local digest matches the initial digest, the local digest is stored in the DNS slave server, and the base digest is the local digest.

5. The method according to claim 1, characterized in that, The method further includes: If the verification digest does not match the target digest, a full data transmission request is sent, which is used to request the transmission of all resource records in the DNS zone.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Based on the change information, a mapping result is obtained, which is obtained by mapping the data indicated by the change information after normalization processing; The incremental summary is generated based on the mapping result.

7. The method according to claim 6, characterized in that, The mapping result obtained based on the change information includes: Based on the change information, the changed data is determined. The changed data is data added to the area data or data deleted from the area data. In the case where the data in the area data is modified, the data before the modification is the data deleted from the area data, and the data after the modification is the data added to the area data. The changed data is then normalized. The normalized changed data is mapped to obtain the mapping result.

8. The method according to claim 7, characterized in that, The mapping result includes a first sub-mapping result and a second sub-mapping result. The first sub-mapping result is obtained based on data added to the area data, and the second sub-mapping result is obtained based on data deleted from the area data. The step of generating the incremental summary based on the mapping result includes: The first sub-mapping result and the second sub-mapping result are subjected to a first-level operation to obtain the incremental summary.

9. A method for validating abstracts, characterized in that, The method is applied to a DNS master server and includes: Obtain change information of zone data in the DNS master server. The zone data includes all resource records in the DNS zone. The change information includes change indication information or change data. The change indication information is used to indicate the addition, deletion or modification of the zone data during the change process. The change data is data added to the zone data, data deleted from the zone data or data modified in the zone data during the change process. Based on the change information and the baseline digest, a target digest is generated. The baseline digest is a digest generated based on the zone data stored in the DNS master server. The target digest is obtained by performing a first-level operation on the baseline digest and the incremental digest. The incremental digest is generated based on the data added, deleted, or modified in the zone data as indicated by the change information. The change information and the target digest are sent, wherein the change information is used to verify the target digest transmitted to the DNS slave server.

10. The method according to claim 9, characterized in that, Before obtaining the change information of the zone data in the DNS master server, the process also includes: Based on the initial zone data in the DNS master server, an initial digest corresponding to the initial zone data is generated, wherein the initial zone data includes the initial full set of resource records within the DNS zone; Send the initial region data and the initial digest.

11. The method according to claim 9, characterized in that, The method further includes: Receive a full data transmission request, which is used to request the transmission of all resource records in the DNS zone; Send the full data and the target digest to the DNS slave server that sent the full data transmission request.

12. The method according to any one of claims 9 to 11, characterized in that, The method further includes: Based on the change information, a mapping result is obtained, which is obtained by mapping the data indicated by the change information after normalization processing; The incremental summary is generated based on the mapping result.

13. The method according to claim 12, characterized in that, The mapping result obtained based on the change information includes: Based on the change information, the changed data is determined. The changed data is data added to the area data or data deleted from the area data. In the case where the data in the area data is modified, the data before the modification is the data deleted from the area data, and the data after the modification is the data added to the area data. The changed data is then normalized. The normalized changed data is mapped to obtain the mapping result.

14. The method according to claim 13, characterized in that, The mapping result includes a first sub-mapping result and a second sub-mapping result. The first sub-mapping result is obtained based on data added to the area data, and the second sub-mapping result is obtained based on data deleted from the area data. The step of generating the incremental summary based on the mapping result includes: The first sub-mapping result and the second sub-mapping result are subjected to a first-level operation to obtain the incremental summary.

15. A digest verification device, characterized in that, The device is used on a DNS slave server and includes: The receiving module is used to receive change information of target digest and zone data. The target digest is the digest corresponding to the changed zone data. The zone data includes all resource records in the DNS zone. The change information includes change instruction information or change data. The change instruction information is used to indicate the addition, deletion or modification of the zone data during the change of the zone data. The change data is data added to the zone data, data deleted from the zone data or data modified in the zone data during the change of the zone data. The generation module is used to generate a verification digest based on the change information and the baseline digest. The baseline digest is a digest generated based on the zone data stored in the server by the DNS. The verification digest is obtained by performing a first-level operation on the baseline digest and the incremental digest. The incremental digest is generated based on the data added, deleted, or modified in the zone data as indicated by the change information. The determination module is used to determine that the target digest passes verification if the verification digest is consistent with the target digest.

16. A digest verification device, characterized in that, The device is used on a DNS master server and includes: The acquisition module is used to acquire change information of zone data in the DNS master server. The zone data includes all resource records in the DNS zone. The change information includes change indication information or change data. The change indication information is used to indicate the addition, deletion or modification of the zone data during the change of the zone data. The change data is data added to the zone data, data deleted from the zone data or data modified in the zone data during the change of the zone data. The generation module is used to generate a target summary based on the change information and the baseline summary. The baseline summary is a summary generated based on the zone data stored in the DNS master server. The target summary is obtained by performing a first-level operation on the baseline summary and the incremental summary. The incremental summary is generated based on the data added, deleted, or modified in the zone data as indicated by the change information. A sending module is used to send the change information and the target digest, wherein the change information is used to verify the target digest transmitted to the DNS slave server.

17. A computing device, characterized in that, Including the processor and memory; The memory is used to store computer programs; The processor is configured to perform the method according to any one of claims 1 to 14 according to the computer program.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program for performing the method according to any one of claims 1 to 14.

19. A computer program product comprising instructions, characterized in that, When it is run on a computing device, it causes the computing device to perform the method of any one of claims 1 to 14.

Images