DNS request shunting method based on point-to-point network

Abstract

The invention discloses a DNS (Domain Name Server) request shunting method based on a peer-to-peer network. According to the method, part of clients can voluntarily join an auxiliary server list when initiating requests to a recursive server through client protocol extension. And the recursive server dynamically adjusts a distribution strategy according to a load threshold, distributes a part of requests to the auxiliary server, and maintains an auxiliary server list to ensure load balance at the same time. And when the auxiliary server provides a DNS cache service, the data reliability is ensured through a public key verification mechanism. According to the method, idle resources are reasonably utilized, so that the pressure of a recursive server is effectively relieved, the cost is reduced, the overall availability and stability of the system are improved, and the method is particularly suitable for scenes with relatively large request quantity fluctuation.

Description

Technical Field

[0001] The present invention relates to the field of information technology, and in particular to a DNS request diversion method based on a point-to-point network. Background Art

[0002] A DNS recursive resolver is a special DNS server that, after receiving a query request from a client, completes the entire domain name resolution process on behalf of the client until the final IP address is obtained and returned to the client.

[0003] During operation, a DNS recursive server may face the problem of large request volume or large fluctuation in request volume. The conventional solution is to add backup nodes to the server cluster to alleviate the overall query request pressure. However, such a solution will generate additional equipment, bandwidth and maintenance costs. In an environment where there are significant peaks and troughs in the request volume, such a solution may cause various resources to be idle during the traffic trough period, resulting in serious waste. Summary of the invention

[0004] Based on this, an embodiment of the present application provides a DNS request diversion method based on a point-to-point network. This method dynamically adjusts the architecture of the relevant network to improve the availability of the DNS server, achieve rational use of resources, and reduce various costs.

[0005] In a first aspect, a method for DNS request offloading based on a peer-to-peer network is provided, the method comprising:

[0006] The DNS module in the client is extended to attach a partner pseudo-resource record when initiating a request to the recursive server. The request includes whether the server is willing to become an auxiliary server. If the server is willing to become an auxiliary server, the specific fields in the partner pseudo-resource record are filled according to the rules.

[0007] After receiving the request, the recursive server decides whether to add the client as an auxiliary server according to the auxiliary server list. The auxiliary server carries the partner record when making a request to the recursive server.

[0008] The recursive server sets a load threshold T1. When the traffic exceeds the threshold, forced diversion is enabled. Requests without partner records are directly rejected and directed to the auxiliary server. Requests to the auxiliary server with records are processed normally.

[0009] The auxiliary server sets a load threshold T2. When the traffic exceeds the threshold, it decides whether to accept the request based on the history list.

[0010] Optionally, a partner pseudo-resource record is attached when making a request to the recursive server. The partner pseudo-resource record contains the following fields:

[0011] Field A: Operator ID. A value of 0 indicates that the current operation comes from a client that supports the partner-related protocol extension. A value of 1 indicates that the current operation comes from a server that supports this protocol extension. A value of 2 indicates that the client has joined the auxiliary server list.

[0012] Field B: Execution result, used to identify the execution result of the request corresponding to this protocol extension. 0 represents successful execution and 1 represents failed execution.

[0013] Field C: The number of active visitors, which will only be filled with non-zero values ​​by packets generated by the server;

[0014] Field D: Active visitor list, a list of IP addresses that will only be populated by the server;

[0015] Field E: Public key record, the public key encapsulated in this opt record for subsequent verification of data validity; the field will contain a length prefix that defines the length of the public key record that is actually encapsulated later. If there is no public key, the length is filled with 0.

[0016] Optionally, the request includes whether the server is willing to become an auxiliary server. If the server is willing to become an auxiliary server, specific fields in the partner pseudo resource record are filled according to the rules, including:

[0017] If the client is willing to become an auxiliary server, it will fill the partner record fields A, B, and C with 0 in the request, leave field D empty, describe the length of field E as 0, and do not fill in the public key record value.

