Large-scale DNS risk situation real-time monitoring system supporting heterogeneous detection terminal

Abstract

The invention discloses a large-scale DNS risk situation real-time monitoring system supporting heterogeneous detection terminals, and belongs to the field of DNS risk situation awareness. The system specifically comprises a detection node cluster, a data acquisition module, a data cleaning and statistics module and a DNS risk situation report module. The method comprises the following steps: initially configuring a detection task of each detection node, deploying the detection nodes by adopting different request modes, monitoring response messages of the detection tasks in real time, formatting the response messages, attaching detected node geographic positions, task timestamps and DNS (Domain Name Server) analysis, uploading the response messages to a Kafka cluster of a data acquisition module, and acquiring server response data corresponding to the tasks. The DNS risk situation report module stores and pushes the data to the data cleaning and statistics module, extraction, namely cleaning and reduction of useful fields is carried out, risk situation statistical indexes are calculated and transmitted to the DNS risk situation report module, the corresponding statistical indexes are presented to users through query, and DNS risk situations of all regions are visually reflected. According to the invention, the risk that the detection features are identified is reduced, and the monitoring concealment is improved.

Description

Technical Field

[0001] The present invention belongs to the field of DNS risk situation awareness of network security, and in particular relates to a large-scale DNS risk situation real-time monitoring system supporting heterogeneous detection terminals. Background Art

[0002] With the rapid development of the Internet, the Domain Name System (DNS), as an important infrastructure supporting the normal operation of the Internet, carries the key function of domain name resolution; however, while providing services, DNS has also become a potential target for network attacks.

[0003] In recent years, security threats targeting the DNS have been increasing, particularly risks such as domain name hijacking and service outages, which have severely impacted the availability of network services and data security. For websites with high daily traffic and important social functions, such as online financial trading systems or well-known search engines, domain name hijacking or service outages can cause severe financial losses to individuals or businesses, a serious threat that cannot be ignored. Therefore, timely and accurate monitoring of domain name risk for important websites is crucial.

[0004] Currently, there are many domain name risk monitoring systems on the market for enterprises or individuals, but they generally have the following problems:

[0005] (1) The domain name risk situation detection system for personal applications requires users to manually input the domain name to be detected, and the response time is long. It lacks automated monitoring and retrieval functions, which is inconvenient for users to use.

[0006] (2) Most domain name risk situation monitoring systems only use servers as detection terminals and lack task adaptability to heterogeneous terminals.

[0007] With the development of edge computing and fog computing technologies, more and more mobile devices are being used to perform network testing and computing tasks. Compared to server-based nodes, mobile nodes are lower cost and easier to deploy on a large scale, but their computing performance is relatively weak. Therefore, considering a combination of cost, detection scale, and performance, deploying detection nodes with multiple architectures (including server-based and mobile-based) within a risk situation monitoring system is an appropriate strategy.

[0008] For heterogeneous terminal detection node clusters, it is particularly important to uniformly collect and analyze the data packets transmitted from these distributed nodes with different architectures.

[0009] In big data processing and analysis applications, Kafka is a widely used message queue middleware due to its high throughput, distributed deployment, and integration with server terminals and embedded terminals. Among all big data processing frameworks, Apache Flink is the distributed framework with the strongest real-time computing performance. It can be connected with Kafka to achieve efficient streaming data processing and analysis, making it ideal for data analysis tasks with high real-time requirements. Summary of the Invention

[0010] In order to solve the problems of low automation, single terminal type and insufficient real-time performance of existing DNS risk monitoring systems, the present invention proposes a large-scale DNS risk situation real-time monitoring system that supports heterogeneous detection terminals. By combining heterogeneous detection terminals, distributed message queues and stream processing frameworks, it realizes automated, large-scale and real-time monitoring of large-scale DNS risk situations.

[0011] The large-scale DNS risk situation real-time monitoring system supporting heterogeneous detection terminals specifically includes the following modules: detection node cluster, data collection module, data cleaning and statistics module, and DNS risk situation reporting module;

