DNS cache optimization system based on multi-node collaboration

Abstract

The invention discloses a DNS (Domain Name Server) cache optimization system based on multi-node collaboration, which is suitable for public DNS, operator recursion, CDN (Content Delivery Network) scheduling and cloud native scenes. The system is composed of an edge recursion node, a shared second-level cache layer, a cooperative forwarding and near-source rollback module, a distributed active refreshing and lease cooperation module, a cache key generation and routing module and a toughness mechanism module. The domain name and the client network segment are taken as main keys, and the ECS and the two-stage consistent Hash are combined to realize request viscosity and fragmentation stability; when a local miss occurs, preferentially forwarding to a same network segment / same city-same operator / same region collaborative node, and then returning to share cache and authority; a coordination node is elected and refreshed according to domain name fragments, active refreshing of hotspots and immediate entries is driven by lease + priority, and group frightening is avoided through push / pull diffusion; toughness capabilities such as request merging, fusing degradation, health detection and the like are provided, and automatic near-source fallback and removal of abnormities are achieved. According to the method, the hit rate and the first packet delay can be remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of network layer address allocation or management technology, specifically a DNS caching optimization system based on multi-node collaboration. Background Technology

[0002] Currently, most internet recursive DNS services expose a unified IP address using Anycast + BGP routing, allowing users to access the nearest recursive node for their queries. However, due to ISP interconnection policies, cross-domain routing fluctuations, and node load differences, "nearest access" often results in "farthest node access" in practice: clients are routed to recursive nodes that are physically far away or from different ISPs, leading to correct resolution results but high latency. Furthermore, the node's local cache may be missing hotspot records, necessitating an upstream lookup. Single-node cache hit rates are limited by their own historical access distribution, making it difficult to aggregate hotspots across the entire network. This results in numerous duplicate lookups during peak or sudden access scenarios, increasing the load on authoritative DNS and cross-network bandwidth consumption. In addition, traditional recursive nodes often use the complete FQDN + record type as the cache key, which is coarse-grained and cannot distinguish the differentiated resolution needs of the same domain name across different client network segments, easily leading to cache pollution and suboptimal scheduling.

[0003] To address the limited cache hit rate of single nodes, the industry has proposed adding a shared secondary cache (or mirror cache center) before the recursive layer. Multiple edge nodes write query mirrors to this layer, or this layer directly provides aggregated results for hot domains, thereby reducing duplicate requests to authoritative DNS. While such solutions can significantly improve the hit rate and reduce outbound traffic when hotspots are concentrated, they still have significant shortcomings in practical deployments:

[0004] Poor adaptability to sudden hotspot changes: Updates to shared caches often rely on passive origin pulls or timed full synchronizations, making it difficult to capture sudden surges in access to hot domains in a short period of time, which can easily lead to cache gaps.

[0005] Weak cache consistency management: When multiple nodes concurrently refresh the same hot spot, it is easy to trigger the "thundering herd effect", which leads to a sudden increase in upstream pressure; the lack of an effective lease and sharding coordination mechanism makes it easy to have update delays or conflicts.

[0006] Insufficient precision in cross-domain and regional scheduling: The cache key does not take into account the client network segment or fine regional attributes, resulting in the same domain name receiving the same cache result in different subnets, which may cause cross-network scheduling deviations and performance degradation.

[0007] Lack of failover and resilience: When shared cache nodes or collaborative nodes fail, existing solutions often lack near-source automatic fallback and expired cache degradation strategies, which can easily lead to parsing interruptions or uneven service degradation.

[0008] To address this, we propose a DNS caching optimization system based on multi-node collaboration. Summary of the Invention

[0009] To achieve the above objectives, the present invention provides the following technical solution: a DNS caching optimization system based on multi-node collaboration, comprising:

[0010] Multiple geographically distributed edge recursive nodes are used to receive and respond to client DNS queries;

[0011] At least one shared secondary cache layer is deployed between the edge recursive nodes and the authoritative DNS to aggregate and provide hot domain name resolution results;

[0012] The collaborative forwarding and near-source fallback module is set in the edge recursive node. When the local cache of the edge node is not hit, the query is forwarded to the collaborative edge node that is in the same network segment, the same city-operator, or the same region as the client. If the collaborative edge node is not hit or is abnormal, the query falls back to the shared second-level cache layer or the authoritative DNS.

