DNS TFO query message protection methods, devices and related equipment

Abstract

This application discloses a method, apparatus, and related equipment for protecting DNS TFO query messages, relating to the field of network security technology. A domain name resolution device receives a TFO query message carrying a target token and DNS query data, and sequentially checks whether the target token is included in the valid token record and the revoked token record. If the valid token record includes the target token and the revoked token record does not, the TFO query message is allowed to pass through the kernel protocol stack of the domain name server. If the target token is not registered or has been revoked, the domain name resolution device discards the TFO query message. This method can identify DNS TFO query messages carrying invalid or revoked tokens before they enter the kernel protocol stack, thereby reducing the resource consumption of the kernel protocol stack and DNS services caused by forged or replayed TFO query messages.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a method, apparatus and related equipment for protecting DNS TFO query messages. Background Technology

[0002] With the development of internet services, terminal devices typically use domain names as access identifiers to access website servers, application servers, or other network service devices. The Domain Name System (DNS) is used to resolve domain names into corresponding network addresses, enabling terminal devices to establish network connections with target service devices based on these network addresses. DNS queries can be transmitted based on the Transmission Control Protocol (TCP). TCP Fast Open (TFO) allows terminal devices to carry DNS query data in the Initial Synchronize Sequence Numbers (SYN) message, ensuring that the DNS query data reaches the domain name server during the connection establishment phase.

[0003] Existing DNS TFO query message protection methods typically rely on the kernel protocol stack within the domain name resolution device. The kernel protocol stack refers to the network protocol processing component running within the operating system kernel of the domain name resolution device. It is used to parse received messages according to the Transmission Control Protocol (TCP), verify sequence numbers, maintain connection states, and deliver data. After receiving a DNS TFO query message, the kernel protocol stack can perform sequence number verification, connection state tracking, and TFO Cookie verification (data stored on the user's local terminal). The TFO Cookie is a connection credential used in the TFO mechanism to verify whether the sender has the conditions to send TFO data. After the DNS TFO query message is processed by the kernel protocol stack, the domain name server then parses the DNS query data carried in the message.

[0004] However, in DNS TFO query scenarios, terminal devices can include DNS query data in the initial SYN packet, allowing the DNS query data to arrive at the domain name server along with the initial SYN packet. The terminal device can send the DNS query data without waiting for the TCP connection to be established, thus achieving zero round-trip time (0-RTT) transmission of the DNS query data. After obtaining a packet carrying a legitimate TFO cookie and DNS query data, an attacker may repeatedly send the same packet within a short period. This causes a large number of duplicate packets to consume the connection processing resources and DNS query processing resources of the domain name resolution device, increasing the processing load on the domain name resolution device and affecting the processing capacity of normal DNS queries. Therefore, there is an urgent need for a DNS TFO query packet protection method to reduce the excessive processing resources consumed by repeatedly sent DNS TFO query packets on the domain name resolution device. Summary of the Invention

[0005] A method, apparatus, and related equipment for protecting DNS TFO query messages are provided to reduce the resource consumption of the kernel protocol stack and DNS service in the domain name resolution device by forged or replayed TFO query messages.

[0006] In a first aspect, embodiments of this application provide a DNS TFO query message protection method, which is applied to a domain name resolution device. The domain name resolution device receives a first message before the message enters the kernel protocol stack. The first message is a TFO query message carrying a target token and DNS query data. The domain name resolution device obtains the target token from the first message and queries the valid token record used to store registered tokens. If the target token exists in the valid token record, the domain name resolution device continues to query the target token in the redeemed token record used to store used tokens. If the target token is registered in the valid token record but has not yet appeared in the redeemed token record, the domain name resolution device allows the first message to enter the kernel protocol stack of the domain name server, where the kernel protocol stack continues to process the first message. If the target token does not appear in the valid token record, or if the target token has already appeared in the redeemed token record, the domain name resolution device discards the first message.

[0007] In this embodiment, the domain name resolution device determines whether the first packet enters the kernel protocol stack based on the legitimacy of the target token's origin and its usage status. Valid token records distinguish between server-registered tokens and randomly forged tokens, while revoked token records distinguish between first-time-used tokens and repeatedly used tokens. Therefore, TFO query packets carrying forged tokens are difficult to determine using valid token records, and TFO query packets carrying used tokens are difficult to determine using revoked token records. Since forged or replayed TFO query packets can be discarded before entering the kernel protocol stack, the number of times the kernel protocol stack and DNS service program process duplicate packets can be reduced, thereby reducing the processing load of the domain name resolution device in high-volume replay scenarios.

[0008] In one possible implementation, the domain name resolution device can receive the first packet via the Express DataPath (XDP) and perform target token extraction, valid token record lookup, revoked token record lookup, packet allowance, and packet discarding through the XDP protection program. The XDP protection program can be deployed at the network interface card (NIC) driver layer or in the kernel network processing path. The XDP protection program only performs packet screening and security filtering actions; it does not construct TCP responses or take over the TCP connection state. The domain name resolution device can complete the screening for forged and duplicate tokens before the packet enters the kernel protocol stack, while maintaining the TCP connection state under the control of the kernel protocol stack. This reduces the number of attack packets entering the kernel protocol stack and lowers the possibility of processing conflicts between the pre-filtering process and TCP connection state management.

[0009] In one possible implementation, before the domain name resolution device allows the first message to enter the kernel protocol stack, the domain name resolution device writes the target token to the verified token record, and the writing process is an atomic operation. An atomic operation combines the verification registration of the target token and concurrency control in the same processing action. When multiple TFO query messages carrying the same target token arrive at similar times, the verified token record only allows one of the writing processes to succeed. This reduces the possibility of the same target token being verified by multiple messages simultaneously.

[0010] In one possible implementation, the domain name resolution device determines the processing method for the first message based on the result of writing the target token to the verified token record. If the target token is successfully written to the verified token record, the domain name resolution device allows the first message to pass through the kernel protocol stack. If the target token is not successfully written to the verified token record, the domain name resolution device discards the first message. The domain name resolution device performs the verification judgment of the target token through a single atomic write. When the target token can be written to the verified token record, the first message is determined to be a message using the token for the first time; if the target token already exists in the verified token record, the first message is determined to be a replay message. Therefore, the domain name resolution device can complete the replay judgment before the first message enters the kernel protocol stack, preventing duplicate TFO query messages carrying the same target token from continuing to occupy kernel protocol stack and DNS service resources.

[0011] In one possible implementation, after confirming that the target token carried in the first message belongs to a valid token record, the domain name resolution device can generate at least one incremental token. The domain name resolution device first registers the incremental token in the valid token record, and then sends the incremental token to the sender of the first message after successful registration. Since the incremental token has been registered before being sent to the sender, the valid token record can provide verification for subsequent TFO query messages initiated by the sender carrying the incremental token, enabling the domain name resolution device to determine whether the incremental token is a registered token based on the valid token record. Simultaneously, the incremental token can replenish the sender's available tokens, ensuring that the sender still has tokens available for subsequent TFO queries even after used tokens have been cancelled. Therefore, while maintaining a one-time token cancellation mechanism, continuous replenishment and rolling updates of available tokens can be achieved, reducing the likelihood of the sender reverting to a normal TCP connection due to token exhaustion.

[0012] In one possible implementation, the incremental token can be sent to the sender via an extended field in the DNS response. The sender can save the received incremental token and carry one of the incremental tokens in subsequent TFO query messages. The extended field and token saving method described above are merely examples and do not constitute a limitation on the scope of protection of this application. The incremental token can be returned with the DNS response, eliminating the need for a separate additional interaction process for token issuance. Therefore, subsequent available tokens can be supplemented while maintaining the DNS query response process, reducing the additional impact of token replenishment on the query chain.

[0013] In one possible implementation, the domain name resolution device performs token cleanup on valid token records and revoked token records. For a first token that has expired and is not yet in the revoked token record, the domain name resolution device deletes the first token from the valid token record. For a second token that has expired and is already in the revoked token record, the domain name resolution device deletes the second token from the revoked token record according to the least recently used (LRU) virtual page storage management service mechanism. The domain name resolution device can clean up unused expired tokens and used expired tokens separately. Since expired tokens do not occupy storage space in valid token records and revoked token records for a long time, token records can be kept continuously updated, reducing the possibility of record capacity being occupied by invalid data.

[0014] In one possible implementation, valid token records can be implemented using an extended Berkeley packet filter (eBPF) mapping of type HASH (hash mapping), and cancelled token records can be implemented using an LRU_HASH type eBPF mapping. Valid token records can use the token value as the query key and the token registration time as the record value. Cancelled token records can use the token value as the query key and the token cancellation time as the record value. The above record structures are merely examples; in practical applications, valid token records and cancelled token records can also use other data structures that support querying, writing, and deletion, and this application does not limit them. HASH type records facilitate fast existence queries for target tokens, while LRU_HASH type records facilitate the eviction of long-unused cancelled records when record space is limited. This improves the adaptability of the token verification and token cleanup process to high-concurrency message processing scenarios.

[0015] In one possible implementation, the domain name resolution device receives a second message. If the second message is a TFO query message and does not carry a token, the domain name resolution device discards the second message. The domain name resolution device can exclude tokenless TFO query messages before the valid token record check and the revoked token record check. Since tokenless TFO query messages do not continue to trigger kernel protocol stack processing and DNS service processing, the resource consumption caused by tokenless TFO query messages can be reduced.

[0016] Secondly, embodiments of this application provide a DNS TFO query message protection device, which is applied to a domain name resolution device. The device includes a receiving module, a first judgment module, a second judgment module, a allowing module, and a discarding module. The receiving module receives a first message before the message enters the kernel protocol stack. The first message is a TFO query message carrying a target token and DNS query data. Exemplarily, the receiving module can receive the first message via the Fast Data Path (XDP). The first judgment module queries the valid token record to determine whether the target token is a token registered with the domain name server and has passed validity verification. The valid token record records at least one token registered with the domain name server and that has passed validity verification. The second judgment module, if the target token belongs to a valid token record, queries the cancelled token record to determine whether the target token has already been used. The cancelled token record records tokens carried in TFO query messages already received by the domain name server that belong to valid token records. The allowing module allows the first message to pass through the kernel protocol stack of the domain name server if the target token belongs to a valid token record and does not appear in the cancelled token record. The kernel protocol stack is used to process the first message. The discard module is used to discard the first message if the target token does not appear in the valid token record, or if the target token already appears in the redeemed token record.

[0017] In one possible implementation, the device further includes a verification module. The verification module is used to write the target token to the verified token record based on atomic operations before the release module releases the first message to the kernel protocol stack.

[0018] In one possible implementation, the allow module is further configured to allow the first message to the kernel protocol stack of the domain name server if the target token is successfully written to the verified token record. The discard module is further configured to discard the first message if the target token is not successfully written to the verified token record.

[0019] In one possible implementation, the device further includes a token management module. The token management module is used to generate at least one incremental token after the first determination module confirms that the target token belongs to a valid token record, and to write the at least one incremental token into the valid token record. If at least one incremental token is written into the valid token record, the module sends at least one incremental token to the sender, and the first message originates from the sender.

[0020] In one possible implementation, the device further includes a cleanup module. The cleanup module is used to delete a first token from the valid token record if the first token in the valid token record becomes invalid, and the first token is not recorded in the cancelled token record; or, if a second token in the valid token record becomes invalid and the second token is recorded in the cancelled token record, to delete the second token from the cancelled token record according to a least recently used (LRU) mechanism.

[0021] In one possible implementation, the device further includes a tokenless interception module. The tokenless interception module discards a second message if it receives a second message that is a TFO query message and does not carry a token.

[0022] Thirdly, embodiments of this application provide a domain name resolution device. The domain name resolution device includes a processor and a memory. The processor is used to execute instructions stored in the memory to cause the domain name resolution device to perform the DNS TFO query message protection method of the first aspect and any possible implementation of the first aspect.

[0023] Fourthly, embodiments of this application provide a computer-readable storage medium. The computer-readable storage medium stores instructions. When the instructions are executed on a domain name resolution device, the domain name resolution device performs the DNS TFO query message protection method of the first aspect and any possible implementation thereof.

[0024] Fifthly, embodiments of this application provide a computer program product. The computer program product includes a computer program or instructions. When the computer program product runs on a domain name resolution device, it causes the domain name resolution device to execute the DNS TFO query message protection method of the first aspect and any possible implementation thereof.

[0025] Furthermore, the technical effects of any of the implementation methods in the second to fifth aspects can be found in the technical effects of different implementation methods in the first aspect, and will not be repeated here.

[0026] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0027] Figure 1 A schematic diagram of a DNS TFO query message protection system provided in this application embodiment; Figure 2 A flowchart illustrating a DNS TFO query message protection method provided in this application embodiment; Figure 3 A schematic diagram of a target token verification process provided in an embodiment of this application; Figure 4 A schematic diagram illustrating an incremental token generation and sending process provided in an embodiment of this application; Figure 5 A schematic diagram illustrating an expired token cleanup process provided in an embodiment of this application; Figure 6 A schematic diagram of a DNS TFO query message protection device provided in this application embodiment; Figure 7 This is a schematic diagram of the hardware structure of a domain name resolution device provided in an embodiment of this application. Detailed Implementation

