CN116962346A

CN116962346A - DNS request processing method, device, system and computer readable medium

Info

Publication number: CN116962346A
Application number: CN202210397415.1A
Authority: CN
Inventors: 高力; 胡金涌
Original assignee: Shanghai Yundun Information Technology Co ltd
Current assignee: Shanghai Yundun Information Technology Co ltd
Priority date: 2022-04-15
Filing date: 2022-04-15
Publication date: 2023-10-27

Abstract

The application provides a DNS request processing method, device, system and computer readable medium, wherein in the scheme, because the DNS request can be encrypted through a safe DNS client locally at user equipment, the DNS request is in an encrypted state when sent from the user equipment, thus effectively avoiding the private information from being stolen or monitored by service providers of intermediate devices such as routing devices, gateway devices and the like, and improving the safety of the scheme; meanwhile, the security detection mechanism is split into two parts, namely, the local security detection is carried out at the user equipment, the original DNS request through the local security detection is only encrypted and sent, the inquiry for the unsafe domain name can be blocked in advance before the DNS request is sent, the waste of network resources is avoided, the processing efficiency is improved, meanwhile, the accuracy of the security detection is ensured through the secondary security detection which is carried out at the edge node more comprehensively, and the security risk caused by the incomplete local detection is avoided.

Description

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

Technical Field

The present application relates to the field of information technologies, and in particular, to a DNS request processing method, device, system, and computer readable medium.

Background

The domain name system (Domain Name System, DNS) is a service of the internet that enables domain names and IP (Internet Protocol ) addresses to be mapped to each other, enabling people to access the internet more conveniently.

Applications in user devices typically need to utilize DNS services when access to a domain name is required, where the processing of DNS requests is illustrated in fig. 1. When an application program needs to access a target domain name, firstly, searching an IP address corresponding to the domain name in a local DNS cache, and if the IP address is not searched, sending a DNS request to a search processing node of the DNS request for search. In the query process, the DNS request is generally transmitted in a plaintext form using the UDP protocol, so that the security of the query process is poor, and the private information is easy to reveal. In addition, since there is no security detection mechanism for domain names, security is low.

In order to solve the above-mentioned security problem, a scheme for performing security detection and encryption on a routing device, a gateway device or a cloud server for DNS requests is provided in the prior art, and the processing principle is shown in fig. 2. First, although the scheme can encrypt data of the DNS request to ensure that data communication between the intermediate device such as the routing device, the gateway device, and the DNS server is secure, the DNS request is still transmitted in a clear text manner between the user device and the intermediate device. Therefore, this scheme still has difficulty in avoiding the acquisition of the private information by the intermediate device service provider, and the security still has a deficiency.

Second, the security detection of this scheme is performed in the intermediate devices, thereby resulting in the user device having to send DNS requests to these intermediate devices regardless of whether the domain name queried by the DNS request is secure, and the intermediate devices perform security detection to determine whether to block or allow subsequent processing flows. In short, if the result of the security detection is unsafe, the subsequent processing flow is blocked, and before that, the user equipment must send the DNS request to the intermediate equipment, which causes technical problems of network resource waste and efficiency reduction.

Disclosure of Invention

An object of the present application is to provide a DNS request processing method, device, system, and computer readable medium, at least for solving the problems of insufficient security and low processing efficiency in the DNS query process.

To achieve the above object, some embodiments of the present application provide a DNS request processing method, which is applied to a user equipment including a secure DNS client, the method including:

the secure DNS client acquires an original DNS request sent by an application program;

the secure DNS client performs local security detection on the original DNS request;

If the local security detection is passed, the secure DNS client encrypts the original DNS request to generate an encrypted DNS request;

and the secure DNS client sends the encrypted DNS request to an edge node so that the edge node decrypts the encrypted DNS request to obtain a corresponding original DNS request, performs secondary security detection on the original DNS request, and requests DNS analysis based on the original DNS request passing the secondary security detection.

Some embodiments of the present application further provide another DNS request processing method, where the method is applied to an edge node, the method including:

the edge node receives a secure DNS request sent by a secure DNS client of the user equipment, wherein the encrypted DNS request is generated by performing secondary security detection on an original DNS request sent by an application program by the secure DNS client and encrypting after passing the secondary security detection;

the edge node decrypts the encrypted DNS request to obtain a corresponding original DNS request;

the edge node performs secondary security detection on the original DNS request;

if the secondary security detection is passed, the edge node forwards the original DNS request to a DNS server.

Some embodiments of the present application further provide a DNS request processing device, where the device is a user equipment, and the user equipment includes a secure DNS client, and the secure DNS client includes:

the receiving module is used for acquiring an original DNS request sent by an application program;

the safety detection module is used for carrying out local safety detection on the original DNS request;

the encryption module is used for encrypting the original DNS request when passing through local security detection, and generating an encrypted DNS request;

and the sending module is used for sending the encrypted DNS request to an edge node so that the edge node decrypts the encrypted DNS request to obtain a corresponding original DNS request, carries out secondary security detection on the original DNS request, and requests DNS analysis based on the original DNS request passing the secondary security detection.