[0013] The distributed proactive refresh and lease coordination module is used to elect refresh coordination nodes based on domain name shards, perform proactive refresh on hot domain names and near-expiring entries, and distribute the refresh results within the cluster;

[0014] The cache key generation and routing module is used to generate cache keys with "domain name + client network segment" as the primary key, and to stick requests to specific edge nodes and shared cache shards based on two-level consistent hashing;

[0015] The near-source fallback and anomaly takeover module is used to automatically switch to other near-source or same-region collaborative nodes or shared cache layers when a collaborative node is abnormal or the response times out.

[0016] The resilience mechanism module is used to enable expired caching services, request merging, circuit breaking and degradation strategies to ensure continuous parsing capabilities in abnormal scenarios.

[0017] Preferably, the shared second-level cache layer includes:

[0018] The cache write agent is used to receive non-recursive query or mirror traffic from edge nodes and write it to the shared cache;

[0019] The hotspot aggregation and fast expiration unit is used to aggregate and store high-frequency domain names and support fast expiration and batch elimination.

[0020] The request merging and batch processing unit is used to merge concurrent requests for the same key and return them to the origin in batch processing mode.

[0021] The data distribution and subscription unit is used to push the refreshed records to relevant edge nodes and shared cache shards, or to respond to pull requests from edge nodes.

[0022] Preferably, the cooperative forwarding and near-source fallback module further includes:

[0023] A topology and affinity library for maintaining affinity relationships between client network segments, city-carrier, region, and edge nodes;

[0024] A forwarding decision engine is used to select the optimal cooperating node based on the affinity library and node health status.

[0025] The rollback priority strategy is used to define the rollback order and timeout threshold for "cooperating nodes → shared secondary cache layer → authoritative DNS".

[0026] Preferably, the distributed active refresh and lease coordination module further includes:

[0027] Sharding and election units are used to divide a domain name into multiple shards based on the domain name hash value and to refresh the coordination node for each shard election.

[0028] The lease and priority strategy unit is used to assign leases and priorities to refresh tasks to avoid repeated refreshes and hot spot fluctuations.

[0029] The diffusion and replay unit is used to push the refresh results to edge nodes and the shared cache layer in an incremental manner, or to replay unconfirmed nodes.

[0030] Preferably, the cache key generation and routing module further includes:

[0031] ECS Awareness Unit, used to parse and normalize EDNS Client Subnet information to generate subnet-level cache keys;

[0032] Two-level consistent hashing units are used to achieve request stickiness and sharding stability at the "edge node layer" and "shared cache layer," respectively.

[0033] Key space partitioning units are used to support partitioning and managing key spaces by domain name suffix, business type, or priority.

[0034] Preferably, the resilience mechanism module further includes:

[0035] The expired cache service unit is used to provide expired but usable parsing results and mark them with a degradation flag when the authoritative source is unreachable or the response times out;

[0036] The request merging and rate limiting unit is used to merge concurrent requests for the same key and limit the rate of return to the origin.

[0037] The health detection and circuit breaker unit is used to periodically detect edge nodes and shared cache fragments, and trigger circuit breakers and removal when anomalies occur.

[0038] Preferably, it also includes an interface that decouples the data plane from the control plane, wherein:

[0039] The data plane is used to carry DNS queries / responses, mirror traffic, and refresh pushes;

[0040] The control plane is used to maintain affinity libraries, sharding and election states, leases and policy configurations, and dynamically update data plane behavior through the policy distribution interface.

[0041] DNS caching optimization methods based on multi-node collaboration include:

[0042] The edge recursive node receives client DNS queries and queries the local cache using "domain name + client network segment" as the primary key;

[0043] If no match is found locally, query the collaborative forwarding and near-source fallback module, and select a collaborative edge node in the same network segment, the same city-operator, or the same region for forwarding;

[0044] If the cooperating node is not found or is abnormal, the query will be forwarded to the shared second-level cache layer; if the shared cache layer is not found, it will fall back to the authoritative DNS.

[0045] Write responses from authoritative DNS or shared cache layers to local and shared cache layers, and trigger proactive refresh of relevant keys based on lease and priority;

[0046] In abnormal scenarios, enable expired caching services, request merging, and circuit breaker degradation strategies to ensure parsing continuity.

[0047] Preferably, the active refresh includes:

[0048] Elect refresh coordination nodes by domain name sharding and assign leases and priorities to refresh tasks;

