Distributed DNS test method and device, computer equipment and storage medium

Abstract

The invention relates to a distributed DNS test method and device, computer equipment and a storage medium. The method comprises the steps of obtaining test demand data, configuring a plurality of agent nodes located in different geographic areas according to the test demand data, creating a test task, and distributing the test task to the plurality of agent nodes, the test task comprising a to-be-tested domain name, an expected analysis result and a query parameter, controlling each agent node to initiate a DNS query request to the to-be-tested DNS system based on the to-be-tested domain name and the query parameter, receive a query result returned by each agent node, verify whether a domain name resolution behavior of the to-be-tested DNS system meets a preset service specification requirement based on the query result and an expected resolution result fed back by each agent node, obtain a verification result, and send the verification result to the to-be-tested DNS system. And generating a test report according to the verification result. By adopting the method, the accuracy and efficiency of DNS system testing can be effectively improved.

Description

Technical Field

[0001] This application relates to the field of network testing technology, and in particular to a distributed DNS testing method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] DNS (Domain Name Server) services play a crucial role in building network infrastructure, responsible for resolving human-readable domain names into computer-readable IP addresses. While DNS services are essential, they can also fail to resolve domain names due to misconfiguration, service outages, or security vulnerabilities. Therefore, testing DNS services is necessary.

[0003] Currently, most existing testing methods for DNS services involve sending a large number of requests using multiple threads to test DNS. However, this method is easily affected by factors such as network fluctuations, making it difficult to obtain accurate resolution results and resulting in low testing efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide a distributed DNS testing method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve testing efficiency and accuracy in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a distributed DNS testing method, including:

[0006] Obtain test requirement data, and configure multiple proxy nodes located in different geographical regions based on the test requirement data;

[0007] A test task is created and distributed to multiple proxy nodes, wherein the test task includes the domain name to be tested, the expected resolution result, and query parameters;

[0008] The system controls each of the proxy nodes to initiate a DNS query request to the DNS system under test based on the domain name to be tested and the query parameters, and receives the query results returned by each of the proxy nodes.

[0009] Based on the query results and expected resolution results fed back by each of the proxy nodes, the domain name resolution behavior of the DNS system under test is verified to meet the preset service specification requirements, and the verification results are obtained.

[0010] A test report is generated based on the verification results.

[0011] In one embodiment, before acquiring the test requirement data, the method further includes:

[0012] Deploy the DNS system under test in the test environment, and distribute the overlay file and IP attribution file to the DNS system under test;

[0013] The control of each of the agent nodes to initiate a DNS query request to the DNS system under test based on the domain name to be tested and the query parameters includes:

[0014] Once it is confirmed that the DNS system under test has loaded the overlay file and the IP attribution file and is in normal operating condition, each of the proxy nodes is controlled to initiate a DNS query request to the DNS system under test based on the domain name under test and the query parameters.

[0015] The overlay file defines the expected resolution results of the target domain name in different geographical regions, and the IP attribution file defines the mapping relationship between IP address ranges and geographical regions.

[0016] In one embodiment, verifying whether the domain name resolution behavior of the DNS system under test meets preset service specification requirements based on the query results returned by each of the proxy nodes and the expected resolution results includes:

[0017] Based on the query results fed back by each of the agent nodes and the expected resolution results, verify whether the DNS system under test meets the preset service specification requirements in terms of the accuracy of the resolved content, the resolution ratio strategy and / or response performance.

[0018] In one embodiment, the query results returned by the proxy nodes include the responding IP address and response time. Verifying whether the DNS system under test meets preset service specification requirements in terms of the accuracy of the resolved content, the resolution ratio strategy, and / or response performance, based on the query results returned by each proxy node and the expected resolution results, includes:

[0019] The response IP address is compared with the expected resolution result, and the accuracy of the resolution content of the DNS system under test is verified based on the comparison result.

[0020] Count the frequency of each second-level domain name in all query results to verify whether the DNS system's resolution ratio strategy conforms to the preset resolution ratio relationship;

[0021] The response performance of the DNS system under test is evaluated based on the response time.

[0022] In one embodiment, the method further includes:

[0023] Enable a security protection policy in the DNS system under test. The security protection policy includes at least one of the following: request frequency limiting policy, DNS query rate control policy, and custom firewall rules.

[0024] In one embodiment, the query parameters include a DNS query type, the query result includes a DNS response packet, and the method further includes:

[0025] When the DNS query type is ANY, determine the size ratio of the request packet sent by the proxy node to the DNS response packet;

[0026] Based on the aforementioned size ratio, verify whether there is a risk of DNS amplification attacks.

[0027] Secondly, this application also provides a distributed DNS testing method apparatus, comprising:

[0028] The data acquisition module is used to acquire test requirement data and configure multiple proxy nodes located in different geographical regions based on the test requirement data.

[0029] The data distribution module is used to create test tasks and distribute the test tasks to multiple proxy nodes, wherein the test task includes the domain name to be tested, the expected resolution result, and query parameters;