[0028] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. The described embodiments are some, but not all, embodiments of this application. Other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are all within the scope of protection of this application.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate; this is merely a method of distinction used in describing objects with the same attributes in the embodiments of this application.

[0030] To facilitate understanding and explanation, the technical terms mentioned in the embodiments of this application will be introduced below.

[0031] The Domain Name System (DNS) can include senders and DNS resolution devices. Senders can be client devices, recursive resolvers, proxy resolvers, or other devices capable of initiating DNS queries. DNS resolution devices can be server devices deploying DNS servers or network devices deploying DNS resolution services and message pre-protection programs. The DNS can serve one or more domain name spaces or one or more business systems. DNS TFO query message protection within the DNS system can be used to pre-screen TFO query messages carrying DNS query data, reducing the number of duplicate messages entering the kernel protocol stack and DNS service programs of the DNS resolution device.

[0032] The kernel protocol stack can be a kernel component in a domain name resolution device used for processing network protocols. The kernel protocol stack can perform processes such as TCP connection processing, TFO cookie verification, data delivery, and DNS query data transmission. In this embodiment, the kernel protocol stack receives packets that pass pre-verification and continues to perform TCP protocol processing on those packets. Packets that fail pre-verification can be discarded before entering the kernel protocol stack.

[0033] TCP connection processing can be performed by the domain name resolution device on TCP packets, including connection establishment, connection state maintenance, sequence number verification, retransmission processing, and data delivery. For ordinary TCP packets that do not enter the DNS TFO query packet protection process, the domain name resolution device can perform TCP connection processing through the kernel protocol stack. For DNS TFO query packets, the domain name resolution device can first perform token verification and token revocation checks before deciding whether to hand over the DNS TFO query packet to the kernel protocol stack for TCP connection processing.

[0034] TFO Cookie verification is a connection credential verification process performed by the kernel protocol stack on TFO messages. TFOCookie is an existing connection credential in the TFO mechanism, used by the kernel protocol stack to determine whether to accept data carried in the SYN message by the sender. In this embodiment, the target token is different from the TFO Cookie. The target token is used to determine whether the DNS TFO query message carries a registered and unverified token before the message enters the kernel protocol stack. TFO Cookie verification is used to continue the data reception and TCP connection establishment process under the TFO mechanism after the message passes the pre-verification. This embodiment adds a one-time token protection check before TFO Cookie verification, rather than replacing TFOCookie verification in the kernel protocol stack.

[0035] Pre-verification is a token verification and token revocation check performed by the domain name resolution device on DNS TFO query messages before the message enters the kernel protocol stack. Pre-verification may include checking whether the DNS TFO query message carries the target token, determining whether the valid token record includes the target token, and determining whether the revoked token record includes the target token. If pre-verification passes, the domain name resolution device can allow the corresponding message to enter the kernel protocol stack. If pre-verification fails, the domain name resolution device can discard the corresponding message.

[0036] XDP protection programs can be deployed on the front-end message processing path of domain name resolution devices. XDP protection programs can be implemented by eBPF programs or other programs that can perform message processing before the message enters the kernel protocol stack. XDP protection programs can perform two types of checks on DNS TFO query messages. The first check confirms whether the target token belongs to a valid token record. The second check confirms whether the target token already appears in a revoked token record. XDP protection programs can allow messages if the target token belongs to a valid token record and does not appear in a revoked token record, or they can discard messages if the target token does not exist in a valid token record or has already appeared in a revoked token record. Specifically, XDP protection programs can perform token extraction, anti-forgery verification, anti-replay revocation, and XDP_PASS or XDP_DROP processing.

[0037] A DNS TFO query message can be a TFO message carrying DNS query data. This DNS TFO query message may include TCP connection establishment related fields, DNS query data, and a token. The DNS query data may include the domain name to be resolved, the query type, or extended fields. The token can be used to allow the domain name resolution device to determine whether the message meets the allowance conditions before it enters the kernel protocol stack. As an example, before accessing the target service server, the sender can send a DNS TFO query message to the domain name resolution device, which carries the domain name to be resolved and the target token. The domain name resolution device can first verify the target token before determining whether the DNS TFO query message enters the kernel protocol stack.

[0038] The token can be generated by the token management program in the domain name resolution device 200. The token can be a 128-bit random number generated using a cryptographically secure pseudo-random number generator (CSPRNG). The token may not contain sender identity, network address, connection identifier, or other structured information, and may not be bound to a specific sender 100. After obtaining the token, the sender 100 can use it as the target token in subsequent DNS TFO query messages. In one possible implementation, the token may not be written to persistent storage media, but may only be stored in a memory buffer, a valid token record, and a local token pool. This application does not limit the specific storage medium and storage period of the token.

[0039] The target token can be a token carried in the first message and used for verification of the current message. The target token can be pre-registered by the domain name resolution device and sent to the sender, or the sender can save it after receiving the incremental token from the domain name resolution device and carry it in subsequent DNS TFO query messages. In this embodiment, the target token is not used to limit the sender's identity, nor does it need to encode the sender's address, connection identifier, or user information. The target token is mainly used in conjunction with valid token records and revoked token records to complete source legitimacy judgment and reuse judgment.

[0040] A valid token record is a record used by the domain name resolution device to store registered tokens. A valid token record can record at least one token registered by a DNS server or token management program and verified for validity. A valid token record can be a hash record, eBPF mapping, in-memory table, or other data structure that supports token queries. The purpose of a valid token record is to provide a basis for determining the legitimacy of the target token's origin. When the target token exists in a valid token record, the domain name resolution device can continue to determine whether the target token has been revoked. When the target token does not exist in a valid token record, the domain name resolution device can discard DNS TFO query messages carrying that target token.

