Method, device and equipment for realizing client source address echo based on DNS protocol

Abstract

This application relates to the field of network communication technology, and provides a method, apparatus, and device for implementing client source address echoing based on the DNS protocol. The method includes: receiving a DNS request message sent by a client; wherein the DNS request message includes a query domain name and a query type; determining whether the query domain name matches a preset source address echoing identifier; if the query domain name matches the source address echoing identifier, extracting the client's source IP address from the network layer header of the DNS request message; encapsulating the source IP address into a DNS response message according to the query type; and returning the DNS response message to the client, so that the client can parse the DNS response message to obtain the source IP address. The embodiments provided in this application can complete the echoing of the client's source address in a single DNS protocol interaction, significantly reducing latency and system resource overhead.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to a method, apparatus and device for implementing client source address echoing based on the DNS protocol. Background Technology

[0002] Currently, obtaining client source IP addresses is widely used in scenarios such as network diagnostics, access control, location services, and security auditing. When a terminal device accesses a public network through a Network Address Translation (NAT) device, its private IP address is mapped to a public IP address, making it impossible for the terminal itself to directly perceive the public IP address and port used for its external communication. To solve this problem, existing technologies typically employ client source address echoing services based on the HTTP protocol. For example, when a user accesses an HTTP application that supports source address echoing, such as ip138.com, the user obtains their public source IP address through the application's response content. This solution requires the client to complete two interactions: DNS domain name resolution and HTTP request / response. Furthermore, the HTTP protocol is based on TCP transmission, requiring a three-way handshake to establish a connection and a four-way handshake to close the connection. The HTTP server also needs to maintain the TCP connection state and handle complex application layer protocols.

[0003] However, the aforementioned existing technologies have significant shortcomings in practical applications. On the one hand, the two interactions between DNS and HTTP, as well as the overhead of TCP connections, result in high overall latency, with the average latency for completing a single source address retrieval process typically exceeding 200 milliseconds. On the other hand, the HTTP server needs to handle complex network and application layer protocols, and due to resource constraints related to connection maintenance and protocol parsing, the concurrent processing capacity of a single general-purpose server is limited, typically only reaching around 50,000 requests per second. With the surge in the number of IoT devices and the increasing real-time requirements of various applications, existing HTTP-based source address echoing solutions are no longer sufficient to meet the business needs of low latency and high concurrency. Summary of the Invention

[0004] This application provides a method, apparatus, and device for echoing client source addresses based on the DNS protocol, which can complete the echoing of client source addresses in a single DNS protocol interaction, significantly reducing latency and system resource overhead.

[0005] In a first aspect, embodiments of this application provide a method for implementing client source address echoing based on the DNS protocol, applied to a DNS server, including: Receive DNS request messages sent by clients; wherein the DNS request message includes the query domain name and query type; Determine whether the queried domain name matches the preset source address echo identifier; If it is determined that the queried domain name matches the source address echo identifier, the source IP address of the client is extracted from the network layer header of the DNS request message; Based on the query type, the source IP address is encapsulated into a DNS response message; The DNS response message is returned to the client so that the client can parse the DNS response message to obtain the source IP address.

[0006] In some embodiments of this application, a method for implementing client source address echoing based on the DNS protocol is also provided. After the step of determining whether the queried domain name matches a preset source address echoing identifier, the method includes: If it is determined that the queried domain name does not match the source address echo identifier, a regular DNS resolution is performed.

[0007] In some embodiments of this application, a method for echoing the client source address based on the DNS protocol is also provided, wherein encapsulating the source IP address into a DNS response message according to the query type includes: When the query type indicates a record type, the first encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message; If the query type is indicated as a text record type, the second encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message.

[0008] In some embodiments of this application, a method for client source address echoing based on the DNS protocol is also provided. When the query type indicates a record type, a first encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message, including: If the query type indicator is a record type, determine whether the version type of the source IP address matches the record type; If the version type of the source IP address matches the record type, the source IP address is encapsulated in binary format into the resource record field of the DNS response message, and the response code of the DNS response message is set to a second preset value.

[0009] In some embodiments of this application, a method for client source address echoing based on the DNS protocol is also provided. After the step of determining whether the version type of the source IP address matches the record type, the method includes: If the version type of the source IP address does not match the record type, a DNS response message without a resource record field is returned, and the response code of the DNS response message is set to a first preset value; wherein, the first preset value indicates that the queried domain name does not exist.

[0010] In some embodiments of this application, a method for client source address echoing based on the DNS protocol is also provided. When the query type indicates a text record type, a second encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message, including: If the query type is indicated as a text record type, a structured text string is constructed based on the version type of the source IP address; The structured text string is encapsulated into the resource record field of the DNS response message, and the response code of the DNS response message is set to the second preset value.

[0011] Secondly, embodiments of this application provide a method for echoing the client's source address based on the DNS protocol, applied to a client, the method comprising: A DNS request message is sent to a DNS server so that the DNS server can determine whether the queried domain name matches a preset source address echo identifier; wherein, the DNS request message includes the queried domain name and the query type; If the DNS server determines that the queried domain name matches the source address echo identifier, the source IP address of the client is extracted from the network layer header of the DNS request message, so that the DNS server encapsulates the source IP address into the DNS response message according to the query type. The DNS response message returned by the DNS server is received, and the DNS response message is parsed to obtain the source IP address.

[0012] In some embodiments of this application, after determining whether the queried domain name matches a preset source address echo identifier through the DNS server, the method includes: If the DNS server determines that the queried domain name does not match the source address echo identifier, a regular DNS resolution is performed.

[0013] In some embodiments of this application, a method for encapsulating the source IP address into a DNS response message according to the query type is also provided, including: When the query type indicates a record type, the first encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message; If the query type is indicated as a text record type, the second encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message.

[0014] In some embodiments of this application, a method is also provided for encapsulating the source IP address into the resource record field of a DNS response message using a first encapsulation strategy when the query type indicates a record type, including: If the query type indicates a record type, the DNS server determines whether the version type of the source IP address matches the record type. If the version type of the source IP address matches the record type, the source IP address is encapsulated in binary format into the resource record field of the DNS response message by the DNS server, and the response code of the DNS response message is set to a second preset value.

[0015] In some embodiments of this application, after determining whether the version type of the source IP address matches the record type via the DNS server, the method further includes: If the DNS server determines that the version type of the source IP address does not match the record type, a DNS response message without a resource record field is returned, and the response code of the DNS response message is set to a first preset value; wherein, the first preset value indicates that the queried domain name does not exist.

[0016] In some embodiments of this application, a method is also provided for encapsulating the source IP address into the resource record field of a DNS response message using a second encapsulation strategy when the query type indication is a text record type, including: If the query type is indicated as a text record type, a structured text string is constructed by the DNS server based on the version type of the source IP address; The DNS server encapsulates the structured text string into the resource record field of the DNS response message and sets the response code of the DNS response message to a second preset value.

[0017] In some embodiments of this application, a method for resolving the DNS response message to obtain the source IP address is also provided, including: If the query type indicates a record type, obtain the response code of the DNS response message; If the response code is the second preset value, extract the IP address data in binary format from the resource record field of the DNS response message; The IP address data is format-validated. If the validation passes, the IP address data is used as the source IP address.