[0049] During the lease term, actively query popular domain names and entries nearing expiration, and push new records to edge nodes and shared cache layer;

[0050] Refresh and replay the results for nodes that have not confirmed receipt to ensure consistency of the view within the cluster;

[0051] The near-source regression includes:

[0052] The system selects cooperative nodes based on topology and affinity libraries, and automatically switches to other cooperative nodes in the same or near-source region when a cooperative node is abnormal or its response times out.

[0053] When both the cooperating node and the shared cache layer are abnormal, the system will fall back to the authoritative DNS and retain the degraded usable results in the local cache.

[0054] Compared with existing technologies, this invention provides a DNS caching optimization system based on multi-node collaboration, which has the following beneficial effects:

[0055] 1. This multi-node collaborative DNS caching optimization system, through a combination of collaborative forwarding and near-source fallback, network segment-level cache keys, and two-level consistent hashing, prioritizes routing queries to collaborative edge nodes located in the same network segment, city / carrier, or region as the client when the local cache misses. This achieves "fast hit within the same city / network segment" in hot domain scenarios. Compared to traditional single-node or coarse-grained Anycast routing, this strategy significantly reduces cross-domain resolution and long-latency paths caused by "remote nodes," especially in mobile internet, video-on-demand, and online games where first-packet latency is critical. It can reduce the user-perceived DNS resolution RTT by tens to hundreds of milliseconds. The network segment-level cache key combined with ECS awareness avoids cross-network scheduling bias caused by users in different subnets sharing the same cache record, ensuring that the same domain name obtains the optimal IP list in different client network segments, thereby further improving the hit rate and access quality of CDN / edge nodes.

[0056] 2. This multi-node collaborative DNS caching optimization system introduces a shared secondary cache layer and a distributed proactive refresh and lease coordination mechanism. It forms an aggregated storage pool of hot domain names before the recursive layer, allowing multiple edge nodes to reuse the same verified hot records, avoiding repeated origin queries for the same domain. The shared cache layer supports request merging and batch origin queries, compressing instantaneous high-concurrency queries into a small number of upstream requests, significantly reducing the QPS peak of authoritative DNS and cross-network outbound traffic. The proactive refresh module, based on shard election and lease strategies, has a few coordinating nodes update hot and near-expiring entries in advance during the lease period, and quickly synchronizes them within the cluster through incremental push and replay. This prevents the "thundering herd effect" from causing a sudden surge in upstream pressure while ensuring the consistency of the cluster's cache view. As a result, the overall query volume of authoritative DNS and cross-ISP bandwidth overhead are significantly reduced. For large operators or public DNS service providers, this can save considerable operating costs and improve the stability of upstream cooperation.

[0057] 3. This DNS caching optimization system based on multi-node collaboration constructs a multi-layered fault-tolerant system through near-source fallback and anomaly takeover, resilience mechanisms, and decoupling of the control plane and data plane. When a collaborative node times out or detects an anomaly, the system automatically switches to a near-source node or other healthy collaborative nodes, and then falls back to the shared cache layer and authoritative DNS in sequence, forming a progressive fault-tolerant path. When the authoritative DNS is unreachable or there is network jitter, the Serve-Stale service can provide expired but still usable resolution results and mark them for degradation, maximizing business continuity. Combined with request merging, circuit breaking and degradation strategies, and periodic health probes, abnormal instances can be quickly removed when nodes or shards fail, preventing fault propagation. Two-level consistent hashing and shard election mechanisms ensure minimal changes to cache key mappings when adding nodes or expanding shards, achieving linear scalability without causing large-scale cache invalidation or hotspot migration. This resilience design enables the system to maintain stable resolution capabilities even in complex scenarios such as sudden traffic spikes, node downtime, and upstream failures, meeting the high availability requirements of telecom-grade and ultra-large public cloud DNS services. Detailed Implementation

[0058] The technical solutions in the embodiments of the present invention will be clearly and completely described below. 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.

[0059] Example

[0060] Implementation Examples of DNS Cache Optimization Systems Based on Multi-Node Collaboration

[0061] A DNS caching optimization system based on multi-node collaboration includes:

[0062] Multiple geographically distributed edge recursive nodes are used to receive and respond to client DNS queries;

[0063] At least one shared secondary cache layer is deployed between the edge recursive nodes and the authoritative DNS to aggregate and provide hot domain name resolution results;

