A DNS message processing method, device and equipment

Abstract

The application provides a DNS message processing method, device and equipment. The method comprises the following steps: receiving a first DNS request message sent by a DNS client; storing a domain name to be requested in a DNS listening table item; sending a second DNS request message to a DNS server, wherein the second DNS request message comprises target slot position identification of a first interface board; when a first DNS response message sent by a second interface board is received and the target slot position identification comprised in the first DNS response message is the same as the slot position identification of the first interface board, storing an IP address corresponding to the domain name to be requested in the DNS listening table item; sending a second DNS response message to the DNS client; wherein the first DNS response message is sent by the DNS server to the second interface board, and the second interface board forwards the first DNS response message to the first interface board after determining that the target slot position identification is different from the slot position identification of the second interface board. According to the application, a large number of DNS response messages do not need to be transmitted between the interface board and the main control board, and the processing resources of the main control board are saved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a DNS message processing method, apparatus and device. Background Technology

[0002] When network devices (such as routers and switches) receive a DNS (Domain Name System) response message from a DNS server, they can obtain the domain name and IP address (i.e., the IP address corresponding to the domain name) from the DNS response message and store the IP address. Based on this, the stored IP address can be used as a legitimate IP address. The network device allows data packets accessing legitimate IP addresses and discards data packets accessing illegitimate IP addresses, thereby achieving data packet access control.

[0003] When the network device is a distributed device, the distributed device may include a main control board and multiple interface boards. When the interface board receives a DNS response message, it needs to send a DNS response message to the main control board. The main control board then obtains the domain name and IP address from the DNS response message and stores the IP address.

[0004] However, this method requires the transmission of a large number of DNS response messages between the interface board and the main control board. These DNS response messages consume bandwidth between the interface board and the main control board, resulting in low processing performance. It also consumes significant processing and storage resources of the main control board. Summary of the Invention

[0005] This application provides a Domain Name System (DNS) message processing method. The method is applied to a first interface board located within a distributed device, which further includes a second interface board. The method includes: receiving a first DNS request message sent by a DNS client, the first DNS request message including a domain name to be requested; storing the domain name to be requested in a DNS listener table entry; sending a second DNS request message to a DNS server, the second DNS request message including a target slot identifier of the first interface board; when receiving a first DNS response message sent by the second interface board, and the target slot identifier included in the first DNS response message is the same as the slot identifier of the first interface board, storing the IP address corresponding to the domain name to be requested included in the first DNS response message in the DNS listener table entry; sending a second DNS response message to the DNS client, the second DNS response message including the IP address but not including the target slot identifier; wherein the first DNS response message is sent by the DNS server to the second interface board, and the second interface board forwards the message to the first interface board after determining that the target slot identifier is different from the slot identifier of the second interface board.

[0006] This application provides a DNS message processing apparatus. The apparatus is applied to a first interface board, which is located within a distributed device. The distributed device further includes a second interface board. The apparatus comprises: a first receiving module for receiving a first DNS request message sent by a DNS client, the first DNS request message including a domain name to be requested; a first storage module for storing the domain name to be requested in a DNS listening table entry; a first sending module for sending a second DNS request message to a DNS server, the second DNS request message including a target slot identifier of the first interface board; and a second storage module for processing DNS messages when a first DNS request message is received from the second interface board. If the first DNS response message contains a target slot identifier that is the same as the slot identifier of the first interface board, then the IP address corresponding to the requested domain name included in the first DNS response message is stored in the DNS listening table entry; the second sending module is used to send a second DNS response message to the DNS client, the second DNS response message including the IP address but not including the target slot identifier; wherein, the first DNS response message is sent by the DNS server to the second interface board, and the second interface board forwards it to the first interface board after determining that the target slot identifier is different from the slot identifier of the second interface board.

[0007] This application provides a distributed device, including: a processor and a machine-readable storage medium, wherein the machine-readable storage medium stores machine-executable instructions that can be executed by the processor; the processor is used to execute the machine-executable instructions to implement the DNS message processing method of the example above in this application.

[0008] This application provides a computer program product, which includes a computer program that, when executed by a processor, implements the DNS message processing method of the above example of this application.

[0009] This application provides a machine-readable storage medium storing machine-executable instructions that can be executed by a processor; wherein the processor is used to execute the machine-executable instructions to implement the DNS message processing method of the example above in this application.

[0010] As can be seen from the above technical solutions, in this embodiment, when the first interface board receives a DNS request message, it can add the target slot identifier of the first interface board to the DNS request message, so that when the DNS server returns a DNS response message, the DNS response message also carries the target slot identifier. Thus, when the second interface board receives a DNS response message, it can send a DNS response message to the first interface board based on the target slot identifier. The first interface board obtains the IP address corresponding to the requested domain name from the DNS response message, stores the IP address in the DNS listening table entry, and then implements the DNS listening function based on the DNS listening table entry, enabling the distributed device to support the DNS listening function. In the above process, the processing of the DNS response message (or DNS request message) does not need to go through the main control board, and there is no need to transmit a large number of DNS response messages between the interface board and the main control board, thereby saving bandwidth between the interface board and the main control board, and the processing performance of the DNS response message is high. It can save the processing and storage resources of the main control board and improve the processing performance of the main control board. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating a DNS message processing method according to one embodiment of this application;

[0012] Figure 2A This is a schematic diagram of the structure of a centralized device in one embodiment of this application;

[0013] Figure 2B This is a schematic diagram of the structure of a distributed device in one embodiment of this application;

[0014] Figure 2C This is a network topology diagram of EVPN VXLAN in one embodiment of this application;

[0015] Figure 2D This is a schematic diagram of a centralized gateway and a distributed gateway in one embodiment of this application;

[0016] Figure 3A This is a schematic diagram of a centralized device supporting DNS Snooping in one embodiment of this application;

[0017] Figure 3B This is a schematic diagram illustrating distributed device support for DNS Snooping in one embodiment of this application;

[0018] Figure 3C This is a schematic diagram illustrating distributed gateway supporting DNS Snooping in one embodiment of this application;

[0019] Figure 4A This is a flowchart illustrating a DNS message processing method according to one embodiment of this application;

[0020] Figure 4B This is a flowchart illustrating a DNS message processing method according to one embodiment of this application;

[0021] Figure 5 This is a flowchart illustrating a DNS message processing method according to one embodiment of this application;

[0022] Figure 6 This is a schematic diagram of the structure of a DNS message processing device according to one embodiment of this application;

[0023] Figure 7 This is a hardware structure diagram of a distributed device in one embodiment of this application. Detailed Implementation

[0024] This application proposes a DNS message processing method. This method is applied to a first interface board, which is located within a distributed device (such as a distributed network device). The distributed device also includes a second interface board. See also... Figure 1 The diagram shown is a flowchart of the method, which may include:

[0025] Step 101: Receive the first DNS request message sent by the DNS client. The first DNS request message includes the domain name to be requested. Store the domain name to be requested in the DNS listener table entry.

[0026] Step 102: Send a second DNS request message to the DNS server. The second DNS request message includes the target slot identifier of the first interface board.

[0027] Step 103: When a first DNS response message is received from the second interface board and the target slot identifier included in the first DNS response message is the same as the slot identifier of the first interface board, the IP address corresponding to the requested domain name included in the first DNS response message is stored in the DNS listening table entry; wherein, the first DNS response message is sent by the DNS server to the second interface board, and the second interface board forwards it to the first interface board after determining that the target slot identifier is different from the slot identifier of the second interface board.

[0028] Step 104: Send a second DNS response message to the DNS client. The second DNS response message includes the IP address but does not include the target slot identifier of the first interface board.

[0029] In one example, after storing the requested domain name in a DNS listener entry, an aging timer can be set for the DNS listener entry. If the IP address corresponding to the requested domain name is not obtained when the aging timer expires, the DNS listener entry can be deleted. Similarly, after storing the IP address corresponding to the requested domain name included in the first DNS response message in the DNS listener entry, the aging timer corresponding to the DNS listener entry can also be deleted. The DNS listener entry is used to generate a security policy, which includes the IP address. This security policy controls access messages. Specifically, when an access message is received, if the IP address in the security policy includes the destination IP address of the access message, the access message is forwarded to the application server corresponding to the destination IP address; otherwise, the access message is blocked.