[0018] In some embodiments of this application, a method for resolving the DNS response message to obtain the source IP address is also provided, including: If the query type indicates a text record type, obtain the response code of the DNS response message; If the response code is the second preset value, extract the structured text record content from the resource record field of the DNS response message; The structured text record content is parsed to obtain a structured text string; Extract the address substring from the structured text string and perform format validation on the address substring. If the validation passes, the address substring is used as the source IP address.

[0019] In some embodiments of this application, the method of resolving the DNS response message to obtain the source IP address further includes: If the response code of the DNS response message is the first preset value, the source address echo request is determined to have failed.

[0020] Thirdly, this application provides a device for implementing client source address echoing based on the DNS protocol, applied to a DNS server, the device comprising: The receiving module is used to receive DNS request messages sent by the client; wherein the DNS request message includes the query domain name and query type; The domain name matching module is used to determine whether the queried domain name matches the preset source address echo identifier; The extraction module is used to extract the client's source IP address from the network layer header of the DNS request message when it is determined that the queried domain name matches the source address echo identifier. An encapsulation module is used to encapsulate the source IP address into a DNS response message according to the query type; The resolution module is used to return the DNS response message to the client so that the client can resolve the DNS response message to obtain the source IP address.

[0021] Fourthly, this application provides a device for implementing client source address echoing based on the DNS protocol, applied to a client, the device comprising: The sending module is used to send a DNS request message to the DNS server so that the DNS server can determine whether the queried domain name matches the preset source address echo identifier; wherein, the DNS request message includes the queried domain name and the query type; The determination module is used to extract the client's source IP address from the network layer header of the DNS request message when the DNS server determines that the queried domain name matches the source address echo identifier, so that the DNS server encapsulates the source IP address into the DNS response message according to the query type. The determination module is used to receive the DNS response message returned by the DNS server, and parse the DNS response message to obtain the source IP address.

[0022] Fifthly, embodiments of this application provide an electronic device, including a processor and a memory storing a computer program, wherein the processor executes the program to implement the steps of the method for implementing client source address echoing based on the DNS protocol as described in the first or second aspect.

[0023] In a sixth aspect, embodiments of this application provide a non-transitory computer-readable storage medium storing a computer program thereon, wherein when the computer program is executed by a processor, it implements the steps of the method for implementing client source address echoing based on the DNS protocol as described in the first or second aspect.

[0024] In a seventh aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the method for implementing client source address echoing based on the DNS protocol as described in the first or second aspect.

[0025] This application provides a method, apparatus, and device for client source address echoing based on the DNS protocol. The method involves receiving a DNS request message from a client, wherein the DNS request message includes a query domain name and a query type; determining whether the query domain name matches a preset source address echoing identifier; if the query domain name matches the source address echoing identifier, extracting the client's source IP address from the network layer header of the DNS request message; encapsulating the source IP address into a DNS response message according to the query type; and returning the DNS response message to the client so that the client can parse the DNS response message to obtain the source IP address. This method enables client source address echoing in a single DNS protocol interaction, significantly reducing latency and system resource overhead. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is a schematic diagram of a source address echoing method in the prior art provided in the embodiments of this application; Figure 2 This is one of the flowcharts illustrating the method for implementing client source address echoing based on the DNS protocol provided in this application embodiment; Figure 3 This is one of the timing diagrams of the client source address echoing method based on the DNS protocol provided in the embodiments of this application; Figure 4 This is the second timing diagram of the method for implementing client source address echo based on DNS protocol provided in the embodiments of this application; Figure 5 This is the second flowchart illustrating the method for implementing client source address echoing based on the DNS protocol provided in this application embodiment; Figure 6 This is one of the structural schematic diagrams of the client source address echoing device based on the DNS protocol provided in the embodiments of this application; Figure 7 This is the second schematic diagram of the structure of the client source address echoing device based on the DNS protocol provided in the embodiments of this application; Figure 8 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0029] First, let's analyze some of the terms used in this application: DNS Protocol: The Domain Name System (DNS) protocol is a core service of the Internet. As a distributed database that maps domain names to IP addresses, it makes it easier for people to access the Internet. The DNS protocol runs on top of UDP (User Datagram Protocol) and uses port 53.

[0030] DNS Request Message: A query message sent by a client to a DNS server to request domain name resolution services. This message contains a Question Section, which includes at least the queried domain name (QNAME) and the query type (QTYPE).

[0031] Query Domain (QNAME): The domain name the client wants to query, such as "www.example.com". In this application, the query domain name can be a predefined source address echo identifier.

[0032] Query Type (QTYPE): The type of resource record requested by the client, such as an A record (IPv4 address), an AAAA record (IPv6 address), or a TXT record (text string). In the DNS protocol, the type value for an A record is 1, for an AAAA record it is 28, and for a TXT record it is 16.

[0033] Source IP address: This refers to the network layer IP address of the client that sent the DNS request message, i.e., the source address field in the IP header of the data packet. This address can be an IPv4 address (32-bit binary) or an IPv6 address (128-bit binary).

[0034] Network header: This refers to the header of an IP data packet, which contains crucial information such as the source IP address and destination IP address. DNS servers can extract the client's source IP address by resolving the IP header of the received data packet.

[0035] DNS response message: A message sent by the DNS server in response to a client's request. This message contains an Answer Section, which carries resource record information.

[0036] Resource record field: A field in DNS response messages used to store query results, its standard name is RDATA. Different types of queries (A, AAAA, TXT) store different data formats in the RDATA field.

[0037] Response Code (RCODE): A status code in the DNS response header used to indicate the query result. RCODE=0 indicates success (No Error), and RCODE=3 indicates that the domain name does not exist (Name Error, i.e., NXDOMAIN).

[0038] Regular DNS resolution refers to the standard domain name resolution process, including local cache lookup, recursive lookup of upstream DNS servers, iterative lookup, etc., which ultimately returns the IP address corresponding to the domain name.

[0039] Record type: In the context of this application, record type specifically refers to A record and AAAA record, which are used to return query results of IP address type.

[0040] Text record type: In the context of this application, text record type specifically refers to TXT record, which is used to return formatted text information.

[0041] Binary format: refers to the raw storage form of IP addresses in DNS messages. IPv4 addresses occupy 4 bytes, and IPv6 addresses occupy 16 bytes.

[0042] Structured text string: A text string with a specific format defined in this application, used to carry address information in a TXT record. Its basic format is "ip_version= <address>For example, "ipv4=192.0.2.1;" or "ipv6=2001:db8::1;".

[0043] In the relevant technologies, at least the following technical problems exist: Combination Figure 1 As shown, the processing flow of the existing source address echoing method is as follows: 1. The client sends an HTTP application domain name query request to the DNS server; 2. The DNS server returns the HTTP application server IP address corresponding to the domain name to the client. 3. The client sends an HTTP request to the HTTP application server; 4. The server parses the source IP address information of the HTTP request message; 5. The server returns content containing the source IP address information in the HTTP response; 6. The client parses the response content to obtain the source IP address information.

[0044] The aforementioned prior art has at least the following disadvantages: Disadvantage 1: High overhead and high latency: For existing technical solutions to complete one process, the customer needs to complete two interactions with the DNS and HTTP servers; at the network layer, a TCP three-way handshake is used to establish a connection and a four-way handshake is used to close the connection; the HTTP server needs to maintain the TCP connection and process application layer protocols; the average latency to complete one process is more than 200 milliseconds.