[0041] A revoked token record is a record used by the DNS resolver to store used tokens. It records tokens that have appeared in received DNS TFO query messages and are considered valid token records. Revoked token records can use Least Recently Used hash records, eBPF mappings, in-memory tables, or other data structures that support token queries and writes. The purpose of a revoked token record is to provide a basis for determining the reuse of a target token. If a target token does not appear in a revoked token record, the DNS resolver can treat it as an unrevoked token. If a target token already appears in a revoked token record, the DNS resolver can treat the DNS TFO query message carrying that target token as a message for reusing the token.

[0042] Atomic operations can be used for write operations on target tokens in concurrent message processing scenarios. Atomic operations ensure that the write process of a target token cannot be divided by other write processes, thus ensuring that the same target token can only be validly revoked once in multiple DNS TFO query messages arriving at similar times. As an example, a domain name resolution device can write a target token to a revoked token record using a "write only if it doesn't exist" approach. If the target token does not exist in the revoked token record, the write succeeds, and the domain name resolution device can allow the first message to the kernel protocol stack. If the target token already exists in the revoked token record, the write fails, and the domain name resolution device can treat the first message carrying the target token as a replay message carrying a used token. The current definitive version of the application also maps atomic operations to the target token revocation judgment, release, and discard logic.

[0043] Incremental tokens are supplementary tokens provided by the DNS resolution device to the sender after the target token has been verified through the valid token record. Incremental tokens can be written to the valid token record before being sent to the sender. Once written, the valid token record provides verification evidence for subsequent DNS TFO query messages initiated by the sender carrying the incremental token. After the incremental token is sent to the sender, the sender can replenish the number of available tokens and include the incremental token in subsequent DNS TFO queries. Therefore, incremental tokens can simultaneously supplement subsequent verification evidence and update the sender's available tokens.

[0044] See Figure 1 This diagram illustrates a DNS TFO query message protection system according to an embodiment of this application. The DNS TFO query message protection system may include a sender 100 and a domain name resolution device 200. A communication connection can be established between the sender 100 and the domain name resolution device 200. The sender 100 can send DNS TFO query messages to the domain name resolution device 200, and the domain name resolution device 200 can perform pre-screening of the DNS TFO query messages and return DNS response data to the sender 100.

[0045] In one possible implementation, the sending end 100 can generate a first message carrying a target token and DNS query data, and send the first message to the domain name resolution device 200. The domain name resolution device 200 can receive the first message through the network interface card 210. The XDP protection program 220 can perform message parsing and token verification on the first message before it enters the kernel protocol stack 230. If the first message meets the passage conditions, the XDP protection program 220 can allow the first message to pass to the kernel protocol stack 230. The kernel protocol stack 230 can perform TCP connection processing on the first message and deliver the DNS query data carried by the first message to the DNS server 240. The DNS server 240 can perform domain name resolution according to the DNS query data and can return DNS response data to the sending end 100 through the domain name resolution device 200.

[0046] In this embodiment, the sender 100 refers to a device capable of initiating DNS queries and sending DNS TFO query messages. The sender 100 is a device role name determined based on the message transmission direction and does not imply that the sender 100 only has message sending functionality. For example, the sender 100 can be a client device, a recursive resolution device, a proxy resolution device, or other network device capable of initiating DNS queries. The sender 100 can carry DNS query data in the initial SYN message, sending the DNS query data and the initial SYN message together to the domain name resolution device 200. The specific device type of the sender 100 can be set according to the DNS query scenario and network deployment method; this application does not limit this.

[0047] In this embodiment, the domain name resolution device 200 refers to a device capable of receiving DNS query messages, performing message pre-screening, and providing DNS resolution services. Exemplarily, the domain name resolution device 200 can be a server device, an edge computing device, a network security device, or other computing device deployed with DNS resolution services. The domain name resolution device 200 may include a network interface card (NIC) 210, an XDP protection program 220, a kernel protocol stack 230, and a DNS server 240. The NIC 210 can provide message receiving and sending functions. The XDP protection program 220 can run on the fast data processing path of the domain name resolution device 200. The kernel protocol stack 230 can perform TCP connection state maintenance, sequence number verification, and TFO cookie verification. The DNS server 240 can perform DNS query data resolution and DNS response data generation. Figure 1The components shown are only for illustrating certain structures related to the DNS TFO query message protection method and do not constitute a limitation on the internal structure of the domain name resolution device 200. In practical applications, the domain name resolution device 200 may also include other components capable of realizing device operation, data processing, status management, or network communication functions, and this application does not limit this.

[0048] Figure 1 Taking a single-server deployment as an example, the domain name resolution device 200 can be implemented by a single server. This server can independently maintain valid token records and revoked token records, and can perform DNS TFO query message screening, target token revocation, and DNS query data resolution.

[0049] In another possible embodiment, the domain name resolution device 200 may include multiple servers. The multi-server distributed deployment in this application employs an independent token record maintenance method. Each server maintains its own valid token record and redeemed token record, and different servers do not share valid token records and redeemed token records.

[0050] After the first server generates an incremental token and writes it into the valid token record maintained by the first server, the first server can send the incremental token to the sender 100. When the sender 100 subsequently sends a DNS TFO query message carrying the incremental token, the DNS TFO query message needs to reach the first server again so that the first server can complete token verification and token cancellation based on its own maintained valid token record and cancelled token record.

[0051] A network forwarding device can be positioned between sender 100 and multiple servers. Based on consistent hashing results, the network forwarding device can continuously forward packets from the same sender 100 to the same server. Consequently, the server that generates and registers the target token can also receive subsequent DNS TFO query packets carrying that target token, ensuring that the registration, verification, and cancellation of the target token are all completed based on token records maintained by the same server.

[0052] Network forwarding devices can be load balancers, switches, routers, or other network devices with traffic scheduling capabilities. The consistent hash parameters and traffic scheduling methods used by the network forwarding devices can be configured according to the network deployment method, and this application does not impose any restrictions on them.

[0053] This application's embodiments apply to DNS TFO query message protection scenarios. The sending end can send TFO query messages carrying DNS query data during the connection establishment phase. After obtaining a message carrying a legitimate TFO cookie and DNS query data, an attacker may repeatedly send the same message. Existing protection methods mainly rely on the kernel protocol stack in the domain name resolution device for TCP connection processing, sequence number verification, connection state maintenance, and TFO cookie verification. Repeatedly sent DNS TFO query messages will still enter the kernel protocol stack and trigger connection-related processing, resulting in the domain name resolution device's connection processing resources and DNS query processing resources being occupied.

[0054] Based on this, the embodiment of this application moves the determination of whether a DNS TFO query message enters the kernel protocol stack to before the message enters the kernel protocol stack. The domain name resolution device determines whether the target token has a registration basis based on the valid token record, and determines whether the target token has been used based on the revoked token record. When the target token has been registered and has not been revoked, the domain name resolution device allows the corresponding message to enter the kernel protocol stack. When the target token has not been registered, has been revoked, or the message does not carry a token, the domain name resolution device discards the corresponding message in the front-end path.

[0055] This application moves the protection judgment of DNS TFO query packets to XDP, allowing TFO packets carrying DNS query data and tokens to be filtered before entering the kernel protocol stack. Specifically, the token carried in the packet is first checked against the valid token records in the domain name server to exclude packets carrying invalid tokens and prevent TFO query packets with invalid tokens from entering the kernel protocol stack. If the token passes validity verification, the application checks whether the token has already been used based on the revoked token record, thus identifying packets that reuse revoked tokens and preventing attackers from copying previously valid TFO query packets and replaying them. Packets with invalid or revoked tokens are discarded directly in XDP; packets carrying valid, unrevoked tokens are allowed to enter the kernel protocol stack for further processing. Therefore, this application can identify and intercept invalid or replayed packets before they enter the kernel protocol stack without interfering with the TCP connection processing, reducing the resource consumption of invalid or replayed packets on the kernel protocol stack.

[0056] Reference Figure 2 , Figure 2 A flowchart illustrating a DNS TFO query message protection method according to an embodiment of this application is shown. Figure 2 The method shown can be applied to Figure 1The DNS TFO query message protection system shown can be applied to other applicable DNS TFO query message protection systems, and is not limited thereto. The following examples illustrate this. Figure 2 Applied to Figure 1 The DNSTFO query message protection system shown is used as an example for illustration. See [link / reference]. Figure 2 The method may include steps S201 to S205.

[0057] S201: The sender 100 sends the first message, which is a TFO query message carrying the target token and DNS query data.

[0058] In one possible implementation, the sender 100 can carry DNS query data in the initial SYN packet to form the first packet. This transmission method allows the DNS query data to be sent to the domain name resolution device 200 along with the initial SYN packet, enabling the sender 100 to send the DNS query data without waiting for the TCP three-way handshake to complete.

[0059] For example, the first message may carry a target token. The target token may be a token pre-registered by the DNS server 240 and provided to the sender 100, or it may be an incremental token supplemented by the DNS server 240 to the sender 100 during a previous message exchange. The target token may be a random byte sequence, an encoded string, a numerical value, or other data format capable of distinguishing different tokens. This application does not limit the specific length, encoding method, or data type of the target token. The sender 100 may subsequently include the target token in the TFO query message when initiating a DNS TFO query.

[0060] In one implementation, the domain name resolution device 200 can distribute tokens to the sender 100 via the extension echanisms for DNS (EDNS extended data) option in the DNS response. This EDNS extended data can employ custom option codes within the experimental scope of the Internet Assigned Numbers Authority (IANA), and the option data can include one or more consecutively arranged 16-byte token values. A DNS response can carry 1 to 200 tokens. After receiving the DNS response, the sender 100 can extract tokens from the EDNS extended data and save the extracted tokens to a local token pool.