[0018] Optionally, after receiving the request, the recursive server decides whether to add the client as an auxiliary server according to the auxiliary server list, including:

[0019] After receiving such a request, the recursive server will check whether the auxiliary server list it maintains has reached the upper limit. If not, the client will be added to the list and the relevant fields of the partner record will be updated in the response. Field A will be filled with 1, Field B will be filled with 0 or 1 depending on whether the addition is successful, Field C will be filled with the actual number of auxiliary servers, and the public key information will be filled in Field E.

[0020] Optionally, when the traffic exceeds the threshold, forced diversion is enabled. Requests without partner records are directly rejected and directed to the auxiliary server, while requests to the auxiliary server with records are processed normally, including:

[0021] For ordinary client requests without partner records, the recursive server will directly reply with rcode as REFUSED and carry partner records, which include auxiliary server list and public key information, to guide the client to initiate requests to the auxiliary servers.

[0022] For auxiliary server requests that have started diversion work, the recursive server will not be restricted by threshold T1 and will process them directly; at the same time, the recursive server will also regularly maintain the auxiliary server list and screen out inactive auxiliary servers.

[0023] Optionally, when the traffic exceeds the threshold, decide whether to accept the request based on the history list, including:

[0024] Before sending a response to the auxiliary server, the recursive server signs the relevant record data with the private key and binds it to the corresponding cache. When responding, it returns the signed record together with the ordinary record.

[0025] After receiving it, the auxiliary server verifies the PARTNERRRSIG corresponding to the ordinary DNS record through the public key. If the verification is successful, the response result is reliable, otherwise it needs to continue to try other servers.

[0026] In a second aspect, a DNS request diversion system based on a peer-to-peer network is provided, the system comprising:

[0027] The client is used to extend the DNS module protocol and attach a partner pseudo-resource record when initiating a request to the recursive server. The request includes whether to volunteer to become an auxiliary server. If so, the specific fields in the partner pseudo-resource record are filled in according to the rules. After becoming an auxiliary server, a load threshold T2 is set. When the traffic exceeds the threshold, whether to accept the request is determined according to the history list.

[0028] The recursive server is used to decide whether to add the client as an auxiliary server according to the auxiliary server list after receiving the request; wherein, the auxiliary server carries the partner record when requesting the recursive server; a load threshold T1 is set, and forced diversion is enabled when the traffic exceeds the threshold. Requests without partner records are directly rejected and directed to the auxiliary server, and requests to the auxiliary server carrying records are processed normally.

[0029] In a third aspect, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the DNS request diversion method described in any one of the first aspects is implemented.

[0030] In a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the DNS request diversion method described in any one of the first aspects is implemented.

[0031] In a fifth aspect, a computer program product is provided, including a computer program / instruction, which, when executed by a processor, implements the DNS request diversion method described in any one of the first aspects.

[0032] The beneficial effects brought by the technical solution provided by the embodiment of the present application include at least:

[0033] (1) By converting some clients into auxiliary servers, potential idle resources can be rationally utilized, avoiding the phenomenon of idle resources wasting during traffic troughs, while reducing the equipment, bandwidth and maintenance costs caused by adding spare nodes.

[0034] (2) In a high-request environment, the dynamic diversion strategy and the participation of auxiliary servers effectively alleviate the pressure on the DNS recursive server, improve the overall availability of the system, and ensure that users can still obtain fast and stable DNS resolution services in high-traffic scenarios.

[0035] (3) Through the incentive mechanism of randomly selecting diversion servers and historical diversion server lists, a balanced load distribution is achieved, avoiding overload of a single server. At the same time, clients are encouraged to actively participate in diversion, thereby improving the overall efficiency and stability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the implementation methods of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for the implementation methods or the description of the prior art. Obviously, the drawings in the following description are only exemplary, and for ordinary technicians in this field, other implementation drawings can be derived from the provided drawings without creative work.