[0045] Disadvantage 2: Limited concurrency capability: Due to the complexity of the HTTP business network layer and application layer, the processing capacity of a single general-purpose server is approximately 50,000 requests per second.

[0046] To address this, this application provides a method for implementing client source address echoing based on the DNS protocol. This method addresses the first drawback by enabling source address echoing during the DNS interaction process, eliminating HTTP interaction redundancy, thereby reducing business interaction overhead and lowering business latency.

[0047] To address the second drawback, the DNS protocol is simple and based on UDP, which consumes fewer resources than the HTTP protocol. Therefore, a single general-purpose server can handle more than 200,000 requests per second, thus significantly improving concurrent processing performance.

[0048] In existing technologies, clients typically need to access a dedicated HTTP service (such as ip138.com) to obtain their public IP address. This process involves two network interactions: DNS resolution and an HTTP request. Furthermore, HTTP, based on the TCP protocol, requires a three-way handshake and a four-way handshake, resulting in high latency (average over 200 milliseconds) and limited concurrency (approximately 50,000 requests / second). In addition, the HTTP server needs to maintain TCP connection states and handle complex application layer protocols, leading to significant system overhead.

[0049] To address the aforementioned technical issues, this application provides a method for implementing client source address echoing based on the DNS protocol. This method involves pre-setting a source address echoing identifier (e.g., "sourceip.query" as a special domain name) on the DNS server side. When a client queries this special domain name, the DNS server no longer performs regular domain name resolution. Instead, it directly extracts the client's source IP address from the network layer header of the received DNS request message and, based on the query type (A / AAAA or TXT), uses an appropriate encapsulation strategy to write the source IP address into the RDATA field of the DNS response message and returns it to the client. The entire address echoing process requires only one DNS request-response interaction. Based on the connectionless UDP protocol, it eliminates the need to maintain connection state, thereby significantly reducing latency and improving concurrent processing capabilities.

[0050] All actions involving the acquisition of signal information or data in this application are carried out in accordance with the relevant data protection laws and policies of the country where the application is located, and with the authorization granted by the owner of the relevant device.

[0051] The following is combined Figures 2-8 This application describes a method, apparatus, and device for implementing client source address echoing based on the DNS protocol. The method involves receiving a DNS request message sent by a client; wherein the DNS request message includes a query domain name and a query type; determining whether the query domain name matches a preset source address echoing identifier; if the query domain name matches the source address echoing identifier, extracting the client's source IP address from the network layer header of the DNS request message; encapsulating the source IP address into a DNS response message according to the query type; and returning the DNS response message to the client, enabling the client to parse the DNS response message and obtain the source IP address. This method enables the echoing of the client's source address in a single DNS protocol interaction, significantly reducing latency and system resource overhead.

[0052] Figure 2 This is one of the flowcharts illustrating a method for implementing client source address echoing based on the DNS protocol provided in this application, such as... Figure 2 As shown, the method may include, but is not limited to, steps S100 to S500: S100, Receive a DNS request message sent by the client; wherein, the DNS request message includes the query domain name and query type; S200, determine whether the queried domain name matches the preset source address echo identifier; S300, if it is determined that the queried domain name matches the source address echo identifier, the source IP address of the client is extracted from the network layer header of the DNS request message; S400, according to the query type, encapsulate the source IP address into a DNS response message; S500, the DNS response message is returned to the client so that the client can parse the DNS response message and obtain the source IP address.

[0053] In step S100 of some embodiments, a DNS request message sent by a client is received; wherein the DNS request message includes a query domain name and a query type.

[0054] In one specific embodiment, combined with Figure 3 and Figure 4 As shown, the DNS server is deployed in the carrier network or corporate intranet, with an IP address of 192.0.2.100, listening on UDP port 53. A client (e.g., a personal computer with an IP address of 203.0.113.25) needs to obtain its source IP address for accessing the public internet. The client constructs a DNS request message according to the standard DNS protocol and sends it to the DNS server 192.0.2.100.

[0055] This DNS request message conforms to RFC 1035, and its Question Section contains two key fields: Query Domain Name (QNAME): Set to the predefined source address echo identifier "sourceip.query"; Query type (QTYPE): Setting it to 1 indicates a request for an A record (IPv4 address).

[0056] After receiving the UDP packet through the socket interface, the DNS server parses the packet content to obtain the complete DNS request message. The technical effect of this step is that the DNS server obtains the query request initiated by the client, providing input data for subsequent processing.

[0057] In step S200 of some embodiments, it is determined whether the queried domain name matches a preset source address echo identifier.

[0058] Understandably, the DNS server resolves the received DNS request message and extracts the value "sourceip.query" from the QNAME field in the question section. The server's local storage (such as a configuration file or in-memory database) pre-defines a list of source address echo identifiers. This list contains one or more special domains, such as "sourceip.query" and "myip.local," which are specifically used to trigger the source address echo function and do not participate in public DNS resolution.

[0059] The DNS server performs an exact string match between the extracted QNAME value "sourceip.query" and the preset source address echo identifier. In this embodiment, the two are completely identical, and the match is successful.

[0060] This step, through the domain name matching mechanism, enables the DNS server to distinguish between regular domain name resolution requests and source address echo requests, thereby entering different processing logics and achieving business traffic diversion.

[0061] In step S300 of some embodiments, if it is determined that the queried domain name matches the source address echo identifier, the source IP address of the client is extracted from the network layer header of the DNS request message.

[0062] Understandably, after determining that the queried domain name matches the source address echo identifier, the DNS server enters the source address echo processing logic. The server obtains the additional information passed by the operating system when receiving the DNS request message and extracts the source IP address field from the network layer header of the IP packet. Since the packet is sent directly from the client to the DNS server, the source IP address in the IP header is the client's real public IP address (or, if the client has passed through a NAT device, the NAT-translated public IP address).

[0063] In this embodiment, the extracted source IP address is 203.0.113.25 (IPv4 address). The DNS server temporarily stores this address in binary form (four bytes: 0xCB 0x00 0x71 0x19).

[0064] In this step, the DNS server obtains the client's public source IP address, which is the core data for the subsequent echo content.

[0065] In step S400 of some embodiments, the source IP address is encapsulated into a DNS response message according to the query type.

[0066] Understandably, the DNS server checks the query type of the client's request. In this embodiment, a QTYPE field value of 1 indicates that the client is requesting an A record. Based on this query type, the server determines the appropriate encapsulation method to write the source IP address into the DNS response message. The server constructs a resource record of type A and writes the binary form of the source IP address into the RDATA field of this resource record.

[0067] In step S500 of some embodiments, the DNS response message is returned to the client so that the client can parse the DNS response message to obtain the source IP address.

[0068] Understandably, after constructing the response message, the DNS server sends it back to the client via UDP. The transaction ID of this response message is the same as the transaction ID of the request message, allowing the client to match the request and response. Upon receiving the response message, the client parses the RDATA field to obtain its source IP address, 203.0.113.25.

[0069] In this embodiment, the client obtains its source IP address with only one DNS query, without the need for additional HTTP interaction, thus achieving low-latency address echoing.