[0061] Since the domain name resolution device 200 sends the token along with the existing DNS response, the token distribution process does not require additional token request and response messages, thus avoiding any additional network round trips. "No additional network round trips" here only means that the token distribution reuses the existing DNS response process; it does not mean that the entire DNS query process is free of network round trips.

[0062] When the sender 100 initiates a subsequent DNS TFO query, it can select a token from the local token pool as the target token and write the target token into the EDNS extension data of the DNS query data. The target token can also be written into other extension options in the DNS query data, which can be recognized and read by the domain name resolution device 200. For example, the EDNS extension data used to carry the target token can be set to 65001, in which case the target token can use 16 consecutive bytes of data. The above option codes, token lengths, and single distribution quantities are merely engineering examples. The target token can also use other option codes, data lengths, encoding formats, or distribution quantities; this application does not limit these aspects.

[0063] In this embodiment, the following three non-limiting implementation methods for token pool management are provided.

[0064] In the first implementation, the sender 100 can use a first-in-first-out (FIFO) queue as the token pool. After receiving DNS response data returned by the domain name resolution device 200, the sender 100 can extract incremental tokens from the EDNS extension data of the DNS response data and add the extracted incremental tokens to the tail of the token pool queue. When the sender 100 initiates a DNS TFO query, it can retrieve an available token from the head of the token pool queue, identify this available token as the target token, and write the target token into the EDNS extension data of the DNS query data. After sending the first message, the sender 100 can delete the target token from the token pool, so that the target token will no longer participate in the generation of subsequent first messages.

[0065] In the second implementation, the sending end 100 can detect the number of available tokens in the token pool. When the number of available tokens is lower than a preset replenishment threshold, the sending end 100 can set a token replenishment flag in the EDNS extended data of the DNS query data. After recognizing the token replenishment flag, the domain name resolution device 200 can increase the incremental number of tokens sent to the sending end 100 this time. The preset replenishment threshold can be set according to one or more of the sending end 100's query frequency, token consumption rate, and network latency. For example, the preset replenishment threshold can be fifty tokens; the above value is only an example and does not constitute a limitation.

[0066] In the third implementation, token management of the token pool can be provided by the domain name resolution device 200. When the available tokens in the token pool are exhausted, the sender 100 can stop using the TFO query method carrying the target token and establish a connection using the normal TCP method. The kernel protocol stack 230 can establish a connection through a TCP three-way handshake. After the connection is established, the sender 100 can send DNS query data, and the domain name resolution device 200 can carry an incremental token in the corresponding DNS response data. After receiving the incremental token, the sender 100 can add the incremental token to the token pool and re-use the TFO query method in subsequent DNS queries.

[0067] The three implementation methods described above are merely illustrative examples of token pool management. In practical applications, the sending end 100 may also use arrays, linked lists, cache tables, or other data structures capable of storing and retrieving tokens to manage the token pool; this application does not limit this approach.

[0068] Accordingly, the domain name resolution device 200 receives the first message.

[0069] The receiving step in this process refers to the domain name resolution device 200 receiving the first message sent by the sender 100 and enabling the first message to enter the processing path that can perform message identification and pre-screening.

[0070] In one possible implementation, the domain name resolution device 200 can receive the first packet via the network interface card 210. After receiving the first packet, the network interface card 210 can direct the first packet into the fast data processing path corresponding to the XDP protection program 220.

[0071] For example, XDP protection program 220 can parse one or more of the following: Ethernet header, network layer header, TCP header, and DNS query data. XDP protection program 220 can perform packet boundary checks during the parsing process. Packet boundary checks may include determining whether the start position of the target field is within the packet range, whether the end position of the target field exceeds the packet range, and whether the declared data length of the target field matches the actual remaining length, to avoid reading beyond the actual length of the first packet.

[0072] The domain name resolution device 200 may also obtain the first message through a virtual network interface, software switching path, network acceleration component, or other components capable of receiving network packets. This application does not limit the specific component of the domain name resolution device 200 that receives the first message.

[0073] In this embodiment, after receiving the packet, the domain name resolution device 200 can parse the TCP flag, TFO option, and DNS query data of the packet. When the domain name resolution device 200 determines that the packet is a TFO query packet carrying DNS query data in the initial SYN packet based on the resolution result, it can continue to execute step S202 to obtain the target token in the first packet.

[0074] XDP protection program 220 can perform one or more of the following processes: packet identification, pre-screening, packet allowing, and packet dropping. XDP protection program 220 may not construct TCP responses or maintain TCP connection state. Kernel protocol stack 230 can continue to perform TCP connection state maintenance, sequence number verification, and TFO cookie verification. The specific functions of each component can be configured according to the program deployment method and packet processing architecture of domain name resolution device 200; this application does not impose any limitations on this.

[0075] S202: Domain name resolution device 200 obtains the target token in the first message.

[0076] The first message is a TFO query message carrying the target token and DNS query data. The target token is the token carried in the first message that is recorded in the valid token record or not recorded in the revoked token record.

[0077] In one possible implementation, the XDP protection program 220 can read the token data in the token field based on the position and length of the token field to obtain the target token.

[0078] As an example, the domain name resolution device 200 can perform a format check on the token field during the acquisition of the target token. The format check may include determining whether the EDNS extension data corresponding to the token field has a preset option code, whether the data length declared by the EDNS extension data is equal to the preset token length, and whether the token data in the EDNS extension data is within the actual data boundary of the first message. For example, the preset option code can be 65001, and the preset token length can be 16 bytes. If the domain name resolution device 200 determines that any format check condition is not met, it can stop extracting the target token and discard the first message with the abnormal format. The above-described exception handling method is only one possible implementation, and this application does not limit it.

[0079] S203: Domain name resolution device 200 determines whether the valid token record includes the target token.

[0080] A valid token record is used to record at least one token registered by DNS server 240 and verified for validity. DNS server 240 can be deployed on domain name resolution device 200 and can register the corresponding token in the valid token record before providing the token to sender 100. In this case, the token registered in the valid token record of domain name resolution device 200 is the token generated by domain name resolution device 200. In other implementations, other devices can also generate tokens and register them with domain name resolution device 200, thereby achieving the registration of a valid token record in domain name resolution device 200.

[0081] In this application, validity verification refers to the verification performed by the DNS server 240 before or during token registration to determine whether a token can be used as a credential for message transmission. Validity verification may include one or more of the following: token format verification, token generation result verification, token duplication verification, token source verification, and token validity period verification. Different token generation methods may correspond to different validity verification content, and this application does not impose any limitations on this.

[0082] For example, after generating a token, the token management program can determine whether the data length of the token meets the preset length and can query whether the same token already exists in the valid token record. If the token meets the preset length and the same token does not exist in the valid token record, the token management program can write the token into the valid token record. After the token is successfully written into the valid token record, the token can be regarded as a registered token that has passed the validity verification.

[0083] In this embodiment, the following two non-limiting implementation methods for achieving valid token records are provided.

[0084] In the first implementation, the valid token record can be implemented using an eBPF mapping of the hash mapping type. The valid token record can use the token value as the query key and the token registration time, token expiration time, or token status information as the record value.

[0085] For example, a valid token record can be a record named token_map. The token_map can be a hash map type. The lookup key of the token_map can be a 16-byte token, the record value can be an 8-byte token registration timestamp, and the maximum number of records can be set to 1,048,576.

[0086] In one possible implementation, the maximum number of valid token records can be determined based on the peak number of queries per second, T (token validity period), and a security factor. max_entries (maximum number of records) can satisfy the following relationship: max_entries ≥ Peak QPS (queries per second) × T × Safety factor.

[0087] Peak QPS represents the maximum number of DNS queries that Domain Name System 200 can handle per unit of time. Validity period T represents the time range from when the token is registered to when it is determined to be expired. The security factor is used to reserve recording space for query traffic fluctuations, centralized token generation, and token cleanup delays.

[0088] For example, the security factor can be set to 1.2 to 2.0. The domain name resolution device 200 can also set other security factors based on available memory capacity, actual peak query volume, and token cleanup cycle, which is not limited in this application.

[0089] XDP protection program 220 can use the target token as the query key to query the token_map. When XDP protection program 220 finds a record corresponding to the target token, domain name resolution device 200 can determine that the valid token records include the target token. When XDP protection program 220 does not find a record corresponding to the target token, domain name resolution device 200 can determine that the valid token records do not include the target token.

[0090] In the second implementation, the valid token record can be a database table, cache structure, array structure, tree structure, or other data structure that supports querying, writing, and deleting based on the token value. The domain name resolution device 200 can query the valid token record using the target token. If a record matching the target token exists in the valid token record, the domain name resolution device 200 determines that the valid token record includes the target token; if no record matching the target token exists in the valid token record, the domain name resolution device 200 determines that the valid token record does not include the target token.

[0091] The mapping name, data length, and maximum number of records mentioned above are merely examples. Valid token records can have other data lengths and record capacities set based on device memory capacity, service traffic, and token validity period; this application does not impose any limitations on this.

[0092] When the domain name resolution device 200 determines that the target token does not exist in a valid token record, it discards the first message carrying the target token. This situation may indicate that the target token was not registered by the DNS server 240, the target token failed validity verification, the target token has expired and been cleaned up, or the domain name resolution device 200 cannot find a valid record corresponding to the target token. In practical applications, the specific reasons or manifestations for the target token not existing in the valid token record can be determined based on the data structure of the valid token record, the token registration method, the token validity verification method, or the token cleanup method. This application does not limit this. When the domain name resolution device 200 determines that the valid token record includes the target token, it may execute step S204.

