Method and apparatus for responding to dns service based on local process

Abstract

The application relates to a DNS service response method and device based on a local process. The method comprises the following steps: a load balancing device associates the entry interface identification information of a DNS request message with a corresponding session; a local DNS service process creates a Socket socket, and sets a source-in and source-out mark on the Socket socket; in the DNS response message sending process, it is detected whether the Socket socket exists the source-in and source-out mark; when the source-in and source-out mark is detected, a target out interface is determined, and the DNS response message is sent through the target out interface; when the source-in and source-out mark is not detected, the DNS response message is sent according to a routing search result. The DNS service response method and device based on the local process can return the response message of the local DNS process from the original request interface without establishing a forwarding session link table, and effectively guarantee the service connectivity in a multi-link scene.

Description

Technical Field

[0001] This application relates to the field of computer information processing, and more specifically, to a method and apparatus for responding to DNS services based on a local process. Background Technology

[0002] With the development of the internet, people's lives and work have become increasingly inseparable from the network. To mitigate the availability risks caused by network egress failures and access problems due to insufficient network bandwidth, enterprises typically lease egress points from multiple ISPs. Furthermore, the services that enterprises provide to the outside world are based on DNS domain names, because domain names are not only easy to understand and remember, but can also be mapped to multiple server IPs.

[0003] Most load balancing devices today integrate interface-based link load balancing and domain-based global load balancing. The domain name resolution and matching functions of domain-based global load balancing are largely implemented using the open-source and powerful BIND, a process running on the device. In load balancing devices with multiple egress points, using DNS services and associating link interfaces, the device looks up the outgoing interface of the server response packet based on the routing table during packet return. When the same client IP in a domain name request enters the device from different interfaces and simultaneously returns packets, a situation arises where the request packet enters from ISP1, while the server response packet returns from ISP2. This situation, where request and response use different interfaces, can lead to technical problems such as the client not receiving the response packet.

[0004] The information disclosed in the background section is only intended to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] In view of this, this application provides a DNS service response method and apparatus based on the local process, which can realize the return of the response message of the local DNS process from the original request interface without the need to establish a forwarding session list, effectively ensuring the service connectivity in multi-link scenarios.

[0006] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0007] According to one aspect of this application, a DNS service response method based on a local process is proposed. The method includes: a load balancing device associating the ingress interface identifier information of a DNS request message with its corresponding session; the local DNS service process creating a Socket and setting a source-ingress-source-egress flag on the Socket; during the transmission of a DNS response message, detecting whether the Socket has a source-ingress-source-egress flag; when the source-ingress-source-egress flag is detected, determining the target egress interface and sending the DNS response message through the target egress interface; when the source-ingress-source-egress flag is not detected, sending the DNS response message according to the routing lookup result.

[0008] In one exemplary embodiment of this application, the load balancing device associates the ingress interface identifier information of a DNS request message with its corresponding session, including: the load balancing device obtaining a DNS request message sent by a client; obtaining the ingress interface identifier information corresponding to the DNS request message when it enters the device; and associating the ingress interface identifier information with the session corresponding to the DNS request message.

[0009] In one exemplary embodiment of this application, associating the ingress interface identification information with the session corresponding to the DNS request message includes: associating the MAC address corresponding to the ingress interface in the ingress interface identification information with the session corresponding to the DNS request message.

[0010] In one exemplary embodiment of this application, associating the ingress interface identification information with the session corresponding to the DNS request message includes: creating a session when the client request message first enters the device; recording the ingress interface identification information corresponding to the DNS request message in the session; and updating and overwriting the recorded ingress interface identification information in subsequent request messages in the same session.

[0011] In one exemplary embodiment of this application, before the local DNS service process creates the Socket socket, it further includes: sending the DNS request message to the local DNS service process for processing.

[0012] In one exemplary embodiment of this application, setting a source-in-source-out flag on the Socket includes: after the socket is successfully created, calling the setsockopt function to set a custom source-in-source-out flag on the socket.

