High-performance intelligent DNS firewall system

Abstract

The invention relates to the technical field of network security, and discloses a high-performance intelligent DNS (Domain Name Server) firewall system, which comprises a front-end firewall; a back-end analysis and management server; a visual platform; the front-end firewall, the back-end analysis and management server and the visual platform are connected in sequence; the QPS of a single machine is improved to 120 million (Intel i7-10700 platform), the processing delay is reduced to be within 5 ms, and the million-level concurrent requirement of an operator is met; the unknown DNS attack recognition rate reaches 98%, the DDoS attack interception rate is 99.5%, and the sensitive traffic interception response is less than or equal to 1s; the system is compatible with a domestic operating system (Kylin V10, United Response UNS) and a chip (Feiteng FT-2000 + / 64, Peng 920), and the performance standard-reaching rate of a domestic platform is 98%; the speed limit of 20 million-level domain names is supported, and the memory occupation is reduced by 75% (from 8GB to 2GB); the deployment time is shortened by 92%, the configuration effective time is shortened by 67%, the fault recovery time is less than or equal to 5s, and the operation and maintenance cost is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security, in particular to the technical field of DNS (Domain Name System) protection, and specifically to a high-performance intelligent DNS firewall system. BACKGROUND

[0002] DNS protection is a comprehensive security strategy and technical measure designed to protect the infrastructure, queries, and data of the Domain Name System (DNS) from various network threats. DNS is responsible for converting easy-to-remember domain names into IP addresses that computers can understand. If DNS is attacked or tampered with, the entire Internet access will be thrown into chaos.

[0003] The existing DNS protection technology has the following core defects, which cannot meet the current network security needs: 1. Insufficient high-concurrency processing capability: Traditional DNS protection systems use a "kernel protocol stack + user state processing" architecture, and data packets need to be forwarded through multiple links (network card -> kernel protocol stack -> socket -> user state), with a processing delay of up to 50ms. The single-machine QPS (Queries Per Second) is generally less than 300,000, which cannot support operator-level million-level concurrent access; 2. Low unknown attack recognition rate: Relies on manual configuration of static rules, with an unknown attack recognition rate of less than 30% for zero-day exploits and random domain name scanning, making it easy for attacks to penetrate; 3. Lack of domestic adaptation: International mainstream products (such as Infoblox DNS Security) do not support domestic operating systems such as Kylin V10 and UOS, and domestic chips such as FT-2000+ / 64 and Kunpeng 920, which do not meet the requirements of the national information creation project; 4. Weak large-scale domain name management capability: International similar products only support 100,000-level domain name speed limiting, and use static memory allocation, with memory occupancy exceeding 8GB, which cannot meet the fine management needs of 20 million-level domain names; 5. Poor operation convenience: Traditional system deployment requires more than 4 hours, with a configuration effective time of more than 30 seconds, lack of real-time visual monitoring, and inability to quickly locate attack sources and performance bottlenecks.

[0004] In summary, the existing technology cannot simultaneously achieve the DNS protection needs of "high performance, high intelligence, domesticization, high expansion, and easy operation", and needs to be broken through. Therefore, we need to propose a high-performance intelligent DNS firewall system. SUMMARY

[0005] The purpose of this invention is to provide a high-performance intelligent DNS firewall system, which increases the single-machine QPS to 1.2 million (Intel Xeon Silver 4210R), reduces the processing latency to less than 5ms, meets the carrier-grade requirements of millions of concurrent connections, achieves an unknown DNS attack identification rate of 98%, a DDoS attack interception rate of 99.5%, and a sensitive traffic interception response of ≤1s, and is compatible with domestic operating systems (Kylin V10, Tongxin UOS) and chips (Hygon C86 7285, Hygon C86-3G), with a domestic platform performance compliance rate of 98%; thereby solving the problems mentioned in the background technology.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a high-performance intelligent DNS firewall system, comprising: As a front-end firewall at the traffic entry layer, it is responsible for real-time interception, efficient processing, and anomaly marking of DNS traffic; As the backend analysis and management server of the logic layer, it enables intelligent analysis, user management, and dynamic policy distribution; As a visualization platform for the interaction layer, it adopts the Vue3+ECharts+Go backend technology stack to provide global situational awareness and convenient operation entry points; The front-end firewall, back-end analysis and management server, and visualization platform are connected sequentially. The front-end firewall includes: The kernel-mode traffic processing module is responsible for high-speed data plane processing and low-level traffic control. The user-mode optimization module efficiently receives and schedules data, enabling high-concurrency processing. A hierarchical bucket domain rate limiting engine is used for fine-grained, large-scale request rate control. The backend analysis and management server includes: The real-time anomaly detection module is used to detect threats and respond automatically based on anomalies. The user-side management module enables multi-tenant business management and provides different policy services for different tenants.