Some embodiments of the present application further provide another DNS request processing device, where the device is an edge node, and the edge node includes:

the receiving module is used for receiving an encrypted DNS request sent by a secure DNS client of the user equipment, wherein the encrypted DNS request is generated by carrying out secondary security detection on an original DNS request sent by an application program by the secure DNS client and encrypting after the secondary security detection;

The decryption module is used for decrypting the encrypted DNS request to obtain a corresponding original DNS request;

the safety detection module is used for carrying out secondary safety detection on the original DNS request;

and the sending module is used for forwarding the original DNS request to a DNS server when the secondary security detection is passed.

Some embodiments of the present application also provide a DNS request processing system, including a user equipment and an edge node, where,

the user equipment comprises a secure DNS client, wherein the secure DNS client is used for acquiring an original DNS request sent by the application program; performing local security detection on the original DNS request; if the original DNS request is detected through local security, encrypting the original DNS request to generate an encrypted DNS request; sending the encrypted DNS request to an edge node;

the edge node is used for receiving an encrypted DNS request sent by a secure DNS client of the user equipment; the edge node performs secondary security detection on the original DNS request; if the encrypted DNS request is detected through secondary security detection, decrypting the encrypted DNS request to obtain a corresponding original DNS request; forwarding the original DNS request to a DNS server.

Some embodiments of the present application further provide a DNS request processing device, where the device includes:

One or more processors; and

a memory storing computer program instructions that, when executed, cause the processor to perform the DNS request processing method.

Some embodiments of the application also provide a computer readable medium having stored thereon computer program instructions executable by a processor to implement the DNS request processing method.

Compared with the prior art, in the DNS request processing solution provided in the embodiment of the present application, the user equipment includes a secure DNS client, in the process of querying DNS, the user equipment obtains an original DNS request sent by the application program through the secure DNS client, performs local security detection on the original DNS request, encrypts the original DNS request through the local security detection to generate an encrypted DNS request, and then sends the encrypted DNS request to an edge node, so that the edge node decrypts the encrypted DNS request to obtain a corresponding original DNS request, performs secondary security detection on the original DNS request, and performs DNS resolution on the basis of the original DNS request through the secondary security detection. Because the user equipment can be locally encrypted through the secure DNS client, the DNS request is in an encrypted state when sent from the user equipment, so that the private information can be effectively prevented from being stolen or monitored by service providers of intermediate equipment such as routing equipment, gateway equipment and the like, and the safety of the scheme is improved; meanwhile, the security detection mechanism is split into two parts, namely, the local security detection is carried out at the user equipment, the original DNS request through the local security detection is only encrypted and sent, the inquiry for the unsafe domain name can be blocked in advance before the DNS request is sent, the waste of network resources is avoided, the processing efficiency is improved, meanwhile, the accuracy of the security detection is ensured through the secondary security detection which is carried out at the edge node more comprehensively, and the security risk caused by the incomplete local detection is avoided.

Drawings

FIG. 1 is a schematic diagram of a prior art process for processing a DNS request;

FIG. 2 is a schematic diagram of another prior art DNS request processing procedure;

fig. 3 is a process flow chart of a DNS request processing method according to an embodiment of the present application when the DNS request processing method is applied to a user equipment;

fig. 4 is a process flow chart of a DNS request processing method according to an embodiment of the present application when the DNS request processing method is applied to an edge node;

fig. 5 is an overall flowchart when DNS request processing is implemented by adopting the solution provided by the embodiment of the present application;

fig. 6 is a schematic structural diagram of a DNS request processing device according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of another DNS request processing device according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of another DNS request processing device according to an embodiment of the present application.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more apparent, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments of the present application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

In one exemplary configuration of the application, the terminal, the devices of the services network each include one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer-readable media include both permanent and non-permanent, removable and non-removable media, and information storage may be implemented by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer 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 technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape storage or other magnetic storage devices, or any other non-transmission medium which can be used to store information that can be accessed by a computing device.

The embodiment of the application provides a DNS request processing method, which can encrypt a DNS request locally by a secure DNS client, so that the DNS request is in an encrypted state when sent from the user equipment, private information can be effectively prevented from being stolen or monitored by a server of intermediate equipment such as routing equipment, gateway equipment and the like, and the safety of a scheme is improved; meanwhile, the security detection mechanism is split into two parts, namely, the local security detection is carried out at the user equipment, the original DNS request through the local security detection is only encrypted and sent, the inquiry for the unsafe domain name can be blocked in advance before the DNS request is sent, the waste of network resources is avoided, the processing efficiency is improved, meanwhile, the accuracy of the security detection is ensured through the secondary security detection which is carried out at the edge node more comprehensively, and the security risk caused by the incomplete local detection is avoided.

Fig. 3 shows a process flow of a DNS request processing method according to an embodiment of the present application, where the method is applied to a user equipment, and the user equipment includes a secure DNS client, and the process flow of the method includes at least the following steps:

In step S301, the secure DNS client obtains an original DNS request sent by the application.