[0030] The control module is used to control each of the proxy nodes to initiate a DNS query request to the DNS system under test based on the domain name to be tested and the query parameters, and to receive the query results returned by each of the proxy nodes;

[0031] The data verification module is used to verify whether the domain name resolution behavior of the DNS system under test meets the preset service specification requirements based on the query results fed back by each of the proxy nodes and the expected resolution results, and to obtain the verification results.

[0032] The report generation module is used to generate a test report based on the verification results.

[0033] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement any of the steps in the above-described distributed DNS testing method embodiments.

[0034] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in any of the above-described embodiments of the distributed DNS testing method.

[0035] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps in any of the above-described distributed DNS testing method embodiments.

[0036] The aforementioned distributed DNS testing method, apparatus, computer equipment, computer-readable storage media, and computer program products acquire test requirement data and configure proxy nodes distributed across different geographical regions accordingly. This achieves a high degree of realism in replicating real user access scenarios, improving the global coverage and environmental diversity of the test. By creating test tasks containing the domain name to be tested, expected resolution results, and query parameters, and distributing them to each proxy node, the controllability of the test behavior and the consistency of the verification benchmark are ensured. Each proxy node initiates a real DNS query request to the DNS system under test based on the task and returns the query results. By comparing the actual response with the expected results, the system can objectively verify whether the DNS system meets the preset service specifications in terms of resolution accuracy, zone policy execution, proportional allocation, and performance. Finally, a structured test report is automatically generated. The entire solution not only significantly improves the realism, coverage, and accuracy of DNS testing, but also effectively reduces the adverse effects of traditional large-volume local requests being susceptible to network interference, unable to simulate regional differences, and having large proportional verification errors, achieving more accurate and efficient testing. Attached Figure Description

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

[0038] Figure 1 This is a diagram illustrating the application environment of a distributed DNS testing method in one embodiment.

[0039] Figure 2 This is a flowchart illustrating a distributed DNS testing method in one embodiment;

[0040] Figure 3 This is a flowchart illustrating a distributed DNS testing method in another embodiment;

[0041] Figure 4 This is a flowchart illustrating a distributed DNS testing method in yet another embodiment;

[0042] Figure 5 This is a detailed flowchart of a distributed DNS testing method in one embodiment;

[0043] Figure 6This is a detailed flowchart of a distributed DNS testing method in yet another embodiment;

[0044] Figure 7 This is a detailed flowchart of a distributed DNS testing method in another embodiment;

[0045] Figure 8 This is a structural block diagram of a distributed DNS testing device in one embodiment;

[0046] Figure 9 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0048] It should be noted that the terms "comprising" and "having," and any variations thereof, as used in this application, are intended to cover non-exclusive inclusion. The term "multiple" as used in this application refers to two or more. The term "and / or" as used in this application refers to one of the solutions, or any combination of multiple solutions.

[0049] The distributed DNS testing method provided in this application embodiment can be applied to, for example, Figure 1 The application environment is shown. Taking a proxy node as an example, the central control node 102 communicates with multiple proxy servers (hereinafter referred to as servers) 104 via a network. A data storage system can store the data that the servers 104 need to process. The data storage system can be integrated onto the servers 104, or it can be placed on the cloud or other network servers.

[0050] Specifically, the central control node 102 can obtain test requirement data, configure multiple proxy servers 104 located in different geographical regions based on the test requirement data, then create test tasks and distribute the test tasks to multiple proxy servers 104. The test tasks include the domain name to be tested, the expected resolution result, and query parameters. The central control node 102 controls each proxy server 104 to initiate a DNS query request to the DNS system under test based on the domain name to be tested and the query parameters, receives the query results returned by each proxy server 104, and verifies whether the domain name resolution behavior of the DNS system under test meets the preset service specification requirements based on the query results and expected resolution results returned by each proxy server 104, obtaining the verification result. Finally, a test report is generated based on the verification result.

[0051] The central control node 102 can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server providing cloud computing services. The proxy server 104 can be a standalone physical server or a virtual server.

[0052] In one exemplary embodiment, such as Figure 2 As shown, a distributed DNS testing method is provided, which is applied to... Figure 1 Taking the central control node 102 as an example, the explanation includes the following steps 202 to 210. Wherein:

[0053] Step 202: Obtain test requirement data and configure multiple proxy nodes located in different geographical regions based on the test requirement data.

[0054] Test requirement data is a set of input information used to define the goals and scope of this DNS test, including high-level instructions such as the geographical areas to be covered, network environment types, and test granularity; and a set of information including the geographical areas to be covered, carrier network types, test scale, and security test level. Proxy nodes are intermediate nodes deployed in different geographical locations that can initiate DNS requests on behalf of a specific network environment. Specifically, a proxy node is a node that, on behalf of a specific geographical area or network environment, initiates a real DNS query request to the DNS system under test as a client and sends the result back to the central control node. These nodes include, but are not limited to, proxy servers, lightweight virtual machines, or containers.