[0037] Figure 1 A flowchart of a method for DNS request diversion based on a peer-to-peer network provided in an embodiment of the present application;

[0038] Figure 2 A block diagram of a DNS request diversion system based on a peer-to-peer network provided in an embodiment of the present application;

[0039] Figure 3 A schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0040] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0041] In the description of the present invention, the terms "comprises", "has" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may also include other steps or units that are not explicitly listed but are inherent to these processes, methods, products or apparatuses, or steps or units added based on further optimization schemes conceived by the present invention.

[0042] During operation, a DNS recursive server may face the problem of large request volume or large fluctuation in request volume. The conventional solution is to add backup nodes to the server cluster to alleviate the overall query request pressure. However, such a solution will generate additional equipment, bandwidth and maintenance costs. In an environment where there are significant peaks and troughs in the request volume, such a solution may cause various resources to be idle during the traffic trough period, resulting in serious waste.

[0043] This solution draws on the idea of ​​peer-to-peer networks to optimize and improve the problems involved in the above scenarios. By dynamically adjusting the architecture of related networks, the availability of DNS servers can be improved, resources can be used rationally, and various costs can be reduced.

[0044] The existing solution requires a large investment to ensure the availability of services. This solution has modified the original client / server architecture to allow some clients to have the role of server at the same time, thereby achieving the purpose of diverting requests.

[0045] Please refer to Figure 1 , which shows a flow chart of a DNS request diversion method based on a peer-to-peer network provided by an embodiment of the present application, the purpose of which is to optimize the existing DNS recursive server architecture, improve availability, and reduce various costs. The following steps may be included:

[0046] S1, extend the DNS module in the client and attach the partner pseudo resource record when initiating a request to the recursive server.

[0047] The request includes whether the server is willing to become an auxiliary server. If the server is willing to become an auxiliary server, specific fields in the partner pseudo resource record are filled according to the rules.

[0048] In this step, the client's DNS-related modules need to implement specific protocol extensions so that they can attach a custom partner pseudo-resource record when initiating a request to the recursive server. If the client is willing to become a diversion server, it will fill the partner record fields A, B, and C with 0 in the request, leave field D empty, describe the length of field E as 0, and not fill in the public key record value. After receiving such a request, the recursive server will check whether the auxiliary server list it maintains has reached the upper limit. If not, it will add the client to the list and update the relevant fields of the partner record in the response, such as filling field A with 1, field B with 0 or 1 depending on whether the addition is successful, and field C with the actual number of auxiliary servers. At the same time, the public key information is filled into field E for subsequent use by the client.

[0049] S2: After receiving the request, the recursive server decides whether to add the client as an auxiliary server based on the auxiliary server list.

[0050] Among them, the auxiliary server carries the partner record when making a request to the recursive server.

[0051] In this step, after the client receives the response from the recursive server, it determines whether it has successfully joined the auxiliary server list through field B in the partner record, and saves the auxiliary server list and public key information. Once it becomes an auxiliary server, the client can provide DNS resolution services to other clients, mainly as a DNS cache server for the original recursive server, diverting requests that can hit the cache. When making subsequent requests to the recursive server, field A in the partner record will be filled with 2, indicating its auxiliary server identity. If the auxiliary server is no longer included in the primary and auxiliary server list of the recursive server, field B will be used in the response to inform it that its registration information has expired. The auxiliary server needs to adjust its role and degenerate to a client. If it wants to continue to be an auxiliary server, it needs to reapply.

[0052] S3, the recursive server sets the load threshold T1. When the traffic exceeds the threshold, forced diversion is enabled. Requests without partner records are directly rejected and directed to the auxiliary server, while requests to the auxiliary server with records are processed normally.