[0064] The collaborative forwarding and near-source fallback module is set in the edge recursive node. When the local cache of the edge node is not hit, the query is forwarded to the collaborative edge node that is in the same network segment, the same city-carrier, or the same region as the client. If the collaborative edge node is not hit or is abnormal, it falls back to the shared second-level cache layer or authoritative DNS.

[0065] The distributed proactive refresh and lease coordination module is used to elect refresh coordination nodes based on domain name shards, perform proactive refresh on hot domain names and near-expiring entries, and distribute the refresh results within the cluster;

[0066] The cache key generation and routing module is used to generate cache keys with "domain name + client network segment" as the primary key, and to stick requests to specific edge nodes and shared cache shards based on two-level consistent hashing;

[0067] The near-source fallback and anomaly takeover module is used to automatically switch to other near-source or same-region collaborative nodes or shared cache layers when a collaborative node is abnormal or the response times out.

[0068] The resilience mechanism module is used to enable expired caching services, request merging, circuit breaking and degradation strategies to ensure continuous parsing capabilities in abnormal scenarios.

[0069] Specifically, the shared second-level cache layer includes:

[0070] The cache write agent is used to receive non-recursive query or mirror traffic from edge nodes and write it to the shared cache;

[0071] The hotspot aggregation and fast expiration unit is used to aggregate and store high-frequency domain names and support fast expiration and batch elimination.

[0072] The request merging and batch processing unit is used to merge concurrent requests for the same key and return them to the origin in batch processing mode.

[0073] The data distribution and subscription unit is used to push the refreshed records to relevant edge nodes and shared cache shards, or to respond to pull requests from edge nodes.

[0074] Specifically, the collaborative forwarding and near-source fallback module further includes:

[0075] A topology and affinity library for maintaining affinity relationships between client network segments, city-carrier, region, and edge nodes;

[0076] A forwarding decision engine is used to select the optimal cooperating node based on the affinity library and node health status.

[0077] The rollback priority strategy is used to define the rollback order and timeout threshold for "cooperating nodes → shared secondary cache layer → authoritative DNS".

[0078] Specifically, the distributed proactive refresh and lease coordination module further includes:

[0079] Sharding and election units are used to divide a domain name into multiple shards based on the domain name hash value and to refresh the coordination node for each shard election.

[0080] The lease and priority strategy unit is used to assign leases and priorities to refresh tasks to avoid repeated refreshes and hot spot fluctuations.

[0081] The diffusion and replay unit is used to push the refresh results to edge nodes and the shared cache layer in an incremental manner, or to replay unconfirmed nodes.

[0082] Specifically, the cache key generation and routing module further includes:

[0083] ECS Awareness Unit, used to parse and normalize EDNS Client Subnet information to generate subnet-level cache keys;

[0084] Two-level consistent hashing units are used to achieve request stickiness and sharding stability at the "edge node layer" and "shared cache layer," respectively.

[0085] Key space partitioning units are used to support partitioning and managing key spaces by domain name suffix, business type, or priority.

[0086] Specifically, the resilience mechanism module further includes:

[0087] The expired cache service unit is used to provide expired but usable parsing results and mark them with a degradation flag when the authoritative source is unreachable or the response times out;

[0088] The request merging and rate limiting unit is used to merge concurrent requests for the same key and limit the rate of return to the origin.

[0089] The health detection and circuit breaker unit is used to periodically detect edge nodes and shared cache fragments, and trigger circuit breakers and removal when anomalies occur.

[0090] Specifically, this also includes the interface for decoupling the data plane from the control plane, wherein:

[0091] The data plane is used to carry DNS queries / responses, mirror traffic, and refresh pushes;

[0092] The control plane is used to maintain affinity libraries, sharding and election states, leases and policy configurations, and dynamically update data plane behavior through the policy distribution interface.

[0093] DNS caching optimization methods based on multi-node collaboration include:

[0094] The edge recursive node receives client DNS queries and queries the local cache using "domain name + client network segment" as the primary key;

[0095] If no match is found locally, query the collaborative forwarding and near-source fallback module, and select a collaborative edge node in the same network segment, the same city-operator, or the same region for forwarding;

[0096] If the cooperating node is not found or is abnormal, the query will be forwarded to the shared second-level cache layer; if the shared cache layer is not found, it will fall back to the authoritative DNS.

[0097] Write responses from authoritative DNS or shared cache layers to local and shared cache layers, and trigger proactive refresh of relevant keys based on lease and priority;

