Domain name resolution method and device, and related equipment

Abstract

The present disclosure provides a domain name resolution method and device, related equipment, wherein the method comprises: searching for a root area file corresponding to a target domain name from a root peer node of a blockchain domain name resolution network when the client resolves the target domain name, wherein the root area file includes top-level domain name (TLD) information and a hash value in the target domain name; the blockchain domain name resolution network includes a root peer node and an authoritative peer node; verifying the root area file based on a public key corresponding to the target domain name obtained from the client; obtaining a sub-area file from an authoritative peer node matching the hash value if the verification is passed; and resolving an IP address corresponding to the target domain name from a resource record set in the sub-area file. In the present application, since the hash value in the root area file corresponds to the sub-area file one by one, the consistency of the root area and the sub-area data storage is ensured, thereby ensuring the consistency of the resource record set.

Description

Technical Field

[0001] This disclosure relates to the field of domain name resolution technology, specifically to a domain name resolution method and apparatus, and related equipment. Background Technology

[0002] DNS (Domain Name System) is a critical infrastructure providing services for domain name resolution on the Internet. Internet applications that use domain names (such as the Web and email) rely on these services to correctly translate domain names into IP (Internet Protocol) addresses. Currently, DNS continues to evolve and plays a wide role on the Internet, but the availability and consistency of the domain name resolution process have long plagued DNS. Domain name resolution availability problems refer to the inability of the domain's authoritative server to respond to domain name resolution requests. Availability problems are caused by denial-of-service (DoS) attacks or single points of failure (SPOF). Consistency problems stem from the lack of mandatory data synchronization mechanisms between authoritative server replicas or between parent / child authoritative servers. Domain name resolution consistency problems refer to inconsistencies in a domain's Resource Record Set (RRSet) across different storage locations. To address availability and consistency issues, increasing the encryption security of DNS is a widely used method. The main solutions currently available are as follows:

[0003] DNS caching can increase access efficiency. A DNS server performs recursive queries and continues querying other DNS servers until it has the IP address returned to the client. Caching recursive DNS queries is generally faster than iterative queries. A recursive DNS server caches the final answer to each query it performs and retains that answer for a certain period.

[0004] However, DNS caching can lead to inconsistencies. These inconsistencies mainly fall into three categories: 1) Inconsistency between the glue record of the parent zone and the storage of the child zone. This is called delegation inconsistency. 2) Inconsistency between the same RRSet replicas on different authoritative servers. This is called replica inconsistency. 3) Inconsistency between the RRSet cached in the recursive resolver and the one stored on the authoritative server. This is called cache inconsistency. Summary of the Invention

[0005] The purpose of this disclosure is to provide a domain name resolution method and apparatus, and related equipment, to solve the technical problem of inconsistent data caching in the prior art of DNS caching.

[0006] In a first aspect, embodiments of this disclosure provide a domain name resolution method, the method comprising: when resolving a target domain name based on a client, searching for a root zone file corresponding to the target domain name from the root peer nodes of a blockchain domain name resolution network, wherein the root zone file includes top-level domain (TLD) information and a hash value of the target domain name; the blockchain domain name resolution network includes root peer nodes and authoritative peer nodes; verifying the root zone file based on a public key obtained from the client corresponding to the target domain name; if the verification is successful, obtaining a sub-zone file from an authoritative peer node matching the hash value, wherein the hash value and the sub-zone file have a one-to-one correspondence; and resolving the IP address corresponding to the target domain name from the resource set in the sub-zone file.

[0007] In one embodiment, before resolving the target domain name based on the client, the method further includes: storing the root region file in multiple first peer nodes of the target blockchain network, and setting the multiple first peer nodes to be based on the same smart contract constraints to obtain multiple root peer nodes; wherein, the root region file includes a hash value, the hash value being used to index a one-to-one corresponding sub-region file; storing the sub-region file in multiple second peer nodes of the target blockchain network to obtain multiple authoritative peer nodes, wherein the multiple second peer nodes all store data with the same identity; and constructing the blockchain domain name resolution network based on the multiple root peer nodes and the multiple authoritative peer nodes.