[0055] In practice, testers can pre-deploy the DNS system and then upload test requirement data to the central control node. The central control node parses the test requirement data to identify the geographical regions to be covered in this test (such as region, province, operator network type, etc.). For example, the test requirements may specify "coverage of five key regions: East China, Eastern North America, Western Europe, and Western South America" ​​to achieve geographical diversity and broad coverage for DNS system testing.

[0056] Next, the central control node accesses the proxy node resource pool it maintains or connects to. Each proxy node in this resource pool is associated with metadata about its deployment location (such as latitude and longitude, administrative division code, operator tag, etc.). Based on the extracted regional requirements, the central control node filters out a list of candidate proxy nodes matching geographical location and network attributes. Then, based on this list of candidate proxy nodes, the central control node selects several proxy nodes for the corresponding geographical region according to preset strategies (such as proximity priority, load balancing, historical stability, etc.). It then sends configuration instructions to these proxies, including specifying their role in this test (e.g., "representing the dx_fujian region"), issuing communication credentials and task receiving addresses, and starting their DNS query proxy service module. At this point, the selected proxy nodes have completed logical binding and become valid execution nodes for this test. The central control node assigns a unique identifier to each activated proxy node and establishes a secure and reliable two-way communication link (such as a message channel based on HTTPS or MQTT) for subsequent task distribution and result feedback, ensuring the continuity of control and feedback throughout the entire test process.

[0057] Step 204: Create a test task and distribute the test task to multiple proxy nodes. The test task includes the domain name to be tested, the expected resolution result, and the query parameters.

[0058] The test task consists of structured instructions generated by the central control node, used to guide proxy nodes in executing specific DNS queries and reporting results. The domain name under test is the target domain whose resolution behavior needs to be verified in this test. The expected resolution result is a correct response content corresponding to the domain name under test, pre-set according to system configuration or business rules. Query parameters are technical settings used to control DNS query behavior, including but not limited to query type, timeout, etc.

[0059] For example, in specific implementation, after the central control node obtains the test requirements and completes the proxy node configuration, it can enter the test task construction and distribution stage: First, based on the test objectives, the domain name to be tested is extracted from the configuration database or input interface, and its corresponding expected resolution results are associated (including the IP address or domain name record that should be returned in different regions); at the same time, general query parameters are set according to the test type and accuracy requirements, such as DNS record type, query timeout threshold and retry strategy, to form a structured test parameter set.

[0060] Subsequently, the central control node encapsulates the domain name to be tested, the expected resolution results, and the query parameters into a test task in a unified format. Based on the list of activated proxy nodes, it pushes this test task to each proxy node through a pre-established secure communication channel. It is understood that, in some embodiments, during the distribution process, the central control node can also serialize, encrypt, and verify the integrity of the task content to ensure that the instructions received by each proxy are consistent, reliable, and executable, thereby laying the data foundation for subsequent distributed DNS queries and result verification.

[0061] Step 206: Control each proxy node to initiate a DNS query request to the DNS system under test based on the domain name to be tested and the query parameters, and receive the query results returned by each proxy node.

[0062] The DNS system under test refers to the domain name resolution service instance included in the test scope, which can be a self-built DNS server or a cloud DNS service. A DNS query request refers to a standard DNS protocol message constructed by the proxy node according to the test task and sent to the DNS system under test. The query result refers to the actual response data returned by proxy nodes distributed in different geographical regions after initiating queries to the DNS system under test, typically including but not limited to the response IP address, response time, and response status code. The expected resolution result is the correct resolution content that should be returned for a specific domain name under test under specific conditions (such as region and ISP), predefined before the test based on business policies or authoritative configuration.

[0063] In this embodiment, the central control node does not directly initiate DNS queries. Instead, it controls the proxy nodes through task-driven and state-coordinated methods. After the test task is successfully distributed, the central control node sends execution instructions to each proxy node or notifies them to begin executing DNS queries via a task state trigger mechanism. Each proxy node autonomously constructs a query request conforming to the DNS protocol based on the domain name to be tested and query parameters included in the task, and sends it to the DNS system under test. Upon receiving the response from the DNS system under test, each proxy node transmits the raw or structured query results (including the resolved IP address, response code, response time, etc.) back to the central control node through a preset communication channel. The central control node synchronously listens for and receives query results returned from all proxy nodes. Furthermore, the received query results can be processed for deduplication, time-series marking, and integrity verification, ultimately collecting and storing the valid query results to provide unified and reliable data input for subsequent verification and analysis.

[0064] Step 208: Based on the query results and expected resolution results fed back by each proxy node, verify whether the domain name resolution behavior of the DNS system under test meets the preset service specification requirements, and obtain the verification results.

[0065] In this embodiment, domain name resolution behavior refers to the external response characteristics exhibited by the DNS system under test after receiving a query request. The preset service specification requirements are predefined compliance standards regarding how the DNS system should respond, covering functional and performance requirements such as content correctness and behavioral consistency.