[0007] Preferably, the kernel-mode traffic processing module deploys an eBPF program during the Linux kernel TC ingress stage to directly intercept data packets. The interception of data packets is achieved by storing traffic statistics in a hash table and using XDP action priority rules.

[0008] Preferably, the process for intercepting data packets is as follows: A1. Implement IP / domain traffic control: A single machine can process 1.5 million rule matches per second; A2. Malformed DNS packet interception: Malformed DNS packets include packets with a length exceeding 1024 bytes or with abnormal QNAME characters; A3. Synchronize traffic metrics to user space within 1ms using eBPF Maps. Traffic metrics include QSP and source IP distribution.

[0009] Preferably, to avoid cross-core scheduling overhead, the user-mode optimization module adopts an architecture of one event-loop per core, binds to the CPU core, and achieves zero-memory copy between kernel mode and user mode through mmap shared memory. Furthermore, it enables inter-module communication based on thread-local storage and lock-free queues.

[0010] Preferably, the hierarchical bucket domain name rate limiting engine adopts a hierarchical structure of 1024 first-level buckets + 2048 second-level buckets, quickly locates the domain name according to the domain name hash value, and dynamically adjusts the bucket capacity. The capacity expansion of high-frequency domain name buckets can be adjusted by a multiplier. The domain name bucket is queried every 30 minutes and memory is automatically reclaimed. The hierarchical bucket domain name rate limiting engine supports simultaneous rate limiting of 20 million domain names, the time for a single rule update is less than or equal to 50ms, and the memory usage is reduced to less than 2GB.

[0011] Preferably, when using the real-time anomaly detection module for anomaly detection, the following method is adopted: Feature extraction: 12 types of DNS traffic features were extracted and standardized using standard scores. Model optimization: A time-series anomaly detection model using a long short-term memory autoencoder is adopted, combined with a 10-second sliding window sampling and attention mechanism, reducing the thrust consumption time to 8ms. Streaming processing, based on the Flink framework, enables the analysis of 500,000 DNS logs per second with a latency of less than or equal to 200ms; The rules are linked, and abnormal IPs are automatically added to the blacklist upon detection. The attack interception response time is less than or equal to 1 second.

[0012] Preferably, the user terminal management module uses OAuth2.0+JWT to implement device identity authentication, supports multi-tenant management, and issues protection rules according to the tenant dimension. It also stores user query volume data based on MongoDB, supports billing based on QPS / domain quantity, and has a statistical error of less than or equal to 0.1%.

[0013] Preferably, for the OAuth2.0+JWT authentication system, a JWT dynamic key is used, the signature key is rotated every hour to prevent replay attacks, and the device fingerprint is bound, and the JWT contains the device hardware hash value to prevent token theft.

[0014] Preferably, the visualization platform monitors multiple indicators in real time and refreshes at a frequency of 1 second. It displays the distribution of attack sources through a geographic heatmap, supports filtering by attack type, has a historical data query response time of less than or equal to 3 seconds, and enables visual editing of IP blacklists and whitelists and domain name rate limit thresholds. The configuration takes effect in less than or equal to 10 seconds. The visualization platform is based on Ansible to achieve automated deployment, shortening deployment time, and supports automatic fault recovery.

[0015] Preferably, real-time monitoring is implemented based on long-connection communication of Vue3 components, combined with high-concurrency data processing of Go goroutines in the backend analysis and management server; attack situation awareness is implemented by integrating ECharts GL for geographic information visualization, and the backend analysis and management server uses the GeoIP2 database for IP address resolution; during dynamic configuration, a graphical form is provided to generate configuration commands, which are then sent to the backend analysis and management server via a RESTful API; automated deployment is based on writing automated deployment scripts using Ansible, combined with Systemd health checks and watchdog scripts.

[0016] Compared with the prior art, the beneficial effects of the present invention are: 1. This invention increases the single-machine QPS to 1.2 million (Intel Xeon Silver 4210R), reduces the processing latency to less than 5ms, and meets the carrier-grade million-level concurrent requirements; the unknown DNS attack identification rate reaches 98%, the DDoS attack interception rate is 99.5%, and the sensitive traffic interception response is ≤1s; it is compatible with domestic operating systems (Kylin V10, Tongxin UOS) and chips (Hygon C86 7285, Hygon C86-3G), and the performance compliance rate of the domestic platform is 98%.