[0093] S204: Domain name resolution device 200 determines whether the revoked token record includes the target token.

[0094] The revoked token record is used to record tokens carried in TFO query messages received by DNS server 240 that are valid token records. If the target token is recorded in the revoked token record, it indicates that the target token has appeared in a previously received TFO query message and has been revoked. If the target token is not recorded in the revoked token record, it indicates that the domain name resolution device 200 has not yet found a revoked record for the target token.

[0095] In this application, token cancellation refers to the domain name resolution device 200 recording that the target token has been used by a TFO query message, preventing the target token from being used again as a release credential for other TFO query messages. Token cancellation does not require the synchronous deletion of the corresponding token in the valid token record. Valid token records can be used to indicate whether a token has been registered, and cancelled token records can be used to indicate whether a registered token has been used. The domain name resolution device 200 can determine the registration and usage status of the target token through both types of records.

[0096] In this embodiment, the following two non-limiting implementation methods for recording cancelled tokens are provided.

[0097] In the first implementation, the redeemed token record can be implemented using an eBPF hash map with an LRU mechanism.

[0098] For example, the redeemed token record can be a record named used_token_map. The used_token_map can be an LRU hash map type. The lookup key of the used_token_map can be a 16-byte token, the record value can be an 8-byte token redemption timestamp, and the maximum number of records can be set to 1,048,576.

[0099] XDP protection program 220 can use the target token as the query key to query the used_token_map. When XDP protection program 220 finds the target token, domain name resolution device 200 can determine that the redeemed token records include the target token. When XDP protection program 220 does not find the target token, domain name resolution device 200 can determine that the redeemed token records do not include the target token.

[0100] In the second embodiment, the redeemed token record can be a database table, a cache structure, a bitmap structure, or other data structure capable of recording the token usage status. The domain name resolution device 200 can query the redeemed token record using the target token. If a record matching the target token exists in the redeemed token record, the domain name resolution device 200 determines that the redeemed token record includes the target token. If no record matching the target token exists in the redeemed token record, the domain name resolution device 200 determines that the redeemed token record does not include the target token. The above mapping name, record value type, and record capacity are merely examples and do not constitute a limitation on the redeemed token record.

[0101] When the domain name resolution device 200 determines that the target token exists in the redeemed token record, it discards the first message carrying the target token. This situation may indicate that the target token has been used by a previously received TFO query message, the target token has completed redemption registration, the used status corresponding to the target token has been recorded, or the domain name resolution device 200 can query the redeemed record corresponding to the target token. In practical applications, the specific reasons or manifestations for the target token existing in the redeemed token record can be determined based on the data structure, status identification method, or redemption registration method of the redeemed token record, and this application does not limit this. When the domain name resolution device 200 determines that the redeemed token record does not include the target token, it may execute step S205.

[0102] S205: Domain name resolution device 200 allows the first message to be passed to the kernel protocol stack 230 of the domain name server.

[0103] When the valid token record includes the target token, the redeemed token record does not include the target token, and the valid token record includes the target token, the domain name resolution device 200 may allow the first message to pass through the kernel protocol stack 230 of the domain name server.

[0104] In this application, the kernel protocol stack 230 of the domain name server refers to the network protocol processing component in the operating system kernel of the domain name resolution device 200 where the DNS server 240 is deployed. Both the XDP protection program 220 and the kernel protocol stack 230 can run on the domain name resolution device 200. The XDP protection program 220 is located in the packet processing path before the first packet enters the kernel protocol stack 230.

[0105] In this application, "allowing" means that the XDP protection program 220 allows the first packet to leave the pre-screening path and continue into the kernel protocol stack 230. As an example, the XDP protection program 220 can return an XDP_PASS processing result for the first packet, allowing the first packet to enter the kernel protocol stack 230.

[0106] After the first packet is allowed to pass, the kernel protocol stack 230 still needs to perform one or more of the following processes on the first packet: TCP connection state maintenance, sequence number verification, TFO cookie verification, and data delivery. After the first packet passes the corresponding processing by the kernel protocol stack 230, the kernel protocol stack 230 can deliver the DNS query data carried in the first packet to the DNS server 240. The DNS server 240 can perform domain name resolution and generate DNS response data based on the DNS query data.

[0107] Therefore, the XDP protection program 220 allowing the first packet to pass to the kernel protocol stack 230 does not mean that the first packet has bypassed TCP protocol processing, nor does it mean that the first packet has been directly delivered to the DNS server 240. The kernel protocol stack 230 still determines the subsequent processing result of the first packet according to the protocol processing flow corresponding to TCP and TFO.

[0108] Because the domain name resolution device 200 can identify unregistered tokens, invalid tokens, and revoked tokens before the first message enters the kernel protocol stack 230, it can reduce the processing resource consumption caused by forged or replayed messages triggering TCP connection state maintenance, TFO cookie verification, and DNS query processing. Meanwhile, the kernel protocol stack 230 continues to execute TCP connection processing and TFO protocol verification, and the XDP protection program 220 does not take over the TCP connection state.

[0109] Meanwhile, the XDP protection program 220 performs pre-screening and processing of packets, while the kernel protocol stack 230 continues to perform TCP connection processing and TFO protocol verification. Therefore, the pre-protection process does not need to take over the TCP connection state.

[0110] In one possible implementation, the first message may be lost during transmission. If the sender 100 does not receive a corresponding response, it can retransmit the TFO SYN message. Since the retransmitted TFO SYN message corresponds to the same TFO connection attempt as the first message sent initially, the retransmitted TFO SYN message can carry the same target token as the first message.

[0111] When the domain name resolution device 200 has already written the target token into the redeemed token record based on the first received message, the domain name resolution device 200 can find the target token in the redeemed token record after receiving a retransmitted TFO SYN message. The domain name resolution device 200 may discard the retransmitted TFO SYN message.

[0112] In this embodiment, retransmission messages can be generated by the normal retransmission mechanism of the sender 100, or they may be repeatedly sent by other devices. The domain name resolution device 200 can perform message processing based on whether the target token has been recorded in the revoked token record, without needing to further distinguish the cause of the duplicate message. In this way, it can be ensured that the same target token corresponds to only one allowed TFO query message.

[0113] After the retransmitted TFO SYN packet is discarded, the sender 100 can, according to the connection timeout handling mechanism in the TCP implementation, stop the current TFO connection attempt and re-initiate the connection using the normal TCP connection method. The sender 100 can also send a normal SYN packet to the domain name resolution device 200 without carrying DNS query data and the target token.

[0114] After receiving a normal SYN packet, the domain name resolution device 200 may not perform any actions. Figure 2 The token verification process is shown. XDP protection program 220 can perform XDP_PASS processing on ordinary SYN packets, allowing the ordinary SYN packets to enter the kernel protocol stack 230. Kernel protocol stack 230 can return a SYN-acknowledgment (ACK) packet to sender 100, and complete the TCP three-way handshake after receiving the ACK packet returned by sender 100.

[0115] After the TCP connection is established, the sender 100 can send DNS query data through the established TCP connection. The kernel protocol stack 230 can deliver the DNS query data to the DNS server 240. The DNS server 240 can parse the DNS query data and generate DNS response data.

[0116] In one possible implementation, the domain name resolution device 200 may carry at least one incremental token already written to a valid token record in the DNS response data and send the DNS response data to the sender 100. The sender 100 may save the incremental token and use it when subsequently initiating a TFO connection, thereby restoring the sender 100's ability to send TFO query messages carrying the token.

[0117] The DNS response data obtains the token required for subsequent DNS TFO queries, and the sender 100 that already supports the token mechanism can continue to use the DNS TFO query method. Therefore, the protection mechanism provided in this application can be compatible with senders 100 in different upgrade states and supports the gradual deployment of the token mechanism.

[0118] The above-mentioned normal TCP rollback conditions, connection timeout duration, and incremental token supply quantity can be set according to the TCP implementation method of the sender 100, the network environment, and the token management strategy. This application does not impose any restrictions on these settings.

[0119] This embodiment uses the sending end 100 sending a first message as an example. The first message is a TFO query message carrying a target token and DNS query data. In actual application scenarios, the sending end 100 can also send a second message, which is a TFO query message without a token. The situation where the sending end 100 does not carry a token may include situations such as the sending end 100 not having obtained a token, the sending end 100 having exhausted its tokens, or an abnormal message not carrying a token. This application does not limit this. The first message and the second message are used to distinguish different message conditions and do not indicate that there is a fixed sending order or receiving order between the first message and the second message. In actual application scenarios, the sending end 100 can send either the first message or the second message, and this application does not limit this.

[0120] In one possible engineering implementation, the domain name resolution device 200 can determine whether the received second message includes a token. If the second message does not include a token, the XDP protection program 220 in the domain name resolution device 200 can return an XDP_DROP (discard file) processing result for the second message, preventing the second message from entering the kernel protocol stack 230. Alternatively, the domain name resolution device 200 can also employ other message discarding methods capable of terminating subsequent processing of the second message; this application does not limit this approach.

[0121] By discarding the second message before it enters the kernel protocol stack 230, the domain name resolution device 200 can reduce the processing resource consumption caused by TFO query messages without tokens triggering TCP connection processing and DNS query processing.