[0066] In practice, after the central control node receives the query results from each proxy server, it compares them item by item with the expected resolution results in the test task to determine whether the actual returned resolution content is consistent with the preset. At the same time, in conjunction with the preset service specification requirements, it aggregates and analyzes all query results to assess whether the DNS system under test stably and correctly executes the resolution logic in different regional or network environments. If the deviation between the actual behavior and the specification requirements is within an acceptable range, it is judged as compliant; otherwise, it is marked as abnormal. Finally, the central control node integrates the various comparison and evaluation results to generate a verification result that represents the overall compliance status of the system.

[0067] Step 210: Generate a test report based on the verification results.

[0068] A test report is a structured output document that summarizes information from the entire test process, key data, and final conclusions.

[0069] In practice, the central control node can compile a professional test report based on the verification results, detailed records of all key steps in the testing process, the testing status of each proxy server, key findings, problem diagnoses, and comprehensive performance evaluations. Alternatively, the verification results can be structured and organized to generate a test report. For example, key indicators can be extracted, including the resolution accuracy, compliance status, anomaly details, and overall pass rate of each proxy server's region. Secondly, metadata related to this test, such as test time, involved domain names, proxy server distribution information, and task configuration parameters, can be associated. Subsequently, the above content is organized according to a preset report template to form a standardized test report document. Finally, the central control node outputs this document in a common format (such as PDF, HTML, or JSON) and can selectively store it in a log system, push it to the operations and maintenance platform, or provide a download interface, thus completing the closed loop from verification to delivery. The test report can provide professional data support and suggestions for the optimization and maintenance of the DNS system, and will provide empirical evidence and professional advice for further system and performance optimization of the DNS system.

[0070] In the aforementioned distributed DNS testing method, test requirement data is acquired and proxy nodes distributed across different geographical regions are configured accordingly. This achieves a high degree of realism in replicating real user access scenarios, improving the global coverage and environmental diversity of the test. By creating test tasks containing the domain name to be tested, expected resolution results, and query parameters, and distributing them to each proxy node, the controllability of the test behavior and the consistency of the verification benchmark are ensured. Each proxy node initiates a real DNS query request to the DNS system under test based on the task and returns the query results. By comparing the actual response with the expected results, the system can objectively verify whether it meets the preset service specifications in terms of resolution accuracy, zone policy execution, proportional allocation, and performance. Finally, a structured test report is automatically generated. The entire solution not only significantly improves the realism, coverage, and accuracy of DNS testing, but also effectively reduces the adverse effects of traditional large-volume local requests being susceptible to network interference, unable to simulate regional differences, and having large proportional verification errors, achieving more accurate and efficient testing.

[0071] In one exemplary embodiment, such as Figure 3 As shown, before step 202, the method further includes:

[0072] Step 102: Deploy the DNS system under test in the test environment and distribute the overlay file and IP attribution file to the DNS system under test.

[0073] Step 206 includes: Step 226, after confirming that the DNS system under test has loaded the overlay file and IP attribution file and is in normal operating condition, controlling each agent node to initiate a DNS query request to the DNS system under test based on the domain name under test and query parameters.

[0074] The overlay file defines the expected resolution results of the target domain name in different geographical regions, and the IP attribution file defines the mapping relationship between IP address ranges and geographical regions.

[0075] A test environment refers to a platform isolated from the production system, used to simulate real network conditions, and deployed to verify the behavior of the DNS system under test. An overlay file is a configuration file that defines the expected resolution results (i.e., IP address or CNAME) that a target domain name (such as a second-level domain) should return in different geographical regions (such as North China, East China, North America, etc.), used to implement a geolocation-based intelligent resolution strategy. For example, the overlay file format is as follows (domain name zone resolution results): www.test.com dx_fujian 1.1.1.0 1.1.1.1 240E::1 240E::X.

[0076] The IP address attribution file is another configuration file that contains the mapping relationship between IP address ranges and their respective geographical regions (such as countries, provinces, and ISPs), used for subsequent location identification and policy verification of the resolution results. For example, the IP address attribution file format is as follows (IP range): 1.0.2.0 1.0.2.255 dx_fujian.

[0077] In practical applications, the central control node first deploys the DNS system under test on the test machine and distributes the overlay file and IP attribution file to it through the management interface or file synchronization mechanism. Then, the central control node monitors the status of the DNS system under test, confirming that it has successfully loaded the aforementioned configuration files and that the service is running normally (e.g., through health checks or log parsing). Based on this, the central control node generates a list of domain names to be tested and corresponding query parameters according to preset test cases, and distributes these instructions to multiple proxy nodes distributed in different geographical locations. Each proxy node constructs a DNS query request according to the instructions (which can simulate a specific source IP to trigger regional scheduling logic) and initiates a query to the DNS system under test. The central control node synchronously collects the response data returned by the proxy nodes, providing basic data support for subsequent accuracy, policy compliance, and performance analysis.

