Domain name authority management method, device, computer equipment and readable storage medium

Abstract

The embodiments of the present application provide a domain name authority management method, apparatus, computer device, and readable storage medium. The method includes: obtaining a first domain name resource acquisition request submitted by a second-region domain name control node via a cross-domain relay chain; determining a first domain name to be resolved based on the first domain name resource acquisition request; obtaining a domain name access permission list from a first-region alliance chain corresponding to a first-region alliance system, and performing a query in the domain name access permission list to obtain an access permission verification result; when the access permission verification result indicates that the second-region alliance system has access permission to the first domain name to be resolved, obtaining a target Internet Protocol address of the first domain name to be resolved, and submitting it to the cross-domain relay chain so that the second-region domain name control node synchronizes the target Internet Protocol address to the second-region alliance chain corresponding to the second-region alliance system. In this way, the flexibility of regional domain name management and the stability of the overall domain name system can be improved.

Description

Technical Field

[0001] The present application relates to the field of domain name resolution technology, and in particular to a domain name authority management method, apparatus, computer equipment, and readable storage medium. Background Art

[0002] The Internet Domain Name System (DNS) is one of the key infrastructures of the Internet. It can convert readable domain names into Internet Protocol addresses used by computers to route communications, thereby enabling the location and access of Internet resources.

[0003] In related technologies, the root zone management of the global Internet domain name system primarily relies on the Internet Assigned Numbers Authority (IANA). Specifically, IANA centrally manages and distributes Internet domain name root zone files, including exercising administrative authority over the ownership of regional top-level domains. However, on the one hand, the regions to which each regional top-level domain belongs are deprived of the authority to fully and independently formulate their own domain name management rules (such as node admission mechanisms, consensus algorithm selection, and security policy configuration), resulting in limited domain name autonomy and reduced flexibility in regional domain name management. On the other hand, due to the high degree of centralization of root zone management, any failure or attack by IANA is highly likely to cause a large-scale disruption of domain name services, reducing the stability of the overall domain name system. Summary of the Invention

[0004] This application proposes a domain name authority management method, apparatus, computer equipment and readable storage medium, which can improve the flexibility of regional domain name management and the stability of the overall domain name system.

[0005] To achieve the above objectives, a first aspect of an embodiment of the present application provides a domain name authority management method, which is applied to a first regional domain name control node in a cross-domain alliance system. The first regional domain name control node and a second regional domain name control node in the cross-domain alliance system jointly maintain a cross-domain relay chain. The first regional domain name control node and other first regional nodes together constitute a first regional alliance system, and the second regional domain name control node and other second regional nodes together constitute a second regional alliance system. The method includes:

[0006] Obtaining a first domain name resource acquisition request submitted by the second regional domain name control node through the cross-domain relay chain;

[0007] The first domain name resource acquisition request is submitted by any second-region node to the second-region alliance chain corresponding to the second-region alliance system for acquisition by the second-region domain name control node;

[0008] Determine, according to the first domain name resource acquisition request, a first domain name to be resolved corresponding to the second regional domain name control node;

[0009] Obtaining a domain name access permission list from the first regional alliance chain corresponding to the first regional alliance system, and performing an access permission query in the domain name access permission list based on the first domain name to be resolved, to obtain an access permission verification result for the second regional alliance system;

[0010] When the access permission verification result indicates that the second regional alliance system has access permission to the first domain name to be resolved, obtaining a target Internet Protocol address corresponding to the first domain name to be resolved;

[0011] Submit the target Internet Protocol address to the cross-domain relay chain, so that the second regional domain name control node synchronizes the target Internet Protocol address to the second regional alliance chain corresponding to the second regional alliance system based on the cross-domain relay chain.

[0012] Accordingly, a second aspect of an embodiment of the present application proposes a domain name authority management device, which is applied to a first regional domain name control node in a cross-domain alliance system. The first regional domain name control node and the second regional domain name control node in the cross-domain alliance system jointly maintain a cross-domain relay chain. The first regional domain name control node and the other first regional nodes together constitute a first regional alliance system, and the second regional domain name control node and the other second regional nodes together constitute a second regional alliance system. The device includes:

[0013] A first acquisition module is configured to acquire a first domain name resource acquisition request submitted by the second-region domain name control node through the cross-domain relay chain;

[0014] The first domain name resource acquisition request is submitted by any second-region node to the second-region alliance chain corresponding to the second-region alliance system for acquisition by the second-region domain name control node;

[0015] a determination module, configured to determine, according to the first domain name resource acquisition request, a first domain name to be resolved corresponding to the second regional domain name control node;

[0016] a query module, configured to obtain a domain name access permission list from the first regional alliance chain corresponding to the first regional alliance system, and perform an access permission query in the domain name access permission list based on the first domain name to be resolved, to obtain an access permission verification result for the second regional alliance system;

[0017] a second acquisition module configured to acquire a target Internet Protocol address corresponding to the first domain name to be resolved when the access permission verification result indicates that the second regional alliance system has access permission to the first domain name to be resolved;

[0018] A synchronization module is used to submit the target Internet Protocol address to the cross-domain relay chain, so that the second regional domain name control node synchronizes the target Internet Protocol address to the second regional alliance chain corresponding to the second regional alliance system based on the cross-domain relay chain.

[0019] In some embodiments, the domain name authority management device further includes a storage module for:

[0020] For each domain name information, obtain the set of second-region alliance systems that are permitted to access, and the permission levels of all second-region alliance systems to access the first-region alliance system;

[0021] Obtaining a first regional alliance chain corresponding to the first regional alliance system, and using a first regional smart contract module included in the first regional alliance chain, storing the set of second regional alliance systems corresponding to each domain name information and the permission levels corresponding to all second regional alliance systems in a domain name access permission list of the first regional alliance chain;

[0022] The relay smart contract module on the cross-domain relay chain is called through the first-region smart contract module, and the domain name access permission information contained in the domain name access permission list is synchronized to the cross-chain interaction permission storage space on the cross-domain relay chain through the relay smart contract module.

[0023] In some implementations, the domain name rights management device further includes a calling module configured to:

[0024] Determine public domain name information from multiple domain name information;

[0025] The relay smart contract module on the cross-domain relay chain is called through the first-region smart contract module, and the public domain name information is synchronized to the public domain name information storage space on the cross-domain relay chain through the relay smart contract module.

[0026] In some embodiments, the domain name authority management device further includes a first updating module configured to:

[0027] When at least one of the target second-region alliance system set permitted to be accessed by the first domain name information, the permission level of the target second-region alliance system to access the first-region alliance system, and the public domain name information of the first-region alliance system is updated, obtaining corresponding update information;

[0028] updating the domain name access permission list based on the update information through the first zone smart contract module to obtain an updated domain name access permission list;

[0029] The relay smart contract module on the cross-domain relay chain is called through the first region smart contract module, and at least one of the public domain name information storage space and the cross-chain interaction permission storage space is updated through the relay smart contract module based on the update information.

[0030] In some implementations, the domain name rights management apparatus further includes a sending module configured to:

[0031] Obtain a second domain name resource acquisition request submitted by the first regional node to the first regional alliance chain corresponding to the first regional alliance system, and send the second domain name resource acquisition request to the relay smart contract module of the cross-domain relay chain through the first regional smart contract module of the first regional alliance chain, wherein the second domain name resource acquisition request includes the second domain name to be resolved and the second regional alliance system corresponding to the second domain name to be resolved;

[0032] Calling the relay smart contract module to query the domain name access permission information stored in the cross-chain interaction permission storage space of the cross-domain relay chain to obtain the permission query result;

[0033] When the permission query result indicates that the first regional alliance system allows access to the second regional alliance system, the relay smart contract module is called to submit a second domain name resource acquisition request to the second regional alliance chain corresponding to the second regional alliance system.

[0034] In some implementations, the sending module is further configured to:

[0035] When the permission query result indicates that the first regional alliance system allows access to the second regional alliance system, the relay smart contract module is called to query the public domain name information storage space of the cross-domain relay chain, and a query is performed in the public domain name information storage space based on the second domain name to be resolved to obtain a public information query result;

[0036] When the public information query result indicates that the public domain name information storage space does not have the Internet Protocol address corresponding to the second domain name to be resolved, the relay smart contract module is called to submit a second domain name resource acquisition request to the second regional alliance chain corresponding to the second regional alliance system.

[0037] In some implementations, the domain name authority management device further includes a second updating module configured to:

[0038] Obtaining the permission setting application submitted by the newly added regional domain name control node through the cross-domain relay chain;

[0039] Determine, based on the permission setting application, a target permission level for the newly added regional domain name control node to access the first regional alliance system, and information about a second domain name that the newly added regional domain name control node is permitted to access by the newly added regional alliance system;

[0040] Storing the target permission level and the second domain name information in the domain name access permission list of the first regional alliance chain;

[0041] The relay smart contract module on the cross-domain relay chain is called through the first-region smart contract module, and the information corresponding to the first-region alliance system in the cross-chain interaction permission storage space is updated through the relay smart contract module based on the target permission level and the second domain name information.

[0042] Correspondingly, the third aspect of the embodiments of the present application proposes a computer device, which includes a memory and a processor, the memory stores a computer program, and when the processor executes the computer program, it implements the domain name authority management method of any one of the embodiments of the first aspect of the present application.

[0043] Correspondingly, the fourth aspect of the embodiments of the present application proposes a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the domain name authority management method of any one of the embodiments of the first aspect of the present application.

