Data processing method and system in domain name resolution system, and electronic device

Abstract

The disclosed embodiments disclose a data processing method, system, and electronic device in a domain name resolution system, relating to the field of domain name resolution technology. The method includes, in response to receiving a first query request sent by a recursive resolver, sending a second query request and a third query request in parallel to a root replica service module and a root server, respectively; receiving a first query result returned by the root replica service module in response to the second query request, and returning the first query result to the recursive resolver; receiving a second query result returned by the root server in response to the third query request; comparing the first query result and the second query result for consistency; and triggering data synchronization between the root replica service module and the root server in response to inconsistencies between the first query result and the second query result. The disclosed embodiments can monitor and calibrate root replica service data in real time.

Description

Technical Field

[0001] The present disclosure relates to domain name resolution technology, and in particular to a data processing method and system, and electronic equipment in a domain name resolution system. Background Art

[0002] The Domain Name System (DNS) is used to map domain names to IP addresses. One of its core functions is to resolve user-friendly domain names into computer-recognizable IP addresses. For example, it can resolve the domain name www.example.com into the IP address 192.168.xx, allowing users to access websites through domain names without having to remember complex IP addresses.

[0003] Root server: The root server is the top layer of the DNS architecture and is responsible for providing authoritative information for top-level domain names (TLDs). In order to reduce the round-trip time between the resolver and the root server and improve the resolution speed, root zone replica services can be deployed locally or regionally. These replica services can cache root zone data to speed up resolution. This can significantly reduce the round-trip time between the recursive resolver and the root server and speed up the query response. In related technologies, since the root replica service cannot synchronize data with the root server in real time, the data locally stored in the root replica service may lag behind the root server. The recursive resolver that relies on the local data of the root replica service may not be able to correctly resolve the domain name, and may even cause problems with the resolution service of the entire top-level domain area. Summary of the Invention

[0004] In order to solve the above technical problems, embodiments of the present disclosure provide a data processing method and system, and an electronic device in a domain name resolution system.

[0005] According to one aspect of an embodiment of the present disclosure, a data processing method in a domain name resolution system is provided, which is applied to a domain name system, wherein the domain name system includes a recursive resolver, a root server and a root replica node, and the root replica node is deployed with a root replica service module and a proxy module; the method is applied to the proxy module: in response to receiving a first query request sent by the recursive resolver, if the current working mode is the first mode, a second query request and a third query request are sent in parallel to the root replica service module and the root server respectively; wherein the first query request carries a first domain name to be queried; the second query request and the third query request are used to query the Internet Protocol address corresponding to the first domain name; a first query result returned by the root replica service module in response to the second query request is received, and the first query result is returned to the recursive resolver; a second query result returned by the root server in response to the third query request is received; the first query result and the second query result are compared to see whether they are consistent; in response to the first query result and the second query result being inconsistent, data synchronization between the root replica service module and the root server is triggered.

[0006] According to another aspect of an embodiment of the present disclosure, a domain name resolution system is provided, which includes a recursive resolver, a root server and a root replica node, and the root replica node is deployed with a root replica service module and a proxy module; the proxy module is used to: in response to receiving a first query request sent by the recursive resolver, if the current working mode is the first mode, send a second query request and a third query request in parallel to the root replica server and the root server respectively; the first query request carries a first domain name to be queried; the second query request and the third query request are used to query the Internet Protocol address corresponding to the first domain name; receive a first query result returned by the root replica server in response to the second query request, and return the first query result to the recursive resolver; receive a second query result returned by the root server in response to the second query request; compare whether the first query result and the second query result are consistent, and in response to the first query result and the second query result being inconsistent, trigger data synchronization between the root replica service module and the root server.

[0007] Based on the data processing method and domain name resolution system in the domain name resolution system provided by the above-mentioned embodiments of the present disclosure, after receiving the first query request sent by the recursive resolver, the same query request is sent in parallel to the root server and the root copy service module respectively, to implement a two-way query mechanism, and the first query result returned by the root copy service module is returned to the recursive resolver. After receiving the second query result returned by the root server, the two query results are compared, and the second query result returned by the root server is used as a reference to verify the accuracy of the query result returned by the root copy service module. If it is found that the query results returned by the two paths are inconsistent, it means that the data locally stored in the root copy service module needs to be updated. The data synchronization between the root copy service module and the root server can be immediately triggered to ensure the timely update of the local data of the root copy service module, thereby improving the reliability and credibility of the domain name resolution service provided by the root copy service module, and thus being able to correctly resolve the domain name.

[0008] The technical solution of the present disclosure is further described in detail below through the accompanying drawings and examples. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0010] The present disclosure can be more clearly understood from the following detailed description with reference to the accompanying drawings, in which:

[0011] Figure 1a A schematic diagram of the DNS system architecture corresponding to the data processing method proposed in an embodiment of the present disclosure;

[0012] Figure 1b A schematic diagram of a DNS system architecture in related art;

[0013] Figure 2 A flowchart of a data processing method according to an embodiment of the present disclosure;

[0014] Figure 3 A schematic diagram of a two-way query in the data processing method proposed in an embodiment of the present disclosure;

[0015] Figure 4 A flowchart of an optional embodiment of the data processing method proposed in the embodiment of the present disclosure;

[0016] Figure 5 A schematic diagram of a flow chart of data verification in an optional embodiment of the data processing method proposed in the embodiment of the present disclosure;

[0017] Figure 6 A schematic diagram of triggering incremental or full update in an optional embodiment of the data processing method proposed in the embodiment of the present disclosure;

[0018] Figure 7 A schematic diagram of a specific process of triggering incremental or full update in an optional embodiment of the data processing method proposed in the embodiment of the present disclosure;

[0019] Figure 8a A schematic diagram of a flow chart of using a prediction model to intelligently predict synchronization time in an optional embodiment of the data processing method proposed in the embodiment of the present disclosure;

[0020] Figure 8b A schematic diagram of a model architecture of a prediction model in an optional embodiment of the data processing method proposed in the embodiments of the present disclosure;

[0021] Figure 9 A flowchart of an adaptive failure processing mechanism in an optional embodiment of the data processing method proposed in the embodiment of the present disclosure;

[0022] Figure 10 A schematic diagram of switching to the international root mode in an optional embodiment of the data processing method proposed in the embodiment of the present disclosure;

[0023] Figure 11 A schematic diagram of the structure of an optional embodiment of the domain name resolution system proposed in the embodiments of the present disclosure;

[0024] Figure 12 A schematic diagram of the structure of another optional embodiment of the domain name resolution system proposed in the embodiment of the present disclosure;

[0025] Figure 13 This is a schematic diagram of the structure of an electronic device proposed in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0026] Below, the exemplary embodiments according to the present disclosure will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present disclosure, rather than all the embodiments of the present disclosure, and it should be understood that the present disclosure is not limited to the exemplary embodiments described herein.

[0027] It should be noted that the relative arrangement of components and steps, the numerical expressions and numerical values ​​set forth in these embodiments do not limit the scope of the present disclosure unless specifically stated otherwise.

[0028] Those skilled in the art will understand that the terms "first" and "second" in the embodiments of the present disclosure are only used to distinguish different steps, devices or modules, and do not represent any specific technical meanings, nor do they indicate a necessary logical order between them.

[0029] It should also be understood that in the embodiments of the present disclosure, “a plurality of” may refer to two or more than two, and “at least one” may refer to one, two, or more than two.

[0030] It should also be understood that any component, data or structure mentioned in the embodiments of the present disclosure can generally be understood as one or more, unless explicitly limited or otherwise indicated in the context.

[0031] In addition, the term "and / or" in this disclosure is merely a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this disclosure generally indicates that the related objects are in an "or" relationship. The data referred to in this disclosure can include unstructured data such as text, images, and videos, as well as structured data.

[0032] It should also be understood that the description of the various embodiments in this disclosure focuses on the differences between the various embodiments, and the same or similar aspects thereof can be referenced with each other. For the sake of brevity, they will not be described one by one.

[0033] At the same time, it should be understood that for the convenience of description, the sizes of the various parts shown in the drawings are not drawn according to the actual proportional relationship.

[0034] The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way intended to limit the present disclosure, its application, or uses.

[0035] Technologies, methods, and equipment known to ordinary technicians in the relevant art may not be discussed in detail, but where appropriate, the technologies, methods, and equipment should be considered part of the specification.

[0036] It should be noted that like reference numerals and letters refer to like items in the following figures, and therefore, once an item is defined in one figure, it need not be further discussed in subsequent figures.