[0008] In one embodiment, both the root zone file and the sub-zone file include at least the following types of data: domain names belonging to the hierarchical namespace, domain data mapped to the domain names, and the public keys of the domain names.

[0009] In one embodiment, the root zone file includes: a first structure and a second structure; wherein the first structure includes a first field for storing the TLD name, a second field for storing the hash value of the subdomain file, a third field for storing the public key of the TLD authorizing entity for location identification, a fourth field for storing the digital signature generated by the root authorization, and a fifth field for storing the digital signature generated by the TLD authority; the second structure includes a sixth field for representing the resource record set and a seventh field for generating a digital signature by signing the resource record set.

[0010] In one embodiment, verifying the root zone file based on the public key corresponding to the target domain name obtained from the client includes: obtaining the public key stored in the third field of the root zone file; and comparing the public key corresponding to the target domain name obtained from the client with the public key stored in the third field.

[0011] In one embodiment, if the verification passes, obtaining a sub-region file from an authoritative peer node that matches the hash value includes: if the public key stored in the third field of the root region file matches the public key corresponding to the target domain name, obtaining the hash value from the second field of the root region file; and obtaining the sub-region file from an authoritative peer node that corresponds one-to-one with the hash value.

[0012] In one embodiment, the method further includes: splitting the region file into multiple small file blocks when the size of the region file is greater than a preset threshold, and uploading and retrieving the multiple small file blocks; after uploading and retrieving the multiple small file blocks, determining the hash value corresponding to the multiple small file blocks, and combining the multiple small files into a new region file based on the determined hash value.

[0013] Secondly, this disclosure also provides a domain name resolution apparatus, comprising: a search module, configured to search for a root zone file corresponding to the target domain name from the root peer nodes of a blockchain domain name resolution network when resolving a target domain name based on a client, wherein the root zone file includes top-level domain (TLD) information and a hash value of the target domain name; the blockchain domain name resolution network includes root peer nodes and authoritative peer nodes; a verification module, configured to verify the root zone file based on a public key obtained from the client corresponding to the target domain name; an acquisition module, configured to acquire a sub-zone file from an authoritative peer node matching the hash value if the verification is successful, wherein the hash value and the sub-zone file have a one-to-one correspondence; and a resolution module, configured to resolve the IP address corresponding to the target domain name from the resource set in the sub-zone file.

[0014] Thirdly, embodiments of this disclosure also provide an electronic device, including a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the domain name resolution method described above.

[0015] Fourthly, embodiments of this disclosure also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the domain name resolution method described above.

[0016] In this embodiment of the disclosure,

[0017] The blockchain domain name resolution network in this embodiment includes root peer nodes and authoritative peer nodes. Root peer nodes are equivalent to root servers, and authoritative peer nodes are equivalent to authoritative servers. Therefore, when resolving a target domain name, the root zone file corresponding to the target domain name can be searched from the root peer nodes. The root zone file is then verified against the public key corresponding to the target domain name. If the verification is successful, a sub-zone file is obtained from the authoritative peer node whose hash value matches, and the corresponding IP address is resolved from this sub-zone file. Since the hash value in the root zone file and the sub-zone file in this embodiment correspond one-to-one, the consistency of data storage between the root zone and sub-zone is guaranteed, thereby ensuring the consistency of the resource record set and solving the problem of data caching inconsistency in existing DNS caching technologies. Attached Figure Description

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

[0019] Figure 1 This is a flowchart illustrating a domain name resolution method provided in an embodiment of this disclosure;

[0020] Figure 2 This is a flowchart illustrating another domain name resolution method provided in this embodiment of the disclosure;

[0021] Figure 3 This is a schematic diagram of a blockchain domain name resolution network provided in a specific example of an embodiment of this disclosure;