[0044] The present application obtains a first domain name resource acquisition request submitted by a second-region domain name control node through a cross-domain relay chain; wherein the first domain name resource acquisition request is submitted by any second-region node to the second-region alliance chain corresponding to the second-region alliance system for acquisition by the second-region domain name control node; according to the first domain name resource acquisition request, the first domain name to be resolved corresponding to the second-region domain name control node is determined; a domain name access permission list is obtained from the first-region alliance chain corresponding to the first-region alliance system, and an access permission query is performed in the domain name access permission list according to the first domain name to be resolved to obtain an access permission verification result for the second-region alliance system; when the access permission verification result indicates that the second-region alliance system has access permission to the first domain name to be resolved, a target Internet Protocol address corresponding to the first domain name to be resolved is obtained; and the target Internet Protocol address is submitted to the cross-domain relay chain so that the second-region domain name control node synchronizes the target Internet Protocol address to the second-region alliance chain corresponding to the second-region alliance system based on the cross-domain relay chain. In this way, the cross-domain relay chain can be jointly maintained by multiple regional domain name control nodes in the cross-domain alliance system. Each region can independently formulate domain name management rules within the regional alliance chain of its region, such as node access mechanism, etc. When there is a first domain name resource acquisition request, the corresponding regional domain name control node performs permission verification based on the domain name access permission list, which greatly improves the flexibility of regional domain name management. At the same time, the decentralized architecture design avoids the risk of global service interruption due to IANA single point failure or attack. Even if the regional domain name control node in a certain area fails, the remaining nodes can still operate independently, reducing the risk of single point failure, enhancing the system's fault tolerance and anti-attack capabilities, and thus effectively improving the stability of the overall domain name system. In summary, this application can improve the flexibility of regional domain name management and the stability of the overall domain name system. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 This is a schematic diagram of the architecture of the domain name rights management system provided by an embodiment of the present application;

[0046] Figure 2 This is a flowchart of the domain name authority management method provided by an embodiment of the present application;

[0047] Figure 3 This is an example diagram of domain name resolution within the own region provided by an embodiment of the present application;

[0048] Figure 4 This is an example diagram of the cross-chain domain name information interaction process provided by an embodiment of the present application;

[0049] Figure 5 This is an example diagram of domain name authority management provided by an embodiment of the present application;

[0050] Figure 6This is an example diagram of domain name confidentiality level information management provided by an embodiment of the present application;

[0051] Figure 7 This is a schematic diagram of the functional modules of the domain name rights management device provided in an embodiment of the present application;

[0052] Figure 8 This is a schematic diagram of the hardware structure of the computer device provided in the embodiment of the present application. DETAILED DESCRIPTION

[0053] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0054] It should be noted that although the device schematics illustrate functional module divisions and the flowcharts illustrate logical sequences, in certain circumstances, the steps shown or described may be performed in a sequence that differs from the module divisions in the device or the sequence in the flowcharts. The terms "first," "second," and so on, in the specification, claims, and drawings, are used to distinguish similar items and are not necessarily used to describe a specific sequence or precedence.

[0055] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0056] The Internet Domain Name System (DNS) is one of the key infrastructures of the Internet. It can convert readable domain names into Internet Protocol addresses used by computers to route communications, thereby enabling the location and access of Internet resources.

[0057] In related technologies, the root zone management of the global Internet domain name system primarily relies on the Internet Assigned Numbers Authority (IANA). Specifically, IANA centrally manages and distributes Internet domain name root zone files, including exercising administrative authority over the ownership of regional top-level domains. However, on the one hand, the regions to which each regional top-level domain belongs are deprived of the authority to fully and independently formulate their own domain name management rules (such as node admission mechanisms, consensus algorithm selection, and security policy configuration), resulting in limited domain name autonomy and reduced flexibility in regional domain name management. On the other hand, due to the high degree of centralization of root zone management, any failure or attack by IANA is highly likely to cause a large-scale disruption of domain name services, reducing the stability of the overall domain name system.

[0058] Based on this, the embodiments of the present application provide a domain name authority management method, apparatus, computer equipment and readable storage medium, which can improve the flexibility of regional domain name management and the stability of the overall domain name system.

[0059] The domain name authority management method, apparatus, computer device, and readable storage medium provided in the embodiments of the present application are specifically described through the following embodiments. First, the domain name authority management system in the embodiments of the present application is described.

[0060] Please refer to Figure 1 In some implementations, embodiments of the present application provide a domain name authority management system. In this domain name authority management system, a cross-domain relay chain is jointly maintained by multiple top-level domain (ccTLD) registries (i.e., regional domain name control nodes), and multiple regional domain name control nodes constitute a regional alliance system.

[0061] For example, a cross-domain relay chain can include a public domain name information storage space, a cross-chain interaction permission storage space, and a relay smart contract module. The public domain name information storage space is used to store publicly accessible domain name information for all ccTLD consortium chains, improving cross-chain query efficiency. The cross-chain interaction permission storage space is used to store a dictionary of access rights between ccTLD consortium chains, with the key being the consortium chain name and the value being the permission level (e.g., "forbidden access" or "allowed access to partial domain name information"). The relay smart contract module includes a permission management smart contract and a cross-chain interaction smart contract. The former is responsible for permission rules and public domain name management, while the latter handles the verification and forwarding of cross-chain requests.

[0062] Furthermore, each regional domain name control node serves as the core management unit of the corresponding region, responsible for maintaining the regional alliance chain (such as the ccTLD alliance chain) of the region. The regional domain name control node and multiple top-level domain name servers contained in the region (such as the nodes managed by CNNIC) together constitute the regional alliance system.

[0063] For example, a regional consortium chain can include a domain name permission level storage module and a regional smart contract module. The domain name permission level storage module can store domain names and their accessible domain name access rights in a dictionary format, distinguishing between public and private domain names. The regional smart contract module also includes a permission management smart contract and a cross-chain interaction smart contract. The former manages the permission levels and external permissions of domain names on the local chain, while the latter processes query requests from the cross-domain relay chain and returns results.

[0064] For example, when a node in region A requests access to a domain name in region B, the node in region A can first query the cross-chain interaction permission storage space through the relay smart contract module of the relay chain to check the permission level of region A (such as "allow access to some domain names"). If approved, the public domain name information storage space of the relay chain can be queried through the relay smart contract module. If the corresponding information can be queried, the information will be synchronized to the regional alliance chain corresponding to region A; if the corresponding information cannot be queried in the public domain name information storage space, the node in region A submits a query request to the regional alliance chain of region B through the relay smart contract module of the relay chain. The node in region B queries the domain name permission level module through the regional smart contract module of the regional alliance chain to obtain the Internet Protocol address corresponding to the domain name, and submits the Internet Protocol address to the cross-domain relay chain through the regional smart contract module, so that the node in region A synchronizes the Internet Protocol address to the regional alliance chain of region A based on the cross-domain relay chain.

[0065] The domain name authority management method in the embodiments of the present application can be illustrated by the following embodiments.

[0066] It should be noted that in each specific embodiment of the present application, when it comes to the need to perform relevant processing based on data related to user identity or characteristics such as user information, user behavior data, user historical data, and user location information, the user's permission or consent will be obtained first. Moreover, the collection, use, and processing of these data will comply with relevant laws, regulations, and standards. In addition, when the embodiment of the present application needs to obtain the user's sensitive personal information, the user's separate permission or consent will be obtained through a pop-up window or by jumping to a confirmation page. After clearly obtaining the user's separate permission or consent, the necessary user-related data for the normal operation of the embodiment of the present application will be obtained.

[0067] Before introducing the specific implementation methods of this application, the cross-domain relay chain and regional alliance chain will be introduced to facilitate readers' understanding of the subsequent implementation plans.

[0068] In some implementations, the cross-domain relay chain may include a public domain name information storage space, a cross-chain interaction permission storage space, and a relay smart contract module. This is described in detail below.

[0069] Please refer to Figure 1 Specifically, the public domain name information storage space can be responsible for storing domain name information on each regional alliance system that is accessible to all other regional alliance systems (i.e., public domain name information). When a regional alliance system requests access to public domain name information, it can directly query the public domain name information storage space after verifying its permissions through the cross-domain relay chain, thereby improving the efficiency of domain name information exchange.

[0070] In some implementations, a cross-domain permission dictionary can be constructed for each regional alliance system (e.g., a .c alliance system) in the cross-chain interaction permission storage space, from the name of the regional alliance system (or the name of the regional domain name control node) to the domain name information access rights it contains. The structure of the cross-domain permission dictionary is defined as follows: Key, which is the unique identifier of the requested party's regional alliance system (e.g., the regional code .fr or the identifier of the regional domain name control node in this embodiment); Value, which is the access level of the requesting party's corresponding regional alliance system (e.g., the first regional alliance system in this embodiment) to the domain name information in the requested party's region.

[0071] Furthermore, to balance security and flexibility, the authority levels are divided into the following two levels: First-level authority (access prohibited): The regional alliance system corresponding to the requesting party is completely prohibited from accessing all domain name information in the region where the requested party is located, ensuring the absolute confidentiality of core data; Second-level authority (access allowed to some domain names): Only a subset of non-public domain names specified in the target area is open, and the specific range is dynamically defined by the regional domain name control node of the requested party (such as the second regional domain name control node) according to its security policy.

[0072] For example, the domain name information access rights dictionary can be used to independently set permission levels for each regional alliance system in the requesting region. For the second-level permissions, a list of domain name access rights that are allowed can be stored synchronously in the cross-chain interaction permission storage space. In short, each regional domain name control node can submit its own data access rules to the relay smart contract module of the cross-domain relay chain, including the regional alliance systems that are allowed to access its domain name data (permission level) and the scope of domain name data that each regional alliance system is allowed to access.

[0073] The key of the cross-domain permission dictionary is the name of the other regional alliance system (which can also be the name of the regional alliance chain or the regional domain name control node), and its corresponding value represents the level of access permission to the domain name information under the regional alliance system (which can also be the name of the regional domain name control node).

[0074] For example, based on different security and management requirements, permission levels can be divided into two tiers: Level 1 permission: defined as "No Access." At this permission level, no domain name information within the regional alliance system can be accessed, ensuring the highest level of data confidentiality and security; Level 2 permission: defined as "Allow Access to Partial Domain Name Information." At this permission level, access to certain non-public domain name information is permitted. Specifically, the domain name data accessible to each regional alliance system and the scope of permitted access are determined by the regional domain name control node being accessed based on its own security policies and management requirements. This data can also be stored in the Relay Chain's cross-chain interaction permission storage space. This achieves a balance between flexibility and security.

