Dns request processing method, device, system, and computer readable medium

Abstract

This application provides a DNS request processing method, device, system, and computer-readable medium. In this solution, DNS requests are encrypted locally on the user device using a secure DNS client, ensuring the DNS request is encrypted from the moment it is sent from the user device. This effectively prevents privacy information from being stolen or eavesdropped on by service providers of intermediate devices such as routing devices and gateway devices, thus improving the security of the solution. Furthermore, this solution splits the security detection mechanism into two parts: a local security detection is performed on the user device, encrypting and sending only the original DNS requests that pass the local security detection. This blocks queries for insecure domain names before the DNS request is sent, avoiding waste of network resources and improving processing efficiency. Simultaneously, a more comprehensive secondary security detection is performed at the edge node to ensure the accuracy of the security detection and avoid security risks caused by insufficient local detection.

Description

Technical Field

[0001] This application relates to the field of information technology, and in particular to a DNS request processing method, device, system, and computer-readable medium. Background Technology

[0002] The Domain Name System (DNS) is an internet service that maps domain names to IP (Internet Protocol) addresses, making it easier for people to access the internet.

[0003] Applications on user devices typically utilize DNS services when they need to access a specific domain name. The process of handling DNS requests is as follows: Figure 1 As shown, when an application needs to access a target domain name, it first queries the local DNS cache for the IP address corresponding to that domain name. If the address is not found, a DNS request is sent to the DNS request query processing node for further lookup. During this query process, the DNS request is typically transmitted in plaintext using the UDP protocol, which results in poor security and easy leakage of private information. Furthermore, the lack of a domain name-specific security detection mechanism further complicates the security process.

[0004] To address the aforementioned security issues, existing technologies provide a solution for securely detecting and encrypting DNS requests on routing devices, gateway devices, or cloud servers. The processing principle is as follows: Figure 2 As shown. First, while this scheme can encrypt DNS requests to ensure secure data communication between intermediate devices such as routing devices and gateway devices and the DNS server, DNS requests are still transmitted in plaintext between user devices and intermediate devices. Therefore, this scheme still cannot prevent intermediate device service providers from obtaining private information, and its security remains insufficient.

[0005] Secondly, the security checks in this scheme are performed on intermediate devices. This means that regardless of whether the domain name queried in the DNS request is secure, the user device needs to send a DNS request to these intermediate devices for security checks to determine whether to block or allow subsequent processing. Simply put, if the security check results in insecurity, subsequent processing is blocked. Before this, the user device must send the DNS request to the intermediate devices, leading to technical problems such as wasted network resources and reduced efficiency. Summary of the Invention

[0006] One object of this application is to provide a DNS request processing method, apparatus, system, and computer-readable medium to at least solve the problems of insufficient security and low processing efficiency in the DNS query process.

[0007] To achieve the above objectives, some embodiments of this application provide a DNS request processing method, which is applied to a user equipment, the user equipment including a secure DNS client, and the method includes:

[0008] The secure DNS client obtains the original DNS request issued by the application;

[0009] The secure DNS client performs local security checks on the original DNS request;

[0010] If the local security test is passed, the secure DNS client encrypts the original DNS request and generates an encrypted DNS request;

[0011] The secure DNS client sends the encrypted DNS request to the edge node, so that the edge node decrypts the encrypted DNS request to obtain the corresponding original DNS request, performs a second security check on the original DNS request, and requests DNS resolution based on the original DNS request that has passed the second security check.

[0012] Some embodiments of this application also provide another DNS request processing method, which is applied to edge nodes, and the method includes:

[0013] The edge node receives an encrypted DNS request sent by the user equipment's secure DNS client. The encrypted DNS request is generated by the secure DNS client after performing a local security check on the original DNS request issued by the application and encrypting it after passing the local security check.

[0014] The edge node decrypts the encrypted DNS request to obtain the corresponding original DNS request;

[0015] The edge node performs a secondary security check on the original DNS request;

[0016] If the secondary security check passes, the edge node will forward the original DNS request to the DNS server.

[0017] Some embodiments of this application also provide a DNS request processing device, the device being a user equipment, the user equipment including a secure DNS client, the secure DNS client comprising:

[0018] The receiving module is used to obtain the raw DNS requests sent by the application;

[0019] The security detection module is used to perform local security detection on the original DNS request;

[0020] An encryption module is used to encrypt the original DNS request when passing local security checks, and generate an encrypted DNS request;

[0021] The sending module is used to send the encrypted DNS request to the edge node, so that the edge node decrypts the encrypted DNS request to obtain the corresponding original DNS request, performs a secondary security check on the original DNS request, and requests DNS resolution based on the original DNS request that has passed the secondary security check.

[0022] Some embodiments of this application also provide another DNS request processing device, which is an edge node, and the edge node includes:

[0023] The receiving module is used to receive encrypted DNS requests sent by the secure DNS client of the user equipment, wherein the encrypted DNS requests are generated by the secure DNS client through local security testing of the original DNS requests issued by the application and after passing the local security testing.

[0024] The decryption module is used to decrypt the encrypted DNS request and obtain the corresponding original DNS request;

[0025] The security detection module is used to perform a secondary security detection on the original DNS request;

[0026] The sending module is used to forward the original DNS request to the DNS server when the secondary security check is passed.

[0027] Some embodiments of this application also provide a DNS request processing system, including user equipment and edge nodes, wherein,