[0030] In one example, before sending a second DNS request message to the DNS server, if the first DNS request message includes an additional field, the target slot identifier and the specified type identifier of the first interface board are added to the first custom option field of the additional field to obtain the second DNS request message; wherein, the first custom option field includes a first option code field and a first option data field, the first option code field is used to carry the specified type identifier, and the first option data field is used to carry the target slot identifier of the first interface board;

[0031] Alternatively; if the first DNS request message does not include additional fields, then add additional fields to the first DNS request message, and add the target slot identifier and specified type identifier of the first interface board to the first custom option field of the additional fields to obtain the second DNS request message;

[0032] The specified type identifier is used to instruct the DNS server to migrate the custom option fields in the second DNS request message to the first DNS response message.

[0033] In one example, after sending a second DNS request message to the DNS server, when a first DNS response message is received from the DNS server and the target slot identifier included in the first DNS response message is the same as the slot identifier of the first interface board, the IP address corresponding to the requested domain name included in the first DNS response message is stored in the DNS listening table entry, and a second DNS response message is sent to the DNS client.

[0034] In one example, the distributed gateway may include multiple member devices with the same IP address. The distributed device can be the first member device (i.e., any member device) among these member devices. The second DNS request message may also include the target route identifier of the first member device. When the second interface board receives the first DNS response message returned by the DNS server, then: the first DNS response message can be sent directly from the DNS server to the first member device; or, the first DNS response message can be sent from the DNS server to the second member device, and then forwarded by the second member device to the first member device based on the target route identifier.

[0035] In one example, the additional fields in the second DNS request message include a second custom option field, which includes a second option code field and a second option data field. The second option code field is used to carry a specified type identifier, and the second option data field is used to carry the target route identifier of the first member device. The specified type identifier is used to instruct the DNS server to migrate the second custom option field in the second DNS request message to the first DNS response message.

[0036] As can be seen from the above technical solutions, in this embodiment, when the first interface board receives a DNS request message, it can add the target slot identifier of the first interface board to the DNS request message, so that when the DNS server returns a DNS response message, the DNS response message also carries the target slot identifier. Thus, when the second interface board receives a DNS response message, it can send a DNS response message to the first interface board based on the target slot identifier. The first interface board obtains the IP address corresponding to the requested domain name from the DNS response message, stores the IP address in the DNS listening table entry, and then implements the DNS listening function based on the DNS listening table entry, enabling the distributed device to support the DNS listening function. In the above process, the processing of the DNS response message (or DNS request message) does not need to go through the main control board, and there is no need to transmit a large number of DNS response messages between the interface board and the main control board, thereby saving bandwidth between the interface board and the main control board, and the processing performance of the DNS response message is high. It can save the processing and storage resources of the main control board and improve the processing performance of the main control board.

[0037] The technical solutions described above in the embodiments of this application will be explained below in conjunction with specific application scenarios.

[0038] Before introducing the DNS message processing method of this application, let's first introduce the concepts related to this application.

[0039] First, centralized equipment. See also... Figure 2AThe diagram shows the structure of a centralized device, where device A is the centralized device. A centralized device may consist only of a main control board and may not have separate interface boards. A centralized device may include multiple interfaces, such as interface 1, interface 2, ..., interface n.

[0040] Second, distributed devices. See also Figure 2B The diagram shows the structure of a distributed device. Device A is the distributed device, which can include multiple main control boards and multiple interface boards. Figure 2B In this context, distributed devices may include main control board 1, main control board 2, ..., main control board m. Distributed devices may include interface board 1, interface board 2, interface board 3, ..., interface board n.

[0041] Third, distributed gateways for EVPN (Ethernet Virtual Private Network) and VXLAN (Virtual Extensible Local Area Network).

[0042] As network scale continues to expand and business demands become increasingly complex, centralized gateway architectures suffer from numerous problems, driving the development of distributed gateway networking. A centralized gateway refers to a single gateway device, while a distributed gateway refers to multiple gateway devices. For example, centralized gateways have the following issues:

[0043] Performance bottleneck: All traffic needs to be processed through a single gateway device, which can easily become a bottleneck for network performance. Insufficient scalability: Limited hardware resources make it difficult to support the expansion needs of large-scale networks. Single point of failure: Once the gateway device fails, the entire network will be affected, lacking high availability. Management complexity: As the network scales up, the configuration and management of centralized gateways become increasingly complex.

[0044] EVPN VXLAN is a Layer 2 VPN technology. Its control plane uses MP-BGP (Multiprotocol Border Gateway Protocol) to advertise EVPN routing information, while its data plane uses VXLAN encapsulation to forward packets. EVPN VXLAN identifies VXLAN networks using VXLAN IDs and maintains an independent MAC (Media Access Control) address table for each VXLAN network, enabling Layer 2 communication within the same VXLAN network and Layer 2 isolation between different VXLAN networks. By deploying an EVPN VXLAN gateway in the network, Layer 3 communication between different VXLAN networks and Layer 3 communication between a VXLAN network and external networks can also be achieved.

[0045] See Figure 2C The diagram shows a network topology diagram of EVPN VXLAN. EVPN VXLAN can include the following components: VTEP (VXLAN Tunnel Endpoints): EVPN network edge devices; all EVPN-related processing is performed on the VTEP. VXLAN Tunnel: A point-to-point logical connection between two VTEPs. AC: The physical or virtual circuit connecting the site (e.g., a server) and the VTEP, such as an Ethernet link or VLAN.

[0046] In one example, the technical advantages of EVPN VXLAN may include:

[0047] Simplified network configuration: Automatic VTEP discovery and VXLAN tunnel establishment are achieved via MP-BGP, eliminating the need for manual user configuration and reducing network deployment complexity. By deploying a BGP route reflector in the network, when a new VTEP is added, it only needs to establish a connection with the route reflector to automatically establish a VXLAN tunnel between the new VTEP and existing VTEPs, simplifying network upgrades.

[0048] Reduced flooding: After learning its local MAC address, ARP, and ND information, the VTEP advertises this information to remote VTEPs via BGP EVPN routing. Compared to dynamically learning entries through packets, this reduces flooding traffic on the backbone network.

[0049] Supports multiple affiliations: By forming a redundant backup group with multiple VTEPs, the network interruption problem caused by a single point of failure of the VTEP can be solved, and the traffic load can be distributed among multiple VTEPs.

[0050] Supports Layer 3 interconnection: EVPN VXLAN can not only provide Layer 2 interconnection for physical sites located in different locations, but also provide Layer 3 interconnection between different physical sites through EVPN gateways.

[0051] In one example, Layer 2 interconnection for an EVPN VXLAN site network:

[0052] Automatic VXLAN Tunnel Establishment: The local VTEP advertises its VXLAN network (i.e., VXLAN ID) to the remote VTEP via IMET or MAC / IP routes. If the local and remote VTEPs belong to the same VXLAN network, a VXLAN tunnel is automatically established between them and associated with that VXLAN network.

[0053] MAC address learning: After receiving a Layer 2 data frame from the local site via the AC, the local VTEP learns the source MAC address (the source MAC address of the Layer 2 data frame) into the MAC address table of the VXLAN network to which the AC belongs, and then advertises the MAC address information to the remote VTEP via MAC / IP route advertising. The remote VTEP learns the MAC address based on the received MAC / IP route advertising.

[0054] Layer 2 data frame forwarding: After receiving a Layer 2 data frame from the AC, the local VTEP looks up the destination MAC address in the MAC address table of the VXLAN network to which the AC belongs. If a matching MAC address entry is found, the Layer 2 data frame is forwarded to the local site. Alternatively, it can be forwarded to a remote VTEP via a VXLAN tunnel. The remote VTEP then looks up the MAC address table of its VXLAN network and forwards the frame to the local site connected to that remote VTEP. If no matching MAC address entry is found, the local VTEP will broadcast the Layer 2 data frame on all ACs and VXLAN tunnels within the VXLAN.

[0055] In one example, regarding Layer 3 interconnection of an EVPN VXLAN site network: To achieve Layer 3 interconnection of the site network, an EVPN VXLAN gateway needs to be deployed in the EVPN VXLAN network, and a VSI virtual interface needs to be configured on the EVPN VXLAN gateway. The VSI virtual interface acts as the gateway interface, and its IP address serves as the gateway address of the site network. The process of Layer 3 interconnection of the site network may include:

[0056] Automatic VXLAN Tunnel Establishment: The local VTEP advertises its VXLAN network (i.e., VXLAN ID) to the remote VTEP via IMET routing, MAC / IP route advertising, or IP prefix routing. If the local VTEP and the remote VTEP belong to the same VXLAN network, a VXLAN tunnel is automatically established between them, and the VXLAN tunnel is associated with that VXLAN network.

[0057] Obtain the gateway MAC address: Hosts within the site network send ARP requests to obtain the MAC address corresponding to the IP address of the gateway device, so as to forward Layer 3 traffic to the gateway device.

[0058] Gateway forwarding of Layer 3 traffic: After receiving Layer 3 traffic, the gateway device looks up the routing table to find the destination VXLAN network. It then forwards the Layer 3 traffic within the destination VXLAN network.

[0059] In one example, EVPN VXLAN gateways are categorized into centralized gateways and distributed gateways. See also... Figure 2DThe diagram shows a centralized gateway and a distributed gateway in an EVPN VXLAN network.

[0060] For centralized gateways: Only one VTEP device acts as the EVPN gateway in the network. All traffic between different VXLANs and traffic from VXLANs accessing external networks is handled by the centralized gateway. This networking method is simple to configure, but the centralized gateway faces significant load. For distributed gateways: Multiple VTEP devices act as EVPN gateways, performing Layer 3 forwarding on traffic from local sites, thus alleviating the gateway's load. In distributed gateway networking, a border gateway is typically also deployed for communication with external networks.

[0061] Fourth, the Router ID in EVPN.

[0062] In an EVPN architecture, the route identifier is used to identify and differentiate devices within the network (such as Leaf switches). The route identifier is a key parameter in BGP (Border Gateway Protocol) used to distribute and identify routing information in the control plane. A route identifier is a 32-bit identifier used to uniquely identify a BGP router. For example, the route identifier can be used as the unique identifier for a BGP router.

[0063] During BGP session establishment, the route identifier appears in the BGP Open message. The BGP Open message is the first step in BGP session establishment and is used to negotiate session parameters. In the BGP Open message, the route identifier is part of the BGP header, specifically located in the "BGP Identifier" field. This field is 4 bytes long and is used to identify the BGP peer that sent the BGP Open message.

[0064] In BGP update messages, route identifiers may appear in optional attributes, such as the ORIGINATOR_ID attribute. In BGP EVPN or route reflector scenarios, the ORIGINATOR_ID attribute is used to identify the originator of the route, and its value is usually the route identifier of the BGP peer that initiated the route.

[0065] In addition, BGP Keepalive messages are used to maintain connections between BGP peers; however, they do not carry route identifiers. Similarly, BGP Notification messages are used to report errors or terminate a BGP session; however, they also do not carry route identifiers.

[0066] Fifth, the basic principles of DNS.

[0067] The functions of DNS are as follows: Domain name resolution (forward resolution): Converts a domain name (e.g., www.aaa.com) into an IP address (e.g., 192.0.2.1). Reverse resolution: Looks up a domain name using its IP address. Load balancing: Distributes traffic to different servers using DNS round-robin. Mail routing: Specifies mail servers using MX records.

[0068] DNS uses a hierarchical query mechanism, and the resolution process is as follows: Browser cache query: The browser first checks its local cache for the IP address of the domain name. If not, it queries the operating system cache (such as the hosts file in Windows). Recursive query (query to the local DNS server): If there is no local cache, the browser sends a request to the local DNS server (such as the DNS provided by the ISP or 8.8.8.8); if the local DNS server does not have the record, it queries the root DNS server. Iterative query (root domain - top-level domain - authoritative DNS): The root DNS server (.) returns the DNS server address of the top-level domain (such as .com); the top-level domain DNS server (.com) returns the authoritative DNS server for that domain name (such as the DNS of example.com); the authoritative DNS server returns the final IP address (such as 192.0.2.1). Result return and caching: The local DNS server caches the result and returns it to the browser, which then caches the record.

[0069] Sixth, DNS Snooping function. The DNS Snooping function is suitable for scenarios that filter user traffic based on domain names, that is, to implement packet access control based on the DNS Snooping function.

[0070] After other modules (such as the address object group module) send a domain name subscription request to the DNS module, the IP address corresponding to the domain name is obtained through the DNSSnooping function. When the DNS Snooping function is enabled, the device will detect passing DNS request packets and DNS response packets (DNS reply packets).

[0071] If the domain name in the DNS request message matches the subscribed domain name, the device will record the IP address (the IP address corresponding to the domain name) in the DNS response message when it receives the DNS response message for that domain name, and report the IP address to the module that initiated the subscription (such as the address object group module). If the domain name in the DNS request message does not match the subscribed domain name, the device will not record the IP address in the DNS response message.

[0072] Once the module that issued the domain subscription request obtains the IP address corresponding to the domain, it can use that IP address to implement domain-based traffic filtering. Furthermore, when a domain subscribed to by other modules expires, the DNS module will notify the relevant modules to delete the corresponding entry in the table to ensure the accuracy of the entries.

[0073] Seventh, Address Object Groups. The Address Object Groups module, acting as the module that issues domain name subscription requests, can send domain name subscription requests to the DNS module and obtain the IP address corresponding to the domain name.

[0074] For example, IPv4 address objects can be configured within an IPv4 address object group. These address objects are bound to IPv4 addresses or users and are used to match the IPv4 address in a packet or the user to whom the packet belongs.

[0075] For example, IPv6 address objects can be configured within an IPv6 address object group. These address objects are bound to IPv6 addresses or users and are used to match the IPv6 address in a packet or the user to whom the packet belongs.

[0076] Eighth, centralized devices support the basic process of DNS Snooping.

[0077] See Figure 3A The diagram illustrates centralized device support for DNS Snooping. Device A is the centralized device, which includes a main control board. The main control board receives DNS request messages from DNS clients through interface 1, establishes temporary entries based on the DNS request messages, and includes the domain name from the DNS request messages (i.e., the key of the temporary entry is the domain name). It then sends DNS request messages to the DNS server.

[0078] The main control board receives the DNS response message returned by the DNS server through interface n, finds the temporary table entry based on the domain name in the DNS response message, and formalizes the temporary table entry, that is, updates the temporary table entry into the formal table entry. The IP address corresponding to the domain name is obtained from the DNS response message, and the IP address is notified to the module that issued the domain name subscription request.

[0079] In the above process, the main control board creates temporary entries based on DNS request messages and then formalizes the temporary entries based on DNS response messages. This can improve security and increase the difficulty of exhaustion attacks (if entries are only created based on DNS response messages, a large number of DNS response messages may lead to the erroneous creation of a large number of entries).

[0080] Ninth, the basic process of DNS Snooping supported by distributed devices.

[0081] See Figure 3B The diagram shows a distributed device supporting DNS Snooping. Device A is a distributed device, which includes multiple main control boards and multiple interface boards.

[0082] In one example, interface board 1 receives a DNS request message from a DNS client and forwards it to the main control board (e.g., main control board 1). The main control board receives the DNS request message and creates a temporary entry based on it. This temporary entry includes the domain name from the DNS request message; that is, the key of the temporary entry is the domain name. Interface board 1 then sends a DNS request message to the DNS server.

[0083] Interface board n receives the DNS response message returned by the DNS server and forwards it to the main control board (e.g., main control board 1). The main control board receives the DNS response message, finds the temporary entry based on the domain name in the message, and formalizes it (updates the temporary entry to a formal entry). The main control board then retrieves the IP address corresponding to the domain name from the DNS response message and adds it to the formal entry. Interface board n then sends a DNS response message to the DNS client.

[0084] However, in the above method, DNS request messages and DNS response messages need to be transmitted between the interface board and the main control board. These DNS request messages and DNS response messages occupy the bandwidth between the interface board and the main control board, consume a lot of the main control board's processing resources, and occupy a lot of the main control board's storage resources.

[0085] In one example, interface board 1 receives a DNS request message from a DNS client, creates a temporary table entry based on the DNS request message, and the temporary table entry includes the domain name from the DNS request message; that is, the key of the temporary table entry is the domain name. Interface board 1 then sends a DNS request message to the DNS server.