[0013] In one exemplary embodiment of this application, determining the target outgoing interface includes: determining the target outgoing interface corresponding to the response message based on the ingoing interface identification information associated with the session.

[0014] In one exemplary embodiment of this application, determining the target outgoing interface corresponding to the response message based on the ingress interface identifier information associated with the session includes: obtaining the MAC address recorded in the session; performing a validity check on the MAC address; searching for the corresponding physical interface or logical interface based on the MAC address that has passed the check; and determining the found interface as the target outgoing interface of the response message.

[0015] In one exemplary embodiment of this application, the DNS request message is a UDP message or a TCP message.

[0016] According to one aspect of this application, a DNS service response device based on a local process is proposed. The device includes: an association module for a load balancing device to associate the ingress interface identifier information of a DNS request message with its corresponding session; a marking module for the local DNS service process to create a Socket and set a source-ingress-source-egress mark on the Socket; a detection module for detecting whether the Socket has a source-ingress-source-egress mark during the transmission of a DNS response message; a target module for determining a target egress interface when the source-ingress-source-egress mark is detected, and sending the DNS response message through the target egress interface; and a routing module for sending the DNS response message according to the routing lookup result when the source-ingress-source-egress mark is not detected.

[0017] According to one aspect of this application, an electronic device is provided, comprising: one or more processors; a storage device for storing one or more programs; and, when the one or more programs are executed by the one or more processors, causing the one or more processors to implement the method as described above.

[0018] According to one aspect of this application, a computer-readable medium is provided having a computer program stored thereon that, when executed by a processor, implements the method described above.

[0019] According to the DNS service response method and apparatus based on the local process of this application, the ingress interface identification information of the DNS request message is associated with its corresponding session through a load balancing device; the local DNS service process creates a Socket and sets a source-ingress-source-egress mark on the Socket; during the transmission of the DNS response message, the presence of the source-ingress-source-egress mark on the Socket is detected; when the source-ingress-source-egress mark is detected, the target egress interface is determined, and the DNS response message is sent through the target egress interface; when the source-ingress-source-egress mark is not detected, the DNS response message is sent according to the routing lookup result. This method eliminates the need to establish a forwarding session list, enabling the local DNS process's response message to return from the original request interface, effectively ensuring service connectivity in multi-link scenarios.

[0020] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description

[0021] The above and other objects, features, and advantages of this application will become more apparent from the detailed description of exemplary embodiments with reference to the accompanying drawings. The drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0022] Figure 1 This is a flowchart illustrating a DNS service response method based on a local process, according to an exemplary embodiment.

[0023] Figure 2 This is a flowchart illustrating a DNS service response method based on a local process, according to another exemplary embodiment.

[0024] Figure 3 This is a flowchart illustrating a DNS service response method based on a local process, according to another exemplary embodiment.

[0025] Figure 4 This is a block diagram illustrating a DNS service response apparatus based on a native process, according to an exemplary embodiment.

[0026] Figure 5 This is a block diagram illustrating an electronic device according to an exemplary embodiment.

[0027] Figure 6 This is a block diagram illustrating a computer-readable medium according to an exemplary embodiment. Detailed Implementation

[0028] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that this application will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.

[0029] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0030] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0031] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0032] It should be understood that although the terms first, second, third, etc., may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one component from another. Therefore, the first component discussed below may be referred to as the second component without departing from the teachings of this application. As used herein, the term "and / or" includes all combinations of any one and more of the associated listed items.

[0033] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of exemplary embodiments, and the modules or processes in the drawings are not necessarily essential for implementing this application, and therefore cannot be used to limit the scope of protection of this application.

[0034] The technical abbreviations used in this application are explained as follows: DNS (Domain Name System): A distributed network service system used to translate domain names into corresponding IP addresses, enabling the resolution and addressing of network resources.

[0035] Source-in-source-out: A network forwarding and routing strategy used to ensure that response traffic for data packets returns from the same interface that the request packet entered the device, in order to maintain the consistency and bidirectional symmetry of the packet forwarding path, thereby avoiding problems such as communication anomalies, carrier dropping, or clients being unable to receive response packets due to inconsistent paths.

