Adaptive switching method and system for connectivity diagnosis of DNS (Domain Name Server)

Abstract

The invention discloses a DNS (Domain Name Server) connectivity diagnosis self-adaptive switching method and a DNS connectivity diagnosis self-adaptive switching system. The method comprises the following steps of: scoring a plurality of pre-configured DNS servers so as to evaluate the connectivity and forwarding quality of each link; the DNS servers are subjected to priority ranking according to the scores, the optimal available DNS server is obtained, domain name request forwarding is carried out, and response results returned by the DNS servers are forwarded to the user side equipment; if all the configured DNS servers fail, obtaining a domain name resolution result through a local disaster preparation cache or a disaster preparation cloud server according to a pre-configured disaster preparation strategy, and forwarding the domain name resolution result to the user side equipment; and performing rapid diagnosis on a plurality of pre-configured DNS servers, and uploading diagnosis results to a cloud for intelligent analysis and alarm. According to the invention, the performance of the built-in DNS forwarding service of the gateway equipment such as the ONT can be improved, and the diagnosis means can be increased.

Description

Technical Field

[0001] The present invention relates to the technical field of DNS services, and in particular to a DNS server connectivity diagnosis adaptive switching method and system. Background Art

[0002] In recent years, wireless and wired broadband services such as optical communications have developed rapidly, and the business of using DNS servers for network domain name resolution has also grown. Based on the deployment of DNS server private networks, switching to different environments will modify various security policies. Environmental changes associated with DNS security policies usually refer to the following aspects: 1. Server-side threat intelligence updates: changes in the global network attack surface, including new malicious domain name registrations, DNS hijacking events, etc., so as to adjust DNS security policies, and DNS refuses to resolve to block known threats; 2. The routers on the link are set up with firewall automatic response: In the face of dynamic network environments, firewalls can automatically adjust DNS resolution rules to isolate or block suspicious traffic; 3. Policy optimization: Operators or enterprises, terminal application apps set filtering rules based on network activities and historical data to ensure that enterprise network access is both safe and efficient; 4. IT administrator control: In an enterprise environment, IT administrators can change or disable certain policies of the terminal to adapt to specific business needs and security policies. All these make it difficult to clearly locate DNS problems encountered during the docking of Netcom devices. In this environment, the user side of the access network needs to adapt to the corresponding DNS server to successfully switch to the top-level DNS server environment. It still takes multiple steps to complete the configuration of the telephone device to connect to the Internet. The steps are cumbersome and highly professional. When maintenance is required, professional technicians need to be bothered, which affects the user experience.

[0003] Due to the widespread use of these home gateway products with DNS forwarding function, home gateway devices with DNS server function are configured with primary and backup servers at most. One server is configured with one domain name, and only a very small number of IPs can be used. When the network architecture is upgraded, fine-grained control requires more firmware changes to adapt to the new situation. The two preceding servers that may have problems will not be switched at the beginning. However, if the server fails and cannot respond to the DNS request of the home gateway, it will cause functional abnormalities. Summary of the invention

[0004] To this end, the present invention provides a DNS server connectivity diagnosis adaptive switching method and system to solve the problems of increased adaptation workload and a large amount of repeated diagnostic work in environmental diagnosis, firmware adaptation, and firmware upgrades caused by environmental changes in DNS security policies.

[0005] In order to achieve the above object, the present invention provides the following technical solutions:

[0006] According to a first aspect of an embodiment of the present invention, a DNS server connectivity diagnosis adaptive switching method is proposed, the method comprising:

[0007] Scoring multiple pre-configured DNS servers to evaluate the connectivity and forwarding quality of each link;

[0008] Prioritize each DNS server according to the score, obtain the best available DNS server and forward the domain name request, and forward the response result returned by the DNS server to the user terminal device;

[0009] If all configured DNS servers fail, the domain name resolution result is obtained through the local disaster recovery cache or disaster recovery cloud server according to the pre-configured disaster recovery strategy and forwarded to the user-end device;

[0010] Quickly diagnose multiple pre-configured DNS servers and upload the diagnosis results to the cloud for intelligent analysis and alarm.

[0011] Furthermore, multiple pre-configured DNS servers are scored to evaluate the connectivity and forwarding quality of each link, including:

[0012] Based on the collected DNS, ICMP and ARP packets, the DNS server score is calculated according to the reference attribute strategy combined with the actual requested domain name and the connection and failure conditions. The scoring factors include the DNS server response speed, request success rate, and the connection speed of the domain name corresponding to the IP. If the DNS server fails, the DNS server score is 0.

[0013] A query matrix based on connection speed or domain name is formed according to the domain name and the scoring factor, and the query matrix is ​​used to obtain the IP with the fastest connection speed corresponding to the domain name according to the domain name query.

[0014] Further, according to the pre-configured disaster recovery strategy, the domain name resolution result is obtained through the local disaster recovery cache or the disaster recovery cloud server and forwarded to the user terminal device, specifically including:

[0015] The cloud server used for disaster preparedness uses a fixed IP address. When the local DNS fails, the resolution request is forwarded to the cloud through the encrypted connection of the fixed IP address. After the cloud DNS database is queried and the resolution is completed, it is restored to the internal host from the cloud.

[0016] The hosts file for resolving domain names set locally only backs up a small number of special domain names, and the cloud DNS database serves as the second disaster recovery cache. When the domain name is returned after DNS resolution is completed, it checks whether the IP values ​​of each domain name of a specific type are updated. If updated, it is written to the local first disaster recovery cache and then updated to hosts, so that it can be enabled when the DNS server cannot be used.

[0017] If the network connection fails completely, only the local first disaster recovery cache is used. If the network connection exists, it is sent to the cloud disaster recovery DNS query server for DNS resolution through a point-to-point network protocol, and the local disaster recovery cache is queried first. If it cannot be found, it will be obtained from the cloud.

[0018] Furthermore, multiple pre-configured DNS servers are quickly diagnosed, including:

[0019] The diagnosis modes include: active diagnosis: performing regular diagnosis at preset time intervals; passive diagnosis: triggering diagnosis based on preset passive trigger conditions, including the number of unresponsive messages exceeding a preset value; manual diagnosis: starting diagnosis based on manual operation;

[0020] The diagnosis methods include: diagnosing through a locally connected LAN-side detection device or directly diagnosing the DNS server using a cloud-based diagnosis server.

[0021] Furthermore, the diagnosis results are uploaded to the cloud for intelligent analysis and alarm, including:

[0022] Intelligent analysis on the cloud or on the LAN side observation terminal:

[0023] Compare the differences based on the field attributes of DNS, including analyzing whether the relevant difference is the source MAC address or the destination MAC address, converting the message into text description content through message parsing, and checking whether there are obvious error prompts;

[0024] Focus on the DNS message content of unresponsive domain names with a high number of interruptions, and compare the characteristics of normal messages in the same environment byte by byte;

[0025] Based on the preset automatic diagnosis strategy for common DNS problems, screen whether there are matching message features; if no completely matching message features are found according to the preset automatic diagnosis strategy, detailed analysis or manual intervention analysis is required;

[0026] It also counts the DNS domain names that have not responded multiple times, and sends messages and preliminary analysis results to the cloud to discover the relevant DNS resolution situations.

[0027] Furthermore, the method further comprises:

[0028] When two DNS servers, primary and backup, are configured on different WAN interfaces, DNS resolution and detection are used to implement active / standby failover:

[0029] After registering with the primary DNS server, it will detect through DNS requests with options at regular intervals to determine whether the path to the primary DNS server is normal. If it is normal, keep the registration refresh unchanged. If it is abnormal, continue to detect whether the backup DNS server is available through DNS requests with options. If it is available, switch to the backup DNS server. If it is not available, wait for the set time before detecting again.

[0030] After registering on the backup DNS server, a DNS request with options is used to detect whether the primary DNS server is currently available at regular intervals. If available, switch to the primary DNS server for registration. If unavailable, continue to detect whether the backup DNS server is normal. If normal, keep the current registration refresh unchanged. If abnormal, wait for the set time before detecting again.

[0031] Furthermore, the method further comprises:

[0032] When both the primary and backup DNS servers are unavailable, stop sending DNS request packets and try to send requests to the public DNS server or ping the cloud server to determine whether the network is disconnected. If the detection fails, detect again after a set interval to prevent excessive DNS request packets from causing network congestion. When both the primary and backup servers fail and the network is normal, call the DNS cache of the cloud server and send it down.

[0033] According to a second aspect of an embodiment of the present invention, a DNS server connectivity diagnosis adaptive switching system is provided, the system comprising:

[0034] A scoring module is used to score multiple pre-configured DNS servers to evaluate the connectivity and forwarding quality of each link;

[0035] The adaptive module is used to prioritize the DNS servers according to the scores, obtain the best available DNS server, forward the domain name request, and forward the response result returned by the DNS server to the user terminal device;

[0036] The disaster recovery module is used to obtain the domain name resolution result through the local disaster recovery cache or the disaster recovery cloud server according to the pre-configured disaster recovery strategy and forward it to the user terminal device if all configured DNS servers fail;

[0037] The diagnostic module is used to quickly diagnose multiple pre-configured DNS servers and upload the diagnostic results to the cloud for intelligent analysis and alarm.

[0038] According to a third aspect of an embodiment of the present invention, a DNS server connectivity diagnosis adaptive switching device is provided, the device comprising: a processor and a memory;

[0039] The memory is used to store one or more program instructions;

[0040] The processor is used to run one or more program instructions to execute the steps of a DNS server connectivity diagnosis adaptive switching method as described in any one of the above items.

[0041] According to a fourth aspect of an embodiment of the present invention, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of a DNS server connectivity diagnosis adaptive switching method as described in any one of the above items are implemented.

[0042] The present invention proposes a DNS server connectivity diagnosis adaptive switching method and system, which scores multiple pre-configured DNS servers to evaluate the connectivity and forwarding quality of each link; prioritizes each DNS server according to the score, obtains the best available DNS server and forwards the domain name request, and forwards the response result returned by the DNS server to the user-end device; if all configured DNS servers fail, the domain name resolution result is obtained through the local disaster recovery cache or the disaster recovery cloud server according to the pre-configured disaster recovery strategy and forwarded to the user-end device; the pre-configured multiple DNS servers are quickly diagnosed, and the diagnosis results are uploaded to the cloud for intelligent analysis and alarm. The present invention can solve the problem of reducing the adaptation workload of environmental diagnosis, firmware adaptation, and firmware upgrades caused by environmental changes in DNS security policies and a large amount of repeated diagnostic work for operation and maintenance personnel, so that the DNS forwarding service built into gateway devices such as ONTs can improve performance and increase diagnostic means. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the implementation methods of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for the implementation methods or the description of the prior art. Obviously, the drawings in the following description are only exemplary, and for ordinary technicians in this field, other implementation drawings can be derived from the provided drawings without creative work.

[0044] The structures, proportions, sizes, etc. illustrated in this specification are only used to match the contents disclosed in the specification so as to facilitate understanding and reading by persons familiar with the technology. They are not used to limit the conditions under which the present invention can be implemented, and therefore have no substantial technical significance. Any structural modification, change in proportion or adjustment of size shall still fall within the scope of the technical contents disclosed in the present invention without affecting the effects and purposes that can be achieved by the present invention.

[0045] Figure 1A flowchart of a DNS server connectivity diagnosis adaptive switching method provided by an embodiment of the present invention;

[0046] Figure 2 A network architecture diagram of a DNS server connectivity diagnosis adaptive switching method provided by an embodiment of the present invention;

[0047] Figure 3 A cloud-based diagnostic server flow chart of a DNS server connectivity diagnostic adaptive switching method provided by an embodiment of the present invention;

[0048] Figure 4 A schematic diagram of the structure of a DNS server connectivity diagnosis adaptive switching system provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0049] The following is a description of the implementation of the present invention by specific embodiments. People familiar with the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0050] The concept of the present invention mainly includes the following parts:

[0051] The first part is to achieve rapid diagnosis by detecting the forwarding status of multiple DNS and the direct connection status of the downstream devices (network devices downstream of the ONT). This can be manually triggered to make a preliminary response to such problems. Specifically, by collecting DNS, ICMP, and ARP messages, the DNS server score is calculated based on the reference attributes to diagnose the connectivity and forwarding quality of the link.

[0052] The second part counts the DNS domain names that have not responded for many times, sends the message and the preliminary analysis results to the cloud, and is used to discover the relevant resolution status of the DNS. Record the relevant status of normal and abnormal resolution, response speed, whether a single resolution is successful, whether the connection is successful, the delay, and the aging time (how long will it take to request again if the cache is cleared).

[0053] The third part, self-adaptation, directly queries the domain name configuration of the current DNS server through user calculation, scores and detects the DNS response according to the fallback algorithm, records the success rate of the DNS request and adjusts it in real time. When the device gets the domain name reply from the primary DNS server successfully, it selects one of the replying IPs to connect. If the IP of the primary DNS server is unsuccessful, the client part switches to query from the DNS server, tries to compress the DNS response time, and finds out the actual situation of the DNS response. The advantage is dynamic deployment, which can be quickly expanded without changing the configuration on the user side, and automatically resolves the new IP to register according to the registration cycle.