[0086] Interface board n receives the DNS response message returned by the DNS server and broadcasts the DNS response message to all interface boards. When the other interface boards besides interface board 1 receive the DNS response message, they cannot find the temporary table entry based on the domain name in the DNS response message, and therefore discard the DNS response message.

[0087] When interface board 1 receives a DNS response message, it can find a temporary entry based on the domain name in the message. Then, interface board 1 formalizes this temporary entry, updating it to a formal entry. It retrieves the IP address corresponding to the domain name from the DNS response message and adds that IP address to the formal entry. Interface board 1 or interface board n then sends a DNS response message to the DNS client.

[0088] However, in the above method, interface board n needs to broadcast DNS response messages to all interface boards, resulting in the transmission of a large number of DNS response messages. These DNS response messages occupy the bandwidth between interface boards, require a large amount of processing resources from each interface board, generate redundant messages, and affect performance.

[0089] Tenth, the basic process of distributed gateway networking supporting DNS Snooping.

[0090] See Figure 3C The diagram illustrates a distributed gateway supporting DNS Snooping. The distributed gateway includes Leaf1, Leaf2, and Leaf3, which can function as member devices. Since Leaf1, Leaf2, and Leaf3 share the same IP address, the distributed gateway comprises multiple member devices with the same IP address. When the DNS server sends a DNS response message to the distributed gateway, because Leaf1, Leaf2, and Leaf3 have the same IP address, this DNS response message may be sent to any of the member devices, such as Leaf1, Leaf2, or Leaf3.

[0091] Each member device of the distributed gateway can support the DNS Snooping function. For example, Leaf1, Leaf2 and Leaf3 all support the DNS Snooping function.

[0092] For each member device, which can be a distributed device, such as Leaf1, which includes a main control board and multiple interface boards; Leaf2, which includes a main control board and multiple interface boards; and Leaf3, which includes a main control board and multiple interface boards.

[0093] In one example, Leaf1's interface board 1 receives a DNS request message from Client 1 (the DNS client). Interface board 1 forwards the DNS request message to Leaf1's main control board. The main control board receives the DNS request message and creates a temporary table entry based on it. The temporary table entry includes the domain name from the DNS request message. Interface board 1 then sends the DNS request message to the DNS Server via Spine.

[0094] The DNS server sends a DNS response message to the distributed gateway. Since the distributed gateway includes Leaf1, Leaf2, and Leaf3, and Leaf1, Leaf2, and Leaf3 have the same IP address, this DNS response message may be sent to any of the member devices, such as Leaf3.

[0095] The Leaf3's interface board x receives the DNS response message returned by the DNS server and forwards it to the Leaf3's main control board. The main control board receives the DNS response message, but since it cannot find a temporary entry based on the domain name in the DNS response message, it broadcasts the DNS response message to other member devices.

[0096] The Leaf2 interface board y receives the DNS response message and forwards it to the Leaf2 main control board. The main control board receives the DNS response message, but because it cannot find a temporary entry based on the domain name in the DNS response message, it discards the DNS response message.

[0097] The interface board n of Leaf1 receives the DNS response message and forwards it to the main control board of Leaf1. The main control board receives the DNS response message, finds a temporary entry based on the domain name in the message, and formalizes it (updates the temporary entry to a formal entry). The main control board then retrieves the IP address corresponding to the domain name from the DNS response message and adds this IP address to the formal entry.

[0098] DNS response messages can be sent to Client 1 from the Leaf3 interface board x or the Leaf1 interface board n, or from other interface boards; there are no restrictions on this.

[0099] In one example, Leaf1's interface board 1 receives a DNS request message from Client 1, creates a temporary table entry based on the DNS request message, and the temporary table entry includes the domain name from the DNS request message; that is, the key of the temporary table entry is the domain name. Interface board 1 then sends a DNS request message to the DNS Server.

[0100] The DNS server sends a DNS response message to the distributed gateway. This DNS response message may be sent to any member device of the distributed gateway, such as when the DNS response message is sent to Leaf3.

[0101] The Leaf3 interface board x receives the DNS response message returned by the DNS server. Since the interface board x cannot find the temporary table entry based on the domain name in the DNS response message, the interface board x broadcasts the DNS response message to all interface boards of Leaf3 and to other member devices.

[0102] For each Leaf3 interface board, after receiving a DNS response message, the interface board discards the DNS response message because it cannot find a temporary table entry based on the domain name in the DNS response message.

[0103] For Leaf2, interface board y receives DNS response messages. Since interface board y cannot find a temporary entry based on the domain name in the DNS response message, it broadcasts the DNS response message to all interface boards of Leaf2. Each interface board of Leaf2, upon receiving a DNS response message, discards it because it cannot find a temporary entry based on the domain name in the message.

[0104] For Leaf1, interface board n receives a DNS response message. Since interface board n cannot find a temporary entry based on the domain name in the DNS response message, it broadcasts the DNS response message to all interface boards on Leaf1. When the other interface boards besides interface board 1 receive the DNS response message, they cannot find a temporary entry based on the domain name in the DNS response message, and therefore discard the DNS response message.

[0105] When interface board 1 receives a DNS response message, it can find a temporary table entry based on the domain name in the DNS response message. Then, interface board 1 formalizes the temporary table entry, obtains the IP address corresponding to the domain name from the DNS response message, and adds the IP address corresponding to the domain name to the formal table entry.

[0106] DNS response messages can be sent to Client 1 from the Leaf3 interface board x or the Leaf1 interface board n, or from other interface boards; there are no restrictions on this.

[0107] 11. DNS message format.

[0108] For DNS request messages and DNS response messages, see Table 1 for the overall structure of DNS request messages and DNS response messages. DNS request messages and DNS response messages include the following fields.

[0109] Table 1

[0110] Fields Length (bytes) illustrate Header 12 The message header contains control information. Question variable The query question section (domain name + type) Answer variable Answer records in the response (only available in the Response) Authority variable Authoritative DNS server information (available only in the Response) Additional variable Additional information (such as EDNS, DNSSEC data)

[0111] For the Header field of DNS request and response messages, the Header field is fixed at 12 bytes, as shown in Table 2, which provides an example of a Header field. For the Flags (control flags) within the Header field, see Table 3, which provides an example of a Flags field.

[0112] Table 2

[0113] field name Number of digits illustrate Transaction ID 16 Random IDs are used to match requests and responses. Flags 16 Control flags QDCOUNT 16 The number of question sections (usually 1). ANCOUNT 16 Number of answer records (0 at the time of request) NSCOUNT 16 Number of authoritative records (0 at the time of request) ARCOUNT 16 Additional records (optional upon request)

[0114] Table 3

[0115]

[0116]

[0117] For the Question field in DNS request and response messages, the Question field is of variable length and can include the domain name, query type (QTYPE), and query class (QCLASS), as shown in Table 4, which is an example of a Question field.

[0118] Table 4

[0119] field name illustrate QNAME The domain name to be queried (see RFC1035 for the encoding format). QTYPE Query type (e.g., A=1, AAAA=28, MX=15) QCLASS Query type (usually IN=1, indicating Internet)

[0120] For DNS request and response messages, the Answer, Authority, and Additional fields are all variable-length. These three fields have the same structure and are used to store resource records (RRs). See Table 5 for an example of the Answer, Authority, and Additional fields.

[0121] Table 5

[0122]

[0123] In one example, for the Additional field in DNS request and response messages, it's possible to add OPT pseudo-records to the Additional field to extend DNS functionality. For instance, the OPT pseudo-record for DNS options is an extension mechanism of the DNS protocol used to pass additional information in DNS request and response messages. An OPT pseudo-record is not a true DNS resource record type, but rather a special pseudo-record appended to DNS request and response messages. For example, see Table 6 for an example of an OPT pseudo-record in the Additional field; there are no restrictions on this.

[0124] Table 6

[0125] Fields describe NAME Empty (encoded as 0x00) TYPE 41(OPT) UDP Payload Size 2 bytes, indicating the maximum UDP packet size supported by the sender (e.g., 4096). Extended RCODE High-order error code (Extended Standard RCODE) Version EDNS0 version (must be 0) Flags Extended flags (e.g., in DNSSEC requests) OPTIONS Custom Options (such as ECS client subnet, DNS Cookie)

[0126] In addition, for the OPTIONS field in the Additional field, the OPTIONS field can adopt the TLV (Type-Length-Value) structure, as shown in Table 7, which is an example of the OPTIONS field.