[0036] ISP (Internet Service Provider): A network service provider is an operator that provides users with internet access, link transmission, domain name resolution and related network services.

[0037] A message 5-tuple is a set of key information used to uniquely identify a network communication session, including the protocol number, source IP address, source port number, destination IP address, and destination port number.

[0038] BIND (Berkeley Internet Name Domain): An open-source DNS server software used to provide domain name resolution services, supporting functions such as recursive resolution, authoritative resolution, and DNS configuration management.

[0039] Socket: In network programming, a socket is a programming interface and data exchange endpoint provided by the operating system for implementing network communication. Applications can use sockets to send and receive data and manage network connections.

[0040] MAC address (Media Access Control Address): The Media Access Control address is a unique hardware identifier for a network interface at the data link layer. It is usually pre-written by the device manufacturer into the network interface card and used for device identification and data frame forwarding in a local area network.

[0041] Session: A data structure used to describe the logical communication relationship established between two communicating parties within a certain time frame. It can be used to record communication status, interface information, and message associations.

[0042] Load balancing equipment: A network device used to distribute, schedule and control network traffic. It can distribute service traffic to different links, servers or network nodes according to preset policies to improve system availability and access performance.

[0043] Socket tag: Identification information set on the Socket to indicate the specific forwarding strategy or processing logic to be executed during message transmission.

[0044] Logical interfaces: Network interfaces virtually generated by software or protocols, including VLAN interfaces, tunnel interfaces, aggregation interfaces, and virtual interfaces, which do not directly correspond to physical hardware ports.

[0045] Physical interface: The actual hardware network interface on the device, used to implement data transmission and reception functions of the physical link.

[0046] The applicant in this case discovered through research that most existing implementations supporting source-in / source-out functionality are based on establishing a session mechanism using the packet 5-tuple at the forwarding layer. Specifically, after receiving a service packet, the load balancing device typically constructs a session linked list based on the protocol number, source IP address, source port number, destination IP address, and destination port number. It then maintains forwarding status information by combining the physical interfaces of the packet-in and packet-out devices, thereby enabling the packet response traffic to return according to the predetermined interface.

[0047] Typical processing steps in existing technologies include: S1. Define and initialize the session linked list: Define the session linked list structure based on the message quintuple, as well as the physical interfaces of the incoming and outgoing devices, and complete the initialization. S2, Message Data Forwarding Processing: The load balancing device receives network packets in real time through the network card and performs query and forwarding processing based on the session list; if no corresponding session is found, step S3 is executed. S3. Generate a new session list: Based on the five-tuple information of the current message and the corresponding inflow and outflow interfaces, a new session list is generated and written into the session table.

[0048] However, the aforementioned source-in-source-out implementation based on the forwarding layer session linked list is mainly applicable to ordinary packet forwarding scenarios. When the local process handles client requests, since the business processing is implemented based on Socket sockets rather than establishing a session linked list based on the traditional forwarding process, the existing source-in-source-out mechanism based on the five-tuple session table cannot be directly reused.

[0049] For example, in DNS service scenarios, the local DNS service process (such as the BIND process) typically uses Socket to create UDP or TCP communication endpoints to send and receive packets when processing client DNS requests. During this process, no packet session list based on the forwarding layer is established. When DNS requests with the same source IP address enter the device from different interfaces, and multiple requests trigger response packets simultaneously, the response packets may return from different interfaces based on routing lookup results. This results in request and response packets not passing through the same interface, causing the client to be unable to receive DNS response packets normally, affecting the stability and reliability of DNS service communication.

[0050] Based on this, this application proposes a DNS service response method based on a local process. Addressing the technical problem that request and response packets cannot pass through the same interface when the local DNS service process in a multi-interface load balancing device handles client requests, this method records the ingress interface identifier information of the request packet in the session and combines it with the source-ingress-source-egress marking mechanism of the Socket socket to achieve source-ingress-source-egress functionality in a local DNS service scenario. This improves the stability and reliability of DNS service responses without the need to establish a traditional forwarding session linked list.