The original DNS request is a DNS request which is sent by an application program in the user equipment and needs to inquire an IP address corresponding to a domain name to be accessed by the application program. The original DNS request is generally transmitted in plain text form using a UDP protocol, that is, the original DNS request acquired by the secure DNS client in this embodiment is in plain text form, but since the secure DNS client is located inside the user device, there is no intervention of other intermediate devices in the process of forwarding the original DNS request from the application program to the secure DNS client, and there is no risk of disclosure of private information.

In a practical scenario, in order to enable the original DNS request issued by the application to be obtained by the secure DNS client, this may be achieved by means of pre-modifying the DNS configuration in the operating system of the user device. For example, a default DNS address in the DNS configuration of the operating system may be modified to be a native address: 127.0.0.1, whereby the original DNS request issued by the application can be sent to the local address for retrieval by a secure DNS client in the user device.

Step S302, the secure DNS client performs local security detection on the original DNS request.

After receiving the original DNS request, the secure DNS client firstly carries out local security detection on the original DNS request so as to carry out preliminary security judgment on the DNS request before sending the DNS request to external equipment, thereby improving the security of the scheme. When the secure DNS client resolves the requested domain name according to the original DNS request, the secure DNS client may determine whether the requested domain name meets a first preset security policy corresponding to the local security detection, and if yes, determine that the domain name passes the local security detection, where a subsequent processing step may be performed. If the first preset security policy is not met, the local security detection is judged not to be passed, at the moment, the subsequent processing step is not executed, and the DNS query initiated by the application program is terminated.

In some embodiments of the present application, the first preset security policy may take at least any one of the following forms: the requested domain name exists on a white list of the local domain name classification library; the requested domain name does not exist in the blacklist of the local domain name classification library; the requested domain name exists on a white list of the local threat intelligence library; the requested domain name does not exist in the blacklist of the local threat intelligence library.

The local classification domain name library can realize safety detection based on classification information of domain names, for example, can be classified according to information provided by different domain names, and can be classified into entertainment class, news class, video class and the like, so that blocking or releasing of domain name resolution of specific classification can be realized. The local threat information library is used for realizing safety detection based on threat information of the domain name, for example, a specific domain name may correspond to a phishing website or contain unsafe data such as Trojan horse, virus and the like, so that resolution of the domain name with threat can be blocked, or resolution of the domain name without threat can be released. The white list and the black list each comprise at least one domain name which is preconfigured, so that local security detection is realized according to security policies in different forms.

The presence of the requested domain name in the whitelist of the local domain name classification library may mean that the domain name requested to be resolved by the original DNS request is the same as one of the domain names in the whitelist of the local domain name classification library. For example, if the solution in the embodiment of the present application needs to pass through DNS requests corresponding to domain names of a part of news classes, and block DNS requests corresponding to domain names of other classifications, the white list of the local domain name classification library may include the following domain names: xxx.abc.com, xxx.de.com and:. Fgh.com, the above domains all correspond to news-like websites. Where a wild card such as a "x" or the like may be used in setting a domain name in a white list or black list, where a "x" indicates that the portion of content may be replaced by any character, e.g., a domain name such as "www.fgh.com", "bbs.fgh.com" is considered to be the same as "x.fgh.com". For the white list of the local domain name classification library, if the domain name requested to be resolved by the original DNS request is xxx.de.com, and the domain name exists in the white list of the local domain name classification library and accords with the first preset security policy, the domain name can be determined to pass the local security detection. If the domain name requested to be resolved by the original DNS request sent by the application program is a domain name www.video.com of a video website, and the domain name is not in the white list of the local domain name classification library and does not conform to the first preset security policy, it may be determined that the local security detection is not passed.

The absence of the requested domain name from the blacklist of the local domain name classification library means that the domain name requested to be resolved by the original DNS request is not the same as any domain name in the blacklist of the local domain name classification library. For example, if the solution in the embodiment of the present application needs to block DNS requests corresponding to domain names of a part of news classes, DNS requests corresponding to domain names of other classes are released. The blacklist of the local domain name classification library may include the following domain names: xxx.hijk.com, xxx.lmn.com and opq.com. For the blacklist of the local domain name classification library, if the domain name requested to be resolved by the original DNS request is xxx. If the domain name requested to be resolved by the original DNS request sent by the application program is www.hijk.com, and the domain name exists in the blacklist of the local domain name classification library and does not conform to the first preset security policy, it may be determined that the local security detection is not passed.

The presence of the requested domain name in the white list of the local threat intelligence library may mean that the domain name requested to be resolved by the original DNS request is the same as one of the domain names in the white list of the local threat intelligence library. For example, if the solution in the embodiment of the present application needs to pass through DNS requests corresponding to domain names that have been confirmed that have no threat, and block DNS requests corresponding to domain names that have not been confirmed that have threat, the white list of the local threat information library may include the following domain names: xxx.abc11.Com, xxx.de123.Com and x.fgh11. Com, all of which correspond to news-like websites. For the white list of the local threat information library, if the domain name requested to be resolved by the original DNS request is xxx.de123.com, and the domain name exists in the white list of the local threat information library and accords with the first preset security policy, the domain name can be determined to pass the local security detection. If the domain name requested to be resolved by the original DNS request sent by the application program is www.vnsf1.com, and the domain name is not in the white list of the local threat information library and does not conform to the first preset security policy, it may be determined that the local security detection is not passed.