[0098] In abnormal scenarios, enable expired caching services, request merging, and circuit breaker degradation strategies to ensure parsing continuity.

[0099] Specifically, active refresh includes:

[0100] Elect refresh coordination nodes by domain name sharding and assign leases and priorities to refresh tasks;

[0101] During the lease term, actively query popular domain names and entries nearing expiration, and push new records to edge nodes and shared cache layer;

[0102] Refresh and replay the results for nodes that have not confirmed receipt to ensure consistency of the view within the cluster;

[0103] Proximal regression includes:

[0104] The system selects cooperative nodes based on topology and affinity libraries, and automatically switches to other cooperative nodes in the same or near-source region when a cooperative node is abnormal or its response times out.

[0105] When both the cooperating node and the shared cache layer are abnormal, the system will fall back to the authoritative DNS and retain the degraded usable results in the local cache.

[0106] Through the above technical solution, this invention combines collaborative forwarding with near-source fallback, network segment-level cache keys, and two-level consistent hashing. When a query misses a local cache hit, it prioritizes routing to a collaborative edge node located in the same network segment, city / carrier, or region as the client. This achieves "fast hit within the same city / network segment" in hot domain scenarios. Compared to traditional single-node or coarse-grained Anycast routing, this strategy significantly reduces cross-domain resolution and long-latency paths caused by "remote nodes," especially in mobile internet, video-on-demand, and online games—services sensitive to first-packet latency—reducing the user-perceived DNS resolution RTT by tens to hundreds of milliseconds. The network segment-level cache key, combined with ECS awareness, avoids cross-network scheduling bias caused by users in different subnets sharing the same cache record, ensuring the same domain name receives the optimal IP list across different client network segments, thereby further improving the hit rate and access quality of CDN / edge nodes. By introducing a shared secondary cache layer and a distributed proactive refresh and lease coordination mechanism, an aggregated storage pool of hot domain names is formed before the recursive layer. This allows multiple edge nodes to reuse the same verified hot record, avoiding repeated origin queries for the same domain. The shared cache layer supports request merging and batch origin queries, compressing instantaneous high-concurrency queries into a small number of upstream requests, significantly reducing the QPS peak of authoritative DNS and cross-network outbound traffic. The proactive refresh module, based on shard election and lease strategies, allows a few coordinating nodes to update hot and near-expiring entries in advance during the lease period. Incremental push and replay enable rapid synchronization within the cluster, preventing the "thundering herd effect" from causing a sudden surge in upstream pressure and ensuring the consistency of the cluster's cached view. As a result, the overall query volume of authoritative DNS and cross-ISP bandwidth overhead are significantly reduced. For large operators or public DNS service providers, this can save considerable operating costs and improve the stability of upstream cooperation. This invention constructs a multi-layered fault-tolerant system through near-source fallback and anomaly takeover, resilience mechanisms, and decoupling of the control plane and data plane. When a cooperating node times out or detects an anomaly, the system automatically switches to the near-source node or other healthy cooperating nodes, and then falls back to the shared cache layer and authoritative DNS in sequence, forming a progressive fault-tolerant path. When the authoritative DNS is unreachable or there is network jitter, the Serve-Stale service can provide expired but still usable DNS resolution results and mark them for degradation, maximizing business continuity. Combined with request merging, circuit breaking, degradation strategies, and periodic health probes, abnormal instances can be quickly removed when nodes or shards fail, preventing fault propagation. Two-level consistent hashing and shard election mechanisms ensure minimal changes to cache key mappings when adding nodes or expanding shards, achieving linear scalability without causing large-scale cache invalidation or hotspot migration.This resilient design enables the system to maintain stable resolution capabilities even in complex scenarios such as sudden traffic surges, node outages, and upstream failures, meeting the high availability requirements of carrier-grade and ultra-large public cloud DNS services.

[0107] System Architecture and Modules

[0108] Edge recursive nodes: enable query parsing, local caching, ECS parsing, collaborative forwarding, near-source rollback, and health reporting; built-in request merging window and circuit breaker threshold.

[0109] Shared secondary cache layer: Composed of multiple instance shards, supporting mirror writing, read-write penetration, hotspot aggregation, fast expiration, request merging, and incremental push / replay.

[0110] Control plane services: Maintaining the network segment / city-carrier / region affinity database, domain name sharding and refresh coordination node election, lease and policy distribution, health detection and removal policy orchestration.