[0012] The detection node module is responsible for executing the detection task, and the data collection module collects the server response data corresponding to the task, stores it and passes it to the data cleaning and statistics module, cleans and reduces the server response data, obtains real-time DNS risk situation indicator data, and transmits it to the DNS risk situation report module, presenting the risk situation indicator data in the form of a user-friendly visual interface, intuitively reflecting the DNS risk situation in various regions.

[0013] The detection node module adopts a hierarchical storage system (HSM-like) architecture, dividing the heterogeneous detection terminals into three layers: edge layer, fog computing layer and cloud computing layer.

[0014] The edge layer consists of lightweight IoT devices and mobile devices; it can quickly access any designated location, perform periodic basic detection tasks with low computing load, and support large-scale deployment, thereby supporting large-scale detection tasks.

[0015] The fog computing layer consists of distributed server nodes deployed in regional data centers or edge clouds; it is responsible for processing tasks of medium complexity and aggregating edge layer data.

[0016] The cloud computing layer consists of a cluster of high-performance cloud servers that supports large-scale remote deployment; it is responsible for global data aggregation, complex analysis, and persistent data storage.

[0017] The data acquisition module is implemented based on Kafka. In the Kafka cluster, at least three broker nodes are deployed, and two topic queues, dig and ping, are set to store Dig task and Ping task response data packets respectively. The number of copies and partitions are set according to actual business needs.

[0018] The data cleaning and statistics module uses Flink as a framework. It first extracts the fields to be analyzed from the original response data. It then collects statistics on website domain name resolution from two dimensions: geographic location and DNS resolver, including resolution accuracy, recall rate, and average TTL. It also analyzes website domain name access connectivity from the geographic location dimension, including the number of normal response status codes and average RTT. The statistical results are persistently stored.

[0019] The DNS risk situation report module is used to read real-time DNS risk situation statistical indicator data and present it to users through the front end, so that users can have an overview of the overall DNS risk situation in various regions. Users can also query the risk situation of website domain names they are concerned about, including domain name resolution accuracy, recall rate, and response delay indicators, so as to analyze the domain name hijacking risks and service suspension risks faced by the website.

[0020] The large-scale DNS risk situation real-time monitoring system supporting heterogeneous detection terminals works as follows:

[0021] Step 1: Initially configure the detection tasks of each detection node;

[0022] It includes the detection domain name, detection DNS resolver, detection task type (Dig / Ping) and detection frequency.

[0023] The detection task adopts unstructured storage and uses the Redis database as the storage engine.

[0024] Step 2: For different detection node terminal types, different request methods are used to implement the deployment of detection nodes;

[0025] Detection node terminal types include servers, IoT devices, and mobile devices.

[0026] For server detection terminals, we use the Python dnslib library to send DNS requests and the scapy library to send Ping requests. We also use Docker containerization technology to implement large-scale deployment of server-side detection nodes.

[0027] For IoT devices, network dial testing is implemented based on C / C++ embedded development technology, including DNS request detection and Ping request detection;

[0028] For mobile devices, use Javascript language to implement a network dial test module that can be migrated and deployed.

[0029] Step 3: The detection node monitors the response message of the detection task in real time, formats it into JSON, attaches the detection node's geographic location, detection task timestamp, and detection DNS resolver, and uploads it to the Kafka cluster of the data collection module.

[0030] Step 4: The Kafka cluster receives the data uploaded by the detection node in real time and pushes it to the data cleaning and statistics module.

[0031] Step 5: The data cleaning and statistics module extracts useful fields from the data pushed by the Kafka cluster according to business needs to obtain cleaned data. It then aggregates the cleaned data according to the required dimensions to calculate risk situation statistical indicators and save them in the statistical results database.

[0032] Useful fields include timestamp, probe domain name, probe node geographic location, accessed DNS resolver, record type, TTL, resolution result, response status code, and RTT field;

[0033] Risk situation statistical indicators include precision (Precision), recall rate (Recall), F1 score (F1), risk coefficient (Risk),

[0034] The calculation formulas for each indicator are as follows:

[0035]

[0036] Risk=1-αPrecision-βRecall-yF1