[0054] The prior art focuses on forwarding itself, rather than the diagnosis that the present invention focuses on, including whether the channel to the DNS server exists, whether the connection is reliable, and including the core scoring factors in a fixed DNS domain name for comprehensive evaluation to generate a diagnostic report. The purpose of the present invention is to detect whether there are obvious problems in the forwarding process from ONT to DNS server, and to provide methods such as dynamic optimization (caching) and disaster relief mode.

[0055] The first embodiment of the present invention provides a DNS server connectivity diagnosis adaptive switching method, as shown below: Figure 1 and Figure 2 Provide explanation.

[0056] like Figure 1 As shown, in step S100, a plurality of pre-configured DNS servers are scored to evaluate the connectivity and forwarding quality of each link.

[0057] In one example, the biggest difference from the prior art is that only the fixed first DNS and second DNS are retained according to the conventional DNS settings, and the priority is determined based on the connection quality score, and the DNS request is sent to the best or even the two best DNSs.

[0058] Conventional WAN interfaces are configured with PPPoE or DHCP services. When an address is obtained through a DHCP server, a DNS server will be assigned at the same time.

[0059] First, the connection between the existing first DNS and the second DNS is detected to determine whether to trigger the switch of DNS and update the scoring. The details are as follows:

[0060] Real-time monitoring of the connection status of the current first DNS server and the second DNS server. First, mainly through passive statistics of the DNS request forwarding status of the ONT's downstream devices, statistics are given to the DNS connection, that is, statistics are given to the performance status of the round-trip response process of the DNS request. Secondly, through the active second cache history record cached by the ONT itself, when a domain name reaches the aging time, the first cache history record of the domain name that the corresponding DNS server has resolved and responded to is updated, and the aging time is recorded (the most recent forwarding request time, the time when the downstream device requested a certain domain name, and the response speed have been recorded before, so the aging time of the domain name should be recorded here, which can facilitate the cloud-side analysis to correctly forward the downstream device), without waiting for the DNS request of the downstream device, and the preferred DNS is selected again to initiate the query.

[0061] The history of ONT's own cache, that is, the first cache contains domain names, IP addresses, and DNS server resolution performance status parameters, which are refreshed in time according to the requests forwarded to the DNS server. These historical records are stored in the first cache of ONT, and will be simplified in the second cache. Only the domain name and the best address mapping records are written to the second cache to ensure that the IP address is new enough. The expiration time is defined as 3 minutes, and the first-in-first-out is cleared according to the cache entry capacity, corresponding to the domain name and IP address mapping records in the DNS server's response to the ONT. The second cache directly responds to the downstream device, and the priority aging of the second cache deletes the domain name and IP that are not continuously accessed. When a new DNS request comes, the best DNS server will be selected according to the calculation and analysis of the first cache to request. The obtained IP address record will be written to the second cache and the first cache at the same time, and replied to the downstream device.

[0062] In passive mode, if a DNS server is found to have many unresponsive responses when resolving multiple domain name requests, the switch will be triggered to forward the failed domain name requests to another preferred server that has not failed, and the quality score record of the first failed DNS will be updated. If there is a network failure, it will be given a score of 0.