[0028] The user equipment includes a secure DNS client, which is used to obtain the original DNS request issued by the application; perform local security detection on the original DNS request; if the local security detection passes, encrypt the original DNS request to generate an encrypted DNS request; and send the encrypted DNS request to the edge node.

[0029] The edge node is used to receive encrypted DNS requests sent by the user equipment's secure DNS client; the edge node performs a secondary security check on the original DNS request; if the secondary security check passes, the encrypted DNS request is decrypted to obtain the corresponding original DNS request; and the original DNS request is forwarded to the DNS server.

[0030] Some embodiments of this application also provide a DNS request processing device, the device comprising:

[0031] One or more processors; and

[0032] A memory storing computer program instructions, which, when executed, cause the processor to perform the DNS request processing method.

[0033] Some embodiments of this application also provide a computer-readable medium having computer program instructions stored thereon, which can be executed by a processor to implement the DNS request processing method described above.

[0034] Compared to existing technologies, the DNS request processing scheme provided in this application includes a secure DNS client in the user equipment. During the DNS query process, the user equipment obtains the original DNS request issued by the application through the secure DNS client, performs local security checks on the original DNS request, encrypts the original DNS request that has passed the local security check, generates an encrypted DNS request, and then sends the encrypted DNS request to the edge node so that the edge node can decrypt the encrypted DNS request to obtain the corresponding original DNS request, and performs a second security check on the original DNS request, and requests DNS resolution based on the original DNS request that has passed the second security check. Because the DNS request is encrypted locally on the user device using a secure DNS client, it is encrypted from the moment it is sent from the user device. This effectively prevents the service provider from stealing or eavesdropping on private information through intermediate devices such as routers and gateways, thus improving the security of the solution. Furthermore, this solution splits the security detection mechanism into two parts: a local security check is performed on the user device, encrypting and sending only the original DNS requests that pass the local security check. This blocks queries for insecure domains before the DNS request is sent, avoiding waste of network resources and improving processing efficiency. Simultaneously, a more comprehensive secondary security check is performed at the edge node to ensure the accuracy of the security check and avoid security risks caused by insufficient local checks. Attached Figure Description

[0035] Figure 1 This is a schematic diagram of a DNS request processing procedure in the prior art;

[0036] Figure 2 This is a schematic diagram illustrating another DNS request processing procedure in the prior art;

[0037] Figure 3 A flowchart illustrating the DNS request processing method provided in this application when applied to a user equipment;

[0038] Figure 4 A flowchart illustrating the DNS request processing method provided in this application when applied to an edge node;

[0039] Figure 5 This is a flowchart illustrating the overall process of DNS request processing using the solution provided in the embodiments of this application.

[0040] Figure 6 This is a schematic diagram of the structure of a DNS request processing device provided in an embodiment of this application;

[0041] Figure 7 This is a schematic diagram of another DNS request processing device provided in an embodiment of this application;

[0042] Figure 8 This is a schematic diagram of another DNS request processing device provided in an embodiment of this application. Detailed Implementation

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

[0044] In a typical configuration of this application, the terminal and the service network devices each include one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0045] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0046] Computer-readable media include both permanent and non-permanent, removable and non-removable media, which can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, read-only optical disc (CD-ROM), digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0047] This application provides a DNS request processing method. This method encrypts DNS requests locally on the user device using a secure DNS client, ensuring the DNS request is encrypted from the moment it is sent from the user device. This effectively prevents privacy information from being stolen or eavesdropped on by service providers of intermediate devices such as routing devices and gateway devices, thus improving the security of the solution. Furthermore, this solution splits the security detection mechanism into two parts: a local security detection is performed on the user device, encrypting and sending only the original DNS requests that pass the local security detection. This blocks queries for insecure domain names before the DNS request is sent, avoiding waste of network resources and improving processing efficiency. Simultaneously, a more comprehensive secondary security detection is performed at the edge node to ensure the accuracy of the security detection and avoid security risks caused by insufficient local detection.

[0048] Figure 3 This application illustrates a DNS request processing method according to an embodiment of the present application. The method is applied to a user equipment, which includes a secure DNS client. The processing flow of the method includes at least the following steps:

[0049] Step S301: The secure DNS client obtains the original DNS request issued by the application.

[0050] The original DNS request is a DNS request issued by an application on the user device to query the IP address corresponding to the domain name it wants to access. This original DNS request is generally transmitted in plaintext using the UDP protocol. That is, the original DNS request obtained by the secure DNS client in this embodiment is in plaintext. However, since the secure DNS client is located inside the user device, the process of forwarding the original DNS request from the application to the secure DNS client is not handled by any other intermediate devices, and there is no risk of privacy information leakage.

[0051] In real-world scenarios, to ensure that raw DNS requests from applications can be received by secure DNS clients, this can be achieved by pre-modifying the DNS configuration in the user's operating system. For example, the default DNS address in the operating system's DNS configuration can be changed to the local address: 127.0.0.1. This allows raw DNS requests from applications to be sent to this local address and thus received by the secure DNS client on the user's device.

[0052] Step S302: The secure DNS client performs local security checks on the original DNS request.