[0070] In some embodiments of this application, after the step of determining whether the queried domain name matches a preset source address echo identifier, the method includes: If it is determined that the queried domain name does not match the source address echo identifier, a regular DNS resolution is performed.

[0071] Understandably, assuming the QNAME field in the DNS request message sent by the client has the value "www.example.com", which is a regular internet domain name and not a preset source address echo identifier (such as "sourceip.query"), the DNS server, when determining whether the queried domain name matches a preset source address echo identifier, will match "www.example.com" against the preset identifier list, and the match will fail.

[0072] In this situation, the DNS server determines that the current request is a regular domain name resolution request, and thus proceeds with the regular DNS resolution process. The regular DNS resolution process includes: first, checking if a resolution record for "www.example.com" exists in the local cache; if the cache is not found, then initiating recursive or iterative queries to the root name server, top-level name server, and authoritative name server according to the DNS configuration; finally obtaining the IP address corresponding to the domain name (e.g., 93.184.216.34); and then constructing a DNS response message containing that IP address and returning it to the client.

[0073] The DNS server in this application supports source address echoing while being fully compatible with standard domain name resolution services. Its processing logic for regular domain name requests is no different from that of ordinary DNS servers, ensuring the universality of the service and its smooth deployment capability.

[0074] In some embodiments of this application, the step of encapsulating the source IP address into a DNS response message according to the query type includes: When the query type indicates a record type, the first encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message; If the query type is indicated as a text record type, the second encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message.

[0075] It is understood that this embodiment refines the "encapsulating the source IP address into the DNS response message according to the query type" and distinguishes between two different query types and their corresponding encapsulation strategies.

[0076] Reference Figure 3 As shown, Scenario 1: The query type indicator is a record type: In this application, the record types specifically refer to A record (QTYPE=1) and AAAA record (QTYPE=28). When a client needs to obtain an IPv4 address, it requests an A record; when it needs to obtain an IPv6 address, it requests an AAAA record.

[0077] In one embodiment, the QTYPE field in the DNS request message sent by the client is set to 1 (A record). After retrieving the source IP address, the DNS server recognizes the query type as a record type and therefore uses the first encapsulation strategy for encapsulation. The core of the first encapsulation strategy is to directly write the source IP address in its original binary format into the RDATA field of the Resource Record in the DNS response message.

[0078] Reference Figure 4 As shown, scenario two: the query type indicator is a text record type. In this application, the text record type specifically refers to a TXT record (QTYPE=16). When a client needs to obtain the source IP address but does not care about the address version or wants to resolve it using a uniform format, it can request a TXT record.

[0079] In another embodiment, the QTYPE field in the DNS request message sent by the client is set to 16 (TXT record). The DNS server recognizes the query type as a text record type and therefore employs a second encapsulation strategy. The core of the second encapsulation strategy is to construct a structured text string based on the version type of the source IP address (e.g., "ipv4=203.0.113.25;" or "ipv6=2001:db8::1;"), and then write this string into the RDATA field of the TXT record.

[0080] This application provides two flexible data encapsulation methods to meet the parsing needs of different clients. The record type method directly returns the binary IP address, resulting in high parsing efficiency; the structured text method returns a highly readable text format, facilitating expansion and compatibility with future needs.

[0081] In some embodiments of this application, when the query type indicates a record type, encapsulating the source IP address into the resource record field of the DNS response message using a first encapsulation strategy includes: If the query type indicator is a record type, determine whether the version type of the source IP address matches the record type; If the version type of the source IP address matches the record type, the source IP address is encapsulated in binary format into the resource record field of the DNS response message, and the response code of the DNS response message is set to a second preset value.

[0082] Understandably, determining whether the version type of the source IP address matches the record type includes: Suppose the client requests an A record (QTYPE=1) expecting to obtain an IPv4 address. The DNS server extracts the source IP address 203.0.113.25 from the network layer header, which is an IPv4 address. The server determines that the version type of the source IP address (IPv4) matches the requested record type (A record).

[0083] If the client requests an AAAA record (QTYPE=28) expecting to obtain an IPv6 address, but the extracted source IP address is an IPv4 address, then it is determined to be a mismatch.

[0084] Furthermore, the source IP address is encapsulated in binary format into a resource record field, and the response code is set to a second preset value, including: If a match is successful, the DNS server constructs a DNS response message. A resource record is added to the AnswerSection, which contains the following fields: NAME: Set to the query domain "sourceip.query"; TYPE: Set to query type A (value is 1); CLASS: Set to IN (Internet class, value is 1); TTL (Time to Live): Setting it to 0 indicates that the record should not be cached by any client or intermediate DNS caching server to ensure that the real-time address can be obtained for each query; RDLENGTH: Setting it to 4 indicates that the length of the RDATA field is 4 bytes; RDATA: Set to the binary form of the source IP address, i.e., 0xCB000719 (four bytes).

[0085] Meanwhile, the DNS server sets the response code RCODE in the response header to a second preset value. In this embodiment, the second preset value is 0, which indicates success (No Error).

[0086] This embodiment employs rigorous type matching verification to ensure that the returned address type matches the type requested by the client, preventing parsing failures due to type errors. Simultaneously, the TTL=0 design guarantees the real-time nature of the address, preventing the client from obtaining expired IP addresses due to caching.

[0087] In some embodiments of this application, after the step of determining whether the version type of the source IP address matches the record type, the method includes: If the version type of the source IP address does not match the record type, a DNS response message without a resource record field is returned, and the response code of the DNS response message is set to a first preset value; wherein, the first preset value indicates that the queried domain name does not exist.

[0088] It is understood that this embodiment provides additional limitations on the type mismatch situation in the above steps and describes the processing logic when the matching fails.

[0089] Suppose a client requests an AAAA record (QTYPE=28) expecting to obtain an IPv6 address. However, the source IP address extracted by the DNS server from the network layer header is 203.0.113.25, which is an IPv4 address. The server determines that the version type of the source IP address (IPv4) does not match the requested record type (AAAA).

[0090] In this case, the DNS server does not construct a resource record containing address information, but instead returns a DNS response message without a resource record field. Simultaneously, the server sets the response code RCODE in the response header to a first preset value, which in this embodiment is 3, i.e., NXDOMAIN (Name Error), indicating that the requested domain name does not exist.

[0091] Upon receiving a response with RCODE=3, the client will know that the source address echo request failed. This embodiment follows the DNS protocol specification, returning a standard error code for requests with mismatched types, preventing the client from misinterpreting incorrect data and ensuring protocol compatibility and correctness.

[0092] In some embodiments of this application, when the query type indicates a text record type, encapsulating the source IP address into the resource record field of the DNS response message using a second encapsulation strategy includes: If the query type is indicated as a text record type, a structured text string is constructed based on the version type of the source IP address; The structured text string is encapsulated into the resource record field of the DNS response message, and the response code of the DNS response message is set to the second preset value.

[0093] It is understood that this embodiment refines the second encapsulation strategy, describing the specific encapsulation steps for the text record type (TXT record): Construct a structured text string based on the version type of the source IP address, specifically including: Assume the source IP address extracted by the DNS server from the network layer header is 203.0.113.25 (IPv4 address). Based on the IPv4 version of this address, the server constructs a structured text string conforming to a predefined format. In this embodiment, the format is "ipv4= <address>;",in <address>Replace with the IP address in dotted decimal notation. The constructed result is: "ipv4=203.0.113.25;".