[0075] For example, the relay smart contract can be responsible for automatically executing the logic for cross-chain domain name information exchange and permission verification. It verifies, forwards, and processes data according to preset rules and conditions, reducing human intervention and improving the efficiency and security of domain name information exchange. The relay smart contract module includes two types of smart contracts: a permission management smart contract and a cross-chain interaction smart contract.

[0076] Furthermore, the permission management smart contract included in the relay smart contract module can be responsible for managing domain name information access rights between regional alliance systems, as well as the public domain name information in the public domain name information storage space. The management of domain name information access rights between regional alliance systems is reflected in the fact that each regional domain name control node (or regional alliance system) can submit its own data access rules to the permission management contract, including which regional alliance systems are allowed to access the domain name data of its regional alliance system and the scope of domain name data allowed to be accessed. The permission management contract then controls these rules to generate a domain name access permission list and store it in the relay chain cross-chain interaction permission storage space.

[0077] Furthermore, the permission management smart contract included in the relay smart contract module can manage the public domain name information in the public domain name information storage space. This means that each regional alliance system can submit a request to the permission management contract to add or delete the corresponding public top-level domain name information. The permission management contract will add or delete the public domain name information in the public domain name information storage space of the cross-domain relay chain based on these requests.

[0078] In some implementations, the regional alliance chain may include a domain name authority level storage module and a regional smart contract module. These are described in detail below.

[0079] Specifically, the domain name protection level storage module is responsible for storing the permission level of each domain name. Its data structure is a regional permission dictionary, where the key is the domain name and the corresponding value is a list of regional alliance systems (or regional domain name control nodes) that can access the domain information. Domain information that is accessible to all other regional alliance systems is called public domain information.

[0080] Exemplarily, the regional smart contract module may include two types of smart contracts: a regional authority management smart contract, and a cross-chain interaction smart contract.

[0081] Among them, the regional authority management smart contract is responsible for managing the domain name access rights of other regional alliance systems, as well as the authority level of the top-level domain name information in this region.

[0082] It should be noted that when the regional authority management smart contract manages the domain name access rights of other regional alliance systems, the regional domain name control node can modify the cross-chain domain name information interaction permissions of other regional alliance systems through the regional authority management smart contract, and modify the permission relationship between the regional alliance chains stored in the cross-chain interaction permission storage space on the cross-domain relay chain by calling the regional authority management smart contract on the cross-domain relay chain.

[0083] Furthermore, when the regional rights management smart contract manages the permission levels of domain name information for a country's top-level domain, the regional domain control node can modify the permission levels of each domain name through the regional rights management smart contract, thereby modifying the list of regional alliance systems that can access each domain name. If a domain name is changed from being accessible by all regional alliance systems to being accessible only to a subset of regional alliance systems, the regional domain control node can invoke the rights management smart contract on the cross-domain relay chain through the regional rights management smart contract to delete the corresponding domain name information from the public domain name information storage space on the cross-domain relay chain. Similarly, if a domain name is changed from being accessible only to a subset of regional alliance systems to being accessible to all regional alliance systems, the corresponding domain name will be stored in the public domain name information storage space on the cross-domain relay chain.

[0084] Furthermore, the cross-chain interaction smart contract within the regional smart contract module handles the specific logic for cross-chain domain name data interaction, including initiating cross-chain domain name data access requests to the cross-domain relay chain. Specifically, when the cross-chain relay chain forwards a domain name information query request from another regional alliance system, it verifies whether the regional alliance system has permission to query the corresponding domain name information based on the permission level stored in the domain name permission level storage module. If verification succeeds, the regional domain name control node sends the domain name information to the cross-domain relay chain via the cross-chain interaction smart contract. If verification fails, an error message is returned.

[0085] In the embodiment of the present application, the domain name authority management device will be described from the perspective of the domain name authority management device, which can be integrated into a computer device. Figure 2 , Figure 2 This is a flowchart of the steps of the domain name rights management method provided in an embodiment of the present application. The domain name rights management device can be integrated into, for example, a terminal or a server. When the processor on the terminal or server executes the program instructions corresponding to the domain name rights management method, the specific process is as follows:

[0086] Step 101: Obtain a first domain name resource acquisition request submitted by a second-region domain name control node through a cross-domain relay chain;

[0087] The first domain name resource acquisition request is submitted by any second-region node to the second-region alliance chain corresponding to the second-region alliance system for acquisition by the second-region domain name control node.

[0088] In some embodiments, the domain name authority management method is applied to the first regional domain name control node in the cross-domain alliance system. The first regional domain name control node and the second regional domain name control node in the cross-domain alliance system jointly maintain the cross-domain relay chain. The first regional domain name control node and other first regional nodes together constitute the first regional alliance system, and the second regional domain name control node and other second regional nodes together constitute the second regional alliance system.

[0089] In some embodiments, in order to realize the interaction, authority verification and response of cross-regional domain name data under the cross-domain alliance system architecture, the first domain name resource acquisition request submitted by the second regional domain name control node through the cross-domain relay chain can be obtained and further processed subsequently to ensure that the access to domain name information is carried out under the authority control mechanism of the regional domain name control node to support the autonomous management and unification of the regional domain name control node.

[0090] The cross-domain relay chain can be a consortium chain jointly maintained by multiple regional domain name control nodes, used to handle cross-region domain name data interactions. For example, the cross-domain relay chain can include three submodules: a public domain name information storage space, a cross-chain interaction permission storage space, and a relay smart contract module. The functions of each submodule will be further explained below.

[0091] Among them, the first domain name resource acquisition request can be a request initiated by the second regional node, aiming to obtain specific domain name resources (such as domain name resolution information) from the first regional alliance system. The request is submitted through the cross-domain relay chain and contains necessary parameters such as the target domain name, the requester (that is, the second regional domain name control node) identifier, etc.

[0092] Among them, the cross-domain alliance system can be a distributed domain name system root zone management framework, consisting of a cross-domain relay chain and multiple regional domain name control nodes (such as the first regional domain name control node and the second regional domain name control node, etc.), which is used to realize decentralized storage of domain name data, cross-regional access control and unified domain name space management.

[0093] Among them, the first regional domain name control node can be the management node of the first regional alliance system, specifically the ccTLD registration management agency, which is responsible for maintaining the corresponding first regional alliance chain, executing authority management, and serving as a participating node in the cross-domain relay chain to process cross-domain domain name query requests for itself.

[0094] Among them, the first regional node can be a member node in the first regional alliance system, composed of multiple top-level domain name servers, used for distributed storage and processing of domain name data in the first region, and executing a consensus mechanism to maintain data consistency and security.

[0095] Among them, the first-region alliance system can be an alliance architecture composed of a first-region domain name control node and multiple first-region nodes, which is used for decentralized storage and management of top-level domain name information of the first region (that is, the region where the first-region domain name control node is located), and can implement customized consensus mechanisms and access policies.

[0096] The second regional domain name control node can be the management node of the second regional alliance system, specifically any other ccTLD registry distinct from the first regional domain name control node. It is responsible for managing the access rights of all second regional alliance systems to the first regional alliance system, initiating cross-domain domain name query requests (such as first domain name resource acquisition requests), and participating in the maintenance and permission management of the cross-domain relay chain. It is understandable that the first regional domain name control node and the second regional domain name control node do not refer to specific regional domain name control nodes. They are simply used to facilitate description and distinction of the objects of action from different perspectives. In fact, the first regional domain name control node and the second regional domain name control node can both refer to regional domain name control nodes in multiple regions.

[0097] Among them, the second regional node can be a member node in the second regional alliance system, composed of multiple top-level domain name servers, and is used for distributed storage and processing of domain name data in the second region (that is, the region where the second regional domain name control node is located).

[0098] The second-region alliance system can be a federation architecture consisting of a second-region domain name control node and multiple second-region nodes. It is used to decentralizedly store and manage top-level domain name information in the second region (i.e., the region where the second-region domain name control node is located), and can implement custom consensus mechanisms and access policies. The second-region alliance system can interact with the first-region alliance system via a cross-domain relay chain.

[0099] Among them, the second-region alliance chain can be an alliance chain architecture jointly maintained by the second-region domain name control node and multiple second-region nodes. All nodes store a complete blockchain copy (relevant data of the domain name authority level storage module, as well as the second-region smart contract module and related access policies, etc.), and realize decentralized storage and verification through a preset consensus mechanism, which is used to execute the second-region top-level domain name autonomous management and cross-chain interaction.

[0100] For example, when a second-region node (such as a .fr domain name server) detects that a domain name outside the region needs to be resolved (such as example.cn), it can generate a first domain name resource acquisition request, which includes the identifier of the domain name to be resolved (example.cn), the signature of the requesting node (the second-region alliance chain private key can be used), the object to be requested (the first-region domain name control node), a timestamp and digital signature, etc. Afterwards, the second-region node calls the second-region smart contract module of the second-region alliance chain to submit the request, triggering an on-chain operation: the second-region smart contract module verifies the validity of the second-region node identity (verifies the digital signature) and encapsulates the request into a standard cross-chain transaction, attaching the second-region regional identifier and the first-region regional identifier (that is, the region where the first-region domain name control node is located) (automatically associated based on the top-level domain).

[0101] Furthermore, the second-region smart contract module of the second-region alliance chain can automatically call the relay smart contract module of the cross-domain relay chain, and the second-region domain name control node can call the relay smart contract module to perform authority verification on the domain name resource acquisition request. If the authority verification is passed, it indicates that the second-region domain name control node allows access to the first-region alliance chain corresponding to the first-region domain name control node. Then, the relay smart contract module can write the first domain name resource acquisition request into the cross-domain relay chain through a cross-chain atomic operation protocol (such as a relay routing protocol). The cross-domain relay chain generates a transaction hash based on the first domain name resource acquisition request and submits it to the on-chain processing queue.

[0102] Furthermore, the relay smart contract module of the cross-domain relay chain can automatically trigger the first-region binding event, writing the transaction hash and metadata of the first domain name resource acquisition request to the dedicated subscription channel of the first-region domain name control node. The first-region domain name control node can then obtain the first domain name resource acquisition request through any mechanism, such as polling, time callback, or transaction hash synchronization.