[0037] The embodiments of the present disclosure can be applied to electronic devices such as terminal devices, computer systems, and servers, and can operate in conjunction with numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known terminal devices, computing systems, environments, and / or configurations suitable for use with electronic devices such as terminal devices, computer systems, and servers include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, network personal computers, minicomputer systems, mainframe computer systems, and distributed cloud computing technology environments including any of the above systems, among others.

[0038] Electronic devices such as terminal devices, computer systems, and servers can be described in the general context of computer system-executable instructions (such as program modules) executed by the computer system. Generally, program modules can include routines, programs, object programs, components, logic, data structures, and the like that perform specific tasks or implement specific abstract data types. Computer systems / servers can be implemented in distributed cloud computing environments, where tasks are performed by remote processing devices linked via a communications network. In distributed cloud computing environments, program modules can be located on local or remote computer system storage media, including storage devices.

[0039] Domain name resolution is the process of converting user-friendly domain names into computer-readable Internet Protocol addresses (IP addresses). This translates user-friendly domain names into IP addresses, making internet resources accessible. Domain name resolution is a critical link and the foundation of internet communications, allowing users to access websites by domain name without having to remember complex IP addresses.

[0040] In the DNS system, a node's domain name is composed of the concatenated labels of all nodes from that node to the root, separated by dots. The domain name of the top-level node is called the top-level domain (TLD), the domain name of the second-level node is called the second-level domain, and so on. The root server is the top layer of the DNS architecture, responsible for providing authoritative information for top-level domains and storing authoritative name server information for all TLDs. As the top layer of the Internet's domain name resolution system, the root server is responsible for initial queries and guidance, translating domain names into IP addresses.

[0041] RFC8806 proposes that root zone replica services (hereinafter referred to as root replica services) can be deployed locally or regionally, and explains the specific methods of deploying root zone replica services. Root replica services, that is, in order to reduce the round-trip time between the resolver and the root server and improve the resolution speed, root replica services can be deployed locally or regionally. These replica services can cache root zone data. For query requests from recursive resolvers, they can quickly respond based on the locally cached root zone data, without having to access the international root server, thereby reducing the round-trip time between the resolver and the root server, improving the resolution speed and response speed, and especially providing faster negative responses. However, this approach also increases the unreliability of domain name resolution. For example, one of the main factors leading to unreliability is data synchronization issues:

[0042] In root domain name resolution systems, data synchronization on root replica servers primarily relies on the expiration mechanism in the Start of Authority (SOA) record. SOA records identify the authoritative starting point for a zone and contain global parameters required for zone management. SOA records typically include a key field: the expiration time. This field specifies how long the root replica server will maintain the record if no updates are received.

[0043] Generally, the expiration time is set to a few days. When the root replica service receives a query request from the recursive resolver, it will decide whether it needs to synchronize data from the international root server based on the expiration time in the SOA record. This update mechanism may cause the local data stored in the root replica server to lag behind the authoritative data in the root server for a period of time. There is a problem that the zone data stored in the root replica service (that is, the regional zone file data) cannot be synchronized with the root server in real time. That is, at least part of the data stored locally in the root replica service is expired and invalid data. Then, the recursive resolver that relies on the local data of the root replica service will not be able to correctly resolve the domain name, which may sometimes cause problems with the resolution service of the entire top-level domain name area.

[0044] In addition, there is also the possibility that data synchronization fails or data update fails, but the synchronization failure is not detected in time for a period of time, thereby affecting the accuracy and reliability of domain name resolution.

[0045] Furthermore, when data synchronization issues are discovered with the root replica server, one solution used by related technologies is to manually retrieve the correct data. This manual process is not only tedious but also prone to errors, increasing the complexity and pressure of operations and maintenance.

[0046] In light of this, embodiments of the present disclosure propose a data processing method in a domain name resolution system that can address at least one of the aforementioned technical issues. This method utilizes a dual-path query and data verification mechanism to automatically trigger data synchronization if verification fails, monitoring and calibrating root replica service data in real time. After multiple data synchronization failures, it automatically switches back to international root mode, reducing operational and maintenance pressure, improving replica data synchronization efficiency, and increasing root zone replica data reliability.

[0047] This method can be applied to various scenarios where root replica servers are deployed, such as enterprise internal networks, operator networks, education and scientific research networks, and other application scenarios.

[0048] For example, the method can be based on Figure 1a The system architecture shown is implemented.

[0049] In order to facilitate understanding of the improvements made to the DNS system architecture proposed in the embodiments of the present disclosure, the DNS system architecture of related technologies is listed for comparison. An example of a DNS system architecture in related technologies is as follows: Figure 1b As shown, in a recursive query mode, a DNS system architecture based on RFC8806 is deployed with root replica nodes. Local root replica servers are deployed at the root replica nodes for the recursive resolvers. The root replica servers are connected to both the recursive resolvers and the root servers. The recursive resolver receives a domain name resolution request from a terminal, such as a personal computer (PC) or other terminal, and sends a query request to the root replica server based on the domain name resolution request. The root replica server responds to the query request and returns the query result to the recursive resolver based on its local root zone data. The root replica server synchronizes data with the root server at regular intervals based on the SOA record.

[0050] like Figure 1a As shown, the DNS system architecture proposed in the embodiment of the present disclosure deploys a recursive resolver and a root server (international root server), deploys a root replica service module on the root replica node, and also sets up and deploys a lightweight proxy layer before the root replica service. The proxy layer communicates with the recursive resolver, the root replica service module and the root server respectively. When receiving a query request from the recursive resolver, the proxy layer sends the same query request to the root replica service module and the root server at the same time.

[0051] Specifically, a recursive resolver receives a domain name resolution request from a PC or other terminal and, based on the domain name resolution request, sends a query request to a root replica node. A proxy layer deployed on the root replica node receives the query request from the recursive resolver on behalf of the root replica service module. In response to the query request, the proxy layer simultaneously sends the same query request to both the local root replica service module and the root server. Generally, the root replica service module can respond based on local root zone data, resulting in a faster response. The proxy layer first obtains the response result (i.e., the query result) returned by the root replica service module. In some embodiments, the proxy layer returns the query result returned by the root replica service to the recursive resolver. Subsequently, the proxy layer receives another query result returned by the root server. By comparing the two query results for consistency, the proxy layer determines whether data synchronization between the root replica service module and the root server needs to be triggered. If they are inconsistent, this indicates that the local data stored in the root replica service module is unreliable and requires data synchronization to update the local data.

[0052] It should be noted that the proxy layer and the root copy service module can be deployed in the same electronic device, or in two independent electronic devices. For example, in a typical implementation, the proxy layer can be deployed in a first electronic device, and the root copy service module can be deployed in a second electronic device. The first electronic device and the second electronic device are two different electronic devices deployed in the root copy node. For example, the first electronic device can be a server for providing services corresponding to the method proposed in the embodiment of the present disclosure to the outside world, and the second electronic device can be a root copy server for providing root copy services. In another typical implementation, the proxy layer and the root copy service module can be deployed in the same electronic device. For example, the proxy layer can be integrated into the root copy server as an independent software module; or the root copy service module can be integrated into the proxy server as an independent software module.

[0053] It should be noted that in the following description, the root replica service module can refer to a software module or an electronic device deployed with the root replica service, for example, a root replica server providing the root replica service. The proxy layer can refer to a layer in the software architecture or an electronic device deployed with the proxy layer, for example, a server deployed with the proxy layer.

[0054] The data processing method proposed in the present disclosure is exemplarily described below with reference to the DNS system framework shown in FIG1 by listing some embodiments.

[0055] like Figure 2 As shown, the data processing method in the domain name resolution system proposed in the embodiment of the present disclosure may include the following process:

[0056] S201: In response to receiving a first query request sent by a recursive resolver, if the current working mode is the first mode, sending a second query request and a third query request in parallel to the root replica service module and the root server respectively.

[0057] The first query request carries the first domain name to be queried, and the second and third query requests are used to query the IP address corresponding to the first domain name carried in the first query request. The second and third query requests are identical, and the identity is at least reflected in that the second and third query requests resolve the IP address corresponding to the same domain name. For example, if the first domain name to be queried is www.example.com, the second query request is used to request the root server to resolve the IP address corresponding to the first domain name www.example.com; the third query request is used to request the root replica service module to resolve the IP address corresponding to the first domain name www.example.com.

[0058] S202: Receive a first query result returned by the root replica service module in response to the second query request, and return the first query result to the recursive resolver.

[0059] The query result generally includes multiple types of resource records, one of which includes the resolved IP address information. For example, the first query result returned by the root replica service module includes the resolved IP address 192.168.xx, and the first query result is returned to the recursive resolver.