[0063] The present invention compares the performance of each request based on the granularity of the domain name, rather than the traditional comparison of each request for the indifferent domain name of the server. Multiple factors are calculated through weighted relationships. For a single domain name, the DNS server score = connectivity * success rate (number of successes per unit time) * (a*1 / DNS response time + b* (∑(1 / ping delay of IP address n)). In general, the multiple addresses returned by the DNS are the same number, and each ping time should be similar, but it is not ruled out that the DNS is not timely in some cases, and the IP that has been replied is problematic. In this case, the request needs to be forwarded to another DNS server. It is possible that both DNSs have problems. The quality score is updated according to the feedback of the backup DNS server. The core is the connectivity check. More preferably, the present invention will also record the time from the resolution request from the client device to the local proxy and the time when the DNS server returns the domain name IP address record to the local proxy, as well as the successful time and failed status code of forwarding the domain name IP address record to the client device, which is the cause of the forwarding failure caused by network failure or security policy, and is used for analysis when diagnosing DNS resolution problems.

[0064] The adaptive strategy includes switching if a single DNS fails, and using the cache to continue working if both DNSs fail (the DNS proxy service uses the records in the second cache to continue providing services to the downstream devices, and if the aging time is reached, it also tries to use the cloud diagnostic server to update the feasible IP address) until recovery and providing a diagnostic report (data is aggregated to the cloud for analysis and output).

[0065] The traditional DNS scoring mechanism is simply based on the connection status of one or more servers for optimization. The present invention is to comprehensively score the DNS server and the actual requested domain name, combined with the on-off fault situation, to determine whether any fault has occurred, implement reasonable optimization and avoidance measures, and send a domain name in parallel to different DNS servers for diagnosis. Fault scoring factors include: domain name server connection speed (confirmed by ping to the DNS server response time, UDP round-trip time), request success rate (whether the domain name and IP are returned), domain name IP connection speed (the upstream DNS server will return the server IP address list corresponding to the domain name, and record the DNS server that returns the fastest IP that can be connected); these factors simplify the judgment, improve the execution efficiency, and adopt more sophisticated strategies and scoring factors when a fault occurs, that is, the second scoring strategy.

[0066] A query matrix based on connection speed or domain name is formed according to the domain name and scoring factors. The domain name data in the query matrix is ​​used to find the most suitable IP address (IP with fast ping response, DNS domain name cache disaster recovery strategy enabled). If the DNS server is available, the best server is selected to initiate the request. The best score comes from the evaluation result calculated in the cloud by the query matrix data. ONT can send the best first or concurrently.

[0067] like Figure 1 As shown, in step S200, each DNS server is prioritized according to the score, the best available DNS server is obtained and the domain name request is forwarded, and the response result returned by the DNS server is forwarded to the user terminal device.

[0068] like Figure 1 As shown, in step S300, if all configured DNS servers fail, the domain name resolution result is obtained through the local disaster recovery cache or the disaster recovery cloud server according to the pre-configured disaster recovery strategy and forwarded to the user terminal device.

[0069] Disaster preparedness strategies include:

[0070] Check whether the DNS server assigned by the upstream DHCP server is an intranet or public network server, and strengthen the cache strategy;

[0071] It can be confirmed by the IP address type of the DNS server and whether the cloud and DNS are interoperable, such as Class A, Class B, and Class C. If it is confirmed that they are all intranet DNS, the DNS request situation will be cached, including but not limited to: cloud backup through network connection, cloud servers used for disaster recovery preferably use fixed IP addresses, when the local DNS fails, the resolution request is forwarded to the cloud through the fixed IP address encrypted connection, and the cloud DNS database is queried and restored to the internal hosts file by the cloud after the resolution is completed; the hosts file for the locally set resolution domain name backs up a small number of special domain names, and serves as the second disaster recovery cache in the cloud DNS database. , special domain names are marked according to the business type, such as multicast business server, intranet use, etc. After the DNS resolution is completed, when the domain name is returned, check whether the IP value of each domain name of a specific type is updated, then write it into the local first disaster recovery cache, and then update it to hosts, which can be used when the DNS server cannot be used; if the network connection fails completely, only the local first disaster recovery cache is used. If the network connection exists, it is sent to the cloud disaster recovery DNS query server for DNS resolution through a point-to-point network protocol. It is preferred not to use the DNS protocol, but to use TCP encrypted connection, and if the query is given priority to the local disaster recovery cache, it will be obtained from the cloud if it cannot be found. On the other hand, the connectivity of the two currently set DNSs is checked regularly at the same time.

[0072] like Figure 1 As shown, in step S400, a quick diagnosis is performed on multiple pre-configured DNS servers, and the diagnosis results are uploaded to the cloud for intelligent analysis and alarm.

[0073] Quickly diagnose the DNS server. This step is checked in parallel with the previous step.

[0074] The existing technology only pre-configures the equipment when connecting to the operator's network, the WAN port and LAN port of the optical network connection, and then automatically obtains upstream information, convenient default WAN configuration, and DNS multiple servers; the smart terminal has a built-in DNS service forwarding. When the remote WAN configuration responds, different WAN interfaces may have different DNS services, and the DNS needs to be scored for the services of different interfaces and downstream devices. In the existing technology, the DNS is often the DNS of the LAN device attached to the ONT, and it is possible that the connection cannot be made.

[0075] If the downstream device is an OTT box, the ONT needs to set up an IPTV WAN interface and bind a LAN port to the OTT box or obtain DNS through the Internet WAN interface. The data stream of the final IPTV service is not in the same WAN. If it is an Internet-based VoIP server, the DNS of a specific WAN should also be requested to obtain the IP corresponding to the voice server domain name.

[0076] Therefore, it is necessary to proactively conduct preliminary diagnosis of current server failures at regular intervals and collect the topology and network protocol communication status from the ONT to the DNS server.

[0077] In an example:

[0078] The first part is to achieve rapid diagnosis by detecting the forwarding status of multiple DNS and the direct connection status of the downstream devices. The diagnosis can be triggered manually to quickly respond to such problems. Normally, diagnosis is performed regularly to detect DNS problems. The diagnostic mode can also be triggered when there are many unresponsive DNS messages. Both scheduled processing and triggered processing are taken into account. For example, the success rate of multiple requests for a domain name will be counted every period of time. If it is not too low, it will continue to the next cycle. This is called active diagnosis. Various domain names (mainstream and popular) have completely failed, and all requests have no response. Passive trigger diagnosis (recording the failure probability is ongoing).

[0079] When any DNS server fails, the DNS diagnostic mode is triggered (the prior art does not diagnose the DNS service of embedded devices).

[0080] (1) Collect DNS, ICMP, and ARP messages, and calculate the DNS server score based on the reference attribute strategy to diagnose the connectivity and forwarding quality of the link.

[0081] Update the query matrix described above, check the resolution requests and performance records of multiple domain names to the DNS server, select the DNS service forwarding strategy for the subsequent selection and select the appropriate IP for caching according to the connection status of the resolved IP, reduce the efficiency of the ONT forwarding service when encountering a DNS attack, and allow the downstream devices to access the network faster and better; generally, the ONT device has multiple WAN interfaces, and one WAN is often configured with two DNSs or a custom DNS that can be changed to a static one.

[0082] ARP failure is not necessarily a problem, because there may be security policies that cause the upstream server to not respond. If there is no ICMP response, execute traceroute to see if there is a response, but there may not be a response. Set a connectivity threshold. If the connection request initiated by ping diagnosis is not supported at the beginning and ICMP cannot be unobstructed, do not set the first unobstructed threshold on the WAN side. If it can be unobstructed at the beginning, then according to the number of DNS servers, first learn to set a reasonable TTL return value and ICMP response status for each DNS server as a reference. For example, you can choose 3 successful replies within 5 seconds as the first DNS unobstructed threshold on the WAN side.

[0083] When the first unobstructed threshold on the WAN side is not reached, the query matrix is ​​triggered to update the statistics. When the DNS service is relatively smooth, the statistics are updated. At this time, most of the domain name resolutions can be successful and periodic detection is performed. When large-scale failures occur, the link is disconnected and the forwarding quality scores of all DNS are 0. Find the best DNS based on the score sorting, and further find the IP corresponding to the best domain name. Detect the subsequent situations separately and prioritize them when forwarding DNS servers. When forwarding DNS, you can detect or forward DNS request services one by one based on this sorting result. Remove unresponsive DNS servers (those that have recovered and are better can continue to be used), and give priority to forwarding through the best DNS server.

[0084] The premise for triggering the diagnostic mode is that the network fixed detection cache IP address is accessible, but the access with the domain name is unavailable, it can be judged that there is a DNS service problem, and the relevant messages of the request to resolve the domain name are automatically marked and transmitted together with other related messages; this requires that the records of domain names and IP addresses should not be cleared before the cache is full or aged, and updated when resolved, and the time of the first request, the time of successful update, and the time of failed update are recorded. This is a negative record used to diagnose DNS resolution data, which is transmitted to the cloud, and the local cache only saves a few of the most recently accessed addresses or does not save them.

[0085] When a DNS problem occurs during quick diagnosis and the domain name resolution result cannot be obtained through the DNS server, the domain name and IP address records backed up in the cloud are directly obtained through the cloud diagnostic server that is always connected, rather than through the domain name server (DNS). If the cloud diagnostic server is not connected, it is considered to be disconnected, and it is necessary to wait until the network is restored before obtaining the domain name or completing the cloud diagnosis and storage.

[0086] The gateway collects the information before and after forwarding to the WAN port and LAN port. When the original primary and backup servers have problems, the IP registration process corresponding to the domain name of the original primary and backup DNS servers fails, and then actively switches to the suboptimal DNS server. The original directly specified WANIP and DNS server itself are replaced with a public network server similar to 6.6.6.6 or other alternative default DNS addresses that can be determined by ICMP diagnosis and other means to determine that the link is unobstructed. This can be fixed in the device firmware. If necessary, the DNS server accessed by the WAN interface corresponding to the local machine can be recorded. Because in daily use, the DNS server is specified by the DHCP service according to the ONT or router restart, so it can be backed up and used to try to connect to initiate a resolution request when a DNS failure occurs in the short term.

[0087] (2) When the detection is that the DNS is completely paralyzed, the forwarding detection mode is started. Because different DNS clients comply with the protocol, but they are adapted by different manufacturers, the performance will be different. Perhaps one of them can be seen. This method system mainly refers to the ONT, and the forwarding message of the LAN side device can be used for reference and comparison.

[0088] Removing the forwarding detection mode mainly includes obtaining the existing LAN device, setting the bridge binding interface or restoring it to routing. This allows the second LAN device used for detection or the network application built into the ONT to directly initiate a request to the DNS server upstream of the WAN interface, and the entire process is reached through multi-hop routing.

[0089] Or in the routing mode after NAT address translation, the WAN interface will obtain one or two DNSs, and the DNS relay function will be enabled. The DNS server forwarded on the WAN side will be directly passed to the LAN device through the LAN. The VLAN ID sets the VLAN ID required by the LAN device so that the LAN device can obtain the IP that can access the Internet. At this time, the LAN device sends a DNS message. If there is no NAT address translation between the WAN and LAN, it is directly transmitted and the corresponding DNS message is directly captured. For example, the source IP address is the LAN device and the destination IP address is the DNS server. It is used for analysis and comparison with normal messages. If NAT address translation is set, obtain the DNS message of the WANIP of the DNS of the specified IP that needs to be detected after address translation, and the LAN side message;

[0090] Directly bridge to DNS, so that LAN devices can be bridged to external links, the ONT internally captures the network of the bridged WAN interface created by the ONT, obtains DNS interaction messages, and transmits them to other messages for collecting mirrored WAN interfaces. If necessary, the corresponding test diagnosis scenario and file name can be prompted.

[0091] You can manually trigger the switch to remotely trigger diagnosis, or issue instructions on the device directly connected to the ONT, because in many cases the diagnosis cannot be performed on the entire link, and only the nearest link of the ONT device can be obtained. The second LAN device used for observation (i.e., the additionally connected detection device) is responsible for collecting DNS messages without operational interference and performing preliminary diagnosis based on limited information, as shown in the content and steps of the first step of the first part.

[0092] Even better, if Figure 3 As shown, the cloud DNS diagnostic server directly diagnoses the DNS server to obtain the domain name and address mapping; it is deployed on the same link as the diagnostic DNS and directly connected to the DNS server to perform relevant DNS diagnosis, directly obtain the alarm information of the DNS security policy and / or the domain name and address mapping table for backup; if the user or gateway of the access network cannot resolve, then there may be a problem in a certain link in the intermediate link, and it can be detected whether there is any missing loop process in the message.

[0093] The second part is to achieve adaptive adaptation. According to the above-mentioned score value, only forward to the preferred DNS server and the designated WAN interface, judge the situation, and sort by rate from high score to low score. The strict steps of security detection can eliminate the faulty DNS. You can manually set its priority to be higher or lower than the regular DNS priority. Then it is the disaster relief mode. Because the DNS assigned by DHCP often contains some domain names that the public DNS is not aware of, only when a failure occurs, adaptive adjustment is required to store the undisclosed domain name in the cloud diagnostic server. When preparing for disasters, the undisclosed domain name and IP address are used to restore to the local ONT. The undisclosed domain name can be resolved and confirmed by the cloud diagnostic server to the reachable public DNS server. The present invention performs more detection on the cloud side and the local side to ensure fine service.

[0094] The first DNS, second DNS, and common DNS of the public network are automatically configured and issued to replace the primary DNS. This also makes it easy to find out the real cause of the DNS connectivity problem, whether it is a failure triggered by a security policy or a failure caused by other non-connectivity failures.

[0095] You can select multiple DNS resolution paths (you can select an optimal server based on the domain name, or send messages to multiple DNS servers in parallel), reduce the amount of forwarding, adapt security policies, and implement detection and changes of security policies.

[0096] The third part will introduce the common remote analysis alarm steps:

[0097] Since the message information that can be viewed by suppliers and operators is different, the present invention is aimed at the scope that can be detected in any link, because even the operator's own employees may not have the authority to find the location where the DNS problem occurs in the first time. Therefore, the present invention provides that after the LAN side exports the message and the cloud connection is successful, the cloud server can obtain relevant information and preliminary comparison results for qualitative analysis. The output report can be sent to a specified mailbox or a specified URL address, and transmitted in the form of a file for alarm.

[0098] Part 4: Cloud-based intelligent analysis of DNS issues:

[0099] The cloud server itself is set up. For ONT, a fixed IP address that is successfully cached is required. The IP address should not be changed easily. Try to dynamically update it to places such as hosts when the network is normal. When DNS is used to resolve the IP address, cloud diagnosis and alarm collection can be performed stably.

[0100] Intelligent analysis on the cloud or on the LAN side observation terminal:

[0101] According to the field attributes of DNS, the differences are compared and analyzed to find out whether the relevant differences are the source MAC address or the destination MAC address, etc. After the message is parsed, it is converted into text description content to check whether there are obvious error prompts;

[0102] Focus on the DNS message content of domain names with more interruptions and no response, and compare them byte by byte with the characteristics of normal messages in the same environment;

[0103] The output presets several automatic diagnosis strategies for common DNS problems to screen whether there are message features. For example, if a DNS attack causes no response, it is necessary to correlate and calculate traffic features. For another example, normal messages respond quickly and continuously, and there are many places where no response messages appear. For the first one or two repeated DNS requests, due to no response, the DNS server response time exceeds a large gap threshold, and the tt l is abnormal. If the steps corresponding to the preset strategy do not find a completely matching message feature, an early warning will be issued if it exceeds the adaptive range, and refined analysis or manual intervention analysis is required;

[0104] It also counts the DNS domain names that have not responded multiple times, and sends messages and preliminary analysis results to the cloud to discover the relevant DNS resolution situations.

[0105] The fifth part, the adaptive step, scores the connection quality and selects the best DNS server:

[0106] When the network environment contains multiple WANs and different WANs have two primary and backup DNS servers, the primary and backup switching is realized through DNS resolution and detection. The IP addresses of the primary and backup servers are not directly notified to the DNS server terminal, but obtained through DNS domain name resolution. Sometimes domain name requests are all sent from different DNS servers, so different DNS servers need to be set up for each WAN interface to determine whether the path between the server is normal.

[0107] After registering with the primary DNS server, it will detect through DNS requests with options at regular intervals to determine whether the path to the primary DNS server is normal. If it is normal, keep the registration refresh unchanged. If it is abnormal, continue to detect whether the backup DNS server is available through DNS requests with options. If available, switch to the backup DNS server. If it is unavailable, wait for the set time before detecting again.

[0108] Among them, network path detection through DNS requests with specific options is a common network diagnostic technology, which is usually used to check the connection status and routing between the client and the primary DNS server. This detection method can reveal problems such as network latency, packet loss rate, and device status on the path, which helps to troubleshoot the reasons for DNS resolution failure or poor network performance. The following are several commonly used DNS request methods with options:

[0109] 1. DNS Traceroute (tracert or traceroute command) This is not a direct DNS request, but it can show all the routers on the path from your machine to the target DNS server. This can help identify network bottlenecks or failure points.

[0110] 2. Extended DNS (EDNS) EDNS allows DNS requests to contain additional data, such as larger response sizes, client subnet information (CS), etc. This can be used to test the EDNS compatibility of a DNS server, and can also be used to optimize local caching of DNS responses.

[0111] 3. DNS Query with Specific Options (such as using the dig or nslookup command) · When using the dig command, you can specify the DNS query type (such as A record, MX record, TXT record, etc.), and whether to use recursive query or non-recursive query. For example, dig+nocmd@8.8.8.8example.com A will send an A record query to Google's public DNS server. · The nslookup command also allows you to change the type of DNS query, and you can manually specify the DNS server address, such as nslookup-query=AAAA example.com 8.8.8.8. · DNSSEC Validation If you suspect that the DNS data has been tampered with, you can use the DNSSEC verification function. This requires that your DNS server supports DNSSEC, and the top-level domain and all intermediate domain name servers also support DNSSEC.

[0112] The specific steps for performing the above operations depend on the operating system and tools used. Therefore, it is better that the machine is equipped with a diagnostic device inside, and the built-in interactive channel can be used to send commands to control the diagnosis, which is not limited to the observation terminal on the LAN side.

[0113] After registering on the backup DNS server, a DNS request with options is used to detect whether the primary DNS server is currently available at regular intervals. If available, switch to the primary DNS server for registration. If unavailable, continue to detect whether the backup DNS server is normal. If normal, keep the current registration refresh unchanged. If abnormal, wait for the set time before detecting again.

[0114] In particular, when both the primary DNS server and the backup DNS server are unavailable, the DNS request packets will stop being sent and an attempt will be made to send them to the public DNS server or ping the cloud server to determine whether the network is disconnected. If the detection fails, the detection will be performed again after a set interval to prevent excessive DNS request packets from causing network congestion.

[0115] Secondly, when it is found that the DNS service is faulty and the network is normal, a temporary domain name and address mapping table is sent to the hosts of the ONT.

[0116] In the DNS resolution step based on hosts, when the previous DNS fails but the network is still unobstructed, the DNS cache (domain name and IP address mapping result) of the cloud server is called and sent to the DNS forwarding service of the ont;

[0117] When a fault is detected, it is sent to the affected ONT and LAN devices; otherwise, the LAN devices need to be manually informed to set up static DNS, which may increase the number of operation and maintenance communication links.

[0118] When the DNS diagnostic command is sent to the ONT or observation device (such as a PC), the internal DNS supported by the operator is re-detected. When it is found that the DNS link has returned to normal, the addresses and IP mapping contents related to Hosts are gradually removed.

[0119] The domain name and IP mapping results are sent to the domain name resolution hosts file of the ONT through the network connection, which is used for further direct use by the DNS request of the LAN device. The LAN terminal communicates according to the specified process after the IP successfully resolved by the hosts, and collects the corresponding destination IP and source address IP for the LAN device. This is the hosts diagnosis message. When the communication fails compared with the normal backup interaction process without hosts diagnosis, it can be judged that it is not a DNS problem, but an application layer communication problem. However, the record of communication failure is also reported. Then remove the record in the hosts to see if the DNS forwarding process is smooth.

[0120] Traditional technologies rely only on a relatively single DNS query path. The default single DNS or backup DNS often has no traffic control when abnormal phenomena occur. A large number of packets will be sent upstream for detection, and the final result will be returned to the earliest requester only after all servers have returned. This naturally leads to performance degradation, and the query path and the time to wait for the IP address of the returned domain name will increase dramatically, affecting network security.

[0121] As long as the DNS request with options detects that the path between the primary DNS server is normal, it will switch immediately and try to choose the DNS with better path quality to send. Due to the real-time detection mechanism, when the network is good, the forwarding overhead is minimal. Only when congestion or failure occurs will more detections be triggered. The detection process can be remotely controlled, reducing the cost of developers and operation and maintenance personnel to discover problems, especially when the operator connection is just started and the relevant network environment is not clear. It can greatly improve the efficiency of exploring the environment and provide reference information in time.

[0122] Thanks to the built-in DNS detection of cloud servers and home gateways, it can be ensured that when DNS problems occur, the relevant situation can be quickly grasped. When necessary, the self-built DNS in the cloud that triggers DNS cache cleaning and other operations can be used to specify the backup addresses of certain specific domain names. It only needs to adjust the uplink of the DNS request through this proxy DNS to reasonably resolve the currently faulty domain name without having to obtain the domain name from a well-known commercial DNS.

[0123] The domain name mapping IP configuration of the second set of DNS servers and voice servers is not necessarily stored on the root domain name server, but exists internally. It can be a temporary environment for DNS deployment on the backup line of the current first set of DNS servers. The server can maintain interoperability with other external operator networks, switch the DNS query link and the uplink of the voice WAN to the new route and gateway, and update the corresponding routing table to the home gateway corresponding to the DNS server client.

[0124] The existing configuration background of the dependency is:

[0125] 1. The home gateway with DNS server function obtains the IP addresses of the primary and backup servers through DNS query;

[0126] 2. Send a registration to the primary DNS server. If successful, it will be registered on the primary DNS server. If it fails, it will enter the primary-backup switch;

[0127] 3. Switch between primary and backup servers and re-register DNS resolution.

[0128] The existing technical process relies passively on client detection, ignoring the fact that there are multiple version environment switches in the production environment, such as experimental environment, production environment, and upgraded production environment.

[0129] In this embodiment, the first detection step includes two parts (the content of this part corresponds to the content of the aforementioned regular detection), a DNS detection step and a DNS server DNS request detection step; the former tests the path through the server, and the latter tests the protocol check of the DNS request itself, using DNS requests with various options to check whether there is any abnormality.

[0130] To detect the current primary DNS server, you need to send a DNS request for detection, and then send out corresponding options based on the obtained IP address for DNS request detection.

[0131] For the first detection step, a voice DNS request detection is sent to the first standby DNS server. If successful, proceed to step 4; if unsuccessful, proceed to step 5;

[0132] 4. Send registration to the first backup DNS server. If the registration is successful, it will be sent to the first backup DNS server. If it fails and the waiting time threshold reaches multiple detection cycles of DNS request detection, the detection environment changes smoothly and the packet volume is better controlled;

[0133] 5. For DNS request detection that is fast first and then slow, for example, wait for a T time first. If both the sending and the response are successful, you can wait for n more T times, preferably not more than half of the registration refresh time;

[0134] If it fails, wait for 2T and then send a DNS request probe to the primary DNS server again. If it succeeds, enter the registration process and maintain the session. If it fails, make the next DNS request query. Each time a DNS request query fails, the waiting time will double, 2T / 4T / 8T, until the total time reaches one detection cycle.

[0135] After registering on the primary DNS server, the steps are as follows:

[0136] 1. Send DNS request detection to the primary DNS server at intervals of T. If the DNS request detection is normal, control is performed according to the registration cycle. If the DNS request detection fails, after multiple DNS request detection attempts and one or more detection cycles are completed, the link switching mechanism is triggered.

[0137] For DNS detection, the principle of fast first and slow later is also followed. When the registration status is normal, a DNS request detection is sent to the primary DNS server at an interval of T. If successful, the detection time is increased. After completing a round of DNS, if there is no problem, a registration refresh instruction can be sent to the primary DNS server through the arrival of the registration cycle, and continue to register on the primary DNS server. If it fails, it will be transferred to the subsequent DNS server detection.

[0138] If the public DNS also fails to detect, a network disconnection may have occurred. You can perform tests such as traceroute to confirm this, and ultimately give a comprehensive analysis and adjustment strategy to provide strong support for the development and adaptation of the DNS service and the stability of operation and maintenance.

[0139] The present invention uses the process of DNS and DNS request detection to guide the client to independently complete the automatic switching of DNS forwarding services, and to make changes to hosts when necessary. This allows the client to actively migrate a single or multiple DNS server clients to complete some production deployment migration strategies when topology changes occur in the network, and solve the problem of using and installing new equipment. A small number of DNS server clients that fail can switch to backup DNS servers in multiple ways, enriching the adaptive stabilization means beyond manual detection of DNS requests and reducing the burden of manual analysis.

[0140] In particular, with the increasing number of security policies through DNS, adaptation and changes consume a lot of manpower. The present invention can enable the deployment of new production environments, and the client can flexibly adapt to migration, avoiding the rapid distribution of traditional DNS forwarding services in embedded devices to all DNS servers, or rapid retransmission, and avoiding attacks on DNS servers. It reduces the risk of concurrent traffic, reduces the iterative upgrade of user adjustment and maintenance of network quality, improves robustness, and solves the problem of deployment flexibility.

[0141] Corresponding to the above disclosed DNS server connectivity diagnosis adaptive switching method, the embodiment of the present invention also discloses a DNS server connectivity diagnosis adaptive switching system, such as Figure 4 As shown, it specifically includes:

[0142] A scoring module is used to score multiple pre-configured DNS servers to evaluate the connectivity and forwarding quality of each link;

[0143] The adaptive module is used to prioritize the DNS servers according to the scores, obtain the best available DNS server, forward the domain name request, and forward the response result returned by the DNS server to the user terminal device;

[0144] The disaster recovery module is used to obtain the domain name resolution result through the local disaster recovery cache or the disaster recovery cloud server according to the pre-configured disaster recovery strategy and forward it to the user terminal device if all configured DNS servers fail;

[0145] The diagnostic module is used to quickly diagnose multiple pre-configured DNS servers and upload the diagnostic results to the cloud for intelligent analysis and alarm.

[0146] It should be noted that for the detailed description of a DNS server connectivity diagnosis adaptive switching system provided in an embodiment of the present invention, reference can be made to the relevant description of a DNS server connectivity diagnosis adaptive switching method provided in an embodiment of the present application, which will not be repeated here.

[0147] In addition, an embodiment of the present invention also provides an electronic device, comprising: a processor and a memory; the memory is used to store one or more program instructions; the processor is used to run one or more program instructions to execute the steps of a DNS server connectivity diagnosis adaptive switching method as described in any of the above items.

[0148] It should be noted that, for the detailed description of an electronic device provided in an embodiment of the present invention, reference can be made to the relevant description of a DNS server connectivity diagnosis adaptive switching method provided in an embodiment of the present application, which will not be repeated here.

[0149] In addition, an embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of a DNS server connectivity diagnosis adaptive switching method as described in any one of the above items are implemented.

[0150] It should be noted that, for a detailed description of a computer-readable storage medium provided in an embodiment of the present invention, reference can be made to the relevant description of a DNS server connectivity diagnosis adaptive switching method provided in an embodiment of the present application, which will not be repeated here.

[0151] In the embodiment of the present invention, the processor may be an integrated circuit chip having the ability to process signals. The processor may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0152] The methods, steps and logic block diagrams disclosed in the embodiments of the present invention can be implemented or executed. The general processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in the embodiments of the present invention can be directly embodied as a hardware decoding processor for execution, or can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The processor reads the information in the storage medium and completes the steps of the above method in combination with its hardware.

