A method, system, device and storage medium for DNS traffic processing

By hijacking DNS traffic on the local client and encrypting it using a private protocol, the security issues caused by DNS resolution relying on third-party CA service providers are resolved, resulting in faster negotiation speeds and higher data security.

CN116781287BActive Publication Date: 2026-07-07SHANGHAI YUNDUN INFORMATION TECH

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
SHANGHAI YUNDUN INFORMATION TECH
Filing Date
2022-03-07
Publication Date
2026-07-07

Smart Images

  • Figure CN116781287B_ABST
    Figure CN116781287B_ABST
Patent Text Reader

Abstract

The application aims to provide a DNS traffic processing method, system, device and storage medium. The application hijacks local DNS traffic through a client, resolves the DNS traffic, and performs corresponding processing on the DNS traffic based on a preset rule. When the DNS traffic matches the preset rule, the destination address of the DNS traffic is rewritten as the address of a specified DNS server, and the DNS traffic is encrypted. The encrypted DNS traffic is sent to an edge node, so that the edge node performs security check on the encrypted DNS traffic, and sends the DNS traffic passing the security check to the specified DNS server according to the address of the specified DNS server. Thus, the processing efficiency is improved, and the risk of data leakage is reduced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of computers, and more particularly to a method, system, device, and storage medium for DNS traffic processing. Background Technology

[0002] In the current network environment, the traditional DNS (Domain Name System) resolution process is vulnerable to various attacks, which may lead to data leakage risks, making it impossible to guarantee the security and performance of traditional DNS resolution servers.

[0003] In existing technologies, data is often encrypted using protocols such as DOH (DNS over HTTPS) or DOT (DNS over TLS) and then sent to a secure DNS resolution server.

[0004] However, both the DOH and DOT protocols rely on the security of the TLS (Transport Layer Security) protocol, which in turn depends heavily on third-party CA (Certified Authority) service providers. If a third-party CA service provider experiences an operational or security incident, its authentication services will become unavailable, directly impacting end-users of the enterprise's IT services. Furthermore, the possibility of attacks cannot be ruled out, as some countries may have control over third-party CA service providers. Summary of the Invention

[0005] One objective of this application is to provide a method, system, device, and storage medium for DNS traffic processing, in order to solve the problem that DNS resolution and encryption in the prior art are vulnerable to attack due to their reliance on third-party CA service providers.

[0006] According to one aspect of this application, a method for processing DNS traffic is provided, applied to a client, the method comprising:

[0007] Local DNS traffic was hijacked and redirected to the client.

[0008] The client parses the DNS traffic and processes it according to preset rules, including: when the DNS traffic matches the preset rules, rewriting the destination address of the DNS traffic to the address of a specified DNS server, encrypting the DNS traffic, and sending the encrypted DNS traffic to an edge node so that the edge node can perform a security check on the encrypted DNS traffic and send the DNS traffic that passes the security check to the specified DNS server according to the address of the specified DNS server.

[0009] Optionally, the DNS traffic is encrypted, including:

[0010] The DNS traffic is encrypted using a proprietary protocol.

[0011] Optionally, the preset rules include a set of first domain names for which a specified DNS needs to be enabled, and the method further includes:

[0012] When the domain name corresponding to the DNS traffic has a match with the first set of domain names that need to enable the specified DNS, it is determined that the DNS traffic matches the preset rule.

[0013] Optionally, the method further includes:

[0014] When the domain name corresponding to the DNS traffic does not match the first set of domain names that need to enable the specified DNS, it is determined that the DNS traffic does not match the preset rule.

[0015] Optionally, the client resolving the DNS traffic and processing the DNS traffic accordingly based on preset rules further includes:

[0016] When the DNS traffic does not match the preset rule, the client does not rewrite the destination address of the DNS traffic, wherein the destination address of the DNS traffic is the address of the default DNS server;