[0017] 2. This invention supports rate limiting for 20 million domain names, reduces memory usage by 75% (from 8GB to 2GB), shortens deployment time by 92%, reduces configuration activation time by 67%, and reduces fault recovery time to ≤5s, thereby reducing operation and maintenance costs. Attached Figure Description

[0018] Figure 1 This is a system block diagram of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Please seeFigure 1 This invention provides a technical solution: a high-performance intelligent DNS firewall system, which is suitable for intelligent DNS attack interception, large-scale domain name management and adaptation to domestic environments in high-concurrency scenarios, and can be applied to DNS security protection scenarios such as operator backbone networks, education and research networks, and enterprise intranets.

[0021] include: As a front-end firewall at the traffic entry layer, it is responsible for real-time interception, efficient processing, and anomaly marking of DNS traffic; As the system's data plane, the front-end firewall is the first line of defense for DNS traffic, focusing on high-speed, real-time traffic processing and security defense. It utilizes eBPF / XDP technology to process DNS traffic at line speeds at the kernel layer, achieving ultra-low latency interception, passage, or marking. Based on preset rules, it immediately intercepts malformed packets and implements fine-grained domain request rate limiting, effectively resisting DDoS flood attacks and abnormal queries. Through lock-free programming and CPU affinity binding technologies, it ensures system stability and extremely high throughput under millions of concurrent connections.

[0022] As the backend analysis and management server of the logic layer, it enables intelligent analysis, user management, and dynamic policy distribution; By using AI models such as LSTM-AE, we can perform in-depth time-series analysis on the traffic reported by the front-end firewall to discover hidden and advanced threats (such as slow attacks and data leaks). The analysis results (such as detected malicious IPs) are converted into protection rules in real time and dynamically sent to the front-end firewall for execution, forming a "detection-response" closed loop. The backend analytics and management server is also used for user and business management, and is responsible for business logic such as multi-tenant management, authentication and authorization, and billing statistics to ensure the operability of the system.

[0023] As a visualization platform for the interaction layer, it adopts the Vue3+ECharts+Go backend technology stack to provide global situational awareness and convenient operation entry points; The system's operational status (QPS, attack events, resource usage) is presented intuitively in the form of charts and maps, providing a clear overview of the security posture on a single screen. A graphical interface is provided, allowing administrators to easily manage IP blacklists and whitelists, rate limiting policies, etc., lowering the operational threshold. One-click deployment and automatic fault recovery functions greatly enhance the system's usability and maintainability.

[0024] The front-end firewall, back-end analysis and management server, and visualization platform are connected sequentially. The front-end firewall uses eBPFMaps to synchronize metrics such as QPS and source IP distribution to the back-end analytics and management server with extremely low latency (within 1ms). The data flow from the front-end firewall to the back-end analysis and management server includes: detailed DNS query logs, which include: the domain name, type, response code, timestamp, etc. After being collected through efficient kernel-mode-user-mode communication mechanisms (such as mmap, lock-free queues), the logs are sent in batches to the back-end analysis and management server to provide raw data fuel for the streaming processing engine and LSTM-AE anomaly detection model of the back-end analysis and management server.

[0025] The front-end firewall includes: The kernel-mode traffic processing module is responsible for high-speed data plane processing and low-level traffic control. The kernel-mode traffic processing module deploys an eBPF program in the Linux kernel TCingress stage to directly intercept data packets. The interception of data packets is achieved by storing traffic statistics in a hash table and using XDP action priority rules.

[0026] The process for intercepting data packets is as follows: A1. Implement IP / domain traffic control: A single machine can process 1.5 million rule matches per second; A2. Malformed DNS packet interception: Malformed DNS packets include packets with a length exceeding 1024 bytes or with abnormal QNAME characters; A3. Synchronize traffic metrics to user space within 1ms using eBPF Maps. Traffic metrics include QSP and source IP distribution.

[0027] The kernel-mode traffic processing module inspects the raw data packets. If a malformed packet is detected, it is dropped by XDP_DROP. If a legitimate packet is detected, it is forwarded to user space by XDP_TX. If a suspicious packet is detected, it is allowed to pass through the protocol stack by XDP_PASS.