[0153] The storage medium may be a memory, which may be, for example, a volatile memory or a nonvolatile memory, or may include both volatile and nonvolatile memory.

[0154] Among them, the non-volatile memory can be a read-only memory (ROM), a programmable ROM (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory.

[0155] The volatile memory may be a random access memory (RAM) which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDRSDRAM), enhanced synchronous DRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM bus DRAM (DRRAM).

[0156] The storage media described in the embodiments of the present invention are intended to include, but are not limited to, these and any other suitable types of memory.

[0157] Those skilled in the art will appreciate that in one or more of the above examples, the functions described in the present invention can be implemented using a combination of hardware and software. When software is used, the corresponding functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any media that facilitates the transmission of computer programs from one place to another. Storage media can be any available media that can be accessed by general or special-purpose computers.

[0158] Although the present invention has been described in detail above by general description and specific embodiments, it is obvious to those skilled in the art that some modifications or improvements can be made to the present invention. Therefore, these modifications or improvements made without departing from the spirit of the present invention all belong to the scope of protection claimed by the present invention.

Claims

1. A DNS server connectivity diagnosis adaptive switching method, characterized in that: The method comprises: Scoring multiple pre-configured DNS servers to evaluate the connectivity and forwarding quality of each link; Prioritize each DNS server according to the score, obtain the best available DNS server and forward the domain name request, and forward the response result returned by the DNS server to the user terminal device; If all configured DNS servers fail, the domain name resolution result is obtained through the local disaster recovery cache or disaster recovery cloud server according to the pre-configured disaster recovery strategy and forwarded to the user-end device; Quickly diagnose multiple pre-configured DNS servers and upload the diagnosis results to the cloud for intelligent analysis and alarm.