[0051] The content of this application will be described in detail below with reference to specific embodiments.

[0052] Figure 1 This is a flowchart illustrating a DNS service response method based on a local process, according to an exemplary embodiment. The DNS service response method 10 based on a local process includes at least steps S102 to S110. The method can be applied to load balancing devices with multiple ISP outbound links, and is particularly suitable for scenarios where the device runs a local DNS service process (such as the BIND process) internally and provides DNS resolution services externally. When multiple ISP links are accessed simultaneously, to ensure that DNS request packets and DNS response packets enter and exit the device through the same interface, and to avoid the client being unable to receive DNS response packets normally due to inconsistent paths, this embodiment proposes a DNS service response method based on a local process.

[0053] like Figure 1 As shown, in S102, the load balancing device associates the ingress interface identifier information of the DNS request message with its corresponding session.

[0054] Specifically, the load balancing device receives DNS request packets sent by clients in real time via its network interface card (NIC) and identifies the ingress interface information corresponding to the DNS request packet when it enters the device. The DNS request packet can be a UDP DNS request packet or a TCP DNS request packet. UDP packets are typically used for ordinary DNS query scenarios, while TCP packets can be used for scenarios such as zone transfers, large packet transmissions, or DNSSEC.

[0055] Upon receiving a DNS request message, the device obtains the ingress interface identifier information corresponding to the DNS request message entering the device, and associates the ingress interface identifier information with the session corresponding to the DNS request message. The ingress interface identifier information may include information such as interface index, interface name, logical interface identifier, or physical interface identifier.

[0056] More specifically, the MAC address corresponding to the ingress interface in the ingress interface identification information can be associated with the session corresponding to the DNS request message. Since the MAC address can uniquely identify the network interface corresponding to the message when it enters the device, by recording the MAC address corresponding to the interface, the ingress interface information corresponding to the request message can be accurately recovered in the subsequent response message sending stage, thereby providing a basis for source-in, source-out.

[0057] In one embodiment, when a client request message first enters the device, the device creates a corresponding session structure for the request and records the interface MAC address corresponding to the request message entering the device in the session structure. Subsequent DNS request messages in the same session can update and overwrite the recorded MAC address to ensure that the session stores the ingress interface information corresponding to the most recent request.

[0058] It should be noted that the sessions in this embodiment are mainly used to associate request packets with ingress interface identification information, and are different from the complete forwarding session linked list established based on the five-tuple of forwarding layer packets in the prior art. This embodiment can realize the source-in-source-out function in the local DNS service scenario without establishing a traditional forwarding layer session table, thereby reducing the resource consumption caused by establishing and maintaining the forwarding session linked list.

[0059] In S104, the local DNS service process creates a Socket and sets a source-in-source-out flag on the Socket.

[0060] In one embodiment, before the local DNS service process creates the Socket socket, the method further includes: sending the DNS request message to the local DNS service process for processing.

[0061] Specifically, when the load balancing device identifies that the DNS request message belongs to the local DNS service, it can send the DNS request message from the forwarding plane to the control plane or the local service processing module, where the local DNS service process will perform the resolution processing. The local DNS service process can be, for example, the BIND process.

[0062] During the processing of DNS request messages, the local DNS service process will create corresponding UDPSocket or TCPSocket sockets as needed for subsequent DNS response messages.

[0063] After the socket is successfully created, the setsockopt function can be called to set a custom source-in-source-out flag on the socket. The source-in-source-out flag is used to indicate that the service traffic corresponding to the current socket needs to execute the source-in-source-out sending strategy.

[0064] Specifically, a preset flag can be written into the option field of the Socket, so that the system packet sending process can identify whether the current Socket needs to perform targeted packet sending based on the ingress interface when sending response messages.

[0065] In S106, during the DNS response message sending process, the presence of a source-in-source-out marker on the Socket is checked. Specifically, after the local DNS service process completes the domain name resolution process, it calls the system sending interface to send a DNS response message. Before sending the message, the system packet sending process first checks whether a source-in-source-out marker exists on the current Socket.