[0028] Real-time traffic control based on eBPF hash tables uses eBPF hash tables to store traffic rules for IPs / domains (such as blacklists / whitelists, rate limiting thresholds), and performs inline matching through eBPF programs, processing 1.5 million rule matches per second on a single machine; it supports dynamic injection of new rules in user space (such as blacklists issued by the backend), which take effect in real time without restarting.

[0029] The user-mode optimization module efficiently receives and schedules data, enabling high-concurrency processing. To avoid cross-core scheduling overhead, the user-mode optimization module adopts an architecture of one event-loop per core, which is bound to the CPU core. It achieves zero-memory copy between kernel mode and user mode through mmap shared memory, and realizes inter-module communication based on thread-local storage and lock-free queues.

[0030] Each event loop has its own dedicated CPU core, implemented via sched_setaffinity(), reducing context switching latency by 60%. Create mmap shared memory area mappings (eBPF Maps) so that user-space programs can directly read memory data, bypassing the copy_from_user system call.

[0031] The technical components for implementing lock-free concurrent communication include: thread-local storage, where each thread maintains an independent queue to avoid global lock contention; and a lock-free circular buffer, which uses CAS atomic operations to implement the producer-consumer model and supports multi-producer-consumer patterns.

[0032] A hierarchical bucket domain rate limiting engine is used for fine-grained, large-scale request rate control. The hierarchical bucket domain name rate limiting engine adopts a hierarchical structure of 1024 first-level buckets + 2048 second-level buckets. It quickly locates domain names based on their hash values ​​and dynamically adjusts bucket capacity. The capacity of high-frequency domain name buckets can be increased by an adjustable multiplier. It queries domain name buckets every 30 minutes and automatically reclaims memory. The hierarchical bucket domain name rate limiting engine supports simultaneous rate limiting of 20 million domain names. The time for a single rule update is less than or equal to 50ms, and the memory usage is reduced to less than 2GB.

[0033] Each primary bucket has 64 secondary buckets. The primary bucket caches hot domains (accounting for 5% of the total but handling 80% of the traffic), while the secondary buckets store long-tail domains and load them on demand. Utilizing the principle of locality of reference in the secondary buckets, 16-bit offsets are used instead of 64-bit pointers.

[0034] The structure of the hierarchical bucket domain rate limiting engine is shown in the table below: Hierarchical bucket domain rate limiting engine structure table Full capture and protocol parsing of DNS traffic provides data support for subsequent tiered rate limiting, avoiding misjudgments or omissions due to incomplete data.