[0122] In this embodiment, the first message sent by the sender 100 is a TFO query message. In actual application scenarios, the sender 100 can also send a normal TCP handshake message or send a TCP data packet carrying DNS query data through an established normal TCP connection.

[0123] If the domain name resolution device determines that the first packet does not belong to the DNS TFO query packet, it may not need to perform any further actions. Figure 2The token verification process is shown, and the first message is allowed to pass through the kernel protocol stack 230. The kernel protocol stack 230 can process the first message according to the TCP state machine, including checking TCP flags and sequence numbers, querying or establishing the TCP connection state, generating an acknowledgment message, and delivering the received DNS query data to the DNS server 240. For example, in a scenario where the sender 100 uses ordinary TCP to transmit DNS query data, the sender 100 can first send an initial synchronization message, i.e., a SYN message, to initiate a TCP connection. After receiving the SYN message, the kernel protocol stack 230 can establish the corresponding TCP connection state and return a synchronization acknowledgment message, i.e., a SYN-ACK message, to the sender 100. After receiving the SYN-ACK message, the sender 100 can return an acknowledgment message, i.e., an ACK message. After receiving the ACK message, the kernel protocol stack 230 can complete the TCP three-way handshake. After the TCP connection is established, the sender 100 can send TCP data packets carrying DNS query data through this TCP connection. The kernel protocol stack 230 can perform sequence number verification, data reassembly, and acknowledgment processing on the TCP datagram, and submit the reassembled DNS query data to the DNS server 240 for resolution. In this way, the domain name resolution device 200 can continue to support the establishment of ordinary TCP connections and the transmission of DNS query data while retaining the DNS TFO query message token verification process.

[0124] Reference Figure 3 , Figure 3 The process of writing a target token to a redeemed token record atomically is illustrated. In some possible implementations, to reduce the possibility of multiple concurrent first packets using the same target token, the domain name resolution device 200 may write the target token to the redeemed token record atomically before allowing the first packet to pass to the kernel protocol stack 230. This method may include steps S301 to S304.

[0125] S301: Domain name resolution device 200 writes the target token to the revoked token record based on atomic operations.

[0126] The atomic operation in this application refers to the domain name resolution device 200 using an update operation that allows writing only if the target token does not exist in the redeemed token record, thus writing the target token to the redeemed token record. When multiple processes concurrently perform this update operation on the same target token, assuming the redeemed token record is functioning normally, only one process can successfully write the target token, and other processes cannot write the same target token again.

[0127] In one possible engineering implementation, the domain name resolution device 200 may use an eBPF mapping update operation with the BPF_NOEXIST flag to write the target token to the revoked token record.

[0128] The BPF_NOEXIST (write only if not found) flag ensures that a mapping update operation only writes to the target token if it does not already exist as a query key. If the target token already exists in the redeemed token record, the mapping update operation cannot write to the same target token again.

[0129] In another possible embodiment, the domain name resolution device 200 may also employ other atomic update mechanisms to cancel the target token. This atomic update mechanism may allow only one concurrent process to successfully write the same target token into the canceled token record, and use the writing result as the basis for determining whether the first message should be allowed or discarded. This application does not limit this approach.

[0130] S302: Domain name resolution device 200 determines whether the target token has been written to the already cancelled token record.

[0131] The domain name resolution device 200 can determine whether the target token has been successfully written to the revoked token record based on the execution result of the atomic operation.

[0132] A successful write of the target token indicates that the processing of the first message will complete the target token verification first.

[0133] The message "Target token not written" could mean that the target token has already been written to the redeemed token record, or that the write operation failed to complete.

[0134] In one possible implementation, the domain name resolution device 200 can determine whether the target token was successfully written based on the result code returned by the eBPF mapping update operation. The domain name resolution device 200 can also determine the writing result of the target token by reading other write result information. This application does not limit this approach.

[0135] S303: When the target token is written to the revoked token record, the domain name resolution device 200 allows the first message to be passed to the kernel protocol stack 230 of the DNS server.

[0136] After the domain name resolution device 200 confirms that the target token has been successfully written, it can allow the current first packet to pass through the kernel protocol stack 230.

[0137] For example, XDP protection procedure 220 can return the XDP_PASS processing result, allowing the current first packet to continue into the kernel protocol stack 230. Since the target token has been written to the redeemed token record, subsequent first packets carrying the same target token can be identified when querying the redeemed token record or performing atomic operations.

[0138] S304: Domain name resolution device 200 discards the first message carrying the target token if the target token has not been written to the revoked token record.

[0139] After the domain name resolution device 200 confirms that the target token has not been written into the revoked token record, it can discard the first message carrying the target token.

[0140] For example, the XDP protection program 220 can return the XDP_DROP processing result, causing the first message carrying the target token to stop entering the kernel protocol stack 230.

[0141] Through atomic operations, the domain name resolution device 200 can associate the verification result of the target token with the release result of the first message. When the same target token corresponds to multiple concurrent first messages, only the first message that successfully completes the writing of the target token can be identified as the first message and released to the kernel protocol stack 230; other first messages that fail to successfully complete the writing of the target token can be discarded. In this way, the situation where multiple first messages corresponding to the same target token are released simultaneously under concurrent processing conditions can be reduced.

[0142] Reference Figure 4 , Figure 4 The incremental token generation and sending process is illustrated. In some possible implementations, after determining that the valid token record includes the target token, the domain name resolution device 200 can also generate at least one incremental token and send the successfully registered incremental token to the sender 100 corresponding to the first message. For example... Figure 4 As shown, the method may include steps S401 to S404.

[0143] S401: Domain name resolution device 200 generates at least one incremental token.

[0144] An incremental token is a token newly generated by the domain name resolution device 200 and provided to the sender 100. After receiving the incremental token, the sender 100 can save the incremental token to its local token pool and carry it as the target token in the TFO query message when initiating a subsequent DNS TFO query.

[0145] The domain name resolution device 200 can determine the number of incremental tokens generated this time based on the preset replenishment quantity, the token replenishment request from the sender 100, the remaining token quantity of the sender 100, the current token inventory, or the current business load.

[0146] In one possible implementation, the user-space token manager in the domain name resolution device 200 can invoke a cryptographically secure pseudo-random number generator (CSPRNG) to generate incremental tokens in batches. For example, the token manager can generate consecutive 16 bytes of random data using getrandom (a random number retrieval system call), and use each set of consecutive 16 bytes of random data as a 128-bit incremental token.

[0147] The incremental token may not encode the sender's identity, sender's network address, TCP connection identifier, or other structured information, and may not be bound to a specific sender 100. The domain name resolution device 200 can query the corresponding token record based solely on the incremental token itself, without needing to determine the validity of the incremental token based on the sender 100's identity information.

[0148] In this configuration, the domain name resolution device 200 may choose not to write the generated incremental token to persistent storage. The token management program can temporarily store the generated incremental token in a memory buffer and write it to the valid token record. After the incremental token is successfully written to the valid token record, the token management program can add the incremental token to the set of tokens to be distributed. After the incremental token has been distributed or its corresponding retention period has expired, the domain name resolution device 200 can clear the corresponding data in the memory buffer.

[0149] For example, the domain name resolution device 200 can also use other cryptographically secure random number generation interfaces to generate incremental tokens. The data length of the incremental token, the number generated at one time, and the memory storage method can be set according to the device's processing power, token consumption speed, and security requirements, and this application does not limit them.

[0150] Because the incremental token uses a cryptographically secure random number generation method and does not encode the identity information of the sender 100, it is difficult for a third party to deduce the identity of the sender 100 or directly associate different DNS queries with the same sender 100 based on the token value.

[0151] S402: Domain name resolution device 200 writes at least one incremental token to a valid token record.

[0152] Domain name resolution device 200 can register the incremental token to the valid token record before sending the incremental token to sender 100.

[0153] Domain name resolution device 200 can perform one or more of the following on incremental tokens: format verification, duplicate verification, and validity period verification, and write incremental tokens that pass the validity verification to the valid token record.

[0154] In one possible engineering implementation, the domain name resolution device 200 can use the incremental token as the query key, the generation time or expiration time of the incremental token as the record value, and write the incremental token into the token_map through an eBPF mapping update operation with the BPF_NOEXIST flag.

[0155] The write method with the BPF_NOEXIST flag can prevent the same token from being registered repeatedly. After the incremental token is successfully written, the domain name resolution device 200 can add the incremental token to the set of tokens to be sent. If the incremental token write fails, the domain name resolution device 200 can abandon sending the incremental token.

[0156] S403: Domain name resolution device 200 determines whether at least one incremental token has been written to a valid token record.

[0157] The domain name resolution device 200 can determine whether the incremental token has been successfully written to a valid token record based on the mapping update result, the database write result, or other registration results.

[0158] When a portion of multiple incremental tokens are successfully written, the domain name resolution device 200 can identify the successfully written incremental tokens as incremental tokens to be sent and abandon sending the incremental tokens that failed to be written.

[0159] If multiple incremental tokens fail to be written successfully, the domain name resolution device 200 can either terminate the current incremental token sending process or regenerate other incremental tokens. This application does not impose any limitations on this.

[0160] S404: Domain name resolution device 200 sends at least one incremental token to sender 100 when at least one incremental token is written to a valid token record.

[0161] Sender 100 is the source device of the first message. Domain name resolution device 200 can send an incremental token to sender 100 indicating that the valid token record has been successfully written.

[0162] In one possible engineering implementation, after the first message is processed by the kernel protocol stack 230 and DNS response data is generated by the DNS server 240, the domain name resolution device 200 can carry the incremental token in the EDNS extension data of the DNS response data.