[0022] Figure 4 This is a schematic diagram of peer nodes in a specific example provided in the embodiments of this disclosure;

[0023] Figure 5 This is a schematic diagram of the region file structure provided in a specific example of an embodiment of this disclosure;

[0024] Figure 6 This is a schematic diagram of domain name delegated verification provided in an embodiment of this disclosure;

[0025] Figure 7 This is a schematic diagram of the structure of a domain name resolution device provided in an embodiment of this disclosure;

[0026] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0027] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0028] This disclosure provides a domain name resolution method, such as... Figure 1 As shown, the method includes:

[0029] Step 101: When resolving the target domain name based on the client, search for the root zone file corresponding to the target domain name from the root peer nodes of the blockchain domain name resolution network. The root zone file includes the top-level domain (TLD) information and hash value of the target domain name. The blockchain domain name resolution network includes root peer nodes and authoritative peer nodes.

[0030] Step 102: Verify the root zone file based on the public key obtained from the client corresponding to the target domain name;

[0031] Step 103: If the verification is successful, obtain the sub-region file from the authoritative peer node that matches the hash value, where there is a one-to-one correspondence between the hash value and the sub-region file;

[0032] Step 104: Resolve the IP address corresponding to the target domain name from the resource set in the sub-region file.

[0033] As can be seen from steps 101 to 104 of this embodiment, the blockchain domain name resolution network in this embodiment includes root peer nodes and authoritative peer nodes. The root peer nodes are equivalent to root servers, and the authoritative peer nodes are equivalent to authoritative servers. Therefore, when resolving a target domain name, the root zone file corresponding to the target domain name can be searched from the root peer nodes. Then, the root zone file is verified against the public key corresponding to the target domain name. If the verification is successful, a sub-zone file is obtained from the authoritative peer node that matches the hash value, and the corresponding IP address is resolved from the sub-zone file. Since the hash value in the root zone file and the sub-zone file in this embodiment correspond one-to-one, the consistency of data storage between the root zone and the sub-zone is guaranteed, thereby ensuring the consistency of the resource record set and solving the problem of inconsistent data caching in the prior art.

[0034] In other words, the index information of the subdomain's zone file in this embodiment is contained in the parent domain's zone file, so the client can obtain the target domain's resolution data through multiple iterative queries. Existing DNS technologies index the subdomain's zone file using the IP address (glue record) of the authoritative server storing the subdomain's zone file. Since the authoritative server and the stored data are not bound together, inconsistency between parent and subdomains cannot be completely avoided. In this embodiment, indexing the subdomain's zone file using the hash value of the root zone file ensures the consistency of the stored data. Furthermore, due to the characteristics of hash functions, the hash value of the zone file obtained by the hash function has a natural binding relationship with the zone file. When the client obtains the hash value of the subdomain's zone file from the root zone file, the zone file storing the subdomain data is uniquely determined. In a specific example of the embodiment of this application, the model of the hash function can be: h = H(M), where M is the area file of the subdomain data, h is the hash value of the area file storing the subdomain data, h has a fixed length and is independent of the length of M; H has a one-way property: (1) given H and M, it is easy to calculate h; (2) given h and H, it is difficult to calculate M; (3) there are no M1 and M2 such that H(M1) = H(M2).

[0035] In an optional embodiment of this application, before resolving the target domain name based on the client, such as Figure 2 As shown, the method in this application embodiment may further include:

[0036] Step 201: Store the root region file in multiple first peer nodes of the target blockchain network, and set multiple first peer nodes based on the same smart contract constraints to obtain multiple root peer nodes; wherein, the root region file includes a hash value, which is used to index the one-to-one corresponding sub-region files;

[0037] Step 202: Store the sub-region file in multiple second peer nodes of the target blockchain network to obtain multiple authoritative peer nodes, wherein the multiple second peer nodes store data with the same identity.