[0053] In this step, the recursive server will set a load threshold T1. When the traffic pressure reaches this threshold, the forced diversion strategy will be enabled. For ordinary client requests that do not carry partner records, the recursive server will directly reply with the result that rcode is REFUSED and carry a partner record, which contains a list of auxiliary servers and public key information, etc., to guide the client to initiate a request to the diversion server. For requests that carry partner records and field A is 2, that is, requests from auxiliary servers that have started diversion work, the recursive server will not be restricted by the threshold T1 and will process it directly. At the same time, the recursive server will also regularly maintain the auxiliary server list, screen out inactive auxiliary servers, and give new servers a chance to join.

[0054] S4, the auxiliary server sets a load threshold T2. When the traffic exceeds the threshold, it decides whether to accept the request based on the history list.

[0055] In this step, the auxiliary server itself also has a load threshold T2. When the load is lower than T2, it can serve any client. When it is higher than T2, it will refer to the historical diversion server list to decide whether to accept the request. If the list contains the client address, it will be accepted. Otherwise, it will return the REFUSED result or probabilistic return according to the strategy to relieve the pressure. In addition, since there is no pre-established trust relationship between the client and the diversion server, the security mechanism can be set as needed. If you are concerned about trust issues, the recursive server needs to sign the relevant record data with a private key before sending a response to the auxiliary server, and bind it to the corresponding cache. When responding, the signed record and the ordinary record will be returned together. After receiving it, the auxiliary server can verify the PARTNERRRSIG corresponding to the ordinary DNS record through the public key. If the verification is successful, the response result is reliable, otherwise it is necessary to continue to try other servers.

[0056] In an optional embodiment of the present application, the method can also be expanded into the following specific implementation process:

[0057] This solution transforms the original client / server architecture to allow some clients to have the role of server at the same time, thus achieving the purpose of splitting requests. The key points of the solution are as follows:

[0058] (1) The DNS-related modules of the client where the application is located need to implement certain protocol extensions.

[0059] (2) A load threshold T1 is set for the DNS recursive server. For example, the threshold is set when the actual request volume reaches 50% of the total processing capacity by quantifying the performance based on qps.

[0060] (3) Define a DNS pseudo resource record (opt) named partner type. This type contains the following fields:

[0061] A) Operator ID, a value of 0 indicates that the current operation comes from a client that supports the partner-related protocol extension, a value of 1 indicates that the current operation comes from a server that supports this protocol extension, and a value of 2 indicates that the client has joined the auxiliary server list.

[0062] B) Execution result, which is used to identify the execution result of the request corresponding to this protocol extension. 0 represents successful execution and 1 represents failed execution.

[0063] C) The number of active visitors will only be filled with non-zero values ​​by packets generated by the server.

[0064] D) Active visitor list, a list of IP addresses that will only be populated by the server.

[0065] E) Public key record, the public key encapsulated in this opt record for subsequent verification of data validity. The field will contain a length prefix, which defines the length of the public key record actually encapsulated later. If there is no public key, the length is filled with 0.

[0066] (4) The client sends a request to the recursive server. If the client voluntarily joins the list of diversion servers, it needs to add the encapsulation of the partner pseudo resource record in step 3 to the normal DNS request. Fields A, B, and C are filled with 0, field D is empty, the length of field E is described as 0, and the public key record value is not filled.

[0067] (5) After receiving such a request, the server will check whether the auxiliary server list it maintains has reached the upper limit of the number of registrations. If not, the client will be added to the list and the corresponding data structure will be updated to construct the partner type record. If the upper limit has been reached, no more additions will be made. After the request is processed normally, field A in the partnet record will be filled with 1, and field B will be filled depending on whether the client has been added as an auxiliary server. If the addition is successful, 0 will be filled, otherwise 1 will be filled. Field C will be filled with the actual number of auxiliary servers, field D will be filled with the actual auxiliary server address list, and field E will be filled with the relevant public key information of this recursive server.

[0068] (6) After receiving the response, the client can determine whether it has been added to the auxiliary server list through field B in the partner record. In addition, the client will also save the address in the auxiliary server list and the public key information of the recursive server locally for future use.