The absence of the requested domain name from the blacklist of the local threat intelligence library may mean that the domain name requested to be resolved by the original DNS request is not the same as any domain name in the blacklist of the local threat intelligence library. For example, if the solution in the embodiment of the present application needs to block DNS requests corresponding to the confirmed domain name with threat, and release DNS requests corresponding to other domain names, the blacklist of the local threat information library may include the following domain names: xxx.hijk11.com, xxx.lmn123.com, opq123.com. For the blacklist of the local threat information library, if the domain name requested to be resolved by the original DNS request is xxx.xyz123.Com, and the domain name does not exist in the blacklist of the local threat information library and accords with the first preset security policy, the domain name can be determined to pass the local security detection. If the domain name requested to be resolved by the original DNS request sent by the application program is www.hijk11.com, and the domain name exists in the blacklist of the local threat information library and does not conform to the first preset security policy, it may be determined that the local security detection is not passed.

For the above-mentioned first preset security policies, the combination may also be used according to the needs of the actual application scenario, for example, in some embodiments of the present application, the secure DNS client may determine the domain name to be queried after acquiring the original DNS request, may first perform matching based on the blacklist of the local domain name classification library, determine blocking or releasing the original DNS request, and then perform matching based on the blacklist of the local threat intelligence library, and determine blocking or releasing.

In step S303, if the local security detection is passed, the secure DNS client encrypts the original DNS request to generate an encrypted DNS request.

For the original DNS request that has passed the local security detection, the secure DNS client may further encrypt it to promote security in subsequent sending processes. When encrypting, the secure DNS client may encrypt the original DNS request by using a preset encryption manner to generate a corresponding encrypted DNS request, for example, a correspondence between a domain name and the encryption manner may be preset, for example, an a domain name corresponds to an a encryption manner, a B domain name corresponds to a B encryption manner, and the like, where if the domain name queried by the original DNS request is an a domain name, the original DNS request may be encrypted by using an a encryption manner to generate the corresponding encrypted DNS request.

In some embodiments of the application, the encryption scheme may include DoT (DNS over TLS, DNS based on secure transport protocol) or DoH (DNS over HTTPS, DNS based on secure hypertext transport protocol). Therefore, the secure DNS client encrypts the original DNS request in a DoT or DoH mode to generate an encrypted DNS request. In an actual scenario, a correspondence between the domain name and the two encryption methods may be preconfigured, for example, encryption is performed by using a DoT method for a part of the domain name, and encryption is performed by using a DoH method for another part of the domain name, so as to generate a corresponding encrypted DNS request.

Step S304, the secure DNS client sends the encrypted DNS request to an edge node, so that the edge node decrypts the encrypted DNS request to obtain a corresponding original DNS request, performs secondary security detection on the original DNS request, and requests DNS resolution based on the original DNS request passing the secondary security detection.

When sending an encrypted DNS request to an edge node, the secure DNS client may send the encrypted DNS request to the edge node through a port corresponding to the encryption mode. The corresponding port can be allocated to the encrypted DNS request generated by each encryption mode, and then the encrypted DNS request generated by each encryption mode is sent to the edge node through the corresponding port. For example, if the encryption scheme adopted includes both DoT and DoH, the port may be set to 853 for the encrypted DNS request generated based on the DoT encryption scheme and 443 for the encrypted DNS request generated based on the DoH encryption scheme. Therefore, the secure DNS client can send the encrypted DNS requests generated by different encryption modes through different ports, so that the edge node can receive the corresponding encrypted DNS requests through different ports, further decrypt the encrypted DNS requests to obtain corresponding original DNS requests, perform secondary security detection on the original DNS requests, and request DNS analysis based on the original DNS requests passing the secondary security detection.

In some embodiments of the present application, the information of the first preset security policy adopted by the secure DNS client in the processing procedure, the encryption manner of encrypting the original DNS request, and the port for sending the encrypted DNS request may be obtained from the management node. For example, the secure DNS client may obtain configuration information from the management node at startup, where the configuration information may include a first preset security policy for local security detection, an encryption manner in which the original DNS request is encrypted, a port used to send the encrypted DNS request, and so on.

For the management node, the configuration information can be created in the management node by the user according to the security requirements of the user in the DNS query process. For example, the management node may provide a graphical user interface for creating configuration information, which a user may access through a browser or client and input configuration information to be created through the interactive interface.

Fig. 4 shows another DNS request processing method according to an embodiment of the present application, where the processing procedure of the DNS request processing method is applied to an edge node, and includes related processing after the edge node receives an encrypted DNS request from a user equipment. The edge node in the embodiment of the application is different from intermediate equipment such as routing equipment or gateway equipment and the like, is a security node which is deployed on a network side and is matched with a security DNS client for processing, and is configured with a decryption mode corresponding to an encryption mode in the security DNS client and a second preset security policy for realizing secondary security detection. In implementing DNS request processing, the edge node may perform at least the following processing steps:

In step S401, the edge node receives an encrypted DNS request sent by a secure DNS client of the user equipment. The encrypted DNS request is generated by performing secondary security detection on an original DNS request sent by an application program by the secure DNS client and encrypting after the secondary security detection.

In step S402, the edge node decrypts the encrypted DNS request to obtain the corresponding original DNS request. Because the secure DNS client of the user equipment can encrypt the original DNS request by adopting a preset encryption mode when encrypting, the edge node can decrypt the encrypted DNS request by adopting a preset decryption mode after receiving the encrypted DNS request, and the corresponding original DNS request is obtained, wherein the encryption mode and the decryption mode are matched. For example, if the secure DNS client encrypts the original DNS request using the DoH or DoT encryption method during encryption, a first encrypted DNS request based on the DoH encryption method or a second encrypted DNS request based on the DoT encryption method may be generated. At this time, if the edge node receives the first encrypted DNS request, it may be decrypted by using a decryption method corresponding to the DoH, and if the edge node receives the second encrypted DNS request, it may be decrypted by using a decryption method corresponding to the DoT, thereby resolving the correct original DNS request.

In some embodiments of the present application, when receiving an encrypted DNS request, the edge node may receive, through a preset port, the encrypted DNS request sent by the secure DNS client of the user equipment. The received port may be set according to port adaptation of the secure DNS client to send the encrypted DNS request, or may also be set separately according to the needs of the actual application scenario. For example, the present embodiment may set 443 ports and 853 ports as ports that receive encrypted DNS requests.

Since the encryption mode and the port can be bound in the transmitting end, namely the secure DNS client of the user equipment, that is, the encrypted DNS requests generated by different encryption modes are transmitted by a corresponding port, decryption can be performed in a similar way in the receiving end. In this case, when the edge node decrypts, the encrypted DNS request may be decrypted by adopting a decryption manner corresponding to the preset port, so as to obtain a corresponding original DNS request.

For example, if the encrypted DNS request is received through the 443 port, since it is known that the sender transmits the first encrypted DNS request based on the DoH encryption manner through the 443 port, the edge node may decrypt the encrypted DNS request received through the 443 port through the decryption manner corresponding to the DoH, to obtain the original DNS request. Similarly, if the encrypted DNS request is received through the 853 port, since it is known that the sender transmits the second encrypted DNS request based on the DoT encryption manner through the port, the edge node may decrypt the encrypted DNS request received through the 853 port through the decryption manner corresponding to the DoT, to obtain the original DNS request.

Step S403, after finishing the decryption, the edge node performs secondary security detection on the original DNS request.

When the secondary security detection is performed, the edge node may first solve the requested domain name according to the original DNS request, then determine whether the requested domain name meets a second preset security policy corresponding to the secondary security detection, and if so, determine that the domain name passes the secondary security detection, where a subsequent processing step may be performed. If the second preset security policy is not met, the second security detection is judged to be failed, at the moment, the subsequent processing step is not executed, and the DNS query is terminated.

In some embodiments of the present application, the second preset security policy may take at least any one of the following forms: the requested domain name exists in a white list of a cloud domain name classification library; the requested domain name does not exist in the blacklist of the cloud domain name classification library; the requested domain name exists in a white list of a cloud hypochondriac information library; the requested domain name does not exist in the blacklist of the cloud threat intelligence library. The judging mode based on the second preset security policy is similar to the judging mode based on the first preset security policy in the local security detection, and the purpose of the judging mode is to control whether to block or release the original DNS request of the query domain name through a white list or a black list of a cloud domain name classification library or a cloud hypochondriac information library.

In some embodiments of the present application, there may be a certain difference between the local security detection at the ue end and the secondary security detection at the edge node end, so as to implement complementation in detection function. For example, the first preset security policy of the local security detection may be a subset of the second preset security policy of the secondary security detection, so that by performing a simple and fast local security detection locally at the user equipment, and performing a more comprehensive secondary security detection at the edge node, security is ensured while ensuring the efficiency of transmitting DNS request queries. Or the first preset security policy of the local security detection and the second preset security policy of the secondary security detection may be disjoint sets, so that security detection of different policies is respectively implemented at two ends of the user equipment and the edge node, so that the security detection is more comprehensive.

In step S403, if the secondary security detection is passed, the edge node forwards the original DNS request to the DNS server, so that the DNS server determines, according to the original DNS request, the IP address corresponding to the domain name requested to be queried by the DNS server.