[0037] Where TP represents the number of correct resolution results returned by the DNS resolver (i.e., the number of records that appear in the trusted record base), FP represents the number of incorrect resolution results returned by the DNS resolver (i.e., the number of records that are not in the trusted record base), and FN represents the number of records in the trusted record base that were not resolved. α, β, and γ are risk assessment weighting coefficients, satisfying α + β + γ = 1.

[0038] Step 6: The DNS risk situation report module sends a query to the statistical result database through SQL statements and presents the corresponding statistical indicators to the user.

[0039] Presentation formats include DNS risk heat maps for each region, a list of the top 10 high-risk domain names, a historical domain hijacking rate curve, and a comparison chart of resolution accuracy and recall rates. The module also provides a search bar where users can enter the website domain of interest. The backend then issues an HTTP GET request to the ElasticSearch component, performs a fuzzy match on the user's query, and returns the matching risk profile data to the module frontend for presentation.

[0040] The present invention has the following advantages:

[0041] (1) Efficiency: This system uses Kafka, a high-throughput distributed message queue middleware, as its internal communication medium and Flink, a high-performance stream processing distributed computing framework, as its data cleaning and statistical analysis tool. This fully guarantees the system's computing performance, availability, scalability, and reliability, and ensures the real-time nature of data statistics, meeting the needs of real-time DNS risk situation statistics.

[0042] (2) Flexibility: This system is based on an HSM-like architecture and supports a variety of terminal types, including servers, mobile devices, and IoT devices. It automatically allocates tasks based on terminal capabilities, thereby achieving a good trade-off between detection performance and node deployment costs, maximizing resource utilization, and customizing the detection scale based on actual detection needs. In addition, the data acquisition module and data processing module in the system are separated from each other, which has good maintainability. Developers can customize data processing logic according to user detection requirements and add required data indicator statistical logic at any time.

[0043] (3) Anti-counterattack capability: Through layered camouflage strategies and diversified request behaviors, the risk of detection features being identified is reduced and the monitoring concealment is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 This is an architectural diagram of a large-scale DNS risk situation real-time monitoring system supporting heterogeneous detection terminals of the present invention. DETAILED DESCRIPTION

[0045] The specific implementation method of the present invention is further described in detail below with reference to the accompanying drawings.

[0046] The present invention proposes a large-scale DNS risk situation real-time monitoring system that supports heterogeneous detection terminals. Based on the Kafka+Flink framework, it provides real-time domain name risk situation monitoring for important websites, allowing individual or corporate users to retrieve the status of monitored website domain names in real time. The present invention supports dynamic allocation of detection terminals according to task characteristics, including IoT cards and mobile terminals (suitable for high-frequency, low-computation tasks, with the advantages of rapid deployment and easy formation of large-scale detection clusters), cloud servers (suitable for tasks requiring large-scale parallel computing, with the advantages of high performance and large data storage capacity), and fog computing hosts (which can undertake regional-level tasks and share the load of cloud servers), and can combine the advantages of various terminals. In addition, the present invention introduces a detection traffic camouflage mechanism to prevent detection behavior from being identified and suppressed, thereby ensuring the normal operation of detection tasks.

[0047] The system described in this invention achieves efficient, real-time monitoring and analysis of DNS risk trends by combining heterogeneous detection terminals, a distributed message queue (Kafka), and a stream processing framework (Flink). Specifically, it includes the following modules: a detection node cluster, a data collection module, a data cleaning and statistics module, and a DNS risk situation reporting module;

[0048] The detection node cluster is responsible for executing the detection task. The data collection module collects the server response data corresponding to the task, provides data temporary storage space and data transmission mechanism, stores it and passes it to the data cleaning and statistics module, cleans and reduces the latest received server response data, obtains real-time DNS risk situation indicator data, and transmits it to the DNS risk situation report module, presenting the risk situation indicator data in the form of a user-friendly visual interface to intuitively reflect the DNS risk situation in various regions.

[0049] The detection node cluster supports multiple terminal types, including servers, mobile devices, and IoT devices, performs DNS detection tasks and collects server response packets. It uses a hierarchical storage system (HSM-like) architecture to divide heterogeneous detection terminals into three layers: edge layer, fog computing layer, and cloud computing layer. Detection tasks are dynamically allocated based on performance, deployment flexibility, and task complexity.