2. A DNS server connectivity diagnosis adaptive switching method according to claim 1, characterized in that: Scores multiple pre-configured DNS servers to evaluate the connectivity and forwarding quality of each link, including: Based on the collected DNS, ICMP, and ARP messages, the DNS server score is calculated according to the reference attribute strategy combined with the actual requested domain name and the connection and failure conditions. The scoring factors include the DNS server response speed, request success rate, and the connection speed of the domain name corresponding to the IP. If the DNS server fails, the DNS server score is 0. A query matrix based on connection speed or domain name is formed according to the domain name and the scoring factor, and the query matrix is ​​used to obtain the IP with the fastest connection speed corresponding to the domain name according to the domain name query.

3. A DNS server connectivity diagnosis adaptive switching method according to claim 1, characterized in that: According to the pre-configured disaster recovery strategy, the domain name resolution result is obtained through the local disaster recovery cache or the disaster recovery cloud server and forwarded to the user terminal device, including: The cloud server used for disaster preparedness uses a fixed IP address. When the local DNS fails, the DNS resolution request is forwarded to the cloud through the encrypted connection of the fixed IP address. After the cloud DNS database is queried and the resolution is completed, it is restored to the internal hosts file by the cloud. The hosts file for resolving domain names set locally only backs up a small number of special domain names, and the cloud DNS database serves as the second disaster recovery cache. When the domain name is returned after DNS resolution is completed, it checks whether the IP values ​​of each domain name of a specific type are updated. If updated, it is written to the local first disaster recovery cache and then updated to hosts, so that it can be enabled when the DNS server cannot be used. If the network connection fails completely, only the local first disaster recovery cache is used. If the network connection exists, it is sent to the disaster recovery DNS query server in the cloud for DNS resolution through a point-to-point network protocol, and the local disaster recovery cache is queried first. If it cannot be found, it will be obtained from the cloud. Finally, the IP address is obtained and returned to the user-end device.