[0038] Step 203: Construct a blockchain domain name resolution network based on multiple root peer nodes and multiple authoritative peer nodes.

[0039] As can be seen from steps 201 to 203 above, the blockchain domain name resolution network in this embodiment includes two layers: a root peer node and an authoritative peer node, such as... Figure 3As shown, root peers act as root servers in the DNS, responding to queries for root zone data. Furthermore, root peers join the permissioned blockchain domain name resolution network through identity verification. All root peers execute operations describing the entity's (root / TLD authorization) actions on resources, such as TLD delegation and domain data publication. These operations are defined by a consensus-based smart contract across all root peers. Therefore, all entities initiating operations through the root nodes are bound by the same smart contract. Each entity can control the TLD resources delegated to it. Moreover, each entity can participate in the collaborative management of other entities' resources based on contractual constraints.

[0040] Authoritative peer nodes function similarly to authoritative servers at various levels in DNS, providing authoritative responses for all stored domain data. In this network, all nodes can act as authoritative servers for all domain names (such as TLDs, second-level domains (SLDs), etc., excluding the root domain). Peer nodes storing domain name data no longer distinguish between master and slave roles; all peer nodes store data with the same identity.

[0041] like Figure 4 As shown, there are two authoritative peers for TLD Ta and Tc, three peers for TLD Te, and one peer for SLD Sa. Each peer can act as an authoritative peer for multiple domains. For example, peer No.1 is an authoritative peer for three domains (TLDa / c / e), and peer No.3 is an authoritative peer for three domains (TLD c / e and SLD a).

[0042] In addition, the root zone file and sub-zone file involved in the embodiments of this application each include at least the following types of data: domain name belonging to the hierarchical namespace, domain data mapped to the domain name, and public key of the domain name.

[0043] Optionally, the root region file in this embodiment includes: a first structure and a second structure; wherein, the first structure includes a first field for storing the TLD name, a second field for storing the hash value of the subdomain file, a third field for storing the location identifier TLD authorization entity public key, a fourth field for storing the digital signature generated by the root authorization, and a fifth field for storing the digital signature generated by the TLD organization; the second structure includes a sixth field for representing the resource record set and a seventh field for signing the resource record set to generate a digital signature.

[0044] Regarding the above structure and fields, see the specific example area file such as... Figure 5 As shown:

[0045] The IndexItem structure (first structure) is used to store the index information of the TLD. IndexItem uses five fields to index the TLD zonefile: SubDomainName (corresponding to the first field), ZonefileHash (corresponding to the second field), AuthorityPublicKey (corresponding to the third field), PublicationSig (corresponding to the fourth field), and DelegationSig (corresponding to the fifth field).

[0046] 1) The Sub DomainName field stores the TLD name.

[0047] 2) The ZonefileHash field stores the hash value of the subdomain zone file.

[0048] 3) The AuthorityPublicKey field stores the public key that uniquely identifies the TLD authorized entity.

[0049] 4) The DelegationSig field is the digital signature generated by the root authorization, representing an authorization action. This means that the TLD (SubDomainName) is authorized to the entity holding the public key (AuthorityPublicKey).

[0050] 5) The PublicationSig field is a digital signature generated by the TLD authority to ensure the authenticity and integrity of the ZonefileHash hash used to index TLD zone data.

[0051] The DomainDataItem structure (corresponding to the second structure) stores data belonging to the root domain. A DomainDataItem must include at least two fields:

[0052] 1) RRSet (corresponding to the sixth field) represents a resource record set whose format conforms to the DNS protocol and consists of five fields: name, class, type, ttl (time to live), and rdata (record data).

[0053] 2) The RRSig (corresponding to the seventh field) field is a digital signature generated by the root authority signing the RRSet field, used to protect the authenticity and integrity of the domain data.