Because the user equipment can be locally encrypted through the secure DNS client, the DNS request is in an encrypted state when sent from the user equipment, and even if the DNS request is intercepted by intermediate equipment such as routing equipment and gateway equipment, the DNS request cannot be decrypted to obtain private information, so that the private information can be effectively prevented from being stolen or monitored by service providers of the intermediate equipment such as the routing equipment and the gateway equipment, and the safety of the scheme is improved; meanwhile, the security detection mechanism is split into two parts, namely, the local security detection is carried out at the user equipment, the original DNS request through the local security detection is only encrypted and sent, the inquiry for the unsafe domain name can be blocked in advance before the DNS request is sent, the waste of network resources is avoided, the processing efficiency is improved, meanwhile, the accuracy of the security detection is ensured through the secondary security detection which is carried out at the edge node more comprehensively, and the security risk caused by the incomplete local detection is avoided.

In some embodiments of the present application, the second preset security policy adopted by the edge node during the processing, the decryption manner of decrypting the encrypted DNS request, and the configuration information such as the port for receiving the encrypted DNS request may all be obtained from the management node. For example, after obtaining the configuration information provided by the user, the management node may push the configuration information to the corresponding edge node, where the configuration information may include a second preset security policy for secondary security detection, a decryption manner for decrypting the encrypted DNS request, a port for receiving the encrypted DNS request, and so on.

The management node refers to a device capable of providing configuration information for an edge node or a secure DNS client of the user equipment, the edge node refers to a device capable of implementing secure transmission of DNS requests between the secure DNS client of the user equipment and a DNS server, in the embodiment of the present application, the actual devices corresponding to the management node and the edge node are not limited, and any device capable of implementing a corresponding processing function may be regarded as the management node or the edge node in the embodiment of the present application. In an actual scenario, the corresponding processing function of the management node may be deployed in any one of the edge nodes in the edge cloud network, so that the edge node may provide the corresponding processing function of the management node. Alternatively, the respective processing functions of the management node may also be deployed in a device in an external network outside the edge cloud network, such that the device may provide the respective processing functions of the management node to the edge node or the user device.

In addition, the method provided by the embodiment of the application can further comprise a processing procedure of returning a DNS response to the user equipment by the DNS server. Thus, the DNS request processing method provided by the embodiment of the present application further includes:

the edge node receives an original DNS reply returned based on the original DNS request from the DNS server;

the edge node encrypts the original DNS response to generate an encrypted DNS response;

the edge node sends the encrypted DNS reply to the secure DNS client of the user device.

In the user equipment, the secure DNS client may receive the encrypted DNS reply sent by the edge node, then decrypt the DNS reply to obtain an original DNS reply, and forward the original DNS reply to the application program that initiates the original DNS request. In the process of returning the DNS response, the processing of the DNS response and the processing mode of the DNS request can adopt a corresponding mode to encrypt and decrypt so as to ensure that the DNS response can also avoid the leakage of privacy information and ensure enough safety in the process of returning the DNS response from the DNS server to the application program in the user equipment according to the original path.

Fig. 5 shows an overall flow of implementing DNS request processing using the solution provided by the embodiment of the present application, where the devices involved in the solution include at least a user device 510, an edge node 520, a management node 530, and a DNS server 540. The interaction process between the devices comprises the following steps:

in step S501, the administrator user creates a corresponding access control rule on the management node of the edge cloud platform, where the access control rule may include a blacklist or a whitelist corresponding to the first preset security policy and the second preset security policy, an encryption manner of the domain name, and a corresponding port.

The administrator user may be a security manager of the CDN service provider or a security manager of the tenant.

In step S502, the management node generates corresponding configuration information based on the access control rule, and issues the configuration information about the edge node to the edge node.

In step S503, when the secure DNS client of the user equipment is started, configuration information about the secure DNS client is acquired from the management node.

Step S504, modifying the DNS address in the operating system of the user equipment to be a local address, for example, modifying the DNS address to be: 127.0.0.1 so that DNS requests issued by applications can be hijacked by secure DNS clients.

In step S505, the application APP1, when accessing a domain name, sends a query packet about the DNS request to the local secure DNS client.

In step S506, the secure DNS client first performs local security detection on the query packet. The specific process of security detection may include: analyzing the domain name to be queried, then carrying out matching query according to the white list or the black list of the local domain name classification library to judge whether blocking occurs, and then carrying out matching query again according to the white list or the black list of the local threat information library for the domain name which is not blocked to judge whether blocking occurs.

Step S507, for the query data packet passing the security detection, the security DNS client encrypts the query data packet by a preset encryption mode to generate an encrypted query data packet. The encryption method used in this embodiment includes a DoH or DoT encryption method.

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

In step S509, after receiving the query packet through the designated port, the edge node decrypts the query packet in a corresponding manner, and then performs secondary security detection.

In step S510, for the query packet passing the secondary security detection, the edge node forwards the query packet to the DNS server to determine the IP address corresponding to the domain name.

In step S511, the DNS server generates a response packet including the IP address, and returns the response packet to the application APP1 in the original path and in a corresponding encryption and decryption manner, so as to complete DNS query of the domain name, so that the application APP1 can continue the access flow of the domain name.