[0053] Upon receiving a raw DNS request, the secure DNS client first performs a local security check. This initial security assessment of the DNS request before it is sent to external devices enhances the overall security of the solution. Specifically, when the secure DNS client resolves the requested domain name from the raw DNS request, it determines whether the requested domain name conforms to a first preset security policy corresponding to the local security check. If it conforms, the local security check is considered passed, and subsequent processing steps can proceed. If it does not conform to the first preset security policy, the local security check is considered failed, and subsequent processing steps are not executed, terminating the DNS query initiated by the application.

[0054] In some embodiments of this application, the first preset security policy may take at least one of the following forms: the requested domain name exists in the whitelist of the local domain name classification database; the requested domain name does not exist in the blacklist of the local domain name classification database; the requested domain name exists in the whitelist of the local threat intelligence database; the requested domain name does not exist in the blacklist of the local threat intelligence database.

[0055] The local categorized domain name database performs security detection based on domain name classification information. For example, it can be categorized according to the information provided by different domains, such as entertainment, news, and video, thereby enabling the blocking or allowing of DNS resolution for specific categories. The local threat intelligence database performs security detection based on threat information of domain names. For example, a specific domain name may correspond to a phishing website or contain insecure data such as Trojans or viruses, thus enabling the blocking of DNS resolution for threatening domains or the allowing of resolution for non-threatening domains. Both the whitelist and blacklist contain at least one pre-configured domain name, thereby enabling local security detection based on different security policies.

[0056] The requested domain name existing in the local domain name classification database whitelist can mean that the domain name requested by the original DNS request is the same as one of the domain names in the local domain name classification database whitelist. For example, if the scheme in this embodiment needs to allow DNS requests corresponding to some news-related domain names while blocking DNS requests corresponding to other categories of domain names, the local domain name classification database whitelist can include the following domain names: xxx.abc.com, xxx.de.com, and *.fgh.com, all of which correspond to news-related websites. When setting the domain names in the whitelist or blacklist, wildcards such as "*" can be used, where "*" indicates that the content can be replaced by any character. For example, domain names such as "www.fgh.com" and "bbs.fgh.com" are considered the same as "*.fgh.com". For the aforementioned local domain name classification database whitelist, if the domain name requested by the original DNS request is xxx.de.com, since this domain name exists in the local domain name classification database whitelist and meets the first preset security policy, it can be determined to pass the local security check. If the original DNS request issued by the application requests to resolve a domain name of a video website, such as www.video.com, since this domain name is not in the whitelist of the local domain name classification database and does not comply with the first preset security policy, it can be determined that the local security test has failed.

[0057] The requested domain name not existing in the local domain name classification database blacklist means that the domain name requested by the original DNS request is different from any domain name in the local domain name classification database blacklist. For example, if the solution in this embodiment needs to block DNS requests corresponding to some news-related domain names while allowing DNS requests corresponding to other categories of domain names, the local domain name classification database blacklist may include the following domain names: xxx.hijk.com, xxx.lmn.com, and *.opq.com. Regarding the aforementioned local domain name classification database blacklist, if the domain name requested by the original DNS request is xxx.xyz.com, since this domain name does not exist in the local domain name classification database blacklist, it conforms to the first preset security policy and can be determined to have passed the local security check. If the domain name requested by the application in the original DNS request is www.hijk.com, since this domain name exists in the local domain name classification database blacklist and does not conform to the first preset security policy, it can be determined to have failed the local security check.

[0058] The requested domain name being in the whitelist of the local threat intelligence database can mean that the domain name requested by the original DNS request is the same as one of the domain names in the whitelist of the local threat intelligence database. For example, if the solution in this embodiment needs to allow DNS requests corresponding to domain names that have been confirmed to be free of threats, while blocking DNS requests corresponding to other domain names that have not yet been confirmed to be threats, the whitelist of the local threat intelligence database can include the following domain names: xxx.abc11.com, xxx.de123.com, and *.fgh11.com, all of which correspond to news websites. Regarding the whitelist of the local threat intelligence database, if the domain name requested by the original DNS request is xxx.de123.com, since this domain name exists in the whitelist of the local threat intelligence database and conforms to the first preset security policy, it can be determined that the local security detection has passed. If the domain name requested by the original DNS request issued by the application is www.vnsf1.com, since this domain name is not in the whitelist of the local threat intelligence database and does not conform to the first preset security policy, it can be determined that the local security detection has failed.

[0059] The requesting domain name not existing in the local threat intelligence database blacklist can mean that the domain name requested by the original DNS request is different from any domain name in the local threat intelligence database blacklist. For example, if the solution in this embodiment needs to block DNS requests corresponding to domain names that have been confirmed to pose a threat, while allowing DNS requests corresponding to other domain names, the local threat intelligence database blacklist may include the following domain names: xxx.hijk11.com, xxx.lmn123.com, and *.opq123.com. Regarding the aforementioned local threat intelligence database blacklist, if the domain name requested by the original DNS request is xxx.xyz123.com, since this domain name does not exist in the local threat intelligence database blacklist, it conforms to the first preset security policy and can be determined to have passed the local security detection. If the domain name requested by the original DNS request issued by the application is www.hijk11.com, since this domain name exists in the local threat intelligence database blacklist and does not conform to the first preset security policy, it can be determined to have failed the local security detection.

[0060] The above-mentioned first preset security strategies can also be combined according to the needs of actual application scenarios. For example, in some embodiments of this application, after obtaining the original DNS request, the secure DNS client can determine the domain name to be queried. It can first match the original DNS request based on the blacklist of the local domain name classification database and determine whether to block or allow it. Then, it can match the original DNS request based on the blacklist of the local threat intelligence database and determine whether to block or allow it.