[0066] If the source-in-source-out flag is detected in the Socket, it means that the current response message needs to perform the source-in-source-out processing procedure and proceeds to step S108; if the source-in-source-out flag is not detected, it means that the current service does not need to perform the source-in-source-out processing procedure and proceeds to step S110.

[0067] In step S108, upon detecting the source-in / source-out marker, the target egress interface is determined, and the DNS response message is sent through the target egress interface. The target egress interface corresponding to the response message can be determined based on the ingress interface identifier information associated with the session.

[0068] In S110, if the source-in-source-out marker is not detected, the DNS response message is sent according to the routing lookup result.

[0069] Specifically, for Sockets without source-in / source-out tags, the system maintains the original standard sending process, performs normal route lookup based on the device's current routing table, forwarding table, or load balancing policy, and sends a DNS response message after determining the packet's outgoing interface based on the lookup results.

[0070] Therefore, this embodiment, while maintaining compatibility with the original routing and forwarding mechanism, records the interface MAC address in the session and combines it with the Socket source-in-source-out marking mechanism to realize the source-in-source-out function in the local DNS service scenario. This solves the problem in the prior art where the local process cannot establish a forwarding session linked list when processing DNS requests, which may result in response packets being returned from different interfaces. Without the need to establish a traditional five-tuple forwarding session linked list, it improves the stability and reliability of DNS service responses and the service processing capacity of the load balancing device.

[0071] According to the DNS service response method based on the local process of this application, the ingress interface identifier information of the DNS request message is associated with its corresponding session through a load balancing device; the local DNS service process creates a Socket and sets a source-ingress-source-egress mark on the Socket; during the DNS response message sending process, the presence of the source-ingress-source-egress mark in the Socket is detected; when the source-ingress-source-egress mark is detected, the target egress interface is determined, and the DNS response message is sent through the target egress interface; when the source-ingress-source-egress mark is not detected, the DNS response message is sent according to the routing lookup result. This method eliminates the need to establish a forwarding session list, enabling the local DNS process's response message to return from the original request interface, effectively ensuring service connectivity in multi-link scenarios.

[0072] It should be clearly understood that this application describes how specific examples are formed and used, but the principles of this application are not limited to any details of these examples. Rather, based on the teachings of the disclosure of this application, these principles can be applied to many other embodiments.

[0073] Figure 2 This is a flowchart illustrating a DNS service response method based on a local process, according to another exemplary embodiment. Figure 2 The process shown in step 20 is... Figure 1 The process shown in the diagram describes in detail S102 "Associating the MAC address corresponding to the ingress interface in the ingress interface identification information with the session corresponding to the DNS request message".

[0074] like Figure 2 As shown in S202, a session is created when a client request message first enters the device. Specifically, when the load balancer receives a DNS request message from a client through the network interface, it first determines whether a corresponding session already exists for the current request message. If no corresponding session exists, a new session structure is created for the request message, and the association between the request message and the session is established. The session can be used to store status information and interface information related to the current DNS request, so that it can be queried and invoked when subsequent DNS response messages are sent.

[0075] It should be noted that the session in this embodiment differs from the session list established based on the five-tuple of forwarding layer packets in existing technologies. It is primarily used to maintain interface association information required during the processing of the local DNS service process, rather than for maintaining the forwarding path of ordinary forwarding packets. By establishing a lightweight session structure, source-in, source-out functionality in a local DNS service scenario can be achieved without constructing a complete forwarding session list.

[0076] In S204, the ingress interface identifier information corresponding to the DNS request message is recorded in the session.

[0077] Specifically, the load balancing device obtains the ingress interface identifier information corresponding to the DNS request message entering the device, and writes the ingress interface identifier information into the corresponding session structure for storage.

[0078] In one embodiment, the ingress interface identification information includes the MAC address of the interface corresponding to the request message when it enters the device. Since a MAC address can uniquely identify a physical or logical interface on a device, accurate identification of the ingress interface of the request message can be achieved by recording the MAC address.