The embodiment of the application also provides a DNS request processing device, where the device is a user device, and the structure of the user device is shown in fig. 6, and the device includes a secure DNS client 600, where the secure DNS client 600 includes a receiving module 610, a security detecting module 620, an encrypting module 630, and a sending module 640. The receiving module 610 is configured to obtain an original DNS request sent by an application program; the security detection module 620 is configured to perform local security detection on the original DNS request; the encryption module 630 is configured to encrypt the original DNS request when passing through local security detection, and generate an encrypted DNS request; the sending module 640 is configured to send the encrypted DNS request to an edge node, so that the edge node decrypts the encrypted DNS request to obtain a corresponding original DNS request, performs secondary security detection on the original DNS request, and requests DNS resolution based on the original DNS request that passes the secondary security detection.

The security detection module 620 is configured to solve the requested domain name according to the original DNS request, determine whether the requested domain name meets a first preset security policy corresponding to the local security detection, and if yes, determine that the domain name passes the local security detection.

The first preset security policy includes at least any one of the following:

the requested domain name exists on a white list of the local domain name classification library;

the requested domain name does not exist in the blacklist of the local domain name classification library;

the requested domain name exists on a white list of the local threat intelligence library;

the requested domain name does not exist in the blacklist of the local threat intelligence library.

The encryption module 630 is configured to encrypt the original DNS request by using a preset encryption manner, so as to generate a corresponding encrypted DNS request.

The sending module 640 is configured to send the encrypted DNS request to an edge node through a port corresponding to the encryption manner.

The receiving module 610 is further configured to obtain configuration information created by a user from a management node, where the configuration information includes a first preset security policy of local security detection, an encryption manner of encrypting the original DNS request, and a port for sending an encrypted DNS request.

The receiving module 610 is further configured to receive an encrypted DNS reply sent by the edge node;

the secure DNS client further includes a decryption module configured to decrypt the DNS reply to obtain an original DNS reply, and the sending module 640 is further configured to forward the original DNS reply to the application that originated the original DNS request.

The encryption module 630 is configured to encrypt the original DNS request by using a DoT or DoH manner, and generate an encrypted DNS request.

The embodiment of the present application provides another DNS request processing device, which is an edge node, and its structure is shown in fig. 7, and at least includes a receiving module 710, a decrypting module 720, a security detecting module 730, and a sending module 740. The receiving module 710 is configured to receive an encrypted DNS request sent by a secure DNS client of the user equipment, where the encrypted DNS request is generated by performing secondary security detection on an original DNS request sent by an application program by the secure DNS client, and performing encryption after the secondary security detection; the decryption module 720 is configured to decrypt the encrypted DNS request to obtain a corresponding original DNS request; the security detection module 730 is configured to perform secondary security detection on the original DNS request; the sending module 740 is configured to forward the original DNS request to a DNS server when passing the secondary security detection.

The decryption module 720 is configured to decrypt the encrypted DNS request by using a preset decryption manner, and obtain a corresponding original DNS request.

The receiving module 710 is configured to receive, through a preset port, an encrypted DNS request sent by a secure DNS client of the user equipment;

the decryption module 720 is configured to decrypt the encrypted DNS request by using a decryption manner corresponding to a preset port, and obtain a corresponding original DNS request.

The security detection module 730 is configured to solve and separate out the requested domain name according to the original DNS request; and judging whether the requested domain name accords with a second preset security policy corresponding to the secondary security detection, and if so, judging that the domain name passes the secondary security detection.

The second preset security policy includes at least any one of:

the requested domain name exists in a white list of a cloud domain name classification library;

the requested domain name does not exist in the blacklist of the cloud domain name classification library;

the requested domain name exists in a white list of a cloud hypochondriac information library;

the requested domain name does not exist in the blacklist of the cloud threat intelligence library.

The receiving module 710 is further configured to receive, from the DNS server, an original DNS reply returned based on the original DNS request;

The edge node further comprises an encryption module for encrypting the original DNS response to generate an encrypted DNS response;

the sending module 740 is further configured to send the encrypted DNS response to a secure DNS client of the user equipment, so that after the secure DNS client decrypts the encrypted DNS response, the original DNS response obtained by decryption is forwarded to the application program that initiates the original DNS request.

The decryption module 720 is configured to decrypt the encrypted DNS request by using a DoT or DoH manner, and obtain a corresponding original DNS request.

The embodiment of the application also provides a DNS request processing system, which comprises user equipment and an edge node, wherein,

In addition, an embodiment of the present application further provides a DNS request processing device, where the structure of the device is shown in fig. 8, and the device includes a memory 810 for storing computer readable instructions and a processor 820 for executing the computer readable instructions, where the computer readable instructions when executed by the processor trigger the processor to execute the DNS request processing method.

The methods and/or embodiments of the present application may be implemented as a computer software program. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flowcharts. The above-described functions defined in the method of the application are performed when the computer program is executed by a processing unit.

The computer readable medium according to the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

In the present application, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations of the present application may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).

The flowchart or block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of devices, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

As another aspect, the embodiment of the present application also provides a computer-readable medium that may be contained in the apparatus described in the above embodiment; or may be present alone without being fitted into the device. The computer readable medium carries one or more computer readable instructions executable by a processor to perform the steps of the methods and/or aspects of the various embodiments of the application described above.