[0163] For example, the domain name resolution device 200 can set the option code to 65001 and write a continuous 16-byte incremental token to the EDNS extension data. After receiving the DNS response data, the sender 100 can extract the incremental token from the EDNS extension data and save the incremental token to a local token pool.

[0164] The domain name resolution device 200 may also send incremental tokens to the sender 100 through other DNS extended fields or other communication messages. This application does not limit this.

[0165] When the number of available tokens in the local token pool falls below a preset number, the sender 100 may request the domain name resolution device 200 to replenish incremental tokens. For example, when the number of available tokens is less than fifty, the sender 100 may include a token replenishment identifier in the DNS query data. The token replenishment identifier may be located in the EDNS extended data with option code 65002. The aforementioned quantities and option codes are merely examples and do not constitute a limitation.

[0166] By registering the incremental token before sending it, the domain name resolution device 200 ensures that the incremental token received by the sender 100 already exists in the valid token record. When the sender 100 subsequently sends the first message carrying this incremental token, the domain name resolution device 200 can find the incremental token in the valid token record.

[0167] The incremental token generation and sending process can be executed after the valid token record includes the target token. There is no fixed execution order between this process and the process of querying the cancelled token record. Without affecting the first message release decision, the domain name resolution device 200 can perform the incremental token generation process first, or it can perform the incremental token generation process after completing the first message token cancellation; this application does not impose any restrictions on this.

[0168] Reference Figure 5 , Figure 5 The invalid token cleanup process is illustrated. In some possible implementations, to reduce the continuous occupation of storage space for valid token records or cancelled token records by invalid tokens, the domain name resolution device 200 can perform cleanup on invalid tokens. For example... Figure 5 As shown, the method may include steps S501 to S504.

[0169] S501: Domain name resolution device 200 determines an invalid token in the valid token record.

[0170] In this application, an invalid token refers to a token that no longer meets the preset validity conditions.

[0171] The domain name resolution device 200 can determine whether a token has expired based on the token registration time and preset validity period. Alternatively, the domain name resolution device 200 can determine whether a token has expired based on the token expiration time, token status identifier, token generation batch, or other expiration conditions.

[0172] For example, the record value in the valid token record may include the token registration time. The domain name resolution device 200 can determine the token's duration based on the difference between the current time and the token registration time. If the token's duration is longer than a preset valid duration, the domain name resolution device 200 can determine that the token has expired.

[0173] In one possible implementation, the preset validity period can be denoted as validity period T. Validity period T can be greater than the longest token consumption time for the sender's local token pool to change from a full state to an empty state. For example, validity period T can be set to 300 seconds. The specific value of validity period T can be set according to the token pool capacity, DNS query frequency, and token consumption rate; this application does not limit this.

[0174] Since the validity period T is greater than the maximum time required for the sender 100 to consume all tokens in the local token pool, the sender 100 can use the tokens it has already acquired during the normal consumption period, reducing the possibility of tokens being cleared due to expiration before they have been used.

[0175] Both the first and second tokens can be tokens that have expired in the valid token record. The first and second tokens are used to distinguish whether an expired token is recorded in the cancelled token record, and do not indicate a fixed generation order or expiration order between the two tokens.

[0176] S502: Domain name resolution device 200 determines whether the invalid token is recorded in the record of cancelled tokens.

[0177] Domain name resolution device 200 can use the expired token as a query key to query the records of revoked tokens.

[0178] If an expired token is not recorded in the revoked token record, the domain name resolution device 200 can identify the expired token as the first token. The first token can represent a token that has expired but was not used by TFO query messages during its validity period.

[0179] When an expired token is recorded in an already cancelled token record, the domain name resolution device 200 can identify the expired token as a second token. The second token can represent a token that has expired and has already been used by a TFO query message.

[0180] S503: Domain name resolution device 200 deletes the first token from the valid token record.

[0181] If the first token in the valid token record of the domain name resolution device 200 has expired and is not recorded in the cancelled token record, the first token can be deleted from the valid token record.

[0182] Since the first token has expired and been unused, it no longer needs to be used in the validity determination of subsequent target tokens. After the domain name resolution device 200 deletes the first token, subsequent TFO query messages carrying the first token cannot be determined using the valid token record.

[0183] In one possible engineering implementation, the domain name resolution device 200 can use the first token as a query key to perform an eBPF mapping deletion operation to remove the first token from the token_map.

[0184] Domain name resolution device 200 can also clean up the first token by deleting the database, eviction of the cache, or other record deletion methods. This application does not limit this.

[0185] S504: Domain name resolution device 200 deletes the second token from the list of revoked tokens according to the LRU mechanism.

[0186] If the second token in the valid token record of the domain name resolution device 200 becomes invalid, and the second token record is in the case of a cancelled token record, the second token can be deleted from the cancelled token record according to the LRU mechanism.

[0187] In one possible engineering implementation, the cancelled token records can employ an LRU hash map. The LRU hash map maintains the eviction order based on the most recent access status of each token record. When the number of cancelled token records reaches a capacity limit, the LRU hash map can prioritize eviction of expired token records that have not been accessed for a longer period.

[0188] The domain name resolution device 200 can also determine the deletion timing of the second token based on the expiration time and the most recent access time of the second token. This application does not limit the specific implementation of the LRU mechanism.

[0189] The first token cleanup method corresponding to step S503 and the second token cleanup method corresponding to step S504 are two parallel processing methods. The domain name resolution device 200 can execute step S503 when the first token meets the corresponding conditions, or it can execute step S504 when the second token meets the corresponding conditions.

[0190] In this embodiment, the domain name resolution device 200 may simultaneously delete the second token from the valid token record when executing step S504. The domain name resolution device 200 may handle the second token in the valid token record separately according to the actual token management strategy, and this application does not limit this.

[0191] In this embodiment, invalid token cleanup can be performed using the following two non-limited triggering methods.

[0192] In the first triggering method, the domain name resolution device 200 can perform expired token cleanup according to a preset cleanup cycle. The preset cleanup cycle can be set according to the token validity period, token generation frequency, and business load.

[0193] In the second triggering method, the domain name resolution device 200 can perform expired token cleanup when the number of records in the valid token records or the expired token records reaches a preset threshold. The domain name resolution device 200 can also trigger expired token cleanup based on device storage space, device processing load, or token generation batches.

[0194] The above triggering methods can be used individually or in combination, and this application does not limit them.

[0195] By distinguishing between unredeemed and redeemed invalid tokens, the domain name resolution device 200 can adopt corresponding cleanup methods for different token states, thereby reducing the continuous occupation of token record space by invalid tokens and maintaining available storage capacity for valid and redeemed token records.

[0196] Furthermore, this application also provides a DNS TFO query message protection device. See also Figure 6 , Figure 6 This illustration shows a schematic diagram of a DNS TFO query message protection device according to an embodiment of this application. The DNS TFO query message protection device 600 can be deployed on a domain name resolution device, or on a computer device or cluster of computer devices capable of performing message processing before the DNS TFO query message enters the kernel protocol stack. The DNS TFO query message protection device 600 may include a receiving module 610, a first judgment module 620, a second judgment module 630, a allowing module 640, and a discarding module 650.

[0197] The receiving module 610 is used to receive a first message, which is a TFO query message carrying a target token and DNS query data.

[0198] The first judgment module 620 is used to determine whether the valid token record includes the target token. The valid token record is used to record at least one token that has been registered by the DNS server and passed the validity verification.

[0199] The second judgment module 630 is used to determine whether the cancelled token record includes the target token when the valid token record includes the target token. The cancelled token record is used to record the token carried in the TFO query message received by the DNS server and belonging to the valid token record.

[0200] The allow module 640 is used to allow the first message to the kernel protocol stack of the DNS server in cases where the revoked token record does not include the target token, so that the kernel protocol stack can process the first message.

[0201] The discard module 650 is used to discard the first message if the target token does not exist in the valid token record or if the target token exists in the revoked token record.

[0202] In one possible implementation, the DNS TFO query message protection device 600 may also include a verification module.

[0203] The verification module is used to write the target token into the verified token record based on atomic operations before the release module 640 releases the first message to the kernel protocol stack of the DNS server.

[0204] In one possible implementation, the release module 640 is also configured to release the first message to the kernel protocol stack of the DNS server if the target token is written to the revoked token record.

[0205] The discard module 650 is also used to discard the first message if the target token has not been written to the revoked token record.

[0206] In one possible implementation, the DNS TFO query message protection device 600 may further include a generation module, a writing module, and a sending module.

[0207] The generation module is used to generate at least one incremental token after the first judgment module 620 determines that the valid token record includes the target token.

[0208] The write module is used to write at least one incremental token to a valid token record.

[0209] The sending module is used to send at least one incremental token to the sender corresponding to the first message after at least one incremental token has been written into a valid token record.

[0210] In one possible implementation, the DNS TFO query message protection device 600 may also include a cleanup module.

[0211] The cleanup module is used to delete the first token from the valid token record if the first token in the valid token record becomes invalid and is not recorded in the cancelled token record.

[0212] Alternatively, the cleanup module is used to delete the second token from the cancelled token record if the second token in the valid token record becomes invalid, and if the second token record is in the case of a cancelled token record, based on the least recently used mechanism.

[0213] The first token and the second token are used to distinguish tokens that meet different cleanup conditions. There is no fixed generation order, registration order, or expiration order between the first token and the second token.

[0214] In one possible implementation, the receiving module 610 is also used to receive a second message.