[0060] The purpose of deploying the root replica service module on the root replica node is to improve the response speed. The root replica service module will return query results faster than the root server. Therefore, to ensure a fast response, the query results returned by the root replica service module can be returned to the recursive resolver first.

[0061] It should be noted that, in other embodiments, the first query result may not be returned to the recursive resolver. Instead, the correct query result may be returned to the recursive resolver after data verification is performed on the first query result and the second query result.

[0062] S203: Receive a second query result returned by the root server in response to the third query request.

[0063] The second query result includes multiple types of resource records, one of which may include resolved IP address information. For example, in the received second query result, the resolved IP address of the root server is 192.168.xy.

[0064] S204: Compare the first query result and the second query result to see if they are consistent. If they are not consistent, proceed to S205. If they are consistent, proceed to S206: end this data verification.

[0065] S205: In response to the inconsistency between the first query result and the second query result, trigger data synchronization between the root replica service module and the root server.

[0066] If the first query result is inconsistent with the second query result, the data verification fails. For example, the IP address resolved by the root server is 192.168.xy, and the IP address resolved by the root copy service module is 192.168.xx. Then the corresponding query result cannot pass the comparison verification, and the data verification result is inconsistent, indicating that the local data of the root copy service module needs to be updated, and data synchronization between the two needs to be triggered.

[0067] The disclosed embodiment adopts the above-mentioned two-way query mechanism, sending query requests in parallel to the root server and the root replica service module respectively, returning the query results returned by the root replica service module to the recursive resolver, and comparing them with the query results of the international root server to verify the accuracy of the root replica service module data. Once data inconsistency is found, data synchronization is immediately triggered to ensure timely updating of local data, thereby improving the reliability and credibility of the domain name resolution service provided by the root replica service module.

[0068] In an optional embodiment, if Figure 3 and Figure 4 As shown, the data processing method in the domain name resolution system proposed in the present disclosure may specifically include the following process:

[0069] S400: Receive a first query request (Query 1, hereinafter referred to as Q1) sent by a recursive resolver.

[0070] The recursive resolver receives a domain name resolution request (Query0, hereinafter referred to as Q0) from a terminal device such as a PC, generates a first query request Q1 based on the domain name resolution request Q0, and sends the first query request Q1 to the electronic device of the root replica node. The proxy layer receives the first query request Q1 instead of the root replica server.

[0071] It should be noted that S400-S409 and S201-S202 can all be executed by the first electronic device deployed with the proxy layer. For the sake of brevity, each step will not be described in detail. Some of the steps can also be performed by other electronic devices to assist the first electronic device, which is not limited in this disclosure.

[0072] S401: When it is determined that the current working mode is the first mode, a second query request Q2 and a third query request Q3 are sent in parallel to the root replica service module and the root server respectively.

[0073] In some embodiments, the proxy layer can configure the operating mode of the root replica node, employing different strategies in different operating modes. The first mode, also referred to as the root replica service mode, is a designated mode in which the two-way query and data verification strategies are employed. In other modes, the two-way query and data verification strategies are not employed.

[0074] In some embodiments, the working mode of the root copy node may include at least a first mode and a second mode, and support switching between the first mode and the second mode. Among them, the first mode can be simply referred to as the root copy service mode. In fact, the first mode is a dual service mode of the root copy service and the root server. The second mode is the international root mode. The international root mode is that the proxy layer directly sends a query request to the international root server and directly receives the query result returned by the international root server. If the data verification fails in the first mode, it will trigger data synchronization between the root copy service module and the root server. If the synchronization fails multiple times and the failure index calculated based on the failure statistics meets the preset conditions, the working mode will be switched from the first mode to the second mode. In the second mode, if the data synchronization is monitored to be successful, the second mode can be switched back to the first mode.

[0075] In other embodiments, other working modes may also be included, for example, a third mode may be included, in which the query request may be sent only to the local root copy service module, rather than sending query requests to the root server and the local root copy service module in parallel. In the second mode, if the data synchronization is monitored to be successful, the second mode may be switched to the third mode first, and then the third mode may be switched to the first mode. The design of the third mode is that in a short period of time after data synchronization, the need to immediately trigger data synchronization again is low. At this time, it is highly likely that the local data stored in the root copy service module is valid data that has just been successfully updated. During this time period, the root copy node can be controlled to work in the third mode to reduce unnecessary signaling interactions. The working time in the third mode can be set to a reasonable value based on statistics or actual application scenarios. For example, it can be set to 12 hours or 6 hours.

[0076] It should be noted that, in other embodiments, S401 may not execute the step of "determining that the current working mode is the first mode", but directly send the second query requests Q2 and Q3 in parallel to the root replica service module and the root server respectively.

[0077] When receiving the first query request Q1 from the recursive resolver, the proxy layer sends the same query request to its own root replica service module and the international root server at the same time. Figure 3 As shown, the proxy layer sends a second query request Q2 to the root server, and then sends a query request Q3 to the local root replica service module. The sending processes of Q2 and Q3 are executed in parallel. The third query request Q3 and the second query request Q2 are identical. It should be noted that the term "identical query request" refers to the same query content, not to the fact that the data information in the two query requests is completely identical. Clearly, the two query requests have the same source address but point to different destination addresses.

[0078] In addition, the proxy layer and the root replica service module have the same external address, that is, the proxy layer uses the same address as the root replica service module to communicate with the recursive resolver and the root server. This design can ensure that after the proxy layer is added, it can be compatible with the existing DNS system architecture, and the recursive resolver does not need to distinguish between the proxy layer and the root replica service module.

[0079] S402: Receive the first query result (answer3, A3 for short) returned by the root replica service module in response to the third query request Q3, and return the first query result A3 to the recursive resolver.

[0080] The first query result A3 returned by the root replica service module is first returned to the recursive resolver, which can ensure the response speed and does not affect the feedback speed while performing data verification.

[0081] S403: Receive the query result A2 returned by the root server in response to the second query request Q2.

[0082] The communication distance between the proxy layer and the root server is significantly greater than the communication distance between the proxy layer and the root replica service module, and the query result A2 returned by the root server will be received with delay.

[0083] S404: Compare the query result A2 with the first query result A3.

[0084] Comparing the query result A2 with the first query result A3 is a process of verifying the first query result A3 returned by the root replica service module using the query result A2 returned by the root server as a reference standard.

[0085] Comparing the second query result A2 with the first query result A3 can involve comparing all of the various resource records included in the query results. In the case of data synchronization, the contents of the multiple resource records in the query results returned by the root server and the root replica service module should be consistent (regardless of order). Comparing multiple resource records allows for more comprehensive data verification, thereby identifying potential data asynchrony issues.

[0086] Illustratively, in some embodiments of the present disclosure, a structured hash algorithm may be used to compare the second query result A2 with the first query result A3 to implement data verification.

[0087] A structured hash algorithm is used to accurately compare the response contents of the root server and the root replica service module (i.e., the second query result A2 and the first query result A3), which can include two parts: normalization processing and structured hashing. To facilitate understanding of the structured hash algorithm, a simple example of the data structure of the query results of the two is first given. The second query result A2 and the first query result A3 each include multiple types of resource records. Resource records (RR) are used to store the mapping relationship between domain names and network resources such as IP addresses and mail servers. Among them, each type of resource record in at least some of the multiple types includes at least two fields.

[0088] For example, the following are several common DNS resource records:

[0089] (1) A record (Address Record)

[0090] Purpose: Map domain names to IPv4 addresses.

[0091] Format: example.com. IN A 192.0.2.x.

[0092] Application example: If someone visits example.com, the DNS server will return the IPv4 address 192.0.2.x.

[0093] (2) AAAA record

[0094] Purpose: Map domain names to IPv6 addresses.

[0095] Format: example.com. IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:733x.

[0096] Application example: When accessing the IPv6-supported domain name example.com, the DNS server returns 2001:0db8:85a3:0000:0000:8a2e:0370:733x.

[0097] (3) CNAME record (Canonical Name Record)

[0098] Purpose: Map a domain name alias to another "canonical domain name".

[0099] Format: www.example.com. IN CNAME example.com.

[0100] Application example: www.example.com is an alias of example.com. When you visit www.example.com, you will be redirected to example.com.

[0101] (4) MX Record (Mail Exchange Record)

[0102] Purpose: Specify the mail server for mail routing.

[0103] Format: example.com. IN MX 10 mail.example.com.

[0104] Application example: When an email is sent to @example.com, it will be sent to mail.example.com.