[0079] For example, when a client's DNS request enters the device from the interface corresponding to ISP1, the device records the MAC address corresponding to that interface in the session. When a corresponding DNS response message needs to be sent later, the device can locate the interface corresponding to the initial entry of the request message into the device based on that MAC address, thereby enabling the response message to be returned according to the request path.

[0080] In S206, subsequent request messages in the same session update and overwrite the recorded ingress interface identification information.

[0081] Specifically, if a DNS request message belonging to the same session is received again during the session's lifecycle, the device will re-acquire the ingress interface identifier information corresponding to the current request message and use the new ingress interface identifier information to overwrite the information of the original record in the session.

[0082] In one embodiment, when DNS requests from the same client enter the device from different carrier links or different logical interfaces, the device updates the MAC address stored in the session to the MAC address of the interface corresponding to the most recent request message, thereby ensuring that the latest inbound interface information is always stored in the session.

[0083] For example, when a client first accesses the DNS service through the ISP1 link, the MAC address corresponding to the ISP1 interface is recorded in the session. Subsequently, when the client sends a DNS request again through the ISP2 link, the original MAC address in the session will be updated to the MAC address corresponding to the ISP2 interface. At this time, the subsequently generated DNS response message will determine the target outgoing interface based on the updated MAC address and return it to the client through the corresponding interface.

[0084] This embodiment implements a dynamic association mechanism between DNS request packet ingress interface information and sessions. It continuously maintains the interface information corresponding to the request packet entering the device within the session, providing a data foundation for subsequent lookup of the target egress interface based on the MAC address and achieving source-in / source-out communication. Simultaneously, this scheme eliminates the need to establish a forwarding session linked list based on the packet's 5-tuple, avoiding the system resource consumption caused by session linked list creation, maintenance, and querying in traditional source-in / source-out schemes, thus improving processing efficiency and operational reliability in local DNS service scenarios.

[0085] Figure 3 This is a flowchart illustrating a DNS service response method based on a local process, according to another exemplary embodiment. Figure 3 The process shown in step 30 is... Figure 1 The flowchart shown describes step S108, "Determine the target outgoing interface corresponding to the response message based on the incoming interface identifier information associated with the session."

[0086] like Figure 3 As shown, in S302, the MAC address recorded in the session is obtained. Specifically, the system reads the ingress interface MAC address recorded in the session based on the session information corresponding to the current response message, in order to determine the interface information corresponding to when the client request message enters the device.

[0087] In S304, the validity of the MAC address is verified.

[0088] Specifically, it can detect whether the MAC address is empty, whether it conforms to a preset MAC address format, and whether it exists in the current device interface table, in order to avoid interface lookup failure caused by abnormal MAC addresses.

[0089] In S306, the corresponding physical or logical interface is located based on the MAC address after verification.

[0090] The physical interface can be an actual network card port, while the logical interface can be a VLAN interface, aggregation interface, tunnel interface, or other virtual interface.

[0091] The device can determine the corresponding target interface information through the interface management module, interface mapping table, or MAC interface mapping relationship.

[0092] In S308, the found interface is determined as the target outgoing interface of the response message.

[0093] Subsequently, the system bypasses the normal route lookup process and directly sends DNS response messages through the target outgoing interface, thereby ensuring that DNS response messages and DNS request messages enter and exit the device through the same interface, realizing the source-in-source-out function.

[0094] Those skilled in the art will understand that all or part of the steps of the above embodiments are implemented as a computer program executed by a CPU. When the computer program is executed by the CPU, it performs the functions defined by the method provided in this application. The program can be stored in a computer-readable storage medium, such as a read-only memory, a magnetic disk, or an optical disk.

[0095] Furthermore, it should be noted that the above figures are merely illustrative representations of the processes included in the method according to exemplary embodiments of this application, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0096] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0097] Figure 4 This is a block diagram illustrating a DNS service response apparatus based on a local process, according to an exemplary embodiment. Figure 4 As shown, the DNS service response device 40 based on local processes includes: an association module 402, a marking module 404, a detection module 406, a target module 408, and a routing module 410.