[0094] If the extracted source IP address is an IPv6 address, such as 2001:db8::1, then the constructed string is: "ipv6=2001:db8::1;".

[0095] This format design has the following characteristics: The version identifier prefix (IPv4 / IPv6) clearly indicates the address type; The semicolon serves as a terminator, facilitating parsing. The format is expandable, and more fields can be added in the future, such as port number and device ID. The format can be expanded to "ipv4=192.0.2.1;port=5060;".

[0096] Furthermore, the structured text string is encapsulated into a resource record field, and the response code is set to a second preset value, including: The DNS server constructs a DNS response message, adding a TXT type resource record to the response portion. This resource record contains the following fields: NAME: Set to the query domain "sourceip.query"; TYPE: Set to TXT (value is 16); CLASS: Set to IN; TTL: Set to 0; RDLENGTH: Set according to the string length. In this embodiment, "ipv4=203.0.113.25;" has a length of 19 bytes. Adding the length bytes of the TXT record, the actual RDLENGTH is 20. RDATA: Following the encoding method of TXT records, first write one byte to represent the string length (19), then write the string content "ipv4=203.0.113.25;".

[0097] At the same time, the DNS server sets the response code RCODE in the response header to 0, indicating success.

[0098] This embodiment uses structured text encapsulation; TXT records provide a unified response format independent of address version, eliminating the need for clients to pre-declare address families and simplifying client-side decision-making. Furthermore, the extensible format reserves space for future feature enhancements.

[0099] Figure 5 This is the second flowchart of a method for implementing client source address echoing based on the DNS protocol provided in this application, as shown below. Figure 5 As shown, the method may include, but is not limited to, steps S510 to S530: S510, a DNS request message is sent to the DNS server so that the DNS server can determine whether the queried domain name matches the preset source address echo identifier; wherein, the DNS request message includes the queried domain name and the query type; S520, if the DNS server determines that the queried domain name matches the source address echo identifier, the source IP address of the client is extracted from the network layer header of the DNS request message, so that the DNS server encapsulates the source IP address into the DNS response message according to the query type; S530, receive the DNS response message returned by the DNS server, and parse the DNS response message to obtain the source IP address.

[0100] Understandably, sending a DNS request message to a DNS server includes: In one specific embodiment, a client (e.g., a smartphone with IP address 203.0.113.25) needs to obtain its own public IP address. The client runs an application that calls the operating system's DNS resolution library functions (such as gethostbyname or getaddrinfo) to construct a DNS request message. In the question portion of this message, QNAME is set to the predefined source address echo identifier "sourceip.query", and QTYPE is set to 1 (A record). The client sends this message to a pre-configured DNS server (IP address 192.0.2.100).

[0101] Furthermore, the DNS server processes the request and returns a response, as illustrated in the following specific implementation: Upon receiving a request, the DNS server executes a client-side source address echoing method based on the DNS protocol, which includes steps such as domain name matching, address extraction, and address encapsulation according to the query type. Finally, it returns a DNS response message. In the client-side description, this step is described as follows: "If the DNS server determines that the queried domain name matches the source address echoing identifier, it extracts the client's source IP address from the network layer header of the DNS request message, so that the DNS server encapsulates the source IP address into the DNS response message according to the query type." The client does not directly execute these steps; instead, it triggers the server to execute them by sending a specific request.

[0102] Furthermore, the DNS response message returned by the DNS server is received and resolved to obtain the source IP address. A specific implementation example is as follows: The client receives the DNS response message returned by the DNS server, then parses the message to extract the source IP address information from the RDATA field of the resource record. The specific resolution process varies depending on the query type. In this embodiment, since the request is for an A record, the client obtains the IPv4 address 203.0.113.25 after successful resolution.

[0103] In this embodiment, the client only needs to initiate a standard DNS query to obtain its own public source IP address. The whole process is transparent to the upper layer application and does not require modification of the operating system's DNS protocol stack.

[0104] In some embodiments of this application, after the step of determining whether the queried domain name matches a preset source address echo identifier through the DNS server, the method includes: If the DNS server determines that the queried domain name does not match the source address echo identifier, a regular DNS resolution is performed.

[0105] Understandably, if the client sends a DNS request message with QNAME set to "www.example.com" (a regular domain name) instead of the default source address echo identifier, the DNS server will determine a mismatch during domain name matching and perform the regular DNS resolution process, returning the IP address of "www.example.com" (e.g., 93.184.216.34). Upon receiving this response, the client processes it according to standard DNS resolution, obtaining the IP address corresponding to the domain name, not its own source IP address.

[0106] In this embodiment, the client uses the same DNS resolution interface, which can obtain the resolution results of ordinary domain names, as well as obtain its own source address when requesting special domain names, without needing to be aware of the differences in the underlying logic.

[0107] In some embodiments of this application, the step of encapsulating the source IP address into a DNS response message according to the query type includes: When the query type indicates a record type, the first encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message; If the query type is indicated as a text record type, the second encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message.

[0108] It is understood that this embodiment is a detailed description of "encapsulating the source IP address into the DNS response message according to the query type", and distinguishes two encapsulation strategies from the client's perspective.

[0109] When the query type is a record type (A / AAAA), the DNS server uses the first encapsulation strategy; when the query type is a text record type (TXT record type), the DNS server uses the second encapsulation strategy. The client indicates the desired encapsulation method through the QTYPE field when sending the request, and the server selects the appropriate strategy accordingly.

[0110] In this embodiment, the client can flexibly choose the desired address return format according to its own capabilities or application requirements.

[0111] In some embodiments of this application, when the query type indicates a record type, encapsulating the source IP address into the resource record field of the DNS response message using a first encapsulation strategy includes: If the query type indicates a record type, the DNS server determines whether the version type of the source IP address matches the record type. If the version type of the source IP address matches the record type, the source IP address is encapsulated in binary format into the resource record field of the DNS response message by the DNS server, and the response code of the DNS response message is set to a second preset value.

[0112] It is understood that this embodiment refines the first encapsulation strategy, describes the server-side type matching judgment in the case of record type, and is presented from the client's perspective.

[0113] Suppose a client requests an A record (QTYPE=1). The DNS server determines that the version type (IPv4) of the source IP address matches the requested record type (A). If the match is successful, the server encapsulates the source IP address in binary format into the resource record field and sets the response code RCODE=0. The client will subsequently obtain this address by parsing the response message.

[0114] In this embodiment, by specifying the record type, the client can ensure that it obtains an IP address consistent with the expected version.

[0115] In some embodiments of this application, after the step of determining whether the version type of the source IP address matches the record type through the DNS server, the method includes: If the DNS server determines that the version type of the source IP address does not match the record type, a DNS response message without a resource record field is returned, and the response code of the DNS response message is set to a first preset value; wherein, the first preset value indicates that the queried domain name does not exist.

[0116] It is understood that this embodiment provides additional limitations for cases of type mismatch.

[0117] Suppose a client requests an AAAA record (QTYPE=28), but the client's network environment is a single-stack IPv4 network, and its public IP address is an IPv4 address. When the DNS server performs type matching, it determines a mismatch and returns a DNS response message without the resource record, setting the response code RCODE=3 (NXDOMAIN). The client will receive a response with RCODE=3.