[0017] The DNS traffic is encrypted and then sent to an edge node. The edge node performs a security check on the encrypted DNS traffic and sends the DNS traffic that passes the security check to the default DNS server according to the address of the default DNS server.

[0018] Optionally, the method includes:

[0019] The client receives the preset rules from the management platform.

[0020] This application also provides a method for DNS traffic processing applied to edge nodes, the method comprising:

[0021] Retrieve encrypted DNS traffic sent by the client;

[0022] The encrypted DNS traffic sent by the client is subjected to a security check. Based on the destination address of the DNS traffic, the DNS traffic that passes the security check is sent to the address of the specified DNS server or the default DNS server.

[0023] Optionally, a security check is performed on the encrypted DNS traffic sent by the client, including:

[0024] The data packets corresponding to the DNS traffic are decrypted to obtain the decrypted DNS traffic;

[0025] A security check is performed on the packets corresponding to the decrypted DNS traffic.

[0026] This application also provides a method for DNS traffic processing, applied to a management platform, the method comprising:

[0027] Get preset rules;

[0028] The preset rules are sent to the client so that the client can process the hijacked DNS traffic to the client's local network according to the preset rules.

[0029] Optionally, the preset rules include a first set of domain names that need to enable a specified DNS, such that when the domain name corresponding to the DNS traffic matches the first set of domain names that need to enable a specified DNS, the destination address of the DNS traffic that has been hijacked to the client's local DNS traffic is rewritten to the address of the specified DNS server, the DNS traffic is encrypted, and the encrypted DNS traffic is sent to the edge node for security check.

[0030] This application also provides a system for DNS traffic processing, the system including a client, a management platform, edge nodes, and a designated DNS server, wherein...

[0031] The client is used to hijack local DNS traffic, parse the DNS traffic, and process the DNS traffic according to preset rules, including: when the DNS traffic matches the preset rules, rewriting the destination address of the DNS traffic to the address of a specified DNS server, encrypting the DNS traffic, and sending the encrypted DNS traffic to the edge node.

[0032] The management platform is used to obtain preset rules and send the preset rules to the client;

[0033] The edge node is used to obtain the encrypted DNS traffic sent by the client, perform security checks on the encrypted DNS traffic sent by the client, and send the DNS traffic that has passed the security check to the address of the specified DNS server or the default DNS server according to the destination address of the DNS traffic.

[0034] The designated DNS server is used to obtain DNS traffic sent by the edge node that has passed security checks, and to respond to the DNS traffic that has passed security checks.

[0035] This application embodiment also provides a device for DNS traffic processing, the device comprising:

[0036] One or more processors; and

[0037] A memory storing computer-readable instructions that, when executed, cause the processor to perform the operations of the method for DNS traffic processing.

[0038] This application also provides a computer-readable medium storing computer-readable instructions that can be executed by a processor to implement the method for DNS traffic processing.

[0039] Compared to existing technologies, the DNS traffic processing scheme provided in this application involves a client intercepting local DNS traffic, resolving the DNS traffic, and processing it according to preset rules. When the DNS traffic matches the preset rules, the destination address of the DNS traffic is rewritten to the address of a specified DNS server, and the DNS traffic is encrypted. The encrypted DNS traffic is then sent to an edge node, where the edge node performs a security check on the encrypted DNS traffic and forwards the securely checked DNS traffic to the specified DNS server based on the address of the specified DNS server. Compared to traditional TLS-based schemes that require algorithm negotiation to adapt to various browsers, the scheme in this application can omit algorithm negotiation and directly perform key negotiation, resulting in faster negotiation speed and improved efficiency. Furthermore, since DNS redirection is performed on the local client, the risk of data leakage is reduced, improving data security. Attached Figure Description

[0040] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0041] Figure 1 The present application illustrates the processing flow of a DNS traffic processing method provided in an embodiment of this application;

[0042] Figure 2 The present application illustrates the processing flow of a DNS traffic processing method provided in an embodiment of this application;

[0043] Figure 3 This application illustrates a method for processing DNS traffic according to an embodiment of the present application.