[0061] Step S303: If the local security test is passed, the secure DNS client encrypts the original DNS request and generates an encrypted DNS request.

[0062] For raw DNS requests that have passed local security checks, the secure DNS client can further encrypt them to enhance security during subsequent transmission. During encryption, the secure DNS client can encrypt the raw DNS request using a preset encryption method to generate a corresponding encrypted DNS request. For example, a mapping between domain names and encryption methods can be pre-defined, such as domain 'a' corresponding to encryption method A, domain 'b' corresponding to encryption method B, etc. In this case, if the domain name queried in the raw DNS request is domain 'a', it can be encrypted using encryption method A to generate the corresponding encrypted DNS request.

[0063] In some embodiments of this application, the encryption method may include DoT (DNS over TLS, DNS based on Secure Transport Protocol) or DoH (DNS over HTTPS, DNS based on Secure Hypertext Transfer Protocol). Thus, the secure DNS client encrypts the original DNS request using either DoT or DoH to generate an encrypted DNS request. In practical scenarios, the mapping between domain names and the two encryption methods can be pre-configured; for example, some domain names can be encrypted using DoT, while others can be encrypted using DoH, thereby generating corresponding encrypted DNS requests.

[0064] In step S304, the secure DNS client sends the encrypted DNS request to the edge node, so that the edge node decrypts the encrypted DNS request to obtain the corresponding original DNS request, performs a second security check on the original DNS request, and requests DNS resolution based on the original DNS request that has passed the second security check.

[0065] When sending encrypted DNS requests to edge nodes, the secure DNS client can send the encrypted DNS requests to the edge nodes through the port corresponding to the encryption method. That is, a corresponding port can be assigned to each encrypted DNS request generated by each encryption method, and then the encrypted DNS requests generated by each encryption method can be sent to the edge nodes through the corresponding port. For example, if the encryption methods used include DoT and DoH, the port for encrypted DNS requests generated based on the DoT encryption method can be set to port 853, and the port for encrypted DNS requests generated based on the DoH encryption method can be set to port 443. Thus, the secure DNS client can send encrypted DNS requests generated using different encryption methods through different ports, allowing the edge nodes to receive the corresponding encrypted DNS requests through different ports. The edge nodes can then decrypt the encrypted DNS requests to obtain the corresponding original DNS requests, perform a secondary security check on the original DNS requests, and request DNS resolution based on the original DNS requests that have passed the secondary security check.

[0066] In some embodiments of this application, information such as the first preset security policy adopted by the secure DNS client during processing, the encryption method for encrypting the original DNS request, and the port used to send the encrypted DNS request can all be obtained from the management node. For example, the secure DNS client can obtain configuration information from the management node at startup. This configuration information may include the first preset security policy for local security detection, the encryption method for encrypting the original DNS request, and the port used to send the encrypted DNS request.

[0067] For the management node, users can create the configuration information based on their security requirements during the DNS query process. For example, the management node can provide a graphical user interface for creating configuration information, which users can access through a browser or client and input the configuration information to be created through this interactive interface.

[0068] Figure 4 This application illustrates another DNS request processing method provided in an embodiment of the present application. The method is applied to an edge node, and its processing includes related processing after the edge node receives an encrypted DNS request from a user device. The edge node in this embodiment differs from intermediate devices such as routing devices or gateway devices; it is a security node deployed on the network side, cooperating with a secure DNS client. It is configured with a decryption method corresponding to the encryption method in the secure DNS client and a second preset security policy for implementing secondary security checks. In the process of implementing DNS request processing, the edge node can perform at least the following processing steps:

[0069] In step S401, the edge node receives an encrypted DNS request sent by the user equipment's secure DNS client. The encrypted DNS request is generated by the secure DNS client after performing a local security check on the original DNS request issued by the application and encrypting it after passing the local security check.

[0070] In step S402, the edge node decrypts the encrypted DNS request to obtain the corresponding original DNS request. Since the user equipment's secure DNS client can use a preset encryption method to encrypt the original DNS request, the edge node, upon receiving the encrypted DNS request, can also use a preset decryption method to decrypt it to obtain the corresponding original DNS request. The encryption and decryption methods match. For example, if the secure DNS client uses DoH or DoT encryption to encrypt the original DNS request, it may generate a first encrypted DNS request based on DoH encryption or a second encrypted DNS request based on DoT encryption. In this case, if the edge node receives the first encrypted DNS request, it can decrypt it using the decryption method corresponding to DoH; if it receives the second encrypted DNS request, it can decrypt it using the decryption method corresponding to DoT, thereby resolving the correct original DNS request.

[0071] In some embodiments of this application, when an edge node receives an encrypted DNS request, it can receive the encrypted DNS request sent by the user equipment's secure DNS client through a preset port. The receiving port can be adapted to the port used by the secure DNS client to send encrypted DNS requests, or it can be set independently according to the needs of the actual application scenario. For example, in this embodiment, ports 443 and 853 can be set as the ports for receiving encrypted DNS requests.