In addition, the embodiment of the application also provides a computer program which is stored in the computer equipment, so that the computer equipment executes the method for executing the control code.

It should be noted that the present application may be implemented in software and/or a combination of software and hardware, e.g., using Application Specific Integrated Circuits (ASIC), a general purpose computer or any other similar hardware device. In some embodiments, the software program of the present application may be executed by a processor to implement the above steps or functions. Likewise, the software programs of the present application (including associated data structures) may be stored on a computer readable recording medium, such as RAM memory, magnetic or optical drive or diskette and the like. In addition, some steps or functions of the present application may be implemented in hardware, for example, as circuitry that cooperates with the processor to perform various steps or functions.

It will be evident to those skilled in the art that the application is not limited to the details of the foregoing illustrative embodiments, and that the present application may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive, the scope of the application being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Any reference sign in a claim should not be construed as limiting the claim concerned. Furthermore, it is evident that the word "comprising" does not exclude other elements or steps, and that the singular does not exclude a plurality. A plurality of units or means recited in the apparatus claims can also be implemented by means of one unit or means in software or hardware. The terms first, second, etc. are used to denote a name, but not any particular order.

Claims

1. A DNS request processing method, wherein the method is applied to a user equipment, the user equipment including a secure DNS client, the method comprising:

2. The method of claim 1, wherein the secure DNS client performing local security detection on the original DNS request comprises:

the secure DNS client solves and separates out the requested domain name according to the original DNS request;

and the secure DNS client judges whether the requested domain name accords with a first preset security policy corresponding to the local security detection, and if so, the domain name is judged to pass the local security detection.

3. The method of claim 2, wherein the first preset security policy comprises at least any one of:

4. The method of claim 1, wherein the secure DNS client encrypting the original DNS request to generate an encrypted DNS request comprises:

and the secure DNS client encrypts the original DNS request by adopting a preset encryption mode to generate a corresponding encrypted DNS request.

5. The method of claim 4, wherein the secure DNS client sending the encrypted DNS request to an edge node comprises:

and the secure DNS client sends the encrypted DNS request to an edge node through a port corresponding to the encryption mode.

6. The method according to claim 1, wherein the method further comprises:

the secure DNS client obtains configuration information created by a user from a management node, where the configuration information includes a first preset security policy for local security detection, an encryption manner for encrypting the original DNS request, and a port for sending the encrypted DNS request.

7. The method according to claim 1, wherein the method further comprises:

the secure DNS client receives an encrypted DNS response sent by the edge node;

and the secure DNS client decrypts the DNS response to obtain an original DNS response, and forwards the original DNS response to an application program initiating the original DNS request.

8. The method of claim 1, wherein the secure DNS client encrypting the original DNS request to generate an encrypted DNS request comprises:

and the secure DNS client encrypts the original DNS request in a DOT or DoH mode to generate an encrypted DNS request.

9. A DNS request processing method, wherein the method is applied to an edge node, the method comprising:

10. The method of claim 9, wherein the edge node decrypting the encrypted DNS request to obtain a corresponding original DNS request, comprising:

and the edge node decrypts the encrypted DNS request by adopting a preset decryption mode to acquire a corresponding original DNS request.

11. The method of claim 10, wherein the edge node receiving the secure DNS client send encrypted DNS request for the user device comprises:

the edge node receives a secure DNS request sent by a secure DNS client of the user equipment through a preset port;

the edge node decrypts the encrypted DNS request by adopting a preset decryption mode to obtain a corresponding original DNS request, which comprises the following steps:

and the edge node decrypts the encrypted DNS request by adopting a decryption mode corresponding to a preset port to acquire a corresponding original DNS request.

12. The method of claim 9, wherein the edge node performs a secondary security check on the original DNS request, comprising:

The edge node solves and separates out the domain name requested according to the original DNS request;

and the edge node judges whether the requested domain name accords with a second preset security policy corresponding to the secondary security detection, and if so, the edge node judges that the domain name passes the secondary security detection.

13. The method of claim 12, wherein the second preset security policy comprises at least any one of:

14. The method according to claim 9, wherein the method further comprises:

and the edge node sends the encrypted DNS response to a secure DNS client of the user equipment, so that the secure DNS client decrypts the encrypted DNS response and then forwards an original DNS response obtained by decryption to an application program which initiates the original DNS request.

15. The method of claim 1, wherein the edge node decrypting the encrypted DNS request to obtain a corresponding original DNS request, comprising:

and the edge node decrypts the encrypted DNS request in a DOT or DoH mode to acquire a corresponding original DNS request.

16. A DNS request processing device, wherein the device is a user device, the user device including a secure DNS client, the secure DNS client comprising:

17. A DNS request processing device, wherein the device is an edge node, the edge node comprising:

18. A DNS request processing system, comprising a user equipment and an edge node, wherein,

19. A DNS request processing device, the device comprising:

one or more processors; and

a memory storing computer program instructions that, when executed, cause the processor to perform the method of any one of claims 1 to 15.

20. A computer readable medium having stored thereon computer program instructions executable by a processor to implement the method of any of claims 1 to 15.