[0044] Figure 4 This invention illustrates a system framework for DNS traffic processing according to one aspect of this application;

[0045] Figure 5 The present application illustrates the structure of a device for DNS traffic processing according to an embodiment of the present application;

[0046] Figure 6 This application illustrates a method flow for DNS traffic processing according to one embodiment. Detailed Implementation

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] Currently, most market solutions encrypt data using protocols such as DOH (DNS over HTTPS) or DOT (DNS over TLS) and send the DNS data to a secure DNS resolution server. However, those skilled in the art will understand that both DOH and DOT protocols rely on the security of the TLS protocol, which in turn depends primarily on third-party CA (Certificate Authority) service providers. If a third-party CA service provider experiences an operational or security incident, its authentication services will become unavailable, directly impacting end-users of the enterprise's IT services. Furthermore, the possibility that third-party CA service providers may have control in some countries makes them vulnerable to attack.

[0052] This application encrypts DNS traffic through a local client, without relying on a third-party CA service provider, thus offering higher security. Furthermore, compared to traditional TLS schemes that require algorithm negotiation to adapt to various browsers, this application omits algorithm negotiation and directly performs key negotiation, resulting in faster speed.

[0053] In a DNS traffic processing scheme provided in this application embodiment, the client intercepts local DNS traffic, parses the DNS traffic, and processes the DNS traffic according to preset rules. When the DNS traffic matches the preset rules, the destination address of the DNS traffic is rewritten to the address of a specified DNS server, and the DNS traffic is encrypted. The encrypted DNS traffic is then sent to an edge node, whereby the edge node performs a security check on the encrypted DNS traffic and forwards the DNS traffic that passes the security check to the specified DNS server according to the address of the specified DNS server. Compared to traditional TLS-based schemes that require algorithm negotiation to adapt to various browsers, the scheme in this application embodiment can omit algorithm negotiation and directly perform key negotiation, thereby making the negotiation faster and improving negotiation efficiency. Since DNS traffic redirection is performed on the local client, the risk of data leakage can be reduced, and data security can be improved.

[0054] Figure 1 This application illustrates a processing flow of a DNS traffic processing method provided in an embodiment of the present application. The method is applied to a client and includes at least the following processing steps:

[0055] In step S101, local DNS traffic is hijacked to the client.

[0056] Following the above embodiments, in practical application scenarios, local DNS traffic can be hijacked to the client by modifying the routing table. For example, the default DNS target address can be read, and the client adds the default DNS target address to the routing table to hijack the local DNS traffic resolution logic to the client. Here, a virtual network interface card can be used to hijack local DNS traffic to the client by changing the routing table. It should be noted that the client is installed on the local system, so the DNS traffic processing is all done locally, without involving the network environment or relying on a third-party CA service provider, effectively improving security.

[0057] Step S102: The client parses the DNS traffic and processes it according to preset rules, including: when the DNS traffic matches the preset rules, rewriting the destination address of the DNS traffic to the address of a specified DNS server, encrypting the DNS traffic, and sending the encrypted DNS traffic to an edge node. The edge node then performs a security check on the encrypted DNS traffic and forwards the DNS traffic that passes the security check to the specified DNS server according to its address. By redirecting DNS traffic on the local client, the risk of data leakage is reduced.

[0058] Following the above embodiment, the client parses the DNS traffic, confirms the domain name corresponding to the DNS traffic, and then determines whether the domain name is one of the domain names specified in the preset rules. If so, it can be determined that the DNS traffic matches the preset rules, and the destination address in the IP data packet of the DNS traffic is modified to the address of the specified DNS server. The specified DNS server can be a secure DNS server, which is a designated trusted server used to resolve DNS data packets. Next, the DNS traffic is encrypted on the client. In some embodiments, the encrypted DNS traffic can be diverted to an edge node by adding edge node location information to the header of the data packet corresponding to the DNS traffic. This allows the edge node to perform a security check on the encrypted DNS traffic and send the DNS traffic that passes the security check to the specified DNS server according to the address of the specified DNS server.