[0072] Because encryption methods can be bound to ports at the sending end, i.e., the user equipment's secure DNS client, encrypted DNS requests generated by different encryption methods are sent through a corresponding port, a similar decryption method can be used at the receiving end. In this case, when decrypting, the edge node can use the decryption method corresponding to the preset port to decrypt the encrypted DNS request and obtain the corresponding original DNS request.

[0073] For example, if an encrypted DNS request is received through port 443, and it is known that the sender is transmitting a first encrypted DNS request based on DoH encryption through this port, the edge node can decrypt the encrypted DNS request received through port 443 using the decryption method corresponding to DoH to obtain the original DNS request. Similarly, if an encrypted DNS request is received through port 853, and it is known that the sender is transmitting a second encrypted DNS request based on DoT encryption through this port, the edge node can decrypt the encrypted DNS request received through port 853 using the decryption method corresponding to DoT to obtain the original DNS request.

[0074] Step S403: After decryption is completed, the edge node performs a secondary security check on the original DNS request.

[0075] During the secondary security check, the edge node first resolves the requested domain name based on the original DNS request. Then, it determines whether the requested domain name conforms to the second preset security policy corresponding to the secondary security check. If it conforms to the second preset security policy, the secondary security check is considered passed, and subsequent processing steps can be executed. If it does not conform to the second preset security policy, the secondary security check is considered failed, and subsequent processing steps are not executed, terminating the current DNS query.

[0076] In some embodiments of this application, the second preset security policy may take at least one of the following forms: the requested domain name exists in the whitelist of the cloud domain name classification database; the requested domain name does not exist in the blacklist of the cloud domain name classification database; the requested domain name exists in the whitelist of the cloud threat intelligence database; the requested domain name does not exist in the blacklist of the cloud threat intelligence database. The determination method based on the above-mentioned second preset security policy is similar to the determination method based on the first preset security policy in local security detection. Its purpose is to control whether to block or allow the original DNS request for the queried domain name through the whitelist or blacklist of the cloud domain name classification database or the cloud threat intelligence database.

[0077] In some embodiments of this application, the local security detection at the user equipment end and the secondary security detection at the edge node end can have certain differences to achieve complementary detection functions. For example, the first preset security policy of the local security detection can be a subset of the second preset security policy of the secondary security detection. This allows for a simple and fast local security detection at the user equipment end, while a more comprehensive secondary security detection is performed at the edge node, ensuring both the efficiency of DNS request queries and security. Alternatively, the first preset security policy of the local security detection and the second preset security policy of the secondary security detection can also be disjoint sets, thereby implementing different security detection strategies at both the user equipment and edge node ends, making the security detection more comprehensive.

[0078] Step S403: If the secondary security check passes, the edge node forwards the original DNS request to the DNS server, so that the DNS server determines the IP address corresponding to the domain name it requested to query based on the original DNS request.

[0079] Because DNS requests are encrypted locally on the user device using a secure DNS client, they are encrypted from the moment they are sent from the user device. Even if intermediate devices such as routers and gateways intercept the DNS requests, they cannot decrypt them to obtain private information. Therefore, this effectively prevents the service providers of intermediate devices such as routers and gateways from stealing or eavesdropping on private information, thus improving the security of the solution. At the same time, this solution splits the security detection mechanism into two parts: a local security detection is performed on the user device, encrypting and sending only the original DNS requests that pass the local security detection. This blocks queries for insecure domain names in advance before the DNS requests are sent, avoiding the waste of network resources and improving processing efficiency. At the same time, a more comprehensive secondary security detection is performed at the edge node to ensure the accuracy of the security detection and avoid security risks caused by insufficient local detection.

[0080] In some embodiments of this application, configuration information such as the second preset security policy adopted by the edge node during processing, the decryption method for decrypting the encrypted DNS request, and the port used to receive the encrypted DNS request can all be obtained from the management node. For example, after obtaining the configuration information provided by the user, the management node can push the configuration information to the corresponding edge node. The configuration information may include the second preset security policy for secondary security detection, the decryption method for decrypting the encrypted DNS request, and the port used to receive the encrypted DNS request.

[0081] In this context, the management node refers to a device capable of providing configuration information to the secure DNS client of an edge node or user device. The edge node refers to a device capable of securely transmitting DNS requests between the secure DNS client of a user device and the DNS server. In this embodiment, the actual devices corresponding to the management node and edge node are not limited; any device capable of performing the corresponding processing functions can be considered as the management node or edge node described in this embodiment. In practical scenarios, the corresponding processing functions of the management node can be deployed in any edge node within the edge cloud network, enabling that edge node to provide the corresponding processing functions of the management node. Alternatively, the corresponding processing functions of the management node can also be deployed in a device in an external network outside the edge cloud network, enabling that device to provide the corresponding processing functions of the management node to edge nodes or user devices.

[0082] Furthermore, the method provided in this application embodiment may also include a process of the DNS server returning a DNS response to the user equipment. Therefore, the DNS request processing method provided in this application embodiment further includes:

[0083] The edge node receives the original DNS response returned by the DNS server based on the original DNS request;

[0084] The edge node encrypts the original DNS response to generate an encrypted DNS response;

[0085] The edge node sends the encrypted DNS response to the user device's secure DNS client.

[0086] In the user device, the secure DNS client can receive the encrypted DNS response sent by the edge node, decrypt the DNS response to obtain the original DNS response, and forward the original DNS response to the application that initiated the original DNS request. During the return of the DNS response, the processing of the DNS response can employ corresponding encryption and decryption methods as described above for processing the DNS request. This ensures that the DNS response, returning from the DNS server to the application in the user device along the original path, also avoids the leakage of privacy information and guarantees sufficient security.