4. A DNS server connectivity diagnosis adaptive switching method according to claim 1, characterized in that: Quickly diagnose multiple pre-configured DNS servers, including: Diagnostic modes include: Active diagnosis, regular diagnosis at preset time intervals; Passive diagnosis: diagnosis is triggered according to preset passive trigger conditions, including the number of unresponsive messages exceeding a preset value; Manual diagnosis: start the diagnosis according to manual operation; When the diagnostic mode is enabled, the diagnostic methods include: performing diagnosis through a locally connected LAN-side detection device or using a cloud-based diagnostic server to directly diagnose the DNS server, and performing diagnosis bypassing the local DNS proxy.

5. A DNS server connectivity diagnosis adaptive switching method according to claim 1, characterized in that: Upload the diagnosis results to the cloud for intelligent analysis and alarm, including: Intelligent analysis on the cloud or on the LAN side observation terminal: Compare the differences based on the field attributes of DNS, including analyzing whether the relevant difference is the source MAC address or the destination MAC address, converting the message into text description content through message parsing, and checking whether there are obvious error prompts; Focus on the DNS message content of unresponsive domain names with a high number of interruptions, and compare the characteristics of normal messages in the same environment byte by byte; Based on the preset automatic diagnosis strategy for common DNS problems, screen whether there are matching message features; if no completely matching message features are found according to the preset automatic diagnosis strategy, detailed analysis or manual intervention analysis is required; It also counts the DNS domain names that have not responded multiple times, and sends messages and preliminary analysis results to the cloud to discover the relevant DNS resolution situations.