[0111] Data plane interfaces: DNS protocol interface (UDP / TCP / DoH / DoT), gRPC / HTTP control interface, streaming push channel (for refreshing result distribution).

[0112] Typical processing flow

[0113] Query reception: Edge nodes parse the query and standardize it for ECS, generating a cache key using "domain name + client network segment" to query the local cache.

[0114] Local hit: Directly respond and update usage statistics; if the record is about to expire, asynchronously trigger passive refresh or add it to the refresh candidate queue.

[0115] Local miss: Invoke the collaborative forwarding and near-source fallback module, and prioritize forwarding to collaborative nodes in the same network segment / city-same operator / region; if the collaborative node misses or is abnormal, it will switch to the shared second-level cache layer; if it still misses, it will fall back to the authoritative DNS.

[0116] Origin retrieval and writing: After obtaining the response from the upstream, write it to the local cache and shared cache layer; if the response contains a CNAME chain, then perform parallel / serial parsing and writing on each node of the chain.

[0117] Active refresh: The refresh coordination node performs active queries on hot and near-expiration keys based on lease and priority; new records are quickly disseminated within the cluster through push / replay to avoid "thundering herd".

[0118] Anomalies and resilience: Enables expired caching service (Serve-Stale), request merging, and circuit breaker degradation; nodes that fail health checks are quickly removed, and traffic is automatically redirected to nearby or same-region nodes.

[0119] Key strategies and parameter examples

[0120] Cache key: Key = Hash(domain name|| client network segment|| record type) (+ optional QNAME canonical suffix); ECS normalization granularity recommendation / 24 (IPv4) / 48 (IPv6).

[0121] Two-level consistent hashing: The first level is used for "client → edge node", and the second level is used for "domain name + network segment → shared cache shard". The recommended number of virtual nodes is ≥100 / shard.

[0122] Active refresh: Hotspot threshold = Top N% of requests or QPS ≥ threshold; Lease T_refresh is slightly less than 1 / 2 of the minimum TTL; Batch refresh concurrency and rate limits are configurable.

[0123] Request merge: Merge window W_merge with the same key (e.g., 10–50 ms); after merging, only one upstream query is initiated, and the result is broadcast to merge waiters.

[0124] Near-source rollback: Timeout T_forward is graded (50–100 ms for cooperating nodes, 100–200 ms for shared cache); anomaly detection uses consecutive failure count and error rate threshold.

[0125] Resilience: Serve-Stale maximum T_stale (e.g., 24–72 h), enabled only for SERVFAIL / timeout; circuit breaker recovery uses exponential backoff and liveness detection success thresholds.

[0126] Deployment and Evolution

[0127] Initially: Deploy 3–5 edge nodes + 1–2 shared cache shards in each region; centrally deploy the control plane and shard the data plane by region.

[0128] Mid-term: Introduce a cross-regional shared caching layer and inter-regional affinity; hot domain names will adopt a dual-channel strategy of "near-source collaboration + regional sharing".

[0129] Long-term: Integrating with CDN / cloud vendor scheduling systems, dynamically optimizing affinity and fallback paths based on network segment-level mapping and measured RTT.

[0130] 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 DNS caching optimization system based on multi-node collaboration, characterized in that: include: Multiple geographically distributed edge recursive nodes are used to receive and respond to client DNS queries; At least one shared secondary cache layer is deployed between the edge recursive nodes and the authoritative DNS to aggregate and provide hot domain name resolution results; The collaborative forwarding and near-source fallback module is set in the edge recursive node. When the local cache of the edge node is not hit, the query is forwarded to the collaborative edge node that is in the same network segment, the same city-operator, or the same region as the client. If the collaborative edge node is not hit or is abnormal, the query falls back to the shared second-level cache layer or the authoritative DNS. The distributed proactive refresh and lease coordination module is used to elect refresh coordination nodes based on domain name shards, perform proactive refresh on hot domain names and near-expiring entries, and distribute the refresh results within the cluster; The cache key generation and routing module is used to generate cache keys with "domain name + client network segment" as the primary key, and to stick requests to specific edge nodes and shared cache shards based on two-level consistent hashing; The near-source fallback and anomaly takeover module is used to automatically switch to other near-source or same-region collaborative nodes or shared cache layers when a collaborative node is abnormal or the response times out. The resilience mechanism module is used to enable expired caching services, request merging, circuit breaking and degradation strategies to ensure continuous parsing capabilities in abnormal scenarios.