[0059] It should be noted that the encryption method used in this application can be any encryption method, and this embodiment does not specifically limit it.

[0060] In an optional embodiment of this application, in step S102, a private protocol can be used to encrypt the DNS traffic. The private protocol used can be a user-defined private network protocol, independent of third-party CA service providers, offering higher security. Compared to traditional secure DNS resolution methods that rely on TLS, this private encryption protocol predefines the algorithm, requiring only key negotiation and eliminating the need for algorithm negotiation. Therefore, the negotiation process only requires a single handshake, resulting in faster handshake speeds and improved negotiation efficiency.

[0061] It should be understood by those skilled in the art that the above-described encryption of DNS traffic using a proprietary protocol is merely an example, and other existing or future forms based on similar principles that are applicable to this application should also be included within the scope of protection of this application and are incorporated herein by reference.

[0062] In some embodiments of this application, the preset rule may include a first set of domain names that need to enable a specified DNS. Here, when the domain name corresponding to the DNS traffic has a match with the first set of domain names that need to enable a specified DNS, it is determined that the DNS traffic matches the preset rule.

[0063] Following the above embodiments, the preset rules can be customized by the user based on their needs. The preset rules set a first set of domain names that need to enable a specified DNS. The first set of domain names that need to enable a specified DNS and the domain names corresponding to the DNS traffic are obtained. It is determined whether there is a match between the two. If there is a match, it is determined that the DNS traffic matches the preset rules.

[0064] In an optional embodiment of this application, enterprises can freely configure the domain names that need to be resolved by a secure DNS resolution server. When enterprise employees access domain names that require secure DNS, all DNS traffic is intercepted to the client, encrypted, and then sent to the secure DNS server. The secure DNS server performs data resolution processing, ensuring data security and thus avoiding the risk of data leakage.

[0065] In an optional embodiment of this application, when the domain name corresponding to the DNS traffic does not match the first set of domain names for which a specified DNS needs to be enabled, it is determined that the DNS traffic does not match the preset rule. When the DNS traffic does not match the preset rule, it is not necessary to enable the specified DNS server.

[0066] In an optional embodiment of this application, the domain name corresponding to the current DNS traffic is domain name A. This domain name requires enabling secure DNS, and it defaults to accessing DNS server X for resolution. However, due to the routing table configuration, this DNS resolution traffic enters the client through a virtual network interface card, and the destination address of this DNS resolution traffic is X. A first set of domain names requiring the use of a specific DNS is set within a preset rule. The first set of domain names requiring the use of a specific DNS and the domain name corresponding to the DNS traffic are obtained, and it is determined whether there is a match between them. If there is a match, it is determined that the DNS traffic matches the preset rule. When the DNS traffic does not match the preset rule, it is not necessary to enable the specific DNS server. By matching the preset rule saved in the client, it is determined that the DNS traffic is a domain name requiring the use of a specific DNS. Therefore, the destination address of the data packet is replaced with the address Y of the specific DNS server, and the data packet is encrypted.

[0067] Following the above embodiments, the client can record the processed data in the form of log information, which facilitates the later viewing of all DNS traffic records hijacked by the client, including DNS traffic sent by the client to the default DNS server and DNS traffic sent by the client to the specified DNS server.

[0068] In an optional embodiment of this application, in step S102, when the DNS traffic does not match the preset rule, the client does not rewrite the destination address of the DNS traffic, wherein the destination address of the DNS traffic is the address of the default DNS server. Then, the DNS traffic is encrypted and sent to the edge node, so that the edge node performs a security check on the encrypted DNS traffic and sends the DNS traffic that passes the security check to the default DNS server according to the address of the default DNS server.