[0035] Traffic collection method: By using bypass mirroring (such as through a switch's SPAN port) or online traffic redirection (such as redirection through a DNS server gateway), capture all traffic entering and leaving the DNS server via UDP port 53 (or TCP port 53, used for large DNS responses) to ensure no traffic loss.

[0036] When selecting technologies, prioritize high-performance frameworks (such as DPDK and Netmap) to avoid excessive CPU / memory consumption during the data collection process and ensure low latency for DNS resolution (DNS requests typically require a response time of <100ms).

[0037] Protocol parsing content: Extract the core fields of the DNS request: the requested domain name (e.g., www.baidu.com), the request type (A / AAAA / CNAME, etc.), the source IP, the request frequency, and the response code (e.g., NXDOMAIN).

[0038] Domain names can be "splittered" hierarchically, for example, abccom can be split into three levels: top-level domain (.com), second-level domain (c.com), and third-level domain (bccom), in preparation for subsequent "layered bucket building".

[0039] 1. Construction of hierarchical buckets and domain name profiling "Hierarchical buckets" are traffic control units divided according to domain name hierarchy. Each bucket corresponds to a type of domain name and presets dynamic rate limiting thresholds based on "domain name profiles" to solve the problems of "overlapping normal traffic with global rate limiting" and "inability to deal with spoofed IPs with IP-based rate limiting".

[0040] Hierarchical bucket partitioning logic DNS traffic is divided into three buckets based on domain influence and traffic volume. The finer the level, the higher the accuracy of the rate limiting: 2. Bucket threshold configuration based on domain profile The rate limiting threshold for each bucket is not a fixed value, but is dynamically adjusted based on the "domain's historical traffic profile" to avoid static thresholds mistakenly blocking normal peak traffic (such as a surge in DNS requests during e-commerce promotions). Profile data collection: Statistics on the "normal traffic baseline" of a domain name over the past 7 days (or 30 days), including: Average daily request volume (e.g., baidu.com receives 1 million requests per day). Peak request volume (e.g., 2 million requests / minute during a major promotion). Request type percentage (e.g., A records account for 80%, CNAME records account for 15%).

[0041] Threshold calculation formula: Dynamic threshold = historical peak value × safety factor (usually taken as 1.2~1.5).

[0042] Example: If the historical peak value of a certain second-level domain is 100,000 times / minute and the safety factor is 1.3, then the rate limit threshold for this bucket is set to 130,000 times / minute. If this is exceeded, rate limiting will be triggered.

[0043] Special bucket configuration: For "low-traffic niche domains" (such as less than 1,000 requests per day), set a lower threshold (such as 2,000 requests per minute), because a sudden surge in traffic to such domains is likely an attack.

[0044] Implementation of dynamic speed limiting engine The rate limiting engine is the "brain" of the hierarchical bucket system. It needs to combine "real-time traffic statistics" and "abnormal feature recognition" to achieve "precise rate limiting without false positives". The core of it adopts the combined logic of "token bucket algorithm + abnormal feature weighting".

[0045] Traditional token buckets are used for single-stream rate limiting; here, they need to be modified to "hierarchical token buckets," allocating tokens independently to each bucket. Preset a "token generation rate" (corresponding to a rate limit threshold) for each hierarchical bucket. For example, the token generation rate of the second-level domain bucket (baidu.com) is 130,000 times / minute (that is, about 2,167 tokens per second).

[0046] When a DNS request arrives, first match the corresponding bucket level and attempt to retrieve one token from the bucket: Successfully obtained token: Allows request forwarding to DNS server for normal resolution; Token not acquired (tokens in bucket exhausted): Triggers exception handling procedures (such as discarding, delayed response).

[0047] The token bucket's "bucket capacity" is set to 10%~20% of the threshold (e.g., for a bucket of 130,000 times / minute, the capacity is set to 13,000 times) to cope with short-term traffic fluctuations (such as a sudden surge in requests from normal users) and avoid frequent triggering of rate limits.

[0048] Relying solely on traffic thresholds may lead to misjudgments (such as legitimate peak traffic for normal domains). It's necessary to combine this with typical characteristics of DNS attacks, further demoting "suspicious requests" (i.e. consuming more tokens) to improve identification accuracy. Common anomaly characteristics and weighting rules: High-frequency repeated requests: The interval between requests from the same source IP to the same domain name is less than 100ms, and each request consumes 2 tokens (normal requests consume 1 token). Invalid request types: A large number of requests for "uncommon types" (such as DNSKEY, AXFR, which are usually used for attack detection) should be rejected and logged directly; Characteristics of a forged source IP: The source IP is a private address (such as 192.168.0.0 / 16) but it initiates a public DNS request, consuming 3 tokens; Anomaly in response code: The percentage of "NXDOMAIN (domain does not exist)" responses for a certain domain is greater than 50% (this may be because the attacker is scanning for non-existent domains). Requests to this domain consume 2 tokens.

[0049] Hierarchical handling of abnormal traffic Instead of simply discarding abnormal traffic that triggers rate limits, we handle it in a tiered manner based on the severity of the abnormality, balancing security and user experience.

[0050] Log and closed-loop optimization By continuously optimizing the thresholds and feature rules of the layered buckets through end-to-end logging and traffic analysis, we can reduce the false positive rate and improve the long-term defense effect.

[0051] Log entries: Real-time traffic (requests per second, token remaining), number of times rate limiting was triggered, and handling results (number of dropped / delayed tokens) for each tiered bucket. Detailed information about the abnormal request (source IP, domain name, request type, and signature tags) is used for subsequent attack tracing.

[0052] Closed-loop optimization strategy: The system calculates the "false positive rate" (the proportion of normal requests that are rate-limited) daily. If the false positive rate of a certain bucket is greater than 5%, its safety factor is automatically increased (e.g., from 1.3 to 1.5). Attack cases are analyzed weekly, and the anomaly signature database is updated (such as adding "attack signatures for a new type of top-level domain") and added to the weighting rules of the rate limiting engine. For domains that are frequently attacked (such as being attacked more than 3 times in a week), an "exclusive three-level bucket" will be automatically created for them, and more refined thresholds will be set.

[0053] To ensure low latency (<100ms) for DNS resolution and high performance for the rate limiting engine, the technology stack must meet the requirements of "high concurrency and low overhead": Traffic collection: DPDK (processing capacity of over 10Gbps, latency <1ms); Tiered bucket storage: RedisCluster (distributed storage bucket configuration and token counting, supporting 100,000+ reads and writes per second); Rule engine: Lua script (embedded in DNS server or scrubbing gateway to achieve millisecond-level rule matching); Monitoring visualization: Grafana + Prometheus (real-time display of traffic, token remaining amount, and handling statistics for each layer bucket).

[0054] The backend analysis and management server includes: The real-time anomaly detection module is used to detect threats and respond automatically based on anomalies. When using the real-time anomaly detection module for anomaly detection, the following method is employed: Feature extraction: 12 types of DNS traffic features were extracted (including the original "single IP to single domain name query interval distribution" feature), and standardized using standard scores (Z-Score); the standard deviation (σ) of query time for the same IP to the same domain name was calculated.

[0055] σ < 0.1s, scanning tools with fixed intervals; σ > 2s, manual operation with random intervals.

[0056] Model optimization: A temporal anomaly detection model using a long short-term memory autoencoder (LSTM-AE) is adopted, combined with a 10-second sliding window sampling and attention mechanism, reducing the push time to 8ms. The sequence is: input layer — 10s sliding window — LSTM-AE encoder — attention mechanism — decoding — reconstruction error — streaming KNN. The 10s sliding window captures short-cycle behavioral patterns, and the attention mechanism automatically focuses on key features, reducing the false positive rate by 25%.

[0057] Streaming processing, based on the Flink framework, enables the analysis of 500,000 DNS logs per second with a latency of less than or equal to 200ms; The rules are linked, and abnormal IPs are automatically added to the blacklist upon detection. The attack interception response time is less than or equal to 1 second.

[0058] The user-side management module enables multi-tenant business management and provides different policy services for different tenants.

[0059] The user-end management module uses OAuth2.0+JWT to implement device identity authentication, supports multi-tenant management, and issues protection rules according to the tenant dimension. It also stores user query volume data based on MongoDB (a database based on distributed file storage), supports billing based on QPS / domain quantity, and has a statistical error of less than or equal to 0.1%.

[0060] For the OAuth2.0+JWT authentication system, a JWT dynamic key is used, and the signing key is rotated every hour to prevent replay attacks. In addition, the device fingerprint is bound, and the JWT contains the device hardware hash value to prevent token theft.

[0061] The visualization platform monitors multiple indicators in real time and refreshes every 1 second. It displays the distribution of attack sources through a geographic heatmap, supports filtering by attack type, and has a historical data query response time of less than or equal to 3 seconds. It also enables visual editing of IP blacklists and whitelists and domain rate limit thresholds, with configuration taking effect in less than or equal to 10 seconds. The visualization platform is based on Ansible to achieve automated deployment, shortening deployment time and supporting automatic fault recovery.

[0062] Real-time monitoring is achieved through long-connection communication of Vue3 components, combined with high-concurrency data processing of Go coroutines in the backend analysis and management server. The Go service continuously reads the real-time data streams provided by the frontend firewall and the backend analysis and management server, while the Vue3 components listen to the WebSocket channel and dynamically update the ECharts chart at a frequency of 1 second.

[0063] Attack situation awareness is achieved by integrating ECharts GL for geographic information visualization, and the backend analysis and management server uses the GeoIP2 database for IP address resolution; By using pre-aggregation technology, historical data is summarized in advance according to time windows (such as 5 minutes) to avoid real-time full scanning. It supports linkage filtering by attack type (such as DDoS, tunnel attack), time range, source IP range, etc.

[0064] When configuring dynamically, a graphical form is provided to generate configuration commands, which are then sent to the backend analysis and management server via a RESTful API. The front-end firewall provides a user-friendly form interface for editing IP blacklists and whitelists, domain rate limiting thresholds, etc.; after receiving the configuration through the API interface of the back-end analysis and management server, it verifies it and immediately sends it to the front-end firewall of the entire cluster through the control flow.

[0065] Automated deployment is based on writing automated deployment scripts using Ansible, combined with Systemd health checks and watchdog scripts.

[0066] Ansible scripts automatically complete the entire process from dependency installation and configuration distribution to service startup, reducing deployment time from 4 hours to 30 minutes. The watchdog script continuously monitors the heartbeat of critical processes (such as eBPF programs and Go backend services), and immediately calls a preset script to restart the service or switch to a standby node once a fault is detected.

[0067] Innovations related to domestic adaptation include: Kernel-mode adaptation: Modify the eBPF program instruction set to be compatible with the ARM architecture; Operating system adaptation: Completed compatibility testing for Kylin V10 and UnionTech UOS systems, and resolved issues related to "driver dependency and process scheduling"; Protocol compatibility: The "protocol resolution proxy module" is designed to support UDP (traditional DNS), TCP (DoT), and HTTPS (DoH) traffic simultaneously, with a protocol recognition accuracy of 100%.

[0068] Prepare the hardware and software environments, including The hardware environment includes: Front-end firewall: Intel Xeon Gold 6326 (16 cores, 32 threads), 128GB DDR4 memory, 10Gbps dual network cards; Backend server: Hygon C86-3G (24 cores, 48 ​​threads), 256GB DDR4 memory, 2TB SSD; Domestic testing environment: Phytium FT-2000+ / 64 (64 cores 128 threads), Kylin V10 operating system.

[0069] The software environment includes: Kernel mode: Linux 5.4.0-xxx (with eBPF and XDP support enabled); User-space: Go 1.20 (Reactor pattern implementation), Flink 1.17 (stream processing); Databases: MongoDB 6.0 (user data storage), Redis 7.0 (caching rules); Visualization: Vue3, ECharts5.4, Nginx1.23.

[0070] In practice; I. Front-end firewall deployment eBPF application loading: Compile the eBPF program (based on the BCC toolchain) and load it into the kernel using the command `tc filter add dev eth0 ingress bpf daobj dns_filter.o sec ingress`. Configure XDP action rules: bpftool map update name xdp_action key 0 0 0 0 value1 0 0 0 (DROP for exception packets).

[0071] User-space module startup: Start the Reactor service: . / dns_reactor --cpu 16 --port 53 (binds to 16 CPU cores, listens on DNS port 53); Initialize the hierarchical bucket engine: . / domain_limit --max_domain 20000000 --bucket_level11024 --bucket_level2 2048 (configure a limit of 20 million domains and hierarchical bucket parameters).

[0072] II. Backend Server Configuration Anomaly detection module deployment: Start the Flink cluster: . / start-cluster.sh, submit the LSTM-AE model job: flink run -c com.dns.detect.LstmAeJob detect_job.jar; Configure feature extraction rules: curl -X POST http: / / backend:8080 / api / feature -d'{"features":["qname_entropy","ip_query_interval","nxdomain_rate"]}'; Client management configuration: Register a tenant: curl -X POST http: / / backend:8080 / api / tenant -d'{"name":"a certain provincial Unicom","domain_whitelist":["*.unicom.com"]}'; Issue rate limiting rules: curl -X POST http: / / backend:8080 / api / rule -d'{"tenant_id":"1","domain":"www.unicom.com","qps_limit":1000}'; Visual platform deployment Front-end build: `npm run build` deploys static files to Nginx; Backend service startup: . / visual_server --monitor_interval 1 (refreshes monitoring data every 1 second); Automated deployment: Execute the Ansible playbook: ansible-playbook -i inventory dns_firewall_deploy.yml, and complete the full node deployment within 30 minutes.

[0073] Testing phase Performance testing: Tool: DNSperf (simulates 1.2 million QPS requests); Results: Average latency 4.8ms, packet loss rate 0%, CPU utilization 28% (16 cores).

[0074] Security testing: Scenario: Simulated random domain name scanning attack (QNAME entropy value 1.8, normal threshold 0.5-1.2); Results: Attack detection rate 100%, interception response time 0.8s, no normal traffic was mistakenly intercepted.

[0075] Domestic compatibility test: Environment: Hygon C86 7285 + Hygon C86-3G; Results: QPS 1.05 million, latency 5.2ms, performance compliance rate 98%.

[0076] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A high-performance intelligent DNS firewall system, characterized in that, include: As a front-end firewall at the traffic entry layer, it is responsible for real-time interception, efficient processing, and anomaly marking of DNS traffic; As the backend analysis and management server of the logic layer, it enables intelligent analysis, user management, and dynamic policy distribution; As a visualization platform for the interaction layer, it adopts the Vue3+ECharts+Go backend technology stack to provide global situational awareness and convenient operation entry points; The front-end firewall, back-end analysis and management server, and visualization platform are connected sequentially. The front-end firewall includes: The kernel-mode traffic processing module is responsible for high-speed data plane processing and low-level traffic control. The user-mode optimization module efficiently receives and schedules data to achieve high-concurrency processing; A hierarchical bucket domain rate limiting engine is used for fine-grained, large-scale request rate control. The backend analysis and management server includes: The real-time anomaly detection module is used to detect threats and respond automatically based on anomalies. The user-side management module enables multi-tenant business management and provides different policy services for different tenants.

2. The high-performance intelligent DNS firewall system according to claim 1, characterized in that: The kernel-mode traffic processing module deploys an eBPF program during the Linux kernel TC ingress stage to directly intercept data packets. The interception of data packets is achieved by storing traffic statistics in a hash table and using XDP action priority rules.

3. The high-performance intelligent DNS firewall system according to claim 2, characterized in that: The process for intercepting data packets is as follows: A1. Implement IP / domain traffic control: A single machine can process 1.5 million rule matches per second; A2. Malformed DNS packet interception: Malformed DNS packets include packets with a length exceeding 1024 bytes or with abnormal QNAME characters; A3. Synchronize traffic metrics to user space within 1ms using eBPF Maps. Traffic metrics include QSP and source IP distribution.

4. The high-performance intelligent DNS firewall system according to claim 1, characterized in that: To avoid cross-core scheduling overhead, the user-mode optimization module adopts an architecture of one event-loop per core, binds to the CPU core, and achieves zero-memory copy between kernel mode and user mode through mmap shared memory. Furthermore, it enables inter-module communication based on thread-local storage and lock-free queues.

5. The high-performance intelligent DNS firewall system according to claim 1, characterized in that: The hierarchical bucket domain name rate limiting engine adopts a hierarchical structure of 1024 first-level buckets + 2048 second-level buckets. It quickly locates domain names based on their hash values ​​and dynamically adjusts bucket capacity. The capacity of high-frequency domain name buckets can be increased by an adjustable multiplier. It queries domain name buckets every 30 minutes and automatically reclaims memory. The hierarchical bucket domain name rate limiting engine supports simultaneous rate limiting of 20 million domain names. The time for a single rule update is less than or equal to 50ms, and the memory usage is reduced to less than 2GB.

6. The high-performance intelligent DNS firewall system according to claim 1, characterized in that: When using the real-time anomaly detection module for anomaly detection, the following method is employed: Feature extraction: 12 types of DNS traffic features were extracted and standardized using standard scores. Model optimization: A time-series anomaly detection model using a long short-term memory autoencoder is adopted, combined with a 10-second sliding window sampling and attention mechanism, reducing the thrust consumption time to 8ms. Streaming processing, based on the Flink framework, enables the analysis of 500,000 DNS logs per second with a latency of less than or equal to 200ms; The rules are linked, and abnormal IPs are automatically added to the blacklist upon detection. The attack interception response time is less than or equal to 1 second.

7. The high-performance intelligent DNS firewall system according to claim 1, characterized in that: The user-end management module uses OAuth2.0+JWT to implement device identity authentication, supports multi-tenant management, and issues protection rules according to the tenant dimension. It also stores user query volume data based on MongoDB, supports billing based on QPS / domain quantity, and has a statistical error of less than or equal to 0.1%.

8. The high-performance intelligent DNS firewall system according to claim 7, characterized in that: For the OAuth2.0+JWT authentication system, a JWT dynamic key is used, and the signing key is rotated every hour to prevent replay attacks. In addition, the device fingerprint is bound, and the JWT contains the device hardware hash value to prevent token theft.

9. The high-performance intelligent DNS firewall system according to claim 1, characterized in that: The visualization platform monitors multiple indicators in real time and refreshes every 1 second. It displays the distribution of attack sources through a geographic heatmap, supports filtering by attack type, and has a historical data query response time of less than or equal to 3 seconds. It also enables visual editing of IP blacklists and whitelists and domain rate limit thresholds, with configuration taking effect in less than or equal to 10 seconds. The visualization platform is based on Ansible to achieve automated deployment, shortening deployment time and supporting automatic fault recovery.

10. A high-performance intelligent DNS firewall system according to claim 9, characterized in that: Real-time monitoring is implemented based on long-connection communication of Vue3 components, combined with high-concurrency data processing of Go coroutines in the backend analysis and management server; attack situation awareness is implemented by integrating ECharts GL for geographic information visualization, and the backend analysis and management server uses the GeoIP2 database for IP address resolution; during dynamic configuration, a graphical form is provided to generate configuration commands, which are then sent to the backend analysis and management server via a RESTful API. Automated deployment is based on writing automated deployment scripts using Ansible, combined with Systemd health checks and watchdog scripts.

Images