[0103] Through the above methods, under the permission verification mechanism of the cross-domain relay chain, it is possible to ensure that the query request complies with the preset access rules, thereby efficiently responding and providing target domain name information, enhancing the security of the domain name system (avoiding unauthorized access), autonomy (supporting regional independent management) and interoperability (realizing unified cross-region domain name queries).

[0104] In some implementations, to ensure that domain name access complies with pre-set cross-chain permission rules while maintaining the autonomous management rights of each regional alliance system, the relay smart contract module of the cross-domain relay chain can be used to coordinate the interaction of domain name resources between the first regional alliance system and the second regional alliance system to achieve permission verification and secure forwarding of cross-region domain name resolution requests. For example, when any first-region node in the first-region alliance system initiates a domain name resource acquisition request, the domain name permission management method may further include:

[0105] (A.1) Obtaining a second domain name resource acquisition request submitted by the first regional node to the first regional alliance chain corresponding to the first regional alliance system, and sending the second domain name resource acquisition request to the relay smart contract module of the cross-domain relay chain through the first regional smart contract module of the first regional alliance chain, wherein the second domain name resource acquisition request includes the second domain name to be resolved and the second regional alliance system corresponding to the second domain name to be resolved;

[0106] (A.2) Call the relay smart contract module to query the domain name access permission information stored in the cross-chain interaction permission storage space of the cross-domain relay chain and obtain the permission query result;

[0107] (A.3) When the permission query result indicates that the first regional alliance system allows access to the second regional alliance system, the relay smart contract module is called to submit a second domain name resource acquisition request to the second regional alliance chain corresponding to the second regional alliance system.

[0108] Among them, the first-region alliance chain can be an alliance chain architecture jointly maintained by the first-region domain name control node and multiple first-region nodes. All nodes store a complete blockchain copy (relevant data of the domain name authority level storage module, as well as the first-region smart contract module and related access policies, etc.), and realize decentralized storage and verification through a preset consensus mechanism, which is used to execute the autonomous management of the top-level domain name of the first region and cross-chain interaction.

[0109] Among them, the second domain name resource acquisition request can be a request initiated by the first regional node, aiming to obtain the Internet Protocol address of the second domain name to be resolved from the second regional alliance system. The second domain name resource acquisition request can include the domain name to be resolved (the second domain name to be resolved) and the target regional identifier (the second regional alliance system).

[0110] Among them, the first-region smart contract module can be a smart contract deployed on the first-region alliance chain, responsible for processing the first-region domain name authority management logic (such as modifying the domain name authority level) and forwarding cross-region requests to the cross-domain relay chain (such as submitting a second domain name resource acquisition request).

[0111] Among them, the relay smart contract module can be the core component of the cross-domain relay chain, used to perform cross-chain permission verification and request routing, including querying the permission storage space, verifying the legitimacy of access, and forwarding the request to the regional alliance system corresponding to the requested party.

[0112] The second domain name to be resolved may be a target domain name identifier to be resolved (such as example.fr), the top-level domain to which it belongs is managed by the second regional domain name control node and serves as a core parameter of the second domain name resource acquisition request.

[0113] Among them, the cross-chain interaction permission storage space can be an on-chain storage module of the cross-domain relay chain, which is used to record the domain name information access rights between regional alliance systems.

[0114] Among them, the domain name access permission information can be structured data stored in the cross-chain interaction permission storage space, which clearly specifies the permission level and domain name access scope of the requesting area (such as the first area alliance system) to the target area (such as the second area alliance system).

[0115] Among them, the permission query result can be a verification conclusion generated by the relay smart contract module based on the domain name access permission information, which can be "access allowed" or "access prohibited", which is used to control the subsequent routing of the cross-domain relay chain for the second domain name resource acquisition request.

[0116] For example, when any first-region node (e.g., a .cn domain name server) in the first-region alliance system needs to resolve a second domain name (e.g., example.fr) outside its region, it can generate a second domain name resource acquisition request based on the second domain name and the second-region identifier, .fr. The regional domain name control node can then submit the second domain name resource acquisition request to the first-region alliance chain by invoking the first-region smart contract module of the first-region alliance chain. The first-region domain name control node can verify the identity of the first-region node through the first-region smart contract module of the first-region alliance chain. Once verification is successful, the second domain name resource acquisition request is packaged as a standardized cross-chain transaction and automatically forwarded to the relay smart contract module of the cross-domain relay chain via the first-region smart contract module.

[0117] Furthermore, after the relay smart contract module receives the request, the first regional domain name control node can query the cross-domain permission dictionary corresponding to the first regional alliance system identifier (.cn) in the cross-chain interaction permission storage space through the relay smart contract module. The query key (Key) is the identifier (.fr) corresponding to the second regional alliance system, and the query value (Value) is the corresponding permission level, such as allowing access or prohibiting access.

[0118] Furthermore, if the permission query result is "access allowed", the relay smart contract module automatically locates the address of the second regional alliance chain corresponding to the second regional alliance system according to the second regional alliance system identifier (.fr), and submits a second domain name resource acquisition request (including example.fr) to the second regional smart contract module of the second regional alliance chain to trigger the local domain name resolution process of the second regional chain.

[0119] It should be noted that the above scheme is only an embodiment. In the actual implementation process, it is sufficient to refer to the concept of the above example for processing. The embodiments of this application are not listed one by one here.

[0120] Please refer to Figure 3In some implementations, before step (A.1), that is, before "obtaining the second domain name resource acquisition request submitted by the first regional node to the first regional alliance chain corresponding to the first regional alliance system, and sending the second domain name resource acquisition request to the relay smart contract module of the cross-domain relay chain via the first regional smart contract module of the first regional alliance chain," the local region should first perform domain name resolution. If the domain name to be resolved does not belong to the local region, cross-domain resolution is performed through step (A.1) and subsequent steps. Specifically, in the first regional alliance system, when a domain name to be resolved needs to be resolved, the client browser initiates a DNS query request. First, the client queries the local DNS cache and hosts file. If the domain name resolution result (i.e., the corresponding Internet Protocol address) is found in the local cache, the domain name resolution query is completed. Otherwise, the client sends a domain name query request to the recursive resolution server.

[0121] Furthermore, after receiving the request from the client browser, the recursive resolver queries the local DNS server's local cache and local servers. If the query finds a result in the local server's cache, the query is complete, and the recursive resolver directly sends the domain name resolution result to the client browser. Otherwise, the recursive resolver sends a domain name query request to the DNS root server. The recursive resolver can select a node to initiate the domain name query request based on geographic location or node status.

[0122] Furthermore, after receiving the request from the recursive resolver, the DNS root server can send a domain name query request to the first regional node of the first regional alliance chain (i.e., the top-level domain name server corresponding to the region). The root server can select the first regional node to initiate the domain name query request based on the geographical location or node status.

[0123] Furthermore, after receiving the request from the root server, the first regional node of the first regional alliance chain first determines whether the domain name is a top-level domain name corresponding to the first regional alliance chain. If so, it queries the target Internet Protocol address in the distributed database of the first regional alliance chain and sends the retrieved target Internet Protocol address to the recursive resolver. If not, the first regional node generates a second domain name resource acquisition request based on the second domain name to be resolved and submits the second domain name resource acquisition request to the first regional alliance chain corresponding to the first regional alliance system, subsequently executing (A.1). This process is not further described.

[0124] Through the above method, the domain name resource acquisition requests sent by each regional alliance system can be uniformly verified through the cross-domain relay chain, which is conducive to ensuring the security of cross-chain data interaction. In addition, the cross-domain relay chain will forward the domain name resource acquisition request only after it is allowed to access the corresponding regional alliance system, avoiding meaningless forwarding when the first regional alliance system has no permission to access the second regional alliance system. While improving the efficiency of domain name information interaction, it ensures the independent autonomy of each regional domain name control node.

[0125] In some implementations, to optimize cross-domain domain name resolution efficiency, the public domain name storage space of the cross-domain relay chain can be prioritized to verify whether the target domain name is publicly accessible information, thereby avoiding unnecessary cross-chain request forwarding. If the public domain name information storage space cannot be queried, a subsequent permission verification process is triggered to ensure the efficiency, integrity, and security of domain name access. For example, (A.3) may include:

[0126] (A.3.1) When the permission query result indicates that the first regional alliance system allows access to the second regional alliance system, the relay smart contract module is called to query the public domain name information storage space of the cross-domain relay chain, and a query is performed in the public domain name information storage space based on the second domain name to be resolved to obtain the public information query result;

[0127] (A.3.2) When the public information query result indicates that the Internet Protocol address corresponding to the second domain name to be resolved does not exist in the public domain name information storage space, the relay smart contract module is called to submit a second domain name resource acquisition request to the second regional alliance chain corresponding to the second regional alliance system.

[0128] Among them, the public domain name information storage space can be an on-chain storage module deployed on the cross-domain relay chain, which is used to centrally store the domain name resolution information actively disclosed by all regional domain name control nodes (or regional alliance systems). The data is dynamically maintained by the regional smart contract module of each region (public domain names are added and deleted) for priority access during cross-domain queries.

[0129] The public information query result can be the judgment result returned by the relay smart contract module after performing a query operation on the public domain name information storage space. The public information query result can be whether it exists or not.

[0130] Please refer to Figure 4 , Figure 4This is a cross-chain domain name information interaction process. Specifically, when the public information query result indicates that the public domain name information storage space contains the Internet Protocol address corresponding to the second domain name to be resolved, the cross-domain relay chain can return the Internet Protocol address to the first regional alliance system through the relay smart contract module; conversely, if the public information query result indicates that the public domain name information storage space does not contain the Internet Protocol address corresponding to the second domain name to be resolved, it indicates that the Internet Protocol address corresponding to the second domain name to be resolved is not public, and it is necessary to further forward the second domain name resource acquisition request to the second regional alliance system.