[0127] Table 7

[0128]

[0129] In the above application scenarios, this application proposes a DNS packet processing method. This method can be applied to distributed devices (such as routers, switches, etc.). The distributed device may include a main control board (such as at least one main control board) and multiple interface boards. See [link to relevant documentation]. Figure 3B The diagram shown is a schematic representation of the structure of a distributed device. (See also...) Figure 4A The diagram shown illustrates a DNS message processing method, which may include:

[0130] Step 401: The first interface board receives a first DNS request message sent by the DNS client. The first DNS request message includes the domain name to be requested, and the domain name to be requested is stored in the DNS listener table entry.

[0131] In one example, when a distributed device receives a first DNS request message through an interface board (such as interface board 1), this interface board 1 is referred to as the first interface board, and the domain name in the first DNS request message is referred to as the domain name to be requested. The first DNS request message is used to obtain the IP address corresponding to the domain name to be requested.

[0132] In one example, if the distributed device enables the DNS snooping function, the first interface board can obtain the domain name to be requested from the first DNS request message. If the domain name to be requested is consistent with the subscribed domain name of other modules (such as the address object group module), the first interface board can establish a DNS snooping entry based on the domain name to be requested. The DNS snooping entry can be a temporary entry, and the DNS snooping entry can include the domain name to be requested in the first DNS request message, that is, the key of the DNS snooping entry is the domain name to be requested.

[0133] In one example, after the first interface board stores the requested domain name in the DNS listener table, it can also set an aging timer for the DNS listener table entry. Before the aging timer expires, if the IP address corresponding to the requested domain name is obtained (see subsequent embodiments for the acquisition process), the aging timer can be deleted, and the DNS listener table entry can be retained. When the aging timer expires, if the IP address corresponding to the requested domain name is not obtained, the DNS listener table entry can be deleted. Obviously, the DNS listener table entry will be deleted due to aging; therefore, this DNS listener table entry is referred to as a temporary entry.

[0134] Step 402: The first interface board adds access information to the first DNS request message to obtain a second DNS request message, and sends the second DNS request message to the DNS server. The access information may include, but is not limited to, the target slot identifier and the specified type identifier of the first interface board. The specified type identifier is used to instruct the DNS server to migrate the access information in the second DNS request message to the first DNS response message, that is, the access information in the first DNS response message is the same as the access information in the second DNS request message.

[0135] In one example, as shown in Table 1, the first DNS request message includes a Header field, a Question field, and an Additional field. Access information can be added to the Header field, the Question field, or the Additional field, as long as access information can be added to the first DNS request message. In this embodiment, adding access information to the Additional field is taken as an example.

[0136] For the Additional field of the first DNS request message, OPT pseudo-records can be added to the Additional field to extend DNS functionality. See Table 6 for an example of an OPT pseudo-record in the Additional field; that is, the Additional field can include the OPTIONS field. Based on this, access information can be added to the OPTIONS field within the Additional field. Of course, access information can also be added to other fields within the Additional field, as long as access information can be added to the Additional field itself.

[0137] In summary, in this embodiment, if the first DNS request message includes an additional field (such as an Additional field), the first interface board can add access information to the custom option field (such as the OPTIONS field) of the additional field to obtain the second DNS request message. Alternatively, if the first DNS request message does not include an additional field, the first interface board first adds the additional field to the first DNS request message, and then adds access information to the custom option field of the additional field to obtain the second DNS request message.

[0138] In one example, the access information may include the target slot identifier of the first interface board, i.e., the slot number of the first interface board. Based on the target slot identifier, other interface boards of the distributed device can find the first interface board corresponding to the target slot identifier and then send the first DNS response message to the first interface board.

[0139] Access information may include a specified type identifier, which can be configured according to actual needs, such as 65002. The specified type identifier is an unused identifier among the existing identifiers in the custom option field, and it only needs to be distinguishable from the existing identifiers in the custom option field. The specified type identifier is used to indicate that the custom option field currently carries a target slot identifier. Thus, the specified type identifier is used to instruct the DNS server to migrate the access information in the second DNS request message to the first DNS response message.

[0140] For example, the custom option fields in the additional fields may include an option code field (OPTION-CODE) and an option data field (OPTION-DATA). The option code field carries a specified type identifier that instructs the DNS server to migrate the custom option fields from the second DNS request message to the first DNS response message. The option data field carries the target slot identifier of the first interface board.

[0141] For example, see Table 8, which shows an example of the custom option field (OPTIONS field) in the Additional field. The content of the custom option field is the access information. The custom option field can carry the specified type identifier and the target slot identifier of the first interface board.

[0142] Table 8

[0143] Fields byte count value OPTION-CODE 2 65002 OPTION-LENGTH 2 1 OPTION-DATA 1 Target slot marking on the first interface board

[0144] In one example, after the first interface board receives the second DNS request message, it can send the second DNS request message to the DNS server, and the second DNS request message carries access information.

[0145] Step 403: The DNS server receives the second DNS request message and returns a first DNS response message to the distributed device in response to the second DNS request message. The first DNS response message includes the access information.

[0146] In one example, after receiving a second DNS request message, the DNS server can resolve the requested domain name from the second DNS request message and query the IP address corresponding to the requested domain name. This IP address is the IP address of the application server for the requested domain name, which is used to provide services to the requested domain name. Thus, the first DNS response message can include the IP address corresponding to the requested domain name.

[0147] In one example, after receiving a second DNS request message, if the second DNS request message carries access information, the DNS server can obtain that access information and add it to the first DNS response message. For instance, if the access information includes a specified type identifier, and that specified type identifier is used to instruct the DNS server to migrate the access information from the second DNS request message to the first DNS response message, then the DNS server can add the access information to the first DNS response message.

[0148] As shown in Table 1, the first DNS response message includes a Header field, a Question field, an Answer field, an Authority field, and an Additional field. Access information can be added to the Header field, the Question field, the Answer field, the Authority field, or the Additional field. Any method that allows access information to be added to the first DNS response message is acceptable. For example, adding access information to the Additional field is used.

[0149] In one example, if the second DNS request message includes an Additional field, and the OPTION-CODE in the OPTIONs field (custom option field) of the Additional field is a specified type identifier (such as 65002), then the specified type identifier is used to instruct the DNS server to migrate the custom option field in the second DNS request message to the first DNS response message. Therefore, the DNS server migrates the custom option field in the second DNS request message to the first DNS response message. Thus, the first DNS response message includes an Additional field, and the custom option field in the Additional field of the first DNS response message is consistent with the custom option field in the Additional field of the second DNS request message.

[0150] For example, if the first DNS response message includes an additional field (such as the Additional field), the DNS server can move the custom option field from the second DNS request message to that additional field, meaning the access information is carried in the custom option field of the additional field. Alternatively, if the first DNS response message does not include an additional field, the DNS server adds the additional field to the first DNS response message, and then can move the custom option field from the second DNS request message to that additional field.

[0151] Step 404: The second interface board receives a first DNS response message returned by the DNS server in response to the second DNS request message. The first DNS response message may include the access information. For example, the access information may include the target slot identifier and the specified type identifier of the first interface board.

[0152] In one example, when a distributed device receives the first DNS response message returned by the DNS server through a certain interface board (such as interface board n), this interface board n is referred to as the second interface board.

[0153] In one example, if the first DNS response message does not carry the access information, the second interface board can broadcast the first DNS response message to all interface boards, or the second interface board can send the first DNS response message to the main control board. This embodiment does not restrict this process. For instance, if the first DNS response message does not carry the Additional field, or if the first DNS response message carries the Additional field but the OPTION-CODE of the custom option field of the Additional field is not a specified type identifier (such as 65002), then the second interface board determines that the first DNS response message does not carry the access information.

[0154] Step 405: The second interface board compares the target slot identifier in the access information with the slot identifier of the second interface board. If the target slot identifier is different from the slot identifier of the second interface board, the second interface board sends the first DNS response message to the first interface board based on the target slot identifier.

[0155] In one example, since the target slot identifier is the slot identifier (such as the slot number) of the first interface board, the target slot identifier is different from the slot identifier of the second interface board. Because the target slot identifier is the slot identifier of the first interface board, the second interface board knows that the target slot identifier corresponds to the first interface board, and the second interface board can send the first DNS response message to the first interface board.