[0098] The association module 402 is used by the load balancing device to associate the ingress interface identifier information of the DNS request message with its corresponding session; the association module 402 is also used by the load balancing device to obtain the DNS request message sent by the client; obtain the ingress interface identifier information corresponding to the DNS request message when it enters the device; and associate the ingress interface identifier information with the session corresponding to the DNS request message.

[0099] The tagging module 404 is used by the local DNS service process to create a Socket and set a source-in-source-out tag on the Socket. The tagging module 404 is also used to send the DNS request message to the local DNS service process for processing. After the socket is successfully created, the tagging module 404 is also used to call the setsockopt function to set a custom source-in-source-out tag on the socket.

[0100] The detection module 406 is used to detect whether the Socket has a source-in-source-out marker during the DNS response message sending process; The target module 408 is used to determine the target egress interface when the source-in-source-out marker is detected, and to send the DNS response message through the target egress interface; the target module 408 is also used to determine the target egress interface corresponding to the response message according to the ingress interface identifier information associated with the session.

[0101] The routing module 410 is used to send the DNS response message according to the routing lookup result when the source-in-source-out marker is not detected.

[0102] According to the DNS service response device based on the local process of this application, the ingress interface identification information of the DNS request message is associated with its corresponding session through a load balancing device; the local DNS service process creates a Socket and sets a source-ingress-source-egress mark on the Socket; during the DNS response message sending process, the presence of the source-ingress-source-egress mark in the Socket is detected; when the source-ingress-source-egress mark is detected, the target egress interface is determined, and the DNS response message is sent through the target egress interface; when the source-ingress-source-egress mark is not detected, the DNS response message is sent according to the routing lookup result. This method eliminates the need to establish a forwarding session list, enabling the local DNS process's response message to return from the original request interface, effectively ensuring service connectivity in multi-link scenarios.

[0103] Figure 5 This is a block diagram illustrating an electronic device according to an exemplary embodiment.

[0104] The following reference Figure 5 To describe an electronic device 500 according to this embodiment of the present application. Figure 5 The electronic device 500 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0105] like Figure 5 As shown, the electronic device 500 is presented in the form of a general-purpose computing device. The components of the electronic device 500 may include, but are not limited to: at least one processing unit 510, at least one storage unit 520, a bus 530 connecting different system components (including storage unit 520 and processing unit 510), a display unit 540, etc.

[0106] The storage unit stores program code that can be executed by the processing unit 510, causing the processing unit 510 to perform the steps described in this specification according to various exemplary embodiments of this application. For example, the processing unit 510 can perform actions such as... Figure 1 , Figure 2 , Figure 3 The steps are shown in the figure.

[0107] The storage unit 520 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 5201 and / or a cache storage unit 5202, and may further include a read-only memory unit (ROM) 5203.

[0108] The storage unit 520 may also include a program / utility 5204 having a set (at least one) program module 5205, such program module 5205 including but not limited to: an operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0109] Bus 530 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0110] Electronic device 500 can also communicate with one or more external devices 500' (e.g., keyboard, pointing device, Bluetooth device, etc.), enabling users to communicate with devices that interact with electronic device 500, and / or any device (e.g., router, modem, etc.) that allows electronic device 500 to communicate with one or more other computing devices. This communication can be performed via input / output (I / O) interface 550. Furthermore, electronic device 500 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 560. Network adapter 560 can communicate with other modules of electronic device 500 via bus 530. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0111] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software, or by combining software with necessary hardware. Therefore, as... Figure 6 As shown, the technical solution according to the embodiments of this application can be embodied in the form of a software product. The software product can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, mobile hard drive, etc.) or on a network, and includes several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the above-described method according to the embodiments of this application.

[0112] The software product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may 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 readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable 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 devices, magnetic storage devices, or any suitable combination thereof.