[0078] In this embodiment, a controllable verification environment closely resembling a real business scenario is constructed by pre-deploying the DNS system under test in the test environment and accurately injecting overlay files and IP attribution files. After confirming that the configuration is loaded and the service is ready, the central control node coordinates multiple proxy nodes to initiate structured DNS queries, ensuring that the test can effectively trigger the geolocation-based intelligent resolution logic. This method not only improves the realism and coverage of the test but also verifies the correctness of the regional scheduling strategy, IP attribution mapping, and configuration file loading in advance, avoiding online resolution anomalies due to configuration errors. Overall, this process achieves closed-loop verification of the functionality, strategies, and stability of the intelligent DNS system, significantly enhancing the quality assurance capabilities before the DNS service goes live and reducing operational risks.

[0079] like Figure 4 As shown, in an exemplary embodiment, step 208 includes:

[0080] Step 228: Based on the query results and expected resolution results fed back by each proxy node, verify whether the DNS system under test meets the preset service specification requirements in terms of the accuracy of the resolved content, the resolution ratio strategy and / or response performance.

[0081] In this embodiment, the accuracy of the resolved content refers to whether the IP address or record actually returned by the DNS system matches the expectation. The resolution ratio strategy refers to the load balancing rule where the DNS system returns different IP addresses for the same domain name according to a preset weight (e.g., 6:4). Response performance refers to the timeliness of the DNS system in processing requests, usually measured by response time. In this embodiment, the preset service specification requirements can be set as acceptance criteria explicitly defined in the test plan, such as accuracy ≥ 99.9%, ratio deviation ≤ ±5%, average response time ≤ 50ms, etc.