[0131] Exemplarily, when the first-region domain name control node verifies through the relay smart contract module that the permission query result of the first-region alliance system function to the second-region alliance system is "access allowed", the relay smart contract module can automatically call the public domain name information storage space query interface and perform a query in the public domain name information storage space based on the second domain name to be resolved (such as example.fr). If the query hits, the Internet Protocol address corresponding to the second domain name to be resolved is returned to the first-region alliance system, and the cross-chain request is skipped; if the query does not hit, the cross-chain access address of the second-region alliance chain is resolved according to the second-region alliance system identifier (.fr) through the relay smart contract module, and a request for obtaining the second domain name resource is submitted to the second-region smart contract module of the second-region alliance chain through the relay routing protocol.

[0132] The pre-query mechanism of public domain name information on the chain can save time for inter-chain communication and consensus verification, and significantly improve the efficiency of cross-domain resolution. Moreover, when the corresponding data is not available for public query, the subsequent cross-chain permission verification and target chain query are triggered, which can ensure that the security isolation of private domain names is not destroyed, and ensure the autonomy of each regional domain name control node, thereby improving the flexibility of domain name authority management.

[0133] In some implementations, in order to clarify the scope and level of access to domain name information by different regional alliance systems, it is possible to set the second regional alliance system allowed to access and the corresponding permission level for each domain name information in each regional alliance chain, and synchronously update the cross-chain access rights on the cross-domain relay chain, thereby supporting refined permission control for cross-domain domain name interactions and ensuring the consistency of global permission status. Exemplarily, before step 101, that is, before "obtaining the first domain name resource acquisition request submitted by the second regional domain name control node through the cross-domain relay chain", it may also include:

[0134] (B.1) For each domain name, obtain the set of second-region alliance systems that are permitted to access the system, as well as the permission levels of all second-region alliance systems to access the first-region alliance system;

[0135] (B.2) Obtaining the first regional alliance chain corresponding to the first regional alliance system, and using the first regional smart contract module contained in the first regional alliance chain, storing the set of second regional alliance systems corresponding to each domain name information, as well as the permission levels corresponding to all second regional alliance systems, in the domain name access permission list of the first regional alliance chain;

[0136] (B.3) The relay smart contract module on the cross-domain relay chain is called through the first-region smart contract module, and the domain name access permission information contained in the domain name access permission list is synchronized to the cross-chain interaction permission storage space on the cross-domain relay chain through the relay smart contract module.

[0137] The domain name information may be a top-level domain name resource managed by the first regional alliance system, including a domain name identifier (such as a .cn domain name) and its associated resolution data (such as an Internet Protocol address, resource records, etc.). Each domain name information corresponds to information of a second regional alliance system to which access is permitted. Information of multiple second regional alliance systems may constitute a second regional alliance system set.

[0138] The second regional alliance system set can be a logical grouping of other regional alliance systems authorized by the first regional alliance system to access domain name information (e.g., allowing domains in the ".fr" and ".de" zones to access domain names in the ".cn" zone). The second regional alliance system set can be independently defined and dynamically maintained by the first regional domain name control node to identify the accessible scope of domain names. It is understood that since each region corresponds to a second regional alliance system, the second regional alliance system set can also be a set of identifiers for each region.

[0139] The permission level may be a domain name access control level set for each second-region alliance system, which may be divided into access prohibited and access permitted. For example, for access to a .cn domain name, access to .fr is permitted, and access to .mx is prohibited.

[0140] Among them, the domain name access permission list can be a structured permission policy table stored in the first regional alliance chain, which is used to locally define the cross-regional opening rules of each domain name information.

[0141] Please refer to Figure 5 For example, a first-region domain name control node (e.g., the .cn management authority) can obtain domain name permission rules through a local management interface or policy configuration file. For each domain name it manages (e.g., news.cn), the first-region domain name control node can explicitly authorize a list of identifiers (or a list of regional identifiers) of the second-region alliance system that can access the domain name, for example, allowing access to the .fr region.

[0142] Furthermore, the first regional domain name control node can also set an authority level for each second regional alliance system. For example, the second regional alliance system A and the second regional alliance system C are allowed to access the first regional alliance system, and the second regional alliance system B is prohibited from accessing the first regional alliance system, and so on.

[0143] Specifically, the first-region domain name control node can write the generated permission policy into the domain name access permission list on the chain through the first-region smart contract module included in the first-region alliance chain. The domain name access permission list can store the regional permission dictionary and the permission levels of all second-region alliance systems to access the current first-region alliance system. The regional permission dictionary can use domain name information as a key to store the associated set of second-region alliance systems. Specifically, this application does not limit the specific format for storing the domain name access permission list. It only needs to ensure that the above information is stored in the domain name access permission list. In this way, flexible and autonomous domain name access rules can be achieved through hierarchical storage of permission policies.

[0144] In some embodiments, the first-region domain name control node can call the synchronization interface of the relay smart contract module of the cross-domain relay chain through the first-region smart contract module of the first-region alliance chain, and write the domain name access permission information contained in the generated domain name access permission list into the cross-chain interaction permission storage space of the cross-domain relay chain through the relay smart contract module to complete the global policy synchronization update.

[0145] Exemplarily, for each domain name information (e.g., news.cn) in the first region (.cn), the second region alliance system set that is permitted to access: authorizes access by the second region alliance systems in the .fr and .de regions;

[0146] For the first region (.cn), the corresponding permission levels of each second-region alliance system can be: allowed access (the specific access scope is determined by the set of second-region alliance systems corresponding to multiple domain name information): ".fr" region, ".de" region; prohibited access: ".m" region, ".cc" region;

[0147] Furthermore, the first-region domain name control node may submit the above-mentioned domain name access permission information to the first-region smart contract module of the first-region alliance chain, and store the domain name access permission information in the domain name access permission list of the first-region alliance chain through the first-region smart contract module. The storage format of the domain name access permission information in the domain name access permission list may be set according to actual conditions, and the embodiment of the present application does not impose any specific restrictions on this.

[0148] In some embodiments, the second-region smart contract module can automatically trigger cross-chain synchronization. At this time, the first-region domain name control node can write the domain name access permission information into the cross-chain interaction permission storage space by calling the relay smart contract.

[0149] Through the above approach, the first-region domain name control node corresponding to the first region can independently define and dynamically adjust domain names to open up its absolute management rights over the domain name information of this region, preventing cross-domain access without authorization from the first-region domain name control node of this region. At the same time, by automatically synchronizing domain name access permission information to the cross-domain relay chain, the real-time and accurate global permission verification is ensured. This not only improves the security and efficiency of domain name resource sharing between multi-region alliance systems, but also provides a feasible technical path for achieving trusted cross-domain resolution under sovereign isolation within multiple regions.

[0150] In some implementations, to improve the efficiency and reliability of cross-domain data interaction, each regional domain name control node (including the first regional domain name control node and the second regional domain name control node) can filter and synchronize public domain name information to the cross-domain relay chain, so that other regional alliance systems that are allowed to access the current regional alliance system can directly obtain the public domain name information of the current regional alliance system from the public domain name information storage space on the cross-domain relay chain. In this way, the efficiency of public domain name resolution can be improved while ensuring the secure isolation of private domain name data. Exemplarily, the domain name rights management method may also include:

[0151] (C.1) Determine public domain name information from multiple domain name information;

[0152] (C.2) The first-region smart contract module calls the relay smart contract module on the cross-domain relay chain, and synchronizes the public domain name information to the public domain name information storage space on the cross-domain relay chain through the relay smart contract module.

[0153] The public domain name information may be a subset of domain name resolution data (such as a public institution domain name under .cn) that is actively authorized by the first regional domain name control node of the first regional alliance system (from the perspective of the first regional alliance system, it can actually be applicable to any regional alliance system) to be accessed by all other regional alliance systems, including domain name information and its associated Internet Protocol address.

[0154] In some implementations, the first regional domain name control node can automatically mark domain name information as public by identifying public attribute tags in domain name registration information (e.g., government / education domain names like "gov.", "edu."). Alternatively, domain names with cross-regional request volumes exceeding a threshold (e.g., 100,000 / day) within a statistical period (e.g., 30 days) based on historical traffic analysis can be identified as high-frequency public domain names. Furthermore, administrators can manually add or remove public domain names through the first regional consortium chain's governance interface, triggering on-chain consensus verification within the regional smart contract module.

[0155] Furthermore, after obtaining the public domain name information, the first-region domain name control node can actively initiate an interaction request to the relay smart contract module (deployed on the cross-domain relay chain) through the first-region smart contract module (deployed on the first-region alliance chain) based on the cross-chain function call protocol (such as the interface specification predefined by the cross-domain relay chain). The request contains the public domain name information data set to be synchronized (including domain name information and associated Internet Protocol address); after receiving the interaction request, the relay smart contract module first confirms the legitimacy of the source of the interaction request through a dual verification mechanism of digital signature and chain identification (verifying the registration identity of the first-region alliance chain and the integrity of the request message). After the verification is passed, the public domain name information data set is hashed and sharded according to the domain name identifier, and is batch-written into the distributed key-value database of the public domain name information storage space through the parallel processing engine (the key is the domain name hash value, and the value is the domain name-Internet Protocol address mapping record).

[0156] Through the centralized storage and dynamic synchronization mechanism of public domain name information on the cross-domain relay chain, non-public domain names can still be controlled by the authority of the regional domain name control node corresponding to the local area. At the same time, regional alliance chains in other regions can directly obtain public domain name information through the public domain name information storage space, reducing the delay of cross-chain interaction and saving computing resources.

[0157] In some implementations, to ensure real-time consistency of domain name access rules and accuracy of cross-domain resolution, when there are changes to the domain name authority policy of the regional alliance system (such as open scope, authority level, public domain name adjustment, etc.), the first regional domain name control node can dynamically adjust the local domain name access permission list through the first regional smart contract module; at the same time, with the help of the relay smart contract module, the changes are synchronized to the public domain name information storage space or cross-chain interactive authority storage space on the cross-domain relay chain to ensure the consistency and verifiability of the authority status of the entire network, effectively preventing illegal access or data inconsistency caused by information lag. For example, the domain name authority management method can also include:

[0158] (D.1) When at least one of the set of target second-region alliance systems permitted to be accessed by the first domain name information, the permission level of the target second-region alliance system to access the first-region alliance system, and the public domain name information of the first-region alliance system is updated, obtaining corresponding update information;

[0159] (D.2) Using the first region smart contract module, the domain name access permission list is updated based on the updated information to obtain an updated domain name access permission list;

[0160] (D.3) Calling the relay smart contract module on the cross-domain relay chain through the first region smart contract module, and updating at least one of the public domain name information storage space and the cross-chain interaction permission storage space based on the update information through the relay smart contract module.

[0161] The target second-region alliance system set may be a second-region alliance system set in the first region that corresponds to the first domain name information and needs to be updated. The target second-region alliance system may be used to define the latest cross-domain open scope of the domain name.

[0162] The update information may be permission change information (adjustment of the set of second-region alliance systems associated with the first-region alliance system, or adjustment of the permission level of the second-region alliance system over the first-region alliance system), or publicity change information (the first-region domain name information managed by the first-region domain name control node needs to be added to or removed from the public domain name information storage space).

[0163] Please refer to Figure 5 In the event that the target second-region alliance system's permission level for accessing the first-region alliance system needs to be updated, the first-region domain name control node can call the first-region smart contract module on the first-region alliance chain and submit the permission level update content through the first-region smart contract module. After updating the domain name access permission list in the domain name confidentiality level storage module through the first-region smart contract module, the first-region domain name control node can send a request to modify cross-chain interaction permissions to the permission management contract on the cross-domain relay chain through the permission management smart contract of the first-region smart contract module, and send the corresponding update information. The permission management contract on the cross-domain relay chain receives the request from the first-region alliance chain to update cross-chain interaction permissions, and after verifying the legitimacy of the request, updates the permission information in the cross-chain interaction permission storage space based on the received update information. After the update is complete, the update result is returned to the first-region alliance chain.

[0164] For example, when there is a target second-region alliance system set that needs to be updated for access permission corresponding to the first domain name information, that is, when the scope of access allowed by the first domain name information to the second-region alliance system is updated, for example, the first domain name information originally allowed access by the second-region alliance system a1 and the second-region alliance system a2, and now the first domain name information needs to be modified to allow access by the second-region alliance system a1, the second-region alliance system a2, and the second-region alliance system a3. At this time, the corresponding combination of the first domain name information is the target second-region alliance system set that needs to be updated.

[0165] Please refer to Figure 6 , Figure 6 This is when the set of target second-region alliance systems permitted to be accessed by the first domain name information needs to be updated. Specifically, the first-region domain name control node can invoke the first-region smart contract module on the first-region alliance chain and submit the updated target second-region alliance system set for the first domain name information for access by all second-region domain name control nodes on the cross-domain relay chain. Based on the updated information, the first-region smart contract module on the first-region alliance chain can modify the domain name confidentiality level information (i.e., the range of second-region alliance systems permitted to be accessed by the first domain name information) in the domain name confidentiality level storage module. After the modification is completed, the corresponding modification information is sent to the relay smart contract module on the cross-domain relay chain via the first-region smart contract, causing the relay smart contract module to modify the cross-domain permission dictionary stored in the relay chain's cross-chain interaction permission storage space.

[0166] Furthermore, after the set of target second-region alliance systems permitted to access the first domain name information has been updated, the first-region alliance system's public domain name information can be checked for updates. For example, the first-region domain name control node can control the first-region smart contract module to check whether the modified content includes modifying domain name information that was originally accessible to all second-region alliance systems to only allow access to some second-region alliance systems; or modifying information that was originally accessible to only some second-region alliance systems to allow access to all second-region alliance systems. If so, the first-region smart contract will send the corresponding modification information to the relay smart contract module on the cross-domain relay chain, requesting that the domain name information stored in the public domain name storage space on the cross-domain relay chain be modified.

[0167] In some embodiments, after receiving an update request and verifying that the request is legitimate, the relay smart contract module on the cross-domain relay chain can update the content as needed, and after the update is completed, return the update result to the first regional alliance system.

[0168] This real-time incremental update mechanism eliminates errors caused by policy delays in cross-domain resolution, enabling real-time synchronization and global consistency of domain name access rights and public information. This ensures that permissions management and data sharing throughout the system are always based on the latest state. This effectively improves the security, consistency, and responsiveness of multi-regional alliance systems in the face of dynamic permissions adjustments, providing key technical support for building a trustworthy distributed domain name management system.

[0169] In some implementations, in order to achieve secure access and refined authority management of the newly added regional alliance system, each first regional domain name control node can, after receiving the authority setting application from the newly added regional domain name control node, configure the authority of the newly added regional alliance information corresponding to the newly added regional domain name control node in the corresponding first regional alliance chain to ensure compatibility and functional consistency between systems. Exemplarily, the domain name authority management method may also include:

[0170] (E.1) Obtain the permission setting application submitted by the newly added regional domain name control node through the cross-domain relay chain;

[0171] (E.2) Based on the permission setting application, determine the target permission level for the newly added regional domain name control node to access the first regional alliance system, and the second domain name information that the newly added regional domain name control node is permitted to access by the newly added regional alliance system;

[0172] (E.3) Storing the target permission level and the second domain name information in the domain name access permission list of the first regional alliance chain;

[0173] (E.4) Calling the relay smart contract module on the cross-domain relay chain through the first-region smart contract module, and updating the information corresponding to the first-region alliance system in the cross-chain interaction permission storage space through the relay smart contract module based on the target permission level and the second domain name information.

[0174] Among them, the newly added regional domain name control node can be a regional domain name control node that has newly joined the cross-domain alliance system, which is responsible for maintaining the newly added regional alliance system to which it belongs. The corresponding newly added regional alliance chain, such as the ".br" alliance chain, needs to apply for cross-chain interaction permissions with other regions through the cross-domain relay chain.

[0175] Among them, the permission setting application can be an on-chain transaction request initiated by a newly added regional domain name control node, which includes its identity and a list of target regions requested for access, and is used to request the regional domain name control nodes corresponding to other regions in the cross-domain alliance system (such as the first region) to configure domain name access rights for it.

[0176] Among them, the target permission level can be the domain name access permission independently defined by the first regional alliance system for the newly added area (such as "allow access to some domain names" or "prohibit access"). The target permission level can be dynamically set based on the first regional security policy. For security reasons, the access permission of the newly added regional alliance system can be set to "prohibit access" by default.

[0177] The second domain name information can be a subset of domain name data that the first regional alliance system authorizes the newly added region to access (such as allowing ".br" to access "eco.cn" and "tech.cn" under ".cn"), which must meet the target permission level constraints (if the permission is "allow access to some domain names", the specific domain name must be specified).

[0178] For example, after completing the deployment of its own regional consortium chain, a newly added regional domain name control node (such as the ".rx" registry) can submit a permission setting application through the cross-domain relay chain. This permission setting application can include chain metadata (such as the cross-chain input address of the newly added consortium chain and the consensus mechanism type) and a digital certificate (certifying that it is a legitimate regional domain name control node). For example, the ".rx" chain can submit an application message to the cross-domain relay chain through the regional smart contract module, including its public key address and light node verification information.

[0179] Furthermore, each regional domain name control node (including the first regional domain name control node) can conduct a risk assessment of the newly added zone (.rx) based on the security policy library and determine the target permission level for its own regional consortium chain to the newly added zone (.rx), such as prohibiting access. Furthermore, some non-sensitive domain names (such as "eco.cn") can be opened as secondary domain name information for .rx access. For example, based on the political credibility assessment of the .rx zone, the permission level for accessing "eco.cn" is to allow access to some domain names.

[0180] In some embodiments, the first regional domain name control node can extract the following trust factors from the permission setting application: regional compliance certificate, that is, whether the newly added region has passed the zero-knowledge proof verification on the chain; historical interaction credit, that is, querying the cross-chain interaction records of the newly added region, such as transaction success rate, number of violations, etc.; regional relationship map, that is, reading the newly added region corresponding to the newly added regional alliance system, and the first region corresponding to the first regional domain name control node, such as ".ch" and ".mg" are alliance regions. Afterwards, the target permission level of the newly added regional alliance chain is determined based on the regional compliance certificate, historical interaction credit, and regional relationship map. For example, the scores of the regional compliance certificate, historical interaction credit, and regional relationship map can be obtained, and the three can be weighted and summed according to preset weights to obtain the final score, and the target permission level corresponding to the newly added regional alliance system can be determined based on the final score.

[0181] Furthermore, the first-region domain name control node can write the target permission level of .rx (for example, allowing access to some domain names) and the list of accessible domain names into the domain name access permission list of the first-region alliance chain through the first-region smart contract module of the first-region alliance chain, and verify the legitimacy of the data through the consensus mechanism.

[0182] Furthermore, the first-region domain name control node can automatically trigger the cross-domain relay chain's relay smart contract module through the first-region smart contract module, and write the target permission level and the second domain name information into the cross-chain interaction permission storage space for storage. For example, the cross-domain relay chain's relay smart contract module records in the permission dictionary that .cn allows .rx limited access to eco.cn.

[0183] By introducing a permission linkage configuration mechanism between the cross-domain relay chain and the regional alliance chain, the permissions can be controlled, the data can be managed, and the cross-chain can be trusted during the access process of the newly added regional domain name control node. This ensures that all participants can access the latest permission configuration in real time, improving cross-chain management efficiency and overall governance capabilities.

[0184] Step 102: Determine the first domain name to be resolved corresponding to the second regional domain name control node according to the first domain name resource acquisition request.

[0185] In some implementations, in order to ensure that subsequent cross-chain queries and permission verification operations can be performed on the correct domain name, the domain name that requires cross-chain domain name resolution can be located to provide a clear operation object for subsequent permission verification and cross-chain routing to ensure the accurate triggering and execution of the domain name resolution process.