[0087] Figure 5 The overall process of implementing DNS request processing using the scheme provided in this application embodiment is illustrated. The devices involved in this scheme include at least user equipment 510, edge node 520, management node 530, and DNS server 540. The interaction process between the above devices includes:

[0088] Step S501: The administrator user creates corresponding access control rules on the management node of the edge cloud platform. The access control rules may include the first preset security policy, the blacklist or whitelist corresponding to the second preset security policy, the encryption method of the domain name, and the corresponding port.

[0089] Among them, the administrator user can be the security administrator of the CDN service provider or the security administrator of its tenant.

[0090] In step S502, the management node generates corresponding configuration information based on the access control rules and sends the configuration information about the edge nodes to the edge nodes.

[0091] In step S503, when the user equipment's secure DNS client starts, it obtains configuration information about the secure DNS client from the management node.

[0092] In step S504, the DNS address in the user device's operating system is modified to the local address, for example, the aforementioned DNS address is modified to 127.0.0.1, so that the DNS requests issued by the application can be hijacked by a secure DNS client.

[0093] In step S505, when application APP1 accesses a domain name, it sends a query data packet about the DNS request to the local secure DNS client.

[0094] Step S506: The secure DNS client first performs a local security check on the query data packet. The specific process of the security check may include: resolving the domain name to be queried, then performing a matching query based on the whitelist or blacklist of the local domain name classification database to determine whether to block it, and then, for unblocked domain names, performing another matching query based on the whitelist or blacklist of the local threat intelligence database to determine whether to block it.

[0095] Step S507: For query data packets that pass the security check, the secure DNS client encrypts them using a preset encryption method to generate encrypted query data packets. In this embodiment, the encryption methods that can be used include DoH or DoT encryption.

[0096] In step S508, the secure DNS client sends the encrypted query data packet to the edge node.

[0097] In step S509, after receiving the query data packet through the designated port, the edge node will decrypt it in an appropriate manner and then perform a secondary security check.

[0098] In step S510, for query data packets that pass the secondary security check, the edge node will forward them to the DNS server to determine the IP address corresponding to the domain name.

[0099] In step S511, the DNS server generates a response data packet including the IP address, returns it to the application APP1 along the original path and using the corresponding encryption and decryption method, thereby completing the DNS query for the domain name and enabling the application APP1 to continue the access process for the domain name.

[0100] This application embodiment also provides a DNS request processing device, which is a user equipment, and the structure of the user equipment is as follows: Figure 6 As shown, a secure DNS client 600 is included, comprising a receiving module 610, a security detection module 620, an encryption module 630, and a sending module 640. The receiving module 610 is used to acquire the original DNS request issued by the application; the security detection module 620 is used to perform local security detection on the original DNS request; the encryption module 630 is used to encrypt the original DNS request when it passes the local security detection, generating an encrypted DNS request; the sending module 640 is used to send the encrypted DNS request to an edge node, so that the edge node decrypts the encrypted DNS request to obtain the corresponding original DNS request, performs a secondary security detection on the original DNS request, and requests DNS resolution based on the original DNS request that has passed the secondary security detection.

[0101] The security detection module 620 is used to resolve the requested domain name according to the original DNS request, and to determine whether the requested domain name conforms to the first preset security policy corresponding to the local security detection. If it conforms to the first preset security policy, it is determined to pass the local security detection.

[0102] The first preset security policy includes at least one of the following:

[0103] The requested domain name exists in the whitelist of the local domain name classification database;

[0104] The requested domain name does not exist in the blacklist of the local domain name classification database;

[0105] The requested domain name exists in the whitelist of the local threat intelligence database;

[0106] The requested domain name does not exist in the blacklist of the local threat intelligence database.

[0107] The encryption module 630 is used to encrypt the original DNS request using a preset encryption method to generate a corresponding encrypted DNS request.

[0108] The sending module 640 is used to send the encrypted DNS request to the edge node through the port corresponding to the encryption method.

[0109] The receiving module 610 is also used to obtain configuration information created by the user from the management node, wherein the configuration information includes a first preset security policy for local security detection, an encryption method for encrypting the original DNS request, and a port for sending encrypted DNS requests.

[0110] The receiving module 610 is also used to receive the encrypted DNS response sent by the edge node;

[0111] The secure DNS client also includes a decryption module for decrypting the DNS response to obtain the original DNS response. The sending module 640 is also used to forward the original DNS response to the application that initiated the original DNS request.

[0112] The encryption module 630 is used to encrypt the original DNS request using DoT or DoH methods to generate an encrypted DNS request.

[0113] This application provides another DNS request processing device, which is an edge node, and its structure is as follows: Figure 7 As shown, it includes at least a receiving module 710, a decryption module 720, a security detection module 730, and a sending module 740. The receiving module 710 receives an encrypted DNS request sent by the user equipment's secure DNS client. The encrypted DNS request is generated by the secure DNS client performing a local security check on the original DNS request issued by the application, and then encrypting it after passing the local security check. The decryption module 720 decrypts the encrypted DNS request to obtain the corresponding original DNS request. The security detection module 730 performs a secondary security check on the original DNS request. The sending module 740 forwards the original DNS request to the DNS server when the secondary security check is passed.