[0118] In this embodiment, when the address type requested by the client does not match the actual network environment, the server notifies the client through a standard error code to prevent the client from mistakenly believing that an address exists but the resolution fails.

[0119] In some embodiments of this application, when the query type indicates a text record type, encapsulating the source IP address into the resource record field of the DNS response message using a second encapsulation strategy includes: If the query type is indicated as a text record type, a structured text string is constructed by the DNS server based on the version type of the source IP address; The DNS server encapsulates the structured text string into the resource record field of the DNS response message and sets the response code of the DNS response message to a second preset value.

[0120] It is understood that this embodiment refines the second encapsulation strategy, describes the server-side construction process in the case of text record type, and is presented from the client's perspective.

[0121] Suppose a client requests a TXT record (QTYPE=16). The DNS server constructs a structured text string (e.g., "ipv4=203.0.113.25;") based on the version type of the source IP address, encapsulates this string in the RDATA field of the TXT record, and sets the response code RCODE=0. The client will then obtain the address by parsing the TXT content.

[0122] In this embodiment, the client can obtain address information with a uniform format through a single TXT query, without needing to distinguish between IPv4 and IPv6.

[0123] In some embodiments of this application, resolving the DNS response message to obtain the source IP address includes: If the query type indicates a record type, obtain the response code of the DNS response message; If the response code is the second preset value, extract the IP address data in binary format from the resource record field of the DNS response message; The IP address data is format-validated. If the validation passes, the IP address data is used as the source IP address.

[0124] It is understood that this embodiment elaborates on "resolving DNS response messages to obtain the source IP address" and describes the client resolution process in the case of record type.

[0125] Assume the client sends an A record request. After receiving the DNS response message, the client executes the following sub-steps: Sub-step 1: Obtain the response code of the DNS response message: The client parses the DNS response header and extracts the value of the RCODE field. In this example, if the request is successful, RCODE = 0.

[0126] Sub-step 2: Extract IP address data in binary format from the resource record fields: Since RCODE=0, the client continues parsing the Answer Section. It confirms that the TYPE field of the resource record is A (value 1), and then reads 4 bytes of binary data from the RDATA field. This data is the binary form of the source IP address encapsulated by the server, for example, 0xCB000719.

[0127] Sub-step 3: Validate the format of the IP address data: The client performs validity checks on the extracted binary data, such as verifying whether it is a valid IPv4 address (excluding special addresses such as 0.0.0.0 and broadcast addresses). If the verification is successful, the binary data is converted into the dotted decimal string "203.0.113.25" as the final source IP address.

[0128] In this embodiment, the client resolves the A record response according to the DNS standard protocol, obtains and verifies the source IP address, and ensures the legitimacy of the address.

[0129] In some embodiments of this application, resolving the DNS response message to obtain the source IP address includes: If the query type indicates a text record type, obtain the response code of the DNS response message; If the response code is the second preset value, extract the structured text record content from the resource record field of the DNS response message; The structured text record content is parsed to obtain a structured text string; Extract the address substring from the structured text string and perform format validation on the address substring. If the validation passes, the address substring is used as the source IP address.

[0130] It is understood that this embodiment refines the process of "resolving DNS response messages to obtain the source IP address" and describes the client resolution process in the case of text record type (TXT record).

[0131] Assume the client sends a TXT record request. After receiving the DNS response message, the client executes the following sub-steps: Sub-step 1: Obtain the response code of the DNS response message: The RCODE field is parsed. In this example, RCODE=0 indicates success.

[0132] Sub-step 2: Extract structured text record content from resource record fields: The client parses the response section, confirms that the TYPE field of the resource record is TXT (value 16), and then reads the TXT record content from the RDATA field. According to the TXT record format, it first reads one byte to represent the string length, and then reads the string data of the corresponding length. In this embodiment, the read string is "ipv4=203.0.113.25;".

[0133] Sub-step 3: Parse the structured text record content to obtain the structured text string: The client has obtained the complete string "ipv4=203.0.113.25;". This string is the structured text string constructed by the server.

[0134] Sub-step 4: Extract the address substring from the structured text string and perform format validation: The client parses the string according to a predefined format: Verify that the string begins with "ipv4=" or "ipv6=" and ends with a semicolon. In this embodiment, the prefix is ​​"ipv4=" and the string ends with a semicolon, which is the correct format.

[0135] Extract the substring between the equals sign and the semicolon to get "203.0.113.25".

[0136] Perform IPv4 address format verification on this substring to confirm whether it is a valid dotted decimal IPv4 address. Verification passed.

[0137] After successful verification, the client will use "203.0.113.25" as the final source IP address.

[0138] If the string prefix is ​​"ipv6=", then verify whether the extracted substring is a valid IPv6 address format.

[0139] In this embodiment, the client can process IPv4 and IPv6 addresses in a unified manner by parsing the structured content of the TXT record, while format verification ensures the correctness of the data.

[0140] In some embodiments of this application, resolving the DNS response message to obtain the source IP address further includes: If the response code of the DNS response message is the first preset value, the source address echo request is determined to have failed.

[0141] Understandably, the parsing process has been supplemented with a description of how to handle error situations.

[0142] Suppose the client sends a request for an AAAA record (requesting an IPv6 address), but the client's actual IP address is an IPv4 address. The DNS server returns a response with RCODE=3 (NXDOMAIN).

[0143] Upon receiving the response, the client parses the RCODE field and finds its value to be 3 (the first preset value). According to the DNS protocol specification, RCODE=3 indicates that the requested domain name does not exist. Based on this, the client determines that the source address echo request failed and will not attempt to extract address data from the response message. The client can choose to retry, use other methods to obtain the address, or report the error to the user, depending on application requirements.

[0144] In this embodiment, the client can accurately determine the failure status of the address echo request by recognizing the standard error code, avoiding the use of invalid or incorrect address data and ensuring the correctness of the business logic.

[0145] In other embodiments of this application, the "preset source address echo flag" is a key triggering mechanism. In actual deployment, this flag can be flexibly configured. For example, it can be configured as any string that does not conflict with public domain names, such as "sourceip.query", "myip.local", or "whoami.example.com".

[0146] In a preferred embodiment, it is recommended to use a domain name with a top-level domain of ".local" or ".query" because these domain names are usually not within the scope of public DNS resolution, thus avoiding confusion with normal domain names.

[0147] DNS servers can load the source address echo list through configuration files (such as named.conf), databases, or environment variables.

[0148] In other embodiments of this application, the method for extracting the network layer header is as follows: Extracting the source IP address from the network layer header of the DNS request message is a fundamental step in this application. In practical implementations, when a DNS server uses a socket to receive UDP packets, the source IP address can be obtained in the following ways: In a DNS server written in C, the source address structure (struct sockaddr) is obtained through the second parameter of the recvfrom function. In a server written in Java, the address is obtained through the getAddress() method of the DatagramPacket class; In a server written in Go, the UDPAddr is obtained through the UDPConn.ReadFromUDP method.

[0149] Regardless of the programming language or framework used, the operating system layer will pass the source address information of the IP header to the application layer when receiving data packets.