[0082] In practice, the central control node first aggregates the query results reported by all proxy nodes and associates each record with the domain name to be tested, query parameters, and expected resolution results. Then, it performs three parallel analyses: First, it compares the IP address in each response with the expected resolution results of that domain name in the current simulated environment (e.g., the originating IP's location) to calculate the matching rate and verify the accuracy of the resolved content. Second, it performs frequency statistics on the responding IPs by second-level domain name or service identifier, calculates the actual return ratio of each IP, and checks for deviations compared to the preset resolution ratio strategy. Third, it extracts the response time of each record and calculates the average value, P95 latency, timeout rate, and other indicators based on dimensions such as region and carrier. Finally, the central control node compares these three types of indicators with the preset service specification requirements to determine whether all are met, and records the relevant data and verification results in detail, clearly indicating any non-compliance and its severity.

[0083] This embodiment achieves automated, multi-dimensional, and standardized verification of DNS system service quality, unifying resolution accuracy, policy compliance, and response performance into a single evaluation system, and using preset service specifications as objective criteria. The central control node significantly improves the breadth of test coverage, evaluation accuracy, and decision-making efficiency through centralized processing and intelligent analysis of distributed agent feedback data. This method can be applied not only to pre-launch functional acceptance but also to daily inspections and change verification, effectively preventing business interruptions caused by DNS configuration errors, policy drift, or performance degradation, thereby ensuring high availability and consistent user experience for large-scale Internet services.

[0084] In an exemplary embodiment, the query result returned by the proxy node includes the response IP address and response time. Step 228 includes:

[0085] The responding IP address is compared with the expected resolution result, and the accuracy of the resolution content of the DNS system under test is verified based on the comparison result.

[0086] Count the frequency of each second-level domain name in all query results to verify whether the DNS system's resolution ratio strategy conforms to the preset resolution ratio relationship.

[0087] The response performance of the DNS system under test is evaluated based on response time.

[0088] The response IP address refers to the actual IP address returned by the proxy node after it sends a domain name resolution request to the DNS system under test. A second-level domain refers to a subdomain level under the main domain (such as "service" in "service.example.com"), often used to distinguish different services or deployment units. Response time refers to the time interval between the proxy node sending a DNS query request and receiving a complete response, usually measured in milliseconds, used to measure system processing latency.

[0089] In practice, the central control node can receive query results reported from multiple distributed proxy nodes, extract the response IP addresses, and match the expected resolution results stored locally with the domain name corresponding to the query. It can then determine whether each result is consistent and thus calculate the resolution accuracy.

[0090] Secondly, the central control node aggregates all query results by second-level domain, counts the frequency of each responding IP under each second-level domain, calculates the actual return ratio, and performs deviation analysis (such as using thresholds or statistical tests) against the preset resolution ratio strategy to determine whether the strategy execution is compliant. Finally, the central control node collects the response time of each record, combines it with metadata such as the geographical location and ISP of the proxy nodes, and calculates performance indicators such as average response time, P95 / P99 latency, and timeout rate in groups. These metrics are then compared with SLA standards or historical baselines to generate a DNS system response performance evaluation report.

[0091] In this embodiment, a central control node uniformly schedules multi-point proxy probing and structures the response IP address and response time data, thereby achieving automated, quantitative, and high-concurrency verification of the DNS system under test in three key dimensions: accuracy of resolution content, compliance of resolution ratio policy, and response performance. Compared with traditional single-point or manual testing methods, this method has advantages such as wide coverage, comprehensive evaluation dimensions, and traceable results. It can promptly detect problems such as configuration errors, policy failures, or regional performance degradation, significantly improving the efficiency and reliability of DNS service quality monitoring and providing a solid technical guarantee for high-availability domain name resolution in large-scale distributed network environments.

[0092] like Figure 5 As shown, in one exemplary embodiment, the method further includes:

[0093] Step 104: Enable security protection policies in the DNS system under test. The security protection policies include at least one of the following: request frequency limiting policy, DNS query rate control policy, and custom firewall rules.

[0094] In this embodiment, the security protection strategy refers to a set of security control mechanisms deployed in the DNS system under test to defend against abnormal or malicious traffic. The request frequency limiting strategy sets an upper limit on the number of DNS queries that can be initiated from a single source IP or client per unit time, preventing high-frequency requests from exhausting resources. The DNS query rate control strategy regulates the processing rate of overall or specific types of DNS queries (such as recursive queries or specific domain name queries) to ensure system stability and service quality. Custom firewall rules can be filtering logic configured by testers according to actual security needs, such as determining whether to allow, drop, or redirect DNS requests based on conditions like source IP address, query domain name, protocol type, or message characteristics.

[0095] In this embodiment, the central control node may send a configuration status query command to the DNS system under test, or read its operation logs and internal status information through a preset interface, to confirm that the overlay file (defining the mapping between domain names and regionalized resolution results) and the IP attribution file (defining the correspondence between IP segments and geographical regions) have been successfully loaded into memory and are in effect. After confirming that the basic configuration is ready, the central control node issues a protection policy activation command to the DNS system under test, activating its built-in security protection mechanism; this mechanism includes three core sub-functions: request frequency limit for specific IP addresses: implementing upper limit control on the number of accesses per unit time for query requests from specified IPs or IP segments; DNS query rate control: setting the maximum number of queries per second (QPS) globally or by source network dimension to prevent sudden traffic surges; and customized firewall rules: based on a preset rule set, intercepting or limiting abnormal query types, illegal domain name formats, or suspicious source addresses.

[0096] Furthermore, the central control node can indirectly confirm that the advanced protection function has been correctly enabled and the policy is effective by sending a small number of probing requests (such as high-frequency queries or unconventional record types) and observing the system response (such as returning REFUSED, packet loss, or rate limiting prompts), thereby ensuring that subsequent formal tests are conducted in an environment with real defense capabilities.

[0097] In this embodiment, by enabling security protection strategies, including request frequency limiting, query rate control, and custom firewall rules, in the DNS system under test, and combining multi-dimensional proactive detection and result analysis led by the central control node, a systematic verification of the effectiveness, accuracy, and robustness of the DNS security mechanism is achieved. This method can not only expose security policy configuration defects or performance bottlenecks in advance, but also simulate real attack scenarios without affecting online services, thereby improving the resilience and security level of the DNS system, effectively preventing common threats such as DDoS attacks, domain name enumeration, and cache poisoning, and enhancing the reliability and security of the entire network infrastructure.

[0098] like Figure 6 As shown, in an exemplary embodiment, the query parameters include a DNS query type, the query result includes a DNS response packet, and the method further includes:

[0099] Step 212: When the DNS query type is ANY, determine the size ratio of the request data packet sent by the proxy node to the DNS response data packet, and verify whether there is a risk of DNS amplification attack based on the size ratio.

[0100] In this embodiment, the DNS query type refers to the query record type defined in the DNS protocol, such as A (IPv4 address), AAAA (IPv6 address), MX (mail exchange), or ANY (request to return all available record types for a domain name). The DNS response packet is a complete response message returned by the DNS server in response to a query request, containing a header, question section, answer section, and possible additional information. The request packet refers to the DNS query message sent by the proxy node to the DNS system under test. The size ratio refers to the ratio of the byte length of the DNS response packet to the byte length of the corresponding request packet; a DNS amplification attack is a denial-of-service attack that utilizes DNS protocol features (especially ANY queries) to trigger a large response with a small request, thereby reflecting and amplifying traffic to the target victim. Its risk level is usually assessed using the request / response size ratio.

[0101] In practice, the central control node can first configure a test task, instructing the proxy node to send a DNS query of type ANY to the DNS system under test and record the original byte count of the request data packet. Subsequently, the proxy node receives the DNS response data packet and reports its complete content and byte length to the central control node. The central control node then filters out all test records with query type ANY and calculates the ratio of the response data packet size to the request data packet size for each record. Next, it compares this ratio with a preset security threshold (such as 50 times or 100 times). If the ratio exceeds the threshold, the central control node determines that the DNS server is at risk of being abused in DNS amplification attacks. Finally, the central control node summarizes all test results, generates a risk assessment report, identifies high-risk nodes, and recommends mitigation measures such as disabling ANY queries or implementing response truncation.

[0102] In this embodiment, by actively initiating DNS ANY type queries and accurately calculating the size ratio of request and response data packets, the automatic identification and quantitative assessment of whether a DNS server is at risk of amplification attacks are achieved. Compared with traditional methods that rely on passive monitoring or log analysis, this technique has the advantages of being proactive, comprehensive, and accurate. It can promptly detect security configuration vulnerabilities before the DNS system goes online or during operation and maintenance, effectively preventing them from being maliciously used to participate in reflection amplification attacks, thereby improving the overall security and compliance of network infrastructure and providing forward technical support for defending against distributed denial-of-service (DDoS) attacks.

[0103] To provide a clearer explanation of the distributed DNS system testing method provided in this application, an example is provided below, which includes the following:

[0104] First, testers deploy the DNS system under test in the test environment and load an overlay file (defining the IP address or subdomain that each domain name should return in different regions) and an IP attribution file (establishing the mapping relationship between IP segments and geographical regions). Then, they verify that the basic configuration file has been loaded correctly and that the system is in normal operation. At the same time, advanced protection functions are enabled, including limiting the request frequency of specific IP addresses, global DNS query rate control, and firewall rules customized based on business needs, in order to build a security defense system that closely resembles the production environment.

[0105] Based on this, the central control node obtains the test requirement data, resolves the geographical areas to be covered (such as Fujian Telecom, North American AWS nodes, European data centers, etc.), and selects and activates multiple proxy servers located in different geographical areas from the proxy resource pool accordingly. Each proxy is bound to a regional identity and a secure communication channel is established. Next, the central control node creates a test task, encapsulates the domain name to be tested, its associated expected resolution results, and query parameters (such as record type and timeout) into a structured instruction, and distributes it to all proxy servers. Subsequently, the central control node triggers the execution process. Each proxy server, according to the task content, initiates a DNS query request to the DNS system under test using a local or simulated client IP, and returns the query results including the response IP, response time, response code, and data packet size.

[0106] After the central control node aggregates all results, it compares them with the expected resolution results. Combining these with preset service specification requirements (covering resolution accuracy, regional policy consistency, proportional allocation compliance, and potential security risks), it comprehensively evaluates whether the domain name resolution behavior of the DNS system under test meets expectations and generates verification conclusions. Finally, the central control node integrates test metadata, regional performance, anomalies, and verification results to automatically generate a structured test report, completing a closed-loop process from system deployment, agent configuration, task distribution, distributed execution, intelligent verification to report output. This achieves high-fidelity, high-coverage, and high-security integrated testing of the DNS system's functionality, performance, and security in a real global network environment.

[0107] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0108] Based on the same inventive concept, this application also provides a distributed DNS testing apparatus for implementing the distributed DNS testing method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more distributed DNS testing apparatus embodiments provided below can be found in the limitations of the distributed DNS testing method described above, and will not be repeated here.