[0114] The decryption module 720 is used to decrypt the encrypted DNS request using a preset decryption method to obtain the corresponding original DNS request.

[0115] The receiving module 710 is used to receive encrypted DNS requests sent by the user equipment's secure DNS client through a preset port;

[0116] The decryption module 720 is used to decrypt the encrypted DNS request using a decryption method corresponding to a preset port, and obtain the corresponding original DNS request.

[0117] The security detection module 730 is used to resolve the requested domain name according to the original DNS request; and to determine whether the requested domain name conforms to the second preset security policy corresponding to the secondary security detection. If it conforms to the second preset security policy, it is determined that the secondary security detection has passed.

[0118] The second preset security policy includes at least one of the following:

[0119] The requested domain name exists in the whitelist of the cloud domain name classification database;

[0120] The requested domain name does not exist in the blacklist of the cloud domain name classification database;

[0121] The requested domain name exists in the whitelist of the cloud-based threat intelligence database;

[0122] The requested domain name does not exist in the cloud threat intelligence database blacklist.

[0123] The receiving module 710 is further configured to receive from the DNS server the original DNS response returned based on the original DNS request;

[0124] The edge node also includes an encryption module for encrypting the original DNS response and generating an encrypted DNS response;

[0125] The sending module 740 is further configured to send the encrypted DNS response to the secure DNS client of the user equipment, so that the secure DNS client can decrypt the encrypted DNS response and forward the decrypted original DNS response to the application that initiated the original DNS request.

[0126] The decryption module 720 is used to decrypt the encrypted DNS request using DoT or DoH methods to obtain the corresponding original DNS request.

[0127] This application also provides a DNS request processing system, including user equipment and edge nodes, wherein,

[0128] The user equipment includes a secure DNS client, which is used to obtain the original DNS request issued by the application; perform local security detection on the original DNS request; if the local security detection passes, encrypt the original DNS request to generate an encrypted DNS request; and send the encrypted DNS request to the edge node.

[0129] The edge node is used to receive encrypted DNS requests sent by the user equipment's secure DNS client; the edge node performs a secondary security check on the original DNS request; if the secondary security check passes, the encrypted DNS request is decrypted to obtain the corresponding original DNS request; and the original DNS request is forwarded to the DNS server.

[0130] Furthermore, embodiments of this application also provide a DNS request processing device, the structure of which is as follows: Figure 8 As shown, it includes a memory 810 for storing computer-readable instructions and a processor 820 for executing computer-readable instructions, wherein when the computer-readable instructions are executed by the processor, the processor is triggered to execute the DNS request processing method.

[0131] The methods and / or embodiments in this application can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by a processing unit, it performs the functions defined in the methods of this application.

[0132] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: 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 application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0133] In this application, a computer-readable signal medium may include a data signal 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. The computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, capable of transmitting, propagating, or transmitting a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any suitable medium, including but not limited to: wireless, wireline, optical fiber, RF, etc., or any suitable combination thereof.

[0134] Computer program code for performing the operations of this application 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 server. 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).

[0135] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0136] In another aspect, embodiments of this application also provide a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The aforementioned computer-readable medium carries one or more computer-readable instructions, which may be executed by a processor to implement the steps of the methods and / or technical solutions of the various embodiments of this application.

[0137] Furthermore, this application also provides a computer program stored in a computer device, which causes the computer device to execute the method for executing the control code.

[0138] It should be noted that this application can be implemented in software and / or a combination of software and hardware, for example, using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the steps or functions described above. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, a magnetic or optical drive, a floppy disk, or similar devices. Furthermore, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0139] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be embraced within this application. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in the apparatus claims may also be implemented by a single unit or device in software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any particular order.

Claims

1. A DNS request processing method, characterized in that, The method is applied to a user equipment, the user equipment including a secure DNS client, the method comprising: The secure DNS client obtains the original DNS request issued by the application; The secure DNS client performs local security checks on the original DNS request; If the local security test is passed, the secure DNS client encrypts the original DNS request and generates an encrypted DNS request; The secure DNS client sends the encrypted DNS request to the edge node, so that the edge node decrypts the encrypted DNS request to obtain the corresponding original DNS request, performs a second security check on the original DNS request, and requests DNS resolution based on the original DNS request that has passed the second security check.

2. The method according to claim 1, characterized in that, The secure DNS client performs local security checks on the original DNS request, including: The secure DNS client resolves the requested domain name based on the original DNS request; The secure DNS client determines whether the requested domain name conforms to the first preset security policy corresponding to the local security detection. If it conforms to the first preset security policy, it is determined that the local security detection has passed.

3. The method according to claim 2, characterized in that, The first preset security policy includes at least one of the following: The requested domain name exists in the whitelist of the local domain name classification database; The requested domain name does not exist in the blacklist of the local domain name classification database; The requested domain name exists in the whitelist of the local threat intelligence database; The requested domain name does not exist in the blacklist of the local threat intelligence database.

4. The method according to claim 1, characterized in that, The secure DNS client encrypts the original DNS request to generate an encrypted DNS request, including: The secure DNS client encrypts the original DNS request using a preset encryption method to generate a corresponding encrypted DNS request.

5. The method according to claim 4, characterized in that, The secure DNS client sends the encrypted DNS request to the edge node, including: The secure DNS client sends the encrypted DNS request to the edge node through the port corresponding to the encryption method.