[0156] Step 406: The first interface board receives the first DNS response message sent by the second interface board, compares the target slot identifier in the access information of the first DNS response message with the slot identifier of the first interface board. If the target slot identifier is the same as the slot identifier of the first interface board, the IP address corresponding to the requested domain name is obtained from the first DNS response message and the IP address is stored in the DNS listening table.

[0157] In one example, since the target slot identifier is the slot identifier of the first interface board, the target slot identifier is the same as the slot identifier of this first interface board. Based on this, the first interface board can obtain the IP address corresponding to the requested domain name from the first DNS response message, that is, the IP address of the application server corresponding to the requested domain name. The application server corresponding to this IP address can provide services for the requested domain name.

[0158] The first interface board can obtain the domain name to be requested from the first DNS response message and query the DNS listener table entry corresponding to the domain name to be requested. In this way, the IP address corresponding to the domain name to be requested can be stored in the DNS listener table entry, that is, the domain name to be requested and the IP address are stored in the DNS listener table entry.

[0159] For example, when querying the DNS listener entry corresponding to the requested domain name, this DNS listener entry is a temporary entry, meaning it corresponds to an aging timer and may be deleted. Based on this, the first interface board can also formalize this temporary entry, that is, update the temporary entry into a formal entry. In this way, the DNS listener entry becomes a formal entry, and the IP address is added to the DNS listener entry.

[0160] In one example, after the first interface board stores the IP address corresponding to the requested domain name in the DNS listener table, the first interface board can also delete the aging timer corresponding to the DNS listener table entry. In this way, the DNS listener table entry will not be deleted due to aging, that is, the DNS listener table entry is a formal entry.

[0161] In one example, after obtaining the DNS listener entry, which includes the requested domain name and IP address, the first interface board can generate a security policy based on this entry, and this security policy can include the IP address. For instance, if the requested domain name matches the subscribed domain name, the IP address can be reported to the module that initiated the subscription (such as the address object group module), which will then generate a security policy that also includes the IP address. Based on this, domain name-based traffic filtering can be implemented using the IP address; that is, the security policy is used to control access packets. For example, when a distributed device receives an access packet, if the security policy includes the destination IP address of the access packet, it will forward the access packet to the application server corresponding to the destination IP address; if the security policy does not include the destination IP address of the access packet, it will intercept the access packet, without restricting this access control process.

[0162] Step 407: The first interface board removes the access information from the first DNS response message to obtain the second DNS response message, and sends the second DNS response message to the DNS client.

[0163] For example, the first interface board removes the custom option field from the Additional field of the first DNS response message, thereby removing the access information from the first DNS response message. The DNS response message after removing the access information is called the second DNS response message, and then it is sent to the DNS client. This completes the DNS response message transmission process, and the DNS client successfully obtains the IP address corresponding to the requested domain name, and then accesses the application server corresponding to the requested domain name through that IP address.

[0164] This application proposes a DNS message processing method applied to a distributed device, which includes multiple interface boards. (See also...) Figure 4B The diagram shown is a flowchart of the method, which may include:

[0165] Step 411: The first interface board receives a first DNS request message sent by the DNS client. The first DNS request message includes the domain name to be requested and stores the domain name to be requested in the DNS listener table entry.

[0166] Step 412: The first interface board adds access information to the first DNS request message to obtain a second DNS request message, and sends the second DNS request message to the DNS server. The access information may include, but is not limited to, the target slot identifier and the specified type identifier of the first interface board.

[0167] Step 413: The DNS server receives the second DNS request message and returns a first DNS response message to the distributed device in response to the second DNS request message. The first DNS response message includes the access information.

[0168] Step 414: The first interface board receives a first DNS response message returned by the DNS server in response to the second DNS request message. The first DNS response message may include the access information. For example, the access information may include the target slot identifier and the specified type identifier of the first interface board.

[0169] Step 415: The first interface board compares the target slot identifier with the slot identifier of the first interface board. If the target slot identifier is the same as the slot identifier of the first interface board, the IP address corresponding to the requested domain name is obtained from the first DNS response message and the IP address is stored in the DNS listener table.

[0170] Step 416: The first interface board removes the access information from the first DNS response message to obtain the second DNS response message, and sends the second DNS response message to the DNS client.

[0171] Steps 411-416 are similar to steps 401-407, and will not be repeated here.

[0172] This application proposes a DNS packet processing method, which can be applied to a distributed gateway. The distributed gateway may include multiple member devices with the same IP address, each member device being a distributed device (such as a router, switch, etc.), and the distributed device may include a main control board (such as at least one main control board) and multiple interface boards. See also... Figure 3C The diagram shows the structure of a distributed gateway. Leaf1, Leaf2, and Leaf3 can be member devices of the distributed gateway, and they all have the same IP address. Leaf1, Leaf2, and Leaf3 are all distributed devices. When the DNS server sends a DNS response message to the distributed gateway, the DNS response message may be sent to any of the member devices. In the above application scenario, see [reference needed]. Figure 5 The diagram shown illustrates a DNS message processing method, which may include:

[0173] Step 501: The first interface board receives a first DNS request message sent by the DNS client. The first DNS request message includes the domain name to be requested, and the domain name to be requested is stored in the DNS listener table entry.

[0174] For example, when the first member device of the distributed gateway (i.e., the distributed device, such as Leaf1) receives the first DNS request message through an interface board (such as interface board 1), this interface board 1 is referred to as the first interface board. The first interface board can establish a DNS listener entry based on the domain name to be requested. This DNS listener entry is a temporary entry, and the DNS listener entry includes the domain name to be requested in the first DNS request message.

[0175] After storing the requested domain name in the DNS listener table, the first interface board can also set an aging timer for the DNS listener table entry. If the IP address corresponding to the requested domain name is obtained before the aging timer expires, the aging timer is deleted, and the DNS listener table entry is retained. If the IP address corresponding to the requested domain name is not obtained when the aging timer expires, the DNS listener table entry is deleted.

[0176] Step 502: The first interface board adds access information to the first DNS request message to obtain a second DNS request message, and sends the second DNS request message to the DNS server. The access information includes, but is not limited to, the target slot identifier of the first interface board, the target route identifier (Router ID) of the first member device (i.e., the member device where the first interface board is located), and a specified type identifier. The specified type identifier is used to instruct the DNS server to migrate the access information in the second DNS request message to the first DNS response message; that is, the access information in the first DNS response message is the same as the access information in the second DNS request message.

[0177] In one example, access information can be added to the OPTIONS field within the Additional field, or to other fields; there are no restrictions on this. For instance, if the first DNS request message includes an additional field (such as the Additional field), access information can be added to the custom options field (such as the OPTIONS field) of the additional field to obtain the second DNS request message. Alternatively, if the first DNS request message does not include an additional field, an additional field can be added to the first DNS request message, and access information can be added to the custom options field of the additional field to obtain the second DNS request message.

[0178] In one example, the additional fields may include a first custom option field, which may include, but is not limited to, a first option code field (OPTION-CODE), a first option data field (OPTION-DATA1), and a second option data field (OPTION-DATA2). The first option code field carries a specified type identifier, the first option data field carries a target slot identifier for the first interface board, and the second option data field carries a target route identifier for the first member device. For instance, see Table 9, which shows an example of the first custom option field (OPTIONs field) in the additional fields. The content of the first custom option field is the access information, carrying a specified type identifier, a target slot identifier for the first interface board, and a target route identifier for the first member device.

[0179] Table 9

[0180]

[0181]

[0182] In one example, the additional fields may include a first custom option field and a second custom option field. The first custom option field includes a first option code field (OPTION-CODE) and a first option data field (OPTION-DATA). The first option code field carries a specified type identifier 1 (used to instruct the DNS server to migrate custom option field 1 to the first DNS response message), and the first option data field carries the target slot identifier of the first interface board. See Table 8 for an example of a first custom option field; the first custom option field carries specified type identifier 1 and the target slot identifier of the first interface board. The second custom option field includes, but is not limited to, a second option code field and a second option data field. The second option code field carries a specified type identifier 2 (used to instruct the DNS server to migrate the second custom option field to the first DNS response message), and the second option data field carries the target route identifier of the first member device. See Table 10 for an example of a second custom option field; the second custom option field may carry specified type identifier 2 and the target route identifier of the first member device. The contents of the first and second custom option fields constitute the access information.