[0054] In addition, in an optional embodiment of this application, for large area file storage, the following method can be adopted: when the capacity of the area file is greater than a preset threshold, the area file is split into multiple small file blocks, and the multiple small file blocks are uploaded and retrieved; after the multiple small file blocks are uploaded and retrieved, the hash value corresponding to the multiple small file blocks is determined, and the multiple small files are combined into a new area file based on the determined hash value.

[0055] The above preset thresholds can be set according to actual needs, such as setting the preset threshold to 100MB, 120MB, etc.

[0056] Based on the blockchain domain name resolution network in the above embodiments of this application, the method of verifying the root zone file based on the public key corresponding to the target domain name obtained from the client in step 102 can further include:

[0057] Step 11: Obtain the public key stored in the third field of the root region file;

[0058] Step 12: Compare the public key obtained from the client corresponding to the target domain name with the public key stored in the third field.

[0059] For steps 11 and 12 above, in a specific example as follows: Figure 6 The domain delegation verification shown is achieved by verifying the delegation result (DelegationSig) of the subdomain. Verify([parent]AuthorityPublicKey,DelegationSig) = True is required to ensure that the subdomain is delegated to the correct registrant. That is, the digital signature generated by the registrant holding the public key (AuthorityPublicKey) must be consistent with DelegationSig.

[0060] Based on the blockchain domain name resolution network in the above embodiments of this application, the method of obtaining the sub-region file from the authoritative peer node matching the hash value in step 103, where verification is successful, further includes:

[0061] Step 21: If the public key stored in the third field of the root zone file matches the public key corresponding to the target domain name, obtain the hash value from the second field of the root zone file.

[0062] Step 22: Obtain the sub-region file from the authoritative peer node that corresponds one-to-one with the hash value.

[0063] For steps 21 and 22 above, in a specific example as follows: Figure 6The area file data verification shown is used to check the authenticity of the area file and verify the area file of subdomain a,sdkcfjdkmsmkqklmbv,l,,,,,,,,,,,,,,,,,,,,,,,,3ercbffnhgdbjmngrjnhcdbfvvgdc.

[0064] Based on this, in a specific example, the steps for resolving the IP address of the target domain name "www.example.com" and ensuring the domain name resolution process in the architecture of this application embodiment include:

[0065] Step 31: In order to resolve "www.example.com", the root peer node searches the root region file and then returns the IndexItem containing the TLD "com" to the client.

[0066] Step 32, the client verifies (leftmost red arrow) that TLD "com" has been delegated to the public key representing the TLD authorization entity.

[0067] Step 33: The client uses the correct hash value (leftmost blue arrow) to verify the region file published by the TLD "com" agency.

[0068] Step 34: The client uses the region file hash to index the TLD “com” region file to find the IndexItem containing the SLD “example.com”.

[0069] Step 35: The client repeats the verification operation until it obtains the RRSet and RRSig of the IP address of "www.example.com", at which point the target domain name is securely resolved.

[0070] Therefore, through the method described in this embodiment, a hash function is used to ensure a natural binding relationship between the hash value of the zone file obtained by the hash function and the zone file itself, avoiding inconsistencies between parent and child domains; domain name data is stored in a blockchain system, guaranteeing data availability. Furthermore, in the data structure of the zone file in this embodiment, the authoritative public key of the domain is used to protect the authenticity of the domain name resolution results; the digital signature generated by the root authority effectively guarantees the integrity of the resolved data. Additionally, the domain name resolution process in this embodiment introduces decentralization, ensuring the data security and traceability of the domain name resolution service. Decentralized storage involves dividing data into small blocks, encrypting them, and distributing them across numerous nodes, leveraging the advantages of storage sharing and saving the construction costs of centralized storage.

[0071] like Figure 7 As shown in the embodiments of this disclosure, a domain name resolution device 700 is also provided, the device 700 comprising:

[0072] Search module 702 is used to search for the root zone file corresponding to the target domain name from the root peer nodes of the blockchain domain name resolution network when resolving the target domain name based on the client. The root zone file includes the top-level domain (TLD) information and hash value of the target domain name. The blockchain domain name resolution network includes root peer nodes and authoritative peer nodes.

[0073] Verification module 704 is used to verify the root zone file based on the public key corresponding to the target domain name obtained from the client;

[0074] The acquisition module 706 is used to obtain sub-region files from authoritative peer nodes that match the hash value if the verification is successful, wherein there is a one-to-one correspondence between the hash value and the sub-region file;

[0075] The resolution module 706 is used to resolve the IP address corresponding to the target domain name from the resource set in the sub-region file.

[0076] Optionally, the apparatus in this application embodiment further includes: a first storage module, configured to store root region files in multiple first peer nodes of the target blockchain network before resolving the target domain name based on the client, and to set multiple first peer nodes to be based on the same smart contract constraints to obtain multiple root peer nodes; wherein, the root region file includes a hash value, and the hash value is used to index the corresponding sub-region files; a second storage module, configured to store sub-region files in multiple second peer nodes of the target blockchain network to obtain multiple authoritative peer nodes, wherein the multiple second peer nodes store data with the same identity; and a construction module, configured to construct a blockchain domain name resolution network based on the multiple root peer nodes and the multiple authoritative peer nodes.

[0077] Optionally, the root zone file and sub-zone file in this application embodiment each include at least the following types of data: domain name belonging to the hierarchical namespace, domain data mapped to the domain name, and public key of the domain name.

[0078] Optionally, the root region file in this embodiment includes: a first structure and a second structure; wherein, the first structure includes a first field for storing the TLD name, a second field for storing the hash value of the subdomain file, a third field for storing the location identifier TLD authorization entity public key, a fourth field for storing the digital signature generated by the root authorization, and a fifth field for storing the digital signature generated by the TLD organization; the second structure includes a sixth field for representing the resource record set and a seventh field for signing the resource record set to generate a digital signature.

[0079] Optionally, the verification module in this application embodiment includes: a first acquisition unit, used to acquire the public key stored in the third field of the root zone file; and a comparison unit, used to compare the public key corresponding to the target domain name acquired from the client with the public key stored in the third field.

[0080] Optionally, the acquisition module in this application embodiment includes: a second acquisition unit, used to acquire a hash value from the second field of the root zone file when the public key stored in the third field of the root zone file matches the public key corresponding to the target domain name; and a third acquisition unit, used to acquire a sub-zone file from the authoritative peer node that corresponds one-to-one with the hash value.

[0081] Optionally, the apparatus in this application embodiment further includes: a first processing module, configured to split the region file into multiple small file blocks when the capacity of the region file is greater than a preset threshold, and upload and retrieve the multiple small file blocks; and a second processing module, configured to determine the hash value corresponding to the multiple small file blocks after the upload and retrieval of the multiple small file blocks are completed, and combine the multiple small files into a new region file based on the determined hash value.

[0082] The domain name resolution device 700 provided in this embodiment can implement the various processes in the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0083] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure, such as... Figure 8 As shown, the electronic device includes: a processor 801, a memory 802, and a program 8021 stored in the memory 802 and executable on the processor 801.

[0084] When program 8021 is executed by processor 801, it can achieve the following: Figure 1 Any steps in the corresponding method embodiments and the achievement of the same beneficial effects will not be repeated here.

[0085] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by hardware related to program instructions, and the program can be stored in a readable medium.

[0086] This disclosure also provides a readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described functions. Figure 1 Any step in the corresponding method embodiment can achieve the same technical effect, and will not be repeated here to avoid repetition.

[0087] The computer-readable storage medium of this disclosure can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0088] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0089] The program code contained on the storage medium can be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0090] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or terminal. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0091] The above description represents the preferred embodiments of this disclosure. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles described herein, and these improvements and modifications should also be considered within the scope of protection of this disclosure.

Claims