[0105] (5) TXT record (Text Record)

[0106] Purpose: Stores arbitrary text information, which can be used to verify domain ownership, SPF records, DKIM signatures, etc.

[0107] Format: example.com. IN TXT "v=spf1 include:_spf.example.com ~all".

[0108] Application example: This record is often used for anti-spam verification (SPF).

[0109] (6) NS record (Name Server Record)

[0110] Purpose: Specify the authoritative DNS server for a domain name.

[0111] Format: example.com. IN NS ns1.example.com.

[0112] Application example: DNS resolution for example.com is handled by ns1.example.com.

[0113] (7) PTR record (Pointer Record)

[0114] Purpose: Maps IP addresses back to domain names, usually used for reverse DNS resolution.

[0115] Format: 1.2.0.192.in-addr.arpa. IN PTR example.com.

[0116] Application example: When querying the reverse DNS record of the IP address 192.0.2.1, example.com is returned.

[0117] (8) SRV record (Service Record)

[0118] Purpose: Defines the server and port of a specific service, commonly used in VoIP, XMPP, etc.

[0119] Format: _sip._tcp.example.com. IN SRV 10 60 5060 sipserver.example.com.

[0120] Application example: Specify the SIP service port as 5060.

[0121] (9) SOA record (Start of Authority Record)

[0122] Purpose: Stores authoritative information of DNS zones, including primary DNS server, administrator email address, serial number, etc.

[0123] Format: example.com. IN SOA ns1.example.com. admin.example.com.2023010101 3600 600 86400 3600.

[0124] Application example: SOA records help identify whether DNS zone information has been updated.

[0125] (10) CAA record (Certification Authority Authorization)

[0126] Purpose: Specify the certificate authority for the domain name and restrict which CAs can issue certificates for the domain name.

[0127] Format: example.com. IN CAA 0 issue "letsencrypt.org".

[0128] Application example: restrict certificates to be issued only by letsencrypt.org and prevent other CAs from issuing certificates for it.

[0129] As can be seen from the example of multiple resource records above, resource records come in various types, and some resource types contain multiple fields. For example, an SRV record includes three fields: "_sip._tcp.example.com.", "INSRV 10 60 5060," and "sipserver.example.com." The order of the fields in query results returned by different servers is not fixed or variable. This means that the order of multiple fields in the same type of resource record returned by different servers may be different. For example, the order of multiple fields in the same type of resource record returned by a root server and a root replica server may be inconsistent. This inconsistent order will result in inconsistent calculated hash values.

[0130] Therefore, normalization is necessary first. Normalization involves sorting the second query result A2 and the first query result A3 using the same sorting algorithm, ensuring that all variable order components are fixed after processing. This includes sorting multiple fields within resource records and sorting multiple types of resource records by type, resulting in a set of resource records with a relatively fixed order after normalization.

[0131] The sorting algorithm may be a lexicographic order sort, or other sorting algorithms such as bubble sort, insertion sort, or shell sort.

[0132] Structured hashing is to calculate the hash value for each type of resource record set separately, then sort and combine these hash values, and then calculate the final overall hash value.

[0133] Normalization processing and structured hash calculation can avoid inconsistent hash values ​​due to sequence issues.

[0134] In an optional embodiment, if Figure 5 As shown, for example, the process of using the structured hash algorithm to perform data verification can be as follows:

[0135] S4041: Sort the multiple fields included in the multiple types of resource records in the first query result and the second query result according to the same sorting algorithm to obtain first query data and second query data having the same first order.

[0136] The first order refers to the order between multiple fields within a resource record of the same type.

[0137] In other words, multiple fields within a resource record in the second query result A2 are sorted according to a first sorting algorithm, for example, lexicographic sorting, to obtain first query data. Multiple fields within a resource record in the first query result A3 are also sorted according to the first sorting algorithm to obtain second query data. The obtained first query data and second query data each include multiple types of resource records, wherein the relative order of the fields within resource records of the same type is consistent.

[0138] For example, an SRV record includes three fields: "_sip._tcp.example.com.", "IN SRV 10 605060," and "sipserver.example.com.". The SRV record obtained after sorting in lexicographical order is: "IN SRV 10605060_sip._tcp.example.com.sipserver.example.com."

[0139] S4042: Sort the resource records of various types in the first query data and the second query data by type using the same sorting algorithm to obtain third query data and fourth query data having the same second order.

[0140] The second order refers to the order between multiple types of resource records.

[0141] In other words, the multiple types of resource records in the second query result A2 are sorted according to their types using the second sorting algorithm to obtain third query data. The multiple types of resource records in the first query result A3 are also sorted using the second sorting algorithm to obtain fourth query data. The resulting third and fourth query data each include multiple types of resource records, and the relative order of the multiple types of resource records is consistent.

[0142] The second sorting algorithm and the first sorting algorithm may be the same sorting algorithm or different sorting algorithms.

[0143] For example, assuming that the second query result A2 or the first query result A3 each contains 10 types of resource records, the same sorting algorithm is used to sort the 10 types of resource records, and query data (i.e., the third query data and the fourth query data) corresponding to the two are obtained with the same order among the multiple types. For example, the numbers (1)-(10) represent the above 10 resource records. Assuming that the order of the 10 resource records in the third query data corresponding to the second query result A2 is (3)(2)(9)(1)(5)(6)(7)(4)(10)(8), the order of the 10 resource records in the fourth query data corresponding to the first query result A3 is also: (3)(2)(9)(1)(5)(6)(7)(4)(10)(8).

[0144] S4043: Calculate the hash value corresponding to each type of resource record respectively to obtain multiple first partial hash values ​​corresponding to the first query result and multiple second partial hash values ​​corresponding to the second query result.

[0145] A local hash value, that is, a hash value corresponding to a type of resource record.

[0146] It should be noted that there is no restriction on the execution order of S4042 and S4013, and S4043 can be executed before S4043.

[0147] S4044: Sort and combine the multiple first local hash values ​​and the multiple local second hash values ​​in the second order, calculate a first global hash value based on the multiple first local hash values, and calculate a second global hash value based on the second local hash values.

[0148] For example, assuming that the 10 local hash values ​​obtained for the 10 types of resource records are H1-H10 respectively; then the 10 local hash values ​​are sorted and combined to obtain: (H3) (H2) (H9) (H1) (H5) (H6) (H7) (H4) (H10) (H8). Based on this sorting, the overall hash value is calculated to obtain the first global hash value and the second global hash value corresponding to the second query result A2 respectively.

[0149] S4045: Compare the first global hash value and the second global hash value.

[0150] If the two hash values ​​are consistent, the data verification passes and there is no need to trigger data synchronization. If they are inconsistent, it means that the domain name resolution of the first query result A3 returned by the root replica service module is incorrect, and the local root zone data stored in the root replica service module needs to be updated, which requires triggering data synchronization between the root replica service module and the root server.

[0151] As can be seen, when the proxy layer forwards query requests, it uses parallel transmission, meaning that it sends queries to both the root replica server and the international root server simultaneously. To improve efficiency and response speed, the proxy layer can then employ asynchronous processing, comparing the two query results in real time. Asynchronous processing not only reduces request blocking but also maximizes network resource utilization, further optimizing query performance.

[0152] S405: When A2 and A3 are inconsistent, data synchronization between the root replica service module and the root server is triggered.

[0153] The disclosed embodiment utilizes a structured hash algorithm for data verification. This algorithm first sorts the query results returned by the root server and the root replica service module, respectively, to avoid verification failures due to variable field order within resource records or changes in the order between resource records, thereby improving data verification accuracy. Furthermore, the structured hash algorithm only requires comparing the calculated global hash value, eliminating the need to compare the plaintext data of the query results. This makes it suitable for domain name resolution applications requiring high data confidentiality.

[0154] like Figure 6 As shown, in some embodiments, when the proxy layer detects that the hash values ​​of the query results returned by both paths are inconsistent, the data verification fails, and the proxy layer triggers data synchronization (or data update) between the root replica service module and the root server. The proxy layer sends a notification to the root replica service module to trigger the update. After receiving the notification, the root replica service module sends an update request to the root server. The update request is an incremental update request or a full update request. In response to the full or incremental update request, the root server sends the full or incremental data of the zone file corresponding to the area to the root replica service module. The root replica service module feeds back the update result of the update failure or success to the proxy layer.

[0155] Specifically, an incremental update (IXFR) is first attempted. This process involves comparing the serial numbers of the SOA records and detecting data differences. If the serial numbers in the SOA records are inconsistent and the detected data differences do not exceed a predetermined threshold (a first threshold), an incremental update is triggered.

