Open public key publishing method and device based on DNS (Domain Name Server) and proof of workload
By adopting an open public key distribution method based on DNS and proof-of-work, the problem of the stringent public key distribution methods in the prior art is solved, and a flexible, reliable and economical public key distribution method is achieved. A lightweight public key distribution scheme is provided by utilizing the DNS system.
Patent Information
- Application Number
- CN202511162443.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-19
- Publication Date
- 2025-11-11
AI Technical Summary
Existing public key distribution methods are too restrictive, resulting in high time and economic costs and a lack of flexibility.
By using an open public key distribution method based on DNS and proof-of-work, an authoritative server receives authoritative DNS requests from clients, checks the pubkey record of the domain name, calculates the proof-of-work, and encapsulates the public key into authoritative data after the conditions are met, and returns the DNS response result.
It achieves flexibility and reliability in public key distribution, reduces time and economic costs, and provides a lightweight public key distribution scheme by leveraging the common network infrastructure DNS system.
Smart Images
Figure CN120934762A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of public key cryptography, specifically to an open public key distribution method and apparatus based on DNS and proof-of-work. Background Technology
[0002] Public-key cryptography plays a crucial role in identity authentication and data tamper-proofing on the internet. Relying on digital signatures, it ensures that data cannot be altered or forged. In this technology, the private key is kept securely by the identity holder and protected from disclosure. Conversely, secure and effective public key distribution is equally critical for the successful implementation of this technology.
[0003] Current public key distribution methods, considering the need to ensure the authenticity of the public key issuer's identity, typically employ certificate issuance. Therefore, public key certificates are usually created and distributed by specialized Certificate Authorities (CAs). Applicants need to choose an authoritative and trustworthy CA.
[0004] There are many well-known Certificate Authorities (CAs) on the market, such as Symantec, GeoTrust, and Thawte, which offer certificates of different levels and functions to meet the needs of different users. When choosing a CA, factors such as security, compatibility, price, and the CA's reputation and service quality should be considered.
[0005] Using Certificate Authorities (CAs) to issue public keys has significant constraints. For example, it requires applying to a specialized CA and submitting stringent supporting documentation, and also incurs fees and waiting times for approval. Therefore, existing public key distribution methods are quite restrictive, inflexible, and result in high time and financial costs. Summary of the Invention
[0006] To address this, this application provides an open public key distribution method and apparatus based on DNS and proof-of-work, in order to solve the problems of insufficient flexibility and high time and economic costs in existing public key distribution methods.
[0007] To achieve the above objectives, this application provides the following technical solution:
[0008] Firstly, an open public key distribution method based on DNS and proof-of-work, the method being applied to an authoritative server, comprising:
[0009] Step 1: Receive the authoritative DNS request sent by the client; the authoritative DNS request is of type pubkey and encapsulates an opt record of type keyex in the authoritative DNS request;
[0010] Step 2: Check if the pubkey record of the domain exists according to the authoritative DNS request, and return the check result to the client; the check result encapsulates an opt record of type keyex; after receiving the check result, the client determines whether the domain is available according to the opt record of type keyex in the check result. If the domain is available, calculate the proof of work that meets the requirements according to the requirements, and re-initiate the authoritative DNS request to the authoritative server.
[0011] Step 3: Receive the authoritative DNS request resent by the client and verify whether the proof-of-work condition is met;
[0012] Step 4: If the proof of work does not meet the conditions, the verification result will be returned to the client;
[0013] Step 5: If the proof-of-work condition is met, the client's public key is encapsulated into a pubkey type record and added to the local authoritative data. A DNS response with a noerror code is returned to the client. The response contains a pubkey type record in the answer segment and encapsulates an opt type record of keyex. After receiving the response, the client confirms whether the public key has been correctly published based on the answer segment in the response.
[0014] Optionally, the opt record of type keyex includes: client or server identifier, opcode, random code or nonce value, matching rule, remaining validity time of random code, submitted public key data and signature data.
[0015] Optionally, in step 2, the calculation of the proof of work that meets the requirements specifically includes: concatenating the domain name requested by oneself, the random code provided by the authoritative server and a nonce value in sequence as input, then calculating the hash value according to the SHA-256 algorithm, and confirming whether the hash value meets the requirements according to the matching rules given by the authoritative server.
[0016] Optionally, in step 3, verifying whether the proof of workload meets the conditions specifically includes: concatenating the request domain name, the random code of the current period, and the nonce value in sequence, calculating the hash value, and confirming whether the conditions are met based on the hash value.
[0017] Optionally, it also includes:
[0018] Receive a public key update request sent by the client; the public key update request contains its own private key signature;
[0019] Verify the validity of the private key signature; if invalid, return a refused result; if valid, update the pubkey type data in the authoritative data and return the corresponding response packet for successful publication.
[0020] Optionally, it also includes: the authoritative server locally maintains a difficulty cycle, and after the cycle ends, the difficulty value is adjusted according to the number of requests to complete the public key publication in the previous cycle, in order to limit the amount of computation required for clients to find proof of work when attempting to publish a public key.
[0021] Optionally, adjusting the difficulty value based on the number of public key publication requests completed in the previous period specifically includes: increasing the difficulty when the number of completed publications increases; decreasing the difficulty when the number of completed publications decreases; and keeping the difficulty unchanged when the number of completed publications is the same.
[0022] Optionally, the difficulty of the initial difficulty period takes effect based on a pre-configured value.
[0023] Secondly, an open public key distribution device based on DNS and proof-of-work includes:
[0024] The request receiving module is used to receive authoritative DNS requests sent by the client; the authoritative DNS request is of type pubkey and encapsulates an opt record of type keyex in the authoritative DNS request;
[0025] The domain name check module is used to check whether the pubkey record of the domain name exists according to the authoritative DNS request, and return the check result to the client; the check result encapsulates the opt record of type keyex; after receiving the check result, the client determines whether the domain name is available according to the opt record of type keyex in the check result. If the domain name is available, the client calculates the proof of work that meets the requirements according to the requirements, and re-initiates the authoritative DNS request to the authoritative server.
[0026] The proof-of-work verification module is used to receive the authoritative DNS request resent by the client and verify whether the proof-of-work meets the conditions.
[0027] If the proof of work does not meet the requirements, the verification result will be returned to the client.
[0028] If the proof-of-work condition is met, the client's public key is encapsulated into a pubkey type record and added to the local authoritative database. A DNS response with a noerror code is returned to the client. The response contains a pubkey type record in the answer segment and encapsulates an opt type record of keyex. After receiving the response, the client confirms whether the public key has been correctly published based on the answer segment in the response.
[0029] Thirdly, a computer device includes a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of an open public key distribution method based on DNS and proof-of-work.
[0030] Compared with the prior art, this application has at least the following beneficial effects:
[0031] This application provides an open public key distribution method based on DNS and proof-of-work. The method involves receiving an authoritative DNS request from a client; checking the existence of a pubkey record for a domain name based on the authoritative DNS request and returning the check result to the client; upon receiving the check result, the client determines the domain name's availability based on the keyex type opt record in the check result; if the domain name is available, the client calculates a valid proof-of-work and resends an authoritative DNS request to the authoritative server; the client receives the resent authoritative DNS request and verifies whether the proof-of-work meets the conditions; if it does not meet the conditions, the verification result is returned to the client; if the proof-of-work meets the conditions, the client's public key is encapsulated into a pubkey type record and added to the local authoritative database, and a DNS response with a noerror code is returned to the client. This open public key distribution method based on DNS and proof-of-work provides a lightweight and publicly available solution for public key distribution using the common network infrastructure DNS system, making public key distribution more flexible and reliable, and reducing time and economic costs. Attached Figure Description
[0032] To more intuitively illustrate the prior art and this application, exemplary drawings are provided below. It should be understood that the specific shapes and structures shown in the drawings should not generally be regarded as limiting conditions for implementing this application; for example, based on the technical concept disclosed in this application and the exemplary drawings, those skilled in the art are able to easily make conventional adjustments or further optimizations to the addition / reduction / classification, specific shapes, positional relationships, connection methods, size ratios, etc. of certain units (components).
[0033] Figure 1 This is a flowchart of an open public key publishing method based on DNS and proof-of-work, provided in Embodiment 1 of this application. Detailed Implementation
[0034] The present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0035] In the description of this application: unless otherwise stated, "a plurality of" means two or more. The terms "first," "second," "third," etc., in this application are intended to distinguish the objects referred to and do not have any special meaning in terms of technical connotation (e.g., they should not be construed as an emphasis on importance or order). Expressions such as "comprising," "including," and "having" also mean "not limited to" (certain units, components, materials, steps, etc.).
[0036] The terms used in this application, such as "upper," "lower," "left," "right," and "middle," are generally used to indicate the general relative positional relationship for the purpose of intuitive understanding by referring to the accompanying drawings, and are not absolute limitations on the positional relationship in the actual product.
[0037] Example 1
[0038] Please see Figure 1 This embodiment provides an open public key distribution method based on DNS and proof-of-work. This method is applied to an authoritative server and includes:
[0039] S1: Receive authoritative DNS requests sent by the client; the authoritative DNS request is of type pubkey and contains an opt record of type keyex.
[0040] Specifically, in this embodiment, the authoritative server and the recursive server agree on a custom pseudo-resource record type (opt), naming this opt record as the keyex type, to provide support for extended protocols for public key distribution. Simultaneously, a custom DNS record type, named pubkey, needs to be added to the authoritative data in the DNS authoritative server to store public key information.
[0041] The opt setting for the keyex type includes the following fields:
[0042] Field A: Client / server identifier, with a value of 0 for the client and 1 for the server;
[0043] Field B: Opcode, with a value range of 0, 1, and 2, representing different meanings for the client or server;
[0044] Field C: Random code / nonce value. If the value of field A is 0, then this field corresponds to the random code; if the value of field A is 1, then this field corresponds to the nonce value. The data length of this field is 32 bytes (256 bits).
[0045] Field D: Matching rule, valid only when the value of field A is 0, with a value range of 1 to 256, used to instruct the client to calculate the target value to search for; when the value of field A is 1, it is filled with 0.
[0046] Field E: Remaining validity time of the random code, corresponding to the remaining validity time of the random code in field C, in seconds.
[0047] Field F: The submitted public key data, which is only valid when the value of field A is 0. It contains a public key data length and the specific public key data (the public key itself needs to carry necessary information such as the algorithm and public key value, but this is not limited in this embodiment).
[0048] G field: Signature data. Some workflows require data to be signed, and this field is used to store the signature.
[0049] Therefore, when a client wants to publish its public key to the authoritative data of an authoritative server, it will send an authoritative DNS request to the corresponding authoritative server, querying the domain name it wishes to use as its identity identifier. For example, if it wants to use alice.a.com as its identity identifier in the a.com zone, the request domain name is alice.a.com, and the request type is pubkey. Simultaneously, it needs to encapsulate an opt record of type keyex in the request, where field A is filled with 0, field B is filled with 0, all 32 bytes of field C are filled with 0, and fields D, E, F, and G are all filled with 0.
[0050] S2: Check if the pubkey record of the domain exists according to the authoritative DNS request, and return the check result to the client; the check result contains an opt record of type keyex; after receiving the check result, the client determines whether the domain is available according to the opt record of type keyex in the check result. If the domain is available, calculate the proof of work that meets the requirements according to the requirements, and re-send the authoritative DNS request to the authoritative server.
[0051] Specifically, after receiving an authoritative DNS request, the authoritative server will confirm that the client wants to publish its public key to the authoritative data of this server, then check whether the domain's pubkey record exists according to the authoritative DNS request, and return the check result to the client.
[0052] The process of checking the existence of a domain's pubkey record according to an authoritative DNS request and returning the result to the client includes: First, checking if a pubkey record for the domain alice.a.com already exists in the local zone. If it already exists, the request cannot be received, and a "refused" result is returned, encapsulated in a keyex type "opt" and returned to the client. In this case, field A of the keyex is filled with 1, field B with 2, and all other fields with 0. If the pubkey record for the domain does not exist, a "refused" result is returned, encapsulated in a keyex type "opt" and returned to the client. In this case, field A of the keyex is filled with 1, field B with 0, field C with the random code of the current difficulty period, field D with the matching rule value of the difficulty value for this period according to the ladder table (the higher the difficulty, the larger this value), field E with the remaining time of the current period, and fields F and G with 0.
[0053] After receiving the server's response, the client uses field B of the keyex to determine whether further processing is required. If field B's value is 2, it indicates that the domain name is unavailable and cannot be published using this domain name, so no further processing is needed; if field B's value is 0, it indicates that the domain name is available, and proof of work is required.
[0054] The specific steps for calculating the required proof-of-work involve: first, concatenating the requested domain name, the random code provided by the server, and a nonce value in sequence as input; then, calculating the hash value using the SHA-256 algorithm. During the calculation, the nonce value can be incremented starting from 0. After calculating the hash value, it needs to be verified against the matching rules provided by the authoritative server to confirm compliance. If the matching rule is a value n, it means that a hash value meeting the requirements must have its first n bits set to 0. Therefore, the larger the matching rule value, the stricter the requirements. This process is typically an exhaustive search, continuously modifying the nonce value to find a satisfying nonce. The larger the matching rule value, the more time-consuming this process will be.
[0055] Once a matching nonce value is found, the client will re-initiate the previous query and simultaneously encapsulate a keyex record. In the keyex record, field A is filled with 0, field B with 1, field C with the nonce value, fields D and E with 0, field F with the public key data to be published, and field G with 0.
[0056] S3: Receive the authoritative DNS request resent by the client and verify whether the proof-of-work condition is met;
[0057] After the authoritative server receives the resent request from the client, it will verify whether the nonce value meets the conditions. Specifically, this includes: concatenating the requested domain name, the random code for this period, and the nonce value in sequence, calculating the hash value, and confirming whether the hash value meets the conditions.
[0058] S4: If the proof of work does not meet the conditions, the verification result will be returned to the client;
[0059] Specifically, if the conditions are not met, a verification result will be returned to the client. The verification result contains a keyex type opt record. At this time, field A of the keyex type opt record is filled with 1, field B is filled with 0, field C is filled with the random code of the current difficulty period, field D is filled with the matching rule value of the difficulty value of this period according to the ladder table, field E is filled with the remaining time of this period, and fields F and G are filled with 0.
[0060] S5: If the proof-of-work condition is met, the client's public key is encapsulated into a pubkey type record and added to the local authoritative data. A DNS response with a noerror code is returned to the client. The response contains a pubkey type record in the answer segment and encapsulates an opt type record in the keyex segment. After receiving the response, the client confirms whether the public key has been correctly published based on the answer segment in the response.
[0061] Specifically, if the conditions are met, the authoritative server will first encapsulate the client's public key into a pubkey type record, add it to the authoritative data on the local machine, and then return a DNS response code of noerror. The answer segment will be filled with a pubkey type record and encapsulated with keyex, where field A is filled with 1, field B is filled with 1, and the remaining fields are filled with 0, indicating that the client's public key has been successfully published.
[0062] After receiving a successful response, the client can compare and confirm the information with the records in the answer section.
[0063] In the open public key publishing method based on DNS and proof-of-work provided in this embodiment, after the client's public key is successfully published for the first time, it can apply to change the public key through a request signed with its own private key, specifically including:
[0064] S6: Receive public key update requests sent by the client; the public key update request contains its own private key signature;
[0065] More specifically, the client initiates a pubkey type request for the domain where the public key is located, and encapsulates an opt record of type keyex. In the opt record of type keyex: field A is filled with 0, field B is filled with 2, fields C, D, and E are filled with 0, field F is filled with the new public key to be published, and field G is filled with the signature of this new public key.
[0066] S7: Verify the validity of your own private key signature; if invalid, return a refused result; if valid, update the pubkey type data in the authoritative data and return the corresponding response packet for successful publication.
[0067] More specifically, after receiving a public key update request, the authoritative server verifies the validity of the signature. If invalid, it returns a "refused" result and encapsulates an "opt" record of type "keyex". In the "opt" record of type "keyex", field A is filled with 1, field B is filled with 0, and all other fields are filled with 0. If the signature is valid, it updates the data of type "pubkey" in the authoritative database and returns the same response packet corresponding to the successful publication mentioned in point 8, indicating that the public key update was successful.
[0068] Once the public key is successfully published, third parties can retrieve the public key information it stores by querying the pubkey type of the corresponding domain.
[0069] This embodiment provides an open public key distribution method based on DNS and Proof-of-Work, which further includes: an authoritative server maintaining a difficulty period locally, measured in seconds. After each period, the difficulty value is adjusted based on the number of public key distribution requests completed in the previous period, limiting the computational load required for clients to find the Proof-of-Work (PoW) when attempting to distribute a public key. The difficulty increases when the number of completed distributions increases; decreases when the number of completed distributions decreases; and remains unchanged when the number of completed distributions is the same. The initial difficulty period is set according to a pre-configured value. Simultaneously, a 32-byte random code is generated for each difficulty period and subsequently provided to clients.
[0070] This embodiment provides an open public key distribution method based on DNS and proof-of-work. It can utilize the common network infrastructure DNS system to provide a lightweight and publicly available solution for public key distribution, making the public key distribution method more flexible and reliable, and reducing time and economic costs.
[0071] Example 2
[0072] This embodiment provides an open public key distribution device based on DNS and proof-of-work, including:
[0073] The request receiving module is used to receive authoritative DNS requests sent by the client; the authoritative DNS request is of type pubkey and encapsulates an opt record of type keyex in the authoritative DNS request;
[0074] The domain name check module is used to check whether the pubkey record of the domain name exists according to the authoritative DNS request, and return the check result to the client; the check result encapsulates the opt record of type keyex; after receiving the check result, the client determines whether the domain name is available according to the opt record of type keyex in the check result. If the domain name is available, the client calculates the proof of work that meets the requirements according to the requirements, and re-initiates the authoritative DNS request to the authoritative server.
[0075] The proof-of-work verification module is used to receive the authoritative DNS request resent by the client and verify whether the proof-of-work meets the conditions.
[0076] If the proof of work does not meet the requirements, the verification result will be returned to the client.
[0077] If the proof-of-work condition is met, the client's public key is encapsulated into a pubkey type record and added to the local authoritative database. A DNS response with a noerror code is returned to the client. The response contains a pubkey type record in the answer segment and encapsulates an opt type record of keyex. After receiving the response, the client confirms whether the public key has been correctly published based on the answer segment in the response.
[0078] For details on the specific implementation of each module in an open public key distribution device based on DNS and proof-of-work, please refer to the above description of the limitations of an open public key distribution method based on DNS and proof-of-work, which will not be repeated here.
[0079] Example 3
[0080] This embodiment provides a computer device, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of an open public key distribution method based on DNS and proof-of-work.
[0081] The technical features of the above embodiments can be combined in any way (as long as there is no contradiction in the combination of these technical features). For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described; these embodiments not explicitly written should also be considered to be within the scope of this specification.
Claims
1. A method for publishing open public keys based on DNS and proof-of-work, characterized in that, The method is applied to an authoritative server and includes: Step 1: Receive the authoritative DNS request sent by the client; the authoritative DNS request is of type pubkey and encapsulates an opt record of type keyex in the authoritative DNS request; Step 2: Check if the pubkey record of the domain exists according to the authoritative DNS request, and return the check result to the client; the check result encapsulates an opt record of type keyex; after receiving the check result, the client determines whether the domain is available according to the opt record of type keyex in the check result. If the domain is available, calculate the proof of work that meets the requirements according to the requirements, and re-initiate the authoritative DNS request to the authoritative server. Step 3: Receive the authoritative DNS request resent by the client and verify whether the proof-of-work condition is met; Step 4: If the proof of work does not meet the conditions, the verification result will be returned to the client; Step 5: If the proof-of-work condition is met, the client's public key is encapsulated into a pubkey type record and added to the local authoritative data. A DNS response with a noerror code is returned to the client. The response contains a pubkey type record in the answer segment and encapsulates an opt type record of keyex. After receiving the response, the client confirms whether the public key has been correctly published based on the answer segment in the response.
2. The open public key distribution method based on DNS and proof-of-work according to claim 1, characterized in that, The opt record of type keyex includes: client or server identifier, opcode, random code or nonce value, matching rule, remaining validity time of random code, submitted public key data and signature data.
3. The open public key distribution method based on DNS and proof-of-work according to claim 2, characterized in that, In step 2, the calculation of the proof of work that meets the requirements specifically includes: concatenating the domain name requested by oneself, the random code provided by the authoritative server and a nonce value in sequence as input, then calculating the hash value according to the SHA-256 algorithm, and confirming whether the hash value meets the requirements according to the matching rules given by the authoritative server.
4. The open public key distribution method based on DNS and proof-of-work according to claim 2, characterized in that, Step 3, specifically, involves concatenating the request domain name, the random code for the current period, and the nonce value in sequence, calculating the hash value, and confirming whether the conditions are met based on the hash value.
5. The open public key distribution method based on DNS and proof-of-work according to claim 1, characterized in that, Also includes: Receive public key update requests sent by clients; The public key update request contains its own private key signature; Verify the validity of the private key signature; if invalid, return a refused result; if valid, update the pubkey type data in the authoritative data and return the corresponding response packet for successful publication.
6. The open public key distribution method based on DNS and proof-of-work according to claim 1, characterized in that, Also includes: The authoritative server maintains a difficulty cycle locally. After the cycle ends, the difficulty value is adjusted based on the number of requests that completed the public key publication in the previous cycle. This is used to limit the amount of computation required for clients to find the proof-of-work when attempting to publish a public key.
7. The open public key distribution method based on DNS and proof-of-work according to claim 6, characterized in that, The method of adjusting the difficulty value based on the number of public key publication requests completed in the previous cycle specifically includes: increasing the difficulty when the number of completed publications increases; decreasing the difficulty when the number of completed publications decreases; and keeping the difficulty unchanged when the number of completed publications is the same.
8. The open public key distribution method based on DNS and proof-of-work according to claim 6, characterized in that, The initial difficulty level for each cycle is determined based on pre-configured values.
9. An open public key distribution device based on DNS and proof-of-work, characterized in that, include: The request receiving module is used to receive authoritative DNS requests sent by clients; The authoritative DNS request is of type pubkey, and the authoritative DNS request encapsulates an opt record of type keyex. The domain name check module is used to check whether the pubkey record of the domain name exists based on the authoritative DNS request, and return the check result to the client; The inspection results contain opt records of type keyex; After receiving the inspection result, the client determines whether the domain name is available based on the opt record of type keyex in the inspection result. If the domain name is available, the client calculates the proof of work that meets the requirements and re-initiates an authoritative DNS request to the authoritative server. The proof-of-work verification module is used to receive the authoritative DNS request resent by the client and verify whether the proof-of-work meets the conditions. If the proof of work does not meet the requirements, the verification result will be returned to the client. If the proof-of-work condition is met, the client's public key is encapsulated into a pubkey type record and added to the local authoritative database. A DNS response with a noerror code is returned to the client. The response contains a pubkey type record in the answer segment and encapsulates an opt type record of keyex. After receiving the response, the client confirms whether the public key has been correctly published based on the answer segment in the response.
10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.