[0050] The edge layer consists of lightweight IoT devices (such as network dial-up test cards) and mobile devices (such as smartphones). These terminals are flexible to deploy and can quickly access any designated location (such as corporate intranets and home gateways). They perform periodic basic detection tasks with low computing load (such as high-frequency ping detection and DNS resolution status monitoring). They are relatively low-cost and support large-scale deployment, thereby supporting large-scale detection tasks.

[0051] The fog computing layer is composed of distributed server nodes and is deployed in regional data centers or edge clouds. It is responsible for processing tasks of medium complexity (such as multi-dimensional DNS resolution result comparison and regional risk situation pre-analysis) and aggregating edge layer data.

[0052] The cloud computing layer consists of a cluster of high-performance cloud servers that supports large-scale remote deployment; it is responsible for global data aggregation, complex analysis, and persistent data storage.

[0053] The data acquisition module is implemented based on Kafka, using the Kafka message queue middleware as a data transmission medium to receive and store data packets from heterogeneous detection terminals, ensuring efficient data transmission and reliable storage. The "producer-consumer" communication model is adopted internally. The detection node acts as a "producer" and uploads the received DNS resolution response message and Ping response message to the Kafka message queue. The Flink cluster acts as a "consumer" to monitor the Kafka message queue in real time and obtain the latest messages (i.e., real-time DNS resolution response message and Ping response message), and responds to them.

[0054] The data cleaning and statistics module uses the Apache Flink distributed data processing framework, relational database and ElasticSearch as the data storage engine, extracts data from the Kafka cluster, performs real-time cleaning, analysis and calculation, and generates DNS risk situation statistics. First, the fields to be analyzed are extracted from the original response data, including the timestamp, detection domain name, detection node geographic location, accessed DNS resolver, record type, TTL, resolution result, response status code, and RTT field. Then, the website domain name resolution status indicators are counted from the two dimensions of geographic location and DNS resolver, including resolution accuracy, recall rate and average TTL. The website domain name access connectivity is analyzed from the geographic location dimension, including the number of normal response status codes and average RTT. The statistical result data is persistently stored.

[0055] The DNS risk situation report module is used to query and read real-time DNS risk situation statistical indicator data, and present a user-friendly data large-screen interface through BI tools, Vue, EChart and other front-end visualization rendering frameworks, so that users can easily overview the overall DNS risk situation in various regions. They can also query the risk situation of website domain names they are concerned about, including domain name resolution accuracy, recall rate, and response delay indicators, so as to analyze the domain name hijacking risks and service suspension risks faced by the website.

[0056] The large-scale DNS risk situation real-time monitoring system supporting heterogeneous detection terminals works as follows:

[0057] Step 1: Initially configure the detection tasks of each detection node;

[0058] It includes the detection domain name, detection DNS resolver, detection task type (Dig / Ping) and detection frequency.

[0059] The detection task adopts unstructured storage and uses the Redis database as the storage engine.

[0060] Step 2: For different detection node terminal types, different request methods are used to implement the deployment of detection nodes;

[0061] Detection node terminal types include servers, IoT devices, and mobile devices.

[0062] For server detection terminals, we use the Python dnslib library to send DNS requests and the scapy library to send Ping requests. We also use Docker containerization technology to implement large-scale deployment of server-side detection nodes.

[0063] For IoT devices, network dial testing is implemented based on C / C++ embedded development technology, including DNS request detection and Ping request detection;

[0064] For mobile devices, a network dialing test module that can be deployed and migrated is implemented using Javascript. The implemented network dialing test module can be used as an extension of the browser or other application software and work in background mode.

[0065] Step 3: The detection node monitors the response message of the detection task in real time, formats it into JSON, attaches the detection node's geographic location, detection task timestamp, and detection DNS resolver, and uploads it to the Kafka cluster of the data collection module.

[0066] Step 4: The Kafka cluster acts as an intermediate communication medium to receive data uploaded by the detection node in real time and push it to the data cleaning and statistics module.