[0069] (7) After the client confirms that it has become a secondary server, it can subsequently provide DNS resolution services to other clients. However, its role is mainly the DNS cache server of the original recursive server, mainly used to divert some requests that can hit the cache.

[0070] (8) When the client subsequently makes a request to the recursive server, field A in the partner record will be filled with 2, indicating that the request is initiated by the auxiliary server. When this auxiliary server receives DNS requests from other clients, it will first search from the cache. If there is no cache, it will initiate a request to the original recursive server and cache the result. When initiating a query to the recursive server, field A is filled with 2, indicating that it is performing diversion work. If this auxiliary server is no longer included in the primary and secondary server list on the server side, the recursive server will fill in 1 in field B in the partner record while replying a normal DNS response, indicating that its auxiliary server registration information has expired. When the auxiliary server receives this result, it also needs to adjust its role and degenerate to a client in subsequent requests. If you plan to continue to be called an auxiliary server, you need to encapsulate the partner record in step 4 again to apply for it, and pay attention to the application results.

[0071] (9) The recursive server will maintain the auxiliary server list, regularly screen inactive auxiliary servers (those that do not continue to provide diversion services), and eliminate a certain proportion of servers to give new servers a chance to be registered.

[0072] (10) When the traffic pressure of the recursive server reaches the threshold mentioned in step 2, the forced diversion strategy will be enabled. At this time, the request from the client that does not carry the partner record (ordinary client that does not want to become an auxiliary server) will be skipped by the recursive server. The server will directly reply with the result of rcode being REFUSED and carrying the partner record. Field A is filled with 1, field B is filled with 0, field C is filled with the actual number of auxiliary servers, field D is filled with the auxiliary server list, and field E is filled with the public key information of the recursive server. Requests that carry a partner record and have a value of 2 in field A represent that the client declares that it has started diversion. After the server verifies that it is indeed in the current auxiliary server list, it will not be affected by threshold T1 and will directly process the request it sent.

[0073] (11) After receiving the response result of step 10, the client can know that the reason for the server's rejection is that the pressure is too high and it needs to be diverted to other servers. The client will save the server list and public key information in the partner field locally. For ordinary clients and clients applying to become auxiliary servers, when saving the server list, such a server list may already exist locally, so two server lists need to be saved locally at this time, one is the currently valid server list, and the other is the top server list ranked by the total number of appearances in the history list. The number of servers in this list needs to be larger than the current valid server list, which is used to record the server list that may have continuously performed the diversion task (the role is related to the incentive measures mentioned later).

[0074] (12) Because the recursive server gives a prompt that diversion is needed, the client will start to initiate a DNS request to the diversion server. Since there may be many diversion servers, the selection method is set to random selection to achieve load balancing as much as possible. In the process of requesting the diversion server, various failures may be encountered. At this time, a new round of random selection can be started and a request can be initiated. The termination condition of this request process is to get a normal DNS response, or the number of retries reaches the upper limit set by its own policy.

[0075] (13) The auxiliary server that provides the server for the client also has a load threshold T2. When its own load is lower than T2, it can provide services to any client. However, when the load is higher than T2, it will check the historical diversion server list mentioned in step 11. If the list contains the client address, it will directly accept and process the client's request. If the address is not included, it will directly return the REFUSED result or probabilistically return the REFUSED result according to the strategy to relieve its own pressure.

[0076] (14) The method of examining the historical offload server list can be understood as an incentive measure to encourage the client to actively participate in offload so that when it no longer participates in offload at some point, it can also be served by other offload servers first.