[0186] The first domain name to be resolved may be a target domain name identifier (such as "example.cn") resolved from the first domain name resource acquisition request, and its top-level domain name server is managed by the first regional domain name control node.

[0187] For example, the first regional domain name control node can extract the target domain name identifier (such as the target_domain field in the message) and the requesting region identifier (such as ".fr") based on the first domain name resource acquisition request (structured message). Format verification and attribution verification can then be performed. For example, the node can check whether the target_domain complies with top-level domain naming specifications (such as the inclusion of the "." separator) and confirm that the domain name top-level domain (".cn") matches the first regional alliance system identifier (proving that it is a domain name under the jurisdiction of this region). Once verification is passed, the target_domain field value ("news.cn") can be output as the first domain name to be resolved.

[0188] By accurately extracting the target domain name identifier, we can clearly identify the region to which the target domain name belongs, ensure the correctness of cross-chain routing, and facilitate improving the efficiency of subsequent permission verification.

[0189] Step 103: Obtain a domain name access permission list from the first regional alliance chain corresponding to the first regional alliance system, and perform an access permission query in the domain name access permission list according to the first domain name to be resolved to obtain an access permission verification result for the second regional alliance system.

[0190] In some embodiments, in order to quickly determine whether the second region has the legal authority to access the target domain name, the first region domain name control node can perform permission verification on the first domain name to be resolved included in the first domain name resource acquisition request by querying the permission policy stored in the first region alliance chain in the local first region alliance chain, so as to provide an access basis for subsequent cross-chain interactions and ensure the compliance of domain name data access.

[0191] The domain name access permission list may be an on-chain permission policy table stored on the first regional alliance chain, which uses a key-value structure to record the mapping relationship.

[0192] Among them, the access permission verification result can be a judgment conclusion generated by querying the domain name access permission list through the smart contract, which can be to allow access or deny access.

[0193] In some implementations, each key in the domain name access permission list may be domain name information managed by the local region (e.g., "example.cn"), and the value corresponding to each key may be a set of regional alliance systems authorized to access the domain name information (e.g., allowing access to ".fr" and ".de").

[0194] Exemplarily, if the second-region alliance system identifier exists in the set of second-region alliance systems authorized to access the first domain name to be resolved, the access permission verification result indicates that access is allowed; if the second-region alliance system corresponding to the second region is not authorized to access the first domain name to be resolved managed by the first-region domain name control node, the access permission verification result indicates that access is prohibited, and the cross-chain request rejection process is triggered.

[0195] For example, if the identifier of the first regional alliance system corresponding to the first domain name to be resolved ("company.fr") is ".fr", and the identifier of the second regional alliance system is ".cn", when the second regional alliance system requests to query the first domain name to be resolved, the first regional alliance system corresponding to ".fr" needs to determine whether the second regional alliance system has the authority to access the Internet Protocol address corresponding to "company.fr".

[0196] Furthermore, the first-region domain name control node can control the first-region smart contract module in the first-region alliance chain, query the corresponding domain name access permission list according to the first domain name to be resolved ("company.fr"), and obtain the second-region alliance system set that the first domain name to be resolved ("company.fr") is allowed to access. If the second-region alliance system set contains ".cn" and ".de", it indicates that the second-region alliance system identifier exists in the second-region alliance system set authorized to access the first domain name to be resolved, and the access permission verification result is that access is allowed; otherwise, access is prohibited.

[0197] Through the above method, it can be ensured that only requests that have passed precise authority verification can proceed with subsequent operations, while ensuring that the open scope of domain names managed by each first-region domain name control node is absolutely controllable, and at the same time, the security of domain name resources is guaranteed.

[0198] Step 104 : When the access authority verification result indicates that the second regional alliance system has access authority to the first domain name to be resolved, a target Internet Protocol address corresponding to the first domain name to be resolved is obtained.

[0199] In some implementations, in order to improve the efficiency and reliability of cross-domain data interaction, the Internet Protocol address bound to the first domain name to be resolved can be obtained after the authority verification is passed to ensure the credibility and real-time nature of the domain name resolution result.

[0200] Among them, the target Internet Protocol address can be a network terminal identifier (such as 192.0.2.1) that is authoritatively bound to the first domain name to be resolved, which is stored in the distributed database of the first regional alliance chain as the final output result of the cross-domain domain name resolution.

[0201] For example, if the cross-chain interaction smart contract in the first-region smart contract module of the first-region alliance system (“.fr”) confirms that the access permission verification result is allowed, that is, the second-region alliance system (such as .cn) is in the authorization list of the first domain name to be resolved “company.fr”, the first-region smart contract module can automatically trigger the local domain name query instruction, initiate a request to the distributed domain name database of the first-region alliance chain corresponding to “.fr”, and query the target Internet Protocol address corresponding to “company.fr”.

[0202] Furthermore, during local domain name resolution, multiple national top-level domain name server nodes (e.g., "ns1.fr" and "ns2.fr") on the first regional consortium chain can query domain name records in the on-chain distributed database through a consensus mechanism. Specifically, they can search the domain name to IP mapping table stored on the first regional consortium chain, for example, to find the mapping between "company.fr" and 192.168.10.100. If two-thirds of the top-level domain name servers return the same result, the query is deemed valid, and 192.168.10.100 is used as the target Internet Protocol address to ensure data consistency.

[0203] Through the above methods, not only the security and automation level of cross-chain domain name resolution are improved, but also the collaborative efficiency and data credibility of the DNS system in a multi-sovereign domain environment are enhanced, providing key technical support for building a globally trusted decentralized root zone management system.

[0204] Step 105: Submit the target Internet Protocol address to the cross-domain relay chain, so that the second regional domain name control node synchronizes the target Internet Protocol address to the second regional alliance chain corresponding to the second regional alliance system based on the cross-domain relay chain.

[0205] In some embodiments, in order to achieve secure transmission and regional synchronization of cross-chain domain name resolution results, after the first regional alliance system completes the target Internet Protocol (IP) address query, the target Internet Protocol address can be submitted to the cross-domain relay chain, and the cross-domain relay chain will assist in synchronizing it to the second regional alliance chain. In this way, the integrity and consistency of cross-domain data transmission can be guaranteed, and efficient intercommunication of DNS resolution information between multiple sovereign domains can be achieved.

[0206] For example, after the first-region alliance chain (.fr alliance chain) obtains the target Internet Protocol address (192.168.10.100), the first-region domain name control node can encapsulate it into a cross-chain response data packet through the cross-chain interaction smart contract of the first-region smart contract module, including the first domain name to be resolved ("company.fr"), the corresponding target Internet Protocol address (192.168.10.100), a digital signature (the node private key signature of the first-region alliance chain to ensure data authenticity), etc., and send the cross-chain response data packet to the cross-domain relay chain through a predefined cross-chain protocol.

[0207] Furthermore, the first-region domain name control node can verify the validity of the digital signature of the cross-chain response data packet (confirm that it is legally sent by the first alliance chain corresponding to ".fr") through the cross-chain interactive smart contract of the relay smart contract module of the cross-domain relay chain, and record the transaction hash to the relay chain ledger (to achieve audit traceability). After that, the cross-chain response data packet is synchronized to the applicant, that is, the second-region alliance chain, such as the .cn alliance chain.

[0208] Furthermore, the second-zone smart contract module of the second-zone alliance chain can verify the signature and source of the data packet (secondary tamper-proof verification), extract the target Internet Protocol address, such as 192.168.10.100, cache it locally, and finally return it to the user's browser through the root server and recursive resolver.

[0209] The present application obtains a first domain name resource acquisition request submitted by a second-region domain name control node through a cross-domain relay chain; wherein the first domain name resource acquisition request is submitted by any second-region node to the second-region alliance chain corresponding to the second-region alliance system for acquisition by the second-region domain name control node; according to the first domain name resource acquisition request, the first domain name to be resolved corresponding to the second-region domain name control node is determined; a domain name access permission list is obtained from the first-region alliance chain corresponding to the first-region alliance system, and an access permission query is performed in the domain name access permission list according to the first domain name to be resolved to obtain an access permission verification result for the second-region alliance system; when the access permission verification result indicates that the second-region alliance system has access permission to the first domain name to be resolved, a target Internet Protocol address corresponding to the first domain name to be resolved is obtained; and the target Internet Protocol address is submitted to the cross-domain relay chain so that the second-region domain name control node synchronizes the target Internet Protocol address to the second-region alliance chain corresponding to the second-region alliance system based on the cross-domain relay chain. In this way, the cross-domain relay chain can be jointly maintained by multiple regional domain name control nodes in the cross-domain alliance system. Each region can independently formulate domain name management rules within the regional alliance chain of its region, such as node access mechanism, etc. When there is a first domain name resource acquisition request, the corresponding regional domain name control node performs permission verification based on the domain name access permission list, which greatly improves the flexibility of regional domain name management. At the same time, the decentralized architecture design avoids the risk of global service interruption due to IANA single point failure or attack. Even if the regional domain name control node in a certain area fails, the remaining nodes can still operate independently, reducing the risk of single point failure, enhancing the system's fault tolerance and anti-attack capabilities, and thus effectively improving the stability of the overall domain name system. In summary, this application can improve the flexibility of regional domain name management and the stability of the overall domain name system.

[0210] See also Figure 7The embodiment of the present application further provides a domain name rights management device, which is applied to a first-region domain name control node in a cross-domain alliance system. The first-region domain name control node and a second-region domain name control node in the cross-domain alliance system jointly maintain a cross-domain relay chain. The first-region domain name control node and other first-region nodes together constitute a first-region alliance system, and the second-region domain name control node and other second-region nodes together constitute a second-region alliance system. The domain name rights management device can implement the above-mentioned domain name rights management method. The domain name rights management device includes:

[0211] A first acquisition module 71 is configured to acquire a first domain name resource acquisition request submitted by a second-region domain name control node via a cross-domain relay chain;

[0212] The first domain name resource acquisition request is submitted by any second-region node to the second-region alliance chain corresponding to the second-region alliance system for acquisition by the second-region domain name control node;