[0156] Among them, the first threshold can be determined comprehensively based on the transmission volume of data content changes between different serial numbers, the performance of the root copy server itself, and the network conditions. In actual applications, the size of the first threshold can be continuously adjusted in real time based on feedback from various factors.

[0157] If data verification fails, incremental update fails, data difference exceeds the first threshold, or SOA sequence number remains unchanged, the proxy layer will automatically trigger a full update (Authoritative eXchange of Resource Records, AXFR).

[0158] In an optional embodiment, if Figure 7 As shown, in S405, the data synchronization between the root replica service module and the root server is triggered, which can be implemented by the following process:

[0159] S4051: Obtain the first serial number in the SOA record stored locally in the root replica service layer and the second serial number in the SOA record stored in the root server.

[0160] In addition to the expiration time mentioned above, the SOA record also includes the following records:

[0161] Primary Name Server: The address of the root server.

[0162] Email Address: The email address of the technical contact responsible for managing this domain.

[0163] Serial Number: Serial number used to identify the last update time of the DNS record.

[0164] Refresh Interval: Refresh interval refers to the frequency at which the root replica server requests updates from the root server.

[0165] Retry Interval: Retry interval refers to the time interval between root replica servers trying to update again after a failed update.

[0166] Minimum TTL (Time to Live): Minimum TTL refers to the shortest time that the recursive resolver caches records.

[0167] It contains the serial number (SN).

[0168] S4052: Compare the first serial number and the second serial number to see if they are consistent. If not, proceed to S4053; if consistent, proceed to S4056.

[0169] S4053: Determine whether the data volume difference between the region file corresponding to the first serial number and the region file corresponding to the second serial number is less than or equal to a specified first threshold. If yes, proceed to S4054. If not, proceed to S4056.

[0170] S4054: Trigger an incremental update between the root replica server and the root server.

[0171] S4055: Detecting that the incremental update fails, if yes, proceed to S4056, otherwise, end this data synchronization.

[0172] S4056: Triggering a full update between the root replica server and the root server when at least one of the following situations occurs:

[0173] The incremental update fails; the data volume difference between the region file corresponding to the first sequence number and the region file corresponding to the second sequence number exceeds the first threshold; the first sequence number and the second sequence number are consistent.

[0174] Among them, it should be noted that, if S4056 has at least one of the above situations, that is, a necessary prerequisite for triggering a full update is that the data verification fails, and it does not trigger a full update only when at least one of the above situations is satisfied. Based on the existing data synchronization mechanism in the relevant technology, an incremental update will be triggered when the serial numbers in the SOA record are inconsistent. The method proposed in the embodiment of the present disclosure triggers a full update when it detects that the first serial number and the second serial number are consistent, so as to be compatible with the synchronization mechanism in the relevant technology as much as possible. The first serial number and the second serial number are consistent, but the data verification fails, which means that the method of relying solely on the serial number to identify whether an update is needed is not completely reliable. There may be a situation where the serial numbers are consistent, but in fact the zone file data stored in the root copy service module lags behind the authoritative data in the root server.

[0175] In the disclosed embodiment, after triggering data synchronization, the proxy layer first attempts an incremental update. If the incremental update fails or the data difference is too large or the SOA sequence number remains unchanged, the proxy layer can automatically trigger a full update. This mechanism can be as compatible as possible with the existing data synchronization update mechanism. When the incremental update fails, the full update is triggered again, reducing the transmission of unnecessary zone files and other data, and reducing the occupancy of communication resources while achieving data update.

[0176] The disclosed embodiment also proposes adopting a prediction mechanism based on an artificial intelligence algorithm to estimate the time when the root copy data is out of sync and synchronize it in advance, which can further improve the real-time accuracy of the data.

[0177] In an optional embodiment, if Figure 8a and Figure 4 As shown, the method proposed in the embodiment of the present disclosure may further include:

[0178] S501: calling a pre-trained prediction model to predict a target time when data in the zone file between the root replica server and the root server will be out of sync using the prediction model;

[0179] S502: triggering data synchronization of the zone file between the root replica server and the root server within a preset time range before and after the target time.

[0180] For example, in some embodiments, the model architecture of the prediction model can be as follows: Figure 8b As shown in Figure 2, the prediction model can include an input layer, a long short-term memory (LSTM) network layer, a random dropout layer, and a fully connected layer.

[0181] Exemplarily, the prediction model can be obtained by the following training method:

[0182] First, data collection is performed to collect historical synchronization data, such as synchronization time, synchronization frequency, data change amount, etc.

[0183] Based on the collected historical synchronization data, feature engineering is performed to extract meaningful features, such as synchronization interval time, data change rate, network delay, etc., to construct time series features, capture the periodic pattern of data synchronization, and build a training sample data set.

[0184] The training sample data set includes multiple groups of training samples. A group of training samples includes an input feature and an actual synchronization time corresponding to the input feature. The actual synchronization time is used as a label corresponding to the input feature to obtain the training sample data set.

[0185] In some embodiments, the input features may include multiple of the following features:

[0186] The time interval between the most recent synchronization time and the current time, with the current time as the reference point;

[0187] The amount of data change or data change rate during the most recent synchronization;

[0188] Current network latency;

[0189] Memory usage and CPU usage of the electronic device corresponding to the root copy service module;

[0190] The time interval between the most recent synchronization time and the designated time in a corresponding time unit within a predetermined period of time, taking the designated time in each of the multiple time units as the reference point.

[0191] The data change rate is the ratio of the data change amount to the data amount of the entire zone file. The electronic device corresponding to the root copy service module is the electronic device deployed with the root copy service module, such as the root copy server.

[0192] For example, the dimension corresponding to the input layer may be 29 dimensions, that is, the input feature is a 29-dimensional feature vector. Exemplarily, the input feature may specifically include the following multiple elements:

[0193] x1: the time interval from the last synchronization to the present (hours);

[0194] x2: the amount of data changed during the last synchronization (KB);

[0195] x3: current network delay (ms);

[0196] x4-5: current server (i.e., root replica server) memory usage, CPU usage (%);

[0197] x6~x29: Synchronization interval in the past 24 hours.

[0198] Here, X2 can be the data change amount or the data change rate.

[0199] x1 represents the time interval between the current moment and the most recent data synchronization, which can be expressed in hours; x6~x29: represents the time interval between the current moment and the most recent data synchronization within the past 24 hours, taking a time point within each hour as the reference point, and calculating the time interval between the reference point and the most recent synchronization. For example, taking the hourly time of each hour as the reference point, calculate the time interval between the hourly time and the most recent data synchronization. One value is obtained every hour, and the values ​​of 24 elements are obtained. The values ​​of these 24 elements are used to reflect the frequency of data synchronization within the past 24 hours. 24 hours is only an example, and other time lengths can also be used, such as the past 7 days, the past 72 hours, or the past 48 hours, etc. In addition, the above 29-dimensional input features are only examples, and the input features can also be set to other dimensions according to the above description.

[0200] Among them, network latency can provide the local DNS server address, which can be obtained using tests such as the ping command, traceroute tool, and hping3 tool.

[0201] The data change amount is the difference in data volume between the zone files corresponding to two different serial numbers in two SOA records.

[0202] For example, in some embodiments, when the input features of the input layer are 29-dimensional, the LSTM layer may include 32 recurrent units, the hyperparameter p of the Dropout layer may be set to 0.1, and the output dimension of the fully connected layer is 1.

[0203] During the training process, the setting of the Dropout layer can make the neurons stop working or the values ​​of the neurons be set to 0 with a probability of the hyperparameter p, and the neurons that are not set to 0 are scaled with a scaling ratio of 1 / (1-p).

[0204] It should be noted that the Dropout layer can only work in the training phase and may not work in the application phase or the testing phase.

[0205] In some embodiments of the present disclosure, the hyperparameter p of the Dropout layer can be set to 0.1, which can achieve better prediction results and higher prediction accuracy. In other embodiments, it can also be set to other values, which can be adjusted according to actual conditions.

[0206] After obtaining the training sample data set and determining the model architecture and hyperparameters, the input feature samples are input into the prediction model. The prediction model outputs the predicted target time, and the actual synchronization time in the historical synchronization data is used as the label to calculate the value of the loss function. Based on the value of the loss function, the trainable parameters in the prediction model are optimized until the prediction model converges.

[0207] The process of training the prediction model can refer to the training process of the network including the LSTM mechanism.