[0109] In one exemplary embodiment, such as Figure 7 As shown, a distributed DNS testing device 700 is provided, including: a data acquisition module 710, a data distribution module 720, a control module 730, a data verification module 740, and a report generation module 750, wherein:

[0110] The data acquisition module 710 is used to acquire test requirement data and configure multiple proxy nodes located in different geographical areas based on the test requirement data.

[0111] The data distribution module 720 is used to create test tasks and distribute them to multiple proxy nodes. The test tasks include the domain name to be tested, the expected resolution result, and the query parameters.

[0112] The control module 730 is used to control each agent node to initiate a DNS query request to the DNS system under test based on the domain name to be tested and query parameters, and to receive the query results returned by each agent node.

[0113] The data verification module 740 is used to verify whether the domain name resolution behavior of the DNS system under test meets the preset service specification requirements based on the query results and expected resolution results fed back by each proxy node, and obtain the verification results.

[0114] The report generation module 750 is used to generate test reports based on the verification results.

[0115] like Figure 8 As shown, in an exemplary embodiment, the apparatus further includes a deployment module 702 for deploying the DNS system under test in a test environment and distributing overlay files and IP attribution files to the DNS system under test.

[0116] The control module 730 is also used to control each agent node to initiate a DNS query request to the DNS system under test based on the domain name under test and query parameters, after confirming that the DNS system under test has loaded the overlay file and the IP attribution file and is in normal operating condition; wherein, the overlay file defines the expected resolution results of the target domain name in different geographical regions, and the IP attribution file defines the mapping relationship between IP address ranges and geographical regions.

[0117] In an exemplary embodiment, the data verification module 740 is further configured to verify, based on the query results and expected resolution results fed back by each proxy node, whether the DNS system under test meets the preset service specification requirements in terms of the accuracy of the resolved content, the resolution ratio strategy and / or the response performance.