[0069] Following the above embodiment, when the DNS traffic does not match the set of domain names requiring the activation of a specified DNS server in the preset rules, the client does not rewrite the destination address of the DNS traffic; the destination address of the DNS traffic is the address of the default DNS server. Next, the DNS traffic can be encrypted, where the encryption method can be arbitrary. The encrypted DNS traffic is then sent to an edge node, where the edge node performs a security check on the encrypted DNS traffic and forwards the DNS traffic that passes the security check to the default DNS server based on its address. The client determines that the hijacked DNS traffic does not require the activation of a specified DNS server through domain name resolution; therefore, it directly redirects the DNS traffic to the default DNS server, allowing the default DNS server to perform the default DNS traffic resolution processing. The default DNS server is the local default DNS resolution server.

[0070] Optionally, the client is installed locally on the terminal. After receiving preset rules from the management platform, the terminal can control the data path of DNS traffic from the initiator to the receiver. Since the local DNS traffic is intercepted on the client, it is convenient to perform various resolutions and modifications on the DNS, and then interface with other DNS acceleration solutions. It can easily perform functions such as encryption, resolution, attack detection, or acceleration of DNS traffic data. Specifically, the subsequent access address can be specified for all DNS traffic data involved in the application, which can easily perform encryption, resolution, attack detection, acceleration, etc., such as replacing the DNS resolution address, and the address accessed by the application can be controlled by the client.

[0071] It should be noted that the terminals include, but are not limited to, mobile terminals, PCs, and other devices.

[0072] In an optional embodiment of this application, the client can receive the preset rules from the management platform. The client obtains the preset rules sent by the management platform and stores the first set of domain names requiring the use of a specified DNS and the address of the specified DNS server in its local memory. This is used to match whether the DNS traffic should be redirected to the specified DNS server after it is intercepted at the client. Here, the DNS traffic data using the preset rules can be determined by viewing the configuration of the management platform and recording the domain names using the specified DNS.

[0073] Figure 2 This application illustrates a processing flow of a DNS traffic processing method provided in an embodiment of the present application. The method is applied to edge nodes and includes at least the following processing steps:

[0074] Step S201: Obtain the encrypted DNS traffic sent by the client.

[0075] Following the above embodiment, the client adds the IP address of the edge node to the header of the DNS traffic data packet and sends the encrypted DNS traffic data packet to the edge node. Thus, the edge node can obtain the encrypted DNS traffic sent by the client through the physical network card.

[0076] Optionally, users can capture data packets from the physical network interface card (NIC) and view all plaintext DNS data passing through the NIC to determine the domain names corresponding to all DNS traffic passing through the NIC and related data such as the access time, sending time, and data size of the DNS traffic.

[0077] Step S202: Perform a security check on the encrypted DNS traffic sent by the client. Based on the destination address of the DNS traffic, forward the DNS traffic that passes the security check to the address of the specified DNS server or the default DNS server. To ensure the security of DNS resolution, the client encrypts all DNS traffic sent to the edge node, and the edge node can perform a security check on the DNS packet. The edge node can be, but is not limited to, a POP point.

[0078] Following the above embodiment, after removing the IP address of the edge node added by the client to the header of the encrypted DNS traffic data packet, a security check is performed on the encrypted DNS traffic sent by the client. This security check includes, but is not limited to, packet verification checks. Based on the destination address of the DNS traffic, the DNS traffic that passes the security check is sent to the address of a designated DNS server or the default DNS server.

[0079] In an optional embodiment of this application, the destination address of DNS traffic is the address of the local default DNS server by default. When the client changes the destination address of DNS traffic to a specified DNS server address, the DNS traffic is redirected to the specified DNS server to ensure data security.

[0080] In an optional embodiment of this application, in step S202, the data packets corresponding to the DNS traffic are decrypted to obtain decrypted DNS traffic; and the packets corresponding to the decrypted DNS traffic are subjected to security checks.

[0081] For example, an edge node can be a Point of Presence (POP). The POP decrypts the DNS traffic by processing the data packets corresponding to the DNS traffic using a proprietary protocol, and then performs security checks, such as verification, on the packets corresponding to the decrypted DNS traffic. Optionally, packets corresponding to the DNS traffic can be captured at the edge node, allowing users to subsequently check whether any DNS data packets forwarded by clients have passed through that edge node, thus identifying all DNS traffic passing through it.