6. A DNS server connectivity diagnosis adaptive switching method according to claim 1, characterized in that: The method further comprises: When two DNS servers, primary and backup, are configured on different WAN interfaces, DNS resolution and detection are used to implement active / standby failover: After registering with the primary DNS server, it will detect through DNS requests with options at regular intervals to determine whether the path to the primary DNS server is normal. If it is normal, keep the registration refresh unchanged. If it is abnormal, continue to detect whether the backup DNS server is available through DNS requests with options. If it is available, switch to the backup DNS server. If it is not available, wait for the set time before detecting again. After registering on the backup DNS server, a DNS request with options is used to detect whether the primary DNS server is currently available at regular intervals. If available, switch to the primary DNS server for registration. If unavailable, continue to detect whether the backup DNS server is normal. If normal, keep the current registration refresh unchanged. If abnormal, wait for the set time before detecting again.

7. A DNS server connectivity diagnosis adaptive switching method according to claim 6, characterized in that: The method further comprises: When both the primary and backup DNS servers are unavailable, stop sending DNS request packets and try to send requests to the public DNS server or ping the cloud server to determine whether the network is disconnected. If the detection fails, detect again after a set interval to prevent excessive DNS request packets from causing network congestion. When both the primary and backup servers fail and the network is normal, call the DNS cache of the cloud server and send it down.

8. A DNS server connectivity diagnosis adaptive switching system, characterized in that: The system comprises: A scoring module is used to score multiple pre-configured DNS servers to evaluate the connectivity and forwarding quality of each link; The adaptive module is used to prioritize the DNS servers according to the scores, obtain the best available DNS server, forward the domain name request, and forward the response result returned by the DNS server to the user terminal device; The disaster recovery module is used to obtain the domain name resolution result through the local disaster recovery cache or the disaster recovery cloud server according to the pre-configured disaster recovery strategy and forward it to the user terminal device if all configured DNS servers fail; The diagnostic module is used to quickly diagnose multiple pre-configured DNS servers and upload the diagnostic results to the cloud for intelligent analysis and alarm.

9. A DNS server connectivity diagnosis adaptive switching device, characterized in that: The device comprises: a processor and a memory; The memory is used to store one or more program instructions; The processor is used to run one or more program instructions to execute the steps of a DNS server connectivity diagnosis adaptive switching method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the DNS server connectivity diagnosis adaptive switching method as claimed in any one of claims 1 to 7 are implemented.

Images