2. The DNS caching optimization system based on multi-node collaboration according to claim 1, characterized in that: The shared second-level cache layer includes: The cache write agent is used to receive non-recursive query or mirror traffic from edge nodes and write it to the shared cache; The hotspot aggregation and fast expiration unit is used to aggregate and store high-frequency domain names and support fast expiration and batch elimination. The request merging and batch processing unit is used to merge concurrent requests for the same key and return them to the origin in batch processing mode. The data distribution and subscription unit is used to push the refreshed records to relevant edge nodes and shared cache shards, or to respond to pull requests from edge nodes.

3. The DNS caching optimization system based on multi-node collaboration according to claim 1, characterized in that: The collaborative forwarding and near-source fallback module further includes: A topology and affinity library for maintaining affinity relationships between client network segments, city-carrier, region, and edge nodes; A forwarding decision engine is used to select the optimal cooperating node based on the affinity library and node health status. The rollback priority strategy is used to define the rollback order and timeout threshold for "cooperating nodes → shared secondary cache layer → authoritative DNS".

4. The DNS caching optimization system based on multi-node collaboration according to claim 1, characterized in that: The distributed active refresh and lease coordination module further includes: Sharding and election units are used to divide a domain name into multiple shards based on the domain name hash value and to refresh the coordination node for each shard election. The lease and priority strategy unit is used to assign leases and priorities to refresh tasks to avoid repeated refreshes and hot spot fluctuations. The diffusion and replay unit is used to push the refresh results to edge nodes and the shared cache layer in an incremental manner, or to replay unconfirmed nodes.

5. The DNS caching optimization system based on multi-node collaboration according to claim 1, characterized in that: The cache key generation and routing module further includes: ECS Awareness Unit, used to parse and normalize EDNS Client Subnet information to generate subnet-level cache keys; Two-level consistent hashing units are used to achieve request stickiness and sharding stability at the "edge node layer" and "shared cache layer," respectively. Key space partitioning units are used to support partitioning and managing key spaces by domain name suffix, business type, or priority.

6. The DNS caching optimization system based on multi-node collaboration according to claim 1, characterized in that: The resilience mechanism module further includes: The expired cache service unit is used to provide expired but usable parsing results and mark them with a degradation flag when the authoritative source is unreachable or the response times out; The request merging and rate limiting unit is used to merge concurrent requests for the same key and limit the rate of return to the origin. The health detection and circuit breaker unit is used to periodically detect edge nodes and shared cache fragments, and trigger circuit breakers and removal when anomalies occur.

7. The DNS caching optimization system based on multi-node collaboration according to claim 1, characterized in that: It also includes an interface for decoupling the data plane from the control plane, wherein: The data plane is used to carry DNS queries / responses, mirror traffic, and refresh pushes; The control plane is used to maintain affinity libraries, sharding and election states, leases and policy configurations, and dynamically update data plane behavior through the policy distribution interface.

8. A DNS caching optimization method based on multi-node collaboration, characterized in that: include: The edge recursive node receives client DNS queries and queries the local cache using "domain name + client network segment" as the primary key; If no match is found locally, query the collaborative forwarding and near-source fallback module, and select a collaborative edge node in the same network segment, the same city-operator, or the same region for forwarding; If the cooperating node is not found or is abnormal, the query will be forwarded to the shared second-level cache layer; if the shared cache layer is not found, it will fall back to the authoritative DNS. Write responses from authoritative DNS or shared cache layers to local and shared cache layers, and trigger proactive refresh of relevant keys based on lease and priority; In abnormal scenarios, enable expired caching services, request merging, and circuit breaker degradation strategies to ensure parsing continuity.

9. The DNS caching optimization method based on multi-node collaboration according to claim 8, characterized in that: The active refresh includes: Elect refresh coordination nodes by domain name sharding and assign leases and priorities to refresh tasks; During the lease term, actively query popular domain names and entries nearing expiration, and push new records to edge nodes and shared cache layer; Refresh and replay the results for nodes that have not confirmed receipt to ensure consistency of the view within the cluster; The near-source regression includes: The system selects cooperative nodes based on topology and affinity libraries, and automatically switches to other cooperative nodes in the same or near-source region when a cooperative node is abnormal or its response times out. When both the cooperating node and the shared cache layer are abnormal, the system will fall back to the authoritative DNS and retain the degraded usable results in the local cache.