[0082] Figure 3 This application illustrates a DNS traffic processing method flow provided by an embodiment of the present application. The method is applied to a management platform and includes at least the following processing steps:

[0083] Step S301: Obtain preset rules.

[0084] Following the above embodiments, the management platform obtains the user's preset configuration policy information and determines the corresponding preset rules based on the configuration policy information; the management platform may also obtain preset rules from any other source.

[0085] Step S302: Send the preset rules to the client so that the client can process the hijacked DNS traffic to the client's local network according to the preset rules.

[0086] Following the above embodiment, the preset rules are sent to the client so that the client can obtain the preset rules of the management platform and store the domain names that need to enable the specified DNS and the specified DNS server addresses in memory. Then, the DNS traffic that has been hijacked to the client's local machine is processed accordingly based on the preset rules.

[0087] In an optional embodiment of this application, the preset rule includes a first set of domain names that need to enable a specified DNS, such that when the domain name corresponding to the DNS traffic matches the first set of domain names that need to enable a specified DNS, the destination address of the DNS traffic that has been hijacked to the client's local DNS traffic is rewritten to the address of the specified DNS server, the DNS traffic is encrypted, and the encrypted DNS traffic is sent to the edge node for security check.

[0088] Figure 4This paper illustrates a system framework for DNS traffic processing according to one aspect of this application. The system includes a client 401, a management platform 402, an edge node 403, and a designated DNS server 404. The client 401 is used to intercept local DNS traffic, resolve the DNS traffic, and process the DNS traffic according to preset rules. Specifically, when the DNS traffic matches the preset rules, the destination address of the DNS traffic is rewritten to the address of the designated DNS server 404, the DNS traffic is encrypted, and the encrypted DNS traffic is sent to the edge node. 403; The management platform 402 is used to obtain preset rules and send the preset rules to the client 401; The edge node 403 is used to obtain the encrypted DNS traffic sent by the client 401, perform a security check on the encrypted DNS traffic sent by the client 401, and send the DNS traffic that passes the security check to the address of the specified DNS server 404 or the address of the default DNS server according to the destination address of the DNS traffic; The specified DNS server 404 is used to obtain the DNS traffic that passes the security check sent by the edge node 403 and respond to the DNS traffic that passes the security check.

[0089] It should be noted that the client is installed on the local system, therefore the processing of hijacked DNS traffic is all done locally, without relying on a third-party CA service provider, effectively improving security. Simultaneously, after the DNS traffic is encrypted by the client 401 and sent to the edge node 403, the edge node 403 sends the DNS traffic data packet that passes the security check to the address of the designated DNS server or the default DNS server. This secure DNS traffic data packet, after having its edge node IP address removed from the packet header by the edge node 403, is then sent completely to the designated DNS server 404 while still encrypted. When the designated DNS server 404 receives the secure DNS traffic sent by the edge node 403, it responds to the secure DNS traffic, for example, by returning the encrypted DNS traffic data packet along the original path, ensuring that the DNS traffic returns to the application using the DNS traffic while remaining encrypted throughout the entire process, thus guaranteeing data security. The system and / or embodiments in this example can be implemented in conjunction with any of the foregoing method embodiments.

[0090] Furthermore, embodiments of this application also provide a structure for a device used for DNS traffic processing, such as... Figure 5 As shown, the device includes one or more processors 502 for DNS traffic processing and a memory 501 storing computer-readable instructions that, when executed, cause the processors 502 to perform the method for DNS traffic processing.

[0091] Figure 6 This application illustrates a method flow for DNS traffic processing according to an embodiment of the present application, which includes at least the following steps:

[0092] Step S601: The client installed on the terminal obtains the preset rules from the management platform and stores the domain names and DNS server addresses that require specific DNS access, as contained in the specified rules, in the terminal's local memory. This allows users to freely configure the domain names requiring specific DNS access in the preset rules. For example, when an employee accesses a domain name that requires specific DNS access, all DNS traffic is intercepted into the client, encrypted, and then redirected to the specified DNS server. After intercepting the DNS traffic into the client, it is checked whether the DNS data traffic should be redirected to the specified DNS server, such as a secure DNS server. By performing DNS redirection on the local client, the risk of data leakage is effectively reduced.

[0093] In step S602, the client probes the terminal's default DNS resolution server address and hijacks the terminal's default DNS resolution logic to the client via a virtual network card by modifying the routing table. This allows the client to control the DNS traffic resolution process from the initiating end to the receiving end. Subsequently, the DNS resolution address can be freely controlled through the routing table, and subsequent access addresses can be specified for the application's DNS data traffic. This facilitates the encryption, resolution, attack detection, or acceleration of DNS traffic data.

[0094] In step S603, the client resolves the incoming DNS traffic and determines, based on preset rules, whether it belongs to a domain that requires enabling a specific DNS. If it does, the client modifies the destination address of the IP packet corresponding to the DNS traffic to the specified DNS server, encrypts the DNS packet using a private protocol, and adds a new IP address leading to the edge node to the packet header, redirecting the data to the edge node, such as a Point of Presence (POP). Subsequently, the client can capture packets from the POP to determine if any DNS data packets are forwarded by the client, or observe the POP's log information to identify all DNS traffic passing through the POP.

[0095] The new IP address mentioned above can be randomly assigned by the management platform, and this embodiment does not impose specific limitations on it.

[0096] In step S604, the POP removes the newly added IP address from the packet header, decrypts the encrypted DNS packet using a private protocol to restore the original DNS packet, and performs security checks on the corresponding message, such as data verification. The POP sends the encrypted DNS packet to the designated DNS server. The designated DNS server parses the encrypted DNS packet to obtain the IP address in the DNS traffic packet, records the IP address in a log, and then returns the corresponding DNS traffic packet to the application that used the DNS traffic in encrypted form via the original path.

[0097] Compared to traditional TLS schemes, which require an algorithm negotiation process to adapt to various browsers, this application omits algorithm negotiation and directly performs key negotiation, thereby making the negotiation speed faster and reducing the risk of data leakage.

[0098] The system and method and / or embodiment in this embodiment can be implemented in conjunction with any of the foregoing method embodiments and any of the foregoing system embodiments.

[0099] It should be noted that the step numbers above are only used to identify different steps and do not represent the execution order of the steps.

[0100] 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.

[0101] 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.

[0102] 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.

[0103] 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).

[0104] 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.

[0105] 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.

[0106] Furthermore, this application also provides a computer program stored in a computer device, which causes the computer device to perform the DNS traffic processing method.

[0107] 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, magnetic or optical drives, floppy disks, and 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.

[0108] 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 it 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 elements or steps, and the singular does not exclude the plural. Terms such as "first," "second," etc., are used to denote names and do not indicate any particular order.

Claims

1. A method for processing DNS traffic, characterized in that, Applied to a client, the method includes: Local DNS traffic was hijacked and redirected to the client. The client parses the DNS traffic and processes it accordingly based on preset rules, including: when the DNS traffic matches the preset rules, rewriting the destination address of the DNS traffic to the address of a specified DNS server, encrypting the DNS traffic, and sending the encrypted DNS traffic to an edge node so that the edge node can perform a security check on the encrypted DNS traffic and send the DNS traffic that passes the security check to the specified DNS server according to the address of the specified DNS server. The encryption of the DNS traffic includes encrypting the DNS traffic using a proprietary protocol.

2. The method according to claim 1, characterized in that, The preset rules include a set of first domain names that need to have a specified DNS enabled, and the method further includes: When the domain name corresponding to the DNS traffic has a match with the first set of domain names that need to enable the specified DNS, it is determined that the DNS traffic matches the preset rule.

