Domain name system proxy method and related device
By modifying the address of the DNS request message on the first network card driver of the terminal, and converting the address at the IP layer, directly completing the forwarding at the kernel layer, solving the problems of complexity and high resource utilization of DNS request message forwarding, and achieving simplification Forwarding process and resource conservation.
Patent Information
- Application Number
- CN202310807729.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-07-03
- Publication Date
- 2025-01-03
- Estimated Expiration
- 2043-07-03
AI Technical Summary
The prior art has high complexity in the forwarding process of DNS request packets and occupies a lot of system resources. Especially in hotspot scenarios, it is necessary to reduce complexity and resource utilization.
Modify the destination address of the DNS request message through the first network card driver of the terminal to the address of the DNS server, and modify the source address to the second network card address through the IP layer, which is directly completed at the kernel layer to avoid data copying and re-encapsulation of the message header. Simplify the forwarding process.
It reduces the complexity of forwarding of DNS request packets, reduces the occupation of system resources, and improves security and efficiency, especially in hot scenarios.
Smart Images

Figure CN119254747A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of terminal technology, and in particular to a domain name system proxy method and related devices. Background Art
[0002] The domain name system (DNS) is a system for converting domain names and their corresponding Internet protocol (IP) addresses, and a DNS server is a server used to store and manage this system. When a user accesses a web page through a terminal, he can enter the domain name of the web page to be visited. Correspondingly, after the terminal obtains the domain name, it generates a DNS request message and sends the DNS request message to the DNS server so that the DNS server can convert the domain name. In actual applications, the address of the DNS server corresponding to the terminal may be configured as the address of another device rather than the address of the DNS server. For example, in a hotspot scenario, the address of the DNS server corresponding to the terminal will be configured as the gateway address of the device that provides the hotspot for the terminal. Therefore, the device that provides the hotspot needs to perform DNS proxy for the terminal and forward the DNS request message.
[0003] Currently, a possible design is that the device providing the hotspot strips the header of the received DNS request message, and then copies the data from the kernel buffer to the user buffer, re-encapsulates the data with the header, and further forwards it to the DNS server. The entire forwarding process is relatively complicated and occupies more system resources. Summary of the invention
[0004] The present application provides a DNS proxy method and related devices, in order to reduce the complexity of the forwarding process and reduce the occupation of system resources.
[0005] On the first aspect, the present application provides a DNS proxy method, which can be executed by a terminal, or by a component configured in the terminal (such as a chip, a chip system, etc.), or by a logic module or software that can implement all or part of the terminal functions, and the present application does not limit this.
[0006] Exemplarily, the method includes: obtaining a message; when the type of the message is a DNS request message, modifying the destination address of the message to the address of the DNS server through the first network card driver, the first network card driver is the driver corresponding to the first network card; modifying the source address of the message to the address of the second network card through the IP layer; and sending the message to the above-mentioned DNS server through the second network card.
[0007] It should be noted that the source address of the message sent to the DNS server is the address of the second network card, and the destination address is the address of the DNS server. The source address and the destination address are different from the source address and the destination address of the acquired message, but the data part of the message is the same, that is, the payload data in the message remains unchanged. Among them, the source address and the destination address are carried in the message header.
[0008] In the above technical solution, when a DNS request message is obtained, the destination address of the message is directly modified to the address of the DNS server through the first network card driver. Further, the source address of the message is modified to the address of the second network card through the IP layer, and the message with the modified source address and destination address is sent to the DNS server through the second network card. The entire process of modifying the source address and destination address of the message can be completed at the kernel layer without passing through the application layer, or in other words, there is no need to copy data from the kernel buffer to the user buffer and re-encapsulate the data into a message header. The forwarding process is relatively simple, which is conducive to reducing the complexity of the message forwarding process, thereby reducing the occupation of system resources.
[0009] In combination with the first aspect, in some possible implementations of the first aspect, the method further includes: determining the type of the message according to a target port of the message and a format of a message header of the message.
[0010] It is understandable that different types of messages may have different target ports and message header formats. In this application, the terminal can identify the type of message based on the target port of the message and the format of the message header on the first network card driver side, without creating a socket to monitor the port (which can be understood as: the socket corresponds to the port, and all data packets whose target port is the port will be forwarded to the socket), which is conducive to reducing the risk of monitoring and improving security. In addition, there is no need to create a socket, which is conducive to reducing the occupation of system resources.
[0011] In combination with the first aspect, in some possible implementations of the first aspect, determining the type of the message according to the target port of the message and the format of the message header of the message includes:
[0012] When the target port of the message is a preset port and the message header of the message meets the preset format, the type of the message is determined to be a DNS request message; when the target port of the message is a preset port but the message header of the message does not meet the preset format, the type of the message is determined to be an illegal message.
[0013] Optionally, the preset port may be port 53.
[0014] In the present application, it is necessary to identify the type of the message whose target port is the preset port, and for the message whose target port is other ports, it is not necessary to identify the type of the message. In other words, for the message whose target port is the preset port, it is possible that it is not a DNS request message. Therefore, it is further determined whether it is a DNS request message or an illegal message based on the format of its message header. Among them, an illegal message can be understood as: the target port of the message is the preset port, but it is not a DNS request message.
[0015] One possible design is that after the terminal obtains the message, the target port is determined through the first network card driver. Assuming that the target port is a preset port, the first network card driver is further used to determine whether the message header meets the preset format. Assuming that the message header meets the preset format, the type of the message is determined to be a DNS request message; assuming that the message header does not meet the preset format, the type of the message is determined to be an illegal message. Assuming that the target port is not a preset port, the format of the message header does not need to be judged, and it can be processed according to the processing flow of ordinary messages.
[0016] In combination with the first aspect, in some possible implementations of the first aspect, the method further includes: when the type of the message is an illegal message, discarding the message through the first network card driver. Wherein, the illegal message is a message whose target port is a preset port but whose message header does not meet the preset format.
[0017] In other words, if the target port is the preset port but the message header does not meet the preset format, the message is discarded, or the message is not processed. This is conducive to effectively preventing distributed denial of service (DDOS) attacks. In addition, for illegal messages whose target port is the preset port but the message header does not meet the preset format, the terminal does not process them, which is conducive to reducing the resource usage of the terminal, thereby freeing up more resources to process DNS request messages.
[0018] In combination with the first aspect, in some possible implementations of the first aspect, the address of the DNS server is determined from the address of at least one pre-stored DNS server according to the network card information.
[0019] The network card information includes, but is not limited to, bandwidth, load, or network card speed. In other words, the upstream DNS server can be determined from the address of at least one pre-stored DNS server according to one or more of bandwidth, load, or network card speed.
[0020] Optionally, the method described in the first aspect or any possible implementation of the first aspect provided by the present application can be applied to a hotspot scenario or a container scenario. When the above method is applied to a hotspot scenario, the first network card is a wireless local area network (WLAN) network card, and the first network card driver is a wireless local area network network card driver; when the above method is applied to a container scenario, the first network card is a virtual network card, and the first network card driver is a virtual network card driver.
[0021] In a second aspect, the present application provides a DNS proxy device that can implement the DNS proxy method described in the first aspect and any possible implementation of the first aspect. The device includes a corresponding module for executing the above method. The module included in the device can be implemented by software and / or hardware. The device can be, for example, a terminal, or a chip, a chip system, or a processor that supports the terminal to implement the above method, or a logic module or software that can implement all or part of the functions of the terminal.
[0022] In a third aspect, the present application provides a DNS proxy device, comprising a processor, wherein the processor is used to execute the DNS proxy method described in the first aspect and any possible implementation manner of the first aspect.
[0023] Optionally, the device may further include a memory for storing instructions and data. The memory is coupled to the processor, and when the processor executes the instructions stored in the memory, the method described in the first aspect and any possible implementation of the first aspect may be implemented.
[0024] Optionally, the apparatus may further include a communication interface, and the communication interface is used for the apparatus to communicate with other devices. Exemplarily, the communication interface may be a transceiver, circuit, bus, module or other types of communication interfaces.
[0025] In a fourth aspect, the present application provides a chip system comprising at least one processor for supporting the implementation of the functions involved in the above-mentioned first aspect and any possible implementation method of the first aspect, for example, receiving or processing the data and / or information involved in the above-mentioned method.
[0026] In one possible design, the chip system also includes a memory, which is used to store program instructions and data, and the memory is located inside or outside the processor.
[0027] The chip system may be composed of the chip, or may include the chip and other discrete devices.
[0028] In a fifth aspect, the present application provides a computer-readable storage medium, including a computer program or instructions, which, when executed on a computer, enables the computer to implement the method in the first aspect and any possible implementation of the first aspect.
[0029] In a sixth aspect, the present application provides a computer program product, comprising: a computer program (also referred to as code, or instructions), which, when executed, enables a computer to execute the method in the first aspect and any possible implementation of the first aspect.
[0030] It should be understood that the second to sixth aspects of the present application correspond to the technical solutions of the first aspect of the present application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation methods are similar and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS
[0031] Figure 1 is a schematic diagram of the hardware structure of the terminal provided in the embodiment of the present application;
[0032] Figure 2 It is a schematic diagram of the structure of a network model to which the method provided in the embodiment of the present application is applicable;
[0033] Figure 3 It is a schematic diagram of a scenario applicable to the method provided in the embodiment of the present application;
[0034] Figure 4 is a schematic flow chart of the DNS proxy method provided in an embodiment of the present application;
[0035] Figure 5 It is a schematic diagram of a preset format of a message header of a DNS message provided in an embodiment of the present application;
[0036] Figure 6 It is a schematic diagram of a process of selecting an upstream DNS server by a terminal provided in an embodiment of the present application;
[0037] Figure 7 It is a comparative schematic diagram of the existing DNS proxy method provided in the embodiment of the present application and the DNS proxy method provided in the present application;
[0038] Figure 8 It is a flowchart of the DNS proxy method for different scenarios provided by the embodiments of the present application. DETAILED DESCRIPTION
[0039] The technical solution in this application will be described below in conjunction with the accompanying drawings.
[0040] To facilitate understanding of the embodiments of the present application, the following description is first made:
[0041] First, in this application, in order to facilitate the clear description of the technical solutions of the embodiments of this application, the words "first" and "second" are used to distinguish the same items or similar items with basically the same functions and effects. For example, the first network card and the second network card are only used to distinguish different network cards, and their order is not limited. Those skilled in the art can understand that the words "first" and "second" do not limit the quantity and execution order, and the words "first" and "second" do not necessarily limit them to be different.
[0042] Second, in this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship, but it does not exclude the situation where the previous and next associated objects are in an "and" relationship. The specific meaning can be understood in combination with the context. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c; a and b; a and c; b and c; or a and b and c. Where a, b, c can be single or multiple.
[0043] Third, in the present application, "when", "assuming", "if" and "if" all mean that the device will take corresponding actions under certain objective circumstances. It does not limit the time, nor does it require that the device must make a judgment when it is implemented, nor does it mean that there are other limitations.
[0044] Fourth, in this application, DNS proxy refers to forwarding DNS request messages to a DNS server. In the process of forwarding messages, the source address and destination address of the message sent to the DNS server are different from those of the message obtained, but the data part is the same, where the data part may include, for example, a domain name entered by a user.
[0045] For example, in a hotspot scenario, assuming that terminal A provides a hotspot to terminal B, the address of the DNS server corresponding to terminal B is configured as the IP address of the wireless LAN network card of terminal A, and terminal B sends a DNS request message to terminal A. Correspondingly, terminal B receives the DNS request message. At this time, the source address of the DNS request message is the IP address of the wireless LAN network card of terminal B, and the destination address is the IP address of the wireless LAN network card of terminal A. The source address of the DNS request message sent by terminal A to the DNS server is the IP address of the cellular network card of terminal A, and the destination address is the IP address of the DNS server. Among them, the data part of the DNS request message received by terminal A and the DNS request message sent are the same, that is, the payload data in the message remains unchanged. Among them, the source address and the destination address are carried in the message header.
[0046] In addition, in this application, an IP address may be referred to as an address. For example, an IP address of a cellular network card may be referred to as an address of the cellular network card.
[0047] Fifth, the method provided in the present application can be executed by a terminal, or it can also be executed by a component configured in the terminal (such as a chip, a chip system, etc.), or it can also be implemented by a logic module or software that can realize all or part of the terminal functions, and the present application does not limit this. Among them, the terminal can also be called user equipment (UE), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal equipment, wireless communication equipment, user agent or user device, etc., and the embodiments of the present application do not limit this.
[0048] In the embodiments of the present application, the types of terminals include, but are not limited to: mobile phones, tablet computers, computers with wireless transceiver functions (such as laptops, PDAs, etc.), mobile Internet devices (MID), virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication functions, computing devices or other processing devices connected to wireless modems, vehicle-mounted devices, wearable devices, fifth generation (5th generation) The present invention relates to terminals in the 5G generation (5G) network or terminals in the future evolved public land mobile network (PLMN), laptop computers, machine type communication (MTC) terminals, etc.
[0049] In addition, the terminal can also be a terminal in the Internet of Things (IoT) system. IoT is an important part of the future development of information technology. Its main technical feature is to connect objects to the network through communication technology, thereby realizing an intelligent network of human-machine interconnection and object-to-object interconnection. IoT technology can achieve massive connections, deep coverage, and terminal power saving through narrow band (NB) technology, for example.
[0050] Figure 1 1 is a schematic diagram of the hardware structure of the terminal 100 provided in the embodiment of the present application. Figure 1 Describe in detail the possible hardware structure of the terminal.
[0051] The terminal 100 includes a processor 101, a transceiver 102, a memory 103, an antenna 104, a power supply 105, an input unit 106, a display unit 107, an audio circuit 108, a camera 109, a sensor 110, and a wireless fidelity (Wi-Fi) module 111. The audio circuit 108 may include a speaker 108a, a microphone 108b, and the like.
[0052] The processor 101 may include one or more processing units, for example, the processor 101 may include one or more of an application processor (AP), a microcontroller unit (MCU), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and a neural-network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors.
[0053] The memory 103 can be used to store computer executable program codes, which include instructions. The processor 101 executes various functional applications and data processing of the terminal 100 by running the instructions stored in the memory 103. The memory 103 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created during the use of the terminal 100 (such as audio data, a phone book, etc.), etc. In addition, the memory 103 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.
[0054] The processor 101, the transceiver 102 and the memory 103 can communicate with each other through an internal connection path to transmit control and / or data signals. The processor 101 is used to call and run the computer program stored in the memory 103 to control the transceiver 102 to send and receive signals.
[0055] The antenna 104 is used to send data or signaling output by the transceiver 102. The power supply 105 is used to provide power to various devices or circuits in the terminal 100. The input unit 106 is used to receive content input by the user. The display unit 107 can be used to display text, images, videos, etc.
[0056] It is to be understood that the structure illustrated in the present application does not constitute a specific limitation on the terminal 100. In other embodiments, the terminal 100 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.
[0057] In addition, the operating system of the terminal may be an Android system, a Linux system, a Unix system, etc., which is not limited in this application. The following will take the Linux system as an example to describe in detail the network model applicable to the method provided by this application.
[0058] Figure 2 : is a schematic diagram of the structure of a network model applicable to the method provided in the embodiment of the present application. Figure 2 a) shows the structure of the Transmission Control Protocol (TCP) / IP network model. Figure 2 b) shows Figure 2 The structure of the IP network stack applicable to the network layer shown in a) in FIG.
[0059] like Figure 2 As shown in a), the TCP / IP network model includes four layers: application layer, transport layer, network layer, and network interface layer. The application layer is used to provide a set of applications to users. For example, hypertext transfer protocol (HTTP), file transfer protocol (FTP), DNS, etc. The transport layer is used for end-to-end communication. For example, TCP, user datagram protocol (UDP), etc. The network layer is used for data packet encapsulation, addressing, and routing. The network interface layer includes the device driver of the operating system and the corresponding network interface card in the computer, which is used to receive data packets from the network layer, further process the data packets into data frames, and transmit them through the network, or receive data frames from the network, parse to obtain data packets, and send the data packets to the network layer.
[0060] When a terminal sends a data packet, it will encapsulate the data packet layer by layer according to the above protocol stack, encapsulate the protocol header of the layer, and then send it to the next layer. Correspondingly, when a terminal receives a data packet, it will also decapsulate it layer by layer according to the above protocol stack, and for the data packet sent from the next layer, it will strip the protocol header of the layer and then send it to the previous layer.
[0061] The following will be combined Figure 2 b) in the figure provides a detailed description of the IP network stack applicable to the network layer.
[0062] like Figure 2 As shown in b), the network stack in the Linux kernel is similar to the four-layer structure of TCP / IP mentioned above. The top-level application interacts with the socket through system calls. Below the socket are the transport layer, IP layer (equivalent to the network layer), and network interface layer. Among them, igb and bnx are network card drivers, and the bottom layer is the physical network card device (such as Figure 2 The network card 1 to the network card n shown in b in FIG. 1 , where n is a positive integer). The network card is a basic device for sending and receiving data packets. During the system startup process, the network card is registered with the system through the network card driver in the kernel.
[0063] In this application, the terminal providing the hotspot may be configured with a wireless LAN network card and a cellular network card, and the corresponding network card drivers are wireless LAN network card drivers and cellular network card drivers. There may be one or more cellular network cards, and this application does not limit the number.
[0064] It should be understood that Figure 1 and Figure 2 The structure shown is only an example and should not constitute any limitation to the embodiments of the present application. For example, in practical applications, the network model applicable to the present application may also be an open system interconnect (OSI) reference model (seven-layer model). For the description of the OSI reference model, reference may be made to known technologies and will not be described in detail here.
[0065] When using a terminal to access the Internet, users may not be able to remember the IP number string that can be directly read by the machine, so they generally use domain names to access the Internet. DNS is a system used to convert domain names and their corresponding IP addresses, and a DNS server is a server used to store and manage this system. For example, when a user accesses a web page through a terminal, he can enter the domain name of the web page to be accessed. Correspondingly, after the terminal obtains the domain name, it generates a DNS request message and sends the DNS request message to the DNS server so that the DNS server can convert it.
[0066] In actual applications, the address of the DNS server corresponding to the terminal may be configured as the address of another device rather than the address of the DNS server. For example, in a hotspot scenario, the address of the DNS server corresponding to the terminal will be configured as the gateway address of the device that provides the hotspot for the terminal. Therefore, the device that provides the hotspot needs to perform DNS proxy for the terminal and forward the DNS request message.
[0067] Currently, a possible design is that the device providing the hotspot strips the header of the received DNS request message, then copies the data from the kernel buffer to the user buffer, re-encapsulates the data with the header, and further forwards it to the DNS server.
[0068] refer to Figure 2 As shown in b), it is assumed that in a hotspot scenario, the terminal providing the hotspot receives a message from the terminal provided with the hotspot. Among them, network card 1 can be considered as a wireless LAN network card, and network card n can be considered as a cellular network card. In the existing DNS proxy method, after network card 1 receives the message from the terminal provided with the hotspot, the message passes through the network interface layer, IP layer, and transport layer in turn, and is decapsulated layer by layer according to the protocol stack. For the message sent from the next layer, the protocol header of this layer is stripped off and then sent to the previous layer. Finally, the data is obtained, and the data is copied from the kernel buffer to the user buffer (that is, through the application layer). Then the data passes through the transport layer, IP layer, and network interface layer in turn, and the data packet is encapsulated layer by layer, and the protocol header of this layer is encapsulated and sent to the next layer. It can be understood that at this time, the source address of the re-encapsulated message is the address of network card n, and the destination address is the address of the DNS server. It is not difficult to see that the entire forwarding process is relatively complicated.
[0069] In order to reduce the complexity of the forwarding process, the present application provides a DNS proxy method. When the terminal recognizes the DNS request message on the first network card driver side, it directly modifies the destination address of the message to the address of the DNS server through the first network card driver. Further, the source address of the message is modified to the address of the second network card through the IP layer, and the message with the modified source address and destination address is forwarded to the DNS server. Therefore, there is no need to strip the message header, copy the data, and re-encapsulate the data. Figure 2 It can be seen that in the method provided in the present application, since there is no need to strip the message header layer by layer, the DNS request message does not need to pass through the transport layer and does not need to copy the data. Therefore, there is no need to go through the conversion from kernel state to user state, that is, there is no need to go through the socket or application, and the forwarding process is relatively simple.
[0070] Before describing in detail the DNS proxy method provided by the present application, Figure 3Applicable scenarios (taking hotspot scenarios as an example) are introduced. It is understandable that the application scenarios described in the embodiments of the present application are to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application.
[0071] Figure 3 It is a schematic diagram of a scenario applicable to the method provided in the embodiment of the present application.
[0072] like Figure 3 As shown in a), the mobile phone provides a hotspot for the tablet, and the tablet uses the mobile phone hotspot to access the Internet, and the mobile phone can access the Internet through the cellular network. In this scenario, the mobile phone can provide a DNS proxy for the tablet. Figure 3 As shown in b), the user can input the domain name of the web page to be visited through the tablet. After the tablet obtains the domain name, it generates a DNS request message. At this time, the source address of the DNS request message is the address of the tablet, such as "192.168.0.2", and the destination address is the address of the wireless LAN network card of the mobile phone, such as "192.168.0.1". The tablet sends the DNS request message to the mobile phone. Correspondingly, the mobile phone receives the DNS request message from the tablet. Further, the mobile phone forwards the DNS request message to the DNS server through the cellular network. At this time, the source address of the DNS request message sent by the mobile phone is the address of the cellular network card, and the destination address is the address of the DNS server, such as "8.**.8".
[0073] It should be understood that Figure 3 The scenarios shown are only examples and should not constitute any limitation on the embodiments of the present application. For example, the method provided by the present application can also be applied to a container scenario (that is, the terminal obtains a DNS request message from the container and sends it to the DNS server). For another example, Figure 3 The terminals (mobile phones and tablets) shown are only examples, but in actual applications, other types of terminals may also be used. Figure 3 The IP addresses shown in are only examples. In actual applications, the addresses of the wireless LAN network card and the DNS server may also be other IP addresses, and this application does not limit this.
[0074] In addition, the wireless local area network card is an example of the first network card, and the cellular network card is an example of the second network card. This application does not limit the types of the first network card and the second network card.
[0075] The DNS proxy method provided by the present application will be described in detail below in conjunction with the accompanying drawings.
[0076] Figure 4 It is a schematic flow chart of the DNS proxy method 400 provided in an embodiment of the present application. Figure 4The method 400 shown may include steps 410 to 440. The various steps in the method 400 are described in detail below. Figure 4 The method 400 shown may be applicable to a hotspot scenario or a container scenario.
[0077] It should be understood that Figure 4 The method 400 shown is described by taking the terminal as the execution subject as an example, but no limitation should be imposed on the execution subject of the method. As long as the program that can record the code of the method provided by the embodiment of the present application can be run, the method provided by the embodiment of the present application can be executed. For example, the terminal can also be replaced by a component configured in the terminal (such as a chip, a chip system, etc.), or other functional modules that can call and execute the program. The embodiment of the present application does not limit this.
[0078] In step 410, a message is obtained.
[0079] In the hotspot scenario, it is assumed that terminal A provides a hotspot for terminal B, or terminal B is connected to the hotspot of terminal A, wherein terminal A is configured with a cellular network card and a wireless LAN network card. In other words, terminal A can communicate with terminal B through the wireless LAN and communicate with the DNS server through the cellular network. Terminal A obtains the message including: terminal A receives the message from terminal B.
[0080] For example, when a user accesses a web page through terminal B, he inputs the domain name of the web page to be accessed. Terminal B obtains the domain name in response to the user's input operation, and then generates and sends a DNS request message. At this time, the source address of the DNS request message is the address of the wireless LAN network card of terminal B, and the destination address is the address of the wireless LAN network card of terminal A. Accordingly, terminal A receives the DNS request message from terminal B.
[0081] It should be understood that the sending of a DNS request message by terminal B to terminal A is only an example. In actual applications, the type of the message may not be a DNS request message. When the message sent by terminal B is a DNS request message, terminal A continues to execute steps 420 to 440; when the message sent by terminal B is an illegal message (i.e., the target port is a preset port, but the format of the message header does not meet the preset format), terminal A discards the message through the wireless LAN network card driver, or in other words, does not process the message. In addition, the cellular network card is only an example of the second network card and should not constitute any limitation to the embodiments of the present application. In actual applications, the second network card may also be other types of network cards that can connect to the Internet, and the present application does not limit this. In the embodiments below, the second network card takes a cellular network card as an example.
[0082] In the container scenario, assuming that a container is running on the terminal, the container can be understood as an operating system image, which bundles a set of isolated applications and the resources they depend on so that they can run separately from the host. Communication is carried out between the inside and outside of the container (or the host) through a virtual network card, and its corresponding driver is a virtual network card driver. A cellular network card is configured outside the container, and its corresponding driver is a cellular network card driver. The terminal communicates with other devices through the cellular network card, such as sending messages to a DNS server. The terminal obtains the message, including: the terminal obtains the message from the container. Exemplarily, the container generates a DNS request message, and the terminal obtains the DNS request message from the container.
[0083] Optionally, before step 420, the method 400 further includes: determining the type of the message according to the destination port of the message and the format of the message header of the message. The destination port of the message may be carried in the message header.
[0084] Exemplarily, after the terminal obtains the message, the first network card driver is used to determine the target port and the format of the message header carried in the message header of the message to determine the type of the message. If the message is a DNS request message, the terminal continues to execute steps 420 to 440; if the message is an illegal message, the first network card driver is used to discard the message, or in other words, the message is not processed. The first network card driver is the driver corresponding to the first network card, and the first network card can be considered as the network card that the terminal receives the message.
[0085] One possible design is that when the target port of the message is a preset port and the message header of the message meets the preset format, the type of the message is determined to be a DNS request message; when the target port of the message is a preset port but the message header of the message does not meet the preset format, the type of the message is determined to be an illegal message. The preset port may be, for example, port 53. The preset format may be the format of the message header of the DNS message specified by the protocol.
[0086] Figure 5 Schematic diagram of the preset format of the message header of the DNS message provided in the embodiment of the present application. Figure 5 Describe in detail the format of the DNS message header.
[0087] like Figure 5As shown in a) in the figure, the DNS message header includes an identifier (ID) field, a flag field, a question count field, an answer resource record number field, an authoritative domain name server count field, and an additional resource record number field. Among them, the ID field is used to indicate whether the DNS response message matches the DNS request message. Assuming that the DNS response message is a message in response to a certain DNS request, the field in the DNS request message and the DNS response message is the same. The question count field is used to indicate the number of DNS requests. The answer resource record number field is used to indicate the number of DNS responses. The authoritative domain name server count field is used to indicate the number of authoritative domain name servers. The additional resource record number field is used to indicate the number of additional records (the number of IP addresses corresponding to the authoritative domain name servers). Among them, the flag field is divided into several fields, such as Figure 5 As shown in b).
[0088] like Figure 5 As shown in b), the flag field is divided into a response (QR) field, an operation code (OPCODE) field, an authorization answer (AA) field, a truncated (TC) field, a desired recursion (RD) field, an available recursion (RA) field, a Z field, and a reply code (RCODE) field.
[0089] The QR field is used to indicate the flag information of the query request / response. When the message is a DNS request message, the value of this field is 0; when the message is a DNS request message, the value of this field is 1.
[0090] The type of query in the opcode field. For example, an opcode field of 0 indicates a standard query, an opcode field of 1 indicates a reverse query, and an opcode field of 2 indicates a server status request.
[0091] The AA field is valid in the response message. The TC field is used to indicate whether it is truncated.
[0092] The RD field can be set in a query and returned in the response. This field is used to indicate that the DNS server must handle this query, which is called a recursive query. If this field is 0, and the requested DNS server does not have an authoritative answer, it will return a list of other DNS servers that can answer the query. This is called an iterative query.
[0093] The RA field only appears in the response message. The Z field is a reserved field, and its value is 0 in all request and response messages.
[0094] The return code field indicates the error status of the response. When the value of this field is 0, it means there is no error; when the value of this field is 1, it means the message format is wrong (format error), the server cannot understand the request message; when the value of this field is 2, it means the domain name server failed (server failure), because the server cannot process this request; when the value of this field is 3, it means name error (name error); when the value of this field is 4, it means the query type is not supported; when the value of this field is 5, it means refused (refused), generally the server refuses to give a response due to the set policy, such as the server does not want to give a response to certain requesters.
[0095] It can be understood that in the present application, it is necessary to identify the type of the message whose target port is the preset port, while for the message whose target port is other ports, the terminal may not identify the type of its message.
[0096] Exemplarily, after receiving the message, the terminal determines its target port through the first network card driver. Assuming that the target port is a preset port, the first network card driver is further used to determine whether its message header meets the preset format. Assuming that its message header meets the preset format, it is determined that the type of the message is a DNS request message. Assuming that the message header does not meet the preset format, it is determined that the type of the message is an illegal message. Assuming that the target port is not a preset port, the format of its message header does not need to be judged, and it can be processed according to the processing flow of ordinary messages.
[0097] It should be understood that the above-mentioned preset format that the DNS message header needs to meet is only an example and should not constitute any limitation to the embodiments of the present application. In practical applications, the preset format may include more or fewer fields, or other fields, and the present application does not limit this.
[0098] In step 420, when the type of the message is a DNS request message, the destination address of the message is modified to the address of the DNS server through the first network card driver.
[0099] It can be understood that the contents indicated by each field in the DNS request message are predefined. Therefore, the terminal can determine the field where the destination address is located according to the contents indicated by each predefined field through the first network card driver, and then modify the destination address to the address of the DNS server without stripping the message header of the DNS request message.
[0100] Optionally, the address of the DNS server is determined from the address of at least one pre-stored DNS server according to the network card information. The network card information includes, for example, but is not limited to: bandwidth, load, or network card speed. In other words, the terminal can determine the upstream DNS server from the address of at least one pre-stored DNS server according to one or more of the bandwidth, load, or network card speed, or select the upstream network card.
[0101] One possible design is that the terminal determines the uplink network card, or the uplink DNS server, based on the bandwidth of each network card configured by the terminal. For example, if the cellular network card of the terminal includes cellular network card 1 and cellular network card 2, the terminal can select the network card with the larger bandwidth between cellular network card 1 and cellular network card 2 as the uplink network card. In other words, the terminal sends a DNS request message to the DNS server corresponding to the network card.
[0102] Another possible design is that the terminal determines the uplink network card, or the uplink DNS server, based on the network card speeds of each network card configured by the terminal. For example, if the cellular network card of the terminal includes cellular network card 1 and cellular network card 2, the terminal can select the network card with the faster network speed between cellular network card 1 and cellular network card 2 as the uplink network card. In other words, the terminal sends a DNS request message to the DNS server corresponding to the network card.
[0103] Another possible design is that the terminal determines the uplink network card, or the uplink DNS server, according to the load of each network card configured by the terminal. For example, the terminal can select the network card with less load between cellular network card 1 and cellular network card 2 as the uplink network card, in other words, send a DNS request message to the DNS server corresponding to the network card.
[0104] After the terminal determines the upstream DNS server, the terminal can modify the destination address of the DNS request message to the address of the DNS server through the first network card driver.
[0105] Figure 6 1 is a flow chart of a terminal selecting an upstream DNS server provided in an embodiment of the present application. Figure 6 In the example of hotspot scenario, suppose the mobile phone provides a hotspot for the tablet, the tablet can access the Internet through the mobile phone hotspot, and the mobile phone can access the Internet through the cellular network. In this scenario, the mobile phone can provide a DNS proxy for the tablet.
[0106] like Figure 6 As shown, the mobile phone has pre-stored at least one uplink DNS server address, such as Figure 6As shown in the figure, address 1 is "8.**.8" and address 2 is "114.114.114.114". After the mobile phone receives the DNS request message through the wireless LAN network card, it can determine which cellular network card to select based on one or more of the network card speed, load, bandwidth, etc., and then determine the address of the DNS server corresponding to the cellular network card.
[0107] It should be understood that the method in which the terminal determines the upstream DNS server according to the network card information shown above is only an example and should not constitute any limitation to the embodiments of the present application. In practical applications, other methods for selecting the upstream DNS server in the known technology may also be adopted. In addition, the terminal may also pre-store the address of a DNS server, in which case the terminal does not need to select.
[0108] In step 430, the source address of the message is modified to the address of the second network card through the IP layer.
[0109] After the terminal modifies the destination address of the DNS request message to the address of the DNS server through the first network card driver, the message reaches the IP layer, and the terminal modifies the source address of the message to the address of the second network card through the IP layer, wherein the second network card can be, for example, a cellular network card.
[0110] In step 440, a message is sent to the DNS server through the second network card.
[0111] The terminal modifies the source address of the DNS request message to the address of the second network card and the destination address to the address of the DNS server, and then sends the message to the DNS server through the second network card.
[0112] Figure 7 Schematic diagram comparing the existing DNS proxy method provided by the present application and the DNS proxy method provided by the present application. Figure 7 In the figure, WLAN 0 represents a wireless local area network interface, and RMNET 0 represents a remote network (RMNET) interface, which may be a cellular network, for example.
[0113] like Figure 7As shown in a), in the existing DNS proxy method, the source address of the data packet received by WLAN 0 is "192.168.0.2", and the destination address is "192.168.0.1", and the source address of the data packet sent by WLAN 0 is "192.168.0.2", and the destination address is "192.168.0.1". The mobile phone can perform processes such as monitoring ports and re-creating sockets. In more detail, the message header is stripped layer by layer, and the message header is re-encapsulated layer by layer. At this time, the source address in the encapsulated message header is "7.2.3.4" (the address of the cellular network card), and the destination address is "8.**.8" (the address of the DNS server). The source address of the data packet received by RMNET 0 is "7.2.3.4", and the destination address is "8.**.8", and the source address of the data packet sent by RMNET 0 is "7.2.3.4", and the destination address is "8.**.8".
[0114] like Figure 7 As shown in b), in the DNS proxy method provided in the present application, the source address of the data packet received by WLAN 0 is "192.168.0.2", and the destination address is "192.168.0.1". Since the mobile phone can modify the destination address to the address of the DNS server on the wireless LAN network card driver side, the source address of the data packet sent by WLAN 0 is "192.168.0.2", and the destination address is "8.**.8" (the address of the DNS server). Further, after the native network address translation (NAT) process, for example, the source address of the DNS request message is converted through the IP layer. At this time, the source address of the DNS request message is converted to "7.2.3.4" (the address of the cellular network card). Therefore, the source address of the data packet received by RMNET 0 is "7.2.3.4", and the destination address is "8.**.8", and the source address of the data packet sent by RMNET 0 is "7.2.3.4", and the destination address is "8.**.8".
[0115] Depend on Figure 7 a) and Figure 7 As can be seen from b), the difference is that, in the DNS method provided in the present application, the destination address of the data packet sent by WLAN 0 has been converted. In other words, the mobile phone has modified the destination address of the DNS request message on the wireless LAN network card driver side.
[0116] Figure 8 It is a flowchart of the DNS proxy method for different scenarios provided by the embodiments of the present application.
[0117] like Figure 8As shown in a), in the hotspot scenario, take the example of a tablet using a mobile phone hotspot to access the Internet, and the mobile phone can provide a DNS proxy for the tablet. The mobile phone receives a DNS request message from the tablet, for example, it can receive the DNS request message through a wireless LAN network card, and then modify the destination address of the DNS request message to "8.**.8" (the address of the DNS server) through the wireless LAN network card driver. At this time, the source address of the DNS request message is "192.168.0.2". Further, the source address conversion is performed. For example, the mobile phone performs source address conversion on the DNS request message through the IP layer. At this time, the source address of the DNS request message is "7.2.3.4" (the address of the cellular network card), and the destination address is "8.**.8". The mobile phone sends the DNS request message to the DNS server through the cellular network card.
[0118] like Figure 8 As shown in b), in the container scenario, the terminal runs a container, and the inside and outside of the container are connected through a virtual link. In other words, the inside and outside of the container of the same terminal can communicate through a virtual network. The terminal obtains a DNS request message from the container. At this time, the source address of the DNS request message is "192.168.0.2" and the destination address is "192.168.0.1". The terminal modifies the destination address of the DNS request message to "8.**.8" (the address of the DNS server) through the virtual network card driver, and further performs source address conversion. For example, the terminal performs source address conversion on the DNS request message through the IP layer. At this time, the source address of the DNS request message is "7.2.3.4" (the address of the cellular network card), and the destination address is "8.**.8". The terminal sends a DNS request message to the DNS server through the cellular network card.
[0119] Based on the above technical solution, when the terminal obtains the DNS request message, it directly modifies the destination address of the message to the address of the DNS server through the first network card driver. Further, it modifies the source address of the message to the address of the second network card through the IP layer, and sends the message with the modified source address and destination address to the DNS server through the second network card. The entire process of modifying the source address and destination address of the message can be completed at the kernel layer without going through the application layer, or in other words, there is no need to copy the data from the kernel buffer to the user buffer and re-encapsulate the data into the message header. The forwarding process is relatively simple, which is conducive to reducing the complexity of the message forwarding process, thereby reducing the occupation of system resources.
[0120] In addition, the terminal can identify the type of message according to the target port of the message and the format of the message header on the first network card driver side, without creating a socket to monitor the port, which is conducive to reducing the risk of monitoring and improving security. In addition, without creating a socket, it is conducive to reducing the occupation of system resources.
[0121] The present application also provides a DNS proxy device that can implement Figure 4 , Figure 6 , Figure 7 or Figure 8 The method described in the embodiment shown. The device includes corresponding modules for executing the above method. The modules included in the device can be implemented by software and / or hardware.
[0122] The embodiment of the present application also provides a DNS proxy device, which includes a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to call and execute the computer program, so that the device implements Figure 4 , Figure 6 , Figure 7 or Figure 8 The method described in the illustrated embodiment.
[0123] The present application also provides a chip system, which includes at least one processor for implementing the above Figure 4 , Figure 6 , Figure 7 or Figure 8 The functions involved in the methods described in the illustrated embodiments, for example, receive or process the data and / or information involved in the above methods.
[0124] In one possible design, the chip system also includes a memory, which is used to store program instructions and data, and the memory is located inside or outside the processor.
[0125] The chip system may be composed of the chip, or may include the chip and other discrete devices.
[0126] The present application also provides a computer-readable storage medium, wherein a computer program (also referred to as code or instruction) is stored on the computer storage medium. When the computer program is executed by a processor, the above Figure 4 , Figure 6 , Figure 7 or Figure 8 The method described in the illustrated embodiment is carried out.
[0127] The present application also provides a computer program product, the computer program product comprising: a computer program (also referred to as code, or instruction), when the computer program is executed, causes the computer to execute Figure 4 , Figure 6 , Figure 7 or Figure 8 The method described in the illustrated embodiments.
[0128] It should be understood that the processor in the embodiment of the present application can be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method embodiment can be completed by the hardware integrated logic circuit or software instructions in the processor. The above processor can be a general processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in the embodiment of the present application can be directly embodied as a hardware decoding processor to perform, or the hardware and software modules in the decoding processor can be combined to perform. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.
[0129] It should also be understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.
[0130] The terms "unit", "module", etc. used in this specification may be used to represent computer-related entities, hardware, firmware, a combination of hardware and software, software, or software in execution. The units and modules in the embodiments of the present application have the same meaning and can be used interchangeably.
[0131] It will be appreciated by those skilled in the art that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or in combination with computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application. In the several embodiments provided in this application, it should be understood that the disclosed devices, equipment and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic, for example, the division of units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point, the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
[0132] In the above embodiments, the functions of each functional unit can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions (programs). When loading and executing computer program instructions (programs) on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. Computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, computer instructions can be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that contains one or more available media integrated. The available media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, digital video discs (DVD)), or semiconductor media (eg, solid state drives (SSD)).
[0133] If the functions provided by the embodiments of the present application are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.
[0134] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.
Claims
1. A domain name system proxy method, characterized in that: include: Get the message; In the case where the type of the message is a Domain Name System DNS request message, modifying the destination address of the message to an address of a DNS server through a first network card driver, wherein the first network card driver is a driver corresponding to the first network card; Modifying the source address of the message to the address of the second network card through the Internet protocol layer; The message is sent to the DNS server through the second network card.
2. The method according to claim 1, characterized in that The method further comprises: The type of the message is determined according to the target port of the message and the format of the message header of the message.
3. The method according to claim 2, characterized in that Determining the type of the message according to the target port of the message and the format of the message header of the message includes: When the target port of the message is a preset port and the message header of the message satisfies a preset format, determining that the type of the message is a DNS request message; When the destination port of the message is the preset port but the message header of the message does not meet the preset format, it is determined that the type of the message is an illegal message.
4. The method according to any one of claims 1 to 3, characterized in that The method further comprises: In the case that the type of the message is an illegal message, the message is discarded by the first network card driver, and the illegal message is a message whose target port is a preset port but whose message header does not meet the preset format.
5. The method according to any one of claims 1 to 4, characterized in that The address of the DNS server is determined from the address of at least one pre-stored DNS server according to the network card information.
6. The method according to any one of claims 1 to 5, characterized in that The first network card is a wireless local area network card, and the first network card driver is a wireless local area network card driver; or, the first network card is a virtual network card, and the first network card driver is a virtual network card driver.
7. A domain name system proxy device, characterized in that: The method comprises modules for implementing the method as claimed in any one of claims 1 to 6.
8. A domain name system proxy device, characterized in that: comprising a processor and a memory, wherein: The memory is used to store computer programs; The processor is configured to call the computer program so that the apparatus implements the method according to any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that: The storage medium stores a computer program or instruction. When the computer program or instruction is executed by a computer, the method according to any one of claims 1 to 6 is implemented.
10. A computer program product, characterized in that The computer program product comprises instructions, and when the instructions are executed by a computer, the method according to any one of claims 1 to 6 is implemented.
Citation Information
Patent Citations
Message processing method and apparatus
CN107154927A
Message forwarding method, message forwarding device, storage medium and electronic equipment
CN111262784A
VPN request processing method, client device and system
CN112887444A
Message transmission method and device, equipment and storage medium
CN116112435A
Network communications system and method
US20070094411A1