[0213] A determination module 72 is configured to determine, based on the first domain name resource acquisition request, a first domain name to be resolved corresponding to the second regional domain name control node;

[0214] A query module 73 is configured to obtain a domain name access permission list from the first regional alliance chain corresponding to the first regional alliance system, and perform an access permission query in the domain name access permission list based on the first domain name to be resolved to obtain an access permission verification result for the second regional alliance system;

[0215] A second obtaining module 74 is configured to obtain a target Internet Protocol address corresponding to the first domain name to be resolved when the access permission verification result indicates that the second regional alliance system has access permission to the first domain name to be resolved;

[0216] The synchronization module 75 is used to submit the target Internet Protocol address to the cross-domain relay chain, so that the second regional domain name control node synchronizes the target Internet Protocol address to the second regional alliance chain corresponding to the second regional alliance system based on the cross-domain relay chain.

[0217] The specific implementation of the domain name authority management device is basically the same as the specific embodiment of the domain name authority management method described above, and will not be repeated here. Under the premise of meeting the requirements of the embodiment of this application, the domain name authority management device can also be provided with other functional modules to implement the domain name authority management method in the above embodiment.

[0218] The present application also provides a computer device comprising a memory and a processor. The memory stores a computer program, and the processor implements the domain name rights management method described above when executing the computer program. The computer device can be any intelligent terminal, including a tablet computer and an in-vehicle computer.

[0219] See also Figure 8 , Figure 8 The hardware structure of a computer device according to another embodiment is shown. The computer device includes:

[0220] The processor 81 may be implemented as a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0221] The memory 82 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 82 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 82 and is called by the processor 81 to execute the domain name rights management method of the embodiments of this application.

[0222] Input / output interface 83, used for information input and output;

[0223] Communication interface 84, used to implement communication interaction between this device and other devices, which can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WiFi, Bluetooth, etc.);

[0224] bus 85 , which transmits information between the various components of the device (e.g., processor 81 , memory 82 , input / output interface 83 , and communication interface 84 );

[0225] The processor 81 , the memory 82 , the input / output interface 83 and the communication interface 84 are connected to each other in communication within the device via a bus 85 .

[0226] An embodiment of the present application also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the above-mentioned domain name authority management method.

[0227] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely arranged relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0228] The embodiments described in the embodiments of this application are intended to more clearly illustrate the technical solutions of the embodiments of this application and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0229] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than shown in the figures, or a combination of certain steps, or different steps.

[0230] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, i.e., they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of this embodiment.

[0231] Those skilled in the art will appreciate that all or some of the steps in the methods, systems, and functional modules / units in the devices disclosed above may be implemented as software, firmware, hardware, or appropriate combinations thereof.

[0232] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0233] It should be understood that in this application, "at least one (item)" and "several" refer to one or more, and "plurality" refers to two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0234] In the several embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For example, the division of the above units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0235] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0236] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0237] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes multiple instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of various embodiments of the present application. The aforementioned storage medium includes: various media that can store programs, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0238] The preferred embodiments of the present invention are described above with reference to the accompanying drawings, but are not intended to limit the scope of the present invention. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and essence of the present invention should be within the scope of the present invention.

Claims

1. A domain name authority management method, characterized in that: A first regional domain name control node is applied to a cross-domain alliance system, the first regional domain name control node and a second regional domain name control node in the cross-domain alliance system jointly maintain a cross-domain relay chain, the first regional domain name control node and other first regional nodes jointly constitute a first regional alliance system, and the second regional domain name control node and other second regional nodes jointly constitute a second regional alliance system, the method comprising: Obtaining a first domain name resource acquisition request submitted by the second regional domain name control node through the cross-domain relay chain; The first domain name resource acquisition request is submitted by any second-region node to the second-region alliance chain corresponding to the second-region alliance system for acquisition by the second-region domain name control node; Determine, according to the first domain name resource acquisition request, a first domain name to be resolved corresponding to the second regional domain name control node; Obtaining a domain name access permission list from the first regional alliance chain corresponding to the first regional alliance system, and performing an access permission query in the domain name access permission list based on the first domain name to be resolved, to obtain an access permission verification result for the second regional alliance system; When the access permission verification result indicates that the second regional alliance system has access permission to the first domain name to be resolved, obtaining a target Internet Protocol address corresponding to the first domain name to be resolved; Submit the target Internet Protocol address to the cross-domain relay chain, so that the second regional domain name control node synchronizes the target Internet Protocol address to the second regional alliance chain corresponding to the second regional alliance system based on the cross-domain relay chain.

2. The domain name authority management method according to claim 1, characterized in that: Before obtaining the first domain name resource acquisition request submitted by the second zone domain name control node through the cross-domain relay chain, the method further includes: For each domain name information, obtain the set of second-region alliance systems that are permitted to access, and the permission levels of all second-region alliance systems to access the first-region alliance system; Obtaining a first regional alliance chain corresponding to the first regional alliance system, and using a first regional smart contract module included in the first regional alliance chain, storing the set of second regional alliance systems corresponding to each domain name information and the permission levels corresponding to all second regional alliance systems in a domain name access permission list of the first regional alliance chain; The relay smart contract module on the cross-domain relay chain is called through the first-region smart contract module, and the domain name access permission information contained in the domain name access permission list is synchronized to the cross-chain interaction permission storage space on the cross-domain relay chain through the relay smart contract module.

3. The domain name authority management method according to claim 2, characterized in that: The method further comprises: Determine public domain name information from multiple domain name information; The relay smart contract module on the cross-domain relay chain is called through the first-region smart contract module, and the public domain name information is synchronized to the public domain name information storage space on the cross-domain relay chain through the relay smart contract module.

4. The domain name authority management method according to claim 3, characterized in that: The method further comprises: When at least one of the target second-region alliance system set permitted to be accessed by the first domain name information, the permission level of the target second-region alliance system to access the first-region alliance system, and the public domain name information of the first-region alliance system is updated, obtaining corresponding update information; updating the domain name access permission list based on the update information through the first zone smart contract module to obtain an updated domain name access permission list; The relay smart contract module on the cross-domain relay chain is called through the first region smart contract module, and at least one of the public domain name information storage space and the cross-chain interaction permission storage space is updated through the relay smart contract module based on the update information.

5. The domain name authority management method according to claim 1, characterized in that: The method further comprises: Obtain a second domain name resource acquisition request submitted by the first regional node to the first regional alliance chain corresponding to the first regional alliance system, and send the second domain name resource acquisition request to the relay smart contract module of the cross-domain relay chain through the first regional smart contract module of the first regional alliance chain, wherein the second domain name resource acquisition request includes the second domain name to be resolved and the second regional alliance system corresponding to the second domain name to be resolved; Calling the relay smart contract module to query the domain name access permission information stored in the cross-chain interaction permission storage space of the cross-domain relay chain to obtain the permission query result; When the permission query result indicates that the first regional alliance system allows access to the second regional alliance system, the relay smart contract module is called to submit a second domain name resource acquisition request to the second regional alliance chain corresponding to the second regional alliance system.

6. The domain name authority management method according to claim 5, characterized in that: When the permission query result indicates that the first regional alliance system allows access to the second regional alliance system, calling the relay smart contract module to submit a second domain name resource acquisition request to the second regional alliance chain corresponding to the second regional alliance system includes: When the permission query result indicates that the first regional alliance system allows access to the second regional alliance system, the relay smart contract module is called to query the public domain name information storage space of the cross-domain relay chain, and a query is performed in the public domain name information storage space based on the second domain name to be resolved to obtain a public information query result; When the public information query result indicates that the public domain name information storage space does not have the Internet Protocol address corresponding to the second domain name to be resolved, the relay smart contract module is called to submit a second domain name resource acquisition request to the second regional alliance chain corresponding to the second regional alliance system.

7. The domain name authority management method according to claim 1, characterized in that: The method further comprises: Obtaining the permission setting application submitted by the newly added regional domain name control node through the cross-domain relay chain; Determine, based on the permission setting application, a target permission level for the newly added regional domain name control node to access the first regional alliance system, and information about a second domain name that the newly added regional domain name control node is permitted to access by the newly added regional alliance system; Storing the target permission level and the second domain name information in the domain name access permission list of the first regional alliance chain; The relay smart contract module on the cross-domain relay chain is called through the first-region smart contract module, and the information corresponding to the first-region alliance system in the cross-chain interaction permission storage space is updated through the relay smart contract module based on the target permission level and the second domain name information.

8. A domain name authority management device, characterized in that: A first regional domain name control node is applied to a cross-domain alliance system, wherein the first regional domain name control node and a second regional domain name control node in the cross-domain alliance system jointly maintain a cross-domain relay chain, the first regional domain name control node and other first regional nodes jointly constitute a first regional alliance system, and the second regional domain name control node and other second regional nodes jointly constitute a second regional alliance system, the device comprising: A first acquisition module is configured to acquire a first domain name resource acquisition request submitted by the second-region domain name control node through the cross-domain relay chain; The first domain name resource acquisition request is submitted by any second-region node to the second-region alliance chain corresponding to the second-region alliance system for acquisition by the second-region domain name control node; a determination module, configured to determine, according to the first domain name resource acquisition request, a first domain name to be resolved corresponding to the second regional domain name control node; a query module, configured to obtain a domain name access permission list from the first regional alliance chain corresponding to the first regional alliance system, and perform an access permission query in the domain name access permission list based on the first domain name to be resolved, to obtain an access permission verification result for the second regional alliance system; a second acquisition module configured to acquire a target Internet Protocol address corresponding to the first domain name to be resolved when the access permission verification result indicates that the second regional alliance system has access permission to the first domain name to be resolved; A synchronization module is used to submit the target Internet Protocol address to the cross-domain relay chain, so that the second regional domain name control node synchronizes the target Internet Protocol address to the second regional alliance chain corresponding to the second regional alliance system based on the cross-domain relay chain.

9. A computer device, characterized in that: The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the domain name authority management method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the domain name authority management method according to any one of claims 1 to 7 is implemented.

Images