[0208] After obtaining the prediction model, it can be used to implement intelligent prediction and decision-making for data synchronization. For example, input features are extracted from the current state data, inputted into the trained prediction model, and the prediction model output predicts the next synchronization time. A threshold is also set, and synchronization is triggered in advance when the distance between the current time and the predicted target time falls within the preset threshold.

[0209] For example, if the preset threshold range is 10 minutes, and the prediction model predicts that the next synchronization time is 18:00 on May 23, XX, and the current time is 17:50 on May 23, XX, data synchronization can be triggered. Alternatively, if data synchronization fails to be triggered before the predicted target time due to some special reasons, data synchronization can be triggered again within a preset time range after the target time. For example, if the prediction model predicts that the next synchronization target time is 18:00 on May 23, XX, and the current time is 18:00 or 18:01 on May 23, XX, and it is detected that data synchronization was not triggered within 10 minutes before 18:00 on May 23, XX, data synchronization can be triggered.

[0210] It should be noted that there is no restriction on the execution sequence of S501 - S502 and the above-mentioned S400 - S405 .

[0211] The disclosed embodiments utilize an AI-based prediction mechanism to more intelligently predict when data desynchronization will occur and synchronize data in advance, improving real-time data accuracy. Adaptive learning enables the system to continuously improve its prediction capabilities and adapt to changing system states and network environments.

[0212] The above content describes the determination of the timing of triggering data synchronization. After triggering data synchronization, there may be multiple synchronization failures. To deal with this situation, in some embodiments of the present disclosure, after S405, the following steps may be further performed:

[0213] S406: In response to the failure index meeting a preset condition, switching the current working mode to a second mode.

[0214] Specifically, in S406, regarding whether a switching operating mode is necessary, embodiments of the present disclosure also propose the use of an adaptive failure handling mechanism. This mechanism uses an intelligent algorithm to continuously monitor and analyze update (i.e., synchronization) failure patterns and dynamically adjust failure count weights. For example, continuous failures might be assigned a higher weight, while intermittent failures might be assigned a lower weight. This approach considers not only the number of failures but also their temporal distribution and severity, thereby more accurately reflecting system status and enabling intelligent switching.

[0215] The failure index is used to quantify the situation of multiple synchronization failures, and can be calculated based on the situation of multiple data synchronization failures between the root replica server and the root server.

[0216] In an optional embodiment, the failure index may be a weighted failure index, and the preset condition may be whether it is greater than or equal to a dynamic threshold, specifically, Figure 9 As shown, in S406, in response to the failure index meeting the preset condition, the current working mode is switched to the second mode, which can be implemented in the following manner:

[0217] S4061: Extract at least two indicators based on historical data of multiple synchronization failures detected within an observation period, and determine a weighted failure index based on the at least two indicators.

[0218] Among them, the at least two indicators include at least two of the following: the severity of the nth failure; the weight corresponding to the nth failure; the total number of failures in an observation period; n is a positive integer.

[0219] For example, the weighted failure index WFI is calculated as follows:

[0220]

[0221] Where Fn represents the severity of the nth failure; wn is the weight of the nth failure; and N is the total number of failures during the observation period.

[0222] The severity level can be an integer between 1 and 10 and is determined based on the failure type. Different failure types correspond to different severity levels. For example, failure types may include one or more of the following: no response received, long response delay (exceeding a set threshold), data verification failure, data errors or garbled characters, network jitter, server unreliability, and so on.

[0223] Weights can be set according to the order of time. For example, recent failures have higher weights. That is, the shorter the time interval from the current moment, the greater the corresponding failure weight, and the longer the time interval from the current moment, the smaller the corresponding failure weight.

[0224] S4062: Calculate a dynamic threshold according to the weighted failure index.

[0225] For example, the dynamic threshold can be calculated according to the following formula:

[0226] ;

[0227] Where T is the dynamic threshold to be calculated, T0 is the preset basic threshold, and k is the adjustment factor, which is a preset constant. For example, the value of k is a constant between [0.5, 5]. σ is the standard deviation of multiple weighted failure indices corresponding to multiple observation periods.

[0228] S4063: Compare whether the weighted failure index is greater than the dynamic threshold. If yes, proceed to S4064; otherwise, return to S4061.

[0229] In other words, when the weighted failure index is greater than or equal to the dynamic threshold, ie, WFI ≥ T, a handover is triggered.

[0230] S4064: In response to the failure index meeting a preset condition, switching the current working mode to a second mode.

[0231] For example, the failure index may be a weighted failure index, and the failure index satisfies a preset condition, that is, the weighted failure index is greater than or equal to a dynamic threshold.

[0232] The second mode can also be called the international root mode. The international root mode is a mode in which the proxy layer skips the local root copy service module and directly accesses the root server.

[0233] After switching to the international root mode, the proxy layer can support intelligent request routing. For example, it can dynamically select the current optimal international root server for query based on network conditions, response time, load conditions, etc., to ensure high availability of the service.

[0234] The disclosed embodiment adopts an adaptive failure handling mechanism. The weighted failure index calculated based on multiple indicators such as the number of multiple synchronization failures, the severity of each failure, and the weight of each failure can more accurately quantify different failure situations and trigger the judgment conditions for whether to switch the working mode. It can be dynamically calculated in real time based on historical failure situations and basic thresholds and other factors. By judging whether the weighted failure index is greater than or equal to the dynamic threshold, an intelligent judgment is made on whether the working mode needs to be switched. For example, continuous failures may be given a higher weight, while intermittent failures are given a lower weight, etc. This method not only considers the number of failures, but also the time distribution and severity of the failures, thereby more accurately reflecting the system status. In this way, the switching mechanism can be controlled by controlling the various indicators that affect the dynamic threshold or the weighted failure index, and the decision on whether to switch the working mode can be made more accurately based on the real-time status of the system.

[0235] S407: When it is determined that the current working mode is the second mode, in response to receiving the fourth query request sent by the recursive resolver, a fifth query request is sent to the root server.

[0236] The fourth query request carries the first domain name to be queried. The fifth query request is used to query the IP address corresponding to the first domain name.

[0237] S408: Receive a fifth query result returned by the root server in response to the fifth query request, and return the fifth query result to the recursive resolver.

[0238] For example, Figure 10 As shown, if the domain name resolution result received by the terminal is incorrect, it may send a domain name resolution request Q0 again. In response to the request, the recursive resolver generates a fourth query request Q4 and sends it to the proxy layer. In response to the fourth query request Q4, the proxy layer generates a fifth query request Q5 and sends it directly to the international root server (i.e. Figure 10 ), the international root server returns the fifth query result A5 to the proxy layer, and the proxy layer returns the fifth query result A5 to the recursive resolver and then returns it to the terminal.

[0239] Optionally, in some embodiments, after S408, the following steps may be further performed:

[0240] S409: It is detected that the data synchronization of the zone file between the root replica server and the root server is successful, and the current working mode is switched back to the first mode.

[0241] The first mode may also be referred to as the root copy service mode. In the embodiment of the present disclosure, the first mode is a working mode in which a two-way query is performed and data verification is performed based on the query results returned by the two paths.

[0242] After switching to the second mode, the root replica server's recovery status can be continuously monitored. When the replica server is detected to be back to normal and data synchronization is successful, the proxy layer can automatically switch back to the root replica server mode (the first mode) to maximize the benefits of the local root replica service.

[0243] It should be noted that in some embodiments, a third mode can also be configured. This mode can be a mode that only uses the root replica service. During the short period after successful data synchronization, the data stored locally on the root replica server is generally valid. In this case, if the first mode is used for each request received, that is, each time a two-way parallel query is triggered and the results of the two-way query are verified, it may consume network and computing resources. Therefore, a reasonable time threshold can be set, for example, 12 hours. During this period after successful data synchronization, the system can switch to the third mode. In this mode, query requests are only sent to the root replica server (or the root replica service module), without sending a separate query request to the international root server in parallel. This reduces the use of network and computing resources and fully utilizes the advantages of the local root replica service. After reaching a preset time threshold (for example, 12 hours), the system can switch to the first mode to ensure the reliability of the root replica service.

[0244] Based on the above description, the embodiment of the present disclosure deploys a lightweight proxy layer in front of the root replica server. When receiving a query request from the recursive resolver, the proxy layer simultaneously sends the same query request to its own root replica service module and the international root server. The query result of the root replica service module is used to return to the recursive resolver. After receiving the query result of the international root server, it checks whether the query results of the two are consistent. If the data is inconsistent, it actively triggers the root replica service module to request an update (incremental / full) to update the replica content in the root replica service module. If the root replica service module fails to synchronize international root data multiple times, it can automatically switch back to international root mode, that is, the recursive resolver accesses the proxy layer, and the proxy layer directly forwards the query request to the international root server.