[0150] In other embodiments of this application, the TTL field of the resource record is set to 0 when constructing the DNS response. TTL (Time to Live) is the time-to-live field in the DNS protocol, representing the maximum time (in seconds) that the record can be cached. Setting the TTL to 0 has the following technical significance: This mandates that all DNS caching servers (including client-side local DNS caches) that receive this response must not cache the record. Ensure that the DNS server retrieves the latest source IP address every time a client queries the source address; To prevent cached addresses from becoming invalid due to NAT device address reassignment or changes in the client's network environment.

[0151] In some other embodiments of this application, if a mobile device switches between WiFi and cellular networks, its public IP address will change. The TTL=0 mechanism ensures that the latest address after the switch can be obtained with each query.

[0152] In other embodiments of this application, the TXT record structured format "ip_version=" defined in this application <address>The semicolon (;) indicates good scalability. In one extended implementation, multiple fields can be returned in the same TXT record, such as both the IP address and port number. In NAT traversal scenarios, clients need not only the public IP address but also the public port number. In this case, the DNS server can construct the following structured text string: Text"ipv4=203.0.113.25;port=12345;" During client-side parsing, each field is first separated by a semicolon, and then the key-value pairs of each field are parsed separately. This format maintains backward compatibility (existing clients can still extract the IPv4 field) while also providing extensibility.

[0153] In other embodiments of this application, in a dual-stack IPv4 and IPv6 network environment, a client may simultaneously possess both IPv4 and IPv6 addresses. Embodiments of this application can perfectly support dual-stack scenarios: If a client requests an A record, the DNS server returns its IPv4 address (assuming it is the public IPv4 address behind NAT). If a client requests an AAAA record, the DNS server returns its IPv6 address; If the client requests a TXT record, the DNS server returns the corresponding structured string based on the version type of its source IP address. If the client accesses the DNS server via IPv6, it returns "ipv6= <address>If accessed via IPv4, it will return "ipv4= <address>;".

[0154] This design allows clients to choose to obtain a specific type of address based on their own needs, or to uniformly obtain the address type currently being accessed through a TXT record.

[0155] To further illustrate the practicality of this application, several typical application scenarios are provided below: Scenario 1: IoT Device Registration An IoT device (such as a smart camera) is deployed in a user's home and accesses the internet through a NAT device. Upon initial startup, the device needs to register its information, including its public IP address, with a cloud platform. Traditionally, this requires the device to first obtain an IP address via DHCP, then access an HTTP service (such as ip138.com) to obtain a public IP address, and finally register with the cloud platform. With this application, the device only needs to query the "sourceip.query" TXT record from the DNS server to obtain its structured text public IP address in the DNS response, significantly reducing registration latency.

[0156] Scenario 2: Dynamic IP Management on a Container Platform In Kubernetes container platforms, Pods may frequently restart and migrate between different nodes, causing their public IP addresses to change dynamically. The platform needs a mechanism to allow Pods to quickly obtain their current public IP address upon startup for service registration. By performing a single DNS lookup (A record request with the domain name echoed by a predefined source address) within the Pod's initialization container, the public IP address can be obtained within milliseconds, enabling rapid service discovery.

[0157] Scenario 3: Network diagnostics for mobile applications: A mobile app needs to diagnose a user's current network egress IP (distinguishing between IPv4 and IPv6) to determine if the user is in a dual-stack network environment. The app can send A record and AAAA record queries in parallel and determine the following based on the received responses: if only a successful A record response is received, the user primarily uses IPv4; if only a successful AAAA record response is received, the user primarily uses IPv6; if both responses are received, the user is in a dual-stack network environment. This diagnostic method requires only one DNS interaction, minimizing the impact on user experience.

[0158] The following describes the client source address echoing device based on the DNS protocol for use in a DNS server provided in this application. The client source address echoing device based on the DNS protocol for use in a DNS server described below can be referred to in correspondence with the client source address echoing method based on the DNS protocol for use in a DNS server described above.

[0159] like Figure 6 The diagram shown is a structural schematic of a client source address echoing device based on the DNS protocol for use in a DNS server, provided in this application. The device includes the following modules: The receiving module 610 is used to receive a DNS request message sent by the client; wherein the DNS request message includes a query domain name and a query type; The domain name matching module 620 is used to determine whether the queried domain name matches the preset source address echo identifier; Extraction module 630 is used to extract the source IP address of the client from the network layer header of the DNS request message when it is determined that the queried domain name matches the source address echo identifier. Encapsulation module 640 is used to encapsulate the source IP address into a DNS response message according to the query type; The resolution module 650 is used to return the DNS response message to the client so that the client can resolve the DNS response message and obtain the source IP address.

[0160] The following describes the client source address echoing device based on the DNS protocol for client applications provided in this application. The client source address echoing device based on the DNS protocol for client applications described below can be referred to in correspondence with the client source address echoing method based on the DNS protocol for client applications described above.

[0161] like Figure 7 The diagram shown is a structural schematic of a client-side source address echoing device based on the DNS protocol, provided in this application. The device includes: The sending module 710 is used to send a DNS request message to a DNS server so that the DNS server can determine whether the queried domain name matches a preset source address echo identifier; wherein, the DNS request message includes the queried domain name and the query type; The determination module 720 is used to extract the client's source IP address from the network layer header of the DNS request message when the DNS server determines that the queried domain name matches the source address echo identifier, so that the DNS server encapsulates the source IP address into the DNS response message according to the query type. The determining module 730 is used to receive the DNS response message returned by the DNS server, and parse the DNS response message to obtain the source IP address.

[0162] Figure 8 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 8 As shown, the electronic device may include a processor 810, a communications interface 820, a memory 830, and a communication bus 840, wherein the processor 810, communications interface 820, and memory 830 communicate with each other via the communication bus 840. The processor 810 can call logical instructions in the memory 830 to execute a client source address echoing method based on the DNS protocol. This method includes: receiving a DNS request message sent by a client; wherein the DNS request message includes a query domain name and a query type; determining whether the query domain name matches a preset source address echoing identifier; if the query domain name matches the source address echoing identifier, extracting the client's source IP address from the network layer header of the DNS request message; encapsulating the source IP address into a DNS response message according to the query type; and returning the DNS response message to the client so that the client can parse the DNS response message to obtain the source IP address.

[0163] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0164] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the client source address echoing method based on the DNS protocol provided by the above methods. The method includes: receiving a DNS request message sent by a client; wherein the DNS request message includes a query domain name and a query type; determining whether the query domain name matches a preset source address echoing identifier; if the query domain name matches the source address echoing identifier, extracting the client's source IP address from the network layer header of the DNS request message; encapsulating the source IP address into a DNS response message according to the query type; and returning the DNS response message to the client so that the client can parse the DNS response message to obtain the source IP address.

[0165] In another aspect, this application also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements a method for implementing client source address echoing based on the DNS protocol provided by the above methods. The method includes: receiving a DNS request message sent by a client; wherein the DNS request message includes a query domain name and a query type; determining whether the query domain name matches a preset source address echoing identifier; if the query domain name matches the source address echoing identifier, extracting the client's source IP address from the network layer header of the DNS request message; encapsulating the source IP address into a DNS response message according to the query type; and returning the DNS response message to the client so that the client can parse the DNS response message to obtain the source IP address.

[0166] The processor-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

[0167] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0168] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0169] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.< / address> < / address> < / address> < / address> < / address> < / address>