[0113] The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying 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 readable storage medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0114] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0115] The aforementioned computer-readable medium carries one or more programs, which, when executed by a device, cause the computer-readable medium to perform the following functions: the load balancing device associates the ingress interface identifier information of a DNS request message with its corresponding session; the local DNS service process creates a Socket and sets a source-ingress-source-egress marker on the Socket; during the transmission of a DNS response message, it detects whether the Socket has a source-ingress-source-egress marker; when the source-ingress-source-egress marker is detected, it determines the target egress interface and sends the DNS response message through the target egress interface; when the source-ingress-source-egress marker is not detected, it sends the DNS response message according to the routing lookup result.

[0116] Those skilled in the art will understand that the above modules can be distributed in the device as described in the embodiments, or they can be modified accordingly and placed in one or more devices that are unique to this embodiment. The modules in the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0117] Through the description of the above embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0118] Exemplary embodiments of this application have been specifically shown and described above. It should be understood that this application is not limited to the detailed structures, arrangements, or implementation methods described herein; rather, this application is intended to cover various modifications and equivalent arrangements contained within the spirit and scope of the appended claims.

Claims

1. A DNS service response method based on a local process, characterized in that it includes: The load balancing device associates the ingress interface identifier information of the DNS request packet with its corresponding session; The local DNS service process creates a Socket and sets a source-in-source-out flag on the Socket; During the DNS response message sending process, it is detected whether the Socket has a source-in-source-out flag; Upon detecting the source-in-source-out marker, the target outgoing interface is determined, and the DNS response message is sent through the target outgoing interface; If the source-in / source-out marker is not detected, the DNS response message is sent according to the routing lookup result.

2. The method as described in claim 1, characterized in that, The load balancing device associates the ingress interface identifier information of DNS request packets with their corresponding sessions, including: The load balancer receives DNS request packets sent by the client; Obtain the ingress interface identifier information corresponding to the DNS request message when it enters the device; Associate the ingress interface identification information with the session corresponding to the DNS request message.

3. The method as described in claim 2, characterized in that, Associating the ingress interface identification information with the session corresponding to the DNS request message includes: Associate the MAC address corresponding to the ingress interface in the ingress interface identification information with the session corresponding to the DNS request message.

4. The method as described in claim 2, characterized in that, Associating the ingress interface identification information with the session corresponding to the DNS request message includes: A session is created when a client request message first enters the device; The ingress interface identifier information corresponding to the DNS request message is recorded in the session; Subsequent request messages in the same session will update and overwrite the recorded ingress interface identifier information.

5. The method as described in claim 1, characterized in that, Before the local DNS service process creates the Socket, it also includes: The DNS request message is sent to the local DNS service process for processing.

6. The method as described in claim 1, characterized in that, Setting source-in / source-out markers on the socket includes: After the socket is successfully created, the setsockopt function is called to set a custom source-in, source-out flag on the socket.

7. The method as described in claim 1, characterized in that, Determine the target outgoing interface, including: The target outgoing interface corresponding to the response message is determined based on the ingoing interface identifier information associated with the session.

8. The method as described in claim 7, characterized in that, The target outgoing interface corresponding to the response message is determined based on the ingoing interface identifier information associated with the session, including: Obtain the MAC address recorded in the session; Perform a validity check on the MAC address; Find the corresponding physical or logical interface based on the MAC address after successful verification; The found interface is determined as the target outgoing interface for the response message.

9. The method as described in claim 1, characterized in that, The DNS request message can be a UDP message or a TCP message.

10. A DNS service response apparatus based on a local process, characterized in that it comprises: The association module is used by the load balancing device to associate the ingress interface identification information of DNS request packets with their corresponding sessions; The tagging module is used by the local DNS service process to create a Socket and set a source-in-source-out tag on the Socket; The detection module is used to detect whether the Socket has a source-in-source-out flag during the DNS response message sending process; The target module is used to determine the target egress interface when the source-in-source-out marker is detected, and to send the DNS response message through the target egress interface; The routing module is used to send the DNS response message according to the routing lookup result when the source-in-source-out marker is not detected.

Images