[0245] It can be seen that the above-mentioned solution proposed in the embodiment of the present disclosure proposes multiple improvement mechanisms such as dual-path query and data verification, active synchronous update mechanism and dynamic transparent switching mechanism, intelligent request routing and fault recovery, and adaptive failure processing.

[0246] The dual-path query and data verification mechanism involves the proxy layer sending query requests to both the root replica server and the international root server simultaneously, performing parallel queries. A structured hash algorithm is used to accurately compare the responses to ensure data consistency.

[0247] Two-way query and data verification: When a proxy receives a query request from a recursive resolver, it simultaneously sends the same query request to its own root replica server and to the international root server. The root replica server prioritizes local data for resolution and returns the query result to the recursive resolver as quickly as possible. The proxy returns the root replica server's query result to the recursive resolver and compares it with the query result from the international root server to verify the accuracy of the root replica server's data.

[0248] Active synchronization and update mechanism: Once data inconsistencies are detected, incremental or full data synchronization is immediately triggered to ensure timely updates of local data. In addition, a prediction mechanism based on artificial intelligence algorithms can be used to predict when data is out of sync and synchronize it in advance.

[0249] Specifically, under the active synchronization update mechanism, if data verification fails, it indicates that the data on the local root replica server is inconsistent with the data on the international root server. The proxy layer will trigger incremental or full data synchronization with the root replica server to ensure timely updates of local data. In addition, the active synchronization update mechanism can also use a prediction mechanism based on artificial intelligence algorithms to estimate the time when the root replica data is out of sync and synchronize it in advance, further improving the real-time accuracy of the data.

[0250] Dynamic transparent switching mechanism: When incremental updates fail, the system automatically switches to international root mode without manual intervention. The proxy layer dynamically selects the optimal international root server for query based on network conditions and response time.

[0251] Specifically, the dynamic transparent switching mechanism includes at least two operating modes: root replica service mode (first mode) and international root mode (second mode). If an incremental update fails, a fallback mechanism is implemented. If multiple incremental update attempts fail, the system automatically switches to international root mode. The recursive resolver continues to send queries to the original address (the address of the root replica server). The proxy layer receives the query and, based on the currently configured operating mode, decides whether to forward it to the root replica server or the international root server. In the second mode, the proxy layer sends the query directly to the international root server. In the first mode, the proxy layer sends query requests to both the international root server and the local root replica server simultaneously, performing a two-way query.

[0252] Intelligent request routing and fault recovery mechanism: After switching to international root mode, it continuously monitors the recovery of the root replica server and automatically switches back to the root replica server mode after data synchronization is successful.

[0253] Adaptive failure handling mechanism: An intelligent algorithm continuously monitors and analyzes update failure patterns, dynamically adjusting failure count weights. It uses a weighted failure index (WFI) and dynamic threshold (T) to more accurately reflect system status and trigger failovers.

[0254] The above-mentioned solution proposed in the embodiment of the present disclosure can monitor and calibrate root replica data in real time. If the root replica service fails, it can automatically switch back to the international root mode, eliminating the need to manually switch data sources, reducing operation and maintenance pressure, and improving the synchronization efficiency of replica data. Through real-time data verification and active synchronization mechanisms, the accuracy of root replica server data is ensured. The intelligent fault switching mechanism ensures the continuity and stability of domain name resolution services, enhancing service reliability. In addition, the configuration of working modes and the automatic switching mechanism of working modes reduce operation and maintenance pressure, simplify operation and maintenance management, and improve operation and maintenance efficiency.

[0255] Figure 11 FIG. 1 is a schematic diagram of the structure of a domain name resolution system according to an embodiment of the present disclosure. The domain name resolution system according to this embodiment can be used to implement the corresponding method embodiments of the present disclosure. Specifically, Figure 11 As shown, the domain name resolution system includes a recursive resolver, a root server and a root replica node, and the root replica node is deployed with a root replica service module and an agent module.

[0256] Among them, the proxy module is used to: in response to receiving a first query request sent by the recursive resolver, if the current working mode is the first mode, send a second query request and a third query request in parallel to the root replica server and the root server respectively; the first query request carries the first domain name to be queried; the second query request and the third query request are used to query the Internet Protocol address corresponding to the first domain name; receive the first query result returned by the root replica server in response to the second query request, and return the first query result to the recursive resolver; receive the second query result returned by the root server in response to the second query request; compare whether the first query result and the second query result are consistent, and in response to the inconsistency between the first query result and the second query result, trigger data synchronization between the root replica server and the root server.

[0257] Figure 12 A schematic diagram of the structure of a domain name resolution system according to another embodiment of the present disclosure. The proxy module may include:

[0258] Parallel query module 1101 is configured to, in response to receiving a first query request sent by a recursive resolver, determine if the current operating mode is the first mode and to send a second query request and a third query request in parallel to the root replica server and the root server, respectively, in response to receiving a first query request sent by the recursive resolver. The first query request carries a first domain name to be queried, and the second query request and the third query request are used to query the Internet Protocol address corresponding to the first domain name.

[0259] The first receiving module 1102 is configured to receive a first query result returned by the root replica server in response to the second query request, and return the first query result to the recursive resolver.

[0260] The second receiving module 1103 is configured to receive a second query result returned by the root server in response to the second query request.

[0261] The triggering module 1104 is configured to compare the first query result and the second query result to see whether they are consistent, and in response to a situation where the first query result and the second query result are inconsistent, trigger data synchronization between the root replica server and the root server.

[0262] In some embodiments, the root copy service module may be integrated into the data processing device.

[0263] Below, reference Figure 13 The electronic device according to an embodiment of the present disclosure is described below. The electronic device may be an electronic device deployed with a proxy layer, or an electronic device deployed with a proxy layer and a root replica service module, or both. The electronic device may be a standalone device independent of a root replica server, and the standalone device may communicate with a recursive resolver, a root replica server, and an international root server in the DNS.

[0264] Figure 13 A block diagram of an electronic device according to an embodiment of the present disclosure is illustrated.

[0265] like Figure 13 As shown, the electronic device includes one or more processors and memory.

[0266] The processor may be a central processing unit (CPU) or other forms of processing units having data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device to perform desired functions.

[0267] The memory may store one or more computer program products. The memory may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), a hard disk, flash memory, etc. One or more computer program products may be stored on the computer-readable storage medium, and the processor may execute the computer program products to implement the data processing methods of the various embodiments of the present disclosure described above and / or other desired functions.

[0268] In one example, the electronic device may further include an input device and an output device, and these components are interconnected via a bus system and / or other forms of connection mechanisms (not shown).

[0269] In addition, the input device may also include, for example, a keyboard, a mouse, and the like.

[0270] The output device can output various information to the outside, including determined distance information, direction information, etc. The output device can include, for example, a display, a speaker, a printer, a communication network and a remote output device connected thereto, and the like.

[0271] Of course, to simplify, Figure 13 Only some of the components related to the present disclosure in the electronic device are shown, and components such as a bus, an input / output interface, etc. are omitted. In addition, the electronic device may further include any other appropriate components according to specific application scenarios.

[0272] In addition to the above-mentioned methods and devices, an embodiment of the present disclosure may also be a computer program product, which includes computer program instructions, which, when executed by a processor, enable the processor to perform the steps of the data processing method according to various embodiments of the present disclosure described in the above part of this specification.

[0273] The computer program product may be written in any combination of one or more programming languages ​​to implement the operations of the disclosed embodiments, including object-oriented programming languages ​​such as Java, C++, and conventional procedural programming languages ​​such as C or similar programming languages. The program code may be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0274] In addition, an embodiment of the present disclosure may also be a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, causes the processor to execute the steps of the data processing method according to various embodiments of the present disclosure described in the above part of this specification.

[0275] The computer-readable storage medium may be any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may include, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0276] The basic principles of the present disclosure have been described above in conjunction with specific embodiments. However, it should be noted that the advantages, strengths, and effects mentioned in this disclosure are merely illustrative and not restrictive, and should not be construed as necessarily possessed by each embodiment of the present disclosure. Furthermore, the specific details disclosed above are provided for illustrative purposes and to facilitate understanding, rather than as limitations. These details do not limit the present disclosure to necessarily being implemented using these specific details.

[0277] Each embodiment in this specification is described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. References to the same or similar parts between the various embodiments are sufficient. For system embodiments, since they largely correspond to method embodiments, their description is relatively simple. For relevant parts, references to the description of the method embodiments are sufficient.