3. The method according to claim 2, characterized in that, The method further includes: When the domain name corresponding to the DNS traffic does not match the first set of domain names that need to enable the specified DNS, it is determined that the DNS traffic does not match the preset rule.

4. The method according to claim 3, wherein, The client resolves the DNS traffic and processes the DNS traffic accordingly based on preset rules, further including: When the DNS traffic does not match the preset rule, the client does not rewrite the destination address of the DNS traffic, wherein the destination address of the DNS traffic is the address of the default DNS server; The DNS traffic is encrypted and then sent to an edge node. The edge node performs a security check on the encrypted DNS traffic and sends the DNS traffic that passes the security check to the default DNS server according to the address of the default DNS server.

5. The method according to any one of claims 1 to 3, characterized in that, The method includes: The client receives the preset rules from the management platform.

6. A method for processing DNS traffic, characterized in that, Applied to edge nodes, the method includes: The client obtains encrypted DNS traffic sent by the client. The encrypted DNS traffic is obtained by the client hijacking local DNS traffic, resolving the hijacked DNS traffic, and then processing the DNS traffic according to preset rules. When the hijacked DNS traffic matches the preset rules, the client rewrites the destination address of the DNS traffic to the address of a specified DNS server and encrypts the DNS traffic using a private protocol. The encrypted DNS traffic sent by the client is subjected to a security check. Based on the destination address of the DNS traffic, the DNS traffic that passes the security check is sent to the address of the specified DNS server or the default DNS server.

7. The method according to claim 6, characterized in that, The encrypted DNS traffic sent by the client is subjected to a security check, including: The data packets corresponding to the DNS traffic are decrypted to obtain the decrypted DNS traffic; A security check is performed on the packets corresponding to the decrypted DNS traffic.

8. A method for processing DNS traffic, characterized in that, Applied to a management platform, the method includes: Get preset rules; The preset rules are sent to the client so that the client can process the hijacked DNS traffic to the client's local network according to the preset rules. In this process, the client's local DNS traffic is intercepted and resolved. When the DNS traffic matches the preset rule, the destination address of the DNS traffic is rewritten to the address of the specified DNS server, and the DNS traffic is encrypted using a private protocol. The encrypted DNS traffic is then sent to the edge node, which performs a security check on the encrypted DNS traffic and forwards the DNS traffic that passes the security check to the specified DNS server according to the address of the specified DNS server.

9. The method according to claim 8, characterized in that, The preset rules include a first set of domain names that need to enable a specified DNS, so that when the domain name corresponding to the DNS traffic matches the first set of domain names that need to enable a specified DNS, the destination address of the DNS traffic that is hijacked to the client's local DNS traffic is rewritten to the address of the specified DNS server, the DNS traffic is encrypted, and the encrypted DNS traffic is sent to the edge node for security check.

10. A system for processing DNS traffic, characterized in that, The system includes a client, a management platform, edge nodes, and a designated DNS server, wherein, The client is used to hijack local DNS traffic, parse the DNS traffic, and process the DNS traffic according to preset rules, including: when the DNS traffic matches the preset rules, rewriting the destination address of the DNS traffic to the address of a specified DNS server, encrypting the DNS traffic using a private protocol, and sending the encrypted DNS traffic to the edge node. The management platform is used to obtain preset rules and send the preset rules to the client; The edge node is used to obtain the encrypted DNS traffic sent by the client, perform security checks on the encrypted DNS traffic sent by the client, and send the DNS traffic that has passed the security check to the address of the specified DNS server or the default DNS server according to the destination address of the DNS traffic. The designated DNS server is used to obtain DNS traffic sent by the edge node that has passed security checks, and to respond to the DNS traffic that has passed security checks.

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

12. A device for DNS traffic processing, wherein, The device includes: One or more processors; and A memory storing computer-readable instructions, which, when executed, cause the processor to perform the operations of the method as described in any one of claims 1 to 9.