[0118] In an exemplary embodiment, the query results returned by the proxy node include the response IP address and response time. The data verification module 740 is further used to compare the response IP address with the expected resolution result, verify the accuracy of the resolution content of the DNS system under test based on the comparison result, count the frequency of each second-level domain name in all query results, verify whether the resolution ratio strategy of the DNS system conforms to the preset resolution ratio relationship, and evaluate the response performance of the DNS system under test based on the response time.

[0119] In an exemplary embodiment, the deployment module 702 is further configured to enable a security protection policy in the DNS system under test, the security protection policy including at least one of a request frequency limiting policy, a DNS query rate control policy, and a custom firewall rule.

[0120] In an exemplary embodiment, the query parameters include the DNS query type, the query result includes the DNS response data packet, and the data verification module 740 is further configured to determine the size ratio of the request data packet sent by the proxy node to the DNS response data packet when the DNS query type is ANY, and verify whether there is a risk of DNS amplification attack based on the size ratio.

[0121] Each module in the aforementioned distributed DNS testing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0122] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data such as overlay files, IP address files, and configuration data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements a distributed DNS testing method.

[0123] Those skilled in the art will understand that Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0124] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in any of the above embodiments of the distributed DNS testing method.

[0125] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in any of the above embodiments of the distributed DNS testing method.

[0126] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the distributed DNS testing method.

[0127] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0128] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0129] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0130] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A distributed DNS testing method, characterized in that, The method includes: Obtain test requirement data, and configure multiple proxy nodes located in different geographical regions based on the test requirement data; A test task is created and distributed to multiple proxy nodes, wherein the test task includes the domain name to be tested, the expected resolution result, and query parameters; The system controls each of the proxy nodes to initiate a DNS query request to the DNS system under test based on the domain name to be tested and the query parameters, and receives the query results returned by each of the proxy nodes. Based on the query results and expected resolution results fed back by each of the proxy nodes, the domain name resolution behavior of the DNS system under test is verified to meet the preset service specification requirements, and the verification results are obtained. A test report is generated based on the verification results.

2. The method of claim 1, wherein, Before obtaining the test requirement data, the method further includes: Deploy the DNS system under test in the test environment, and distribute the overlay file and IP attribution file to the DNS system under test; The control of each of the agent nodes to initiate a DNS query request to the DNS system under test based on the domain name to be tested and the query parameters includes: Once it is confirmed that the DNS system under test has loaded the overlay file and the IP attribution file and is in normal operating condition, each of the proxy nodes is controlled to initiate a DNS query request to the DNS system under test based on the domain name under test and the query parameters. The overlay file defines the expected resolution results of the target domain name in different geographical regions, and the IP attribution file defines the mapping relationship between IP address ranges and geographical regions.

3. The method of claim 2, wherein, The process of verifying whether the domain name resolution behavior of the DNS system under test meets the preset service specification requirements based on the query results fed back by each of the proxy nodes and the expected resolution results includes: Based on the query results fed back by each of the agent nodes and the expected resolution results, verify whether the DNS system under test meets the preset service specification requirements in terms of the accuracy of the resolved content, the resolution ratio strategy and / or response performance.

4. The method of claim 3, wherein, The query results returned by the proxy nodes include the responding IP address and response time. Verifying whether the DNS system under test meets the preset service specifications in terms of the accuracy of the resolved content, the resolution ratio strategy, and / or response performance, based on the query results returned by each proxy node and the expected resolution results, includes: The response IP address is compared with the expected resolution result, and the accuracy of the resolution content of the DNS system under test is verified based on the comparison result. Count the frequency of each second-level domain name in all query results to verify whether the DNS system's resolution ratio strategy conforms to the preset resolution ratio relationship; The response performance of the DNS system under test is evaluated based on the response time.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: Enable a security protection policy in the DNS system under test. The security protection policy includes at least one of the following: request frequency limiting policy, DNS query rate control policy, and custom firewall rules.

6. The method according to any one of claims 1 to 4, characterized in that, The query parameters include the DNS query type, the query result includes a DNS response data packet, and the method further includes: When the DNS query type is ANY, determine the size ratio of the request packet sent by the proxy node to the DNS response packet; Based on the aforementioned size ratio, verify whether there is a risk of DNS amplification attacks.

7. A distributed DNS testing device, characterized in that, The device includes: The data acquisition module is used to acquire test requirement data and configure multiple proxy nodes located in different geographical regions based on the test requirement data. The data distribution module is used to create test tasks and distribute the test tasks to multiple proxy nodes, wherein the test task includes the domain name to be tested, the expected resolution result, and query parameters; The control module is used to control each of the proxy nodes to initiate a DNS query request to the DNS system under test based on the domain name to be tested and the query parameters, and to receive the query results returned by each of the proxy nodes; The data verification module is used to verify whether the domain name resolution behavior of the DNS system under test meets the preset service specification requirements based on the query results fed back by each of the proxy nodes and the expected resolution results, and to obtain the verification results. The report generation module is used to generate a test report based on the verification results.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images