[0067] Step 5: The data cleaning and statistics module extracts useful fields from the data pushed by the Kafka cluster according to business needs to obtain cleaned data. It then aggregates the cleaned data according to the required dimensions to calculate risk situation statistical indicators and save them in the statistical results database.

[0068] Useful fields include timestamp, probe domain name, probe node geographic location, accessed DNS resolver, record type, TTL, resolution result, response status code, and RTT field;

[0069] The specific cleaning process is:

[0070] First, build a Flink cluster, then use Java to write data cleaning and statistical analysis program code, compile and package the code, and submit it to the Flink cluster to start data processing and analysis tasks.

[0071] Risk situation statistical indicators include precision (Precision), recall (Recall), F1 score (F1), and risk coefficient (Risk).

[0072] Step 6: The DNS risk situation report module sends a query to the statistical result database through SQL statements and presents the corresponding statistical indicators to the user.

[0073] Presentation formats include DNS risk heat maps for each region, a list of the top 10 high-risk domain names, a historical domain hijacking rate curve, and a comparison chart of resolution accuracy and recall rates. The module also provides a search bar where users can enter the website domain of interest. The backend then issues an HTTP GET request to the ElasticSearch component, performs a fuzzy match on the user's query, and returns the matching risk profile data to the module frontend for presentation.

[0074] Example:

[0075] The specific implementation of each module in this example is as follows:

[0076] (1) Detection node deployment

[0077] In this system, detection node terminal types include servers, IoT devices, and mobile devices.

[0078] Before executing a detection task, the detection node reads the pre-configured detection task (including the detection domain name, detection DNS resolver, detection task type (Dig / Ping), and detection frequency). The detection task adopts an unstructured storage method and uses the Redis database as the storage engine.

[0079] After receiving the probe task response message, the probe node formats the response message in JSON, attaches the probe node's geographic location, the probe task timestamp, and the probe's DNS resolver (this field is only added in the Dig task), and uploads it to the Kafka cluster.

[0080] To prevent detection behavior from being identified, the system simulates real user behavior through the following means:

[0081] ①Device fingerprint camouflage

[0082] In the IoT card, the MAC address and HTTP request header of common smart hardware (such as routers and cameras) are simulated to disguise themselves as ordinary IoT devices; on the mobile side, the device ID is randomly generated and the User-Agent is dynamically switched (simulating mobile browsers of different brands); in the cloud, IP pool rotation technology is used to simulate the distributed IP distribution of real users.

[0083] ② Diversified request behaviors

[0084] After DNS resolution, subsequent HTTP requests (GET / POST) are initiated probabilistically to simulate a complete access link and dynamically adjust the detection frequency to avoid triggering the anti-crawl mechanism at fixed time intervals.

[0085] ③ Traffic feature confusion

[0086] Edge-tier devices inject noise data (such as random DNS queries) by region to hide core detection targets.

[0087] (2) Data acquisition module deployment

[0088] This system's data collection module is implemented based on Kafka. Within the Kafka cluster, we deploy at least three broker nodes and set up two topic queues, dig and ping, to store response packets for Dig and Ping tasks, respectively. A distributed replication mechanism is employed (the number of replicas and partitions is set based on actual business needs) to ensure system data reliability and access performance. Server-side detection nodes transmit data packets to Kafka via the Kafka Producer API. IoT terminals and mobile devices use the lightweight MQTT protocol to bridge with Kafka to reduce resource usage.

[0089] (3) Data cleaning and statistics module

[0090] The data cleaning and statistics module of this system is implemented based on Flink, using YARN components to schedule data computing tasks. Developers first set up a Flink cluster, then write the data cleaning and statistical analysis program code in Java. This code is compiled, packaged, and submitted to the Flink cluster to start the data processing and analysis tasks.

[0091] The Java code for data cleaning is as follows:

[0092]

[0093] The data statistical analysis code is as follows:

[0094]

[0095]

[0096] The data processing logic in this module is implemented based on the Flink DataStream API and is divided into two steps: data cleaning and reduction statistics.