Claims

1. A method for implementing a client source address echo based on a DNS protocol, characterized in that, Applied to a DNS server, the method includes: Receive DNS request messages sent by clients; wherein the DNS request message includes the query domain name and query type; Determine whether the queried domain name matches the preset source address echo identifier; If it is determined that the queried domain name matches the source address echo identifier, the source IP address of the client is extracted from the network layer header of the DNS request message; Based on the query type, the source IP address is encapsulated into a DNS response message; The DNS response message is returned to the client so that the client can parse the DNS response message to obtain the source IP address.

2. The method for implementing client source address echo based on DNS protocol according to claim 1, characterized in that, After the step of determining whether the queried domain name matches the preset source address echo identifier, the method includes: If it is determined that the queried domain name does not match the source address echo identifier, perform regular DNS resolution.

3. The method of claim 1, wherein the method is implemented in a DNS protocol. The step of encapsulating the source IP address into a DNS response message according to the query type includes: When the query type indicates a record type, the first encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message; If the query type is indicated as a text record type, the second encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message.

4. The method for implementing client source address echoing based on DNS protocol according to claim 3, characterized in that, When the query type indicates a record type, the first encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message, including: If the query type indicator is a record type, determine whether the version type of the source IP address matches the record type; If the version type of the source IP address matches the record type, the source IP address is encapsulated in binary format into the resource record field of the DNS response message, and the response code of the DNS response message is set to a second preset value.

5. The method of claim 4, wherein the DNS protocol is used to implement the client source address echo. After the step of determining whether the version type of the source IP address matches the record type, the method includes: If the version type of the source IP address does not match the record type, a DNS response message without a resource record field is returned, and the response code of the DNS response message is set to a first preset value; wherein, the first preset value indicates that the queried domain name does not exist.

6. The method of claim 3, wherein the DNS protocol is used to implement the client source address echo. When the query type indicates a text record type, the second encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message, including: If the query type is indicated as a text record type, a structured text string is constructed based on the version type of the source IP address; The structured text string is encapsulated into the resource record field of the DNS response message, and the response code of the DNS response message is set to the second preset value.

7. A method for implementing a client source address echo based on a DNS protocol, characterized in that, Applied to a client, the method includes: A DNS request message is sent to a DNS server so that the DNS server can determine whether the queried domain name matches a preset source address echo identifier; wherein, the DNS request message includes the queried domain name and the query type; If the DNS server determines that the queried domain name matches the source address echo identifier, the source IP address of the client is extracted from the network layer header of the DNS request message, so that the DNS server encapsulates the source IP address into the DNS response message according to the query type. The DNS response message returned by the DNS server is received, and the DNS response message is parsed to obtain the source IP address.

8. The method for implementing client source address echoing based on DNS protocol according to claim 7, characterized in that, After the step of determining whether the queried domain name matches the preset source address echo identifier through the DNS server, the method includes: If the DNS server determines that the queried domain name does not match the source address echo identifier, a regular DNS resolution is performed.

9. The method of claim 7, wherein the DNS protocol is used to implement the client source address echo. The step of encapsulating the source IP address into a DNS response message according to the query type includes: When the query type indicates a record type, the first encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message; If the query type is indicated as a text record type, the second encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message.

10. The method of claim 9, wherein the method is implemented by a DNS client. When the query type indicates a record type, the first encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message, including: If the query type indicates a record type, the DNS server determines whether the version type of the source IP address matches the record type. If the version type of the source IP address matches the record type, the source IP address is encapsulated in binary format into the resource record field of the DNS response message by the DNS server, and the response code of the DNS response message is set to a second preset value.

11. The method of claim 10, wherein the DNS protocol is used to implement the client source address echo. After the step of determining whether the version type of the source IP address matches the record type through the DNS server, the method includes: If the DNS server determines that the version type of the source IP address does not match the record type, a DNS response message without a resource record field is returned, and the response code of the DNS response message is set to a first preset value; wherein, the first preset value indicates that the queried domain name does not exist.

12. The method of claim 9, wherein the DNS protocol is used to implement the client source address echo. When the query type indicates a text record type, the second encapsulation strategy is used to encapsulate the source IP address into the resource record field of the DNS response message, including: If the query type is indicated as a text record type, a structured text string is constructed by the DNS server based on the version type of the source IP address; The DNS server encapsulates the structured text string into the resource record field of the DNS response message and sets the response code of the DNS response message to a second preset value.

13. The method of claim 10, wherein the DNS protocol is used to implement the client source address echo. The process of resolving the DNS response message to obtain the source IP address includes: If the query type indicates a record type, obtain the response code of the DNS response message; If the response code is the second preset value, extract the IP address data in binary format from the resource record field of the DNS response message; The IP address data is format-validated. If the validation passes, the IP address data is used as the source IP address.

14. The method for implementing client source address echoing based on DNS protocol according to claim 12, characterized in that, The process of resolving the DNS response message to obtain the source IP address includes: If the query type indicates a text record type, obtain the response code of the DNS response message; If the response code is the second preset value, extract the structured text record content from the resource record field of the DNS response message; The structured text record content is parsed to obtain a structured text string; Extract the address substring from the structured text string and perform format validation on the address substring. If the validation passes, the address substring is used as the source IP address.

15. The method for implementing client source address echoing based on DNS protocol according to claim 11, characterized in that, The step of resolving the DNS response message to obtain the source IP address further includes: If the response code of the DNS response message is the first preset value, the source address echo request is determined to have failed.

16. A device for echoing the client's source address based on the DNS protocol, characterized in that, Applied to a DNS server, the apparatus includes: A receiving module is used to receive DNS request messages sent by a client; wherein the DNS request message includes a query domain name and a query type; The domain name matching module is used to determine whether the queried domain name matches the preset source address echo identifier; The extraction module is used to extract the client's source IP address from the network layer header of the DNS request message when it is determined that the queried domain name matches the source address echo identifier. An encapsulation module is used to encapsulate the source IP address into a DNS response message according to the query type; The resolution module is used to return the DNS response message to the client so that the client can resolve the DNS response message and obtain the source IP address.

17. A device for echoing the client's source address based on the DNS protocol, characterized in that, Applied to a client, the device includes: The sending module is used to send a DNS request message to the DNS server so that the DNS server can determine whether the queried domain name matches the preset source address echo identifier; wherein, the DNS request message includes the queried domain name and the query type; The determination module is used to extract the client's source IP address from the network layer header of the DNS request message when the DNS server determines that the queried domain name matches the source address echo identifier, so that the DNS server encapsulates the source IP address into the DNS response message according to the query type. The determination module is used to receive the DNS response message returned by the DNS server, and parse the DNS response message to obtain the source IP address.

18. An electronic device comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the client source address echoing method based on the DNS protocol as described in any one of claims 1 to 6, or implements the client source address echoing method based on the DNS protocol as described in any one of claims 7 to 15.

19. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the method for echoing the client source address based on the DNS protocol as described in any one of claims 1 to 6, or implements the method for echoing the client source address based on the DNS protocol as described in any one of claims 7 to 15.

20. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the method for echoing the client source address based on the DNS protocol as described in any one of claims 1 to 6, or implements the method for echoing the client source address based on the DNS protocol as described in any one of claims 7 to 15.

Images