1. A domain name resolution method, characterized in that, The method includes: When resolving a target domain name based on a client, the root zone file corresponding to the target domain name is searched from the root peer nodes of the blockchain domain name resolution network. The root zone file includes the top-level domain (TLD) information and hash value of the target domain name. The blockchain domain name resolution network includes root peer nodes and authoritative peer nodes. The root peer nodes respond to queries for root zone data, and the authoritative peer nodes provide authoritative responses for all stored domain data. The root zone file is verified based on the public key obtained from the client corresponding to the target domain name; If the verification is successful, a sub-region file is obtained from the authoritative peer node that matches the hash value, wherein there is a one-to-one correspondence between the hash value and the sub-region file; The IP address corresponding to the target domain name is resolved from the resource set in the sub-region file.

2. The method according to claim 1, characterized in that, Before resolving the target domain name based on the client, the method further includes: The root region file is stored in multiple first peer nodes of the target blockchain network, and the multiple first peer nodes are set to be based on the same smart contract constraints to obtain multiple root peer nodes; wherein, the root region file includes a hash value, which is used to index the corresponding sub-region files; The sub-region file is stored in multiple second peer nodes of the target blockchain network to obtain multiple authoritative peer nodes, wherein the multiple second peer nodes store data with the same identity. The blockchain domain name resolution network is constructed based on multiple root peer nodes and multiple authoritative peer nodes.

3. The method according to claim 1, characterized in that, Both the root zone file and the sub-zone file include at least the following types of data: domain names belonging to the hierarchical namespace, domain data mapped to the domain names, and the public keys of the domain names.

4. The method according to claim 3, characterized in that, The root region file includes: a first structure and a second structure; The first structure includes a first field for storing the TLD name, a second field for storing the hash value of the subdomain file, a third field for storing the public key of the TLD authorizing entity for location identification, a fourth field for storing the digital signature generated by the root authorizing entity, and a fifth field for storing the digital signature generated by the TLD authority. The second structure includes a sixth field for characterizing the resource record set and a seventh field for generating a digital signature by signing the resource record set.

5. The method according to claim 4, characterized in that, Verification of the root zone file based on the public key obtained from the client corresponding to the target domain name includes: Obtain the public key stored in the third field of the root region file; The public key corresponding to the target domain name obtained from the client is compared with the public key stored in the third field.

6. The method according to claim 5, characterized in that, If the verification passes, the sub-region file is retrieved from the authoritative peer node that matches the hash value, including: If the public key stored in the third field of the root zone file matches the public key corresponding to the target domain name, the hash value is obtained from the second field of the root zone file. The sub-region file is obtained from the authoritative peer node that corresponds one-to-one with the hash value.

7. The method according to claim 1, characterized in that, The method further includes: If the size of a region file exceeds a preset threshold, the region file is split into multiple smaller file blocks, and these smaller file blocks are then uploaded and retrieved. After uploading and retrieving the multiple small file blocks, the hash values ​​corresponding to the multiple small file blocks are determined, and the multiple small files are combined into a new area file based on the determined hash values.

8. A domain name resolution device, characterized in that, include: The search module is used to search for the root zone file corresponding to the target domain name from the root peer nodes of the blockchain domain name resolution network when the target domain name is resolved based on the client. The root zone file includes the top-level domain (TLD) information and hash value of the target domain name. The blockchain domain name resolution network includes root peer nodes and authoritative peer nodes. The root peer nodes respond to queries for root zone data, and the authoritative peer nodes provide authoritative responses for all stored domain data. The verification module is used to verify the root zone file based on the public key obtained from the client corresponding to the target domain name; The acquisition module is used to acquire a sub-region file from an authoritative peer node that matches the hash value if the verification is successful, wherein there is a one-to-one correspondence between the hash value and the sub-region file; The parsing module is used to parse the IP address corresponding to the target domain name from the resource set in the sub-region file.

9. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the method as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that, The readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 7.

Images