[0278] The block diagrams of the devices, devices, equipment, and systems involved in this disclosure are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As will be appreciated by those skilled in the art, these devices, devices, equipment, and systems can be connected, arranged, or configured in any manner. Words such as "include," "comprise," "have," and the like are open-ended words, meaning "including but not limited to," and can be used interchangeably therewith. The words "or" and "and" used herein refer to the words "and / or" and can be used interchangeably therewith, unless the context clearly indicates otherwise. The word "such as" used herein refers to the phrase "such as but not limited to," and can be used interchangeably therewith.

[0279] The methods and systems of the present disclosure may be implemented in many ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above order of steps for the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless otherwise specified. In addition, in some embodiments, the present disclosure may also be implemented as programs recorded in a recording medium, which include machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers recording media that store programs for executing the methods according to the present disclosure.

[0280] It should also be noted that in the apparatus, device, and method of the present disclosure, each component or each step can be decomposed and / or recombined. Such decomposition and / or recombination should be regarded as equivalent solutions of the present disclosure.

[0281] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of the present disclosure. Therefore, the present disclosure is not intended to be limited to the aspects shown herein, but rather to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0282] The above description has been provided for the purpose of illustration and description. In addition, this description is not intended to limit the embodiments of the present disclosure to the forms disclosed herein. Although a number of example aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A data processing method in a domain name resolution system, characterized in that: The method is applied to a domain name system, which includes a recursive resolver, a root server, and a root replica node, wherein the root replica node is deployed with a root replica service module and an agent module; The method is applied to the agent module, and the method includes: In response to receiving the first query request sent by the recursive resolver, if the current working mode is the first mode, sending a second query request and a third query request in parallel to the root replica service module and the root server respectively; wherein the first query request carries the first domain name to be queried; and the second query request and the third query request are used to query the Internet Protocol address corresponding to the first domain name; receiving a first query result returned by the root replica service module in response to the second query request; Receiving a second query result returned by the root server in response to the third query request; Comparing the first query result and the second query result to see if they are consistent; returning the second query result to the recursive resolver; In response to the inconsistency between the first query result and the second query result, data synchronization between the root replica service module and the root server is triggered.

2. The method according to claim 1, characterized in that The first query result and the second query result each include resource records of multiple types; Comparing whether the first query result and the second query result are consistent includes: sorting the multiple fields included in the multiple types of resource records in the first query result and the second query result using the same sorting algorithm to obtain first query data and second query data having the same first order; the first order is the order between multiple fields within the same type of resource record; sorting the resource records of the multiple types in the first query data and the second query data using the same sorting algorithm according to their types, thereby obtaining third query data and fourth query data having the same second order; the second order being the order between the resource records of the multiple types; Calculating hash values ​​corresponding to each type of resource record respectively to obtain multiple first partial hash values ​​corresponding to the first query result and multiple second partial hash values ​​corresponding to the second query result; sorting the plurality of first partial hash values ​​and the plurality of second partial hash values ​​according to the second order; calculating an overall first global hash value based on the sorted plurality of first partial hash values, and calculating an overall second global hash value based on the sorted plurality of second partial hash values; Compare the first global hash value and the second global hash value to see if they are consistent.

3. The method according to claim 1 or 2, characterized in that Triggering data synchronization between the root replica service module and the root server, including: Obtaining a first serial number in a starting authorization record stored locally by the root replica service module and a second serial number in a starting authorization record stored by the root server; In response to the first sequence number and the second sequence number being inconsistent, and a data volume difference between the zone file corresponding to the first sequence number and the zone file corresponding to the second sequence number being less than or equal to a specified first threshold, triggering an incremental update between the root replica service module and the root server; or, In response to at least one of the following situations, a full update between the root replica service module and the root server is triggered: The incremental update fails; the data volume difference between the zone file corresponding to the first sequence number and the zone file corresponding to the second sequence number exceeds the first threshold; the first sequence number and the second sequence number are consistent.

4. The method according to claim 1, wherein After triggering data synchronization of the zone file between the root replica service module and the root server, the method further includes: In response to the failure index meeting a preset condition, switching the current working mode to the second mode; the failure index is used to quantitatively characterize the situation of data synchronization failure between the root replica service module and the root server; In the second mode, in response to receiving the fourth query request sent by the recursive resolver, sending a fifth query request to the root server; the fourth query request carries the first domain name to be queried; and the fifth query request is used to query the Internet Protocol address corresponding to the first domain name; Receive a fifth query result returned by the root server in response to the fifth query request, and return the fifth query result to the recursive resolver.

5. The method according to claim 4, characterized in that The failure index includes a weighted failure index; In response to the failure index meeting a preset condition, switching the current working mode to the second mode includes: Extract at least two indicators based on historical data of multiple synchronization failures detected within an observation period; the at least two indicators include at least two of the following: the severity of the nth failure; the weight corresponding to the nth failure; and the total number of failures within the observation period; wherein the severity is determined based on the failure type, with different failure types corresponding to different severities; and n is a positive integer; A weighted failure index is determined based on the at least two indicators; the weighted failure index is calculated as follows: Where WFI represents the weighted failure index; Fn represents the severity of the nth failure; wn is the weight of the nth failure; N is the total number of failures during the observation period; severity is an integer from 1 to 10; Calculating a dynamic threshold value according to the weighted failure index; In response to the weighted failure index being greater than the dynamic threshold, a switching operation is triggered to switch the current operating mode to the second mode.

6. The method according to claim 5, characterized in that Calculating a dynamic threshold according to the weighted failure index includes: The dynamic threshold is calculated according to the following formula: ； Wherein, T is the dynamic threshold to be calculated, T0 is the preset basic threshold, k is the adjustment factor, the adjustment factor is a preset constant, and σ is the standard deviation of multiple weighted failure indices corresponding to multiple observation periods.

7. The method according to any one of claims 1-2 and 4-6, characterized in that After switching the current working mode to the second mode, the method further includes: It is detected that the data synchronization of the zone file between the root replica service module and the root server is successful, and the current working mode is switched back to the first mode.

8. The method according to any one of claims 1-2 and 4-6, characterized in that The method further comprises: Invoking a pre-trained prediction model to predict a target time when data in a zone file between the root replica service module and the root server will be out of sync; Within a preset time range before and after the target time, data synchronization of the zone file between the root replica service module and the root server is triggered.

9. The method according to claim 8, characterized in that The prediction model includes an input layer, a long short-term memory network (LSTM) layer, a random dropout layer, and a fully connected layer; The pre-trained prediction model is obtained using the following training method: Obtain training sample data, the training sample data including input feature samples obtained based on historical synchronization data and corresponding actual synchronization times; the input features include multiple of the following features: The time interval between the most recent synchronization time and the current time, based on the current time as the reference point; the amount of data change or the data change rate of the most recent synchronization; wherein the data change rate is the ratio of the amount of data change to the amount of data in the entire zone file; the current network latency; the memory usage and CPU usage of the electronic device corresponding to the root replica service module; the time interval between the most recent synchronization time and the specified time in each of the multiple time units as the reference point within the past predetermined period of time, based on the specified time in each of the multiple time units as the reference point; The input feature sample is input into the prediction model, the predicted target moment is output by the prediction model, the actual synchronization moment in the historical synchronization data is used as a label, the value of the loss function is calculated, and the trainable parameters in the prediction model are optimized according to the value of the loss function until the prediction model converges.

10. A domain name resolution system, characterized in that: The domain name resolution system includes a recursive resolver, a root server, and a root replica node. The root replica node is deployed with a root replica service module and an agent module; the agent module is used to: In response to receiving the first query request sent by the recursive resolver, if the current working mode is the first mode, sending a second query request and a third query request in parallel to the root replica service module and the root server respectively; The first query request carries a first domain name to be queried; The second query request and the third query request are used to query the Internet Protocol address corresponding to the first domain name; receiving a first query result returned by the root replica service module in response to the second query request; Receiving a second query result returned by the root server in response to the second query request; comparing the first query result and the second query result to determine whether they are consistent, and returning the second query result to the recursive resolver; In response to the inconsistency between the first query result and the second query result, data synchronization between the root replica service module and the root server is triggered.

11. An electronic device, characterized in that: include: a memory for storing a computer program product; A processor is configured to execute a computer program product stored in the memory, and when the computer program product is executed, implements the method described in any one of claims 1 to 9.

12. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the computer program instructions are executed by a processor, the method described in any one of claims 1 to 9 is implemented.

13. A computer program product comprising computer program instructions, characterized in that When the computer program instructions are executed by a processor, the method according to any one of claims 1 to 9 is implemented.

Images