[0097] Data cleansing extracts useful fields from raw data packets for analysis based on business needs, while statistical reduction aggregates the cleansed data according to the dimensions to be analyzed to calculate risk profile indicators. To facilitate traceability analysis, both cleansed data packets and statistical reduction results are stored in a structured format, using either MySQL or Oracle as the storage engine.

[0098] For the Dig task, the fields extracted through data cleaning and the value types and meanings saved in the database are shown in Table 1.

[0099] Table 1

[0100]

[0101]

[0102] After receiving the cleaned data packet, the data analysis program will use time (timestamp), city location (city), and resolver (resolver) as analysis dimensions to count the total type (type) and quantity (total_answers) of DNS resolution results received at the current time point, and compare them with the trusted DNS resolution record library to calculate the total number of trusted records (total_creds) and the number of correct resolution results (true_answers) for the current domain name, and store the statistical result records in a relational database.

[0103] The stored field information is shown in Table 2

[0104] Table 2

[0105]

[0106] For Ping task records, the fields that the data analysis program first extracts, that is, the fields retained after cleaning the Ping response data packet, are shown in Table 3:

[0107] Table 3

[0108]

[0109] After obtaining the cleaned data packets, the data analysis program reduces and counts them, and obtains the statistical results shown in Table 4:

[0110] Table 4

[0111]

[0112] (Note: The number of messages not received normally refers to the sum of the number of requests that did not receive a response and the number of response messages with abnormal status codes; for PING requests that did not receive a response, the rtt field will be recorded as the system TIMEOUT duration)

[0113] In order to facilitate users to retrieve the domain name status they are concerned about, the system uses the high-performance distributed search engine middleware ElasticSearch to connect with the search engine module, and automatically synchronizes the statistical result data stored in the relational database to ElasticSearch.

[0114] (4) DNS risk situation report module

[0115] This module sends a query to the statistical result database through SQL statements and presents the corresponding statistical indicators. For the domain name hijacking risk situation, this module will present the user with four indicators: precision, recall, F1 score, and risk factor. The corresponding calculation formulas are as follows:

[0116]

[0117] Risk=1-αPrecision-βRecall-yF1

[0118] Where TP represents the number of correct resolution results returned by the DNS resolver (i.e., the number of records that appear in the trusted record base), FP represents the number of incorrect resolution results returned by the DNS resolver (i.e., the number of records that are not in the trusted record base), and FN represents the number of records in the trusted record base that were not resolved. α, β, and γ are risk assessment weighting coefficients, satisfying α + β + γ = 1.

[0119] After obtaining the corresponding indicator data, the module uses the EChart framework to render the data on the large screen interface and present the queried indicator data.

Claims

1. A large-scale DNS risk situation real-time monitoring system supporting heterogeneous detection terminals, characterized by: It includes detection node cluster, data collection module, data cleaning and statistics module, and DNS risk situation report module; The detection node cluster is responsible for executing the detection task. The data collection module collects the server response data corresponding to the task, stores it and passes it to the data cleaning and statistics module, cleans and reduces the server response data, obtains real-time DNS risk situation indicator data, and transmits it to the DNS risk situation report module, which presents the risk situation indicator data in the form of a user-friendly visual interface to intuitively reflect the DNS risk situation in various regions.

2. The large-scale DNS risk situation real-time monitoring system supporting heterogeneous detection terminals according to claim 1 is characterized in that: The detection node cluster adopts a layered storage architecture, dividing the heterogeneous detection terminals into three layers: edge layer, fog computing layer and cloud computing layer; The edge layer consists of lightweight IoT devices and mobile devices. It can quickly access any designated location, perform periodic basic detection tasks with low computing load, and support large-scale deployment, thereby supporting large-scale detection tasks. The fog computing layer consists of distributed server nodes deployed in regional data centers or edge clouds. It is responsible for processing tasks of medium complexity and aggregating edge layer data. The cloud computing layer consists of a cluster of high-performance cloud servers that supports large-scale remote deployment; it is responsible for global data aggregation, complex analysis, and persistent data storage.