[0183] Table 10

[0184] Fields byte count value OPTION-CODE 2 65001 OPTION-LENGTH 2 2 OPTION-DATA 2 Target route identifier of the first member device

[0185] In one example, after the first interface board receives the second DNS request message, it can send the second DNS request message to the DNS server, and the second DNS request message carries the access information.

[0186] Step 503: The DNS server receives the second DNS request message and returns a first DNS response message to the distributed gateway in response to the second DNS request message. The first DNS response message includes the access information.

[0187] In one example, if the second DNS request message carries access information, the DNS server adds that access information to the first DNS response message. For instance, if the access information includes a specified type identifier that instructs the DNS server to migrate the access information from the second DNS request message to the first DNS response message, the DNS server can add that access information to the first DNS response message. For example, the DNS server can add the access information shown in Table 9 to the first DNS response message, or it can add the access information shown in Tables 8 and 10 to the first DNS response message.

[0188] In one example, when the DNS server returns a first DNS response message to the distributed gateway, the first DNS response message may be returned to the first member device (such as Leaf1) or to the second member device (any member device other than the first member device, such as Leaf2 or Leaf3). If the first DNS response message is returned to the second interface board of the first member device, the processing flow is as follows: Figure 4A As shown, if the response is returned to the first interface board of the first member device, the processing flow is as follows: Figure 4B As shown. In this embodiment, the example is to return the first DNS response message to the second member device.

[0189] Step 504: Any interface board of the second member device receives a first DNS response message, which may include the access information. For example, the access information may include the target slot identifier of the first interface board, the target route identifier of the first member device, and the specified type identifier.

[0190] Step 505: The interface board of the second member device compares the target route identifier in the access information with the route identifier of the second member device. If the target route identifier is different from the route identifier of the second member device, the first DNS response message is sent to the first member device based on the target route identifier.

[0191] In one example, since the target route identifier is the route identifier of the first member device, it is different from the route identifier of the second member device. Because the target route identifier is a unique identifier for the first member device, the second member device knows that the target route identifier corresponds to the first member device, and its interface board can send the first DNS response message to the first member device.

[0192] When the second member device sends a first DNS response message to the first member device, the first DNS response message may be sent to the second interface board of the first member device. See the processing flow below. Figure 4A As shown, the first DNS response message may be sent to the first interface board of the first member device. See the processing flow for details. Figure 4B As shown. In this embodiment, the example is the second interface board that sends the first DNS response message to the first member device.

[0193] Step 506: The second interface board of the first member device receives a first DNS response message. The first DNS response message may include the access information. It compares whether the target route identifier in the access information is the same as the route identifier of the first member device. If the target route identifier is the same as the route identifier of the first member device, the second interface board compares whether the target slot identifier in the access information is the same as the slot identifier of the second interface board. If the target slot identifier is different from the slot identifier of the second interface board, the second interface board sends the first DNS response message to the first interface board based on the target slot identifier.

[0194] Step 507: The first interface board receives the first DNS response message sent by the second interface board, compares the target slot identifier in the access information of the first DNS response message with the slot identifier of the first interface board. If the target slot identifier is the same as the slot identifier of the first interface board, the IP address corresponding to the requested domain name is obtained from the first DNS response message and the IP address is stored in the DNS listening table.

[0195] Step 508: The first interface board removes the access information from the first DNS response message to obtain the second DNS response message, and sends the second DNS response message to the DNS client.

[0196] As can be seen from the above technical solutions, in this embodiment, the processing of DNS response messages (or DNS request messages) does not need to go through the main control board, and there is no need to transmit a large number of DNS response messages between the interface board and the main control board, thereby saving bandwidth between the interface board and the main control board, and the processing performance of DNS response messages is high. It can save the processing and storage resources of the main control board and improve its processing performance. It can support DNS Snooping in distributed devices and distributed gateways, and has high security and good performance.

[0197] For example, distributed devices support DNS Snooping, offering high security: DNS request messages are processed first, followed by DNS response messages before DNS Snooping entries are generated. Performance is also good: distributed processing of both DNS response and request messages doesn't require bypassing the main control board. The first interface board receiving a DNS request message directly generates a temporary entry and forwards it. The second interface board receiving a DNS response message accurately locates the first interface board and forwards it. The first interface board then formalizes the temporary entry and forwards the DNS response message to the DNS client. Each interface board maintains its own DNS Snooping entries (DNS snooping entries) and is responsible for external notifications.

[0198] For example, the distributed gateway supports DNS Snooping, offering high security: DNS request messages are processed first, followed by DNS response messages before DNS Snooping entries are generated. It also boasts good performance: the distributed processing of forwarding DNS response or DNS request messages doesn't necessarily bypass the main control board. The first interface board (located in the first member device) directly generates a temporary entry and forwards the DNS request message. The second member device, upon receiving a DNS response message, forwards it to the first member device. The second interface board of the first member device accurately locates the first interface board and forwards the DNS response message there. The first interface board formalizes the temporary entry and forwards the DNS response message to the DNS client. Each interface board maintains its own DNS Snooping entries (DNS snooping entries) and is responsible for external notifications.

[0199] Based on the same concept as the above method, this application proposes a DNS message processing device applied to a first interface board. The first interface board is located within a distributed device, which also includes a second interface board. See [link to relevant documentation]. Figure 6 The diagram shown is a structural schematic of the device, which includes:

[0200] The first receiving module 61 is configured to receive a first DNS request message sent by a DNS client, wherein the first DNS request message includes the domain name to be requested.

[0201] The first storage module 62 is used to store the domain name to be requested in a DNS listening table entry;

[0202] The first sending module 63 is used to send a second DNS request message to the DNS server, the second DNS request message including the target slot identifier of the first interface board;

[0203] The second storage module 64 is configured to, when receiving a first DNS response message sent by the second interface board and the target slot identifier included in the first DNS response message is the same as the slot identifier of the first interface board, store the IP address corresponding to the domain name to be requested included in the first DNS response message in the DNS listening table entry.

[0204] The second sending module 65 is used to send a second DNS response message to the DNS client, wherein the second DNS response message includes the IP address but does not include the target slot identifier;

[0205] The first DNS response message is sent by the DNS server to the second interface board, and the second interface board forwards it to the first interface board after determining that the target slot identifier is different from the slot identifier of the second interface board.

[0206] In one example, the first storage module 62 is further configured to store the domain name to be requested in the DNS listener table entry, and then set an aging timer for the DNS listener table entry. If the IP address corresponding to the domain name to be requested is not obtained when the aging timer expires, the DNS listener table entry is deleted.

[0207] The second storage module 64 is further configured to delete the aging timer corresponding to the DNS listening table entry after storing the IP address corresponding to the requested domain name included in the first DNS response message in the DNS listening table entry;

[0208] The DNS snooping entry is used to generate a security policy, which includes the IP address and is used to control access packets.

[0209] Specifically, upon receiving an access message, if the IP address in the security policy includes the destination IP address of the access message, the access message is forwarded to the application server corresponding to the destination IP address; if the IP address in the security policy does not include the destination IP address of the access message, the access message is intercepted.

[0210] The device further includes (in) Figure 6 (Not shown in the image): Processing module, configured to add the target slot identifier and specified type identifier of the first interface board to the first custom option field of the additional field if the first DNS request message includes an additional field, to obtain a second DNS request message; wherein, the first custom option field includes a first option code field and a first option data field, the first option code field is used to carry the specified type identifier, and the first option data field is used to carry the target slot identifier of the first interface board.

[0211] Alternatively; if the first DNS request message does not include additional fields, then add additional fields to the first DNS request message, and add the target slot identifier and specified type identifier of the first interface board to the first custom option field of the additional fields to obtain the second DNS request message;

[0212] The specified type identifier is used to instruct the DNS server to migrate the first custom option field in the second DNS request message to the first DNS response message.

[0213] In one example, the distributed gateway includes multiple member devices with the same IP address, and the distributed device is the first member device among the multiple member devices; the second DNS request message also includes the target route identifier of the first member device;

[0214] When the second interface board receives the first DNS response message returned by the DNS server,

[0215] The first DNS response message is sent by the DNS server to the first member device; or, the first DNS response message is sent by the DNS server to the second member device, and then sent by the second member device to the first member device based on the target route identifier.