[0077] (15) Since there is a trust relationship between the actual client and the recursive server, but the client does not have pre-established trust in the diversion server, a security mechanism needs to be set up as needed. If such trust issues are not involved or are not of concern, the length of field E in all processes in the partner record needs to be filled with 0, and the public key record part needs to be left blank. If trust issues are a concern, the recursive server needs to sign the relevant record data with its own private key before sending a response to the auxiliary server, and bind it to the corresponding cache. When responding, the signed record and the ordinary record are returned to the auxiliary server together. In order to avoid conflicts between the signed record and the public DNSSEC-related record RRSIG, this scheme defines a private signature record type PARTNERRRSIG related to this protocol extension to ensure that it can exist at the same time as RRSIG.

[0078] (16) Because the client actually extracts the encapsulated public key (which can be a DNSKEY record type or other form) from field E of the partner record returned by the recursive server and saves it locally. After getting the DNS record from the offload server with no trust relationship, the PARTNERRRSIG corresponding to the ordinary DNS record can be verified by the public key. If the verification is successful, it means that the response result is reliable, otherwise it is necessary to continue trying other servers.

[0079] From the above, it can be seen that this application rationally utilizes potential idle resources and improves the availability of the entire DNS service.

[0080] Please refer to Figure 2 , which shows a block diagram of a DNS request diversion system based on a peer-to-peer network provided by an embodiment of the present application. Figure 2 As shown, the system may include:

[0081] The client is used to extend the DNS module protocol and attach a partner pseudo-resource record when initiating a request to the recursive server. The request includes whether to volunteer to become an auxiliary server. If so, the specific fields in the partner pseudo-resource record are filled in according to the rules. After becoming an auxiliary server, a load threshold T2 is set. When the traffic exceeds the threshold, whether to accept the request is determined according to the history list.

[0082] The recursive server is used to decide whether to add the client as an auxiliary server according to the auxiliary server list after receiving the request; wherein, the auxiliary server carries the partner record when requesting the recursive server; a load threshold T1 is set, and forced diversion is enabled when the traffic exceeds the threshold. Requests without partner records are directly rejected and directed to the auxiliary server, and requests to the auxiliary server carrying records are processed normally.

[0083] For the specific definition of the DNS request diversion system based on a peer-to-peer network, please refer to the definition of the DNS request diversion method based on a peer-to-peer network above, which will not be repeated here. Each module in the above-mentioned DNS request diversion system based on a peer-to-peer network can be implemented in whole or in part by software, hardware and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0084] In one embodiment, an electronic device is provided. The electronic device may be a computer, and its internal structure diagram may be as follows: Figure 3 As shown. The electronic device includes a processor, a memory and a network interface connected via a system bus. The processor of the device is used to provide computing and control capabilities. The memory of the device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to divert data based on a DNS request of a point-to-point network. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a DNS request diversion method based on a point-to-point network is implemented.

[0085] Those skilled in the art will understand that Figure 3 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0086] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which involves all or part of the processes in the above-mentioned embodiment method.

[0087] In one embodiment, a computer program product is also provided, including a computer program / instruction, which involves all or part of the process in the above embodiment method.

[0088] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing related hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in M ​​forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (SyMchliMk) DRAM (SLDRAM), memory bus (RaMbus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0089] The technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0090] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be construed as limiting the scope of the patent application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent application shall be subject to the attached claims.

Claims

1. A DNS request offloading method based on a peer-to-peer network, characterized in that: The method comprises: The DNS module in the client is extended to attach a partner pseudo-resource record when initiating a request to the recursive server. The request includes whether the server is willing to become an auxiliary server. If the server is willing to become an auxiliary server, the specific fields in the partner pseudo-resource record are filled according to the rules. After receiving the request, the recursive server decides whether to add the client as an auxiliary server according to the auxiliary server list. The auxiliary server carries the partner record when making a request to the recursive server. The recursive server sets a load threshold T1. When the traffic exceeds the threshold, forced diversion is enabled. Requests without partner records are directly rejected and directed to the auxiliary server. Requests to the auxiliary server with records are processed normally. The auxiliary server sets a load threshold T2. When the traffic exceeds the threshold, it decides whether to accept the request based on the history list.