3. The large-scale DNS risk situation real-time monitoring system supporting heterogeneous detection terminals according to claim 1 is characterized in that: The data acquisition module is implemented based on Kafka. In the Kafka cluster, at least 3 broker nodes are deployed, and 2 topic queues dig and ping are set to store Dig task and Ping task response data packets respectively, and the number of copies and partitions are set according to actual business needs.

4. The large-scale DNS risk situation real-time monitoring system supporting heterogeneous detection terminals according to claim 1 is characterized in that: The data cleaning and statistics module uses Flink as a framework. It first extracts the fields to be analyzed from the original response data. It then collects statistics on website domain name resolution from two dimensions: geographic location and DNS resolver. These metrics include resolution accuracy, recall, and average TTL. Furthermore, it analyzes website domain name access connectivity from the geographic location dimension, including the number of normal response status codes and average RTT. The statistical result data is stored persistently.

5. The large-scale DNS risk situation real-time monitoring system supporting heterogeneous detection terminals according to claim 1 is characterized in that: The DNS risk situation report module is used to read real-time DNS risk situation statistical indicator data and present it to users through the front end, so that users can have an overview of the overall DNS risk situation in various regions. Users can also query the risk situation of website domain names they are concerned about, including domain name resolution accuracy, recall rate, and response delay indicators, so as to analyze the domain name hijacking risks and service suspension risks faced by the website.

6. The large-scale DNS risk situation real-time monitoring system supporting heterogeneous detection terminals according to claim 1 is characterized in that: The system works as follows: Step 1: Initially configure the detection tasks of each detection node; Including detection domain name, detection DNS resolver, detection task type Dig / Ping and detection frequency; Step 2: For different detection node terminal types, different request methods are used to implement the deployment of detection nodes; Detection node terminal types include servers, IoT devices, and mobile devices; Step 3: The detection node monitors the response message of the detection task in real time, formats it into JSON, attaches the detection node's geographic location, detection task timestamp, and detection DNS resolver, and uploads it to the Kafka cluster of the data collection module; Step 4: The Kafka cluster receives the data uploaded by the detection node in real time and pushes it to the data cleaning and statistics module; Step 5: The data cleaning and statistics module extracts useful fields from the data pushed by the Kafka cluster according to business needs to obtain cleaned data. It then aggregates the cleaned data according to the required dimensions to calculate risk situation statistical indicators and saves them in the statistical results database. Risk situation statistical indicators include precision, recall, F1 score and risk factor; Step 6: The DNS risk situation report module sends a query to the statistical result database through SQL statements and presents the corresponding statistical indicators to the user.

7. The large-scale DNS risk situation real-time monitoring system supporting heterogeneous detection terminals according to claim 6 is characterized in that: In step 1, the detection task adopts an unstructured storage method and uses the Redis database as the storage engine.

8. The large-scale DNS risk situation real-time monitoring system supporting heterogeneous detection terminals according to claim 6 is characterized in that: In step 2, for the server detection terminal, the Python dnslib library is used to implement DNS request sending, the scapy library is used to implement Ping request sending, and the Docker containerization technology is used to implement large-scale server-side detection node deployment; For IoT devices, network dial testing is implemented based on C / C++ embedded development technology, including DNS request detection and Ping request detection; For mobile devices, use Javascript language to implement a network dial test module that can be migrated and deployed.

9. The large-scale DNS risk situation real-time monitoring system supporting heterogeneous detection terminals according to claim 6, characterized in that: In step five, useful fields include timestamp, detection domain name, detection node geographic location, accessed DNS resolver, record type, TTL, resolution result, response status code and RTT field.

10. The large-scale DNS risk situation real-time monitoring system supporting heterogeneous detection terminals according to claim 6, characterized in that: In step 6, the statistical indicators presented include a DNS risk heat map for each region, a list of the top 10 high-risk domain names, a curve of the historical domain name hijacking rate, and a comparison chart of the resolution accuracy and recall rate; At the same time, the DNS risk situation report module provides a search bar. Users enter the website domain name they are interested in. The backend sends an HTTP GET request to the ElasticSearch component, performs fuzzy matching on the query issued by the user, and returns the matched risk situation record data to the module front end for presentation.

Images