[0216] In one example, the additional fields of the second DNS request message include a second custom option field, which includes a second option code field and a second option data field. The second option code field is used to carry a specified type identifier, and the second option data field is used to carry the target route identifier of the first member device.

[0217] The specified type identifier is used to instruct the DNS server to migrate the second custom option field in the second DNS request message to the first DNS response message.

[0218] Based on the same application concept as the above method, this application proposes a distributed device, see [link to relevant documentation]. Figure 7 As shown, the distributed device includes a processor 71 and a machine-readable storage medium 72, the machine-readable storage medium 72 storing machine-executable instructions that can be executed by the processor 71; the processor 71 is used to execute the machine-executable instructions to implement the DNS message processing method disclosed in the above example of this application.

[0219] Based on the same concept as the above method, this application also provides a machine-readable storage medium storing a plurality of computer instructions, which, when executed by a processor, can implement the DNS message processing method disclosed in the above examples of this application.

[0220] The aforementioned machine-readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, machine-readable storage media can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0221] Based on the same concept as the methods described above, this application also provides a computer program product, which may include a computer program. When executed by a processor, the computer program implements the DNS message processing method disclosed in the examples above.

[0222] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0223] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for processing Domain Name System (DNS) messages, characterized in that, The method is applied to a first interface board, which is located within a distributed device. The distributed device further includes a second interface board. The method includes: Receive a first DNS request message sent by a DNS client, wherein the first DNS request message includes the domain name to be requested; Store the requested domain name in the DNS listener table entry; Send a second DNS request message to the DNS server, the second DNS request message including the target slot identifier of the first interface board; When a first DNS response message is received from the second interface board and the target slot identifier included in the first DNS response message is the same as the slot identifier of the first interface board, the IP address corresponding to the domain name to be requested included in the first DNS response message is stored in the DNS listening table entry. Send a second DNS response message to the DNS client, the second DNS response message including the IP address but excluding the target slot identifier; The first DNS response message is sent by the DNS server to the second interface board, and the second interface board forwards it to the first interface board after determining that the target slot identifier is different from the slot identifier of the second interface board.

2. The method according to claim 1, characterized in that, After storing the domain name to be requested in the DNS listener table entry, the method further includes: An aging timer is set for the DNS listener entry. If the IP address corresponding to the domain name to be requested is not obtained when the aging timer expires, the DNS listener entry is deleted. After storing the IP address corresponding to the requested domain name included in the first DNS response message in the DNS listener table entry, the method further includes: Delete the aging timer corresponding to the DNS listener entry; The DNS snooping entry is used to generate a security policy, which includes the IP address and is used to control access packets. Specifically, upon receiving an access message, if the IP address in the security policy includes the destination IP address of the access message, the access message is forwarded to the application server corresponding to the destination IP address; if the IP address in the security policy does not include the destination IP address of the access message, the access message is intercepted.

3. The method according to claim 1, characterized in that, Before sending the second DNS request message to the DNS server, the method further includes: If the first DNS request message includes additional fields, then add the target slot identifier and specified type identifier of the first interface board to the first custom option field of the additional fields to obtain the second DNS request message; The first custom option field includes a first option code field and a first option data field. The first option code field is used to carry the specified type identifier, and the first option data field is used to carry the target slot identifier of the first interface board. or; If the first DNS request message does not include an additional field, then an additional field is added to the first DNS request message. The target slot identifier and the specified type identifier of the first interface board are added to the first custom option field of the additional field to obtain the second DNS request message. The specified type identifier is used to instruct the DNS server to migrate the first custom option field in the second DNS request message to the first DNS response message.

4. The method according to claim 1, characterized in that, After sending the second DNS request message to the DNS server, the method further includes: When a first DNS response message is received from the DNS server and the target slot identifier included in the first DNS response message is the same as the slot identifier of the first interface board, the IP address corresponding to the requested domain name included in the first DNS response message is stored in the DNS listening table entry, and a second DNS response message is sent to the DNS client.

5. The method according to any one of claims 1-4, characterized in that, The distributed gateway includes multiple member devices with the same IP address, and the distributed device is the first member device among the multiple member devices; the second DNS request message also includes the target route identifier of the first member device; When the second interface board receives the first DNS response message returned by the DNS server, The first DNS response message is sent by the DNS server to the first member device; or, the first DNS response message is sent by the DNS server to the second member device, and then sent by the second member device to the first member device based on the target route identifier.

6. The method according to claim 5, characterized in that, The additional fields in the second DNS request message include a second custom option field, which includes a second option code field and a second option data field. The second option code field is used to carry a specified type identifier, and the second option data field is used to carry the target route identifier of the first member device. The specified type identifier is used to instruct the DNS server to migrate the second custom option field in the second DNS request message to the first DNS response message.

7. A Domain Name System (DNS) message processing apparatus, characterized in that, The device is applied to a first interface board, which is located within a distributed device. The distributed device further includes a second interface board. The device comprises: The first receiving module is configured to receive a first DNS request message sent by a DNS client, wherein the first DNS request message includes the domain name to be requested. The first storage module is used to store the requested domain name in a DNS listening table entry; The first sending module is used to send a second DNS request message to the DNS server, the second DNS request message including the target slot identifier of the first interface board; The second storage module is configured to, when receiving a first DNS response message sent by the second interface board and the target slot identifier included in the first DNS response message is the same as the slot identifier of the first interface board, store the IP address corresponding to the requested domain name included in the first DNS response message in the DNS listening table entry. The second sending module is used to send a second DNS response message to the DNS client, wherein the second DNS response message includes the IP address but does not include the target slot identifier; The first DNS response message is sent by the DNS server to the second interface board, and the second interface board forwards it to the first interface board after determining that the target slot identifier is different from the slot identifier of the second interface board.

8. The apparatus according to claim 7, characterized in that, The first storage module is further configured to store the domain name to be requested in the DNS listening table entry, and then set an aging timer for the DNS listening table entry. If the IP address corresponding to the domain name to be requested is not obtained when the aging timer expires, the DNS listening table entry is deleted. The second storage module is further configured to, after storing the IP address corresponding to the requested domain name included in the first DNS response message in the DNS listener table entry, delete the aging timer corresponding to the DNS listener table entry; The DNS snooping entry is used to generate a security policy, which includes the IP address and is used to control access packets. Specifically, upon receiving an access message, if the IP address in the security policy includes the destination IP address of the access message, the access message is forwarded to the application server corresponding to the destination IP address; if the IP address in the security policy does not include the destination IP address of the access message, the access message is intercepted.

9. The apparatus according to claim 7, characterized in that, Also includes: The processing module is configured to, if the first DNS request message includes an additional field, add the target slot identifier and the specified type identifier of the first interface board to the first custom option field of the additional field to obtain a second DNS request message; wherein, the first custom option field includes a first option code field and a first option data field, the first option code field is used to carry the specified type identifier, and the first option data field is used to carry the target slot identifier of the first interface board. Alternatively; if the first DNS request message does not include additional fields, then add additional fields to the first DNS request message, and add the target slot identifier and specified type identifier of the first interface board to the first custom option field of the additional fields to obtain the second DNS request message; The specified type identifier is used to instruct the DNS server to migrate the first custom option field in the second DNS request message to the first DNS response message.

10. The apparatus according to any one of claims 7-9, characterized in that, The distributed gateway includes multiple member devices with the same IP address, and the distributed device is the first member device among the multiple member devices; the second DNS request message also includes the target route identifier of the first member device; When the second interface board receives the first DNS response message returned by the DNS server, The first DNS response message is sent by the DNS server to the first member device; or, the first DNS response message is sent by the DNS server to the second member device, and then sent by the second member device to the first member device based on the target route identifier.

11. The apparatus according to claim 10, characterized in that, The additional fields of the second DNS request message include a second custom option field, which includes a second option code field and a second option data field. The second option code field is used to carry a specified type identifier, and the second option data field is used to carry the target route identifier of the first member device. The specified type identifier is used to instruct the DNS server to migrate the second custom option field in the second DNS request message to the first DNS response message.

12. A distributed device, characterized in that, include: A processor and a machine-readable storage medium storing machine-executable instructions that can be executed by the processor; wherein the processor is configured to execute the machine-executable instructions to implement the method of any one of claims 1-6.

Images