6. The method according to claim 1, characterized in that, The method further includes: The secure DNS client obtains configuration information created by the user from the management node. The configuration information includes a first preset security policy for local security detection, an encryption method for encrypting the original DNS request, and a port for sending encrypted DNS requests.

7. The method according to claim 1, characterized in that, The method further includes: The secure DNS client receives the encrypted DNS response sent by the edge node; The secure DNS client decrypts the DNS response to obtain the original DNS response and forwards the original DNS response to the application that initiated the original DNS request.

8. The method according to claim 1, characterized in that, The secure DNS client encrypts the original DNS request to generate an encrypted DNS request, including: The secure DNS client encrypts the original DNS request using DoT or DoH to generate an encrypted DNS request.

9. A DNS request processing method, characterized in that, The method is applied to edge nodes, and the method includes: The edge node receives an encrypted DNS request sent by the user equipment's secure DNS client. The encrypted DNS request is generated by the secure DNS client after performing a local security check on the original DNS request issued by the application and passing the local security check. The edge node decrypts the encrypted DNS request to obtain the corresponding original DNS request; The edge node performs a secondary security check on the original DNS request; If the secondary security check passes, the edge node will forward the original DNS request to the DNS server.

10. The method according to claim 9, characterized in that, The edge node decrypts the encrypted DNS request to obtain the corresponding original DNS request, including: The edge node decrypts the encrypted DNS request using a preset decryption method to obtain the corresponding original DNS request.

11. The method according to claim 10, characterized in that, The edge node receives an encrypted DNS request sent by the user equipment's secure DNS client, including: The edge node receives encrypted DNS requests sent by the user equipment's secure DNS client through a preset port; The edge node decrypts the encrypted DNS request using a preset decryption method to obtain the corresponding original DNS request, including: The edge node decrypts the encrypted DNS request using a decryption method corresponding to a preset port to obtain the corresponding original DNS request.

12. The method according to claim 9, characterized in that, The edge node performs a secondary security check on the original DNS request, including: The edge node resolves the requested domain name based on the original DNS request; The edge node determines whether the requested domain name conforms to the second preset security policy corresponding to the secondary security detection. If it conforms to the second preset security policy, it is determined that the secondary security detection has passed.

13. The method according to claim 12, characterized in that, The second preset security policy includes at least one of the following: The requested domain name exists in the whitelist of the cloud domain name classification database; The requested domain name does not exist in the blacklist of the cloud domain name classification database; The requested domain name exists in the whitelist of the cloud-based threat intelligence database; The requested domain name does not exist in the cloud threat intelligence database blacklist.

14. The method according to claim 9, characterized in that, The method further includes: The edge node receives the original DNS response returned by the DNS server based on the original DNS request; The edge node encrypts the original DNS response to generate an encrypted DNS response; The edge node sends the encrypted DNS response to the user device's secure DNS client, so that the secure DNS client decrypts the encrypted DNS response and forwards the decrypted original DNS response to the application that initiated the original DNS request.

15. The method according to claim 9, characterized in that, The edge node decrypts the encrypted DNS request to obtain the corresponding original DNS request, including: The edge node decrypts the encrypted DNS request using DoT or DoH to obtain the corresponding original DNS request.

16. A DNS request processing device, characterized in that, The device is a user equipment, and the user equipment includes a secure DNS client, which includes: The receiving module is used to obtain the raw DNS requests sent by the application; The security detection module is used to perform local security detection on the original DNS request; An encryption module is used to encrypt the original DNS request when passing local security checks, and generate an encrypted DNS request; The sending module is used to send the encrypted DNS request to the edge node, so that the edge node decrypts the encrypted DNS request to obtain the corresponding original DNS request, performs a secondary security check on the original DNS request, and requests DNS resolution based on the original DNS request that has passed the secondary security check.

17. A DNS request processing device, characterized in that, The device is an edge node, and the edge node includes: The receiving module is used to receive encrypted DNS requests sent by the user equipment's secure DNS client. The encrypted DNS requests are generated by the secure DNS client after performing local security checks on the original DNS requests issued by the application and encrypting them after passing the local security checks. The decryption module is used to decrypt the encrypted DNS request and obtain the corresponding original DNS request; The security detection module is used to perform a secondary security detection on the original DNS request; The sending module is used to forward the original DNS request to the DNS server when the secondary security check is passed.

18. A DNS request processing system, characterized in that, Including user equipment and edge nodes, among which, The user equipment includes a secure DNS client, which is used to obtain the original DNS request issued by the application; perform local security detection on the original DNS request; if the local security detection passes, encrypt the original DNS request to generate an encrypted DNS request; and send the encrypted DNS request to the edge node. The edge node is used to receive encrypted DNS requests sent by the user equipment's secure DNS client; the edge node performs a secondary security check on the original DNS request; if the secondary security check passes, the encrypted DNS request is decrypted to obtain the corresponding original DNS request; and the original DNS request is forwarded to the DNS server.

19. A DNS request processing device, characterized in that, The device includes: One or more processors; and A memory storing computer program instructions, which, when executed, cause the processor to perform the method as described in any one of claims 1 to 15.

20. A computer-readable medium having stored thereon computer program instructions that can be executed by a processor to implement the method as described in any one of claims 1 to 15.

Images