A multi-instance domain name resolution caching method, apparatus, device and medium
By configuring a DNS cache instance for each network egress line and associating it with an upstream DNS server, combined with policy routing and real-time monitoring, the latency and stability issues of traditional DNS resolution in multi-egress line environments are resolved. Dynamic adjustment and seamless switching of DNS queries are achieved, improving user experience and system performance.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- LINGBO TECH (BEIJING) CO LTD
- Filing Date
- 2025-12-29
- Publication Date
- 2026-05-22
AI Technical Summary
Traditional DNS resolution methods cannot be dynamically adjusted in multi-exit network environments, leading to increased DNS query latency, resolution failures, and performance degradation, which negatively impacts user experience.
Configure a corresponding DNS cache instance for each network egress line and associate it with the operator's primary upstream DNS server. Through policy routing and real-time monitoring of network status, dynamically adjust the routing of DNS query requests to ensure a rapid switch to backup lines in the event of network failure or overload.
It improves the efficiency and stability of DNS resolution, reduces latency and cross-network traffic, optimizes network resource utilization, and enhances user experience and system adaptability.
Smart Images

Figure CN121441885B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing, specifically to a multi-instance domain name resolution caching method, apparatus, device, and medium. Background Technology
[0002] Domain Name System (DNS) technology is a crucial infrastructure element of the internet, used to resolve user-input domain names into IP addresses that computers can recognize, thereby enabling network communication. In network environments with multiple exit points and multiple ISPs, to improve network performance, it is usually necessary to select appropriate upstream DNS servers for domain name resolution based on different network exit lines. However, traditional DNS resolution methods typically use fixed upstream DNS server configurations, failing to dynamically adjust the DNS resolution path according to different network exit lines. This approach easily leads to increased DNS query latency, resolution failures, and performance degradation when accessing cross-ISP networks in multi-exit line environments, severely impacting the user's network experience.
[0003] To address the aforementioned issues, existing technologies propose a DNS resolution method that optimizes DNS resolution by configuring independent DNS servers for different network egress lines and utilizing a policy-based routing mechanism to direct DNS query requests to specific egress lines. This technology, by combining local DNS caching and policy-based routing, can reduce cross-network access latency to a certain extent, improve DNS resolution efficiency, and decrease the probability of resolution failures due to poor network egress line conditions.
[0004] However, while existing technologies can optimize DNS resolution in multi-egress network environments, they lack the ability to dynamically adjust. When a particular egress network experiences a problem, DNS query requests may still be routed to that network, leading to domain name resolution interruptions or performance degradation. Therefore, existing technologies cannot achieve real-time switching based on egress network status or dynamic adjustment of DNS cache instances, making it difficult to guarantee the stability of DNS resolution services. Summary of the Invention
[0005] This application provides a multi-instance domain name resolution cache, device, equipment, and medium, which improves the stability of DNS resolution services.
[0006] The first aspect of this application provides a multi-instance domain name resolution caching method. In this method, for multiple network egress lines, a corresponding DNS cache instance is configured for each network egress line; a corresponding local listening port is allocated to each DNS cache instance, and each DNS cache instance is associated with the primary upstream DNS server address of the operator to which the corresponding network egress line belongs; an association configuration table is generated, the association configuration table including the correspondence between network egress lines, DNS cache instances, and primary upstream DNS server addresses; the initial egress line of a user terminal is determined, and based on the association configuration table, the destination address of a DNS query request initiated by the user terminal is directed to the first DNS cache instance corresponding to the initial egress line and the target local listening port corresponding to the first DNS cache instance through policy routing; the operating status of the network egress line is monitored, and if it is determined that the first network egress line currently used by the user terminal has failed or is overloaded, a new network egress line is determined for the user terminal according to a preset switching policy; the policy routing associated with the user terminal is updated, and the destination address of subsequent DNS query requests initiated by the user terminal is redirected to the second DNS cache instance corresponding to the new network egress line.
[0007] By adopting the above technical solution, configuring a corresponding DNS cache instance for each network egress line and associating it with the operator's primary upstream DNS server, the latency of DNS queries can be reduced. This approach avoids unnecessary access to upstream DNS servers across network egress lines, thereby improving the efficiency and stability of DNS resolution. Through policy routing and association configuration tables, user terminal DNS query requests can be dynamically directed to the appropriate DNS cache instance. When a network egress line fails or becomes overloaded, DNS query requests can be quickly switched to a new network egress line and its corresponding DNS cache instance according to a preset switching policy. This dynamic adjustment capability ensures uninterrupted DNS resolution service for user terminals. Associating the DNS cache instance with the primary upstream DNS server of each network egress line effectively reduces the need for cross-network access to other operator networks. This not only reduces the latency caused by cross-network resolution but also reduces cross-network traffic, optimizing the utilization of network resources. By monitoring the operational status of network egress lines, line failures or overload issues can be detected in a timely manner, and the DNS query flow of user terminals can be adjusted according to the switching policy. In a multi-carrier environment, different outbound lines may connect to different carrier networks. By configuring a dedicated DNS caching instance for each carrier, optimized DNS resolution for different carriers can be achieved. This approach fully leverages the advantages of each carrier's network, improving overall DNS resolution performance. Using local caching instances, DNS queries can be resolved locally first, reducing the frequency of queries to upstream DNS servers. This not only reduces network bandwidth consumption but also decreases latency, improving user experience. This technical solution, through multi-instance domain name resolution caching, solves the problems of inefficiency, insufficient reliability, poor flexibility, and resource waste inherent in traditional DNS resolution in multi-outbound, multi-carrier environments. It improves the efficiency and reliability of DNS resolution.
[0008] Optionally, configuring a corresponding DNS cache instance for each of the multiple network egress lines specifically includes: obtaining performance index data of all network egress lines in the network system; calculating a comprehensive score for each network egress line based on the performance index data according to preset network egress line evaluation rules, and sorting the network egress lines according to the comprehensive score; setting the network egress line with the highest comprehensive score as the primary network egress line, and setting the network egress lines other than the primary network egress line among the multiple network egress lines as backup network egress lines, and numbering the backup network egress lines according to the comprehensive score from high to low; setting a primary DNS cache instance and configuring the listening port of the primary DNS cache instance as a standard DNS protocol port; setting multiple extended DNS cache instances and assigning a custom listening port different from the standard DNS protocol port to each extended DNS cache instance; associating the primary DNS cache instance with the primary network egress line, and associating each extended DNS cache instance with the backup network egress line according to the numbering order of the backup network egress lines.
[0009] By adopting the above technical solution, performance index data of all network egress lines within the network system is obtained. Based on preset network egress line evaluation rules, a comprehensive score for each egress line is calculated. The primary and backup network egress lines are then sorted according to their scores. This allows for the prioritization and role allocation of multiple network egress lines during the DNS cache instance configuration phase, providing a basis for subsequent request scheduling and instance selection. Simultaneously, by setting up a primary DNS cache instance associated with the primary network egress line and configuring its listening port to a standard DNS port, it is ensured that all regular DNS query requests can be correctly received and processed by the primary DNS cache instance when the primary network egress line is functioning normally. Furthermore, by setting up extended DNS cache instances corresponding one-to-one with backup network egress lines and assigning each extended instance a custom listening port different from the standard port, user requests can be quickly switched to the extended instance corresponding to the most available backup line when the primary network egress line fails, ensuring the continuity and high reliability of DNS services. The custom listening port design also prevents backup instances from being accessed by external parties, improving system security.
[0010] Optionally, after associating the primary DNS cache instance with the primary network egress line and associating each extended DNS cache instance with the backup network egress line according to the numbering order of the backup network egress lines, the method further includes: configuring basic DNS resolution rules and local host record files for the primary DNS cache instance; when initializing the first extended DNS cache instance, synchronizing the basic DNS resolution rules and the local host record file from the primary DNS cache instance as initial configuration parameters for the first extended DNS cache instance, wherein the first extended DNS cache instance is any one of multiple extended DNS cache instances; when the first extended DNS cache instance receives a DNS query request from the user terminal, resolving the DNS query request using the basic DNS resolution rules and the local host record file.
[0011] By adopting the above technical solution, configuring basic DNS resolution rules and local host record files in the primary DNS cache instance, and synchronizing these configuration parameters from the primary instance as the initial configuration of the extended DNS cache instance during initialization, it is possible to ensure that each DNS cache instance has consistent basic resolution capabilities from the service startup phase, improving system availability. Furthermore, since these basic resolution rules and local host records are typically relatively stable and universal configuration information, covering the resolution needs of most common domain names, even after the first extended instance takes over the service, these synchronized configuration parameters can still independently resolve most DNS query requests, avoiding the additional latency introduced by frequent access to upstream DNS servers and improving resolution efficiency. In addition, by centrally configuring and uniformly synchronizing basic resolution rules and host record files, configuration differences and maintenance costs among DNS cache instances can be minimized, simplifying the operation and maintenance process. When updating and optimizing resolution rules, modifications only need to be made on the primary instance, and then automatically synchronized to each extended instance, enabling rapid deployment and effectiveness of configuration changes, improving system maintainability and flexibility.
[0012] Optionally, after configuring a corresponding DNS cache instance for each of the multiple network egress lines, the method further includes: setting a DNS splitting enable flag for the primary DNS cache instance corresponding to the primary network egress line, and setting a DNS splitting disable flag for each of the extended DNS cache instances; periodically probing the availability status of the primary network egress line and each of the backup network egress lines within a preset period; if the primary network egress line is available, activating the DNS splitting function of the primary DNS cache instance, and dynamically splitting the DNS query request to different upstream DNS servers for resolution by identifying the network type and request characteristics of the user terminal's DNS query request; if a failure is detected in the primary network egress line, redirecting the user terminal's DNS query request to the second extended DNS cache instance corresponding to the backup network egress line with the highest comprehensive score; for all DNS query requests received by the second extended DNS cache instance, directly forwarding them to the upstream DNS server associated with the second extended DNS cache instance for resolution, disabling the DNS splitting function, until the primary network egress line recovers its availability.
[0013] By adopting the above technical solution, setting an enabled flag for the primary DNS caching instance and a disabled flag for the extended instances, the DNS routing behavior of different instances can be precisely controlled, avoiding request chaos and conflicts in a multi-instance environment. When the primary network egress line is working normally, enabling the DNS routing function of the primary instance allows for intelligent identification and dynamic routing based on the network type and characteristics of user requests, selectively scheduling requests to the optimal upstream DNS server, improving resolution quality and response speed. Simultaneously, by continuously probing the availability status of the primary and backup network egress lines within a preset period, once a primary line failure is detected, subsequent requests can be automatically switched to the extended DNS caching instance corresponding to the backup line, and the extended instance directly forwards the request to the associated upstream DNS server for resolution, bypassing potentially erroneous intelligent routing logic, thereby ensuring the continuity and reliability of DNS services in the event of a primary line failure. Furthermore, since the extended instances will re-disable the DNS routing function after the primary line recovers, returning intelligent scheduling control to the primary instance, seamless switching and responsibility transfer between primary and backup instances can be achieved, improving the system's fault tolerance and automatic recovery capabilities, and minimizing the business impact of failures.
[0014] Optionally, associating each DNS cache instance with the primary upstream DNS server address of the corresponding network egress line operator specifically includes: obtaining operator information for each network egress line; based on the operator information of the network egress line, querying the corresponding upstream DNS server address list from a preset operator DNS mapping table for each DNS cache instance; if the upstream DNS server address list contains multiple upstream DNS server addresses, testing the response speed and response success rate of each upstream DNS server address through DNS resolution requests; determining the primary upstream DNS server address from the multiple upstream DNS server addresses based on the response speed and the response success rate; configuring the primary upstream DNS server address into the upstream forwarding address list of the corresponding DNS cache instance, thereby completing the association between the DNS cache instance and the primary upstream DNS server address.
[0015] By adopting the above technical solution, the operator information of each network egress line is obtained, and based on this information, the corresponding upstream DNS server address list is queried from the preset operator DNS mapping table. This establishes a mapping relationship between network egress lines, operators, and upstream DNS servers, providing a data foundation for intelligent DNS resolution and improving the system's adaptability to different network environments. Simultaneously, when the upstream DNS server address list corresponding to a DNS cache instance contains multiple addresses, the response speed and success rate of each address are tested through DNS resolution requests. Based on this, the optimal address is selected from the list as the primary upstream DNS server. This allows for the evaluation and selection of the best-performing upstream DNS server during the DNS cache instance initialization phase, optimizing resolution quality. Configuring the selected primary upstream DNS server address into the forwarding address list of the corresponding DNS cache instance completes the association between the instance and the upstream DNS server, ensuring that the instance can select the optimal upstream DNS server for forwarding when processing DNS resolution requests, improving resolution efficiency and success rate. Furthermore, by introducing the preset operator DNS mapping table mechanism, the system can flexibly adapt to the network environments of different operators, facilitating the expansion of new network egress lines. When adding a new outbound line, the system can quickly obtain a list of recommended upstream DNS servers by simply updating the mapping table based on the operator's information. Then, the optimal server can be selected according to the optimization mechanism without manual intervention, thus improving the system's adaptability and scalability.
[0016] Optionally, after redirecting the destination address of the DNS query request initiated by the user terminal to the first DNS cache instance corresponding to the initial egress line and the target local listening port corresponding to the first DNS cache instance through policy routing based on the association configuration table, the method further includes: receiving the redirected DNS query request through the first DNS cache instance; obtaining a set of status data of backend service instances related to the target domain name in the DNS query request from the distributed collection network, the set of status data including real-time network performance indicators of each backend service instance related to the initial egress line, the real-time network performance indicators including latency, packet loss rate and available bandwidth; calculating a corresponding dynamic weight value for each backend service instance based on the set of status data using a preset weight calculation function; constructing a DNS response message based on the dynamic weight value corresponding to each backend service instance, and returning the DNS response information to the user terminal, the DNS response message containing the IP address record of the backend service instance, and the IP address record including a priority value determined according to the dynamic weight value.
[0017] By adopting the above technical solution, after receiving a user's DNS query request through the first DNS cache instance, it obtains real-time status data of backend service instances related to the target domain name in the request from the distributed collection network. This includes real-time network performance indicators of each backend instance related to the initial egress line, such as latency, packet loss rate, and available bandwidth. This allows for accurate understanding of the true service capabilities and network quality of each backend service node in the current network environment. Based on this, a preset weight calculation function is used to calculate a dynamic weight value for each backend service instance. This comprehensively considers multiple network performance indicators, balances the importance of different indicators, and yields a reasonable, dynamically updated service quality score, providing a basis for subsequent intelligent scheduling decisions. Furthermore, the DNS cache instance constructs a DNS response message based on the dynamic weight value of each backend service instance and returns it to the user. The message encapsulates the IP addresses of the instances according to the priority order determined by the dynamic weight value. This allows for prioritizing the recommendation of instances with the best network quality and strongest service capabilities to the user, guiding the user to prioritize service requests to these instances, thereby improving the availability and response speed of user services. Meanwhile, since real-time network performance data is dynamically acquired through a distributed collection network, the entire process can quickly respond to changes in the network environment and service capabilities. This allows the resolution results returned by the DNS cache instance to be highly matched with the current actual network conditions, exhibiting adaptability and real-time performance, improving the accuracy of intelligent scheduling, and thus enhancing the user experience.
[0018] Optionally, monitoring the operational status of the network egress line specifically includes: testing link reachability by sending probe packets to the next-hop gateway device of the network egress line; testing end-to-end network connectivity by sending probe requests to multiple preset external network reference points through the network egress line; obtaining network performance indicators characterizing the status of the network egress line, including latency, packet loss rate, and availability; comparing the network performance indicators with preset performance thresholds; and determining that the network egress line has failed or is overloaded when the network performance indicators do not meet the preset performance thresholds.
[0019] By employing the above technical solution, a NAT gateway device is deployed on the current network egress line. This device monitors the external IP addresses of user terminals accessing the network via the initial egress line, allowing for real-time monitoring of the size and distribution of users currently accessing the network through this line. This provides data for determining whether a user terminal has switched lines. Furthermore, the NAT gateway device detects the source and destination IP addresses in the headers of bidirectional data packets on the initial egress line in real time and compares them with the user's external IP addresses registered in a pre-defined NAT translation table. If a new, unknown external IP address is detected, or if an previously active external IP address is no longer detected within a certain period, it can be determined that the user terminal's access line has changed. After determining that the user's initial egress line has changed, the system can quickly determine the new network egress line corresponding to the user terminal based on the real-time IP address information reported by the NAT gateway device and the mapping relationship between IP address ranges and network egress lines, providing a basis for subsequent request redirection. This real-time monitoring and judgment mechanism for user access lines based on NAT gateway devices can accurately perceive user network status and line switching behavior by directly collecting and analyzing user access data at the network entry and exit points. It boasts fast response speed and low false positive rate, minimizing user request errors and response timeouts caused by line switching and improving the system's adaptability. Furthermore, by utilizing packet header information compared with a preset NAT translation table, the data collection and status judgment process does not involve deep parsing of user data content, protecting user information. This judgment method is also simple and efficient, compatible with existing network architectures and equipment, and requires no modification to user terminals, demonstrating good practicality and deployability.
[0020] A second aspect of this application provides a multi-instance domain name resolution caching device, which includes a DNS configuration module 201, an address association module 202, an association configuration table generation module 203, a DNS request acquisition module 204, and a redirection module 205, wherein: the DNS configuration module 201 is used to configure a corresponding DNS cache instance for each of multiple network egress lines; the address association module 202 is used to allocate a corresponding local listening port for each DNS cache instance and associate each DNS cache instance with the primary upstream DNS server address of the corresponding network egress line's operator; the association configuration table generation module 203 is used to generate an association configuration table, which includes the correspondence between network egress lines, DNS cache instances, and primary upstream DNS server addresses. The DNS request acquisition module 204 is used to determine the initial egress line of the user terminal, and based on the association configuration table, to redirect the destination address of the DNS query request initiated by the user terminal to the first DNS cache instance corresponding to the initial egress line and the target local listening port corresponding to the first DNS cache instance through policy routing. The DNS request acquisition module 204 is also used to monitor the operating status of the network egress line. If it is determined that the first network egress line currently used by the user terminal has failed or is overloaded, a new network egress line is determined for the user terminal according to a preset switching policy. The redirection module 205 is used to update the policy routing associated with the user terminal and redirect the destination address of subsequent DNS query requests initiated by the user terminal to the second DNS cache instance corresponding to the new network egress line.
[0021] A third aspect of this application provides an electronic device including a processor, a memory, a user interface, and a network interface, wherein the memory is used to store instructions, the user interface and the network interface are used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any of the foregoing.
[0022] A fourth aspect of this application provides a computer-readable storage medium storing instructions that, when executed, perform the method described in any of the preceding descriptions.
[0023] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages:
[0024] 1. By creating and binding an independent DNS cache instance to each network egress line, the core problem of inconsistency between the DNS resolution path and the actual data egress in traditional solutions is solved. It monitors the user's egress line in real time and dynamically redirects DNS queries to the instance matching that line, ensuring that users always obtain the optimal server IP from the CDN, thereby eliminating performance degradation caused by "cross-network access." This solution significantly improves user access speed and experience in multi-egress networks, achieves seamless network switching, and enhances the overall reliability of DNS services. Attached Figure Description
[0025] Figure 1 This is a flowchart illustrating a multi-instance domain name resolution caching method disclosed in an embodiment of this application;
[0026] Figure 2 This is a schematic diagram of a module of a multi-instance domain name resolution caching device disclosed in an embodiment of this application;
[0027] Figure 3 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application.
[0028] Explanation of reference numerals in the attached diagram: 201, DNS configuration module; 202, address association module; 203, association configuration table generation module; 204, DNS request acquisition module; 205, redirection module; 300, electronic device; 301, processor; 302, communication bus; 303, user interface; 304, network interface; 305, memory. Detailed Implementation
[0029] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.
[0030] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.
[0031] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.
[0032] This application provides a multi-instance domain name resolution caching method, refer to... Figure 1 , Figure 1 This is a flowchart illustrating a multi-instance domain name resolution caching method provided in an embodiment of this application. The method is applied to a server, which executes the multi-instance domain name resolution caching program. The server can be a single server, a server cluster consisting of multiple servers, or a cloud computing service center. The method includes steps S101 to S107, as follows:
[0033] Step S101: For multiple network egress lines, configure a corresponding DNS cache instance for each network egress line.
[0034] In step S101, for multiple network egress lines, a corresponding DNS cache instance is configured for each network egress line. Specifically, this includes: obtaining performance index data of all network egress lines in the network system; calculating the comprehensive score of each network egress line based on the performance index data according to preset network egress line evaluation rules, and sorting each network egress line according to the comprehensive score; setting the network egress line with the highest comprehensive score as the primary network egress line, setting the network egress lines other than the primary network egress line as backup network egress lines, and numbering the backup network egress lines according to the comprehensive score from high to low; setting a primary DNS cache instance and configuring the listening port of the primary DNS cache instance as a standard DNS protocol port; setting multiple extended DNS cache instances and assigning a custom listening port different from the standard DNS protocol port to each extended DNS cache instance; associating the primary DNS cache instance with the primary network egress line, and associating each extended DNS cache instance with a backup network egress line according to the numbering order of the backup network egress lines.
[0035] Specifically, the server first acquires performance metrics data for all network egress lines in the network system. These performance metrics may include, but are not limited to, bandwidth capacity, latency, packet loss rate, and jitter of the network egress lines. The server can collect this performance metrics data in real time through a network monitoring system, or it can periodically retrieve historical performance metrics data from a network management database.
[0036] After obtaining the performance metrics data of the network egress lines, the server calculates a comprehensive score for each network egress line based on preset network egress line evaluation rules. The preset network egress line evaluation rules can be a set of weighted calculation formulas, where different performance metrics are assigned different weights, and the comprehensive score for each network egress line is obtained through weighted summation. For example, the weight of bandwidth capacity can be set to 0.4, latency to 0.3, packet loss rate to 0.2, and jitter to 0.1. Therefore, the comprehensive score of a network egress line = bandwidth capacity score × 0.4 + latency score × 0.3 + packet loss rate score × 0.2 + jitter score × 0.1.
[0037] The server ranks the network egress lines based on the calculated overall score. The network egress line with the highest score is designated as the primary network egress line, while the other network egress lines are designated as backup network egress lines. The backup network egress lines are numbered from highest to lowest overall score; for example, the backup network egress line with the second highest overall score is numbered 1, and so on.
[0038] Next, the server sets up a primary DNS cache instance and configures its listening port to a standard DNS protocol port, typically port 53. Then, the server sets up multiple extended DNS cache instances, each corresponding to a separate backup network exit line. To differentiate between the various extended DNS cache instances, the server assigns each instance a custom listening port different from the standard DNS protocol port, such as 8053 or 8153.
[0039] Finally, the server associates the primary DNS cache instance with the primary network egress line, ensuring that the primary DNS cache instance prioritizes using the primary network egress line to forward DNS requests. Simultaneously, the server associates each extended DNS cache instance with its corresponding backup network egress line according to their numbering. For example, the extended DNS cache instance corresponding to backup network egress line number 1 listens on port 8053, the extended DNS cache instance corresponding to backup network egress line number 2 listens on port 8153, and so on.
[0040] In one possible implementation, after associating the primary DNS cache instance with the primary network egress line and associating each extended DNS cache instance with a backup network egress line according to the numbering order of the backup network egress lines, the method further includes: configuring basic DNS resolution rules and local host record files for the primary DNS cache instance; when initializing the first extended DNS cache instance, synchronizing the basic DNS resolution rules and local host record files from the primary DNS cache instance as initial configuration parameters for the first extended DNS cache instance, wherein the first extended DNS cache instance is any one of multiple extended DNS cache instances; and when the first extended DNS cache instance receives a DNS query request from a user terminal, resolving the DNS query request using the basic DNS resolution rules and local host record files.
[0041] Specifically, the server configures basic DNS resolution rules and a local host record file for the primary DNS cache instance. Basic resolution rules define how the DNS cache instance selects the appropriate resolution strategy based on conditions such as the requested domain name type and query type when it receives a DNS query request. For example, for a root domain name query request, the DNS cache instance can directly return the pre-configured root name server address; for a local domain name query request, the DNS cache instance can directly look up the corresponding IP address in the local host record file and return it. The local host record file contains some predefined mapping relationships between domain names and IP addresses, typically used for hostname resolution within the internal network. The server configures these basic resolution rules and the local host record file into the primary DNS cache instance as its initialization parameters.
[0042] Next, the server initializes each extended DNS cache instance. When the server initializes the first extended DNS cache instance, it synchronizes the basic DNS resolution rules and localhost record file from the primary DNS cache instance as the initial configuration parameters for that extended DNS cache instance. This first extended DNS cache instance can be any one of multiple extended DNS cache instances, and the server can initialize each extended DNS cache instance sequentially in a certain order. In this way, the server ensures that all extended DNS cache instances inherit the basic configuration of the primary DNS cache instance, maintaining consistency.
[0043] Once the first extended DNS cache instance is initialized, it can begin receiving and processing DNS query requests from user terminals. When a user terminal sends a DNS query request, the request is forwarded to the extended DNS cache instance bound to the corresponding network egress line according to the forwarding rules pre-configured on the server. For example, if the user terminal's DNS query request is sent through the backup network egress line numbered 1, then the request will be forwarded to the extended DNS cache instance listening on port 8053.
[0044] Upon receiving a DNS query request, the extended DNS cache instance resolves the request using the base DNS resolution rules synchronized from the primary DNS cache instance and the local host record file. Specifically, the extended DNS cache instance first searches for a matching resolution strategy in the base DNS rules based on conditions such as the requested domain name type and query type. If a matching resolution strategy is found, it resolves the request according to the strategy's definition. If no matching resolution strategy is found, the extended DNS cache instance searches for the IP address corresponding to the requested domain name in the local host record file. If a corresponding IP address is found in the local host record file, it is directly returned to the user terminal. If no corresponding IP address is found, the extended DNS cache instance forwards the request to the upstream DNS server for recursive resolution and caches the resolution result for subsequent request processing.
[0045] Through the above steps, the server configures the basic resolution rules and local host record file for the primary DNS cache instance, and synchronizes these configurations to each extended DNS cache instance during initialization, ensuring consistency across all DNS cache instances. Simultaneously, the server also configures a binding relationship between each extended DNS cache instance and a backup network egress line, enabling DNS query requests to be intelligently forwarded to the corresponding extended DNS cache instance for processing based on the source network, improving the efficiency and reliability of DNS resolution.
[0046] In one possible implementation, after configuring a corresponding DNS cache instance for each of the multiple network egress lines, the method further includes: setting a DNS splitting enable flag for the primary DNS cache instance corresponding to the primary network egress line, and setting a DNS splitting disable flag for each extended DNS cache instance; periodically probing the availability status of the primary network egress line and each backup network egress line within a preset period; if the primary network egress line is available, activating the DNS splitting function of the primary DNS cache instance, dynamically splitting the DNS query request to different upstream DNS servers for resolution by identifying the network type and request characteristics of the user terminal's DNS query request; if a failure is detected in the primary network egress line, redirecting the user terminal's DNS query request to the second extended DNS cache instance corresponding to the backup network egress line with the highest comprehensive score; for all DNS query requests received by the second extended DNS cache instance, directly forwarding them to the upstream DNS server associated with the second extended DNS cache instance for resolution, disabling the DNS splitting function, until the primary network egress line recovers its availability.
[0047] Specifically, when initializing the primary DNS cache instance and extended DNS cache instances, the server also sets a DNS splitting enable flag for the primary DNS cache instance corresponding to the primary network egress line, indicating that the primary DNS cache instance is allowed to split user DNS query requests according to certain rules. At the same time, the server sets a DNS splitting disable flag for each extended DNS cache instance, indicating that the extended DNS cache instance is prohibited from performing DNS splitting operations and can only forward received DNS query requests directly to the associated upstream DNS server for resolution.
[0048] During system operation, the server periodically probes the availability status of the main network egress line and each backup network egress line within a preset period. This availability status can include indicators such as network egress line connectivity, latency, and packet loss rate. The server can determine whether the network egress lines are functioning correctly by periodically sending probe packets and analyzing the response data.
[0049] If the server detects that the main network egress line is available, it will activate the DNS routing function of the primary DNS cache instance. At this time, when a user terminal sends a DNS query request, the primary DNS cache instance will dynamically route the request to different upstream DNS servers for resolution based on the network type of the request (e.g., the network segment to which the source IP address belongs) and request characteristics (e.g., the requested domain name type, query type, etc.). This DNS routing mechanism can select the optimal upstream DNS server based on different request characteristics, improving the efficiency and accuracy of DNS resolution. For example, for resolution requests for domestic domain names, the primary DNS cache instance can choose a domestic upstream DNS server for resolution; for resolution requests for foreign domain names, the primary DNS cache instance can choose a foreign upstream DNS server for resolution, avoiding the latency and instability caused by cross-border resolution.
[0050] If the server detects a failure in the primary network egress line, such as connectivity interruption or latency exceeding a threshold, it will trigger a failover mechanism. The server will redirect user terminal DNS query requests to the extended DNS cache instance (referred to as the second extended DNS cache instance) corresponding to the backup network egress line with the highest overall score. Since the DNS splitting function of the second extended DNS cache instance is disabled, it will directly forward all received DNS query requests to its associated upstream DNS server for resolution without performing any splitting. This failover mechanism ensures that DNS query requests can still be processed normally when the primary network egress line fails, guaranteeing service continuity.
[0051] The server will continuously monitor the status of the primary network egress line until it is restored to a usable state. Once the primary network egress line returns to normal operation, the server will switch DNS query requests back to the primary DNS cache instance and re-enable the DNS traffic splitting function of the primary DNS cache instance, restoring it to normal working mode.
[0052] Step S102: Assign a corresponding local listening port to each DNS cache instance, and associate each DNS cache instance with the primary upstream DNS server address of the operator to which the corresponding network egress line belongs.
[0053] In step S102, each DNS cache instance is associated with the primary upstream DNS server address of the operator to which the corresponding network egress line belongs. Specifically, this includes: obtaining the operator information of each network egress line; based on the operator information of the network egress line, querying the corresponding upstream DNS server address list from the preset operator DNS mapping table for each DNS cache instance; if the upstream DNS server address list contains multiple upstream DNS server addresses, testing the response speed and response success rate of each upstream DNS server address through DNS resolution requests; determining the primary upstream DNS server address from the multiple upstream DNS server addresses based on the response speed and response success rate; configuring the primary upstream DNS server address into the upstream forwarding address list of the corresponding DNS cache instance, thus completing the association between the DNS cache instance and the primary upstream DNS server address.
[0054] Specifically, the server retrieves the carrier information for each network egress line. This carrier information can be obtained through an interface provided by the network management system or manually configured by the administrator. Carrier information typically includes attributes such as carrier name, AS number, and network segment, used to identify different network carriers.
[0055] Next, the server, on a per-DNS cache instance basis, queries the pre-configured ISP DNS mapping table for the corresponding list of upstream DNS server addresses, based on the ISP information of its corresponding network egress line. The ISP DNS mapping table is a pre-configured data structure that maintains the mapping relationship between different ISPs and their recommended upstream DNS server addresses. For example, if ISP A recommends upstream DNS server addresses X and Y, and ISP B recommends upstream DNS server addresses M and N, then the ISP DNS mapping table will contain the following mapping relationships: ISP A -> [X, Y]; ISP B -> [M, N]. The server searches the ISP DNS mapping table for a matching list of upstream DNS server addresses based on the ISP information corresponding to the DNS cache instance.
[0056] If the list of upstream DNS server addresses obtained from the query contains only one address, the server directly configures that address as the primary upstream DNS server address for the DNS cache instance. However, if the list of upstream DNS server addresses contains multiple addresses, the server performs further testing to select the optimal primary upstream DNS server address.
[0057] Specifically, the server initiates DNS resolution requests for each upstream DNS server address, testing their response speed and success rate. Response speed refers to the time interval from sending a DNS resolution request to receiving a resolution response; a faster response speed indicates higher resolution efficiency of the upstream DNS server. Response success rate refers to the percentage of DNS resolution requests that successfully obtain a resolution result out of a certain number of requests; a higher response success rate indicates better reliability of the upstream DNS server.
[0058] The server comprehensively considers the response speed and success rate of upstream DNS server addresses, selecting the address with the best overall performance as the primary upstream DNS server address. Typically, the server assigns different weights to response speed and success rate, for example, a weight of 0.7 for response speed and a weight of 0.3 for success rate. Then, it calculates the overall performance score of each upstream DNS server address using a weighted average method, and the address with the highest score becomes the primary upstream DNS server address.
[0059] After determining the primary upstream DNS server address, the server configures it in the upstream forwarding address list of the corresponding DNS cache instance. The upstream forwarding address list is a configuration item for the DNS cache instance that specifies which upstream DNS servers should be forwarded to when the DNS cache instance cannot retrieve the resolution result from its local cache. By adding the primary upstream DNS server address to the upstream forwarding address list, the server completes the association between the DNS cache instance and the primary upstream DNS server address.
[0060] Step S103: Generate an association configuration table, which includes the correspondence between network egress lines, DNS cache instances, and primary upstream DNS server addresses.
[0061] In step S103, the server creates a new data structure called the association configuration table. The association configuration table can be a two-dimensional table or a key-value dictionary, used to store three types of information: network egress lines, DNS cache instances, and the address of the primary upstream DNS server.
[0062] For each network egress line, the server creates a corresponding entry in the association configuration table. This entry contains the following fields:
[0063] Network egress line ID: Used to uniquely identify a network egress line, and can be a number or a string.
[0064] DNS Cache Instance Name: Specifies the name of the DNS cache instance associated with the network egress line.
[0065] Primary upstream DNS server address: Specifies the primary upstream DNS server address used by the DNS cache instance associated with this network egress line.
[0066] During the generation of the association configuration table, the server traverses each network egress line to obtain the name of its associated DNS cache instance and the address of the primary upstream DNS server, and then fills this information into the corresponding fields of the association configuration table.
[0067] The purpose of the association configuration table is to provide a centralized view for managing and querying the relationships between network egress lines, DNS cache instances, and primary upstream DNS server addresses. By querying the association configuration table, the server can quickly find out the DNS cache instance and primary upstream DNS server address corresponding to each network egress line, or conversely, query the network egress line and primary upstream DNS server address corresponding to the name of the DNS cache instance.
[0068] The association configuration table can also be used to support system operation and maintenance. For example, when modifying the DNS cache instance or primary upstream DNS server address of a network egress line, the administrator can directly edit the corresponding entry in the association configuration table without delving into the configuration files of each DNS cache instance. Simultaneously, the association configuration table also facilitates system monitoring and troubleshooting; administrators can quickly understand the relationships and configurations between various components in the current system by viewing the association configuration table.
[0069] Step S104: Determine the initial egress line of the user terminal, and based on the association configuration table, use policy routing to direct the destination address of the DNS query request initiated by the user terminal to the first DNS cache instance corresponding to the initial egress line and the target local listening port corresponding to the first DNS cache instance.
[0070] In step S104, the server first determines the initial outgoing line for the user terminal. The server can analyze information such as the user terminal's IP address, network access method, and geographical location, and combine this with a preset outgoing line selection strategy to allocate an optimal initial outgoing line for the user terminal. For example, the server can choose the outgoing line closest to the user terminal's physical location as the initial outgoing line to reduce network transmission latency.
[0071] After determining the initial egress line, the server will query the association configuration table generated in step S103 to find the first DNS cache instance corresponding to the initial egress line and the target local listening port of that instance. The association configuration table records the correspondence between each network egress line, DNS cache instance, and listening port.
[0072] Next, the server configures policy-based routing to redirect the destination address of the DNS query request initiated by the user terminal to the target local listening port of the first DNS cache instance. Policy-based routing is a flexible routing mechanism that can determine the forwarding path of data packets based on multiple conditions such as the source address, destination address, and protocol type of the data packets.
[0073] Specifically, the server establishes a policy-based routing rule between the user terminal and the DNS cache instance. This rule defines a matching condition and an action. The matching condition may include the user terminal's IP address range, the destination port number of the DNS query request, etc. When a DNS query request initiated by the user terminal meets the matching condition, the policy-based routing rule is triggered, and the corresponding action is executed. In this step, the action of the policy-based routing rule is to modify the destination address of the matched DNS query request to the IP address of the first DNS cache instance and the target local listening port number.
[0074] For example, suppose a user terminal's IP address is 192.168.1.100, its initial outgoing line is line A, and the IP address of the corresponding first DNS cache instance is 10.0.0.1, with a listening port of 53. The server can configure a policy-based routing rule with the matching conditions of source IP address 192.168.1.100 and destination port number 53. The rule's action is to rewrite the destination IP address to 10.0.0.1 and the destination port number to 53. When the user terminal with IP address 192.168.1.100 initiates a DNS query request to destination port number 53, this request will be captured by the policy-based routing rule, the destination address of the request will be modified to 10.0.0.1:53, and then forwarded to the first DNS cache instance for processing.
[0075] Step S105: Monitor the operating status of the network egress line. If it is determined that the first network egress line currently used by the user terminal has failed or is overloaded, a new network egress line is determined for the user terminal according to the preset switching strategy.
[0076] In step S105, the server continuously monitors the operational status of each network egress line to ensure that user terminals can use the best quality network access service. The server can monitor the network egress lines in various ways, such as periodically sending probe packets, collecting performance data of network devices, and analyzing network quality feedback from user terminals.
[0077] When the server detects a failure or overload on the primary network egress line currently used by a user terminal, it triggers an egress line switching mechanism. The server first determines the specific type of anomaly on the primary network egress line, such as physical link interruption, network equipment failure, or line congestion. Based on the anomaly type, the server can estimate the time it will take for the primary network egress line to recover and decide whether to switch the user terminal to a new egress line.
[0078] If the server determines that the anomaly of the primary network egress line cannot be resolved within a short period, or that line overload severely impacts the user's network experience, it will trigger an egress line switching process. The server will select a new, optimal network egress line for the user's terminal based on a preset switching strategy. The switching strategy can be based on multiple factors, such as the health status of the egress line, bandwidth capacity, latency, packet loss rate, and physical distance to the user's terminal.
[0079] For example, a server switching strategy can be defined as prioritizing other healthy egress lines from the same operator as the primary network egress line; if other egress lines from the same operator are also unavailable, then the optimal egress line from other operators is selected. Furthermore, the switching strategy can also consider factors such as the user terminal's service level and service type, providing differentiated egress line switching solutions for different users.
[0080] Suppose that the user terminal is currently using line A of operator A as its primary network exit line, and the server detects a failure in line A. According to the handover policy, the server finds that operator A also has a working line B, which is physically closer to the user terminal and has better latency and packet loss rate than other operators' lines. Therefore, the server decides to switch the user terminal's new network exit line to line B.
[0081] After determining the new network egress line, the server will query the association configuration table to find the second DNS cache instance corresponding to the new egress line. Similar to the initial DNS cache instance, the second DNS cache instance is associated with the upstream DNS server of the operator to which the new egress line belongs, and can provide optimal DNS resolution services for that line.
[0082] In one possible implementation, monitoring the operational status of the network egress line specifically includes: testing link reachability by sending probe packets to the next gateway device of the network egress line; testing end-to-end network connectivity by sending probe requests to multiple preset external network reference points through the network egress line; obtaining network performance indicators characterizing the status of the network egress line, including latency, packet loss rate, and availability; comparing the network performance indicators with preset performance thresholds; and determining that the network egress line has failed or is overloaded when the network performance indicators do not meet the preset performance thresholds.
[0083] In this embodiment, the network egress line refers to the link through which the server connects to the Internet, used to connect the server's internal network to the external public network. The next-hop gateway device refers to the router or switch device on the network egress line that is closest to the server and is directly connected to the server. A probe packet is a special data packet sent by the server to test network reachability, typically using the ICMP protocol. Preset external network reference points refer to a group of well-known websites or servers distributed on the Internet; availability and response time reflect network quality, such as famous portal websites and public DNS servers. Probe requests are HTTP, DNS, and other request messages periodically sent by the server to the preset reference points to test connectivity with the external network. Network performance metrics are quantitative indicators for evaluating the status of the network egress line. Latency represents the round-trip time of data packets from the server to the destination; packet loss rate is the ratio of lost data packets to transmitted data packets; availability represents the ratio of the network egress line's normal operating time to the total available time. Preset performance thresholds represent the critical points for acceptable network performance metrics preset by the server based on service quality requirements and user experience standards; exceeding these thresholds indicates a failure or overload of the network egress line.
[0084] Specifically, the server tests the reachability of the link by sending probe packets to the next-hop gateway device on the network egress line. Specifically, the server periodically sends probe packets of types such as ICMP and UDP to the next-hop gateway and waits for the gateway's response. If the server receives a response packet from the gateway within a specified time, it indicates that the link with the next-hop gateway is working; if the server does not receive a response, or the response packet indicates an error, it indicates that the link may have failed and further inspection and handling are required.
[0085] Secondly, the server sends probe requests to multiple pre-defined external network reference points via the network egress line to test end-to-end network connectivity. These external network reference points can be a group of well-known websites or authoritative DNS servers distributed across the Internet; their accessibility and response time reflect the overall quality of the network egress line. The server periodically sends HTTP, DNS, and other types of requests to these reference points, and tracks metrics such as request success rate and response latency. If the failure rate of the probe requests exceeds a pre-defined threshold, or the response latency is significantly high, it indicates that the end-to-end connectivity of the network egress line is affected, possibly due to congestion or a failure.
[0086] While probing link reachability and end-to-end connectivity, the server continuously collects and analyzes various performance metrics reflecting the status of the network egress line, including network latency, packet loss rate, and available bandwidth. The server can obtain these performance metrics in real time through network device performance monitoring interfaces and network traffic analysis tools. For example, the server can collect the average latency and packet loss rate of the network egress line every 5 minutes; if these values exceed 100ms and 1% for three consecutive periods, a line congestion alarm will be issued.
[0087] The server compares the collected network performance metrics with preset performance thresholds to determine the health of the network egress line. These performance thresholds are set based on factors such as Service Level Agreements (SLAs) and user experience requirements, reflecting the server's basic requirements for line quality. For example, the server can set performance thresholds such as network latency not exceeding 50ms, packet loss rate not exceeding 0.5%, and available bandwidth not less than 100Mbps. When network performance metrics consistently reach or exceed these thresholds, the server considers the network egress line to be faulty or overloaded, requiring subsequent processing such as line switching.
[0088] Step S106: Update the policy route associated with the user terminal, and redirect the destination address of subsequent DNS query requests initiated by the user terminal to the second DNS cache instance corresponding to the new network egress line.
[0089] In step S106, the server updates the policy routing rules associated with the user terminal to ensure that subsequent DNS query requests initiated by the user terminal can be correctly redirected to the second DNS cache instance corresponding to the new network egress line. This step is crucial for implementing network egress line switching; the server dynamically adjusts the policy routing to keep it consistent with the latest network topology and DNS cache instance deployment.
[0090] Specifically, the server first queries the association configuration table to retrieve the IP address and listening port number of the second DNS cache instance bound to the new network egress line. Similar to the initial DNS cache instance, the second DNS cache instance is also deployed on the server's local network, providing DNS resolution services through the specified IP address and port number.
[0091] Next, the server modifies existing policy routing rules or creates a new policy routing rule to redirect user terminal DNS query requests to the second DNS cache instance. The server can dynamically issue policy routing rule update instructions through network device configuration interfaces or software-defined networking (SDN) controllers.
[0092] When modifying policy routing rules, the server accurately identifies the target traffic for redirection based on factors such as the user terminal's IP address and the destination port number of the DNS query request. Simultaneously, the server adjusts the action portion of the policy routing rule, replacing the destination IP address of the matched DNS query request with the IP address of the second DNS cache instance, and the destination port number with the listening port number of the second DNS cache instance.
[0093] For example, suppose in step S105, the server selects a new network egress line B for the user terminal, with the corresponding second DNS cache instance having an IP address of 10.0.0.2 and a listening port number of 53. The server updates the existing policy routing rules, keeping the matching conditions unchanged, still matching DNS query requests with a source IP address of 192.168.1.100 and a destination port number of 53. However, the action part of the rule is modified, rewriting the destination IP address to 10.0.0.2 and the destination port number to 53. Thus, when the user terminal subsequently initiates a new DNS query request, the request will be captured by the policy routing rules and redirected to the second DNS cache instance for processing.
[0094] After updating the policy routing rules, the server also performs necessary configuration and initialization operations on the second DNS cache instance to ensure that it can correctly receive and respond to DNS query requests from user terminals. This may include synchronizing the cached data of the first DNS cache instance, updating the address of the upstream DNS server, and adjusting the caching policy.
[0095] By dynamically updating policy routing rules, the server seamlessly switches user terminal DNS query requests from the original first DNS cache instance to a new second DNS cache instance. This switch is transparent to the user terminal; the user is unaware of any changes to the network egress line or DNS resolution scheme. Simultaneously, because the second DNS cache instance is associated with the new network egress line, it can provide user terminals with higher-quality and more stable DNS resolution services, improving the user's network access experience.
[0096] In one possible implementation, after step S107, the method further includes: receiving a redirected DNS query request through a first DNS cache instance; obtaining a set of status data of backend service instances related to the target domain name in the DNS query request from a distributed collection network, the set of status data including real-time network performance indicators of each backend service instance related to the initial egress line, the real-time network performance indicators including latency, packet loss rate, and available bandwidth; calculating a corresponding dynamic weight value for each backend service instance based on the set of status data using a preset weight calculation function; constructing a DNS response message based on the dynamic weight value corresponding to each backend service instance, and returning the DNS response information to the user terminal, the DNS response message containing the IP address record of the backend service instance, and the IP address record including a priority value determined according to the dynamic weight value.
[0097] Specifically, the server first queries the association configuration table to find the DNS cache instance (referred to as the second DNS cache instance) corresponding to the new network egress line. Then, the server updates its internal routing rules and forwarding table, redirecting the destination address of DNS query requests from the user terminal to the IP address and listening port of the second DNS cache instance. In this way, subsequent DNS query requests initiated by the user terminal will be forwarded to the second DNS cache instance for processing.
[0098] After receiving a redirected DNS query request, the second DNS cache instance will follow a similar processing flow as the first DNS cache instance. It will obtain a set of status data of backend service instances related to the target domain name from the distributed collection network, calculate the dynamic weight value of each backend service instance based on real-time network performance indicators, and construct an intelligent DNS response message to return to the user terminal.
[0099] During the process of acquiring the backend service instance status data set, the second DNS cache instance will consider the backend service instances related to the current new egress line. Since the network quality and connectivity between different network egress lines and backend service instances may vary, the second DNS cache instance selects the most matching subset of backend service instances for status data collection and analysis based on the network topology and routing of the new egress line.
[0100] For example, suppose a user terminal previously accessed the network through the outbound line L1. When processing its DNS query requests, the first DNS cache instance primarily considered the state data of backend service instances A, B, and C, which had better communication quality with the L1 line. Now, the user terminal has switched to the new outbound line L2, and the backend service instances with better communication quality with the L2 line may have changed, for example, to B, C, and D. Therefore, when processing the redirected DNS query requests, the second DNS cache instance will prioritize obtaining and analyzing the state data of instances B, C, and D, and will no longer consider instance A.
[0101] After obtaining the set of backend service instance status data related to the new outbound line, the second DNS cache instance extracts the real-time network performance metrics for each instance, including latency, packet loss rate, and available bandwidth. Then, the second DNS cache instance uses the same preset weight calculation function as the first DNS cache instance to calculate the dynamic weight value of each backend service instance based on these network performance metrics.
[0102] The weighting calculation function comprehensively considers the impact of various network performance indicators on service quality, assigning different weight coefficients to different indicators, and ultimately deriving a weight value that reflects the overall service capability of the backend service instance. The larger the weight value, the better the service quality that the instance can provide in the current network environment, and the more likely it should be selected and recommended.
[0103] Based on the calculated dynamic weight values, the second DNS cache instance assigns a priority value to each backend service instance and constructs a DNS response message. In this message, the IP addresses of the backend service instances are arranged in descending order of priority value, forming an ordered list of IP addresses. IP addresses with higher priority values are placed at the beginning of the list, indicating that they are the preferred service nodes.
[0104] Finally, the second DNS cache instance returns the constructed DNS response message to the user terminal that initiated the query request. Upon receiving the response message, the user terminal's DNS resolver will prioritize the IP address with the highest IP address ranking for subsequent service requests and communication.
[0105] Reference Figure 2This application also provides a multi-instance domain name resolution caching device, which is a server. The server includes a DNS configuration module 201, an address association module 202, an association configuration table generation module 203, a DNS request acquisition module 204, and a redirection module 205. The DNS configuration module 201 is used to configure a corresponding DNS cache instance for each of the multiple network egress lines. The address association module 202 is used to allocate a corresponding local listening port for each DNS cache instance and associate each DNS cache instance with the primary upstream DNS server address of the corresponding network egress line's operator. The association configuration table generation module 203 is used to generate an association configuration table, which includes the correspondence between network egress lines, DNS cache instances, and primary upstream DNS server addresses. The DNS request acquisition module 204 is used to determine the initial egress line of the user terminal, and based on the association configuration table, to redirect the destination address of the DNS query request initiated by the user terminal to the first DNS cache instance corresponding to the initial egress line and the target local listening port corresponding to the first DNS cache instance through policy routing; the DNS request acquisition module 204 is also used to monitor the operating status of the network egress line, and if it is determined that the first network egress line currently used by the user terminal has failed or is overloaded, a new network egress line is determined for the user terminal according to a preset switching policy; the redirection module 205 is used to update the policy routing associated with the user terminal, and to redirect the destination address of subsequent DNS query requests initiated by the user terminal to the second DNS cache instance corresponding to the new network egress line.
[0106] In one possible implementation, the DNS configuration module 201 configures a corresponding DNS cache instance for each of the multiple network egress lines. Specifically, the DNS configuration module 201 acquires performance index data for all network egress lines in the network system; the DNS configuration module 201 calculates a comprehensive score for each network egress line based on the performance index data according to preset network egress line evaluation rules, and sorts the network egress lines according to their comprehensive scores; the DNS configuration module 201 sets the network egress line with the highest comprehensive score as the primary network egress line, and sets the network egress lines other than the primary network egress line as backup network egress lines, numbering the backup network egress lines according to their comprehensive scores from highest to lowest; the DNS configuration module 201 sets up a primary DNS cache instance and configures its listening port to a standard DNS protocol port; the DNS configuration module 201 sets up multiple extended DNS cache instances and assigns a custom listening port different from the standard DNS protocol port to each extended DNS cache instance; the DNS configuration module 201 associates the primary DNS cache instance with the primary network egress line, and associates each extended DNS cache instance with a backup network egress line according to their numbering order.
[0107] In one possible implementation, after the DNS configuration module 201 associates the primary DNS cache instance with the primary network egress line and associates each extended DNS cache instance with a backup network egress line according to the numbering order of the backup network egress lines, the implementation further includes: the DNS configuration module 201 configuring basic resolution rules and local host record files for the primary DNS cache instance; when initializing the first extended DNS cache instance, the DNS configuration module 201 synchronizes the basic resolution rules and local host record files from the primary DNS cache instance as initial configuration parameters for the first extended DNS cache instance, wherein the first extended DNS cache instance is any one of multiple extended DNS cache instances; when the first extended DNS cache instance receives a DNS query request from a user terminal, the DNS configuration module 201 resolves the DNS query request using the basic resolution rules and local host record files.
[0108] In one possible implementation, after configuring a corresponding DNS cache instance for each of the multiple network egress lines, the DNS configuration module 201 further includes: setting a DNS splitting enable flag for the primary DNS cache instance corresponding to the primary network egress line, and setting a DNS splitting disable flag for each extended DNS cache instance; periodically probing the availability status of the primary network egress line and each backup network egress line within a preset period; if the primary network egress line is available, the DNS configuration module 201 activates the DNS splitting function of the primary DNS cache instance, dynamically splitting the DNS query request to different upstream DNS servers for resolution by identifying the network type and request characteristics of the user terminal's DNS query request; if a failure is detected in the primary network egress line, the DNS configuration module 201 redirects the user terminal's DNS query request to the second extended DNS cache instance corresponding to the backup network egress line with the highest comprehensive score; for all DNS query requests received by the second extended DNS cache instance, the DNS configuration module 201 directly forwards them to the upstream DNS server associated with the second extended DNS cache instance for resolution, disabling the DNS splitting function until the primary network egress line returns to availability.
[0109] In one possible implementation, the address association module 202 associates each DNS cache instance with the primary upstream DNS server address of the operator to which the corresponding network egress line belongs. Specifically, the address association module 202 obtains the operator information of each network egress line; based on the operator information of the network egress line, the address association module 202 queries the corresponding upstream DNS server address list from a preset operator DNS mapping table for each DNS cache instance; if the upstream DNS server address list contains multiple upstream DNS server addresses, the address association module 202 tests the response speed and response success rate of each upstream DNS server address through DNS resolution requests; based on the response speed and response success rate, the address association module 202 determines the primary upstream DNS server address from the multiple upstream DNS server addresses; the address association module 202 configures the primary upstream DNS server address into the upstream forwarding address list of the corresponding DNS cache instance, thus completing the association between the DNS cache instance and the primary upstream DNS server address.
[0110] In one possible implementation, after the redirection module 205, based on the association configuration table, redirects the destination address of the DNS query request initiated by the user terminal to the first DNS cache instance corresponding to the initial egress line and the target local listening port corresponding to the first DNS cache instance through policy routing, the method further includes: the redirection module 205 receiving the redirected DNS query request through the first DNS cache instance; the redirection module 205 obtaining a set of status data of backend service instances related to the target domain name in the DNS query request from the distributed collection network, the set of status data including real-time network performance indicators of each backend service instance related to the initial egress line, the real-time network performance indicators including latency, packet loss rate, and available bandwidth; the redirection module 205 calculating a corresponding dynamic weight value for each backend service instance based on the status data set using a preset weight calculation function; the redirection module 205 constructing a DNS response message based on the dynamic weight value corresponding to each backend service instance and returning the DNS response information to the user terminal, the DNS response message containing the IP address record of the backend service instance, and the IP address record including a priority value determined according to the dynamic weight value.
[0111] In one possible implementation, the DNS request acquisition module 204 monitors the operating status of the network egress line, specifically including: the DNS request acquisition module 204 sends probe packets to the next-hop gateway device of the network egress line to test link reachability; the DNS request acquisition module 204 sends probe requests to multiple preset external network reference points through the network egress line to test end-to-end network connectivity; the DNS request acquisition module 204 acquires network performance indicators characterizing the status of the network egress line, the network performance indicators including latency, packet loss rate, and availability; the DNS request acquisition module 204 compares the network performance indicators with preset performance thresholds; when the network performance indicators do not meet the preset performance thresholds, the DNS request acquisition module 204 determines that the network egress line has failed or is overloaded.
[0112] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.
[0113] This application also provides an electronic device. (See reference...) Figure 3 , Figure 3This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 300 may include: multiple processors 301, multiple network interfaces 304, a user interface 303, a memory 305, and multiple communication buses 302.
[0114] The communication bus 302 is used to enable communication between these components.
[0115] The user interface 303 may include a display screen and a camera. Optionally, the user interface 303 may also include a standard wired interface and a wireless interface.
[0116] The network interface 304 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).
[0117] The processor 301 may include one or more processing cores. The processor 301 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 305, and by calling data stored in memory 305. Optionally, the processor 301 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 301 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 301 and may be implemented as a separate chip.
[0118] The memory 305 may include random access memory (RAM) or read-only memory. Optionally, the memory 305 may include a non-transitory computer-readable storage medium. The memory 305 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for multiple functions (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method embodiments described above. The data storage area may store data involved in the various method embodiments described above. Optionally, the memory 305 may also be multiple storage devices located remotely from the aforementioned processor 301. (Refer to...) Figure 3 The memory 305, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application for a multi-instance domain name resolution caching method.
[0119] exist Figure 3 In the illustrated electronic device 300, the user interface 303 is mainly used to provide an input interface for the user and obtain user input data; while the processor 301 can be used to call an application program stored in the memory 305 that stores a multi-instance domain name resolution caching method. When executed by one or more processors 301, the electronic device 300 performs one or more of the methods described in the above embodiments. It should be noted that, for the foregoing method embodiments, for the sake of simplicity, they are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.
[0120] This application also provides a computer-readable storage medium storing instructions. When executed by one or more processors 301, these instructions cause an electronic device 300 to perform one or more of the methods described in the above embodiments.
[0121] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.
[0122] In the various embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between apparatuses or units may be electrical or other forms.
[0123] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0124] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0125] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, portable hard drives, magnetic disks, or optical disks.
[0126] The above description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Other embodiments of this disclosure will be readily apparent to those skilled in the art upon consideration of the specification and the disclosure of practical truths.
[0127] This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.
Claims
1. A multi-instance domain name resolution caching method, characterized in that, The method includes: For multiple network egress lines, configure a corresponding DNS cache instance for each of the network egress lines; Assign a corresponding local listening port to each DNS cache instance, and associate each DNS cache instance with the primary upstream DNS server address of the operator to which the corresponding network egress line belongs; Generate an association configuration table, which includes the correspondence between network egress lines, DNS cache instances, and primary upstream DNS server addresses; The initial egress line of the user terminal is determined, and based on the association configuration table, the destination address of the DNS query request initiated by the user terminal is directed to the first DNS cache instance corresponding to the initial egress line and the target local listening port corresponding to the first DNS cache instance through policy routing. Monitor the operating status of the network egress line. If it is determined that the first network egress line currently used by the user terminal has failed or is overloaded, a new network egress line is determined for the user terminal according to a preset switching strategy. Update the policy route associated with the user terminal, and redirect the destination address of subsequent DNS query requests initiated by the user terminal to the second DNS cache instance corresponding to the new network egress line.
2. The method according to claim 1, characterized in that, The provision of configuring a corresponding DNS cache instance for each of the multiple network egress lines specifically includes: Obtain performance metrics data for all network egress lines in the network system; Based on the preset network egress line evaluation rules, the comprehensive score of each network egress line is calculated according to the performance index data, and the network egress lines are sorted according to the comprehensive score. The network exit line with the highest comprehensive score is set as the primary network exit line, and the network exit lines other than the primary network exit line are set as backup network exit lines. The backup network exit lines are numbered from high to low according to their comprehensive scores. Set up a primary DNS cache instance and configure the listening port of the primary DNS cache instance to the standard DNS protocol port; Configure multiple extended DNS cache instances and assign a custom listening port different from the standard DNS protocol port to each of the extended DNS cache instances; Associate the primary DNS cache instance with the primary network egress line, and associate each of the extended DNS cache instances with the backup network egress line according to the numbering order of the backup network egress lines.
3. The method according to claim 2, characterized in that, After associating the primary DNS cache instance with the primary network egress line, and associating each extended DNS cache instance with the backup network egress line according to their numbering order, the method further includes: Configure basic DNS resolution rules and local host record files for the primary DNS cache instance; When initializing the first extended DNS cache instance, the basic resolution rules and the local host record file are synchronized from the primary DNS cache instance as the initial configuration parameters of the first extended DNS cache instance. The first extended DNS cache instance can be any one of multiple extended DNS cache instances. When the first extended DNS cache instance receives a DNS query request from the user terminal, it resolves the DNS query request using the basic resolution rules and the local host record file.
4. The method according to claim 2, characterized in that, After configuring a corresponding DNS cache instance for each of the multiple network egress lines, the method further includes: Set the DNS splitting enable flag for the primary DNS cache instance corresponding to the primary network egress line, and set the DNS splitting disable flag for each of the extended DNS cache instances; Within a preset period, the availability status of the main network egress line and each of the backup network egress lines is periodically detected; If the main network egress line is available, the DNS routing function of the main DNS cache instance is activated. By identifying the network type and request characteristics of the user terminal's DNS query request, the DNS query request is dynamically routed to different upstream DNS servers for resolution. If a failure is detected in the main network egress line, the DNS query request of the user terminal will be redirected to the second extended DNS cache instance corresponding to the backup network egress line with the highest comprehensive score. All DNS query requests received by the second extended DNS cache instance are directly forwarded to the upstream DNS server associated with the second extended DNS cache instance for resolution, and the DNS traffic splitting function is disabled until the main network egress line is restored to an available state.
5. The method according to claim 1, characterized in that, Associating each DNS cache instance with the primary upstream DNS server address of the corresponding network egress line operator specifically includes: Obtain the operator information for each of the aforementioned network egress lines; Based on the operator information of the network egress line, the corresponding upstream DNS server address list is queried from the preset operator DNS mapping table for each DNS cache instance. If the list of upstream DNS server addresses contains multiple upstream DNS server addresses, then the response speed and response success rate of each upstream DNS server address are tested through DNS resolution requests; Based on the response speed and the response success rate, a primary upstream DNS server address is determined from a plurality of upstream DNS server addresses; Configure the primary upstream DNS server address into the upstream forwarding address list of the corresponding DNS cache instance to complete the association between the DNS cache instance and the primary upstream DNS server address.
6. The method according to claim 1, characterized in that, After directing the destination address of the DNS query request initiated by the user terminal to the first DNS cache instance corresponding to the initial egress line and the target local listening port corresponding to the first DNS cache instance through policy routing based on the association configuration table, the method further includes: The redirected DNS query request is received through the first DNS cache instance; Obtain a set of status data of backend service instances related to the target domain name in the DNS query request from the distributed collection network. The set of status data includes real-time network performance indicators of each backend service instance related to the current egress line, including latency, packet loss rate, and available bandwidth. Based on the state data set, a corresponding dynamic weight value is calculated for each of the backend service instances using a preset weight calculation function; Based on the dynamic weight value corresponding to each of the backend service instances, a DNS response message is constructed and the DNS response information is returned to the user terminal. The DNS response message contains the IP address record of the backend service instance, and the IP address record includes a priority value determined according to the dynamic weight value.
7. The method according to claim 1, characterized in that, Monitoring the operational status of the network egress line specifically includes: Link reachability is tested by sending probe packets to the next-hop gateway device of the network egress line; The network egress line is used to send probe requests to multiple preset external network reference points to test end-to-end network connectivity. Obtain network performance indicators that characterize the operating status of the network egress line, including latency, packet loss rate, and availability; The network performance metrics are compared with preset performance thresholds; When the network performance indicators fail to meet the preset performance threshold, it is determined that the network egress line has failed or is overloaded.
8. A multi-instance domain name resolution caching device, characterized in that, The device includes a DNS configuration module (201), an address association module (202), an association configuration table generation module (203), a DNS request acquisition module (204), and a redirection module (205), wherein: The DNS configuration module (201) is used to configure a corresponding DNS cache instance for each of the multiple network egress lines. The address association module (202) is used to allocate a corresponding local listening port to each DNS cache instance and associate each DNS cache instance with the primary upstream DNS server address of the operator to which the corresponding network egress line belongs; The association configuration table generation module (203) is used to generate an association configuration table, which includes the correspondence between network egress lines, DNS cache instances, and primary upstream DNS server addresses. The DNS request acquisition module (204) is used to determine the initial egress line of the user terminal, and based on the association configuration table, to direct the destination address of the DNS query request initiated by the user terminal to the first DNS cache instance corresponding to the initial egress line and the target local listening port corresponding to the first DNS cache instance through policy routing. The DNS request acquisition module (204) is also used to monitor the operating status of the network egress line. If it is determined that the first network egress line currently used by the user terminal has failed or is overloaded, a new network egress line is determined for the user terminal according to a preset switching strategy. The redirection module (205) is used to update the policy route associated with the user terminal and redirect the destination address of subsequent DNS query requests initiated by the user terminal to the second DNS cache instance corresponding to the new network exit line.
9. An electronic device, characterized in that, The device includes a processor (301), a memory (305), a user interface (303), and a network interface (304). The memory (305) is used to store instructions. The user interface (303) and the network interface (304) are used to communicate with other devices. The processor (301) is used to execute the instructions stored in the memory (305) to cause the electronic device (300) to perform the method as described in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, perform the method as described in any one of claims 1-7.