[0215] The discard module 650 is also used to discard the second message if the second message is a TFO query message and the second message does not carry a token.

[0216] The receiving module 610 can receive the first and second packets through the network card or network interface of the domain name resolution device. The first judgment module 620 and the second judgment module 630 can be implemented by the XDP protection program running in the domain name resolution device. The allowing module 640 can deliver the first packet to the kernel protocol stack of the DNS server by returning the XDP_PASS processing result. The dropping module 650 can prevent the first or second packet from entering the kernel protocol stack by returning the XDP_DROP processing result.

[0217] In another possible embodiment, the receiving module 610, the first judgment module 620, the second judgment module 630, the release module 640, and the discard module 650 can also be implemented by software programs, hardware circuits, or a combination of software programs and hardware circuits. Each module can be set separately, or two or more modules can be integrated into the same functional component. This application does not limit this.

[0218] The DNS TFO query message protection device 600 provided in this embodiment corresponds to the aforementioned Figures 2 to 5 The method is illustrated above. Therefore, the functions of each module and the technical effects of each module in this embodiment can be found in the foregoing. Figures 2 to 5 The relevant descriptions in the corresponding embodiments will not be repeated here.

[0219] Figure 7 This is a structural diagram of a domain name resolution device provided in this application. Figure 7 As shown, the domain name resolution device 700 includes a processor 701, a memory 702, a communication interface 703, and a bus 704. The processor 701, memory 702, and communication interface 703 communicate via the bus 704. The bus 704 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0220] It should be understood that in the embodiments of this application, processor 701 may be a CPU, or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete device assemblies, etc. General-purpose processors may be microprocessors or any conventional processors, etc.

[0221] The memory 702 may include read-only memory and random access memory, and provides instructions and data to the processor 701. The memory 702 may also include non-volatile random access memory.

[0222] The memory 702 can be volatile memory or non-volatile memory, or it can include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0223] The memory 702 stores executable code, and the processor 701 executes the executable code to perform the aforementioned actions. Figure 2 The DNS TFO query message protection method in the illustrated embodiment.

[0224] It should be understood that the domain name resolution device 700 in this application embodiment can correspond to the domain name resolution device 200 in the embodiment, and can correspond to the execution of the embodiments of this application. Figure 2 The DNS TFO query message protection method in the illustrated embodiment, and the above and other operations and / or functions implemented by the domain name resolution device 700, are respectively for the purpose of implementing... Figure 2 The process of the corresponding methods in [the document] will not be elaborated here for the sake of brevity.

[0225] This application illustrates the DNS TFO query message protection method as being executed by the domain name resolution device 200. In other possible embodiments, the aforementioned DNS TFO query message protection method may also be executed by other computer devices with capabilities such as message reception, token record query, token cancellation, message release, and message discarding; this application does not limit this.

[0226] In addition, this application also provides a domain name resolution device cluster. The domain name resolution device cluster may include at least one domain name resolution device. Each domain name resolution device may include a processor and a memory. The memory may store computer instructions. The processor may invoke and execute the computer instructions to perform the DNS TFO query message protection method provided in this application.

[0227] In one possible implementation, multiple domain name resolution devices in a domain name resolution device cluster can process DNS TFO query messages sent by different senders. Each domain name resolution device can maintain its own valid token record and revoked token record, and can independently perform target token query, target token revocation, message release, and message discarding.

[0228] In another possible embodiment, multiple domain name resolution devices in the domain name resolution device cluster can perform one or more of the following processes: message reception, message resolution, valid token record query, revoked token record query, atomic operation, incremental token generation and sending, and expired token cleanup.

[0229] When multiple DNS resolution devices maintain separate records of valid and revoked tokens, and these devices do not share token records, network forwarding devices can continuously forward packets corresponding to the same sender to the same DNS resolution device based on the sender identifier, destination address, connection information, or consistent hash result. Therefore, the querying and revocation of the same target token can be completed by the same DNS resolution device, thus maintaining the consistency of the token revocation status.

[0230] The number of devices, task allocation method, message forwarding method, and token record management method of the aforementioned domain name resolution device cluster can be configured according to the deployment scale, business traffic, and device processing capacity; this application does not impose any restrictions on these.

[0231] In addition, this application also provides a computer program product. This computer program product may include computer instructions. When the computer program product runs on a domain name resolution device, the computer instructions can cause the domain name resolution device to execute the DNS TFO query message protection method provided in this application embodiment.

[0232] In one possible implementation, computer instructions may cause the domain name resolution device to receive the first message, determine whether the valid token record includes the target token, and if the valid token record includes the target token, determine whether the redeemed token record includes the target token. The computer instructions may also cause the domain name resolution device to allow the first message to the kernel protocol stack of the DNS server if the redeemed token record does not include the target token, and to discard the first message if the target token does not exist in the valid token record or exists in the redeemed token record.

[0233] In another possible embodiment, the computer instructions may also cause the domain name resolution device to perform one or more of the following processes: atomic operation of writing the target token, incremental token generation and sending, expired token cleanup, and discarding tokenless TFO query messages. Specific processing procedures can be found in the relevant descriptions in the foregoing method embodiments.

[0234] In addition, embodiments of this application also provide a computer-readable storage medium. This computer-readable storage medium can store computer instructions. When the computer instructions are executed by the processor of a domain name resolution device, the domain name resolution device can perform the DNS TFO query message protection method provided in embodiments of this application.

[0235] Computer-readable storage media may include read-only memory, random access memory, flash memory, hard disk drive, solid-state drive, magnetic disk, optical disk, or other storage media capable of storing computer instructions. This application does not limit the specific type of computer-readable storage media.

[0236] Based on the above description of the embodiments, those skilled in the art will understand that all or part of the steps in the embodiments of this application can be implemented by software in conjunction with a general-purpose hardware platform, or by dedicated hardware.

[0237] When implemented through a combination of software and a general-purpose hardware platform, the technical solution of this application can be implemented in the form of a computer program product. This computer program product can be stored in a computer-readable storage medium and may include computer instructions for causing a domain name resolution device to execute the various method embodiments of this application. This application does not limit the software implementation, hardware implementation, or combined software and hardware implementation of the DNS TFO query message protection method.

[0238] The above description is merely an exemplary embodiment of this application and is not intended to limit the scope of protection of this application. Any equivalent substitutions, modifications, or improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for protecting against Fast Opening (TFO) query messages in the Domain Name System (DNS) Transmission Control Protocol, characterized in that, The method is applied to a domain name resolution device, and the method includes: Receive the first message, which is a TFO query message carrying the target token and DNS query data; Determine whether the valid token record includes the target token, wherein the valid token record is used to record at least one token registered by the domain name server and that has passed validity verification; If the valid token record includes the target token, it is determined whether the cancelled token record includes the target token. The cancelled token record is used to record the tokens carried in the TFO query message received by the domain name server that belong to the valid token record. If the target token is not included in the revoked token record, the first message is allowed to pass through the kernel protocol stack of the domain name server, and the kernel protocol stack is used to process the first message; If the target token does not exist in the valid token record or exists in the cancelled token record, the first message is discarded.

2. The method according to claim 1, characterized in that, Before allowing the first message to pass through the kernel protocol stack of the domain name server, the process also includes: Based on atomic operations, the target token is written to the revoked token record.

3. The method according to claim 2, characterized in that, The method further includes: If the target token is written to the revoked token record, the first message is allowed to pass through the kernel protocol stack of the domain name server; If the target token is not written to the revoked token record, the first message is discarded.

4. The method according to claim 1, characterized in that, After determining that the valid token record includes the target token, the method further includes: Generate at least one incremental token; Write the at least one incremental token into the valid token record; If the at least one incremental token is written to the valid token record, the at least one incremental token is sent to the sender, and the first message originates from the sender.

5. The method according to claim 4, characterized in that, The method further includes: If the first token in the valid token record becomes invalid, the first token is deleted from the valid token record, and the first token is not recorded in the cancelled token record. Alternatively, if the second token in the valid token record becomes invalid and the second token record is in the cancelled token record, the second token is deleted from the cancelled token record according to the Least Recently Used (LRU) mechanism.

6. The method according to claim 1, characterized in that, The method further includes: If a second message is received, and the second message is a TFO query message and does not carry a token, the second message is discarded.

7. A protection device for the Domain Name System (DNS) Transmission Control Protocol (TCO) Fast Opening (TFO) query message, characterized in that, The device is used in a domain name resolution device, and the device includes: The receiving module receives a first message, which is a TFO query message carrying a target token and DNS query data; The first judgment module determines whether the valid token record includes the target token. The valid token record is used to record at least one token registered by the domain name server and that has passed the validity verification. The second judgment module, when the valid token record includes the target token, determines whether the cancelled token record includes the target token. The cancelled token record is used to record the tokens carried in the TFO query message received by the domain name server that belong to the valid token record. The allow module, if the target token is not included in the verified token record, allows the first message to be passed to the kernel protocol stack of the domain name server, and the kernel protocol stack is used to process the first message; The discarding module discards the first message if the target token does not exist in the valid token record or if the target token exists in the revoked token record.

8. A domain name resolution device, characterized in that, The domain name resolution device includes a processor and a memory; The processor is configured to execute instructions stored in the memory to cause the domain name resolution device to perform the method of any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a domain name resolution device, cause the domain name resolution device to perform the method as described in any one of claims 1 to 6.

10. A computer program product containing instructions, characterized in that, When it is run on a domain name resolution device, it causes the domain name resolution device to perform the method as described in any one of claims 1 to 6.

Images