2. The DNS request diversion method according to claim 1, characterized in that: When making a request to a recursive server, the partner pseudo-resource record is attached. The partner pseudo-resource record contains the following fields: Field A: Operator ID. A value of 0 indicates that the current operation comes from a client that supports the partner-related protocol extension. A value of 1 indicates that the current operation comes from a server that supports this protocol extension. A value of 2 indicates that the client has joined the auxiliary server list. Field B: Execution result, used to identify the execution result of the request corresponding to this protocol extension. 0 represents successful execution and 1 represents failed execution. Field C: The number of active visitors, which will only be filled with non-zero values ​​by packets generated by the server; Field D: Active visitor list, a list of IP addresses that will only be populated by the server; Field E: Public key record, the public key encapsulated in this opt record for subsequent verification of data validity; the field will contain a length prefix that defines the length of the public key record that is actually encapsulated later. If there is no public key, the length is filled with 0.

3. The DNS request diversion method according to claim 2, characterized in that: The request includes whether the server is willing to become an auxiliary server. If the server is willing to become an auxiliary server, the specific fields in the partner pseudo resource record are filled according to the rules, including: If the client is willing to become an auxiliary server, it will fill the partner record fields A, B, and C with 0 in the request, leave field D empty, describe the length of field E as 0, and do not fill in the public key record value.

4. The DNS request diversion method according to claim 1, characterized in that: After receiving the request, the recursive server decides whether to add the client as an auxiliary server based on the auxiliary server list, including: After receiving such a request, the recursive server will check whether the auxiliary server list it maintains has reached the upper limit. If not, the client will be added to the list and the relevant fields of the partner record will be updated in the response. Field A will be filled with 1, Field B will be filled with 0 or 1 depending on whether the addition is successful, Field C will be filled with the actual number of auxiliary servers, and the public key information will be filled in Field E.

5. The DNS request diversion method according to claim 1, characterized in that: When the traffic exceeds the threshold, forced diversion is enabled. Requests without partner records are directly rejected and directed to the auxiliary server. Requests to the auxiliary server with records are processed normally, including: For ordinary client requests without partner records, the recursive server will directly reply with rcode as REFUSED and carry partner records, which include auxiliary server list and public key information, to guide the client to initiate requests to the auxiliary servers. For auxiliary server requests that have started diversion work, the recursive server will not be restricted by threshold T1 and will process them directly; at the same time, the recursive server will also regularly maintain the auxiliary server list and screen out inactive auxiliary servers.

6. The DNS request diversion method according to claim 1, characterized in that: When the traffic exceeds the threshold, the server decides whether to accept the request based on the history list, including: Before sending a response to the auxiliary server, the recursive server signs the relevant record data with the private key and binds it to the corresponding cache. When responding, it returns the signed record together with the ordinary record. After receiving it, the auxiliary server verifies the PARTNERRRSIG corresponding to the ordinary DNS record through the public key. If the verification is successful, the response result is reliable, otherwise it needs to continue to try other servers.

7. A DNS request diversion system based on a peer-to-peer network, characterized in that: The system comprises: The client is used to extend the DNS module protocol and attach a partner pseudo-resource record when initiating a request to the recursive server. The request includes whether to volunteer to become an auxiliary server. If so, the specific fields in the partner pseudo-resource record are filled in according to the rules. After becoming an auxiliary server, a load threshold T2 is set. When the traffic exceeds the threshold, whether to accept the request is determined according to the history list. The recursive server is used to decide whether to add the client as an auxiliary server according to the auxiliary server list after receiving the request; wherein, the auxiliary server carries the partner record when requesting the recursive server; a load threshold T1 is set, and forced diversion is enabled when the traffic exceeds the threshold. Requests without partner records are directly rejected and directed to the auxiliary server, and requests to the auxiliary server carrying records are processed normally.

8. An electronic device, characterized in that: The method comprises a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images