Network access method and device in DNS hijacked scene and related product

Abstract

The invention discloses a network access method and device in a DNS hijacked scene and a related product, and relates to the technical field of network security. The method comprises the following steps: firstly, checking a local domain name resolution cache of a client, preferentially multiplexing a valid IP address cache, if the valid IP address cache is invalid, acquiring an IP address list corresponding to a target domain name through an IP direct connection trusted service interface, and bypassing a DNS resolution link; an IP address set with timeliness is generated and stored persistently, and address validity is guaranteed through regular refreshing of a double-judgment mechanism; a main domain name, a standby domain name and a local cache IP address are obtained based on the set, and a domain name-first progressive failover access strategy is generated in combination with multi-network configuration; and when the access of the main domain name and the standby domain name fails, automatically switching to the local cache IP address to initiate the access. According to the method and the device, stable network access in a DNS hijacking scene is realized, and reliable network access guarantee is provided for various software which depends on domain name access.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security, in particular to a network access method and device in a DNS hijacking scenario and related products. BACKGROUND

[0002] In the Internet application scenario, domain names have become the core entrance of network access due to their strong readability, easy memorability, brand recognition, support for virtual hosts and other advantages, and are widely used in resource positioning of various software and services. Whether in online education, file transfer or web browsing scenarios, users rely on domain names to achieve fast access to target services, and the stability of domain name resolution directly affects the normal operation of software functions.

[0003] In the prior art, there is a conventional solution for domain name resolution and access protection, which configures a backup domain name resolution server, switches to the backup server for re-resolution when the primary domain name resolution fails, to obtain the Internet Protocol address corresponding to the target domain name. At the same time, the local cache will cache the Internet Protocol address obtained by resolution, and the cached data will be called preferentially in subsequent access to reduce the time-consuming of repeated resolution. This solution improves the stability of domain name access to a certain extent through multi-resolution server configuration and simple caching mechanism.

[0004] However, the conventional solution has obvious technical defects: its core still relies on the domain name system for resolution, and when DNS hijacking occurs, both the primary and backup resolution servers may return incorrect Internet Protocol addresses, resulting in access failure; and the local cache lacks effective time management and dynamic refresh mechanism, and the cached Internet Protocol address may become invalid due to server configuration changes, which cannot provide reliable access backup for the domain name hijacking scenario and cannot guarantee the continuity of the core functions of the software in this scenario. SUMMARY

[0005] To solve one or more technical problems in the prior art, the present application provides a network access method in a DNS hijacking scenario, comprising: The local domain name resolution cache of the client is checked, if there is a non-expired IP address cache corresponding to the target domain name, the IP address list corresponding to the target domain name is directly obtained, otherwise, an IP address is directly used to initiate a network request to a preset trusted service interface to bypass domain name system resolution, to generate an IP address list corresponding to the target domain name; a time-limited client local domain name resolution cache IP address set is generated according to the IP address list corresponding to the target domain name; based on the time-limited client local domain name resolution cache IP address set, the primary domain name, the backup domain name and the local cache IP address associated with the target domain name are obtained and configured for multi-network enablement and priority IP address access, to generate a domain name priority progressive failover access strategy; based on the domain name priority progressive failover access strategy, switching to the local cache IP address to initiate access to the target resource server is performed.

[0006] The application also provides a network access device in a DNS hijacking scenario, comprising: The cache checking unit is configured to check the local domain name resolution cache of the client, if there is a non-expired IP address cache corresponding to the target domain name, the IP address list corresponding to the target domain name is directly obtained, otherwise, an IP address is directly used to initiate a network request to a preset trusted service interface to bypass domain name system resolution, to generate an IP address list corresponding to the target domain name; The cache management unit is configured to generate a time-limited client local domain name resolution cache IP address set according to the IP address list corresponding to the target domain name; The strategy generating unit is configured to obtain the primary domain name, the backup domain name and the local cache IP address associated with the target domain name based on the time-limited client local domain name resolution cache IP address set, and perform multi-network enablement and priority IP address access configuration, to generate a domain name priority progressive failover access strategy; The access executing unit is configured to perform switching to the local cache IP address to initiate access to the target resource server based on the domain name priority progressive failover access strategy.

[0007] The application also provides a computer device, which comprises a processor and a memory, and the memory stores at least one instruction or at least one program, the at least one instruction or the at least one program is loaded and executed by the processor to realize the network access method in the DNS hijacking scenario.

[0008] The application also provides a computer program product or a computer program, which comprises computer instructions, and the computer instructions are executed by a processor to realize the network access method in the DNS hijacking scenario.

[0009] The application has the following beneficial effects: First, in the Internet Protocol (IP) address acquisition stage, this application adopts a dual-path mechanism of "cache check + DNS-free acquisition". By pre-checking the existence and timeliness of the local DNS resolution cache, valid caches are reused first, reducing network request overhead. When the cache is invalid, a request is directly initiated using a preset trusted service interface IP address, completely bypassing the DNS resolution stage and avoiding the risk of resolution errors caused by domain name hijacking from the source. Compared with the existing technology that relies on DNS resolution, this design cuts off the impact path of domain name hijacking at the access link level, providing a reliable source of IP addresses for subsequent access. At the same time, signature data is generated and verified through a hash encryption algorithm to ensure the security of the IP address acquisition process, prevent request tampering, and further improve the reliability of address acquisition. In addition, in the cache management stage, this application constructs a full lifecycle management mechanism of "time-sensitive set generation + persistent storage + timed refresh". The generated client-side local domain name resolution cache Internet Protocol (IP) address set with timeliness integrates multi-dimensional information such as the IP address list, resolution time, and cache expiration time, providing a comprehensive basis for judging cache validity. Persistent cached data is achieved through serialized storage, ensuring that the cache can still be reused after the client restarts. A timed refresh thread, combined with a dual-judgment mechanism of existence and timeliness, dynamically updates the IP addresses in the cache, avoiding address invalidation due to server configuration changes. Compared with the simple caching design of existing technologies that lack dynamic updates, this mechanism significantly improves the timeliness and validity of cached data, providing a reliable address reserve for failover. Furthermore, in the access strategy construction stage, the "domain name priority + progressive failover" strategy designed in this application retains the natural advantages of domain names in terms of readability and brand recognition, while improving adaptability to different network environments through multi-network configuration and priority adaptation. The progressive process of "primary domain name → backup domain name → local cached IP address" achieves step-by-step fault coverage. Compared with the single resolution server switching of existing technologies, the failover coverage is wider and the fault tolerance is stronger. The flexible selection of multiple network enablement and priority Internet Protocol (IP) address access configuration allows the solution to adapt to different scenarios such as mobile networks and wireless networks, further expanding its application scope. Finally, in the access execution phase, based on the switching mechanism of the above strategy, when both the primary domain name and the backup domain name are inaccessible due to hijacking, access is automatically switched to the locally cached IP address, providing a fallback access solution in domain hijacking scenarios. This switching process is fully automated, ensuring the continuity of the software's core functions. For example, in online education scenarios, even in the event of domain hijacking, the switching of IP addresses can still ensure the normal operation of online teaching, recording, and other functions. Compared to the problem of existing technologies completely failing in hijacking scenarios, this method significantly improves the availability and stability of the software service.In summary, this method forms a complete technical closed loop through address acquisition without domain name system dependence, full lifecycle cache management, progressive failover strategy, and automated access switching. It effectively solves the core problem of access failure in domain name hijacking scenarios of existing technologies, while taking into account access efficiency, security, and environmental adaptability, and provides reliable network access protection for various software that rely on domain name access. Attached Figure Description

[0010] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof.

[0011] Fig. 1 This application provides an overall flowchart of a network access method in a DNS hijacking scenario. Fig. 2 A system block diagram of a network access device for a DNS hijacking scenario provided in this application embodiment; Fig. 3 This is a hardware structure block diagram of an electronic device for a network access method in a DNS hijacking scenario, as provided in an embodiment of this application. Detailed Implementation

[0012] The present invention will now be described in detail with reference to the accompanying drawings and embodiments. Various aspects are provided by way of explanation and not limitation of the invention. Indeed, those skilled in the art will recognize that modifications and variations can be made to the invention without departing from its scope or spirit. For example, a feature represented or described as part of one embodiment may be used in another embodiment to produce yet another embodiment. Therefore, it is desirable that the invention encompass such modifications and variations falling within the scope of the appended claims and their equivalents.

[0013] In the description of this invention, the terms "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," and "bottom," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and do not require the invention to be constructed and operated in a specific orientation; therefore, they should not be construed as limitations on the invention. The terms "connected," "linked," and "set up" used in this invention should be interpreted broadly. For example, they can refer to a fixed connection or a detachable connection; they can refer to a direct connection or an indirect connection through intermediate components. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.

[0014] like Figs. 1-3As shown, this application provides a network access method in a DNS hijacking scenario, including the following steps: checking the client's local domain name resolution cache; if an unexpired IP address cache corresponding to the target domain name exists, it is directly obtained; otherwise, a network request is directly initiated to a preset trusted service interface using the IP address to bypass the domain name system resolution, thereby generating a list of IP addresses corresponding to the target domain name; generating a time-sensitive client local domain name resolution cache IP address set based on the IP address list corresponding to the target domain name; based on the time-sensitive client local domain name resolution cache IP address set, obtaining the primary domain name, backup domain name, and local cache IP address associated with the target domain name, and configuring multi-network enabling and priority IP address access to generate a domain name-priority progressive failover access strategy; based on the domain name-priority progressive failover access strategy, switching to the local cache IP address to initiate access to the target resource server.

[0015] Optionally, the client's local domain name resolution cache is checked. If an unexpired Internet Protocol (IP) address corresponding to the target domain exists in the cache, it is directly retrieved. Otherwise, an IP address is used to directly initiate a network request to a preset trusted service interface to bypass the domain name system (DNS) resolution. After verification, the response data is obtained to generate a list of IP addresses corresponding to the target domain. This includes: checking the existence of the client's local domain name resolution cache by scanning the preset cache storage directory and searching for a cache file uniquely identified by the target domain to obtain a result indicating whether the cache exists or does not exist; if the cache exists, the cache file is checked for expiration by extracting the cache expiration time and comparing it with the current system time to obtain a result indicating whether the cache has not expired or has expired; if the cache does not exist or has expired, a network request is directly initiated using the preset trusted service interface IP address. After signature verification and response parsing, invalid IP addresses are removed to generate a list of IP addresses corresponding to the target domain; if the cache has not expired, the list of IP addresses corresponding to the target domain is directly extracted from the cache file.

[0016] Optionally, an existence check is performed on the client's local domain name resolution cache. This involves scanning a preset cache storage directory to find cache files uniquely identified by the target domain name, thus obtaining a cache presence or absence result. This includes: determining the client's preset local cache storage directory path, which is a pre-configured fixed storage path; scanning all files in the cache storage directory according to the naming rule of "target domain name - Internet Protocol cache"; comparing the association between the scanned file names and the target domain name, and obtaining a cache presence result if a file with a complete match exists, otherwise obtaining a cache absence result.

[0017] Preferably, the specific implementation process for determining the cache storage directory path is as follows: Based on the client's system environment parameters and application configuration information, the cache storage path is subjected to dual-verification anchoring processing to generate a trusted fixed cache path; specifically, firstly, the initial cache path written to the system configuration file during application installation is read, and then the read / write permissions and storage medium availability of the path are verified by the application's built-in path verification algorithm. If the verification passes, it is directly used as a trusted fixed cache path; if the verification fails (e.g., the path is tampered with or the storage medium is unavailable), then a backup trusted fixed cache path is dynamically reconstructed based on the relative path between the application's running directory and the preset cache directory. This dual-verification mechanism avoids the cache lookup failure problem caused by the traditional fixed path being easily tampered with or unavailable.

[0018] Preferably, in the specific technical implementation of scanning files according to naming rules: based on the characteristic information of the target domain name and the functional attributes of the cache file, the cache file is subjected to structured naming encoding processing to generate a domain-associated feature file name; specifically, the main field and suffix field of the target domain name are extracted, and the domain name standard string is obtained through character standardization processing (such as uniform conversion to lowercase and removal of special characters). Then, the domain name standard string is encrypted using an information digest algorithm (such as SHA-1), and a fixed-length encrypted string is extracted as the domain name feature code. Finally, the domain name-associated feature file name is generated by concatenating the structure "domain name standard string - Internet Protocol cache - domain name feature code". For example, when the target domain name is "Example.Service.com", the generated file name after processing is "example.service.com-Internet Protocol cache-7a3f9d2b". This structured naming not only ensures the unique association between the target domain name and the cache file, but also avoids matching confusion caused by similar names of different domain names through the feature code. At the same time, based on this naming rule, candidate files can be quickly filtered through the feature code during scanning, improving scanning efficiency.

[0019] Preferably, in a specific implementation of comparing the association between file names and target domain names in a given scenario: based on the generated domain name association feature file name and trusted fixed cache path, multi-dimensional association verification processing is performed on files in the cache directory to obtain a cache existence determination result; specifically, firstly, based on the trusted fixed cache path, a directory traversal algorithm is used to traverse all files under the path, extracting the complete file name of each file, and then the extracted file name is structurally split to obtain the split domain name fragment, function identifier fragment, and feature code fragment. Then, the split domain name fragment is completely matched with the standard string of the target domain name, and the feature code fragment is consistent with the domain name feature code corresponding to the target domain name. Only when both checks pass can the file be determined to be a cache file corresponding to the target domain name, and a cache existence confirmation result is generated; if no file that meets both check conditions is found after traversal, a cache non-existence confirmation result is generated. This multi-dimensional association verification mechanism avoids the misjudgment that may occur with traditional single file name matching and improves the accuracy of cache existence determination.

[0020] Optionally, if a cache existence result is obtained, an expiration check is performed on the cache file, extracting the cache expiration time from the cache file and comparing it with the current system time to obtain a cache not expired result or a cache expired result. This includes: reading the cache file corresponding to the cache existence result, extracting the metadata field in the file, which contains the cache generation time and the preset validity period; calculating the cache expiration time by using the cache generation time and the preset validity period; converting the cache expiration time and the current system time into a unified time format and comparing them. If the current system time does not exceed the cache expiration time, a cache not expired result is obtained; otherwise, a cache expired result is obtained.

[0021] Preferably, in one scenario, the specific implementation process of reading the cache file and extracting metadata fields is as follows: Based on the cache file corresponding to the cached result, the cache file is subjected to structured parsing and metadata verification processing to generate a trusted cache metadata set; specifically, a file segmentation parsing algorithm is used to divide the cache file into a data area and a metadata area, wherein the metadata area is stored at a fixed offset position at the beginning of the cache file. The cache generation time and the preset valid duration fields are located and extracted by using preset metadata field identifiers (such as the cache generation time identifier "CT" and the preset validity duration identifier "ET"); at the same time, a verification mechanism based on Message Authentication Code (MAC) is used to perform integrity verification on the extracted metadata fields. The metadata fields are encrypted with a preset key to generate a verification code, which is compared with the metadata verification code stored in the cache file. If the verification passes, it is confirmed that the metadata has not been tampered with, forming a trusted cache metadata set; if the verification fails, the cache file is determined to be invalid, and the Internet Protocol address re-acquisition process is directly triggered. This design avoids the risk of tampering caused by the lack of verification in traditional metadata extraction.

[0022] Preferably, in a specific implementation of calculating cache expiration time in a scenario: based on the cache generation time and preset validity period in the trusted cache metadata set, the validity period is dynamically adjusted in combination with the domain name access frequency to generate a dynamic cache expiration time; specifically, firstly, the cache generation time is converted into a standard timestamp format (such as a Unix timestamp), then the historical access records of the target domain name stored locally by the application are read, the access frequency per unit time is counted, and the preset validity period is dynamically adjusted according to the access frequency—when the access frequency is higher than a preset threshold, the preset validity period is shortened by a certain proportion (such as shortened to the original value). When the access frequency is lower than a preset threshold (half of the original access frequency), the preset validity period is extended by a certain proportion (e.g., doubled), forming a dynamic validity period. Finally, the dynamic cache expiration time is obtained by adding the cache generation timestamp and the dynamic validity period. For example, if the cache generation timestamp is 1690000000 and the dynamic validity period is 1800 seconds (30 minutes), then the dynamic cache expiration timestamp is 1690001800. This dynamic adjustment mechanism adapts the cache expiration time to the domain name access frequency, avoiding cache failure or redundancy problems caused by the traditional fixed validity period.

[0023] Preferably, in one scenario, the specific implementation of comparing the cache expiration time with the current system time is as follows: Based on the dynamic cache expiration time and the current system time, time format standardization and bidirectional comparison processing are performed to obtain the cache timeliness determination result; specifically, firstly, the dynamic cache expiration time and the current system time are uniformly converted into a standard timestamp format to eliminate comparison errors caused by different time formats; then, a bidirectional comparison is performed: on the one hand, the difference between the current system timestamp and the dynamic cache expiration timestamp is calculated; if the difference is less than or equal to zero, the cache is determined not to have expired; on the other hand, the cache is compared using the Network Time Protocol (NMT). The system uses rkTimeProtocol (NTP) to obtain the trusted network time. After converting the trusted network time into a standard timestamp, it compares it with the dynamic cache expiration timestamp. If the trusted network timestamp also does not exceed the dynamic cache expiration timestamp, the cache is further confirmed to be not expired, and a cache not expired confirmation result is generated. If either comparison result shows that the timestamp has exceeded the dynamic cache expiration timestamp, the cache is determined to have expired, and a cache expired confirmation result is generated. This two-way comparison mechanism combines local time and trusted network time, improving the accuracy of timeliness determination and avoiding misjudgments caused by local time tampering.

[0024] Optionally, if the cached result is not found or has expired, a network request is initiated directly using a preset trusted service interface Internet Protocol address. After signature verification and response parsing, invalid Internet Protocol addresses are removed to generate a list of Internet Protocol addresses corresponding to the target domain name. If the cached result is not expired, the list of Internet Protocol addresses corresponding to the target domain name is extracted directly from the cache file, including: extracting the preset trusted service interface Internet Protocol address from the local configuration file; concatenating the target domain name with the current timestamp and generating signature data using a hash encryption algorithm; encapsulating the target domain name, timestamp, and signature data into a network request data packet; directly initiating a network request to the trusted service interface Internet Protocol address, bypassing Domain Name System (DNS) resolution; receiving the response data returned by the trusted service; verifying the consistency between the server signature in the response data and the locally generated signature data; after successful parsing, extracting the list of Internet Protocol addresses; removing invalid Internet Protocol addresses to generate a list of Internet Protocol addresses corresponding to the target domain name.

[0025] Preferably, in one scenario, the specific implementation process for extracting the Internet Protocol address of a trusted service interface and generating signature data is as follows: Based on the local configuration file, the target domain name, and the current timestamp, the trusted service interface address is subjected to multi-source verification and layered signature data generation processing to generate a set of trusted service interface addresses and layered signature data; specifically, the preset trusted service interface Internet Protocol address is extracted from different storage nodes of the local configuration file (such as the primary configuration node and the backup configuration node), and network connectivity detection (such as sending test data packets and receiving responses) and address validity verification (such as verifying whether it conforms to the Internet Protocol address format) are performed. The system standardizes and filters out available addresses to form a set of trusted service interface addresses. Simultaneously, it standardizes the target domain name (e.g., removing special characters and unifying case) to obtain a standard domain name string. This string is then combined with the current timestamp (accurate to milliseconds) to generate a basic information string. A layered hash encryption mechanism is employed. The first layer uses the SHA-256 algorithm to encrypt the basic information string, generating a primary signature. The second layer, based on the primary signature and a preset unique device identifier (e.g., the device hardware serial number hash value), further encrypts the string to generate a secondary signature, forming layered signature data. This layered signature design enhances the signature's resistance to tampering and provides higher security compared to a single encryption method.

[0026] Preferably, in the specific technical implementation of encapsulating network request data packets and initiating requests: based on a set of trusted service interface addresses, the target domain name, timestamp, and hierarchical signature data, the network request is dynamically routed and securely encapsulated to generate a secure routed network request packet and initiate access; specifically, a load balancing algorithm (such as a weighted round-robin algorithm based on address response speed) is used to select the optimal access address from the set of trusted service interface addresses; subsequently, according to a preset request protocol format (such as HTTP / HTTPS), the target domain name, timestamp, hierarchical signature data, and device identification information are encapsulated into structured request data, and the request header is encrypted (such as using a symmetric encryption algorithm to encrypt key fields) to generate a secure routed network request packet; finally, the network request is directly initiated based on the optimal access address, without going through the domain name system resolution stage. Dynamic routing improves the request success rate, and secure encapsulation prevents the request data from being stolen or tampered with during transmission.

[0027] Preferably, in one scenario, the specific implementation of receiving response data and generating an Internet Protocol address list in the step is as follows: Based on the received response data, signature verification, format parsing, and intelligent removal of invalid addresses are performed to generate a list of valid Internet Protocol addresses corresponding to the target domain name; specifically, firstly, the server signature (including the primary and secondary signatures generated by the server) is extracted from the response data, and consistency verification is performed with the locally generated hierarchical signature data. At the same time, the timeliness of the response data is ensured by timestamp verification (e.g., the difference between the server timestamp and the local timestamp does not exceed a preset range). If the double verification passes, the response data is confirmed to be trustworthy; then, the Internet Protocol address field in the response data is parsed using a structured parsing algorithm, and all Internet Protocol addresses are extracted to form the original addresses. Finally, a multi-dimensional invalid address removal mechanism is used. First, the address format is verified (e.g., addresses that do not conform to Internet Protocol version 4 or 6). Second, unreachable addresses are removed through Ping tests or port connectivity checks (e.g., attempting to connect to common ports of the target address). Third, duplicate invalid addresses are removed by comparing with a historical invalid address database (which stores addresses previously deemed invalid). This process ultimately yields a list of valid Internet Protocol addresses corresponding to the target domain. If the cached result is not expired, the Internet Protocol address field in the cache file is directly read. After processing by the multi-dimensional invalid address removal mechanism, a list of valid Internet Protocol addresses corresponding to the target domain is generated. This mechanism ensures the availability of the address list and avoids the problem of invalid address residue caused by relying solely on format verification in traditional methods.

[0028] Optionally, a time-sensitive client-side local DNS resolution cache Internet Protocol address set is generated based on the list of Internet Protocol addresses corresponding to the target domain name. This set is persistently stored in the local DNS resolution cache and refreshed periodically using a dual-judgment mechanism of existence and timeliness. This includes: supplementing the list of Internet Protocol addresses corresponding to the target domain name with information such as resolution time, cache generation time, cache expiration time, and whether it is a preset domain name identifier (specific player domain name identifier) ​​to generate a time-sensitive client-side local DNS resolution cache Internet Protocol address set; serializing the time-sensitive client-side local DNS resolution cache Internet Protocol address set into a specified format data and writing it to a local cache file for persistent storage; and starting an independent cache refresh thread to trigger the cache check and update process according to a preset period, re-obtaining the latest Internet Protocol address list through the dual-judgment mechanism of existence and timeliness to update the local DNS resolution cache.

[0029] Optionally, based on the list of Internet Protocol addresses corresponding to the target domain name, information such as resolution time, cache generation time, cache expiration time, and whether it is a preset domain name identifier (specific player domain name identifier) ​​is supplemented to generate a time-sensitive client-side local domain name resolution cache Internet Protocol address set. This includes: extracting all Internet Protocol addresses from the list of Internet Protocol addresses corresponding to the target domain name; recording the current system time as the resolution time and cache generation time, and calculating the cache expiration time based on a preset valid duration; determining whether the target domain name is a domain name corresponding to a specific player, generating a "whether it is a specific player domain name identifier"; and associating and integrating the Internet Protocol address list, resolution time, cache generation time, cache expiration time, and "whether it is a specific player domain name identifier" to generate a time-sensitive client-side local domain name resolution cache Internet Protocol address set.

[0030] Preferably, in one scenario, the specific implementation process of extracting the Internet Protocol address corresponding to the target domain name and performing quality classification is as follows: Connectivity verification and quality scoring are performed on the addresses in the list of valid Internet Protocol addresses corresponding to the target domain name to generate a hierarchical set of Internet Protocol addresses. Specifically, a concurrent connectivity detection mechanism is used to send a preset number of test requests (such as TCP handshake requests) to each address in the list of valid Internet Protocol addresses, recording parameters such as response latency and packet loss rate. Based on a preset quality scoring model, response latency and packet loss rate are converted into quantitative scores (e.g., the shorter the response latency and the lower the packet loss rate, the higher the score). Addresses are divided into three levels—high priority, medium priority, and low priority—according to their scores. Each level is associated with corresponding quality parameters to form a hierarchical set of Internet Protocol addresses. For example, a high-priority address must have a response latency lower than a preset threshold (e.g., 50 milliseconds) and a packet loss rate of zero. This hierarchical design facilitates the priority selection of high-quality addresses during subsequent accesses, improving access efficiency.

[0031] Preferably, in a specific technical implementation of recording time information and dynamically calibrating cache expiration time in a scenario: based on the current system time and a preset valid duration, combined with the quality level of the hierarchical Internet Protocol address set, the expiration parameters are calibrated to generate an accurate set of expiration parameters; specifically, the current system time and the trusted network time (obtained via the Network Time Protocol) are synchronously acquired, and the time difference between the two is calculated. If the difference is within a preset allowable range (e.g., 10 seconds), the current system time is used as the parsing time and cache generation time; if the difference exceeds the range, the trusted network time is used as the reference time, and the cache is adjusted accordingly. The current system time is used as the resolution time and cache generation time. Subsequently, the preset validity period is dynamically adjusted according to the proportion of high-priority addresses in the hierarchical Internet Protocol address set. When the proportion of high-priority addresses is higher than the preset proportion, the preset validity period is extended; when the proportion is lower than the preset proportion, the preset validity period is shortened. The calibrated cache generation time is added to the adjusted validity period to obtain the accurate cache expiration time, forming a precise set of timeliness parameters that includes resolution time, cache generation time, and accurate cache expiration time. This dynamic calibration mechanism adapts the timeliness parameters to address quality and improves the effective utilization rate of the cache.

[0032] Preferably, in a specific implementation of identifying the target domain name type and integrating multi-dimensional information in a scenario: based on the target domain name's features and a set of accurate timeliness parameters, and a hierarchical set of Internet Protocol addresses, intelligent identification of the domain name type and structured information integration processing are performed to generate a time-sensitive set of Internet Protocol addresses for client-side local domain name resolution caching; specifically, a domain name type feature library is constructed, which contains feature fields of specific player domain names (such as key fields like "player" and "video"), domain name suffix rules, etc. A string matching algorithm (such as the KMP algorithm) is used to compare the target domain name with the features in the feature library. If a match is successful, a "is a special" result is generated. A "specific player domain name" identifier is generated; otherwise, a "non-specific player domain name" identifier is generated. Subsequently, a structured data model is designed, which includes address hierarchy fields, timeliness parameter fields, and domain name type identifier fields. The address and level information in the hierarchical Internet Protocol address set, the resolution time, cache generation time, and precise cache expiration time in the precise timeliness parameter set, and the domain name type identifier are mapped one by one according to the model fields. The data is then converted into structured data in a unified format through a serialization algorithm, forming a time-sensitive client-side local domain name resolution cache Internet Protocol address set. This structured integration ensures the standardization and integrity of the set data, facilitating subsequent cache storage and fast retrieval.

[0033] Optionally, the time-sensitive client-side local domain name resolution cache Internet Protocol address set is serialized into data of a specified format and written to a local cache file for persistent storage. This includes: using a serialization algorithm to convert the time-sensitive client-side local domain name resolution cache Internet Protocol address set into string data of a specified format; creating or overwriting a cache file with the target domain name as the unique identifier in a preset local cache storage directory; and writing the serialized string data to the created or overwritten cache file to complete persistent storage.

[0034] Preferably, in one scenario, the specific implementation process of multi-format adaptive serialization of a time-sensitive client-side local domain name resolution cache Internet Protocol address set is as follows: Based on the structured characteristics of the time-sensitive client-side local domain name resolution cache Internet Protocol address set, an adaptive serialization algorithm is used for format conversion and data encryption to generate an encrypted serialized data string. Specifically, the structured data types of the set (such as nested dictionaries, lists, etc.) are first parsed, and the serialization format is adaptively selected according to the data complexity (compact binary format is used for simple structures, and extensible markup language format is used for complex structures) to ensure the compatibility and compactness of the serialized data. Subsequently, a hybrid encryption mechanism is used to process the serialized original data—the data encryption key is encrypted using an asymmetric encryption algorithm (such as the RSA algorithm), and then the original serialized data is encrypted using the same symmetric encryption key (such as the AES algorithm). At the same time, a checksum generated based on the data content (such as a CRC32 checksum) is added to the end of the data to form an encrypted serialized data string. This design not only ensures the security of data storage but also improves the serialization efficiency through format adaptation, avoiding compatibility or redundancy problems caused by traditional single-format serialization.

[0035] Preferably, in the specific technical implementation of creating or overwriting the cache file corresponding to the target domain name and performing security verification: based on the trusted fixed cache path and the target domain name associated feature file name, the cache file is processed for path verification, file creation, and permission configuration to generate a secure cache storage file; specifically, firstly, the read and write permissions of the trusted fixed cache path and the remaining space of the storage medium are verified to ensure that the file writing requirements are met (the remaining space is not less than a preset multiple of the estimated file size, such as 3 times); if the file corresponding to the target domain name associated feature file name already exists, the file locking mechanism is first used to prevent other processes from accessing the file, and then the file integrity is verified (the file size is compared with the checksum), and after confirming the file status, overwriting preparation is performed; if the file does not exist, a new file is created according to the preset file permission configuration (such as only the current application can read and write); after the creation or overwriting preparation is completed, a secure cache storage file is generated. This process avoids file corruption caused by abnormal storage environment or concurrent access through path verification and file locking.

[0036] Preferably, in a specific implementation of writing encrypted serialized data strings to a secure cache storage file and ensuring their integrity in a given scenario: based on the encrypted serialized data strings and the secure cache storage file, an incremental writing and dual verification mechanism is used for data writing and integrity confirmation to complete persistent storage; specifically, firstly, an incremental writing algorithm is used to divide the encrypted serialized data strings into fixed-size data packets (e.g., each packet is a preset number of bytes), which are then written sequentially to the secure cache storage file, while simultaneously recording the offset and verification information of each data packet; during the writing process, the writing status is monitored in real time, and if a writing interruption occurs (e.g., due to storage medium abnormality), the process is restarted next time. In real-time, breakpoint resume is performed based on offset and verification information to avoid duplicate writing or data loss. After writing, a dual integrity check is performed: first, the checksum of the entire file is calculated and compared with the original checksum of the encrypted serialized data string; second, the file content is read, decrypted, and deserialized to verify the consistency between the deserialized data and the original time-sensitive client local domain name resolution cache Internet Protocol address set. If the dual check passes, the persistent storage is confirmed to be complete; otherwise, the rewrite process is triggered. This incremental writing and dual check mechanism improves the reliability of writing and avoids the data loss or tampering problems caused by traditional one-time writing.

[0037] Optionally, a separate cache refresh thread is started to trigger a cache check and update process according to a preset period. The latest Internet Protocol address list is re-obtained through a dual judgment mechanism of existence and timeliness to update the local domain name resolution cache. This includes: setting a preset cache refresh period, starting a separate cache refresh thread, and triggering the cache processing process according to the preset period; performing a dual judgment mechanism of existence and timeliness on the local cache file to obtain a valid cache result or an invalid cache result; if an invalid cache result is obtained, the Internet Protocol address acquisition process is re-executed to update the Internet Protocol address list corresponding to the newly generated target domain name to the local domain name resolution cache.

[0038] Preferably, in one scenario, the specific implementation process of setting a dynamic cache refresh cycle and starting an independent refresh thread is as follows: Based on the historical access frequency and Internet Protocol address change records of the target domain name, the cache refresh cycle is dynamically calibrated and thread-safely started to generate an intelligent refresh thread; specifically, historical access data of the target domain name is collected, the number of accesses and access time distribution per unit time are statistically analyzed, and the historical Internet Protocol address change frequency (such as the number of address updates per unit time) is analyzed. A cycle calibration model is constructed, and the access frequency and address change frequency are converted into quantitative weights. The initial preset cycle is dynamically adjusted—when both the access frequency and change frequency are higher than the preset threshold, the refresh cycle is shortened (such as shortened to two-thirds of the initial cycle); when both are lower than the preset threshold, the refresh cycle is extended (such as extended to 1.5 times the initial cycle), thus generating a dynamic refresh cycle; subsequently, an independent cache refresh thread is started, the thread priority (lower than the business thread priority) and resource consumption threshold (such as CPU consumption not exceeding a preset ratio) are configured, and thread safety is ensured through a thread lock mechanism to avoid conflicts with other cache operation threads, thus generating an intelligent refresh thread. This dynamic cycle design makes the refresh frequency adaptable to the actual use scenario and is more resource-efficient than a fixed cycle.

[0039] Preferably, in the specific technical implementation of the three-dimensional validity judgment of the local cache file: based on the local cache file, trusted network time, and Internet Protocol address connectivity, the cache is processed for existence, timeliness, and availability in a three-dimensional judgment to generate a comprehensive cache validity result; specifically, firstly, the existence judgment is performed, scanning whether there is a cache file corresponding to the target domain name under the trusted fixed cache path, and obtaining the existence or non-existence result; if it exists, the timeliness judgment is performed, extracting the precise cache expiration time in the cache file and comparing it with the trusted network time to obtain the result of not expired or expired; if it has not expired, the availability judgment is further performed, extracting the hierarchical Internet Protocol address set in the cache file, and performing sampling connectivity detection on high-priority addresses (the sampling ratio is a preset ratio). If the connectivity rate of the sampled addresses is higher than a preset threshold (such as 80%), it is judged as available; otherwise, it is judged as unavailable; combining the three-dimensional judgment results, only when the existence, not expired, and availability are simultaneously satisfied, a cache validity result is generated; otherwise, a cache invalid result is generated. This three-dimensional judgment mechanism avoids the invalid address caching problem caused by the traditional reliance on only existence and timeliness judgment.

[0040] Preferably, in one scenario, the specific implementation of cache update and conflict resolution based on the comprehensive cache validity result is as follows: Based on the comprehensive cache validity result and the intelligent refresh thread, incremental update and refresh conflict resolution are performed on the local domain name resolution cache to complete the cache optimization update; specifically, if an invalid cache result is obtained, the intelligent refresh thread triggers the Internet Protocol address re-acquisition process to obtain the latest list of valid Internet Protocol addresses corresponding to the target domain name, and generates a new set of Internet Protocol addresses for the client's local domain name resolution cache with time expiration; then, an incremental update algorithm is used to compare the new set with the address set in the original cache file, only replacing the changed addresses and time expiration parameters, retaining the unchanged content, and reducing the amount of data written; if the cache file is detected to be occupied by a business thread during the update process (i.e., refresh conflict), the conflict resolution mechanism is started, the update task is added to the priority queue, and after the business thread releases the occupation, the update is executed in the queue order, while recording the conflict log and update result; if a valid cache result is obtained, the intelligent refresh thread only updates the last check timestamp in the cache file, without needing to re-acquire the address, and completes the cache optimization update. This incremental update and conflict resolution design improves update efficiency and avoids cache corruption caused by data write conflicts.

[0041] Optionally, based on a time-sensitive client-side local DNS resolution cached Internet Protocol (IP) address set, the primary domain name, backup domain name, and locally cached IP address associated with the target domain name are obtained, and multi-network enabling and priority IP address access configuration are performed to generate a domain name-priority progressive failover access strategy. This includes: extracting the locally cached IP address from the time-sensitive client-side local DNS resolution cached IP address set; obtaining the primary domain name and backup domain name corresponding to the target domain name from the preset domain name association configuration; reading the client's network configuration parameters to determine whether multi-network functionality is enabled; if enabled, detecting the currently available network types and locking the priority network according to rules; reading the client's access priority configuration to determine whether to prioritize IP address access; and combining the primary domain name, backup domain name, locally cached IP address, and network configuration results to generate a domain name-priority progressive failover access strategy. Optionally, the process involves extracting local cached Internet Protocol (IP) addresses from a time-sensitive client-side local DNS resolution cache set, and obtaining the primary and backup domain names corresponding to the target domain name from a preset domain name association configuration. This includes: resolving the time-sensitive client-side local DNS resolution cache set and extracting the list of IP addresses from it as local cached IP addresses; accessing a preset domain name association configuration file, which stores the mapping relationship between each domain name and the primary and backup domain names; and querying the mapping relationship based on the target domain name to extract the corresponding primary and backup domain names.

[0042] Optionally, the client's network configuration parameters are read to determine whether the multi-network function is enabled. If enabled, the currently available network types are detected and prioritized according to rules. This includes: reading the client's network configuration parameters and extracting the multi-network enable identifier; if the multi-network enable identifier is enabled, detecting the currently available network types on the client and obtaining parameters such as connection status, bandwidth, latency, and packet loss rate for each network type; sorting the available network types according to a preset network priority sorting rule and locking the network at the top of the sort as the priority network.

[0043] Preferably, in one scenario, the specific implementation process of parsing and filtering the set of Internet Protocol (IP) addresses with time-sensitive client-side local DNS resolution cache is as follows: The set of IP addresses with time-sensitive client-side local DNS resolution cache undergoes structured parsing and priority filtering to generate a preferred list of local cached IP addresses. Specifically, a hierarchical parsing algorithm is used to first decrypt and deserialize the serialized data of the set, restoring core information such as the address hierarchy field and time-sensitive parameter field in the structured data model. Then, based on the priority identifier in the address hierarchy field, high-priority and medium-priority IP addresses are extracted. Simultaneously, combined with the precise cache expiration time in the time-sensitive parameter field, addresses nearing expiration (remaining valid time less than a preset duration) are removed. Finally, the filtered addresses are sorted by response latency from smallest to largest to generate a preferred list of local cached IP addresses. For example, high-priority addresses with response latency below a preset threshold and sufficient remaining valid time are prioritized. This filtering and sorting design ensures that high-quality addresses with sufficient validity are used preferentially during subsequent accesses, improving the access success rate.

[0044] Preferably, in the specific technical implementation of accessing and performing security verification of the preset domain name association configuration file: based on the preset configuration file path and the domain name association configuration file, the configuration file is subjected to integrity verification and permission verification to generate trusted domain name association configuration data; specifically, the domain name association configuration file is accessed according to the preset path. The file is stored in an encrypted format (such as encryption based on a symmetric encryption algorithm). First, the file is decrypted using a preset key; then, a file integrity verification algorithm (such as comparison of hash values ​​based on file content) is used to verify whether the file has been tampered with, and at the same time, it is checked whether the file's access permissions meet the preset requirements (only the current application can read it); after the verification is passed, the file content is parsed to restore the mapping relationship data between each domain name and the main domain name and the backup domain name, and trusted domain name association configuration data is generated. This security verification mechanism avoids domain name data errors caused by configuration file tampering or unauthorized access.

[0045] Preferably, in a scenario, when querying the mapping relationship based on the target domain name and extracting the primary and backup domain names: based on the configuration data associated with the target domain name and the trusted domain name, a multi-pattern matching algorithm is used to query the mapping relationship and verify the validity of the domain name to generate a trusted primary and backup domain name combination corresponding to the target domain name; specifically, the target domain name is standardized (e.g., case-sensitive matching, removal of redundant characters) to obtain a standard target domain name; then, an improved multi-pattern matching algorithm (e.g., an optimized algorithm based on the AC automaton) is used to quickly query the primary and backup domain names corresponding to the standard target domain name in the mapping relationship of the trusted domain name associated configuration data; after the query is completed, the extracted primary and backup domain names are format-validated (verified to conform to the domain name format specification) and connectivity pre-detected (a DNS query request is sent to verify the reachability of the domain name), and domain names with incorrect format or unreachable are eliminated; if there are multiple backup domain names, they are sorted according to a preset weight (e.g., historical access success rate), and finally a trusted primary and backup domain name combination containing the primary domain name and ordered backup domain names is generated. This multi-pattern matching and validity verification design improves the domain name query efficiency and data reliability, and avoids the slow query or invalid domain name problems caused by the traditional single matching method.

[0046] Optionally, the client's access priority configuration is read to determine whether to prioritize access via Internet Protocol (IP) addresses. This is combined with the primary domain name, backup domain name, locally cached IP addresses, and network configuration results to generate a domain-priority progressive failover access strategy. This includes: reading the client's access priority configuration and extracting the priority IP address access identifier; if the priority IP address access identifier is not prioritized, constructing a progressive process of "primary domain name access → backup domain name access → locally cached IP address access"; and integrating the progressive process with the network configuration, combined with the locked priority network or the currently active network, to generate a domain-priority progressive failover access strategy.

[0047] Preferably, in one scenario, the specific implementation process of reading the client access priority configuration and parsing the identifier is as follows: The client's access priority configuration file is encrypted and parsed, and the identifier validity is verified to generate a trusted access priority identifier. Specifically, the client's access priority configuration file is stored in an encrypted form. The configuration file is decrypted using a preset decryption key to restore the core configuration fields in the configuration file, which include the priority Internet Protocol address access identifier field (such as "IP_PRIORITY"). Then, the validity of this identifier field is verified. The verification includes the identifier format (such as whether it is a preset "yes" or "no" string or corresponding encoded value) and the identifier's legality (such as whether it is within a preset legal value range). If the verification passes, the identifier is extracted as a trusted access priority identifier; if the verification fails, the "non-priority Internet Protocol address access" identifier is used by default. This encryption and parsing mechanism avoids priority configuration errors caused by tampering or illegal modification of the configuration file.

[0048] Preferably, in the specific technical implementation of constructing a domain-priority progressive access process: a dynamic progressive access process model is constructed based on a trusted access priority identifier, a trusted primary and backup domain name combination, and a preferred local cached Internet Protocol address list. Specifically, if the trusted access priority identifier is in a non-priority state, the process model is constructed with the logic of "primary domain name access as the core, backup domain name access as redundancy, and local cached Internet Protocol address access as a fallback." First, the primary domain name in the trusted primary and backup domain name combination is assigned the highest access priority, the backup domain names are assigned secondary priorities according to preset weights (such as historical access success rates), and the addresses in the preferred local cached Internet Protocol address list are assigned fallback priorities according to priority. Subsequently, access failure judgment conditions (such as response timeout, response status code failure code, connection interruption) and switching triggering mechanisms (if any failure judgment condition is met, the next level of access is triggered) are set in the process model to generate a dynamic progressive access process model. This model can dynamically adjust the switching logic according to the subsequent network status and address validity, making it more adaptable than a fixed process.

[0049] Preferably, in a scenario, when integrating the dynamic progressive access process model with the specific implementation of network configuration: based on the dynamic progressive access process model and network configuration results (including locked priority networks or currently active networks), network adaptation and policy pre-verification processing are performed to generate a domain-priority progressive failover access strategy; specifically, firstly, the network type (such as mobile data network, wireless network), network bandwidth, latency, and other parameters in the network configuration results are analyzed to match the optimal network transmission parameters (such as adjusting the request timeout time according to network bandwidth, bandwidth...) for each access stage in the dynamic progressive access process model (primary domain name access, backup domain name access, local cached Internet Protocol address access). If the timeout is too low, the timeout period should be extended appropriately. Then, the integrated strategy is pre-validated to simulate different access failure scenarios (such as timeout of access to the main domain name and failure of the backup domain name response) to verify whether the strategy can correctly trigger the switching logic. At the same time, the compatibility of network parameters and access methods is checked (such as ensuring that the local cached Internet Protocol address access supports direct access in the current network environment). If the pre-validation passes, the final domain name-first progressive failover access strategy is generated. If the pre-validation finds problems, the network parameters or access process order are adjusted and re-validated until the strategy meets the execution requirements. This integration and pre-validation design ensures the feasibility and execution efficiency of the strategy and avoids switching failures caused by improper network adaptation.

[0050] Optionally, based on the access strategy, when both the primary domain name and the backup domain name access fail, the system switches to the locally cached Internet Protocol address to initiate access to the target resource server, thereby enabling network service access in the scenario of DNS hijacking. This includes: a progressive failover access strategy based on domain name priority, using the primary domain name to initiate access in the priority network or the currently active network, and monitoring the access response results; if the primary domain name access fails, switching to the backup domain name to initiate access, and monitoring the backup domain name access response results; if the backup domain name access fails, selecting an Internet Protocol address from the time-sensitive client local DNS resolution cache Internet Protocol address set, replacing the domain name, and initiating access, thereby enabling network service access in the scenario of DNS hijacking. Optionally, based on a domain-priority progressive failover access strategy, the main domain name is used to initiate access in a priority network or the currently active network, and the access response results are monitored, including: based on the domain-priority progressive failover access strategy, obtaining the main domain name and the corresponding priority network or currently active network information; using the main domain name as the access target, constructing a network access link, and initiating access in the corresponding network; monitoring the connection status and response status code during the access process to determine whether the main domain name access is successful.

[0051] Preferably, in one scenario, the specific implementation process of extracting the main domain name and corresponding network information and performing parameter adaptation is as follows: Based on the domain name-first progressive failover access strategy, parameter parsing and adaptive configuration processing are performed on the main domain name and corresponding network information to generate a main domain name access configuration set; specifically, the main domain name in the trusted primary and backup domain name combination is parsed from the domain name-first progressive failover access strategy, and the corresponding network information (locked priority network or currently active network) is extracted, including core parameters such as network type (mobile data network, wireless network, wired network), network bandwidth, latency threshold, and packet loss rate limit; subsequently, according to the service type (such as HTTP service, HTTPS service, streaming media service) corresponding to the main domain name and Network type and adaptive configuration of access parameters—For HTTPS services, enable certificate verification optimization (such as preloading commonly used root certificates to shorten verification time); for streaming media services, adjust the request data packet size (such as dynamically adjusting the data packet size to a preset range based on network bandwidth); at the same time, set the access timeout time based on the network latency threshold. If the network latency is low, set a shorter timeout time (such as 0.8 times the preset base timeout time); if the network latency is high, extend it appropriately (such as 1.2 times the preset base timeout time). Integrate the main domain name, adapted access parameters, and network information to generate a main domain name access configuration set. This adaptive configuration mechanism ensures that the access parameters are highly matched with the main domain name service type and network status, improving the initial access success rate.

[0052] Preferably, in the specific technical implementation of constructing and optimizing network access links: based on the main domain name access configuration set, the network access links are constructed in layers and the link quality is pre-optimized to generate efficient main domain name access links; specifically, firstly, according to the network information in the main domain name access configuration set, the corresponding network interface (such as Wi-Fi interface for wireless network and cellular network interface for mobile data) is selected, and network connection parameters (such as TCP window size and maximum transmission unit value) are initialized; subsequently, the link quality pre-optimization operation is performed by sending a preset number of test data packets (such as 3-5) to detect the actual transmission quality of the current network link, including indicators such as real-time latency, packet loss rate, and link stability, based on the detection results. Dynamically adjust transmission parameters—if the detected link packet loss rate is higher than the preset threshold, activate the link retransmission optimization mechanism (such as adjusting the retransmission timeout time and enabling selective retransmission algorithms). If the latency fluctuation is large, activate the flow control algorithm (such as dynamically adjusting the sending rate based on the congestion window). At the same time, construct a layered access link structure, divided into transport layer links (responsible for establishing data transmission channels) and application layer links (responsible for service request encapsulation and response parsing). After the transport layer link is established, connectivity verification is performed to ensure that the link is smooth before initiating the application layer request, generating an efficient main domain name access link. This link pre-optimization and layered construction design effectively reduces the false judgment of access failure caused by network link quality problems, while improving the transmission efficiency of main domain name access.

[0053] Preferably, in a scenario, the specific implementation of initiating main domain access and performing multi-dimensional real-time monitoring is as follows: Based on the efficient main domain access link and the main domain access configuration set, the main domain access is initiated and full-link multi-dimensional monitoring processing is performed to generate real-time monitoring data for the main domain access; specifically, based on the efficient main domain access link, the application layer request data (such as carrying request parameters, request header information, and adapted timeout parameters) in the main domain access configuration set is encapsulated, and an access request is initiated to the target server corresponding to the main domain; after the access is initiated, the full-link multi-dimensional monitoring thread is started, which executes in parallel with the access thread, and collects four types of core monitoring data in real time: first, link layer monitoring data, including the number of bytes sent and received by the network interface, and the number of error frames, used to determine whether there are physical layer anomalies in the link transmission; second, transport layer monitoring data, including TCP connection... The monitoring data includes four types: 1) Connection status (establishment, transmission, closure), retransmission count, and congestion window changes, used to identify problems such as packet loss and congestion at the transport layer; 2) Application layer monitoring data, including request completion time, response start time, and response data integrity identifier, used to determine whether application layer requests are processed normally; and 3) Domain name resolution implicit monitoring data, which compares the actual Internet Protocol address after the main domain name is resolved with a historical normal resolution address database. If the resolved address differs significantly from the historical normal address (e.g., no overlap and not within a preset trusted address range), it is marked as a suspected domain name hijacking identifier. These four types of monitoring data are linked and integrated by timestamp to generate real-time monitoring data for main domain name access. This multi-dimensional monitoring design breaks through the limitations of traditional methods that only monitor response status codes, and can comprehensively capture various anomalies during the access process, especially the abnormal resolution address caused by domain name hijacking.

[0054] Preferably, the specific implementation process of intelligent access result determination based on monitoring data is as follows: Based on the real-time monitoring data of the main domain access and the main domain access configuration set, the access result is subjected to multi-dimensional verification and intelligent failure determination processing to generate the main domain access result determination; Specifically, firstly, the application layer response status code in the real-time monitoring data of the main domain access is extracted. If the status code belongs to the preset success status code set (such as the 200 series status codes) and the response data integrity identifier is "complete", then it is initially determined that the access is successful; Subsequently, it is verified whether the number of retransmissions in the transmission layer monitoring data is lower than the preset threshold and whether the number of link layer error frames is zero. If both are satisfied, the access is further confirmed as successful, and the main domain access success result is generated; If the response status code belongs to the preset failure status code set (such as 403 and 404 in the 4xx series, and 500 and 502 in the 5xx series), then deep failure analysis is initiated: If a suspected domain hijacking identifier is detected, it is directly determined as a domain-related access failure; if no detection is found... If a suspected domain hijacking flag is detected, the system analyzes whether the number of retransmissions at the transport layer exceeds a threshold (such as a preset retransmission limit). If it does, the network link is considered to have failed. If the number of retransmissions is normal but the response times out (the current time exceeds the access timeout time in the main domain access configuration set), the system combines the link layer monitoring data to determine whether the network interface is normal. If the network interface is abnormal, it is considered to have failed; if the network interface is normal, it is considered to have failed due to no response from the server. If the response data integrity flag is "incomplete," it is considered to have failed in data transmission. All failure scenarios generate a main domain access failure result and associate the failure type with the record (suspected domain hijacking, network link failure, network interface failure, no response from the server, data transmission failure). This multi-dimensional verification and intelligent failure judgment mechanism can accurately distinguish access failures caused by different reasons, especially quickly identifying domain hijacking scenarios. It provides accurate basis for switching to backup domain access or local cached Internet Protocol address access, avoiding invalid retries or erroneous switching.

[0055] Preferably, in the specific technical implementation of log retention and anomaly early warning for monitoring data and judgment results: based on the real-time monitoring data and judgment results of the main domain access, structured log storage and intelligent anomaly early warning processing are performed to generate a main domain access record archive; specifically, various monitoring indicators, core parameters of the main domain access configuration set, main domain access result judgment and failure type (if failure) in the real-time monitoring data of the main domain access are structurally integrated in timestamp order, and stored in the local access log directory using an encrypted format (such as encryption based on a symmetric encryption algorithm). The log file name includes the main domain, access initiation timestamp, and result identifier, which is convenient for subsequent problem tracing; at the same time, if the main domain access result is judged as failure and the failure type is "domain hijacking suspected". If a suspected hijacking occurs, a lightweight local alert mechanism is triggered (e.g., recording the alert flag in the application log without actively popping up a pop-up to disturb the user). Suspected hijacking-related data (abnormal Internet Protocol addresses resolved, monitoring timestamps, and main domain names) is cached in a dedicated abnormal data directory to provide data support for subsequent system upgrades or security analysis. If the failure type is another network-related failure, the failure frequency is recorded. When the frequency of network-related failures for the same main domain name exceeds a preset threshold within a unit of time, a network status self-check mechanism is triggered (e.g., re-detecting network interfaces and re-acquiring network parameters). This log retention and abnormal alert design ensures the traceability of the access process and provides data support for subsequent analysis of domain hijacking and network status optimization, further enhancing the robustness of the overall solution. Optionally, if access to the primary domain fails, the system switches to the backup domain to initiate access and monitors the response of the backup domain access. This includes: if access to the primary domain fails, storing the primary domain and access parameters in a retry queue and marking the queue status type; obtaining the backup domain and its corresponding network information based on a domain-priority progressive failover access strategy; constructing a network access link with the backup domain as the access target, initiating access in the corresponding network, and monitoring the response of the backup domain access.

[0056] Preferably, the specific implementation process of storing and marking the retry queue of the main domain name and access parameters is as follows: Based on the main domain name access failure results and the main domain name access configuration set, the retry queue is structured and intelligently marked to generate an ordered retry queue; specifically, a multi-level retry queue structure is first constructed, which is divided into a basic information layer (storing the main domain name, access failure type, failure timestamp), a parameter layer (storing the adapted access parameters and network information in the main domain name access configuration set), and a status layer (storing the queue status type and retry priority); the failure type (such as suspected domain name hijacking, network link failure, etc.) in the main domain name access failure results and the complete parameter information in the main domain name access configuration set are stored in a structured manner. The retry queue is stored hierarchically. Then, a smart status marking operation is performed, assigning queue status types based on the main domain access failure type—if the failure type is "suspected domain hijacking," the queue status type is marked as a domain abnormal status identifier; if it's another network-related failure type, it's marked as a network abnormal status identifier. Simultaneously, retry priorities are set based on the failure timestamp and service urgency. High-urgency services (such as real-time resource requests for online teaching) are assigned high retry priorities, while low-urgency services are assigned normal priorities, generating an ordered retry queue. This multi-level storage and smart marking design ensures the integrity of retry data and provides accurate data for subsequent queue scheduling and secondary retries, avoiding resource waste caused by disordered retries.

[0057] Preferably, in the specific technical implementation of acquiring and dynamically sorting backup domain names and corresponding network information: based on the domain-priority progressive failover access strategy and the main domain name access failure type, backup domain names are intelligently filtered and dynamically prioritized to generate an optimal backup domain name access set; specifically, all backup domain names in the trusted main and backup domain name combination are extracted from the domain-priority progressive failover access strategy, and intelligent filtering is performed in combination with the main domain name access failure type—if the main domain name failure type is "suspected domain hijacking", then backup domain names with different domain segments from the main domain name are retained first (e.g., if the main domain name is "a.example.com", then cross-segment domain names such as "b.service.com" are retained first), reducing the risk of backup domain names failing simultaneously due to full-domain hijacking; if it is a network-related failure type, then all backup domain names are retained. Subsequently, the priority of backup domain names is dynamically adjusted, and a multi-dimensional ranking model is constructed. The ranking indicators include historical access success rate (the percentage of successful visits within a recent preset period), average response latency (the average access latency within a recent preset period), and compatibility with the current network (calculated based on the matching degree of the network type and the server network line corresponding to the backup domain name). The weights of each indicator are assigned using the analytic hierarchy process (AHP), and the comprehensive priority score of each backup domain name is calculated and ranked from high to low. At the same time, the optimal network information corresponding to each backup domain name (such as the network type with the highest historical access success rate and the compatible network parameters) is extracted and integrated with the ranked backup domain names to generate the optimal backup domain name access set. This intelligent filtering and dynamic ranking mechanism makes the access order of backup domain names highly compatible with failure scenarios and historical performance, thereby improving the success rate of the first access of backup domain names.

[0058] Preferably, in one scenario, the specific implementation of constructing and optimizing the backup domain name access link is as follows: Based on the network information in the optimal backup domain name access set and the ordered retry queue, the backup domain name access link is constructed and adaptively optimized to generate an adapted backup domain name access link; specifically, the backup domain name with the highest overall priority is selected from the optimal backup domain name access set, its corresponding optimal network information is extracted, and combined with the network status when the main domain name access fails (such as whether the original network is still available), the adapted network interface is selected; if the main domain name access failure type is network link failure, and the original network interface has an anomaly (such as the number of error frames exceeding the threshold), then it is automatically switched to other available network interfaces (such as switching from the Wi-Fi interface to the cellular network interface); subsequently, the link adaptive optimization operation is performed, and the transmission is adjusted based on the service type corresponding to the backup domain name (whether it is the same as or different from the main domain name). Input parameters—If the service type of the backup domain name is the same as that of the primary domain name (such as HTTPS service), the optimized transmission parameters (such as TCP window size and congestion control algorithm) in the primary domain name access configuration set are reused and fine-tuned according to the historical response characteristics of the backup domain name server (such as adjusting the timeout time ± preset ratio); if the service type is different, the transmission parameters adapted to the service type are reinitialized; at the same time, a two-way verification access link is built. After the transport layer link is established, connectivity and service availability are pre-verified through the preset verification node corresponding to the backup domain name (such as the health check interface on the server side). After the verification is successful, the application layer request is initiated to generate an adapted backup domain name access link. This targeted construction and adaptive optimization design effectively solves the problem of inefficient access caused by the mismatch between the traditional backup domain name access link and the service type and network status, and at the same time reduces access failures caused by service unavailability.

[0059] Preferably, the specific implementation process of initiating backup domain name access and full-link multi-dimensional monitoring is as follows: Based on the adapted backup domain name access link and the optimal backup domain name access set, the backup domain name access is initiated and full-link multi-dimensional real-time monitoring is performed to generate a backup domain name access monitoring dataset; specifically, based on the adapted backup domain name access link, the application layer request data (carrying request parameters, request headers, and timeout time adapted to the backup domain name) in the optimal backup domain name access set is encapsulated and an access request is sent to the target server corresponding to the backup domain name; after the access is initiated, a multi-dimensional monitoring thread with the same source as the main domain name access monitoring logic but specifically optimized is started to collect five types of core monitoring data in real time: First, implicit monitoring data of domain name resolution, which is obtained by resolving the actual Internet Protocol address corresponding to the backup domain name in the background and comparing it with the preset trusted address database of backup domain name and the historical normal address database of the main domain name. If the resolved address is not in the trusted address database, has no relation to the historical normal address of the main domain name, and is not in the preset database, the monitoring thread will be activated. The monitoring system employs a multi-dimensional approach, employing five key technologies: 1) a trusted address range marked as a suspected hijacking identifier for backup domains; 2) transport layer monitoring data, including connection establishment time, retransmission count, and congestion window changes, to determine if there are persistent anomalies at the transport layer; 3) application layer monitoring data, including response status codes, response header integrity, and data transmission rate, to determine if the server is processing requests correctly; 4) network interface monitoring data, including sent / received bytes and interface error rate, to determine if the current network interface is stable; and 5) cross-domain consistency monitoring data, comparing the failure characteristics of backup domains and primary domains (e.g., whether both show abnormal resolution addresses or point to the same abnormal IP). If the characteristics are highly consistent, the data is marked as a cross-domain anomaly association. These five types of monitoring data are then integrated and aligned by timestamps to generate a backup domain access monitoring dataset. This multi-dimensional monitoring design not only captures anomalies in backup domain access itself but also accurately identifies cross-domain anomalies caused by full-domain hijacking, overcoming the limitations of traditional methods that only monitor response status codes.

[0060] Preferably, in the specific technical implementation of intelligent judgment and log retention of backup domain access response results: based on the backup domain access monitoring dataset and the optimal backup domain access set, the backup domain access results are subjected to multi-dimensional verification and intelligent judgment processing to generate the final backup domain access result; specifically, firstly, the application layer response status code in the backup domain access monitoring dataset is extracted. If the status code belongs to the preset success status code set, and the response header integrity identifier is "complete" and the data transmission rate meets the preset threshold, then it is initially judged as successful access; then, it is verified whether the number of retransmissions at the transport layer is lower than the preset threshold, whether the network interface error rate is zero, and whether there is a suspected hijacking identifier for the backup domain. If all conditions are met, the access is confirmed as successful, a successful backup domain access result is generated, and the historical access success rate, average response latency, and other indicators of the backup domain are updated to the domain performance database; if the response status code belongs to the preset failure status code set, or if a response timeout or incomplete data transmission occurs, then deep failure analysis is initiated: if a suspected hijacking identifier or cross-domain abnormal association identifier for the backup domain is detected. If the backup domain name is determined to be hijacked and fails, a backup domain name hijacking failure result is generated. If the above identifier is not detected, the number of retransmissions at the transport layer is analyzed to see if it exceeds the threshold. If it does, it is determined that the network link is continuously abnormal. If the number of retransmissions is normal but the response times out, the availability of the network interface is determined by combining the network interface monitoring data. If it is unavailable, it is determined that the network switching has failed. If it is available, it is determined that the backup domain name server is unresponsive. All failure scenarios generate backup domain name access failure results and associate the failure type with the core abnormal indicators in the monitoring data. At the same time, the backup domain name access monitoring dataset, access results, and optimal backup domain name access set parameters are stored in the access log directory in an encrypted format. The log file name includes the backup domain name, access timestamp, and result identifier, providing data support for subsequent fault tracing and domain name performance optimization. This multi-dimensional verification and intelligent judgment mechanism can accurately distinguish different failure scenarios such as backup domain name failure, network abnormality, and global hijacking, providing a clear basis for whether to switch to the local cached Internet Protocol address for access, avoiding invalid retries or erroneous switching.

[0061] Preferably, the specific implementation process of iterative switching and queue scheduling of multiple backup domains is as follows: Based on the final result of backup domain access and the ordered retry queue, iterative switching and intelligent queue scheduling are performed on multiple backup domains to achieve full utilization of backup domains across the entire domain; specifically, if the current backup domain access fails and the failure type is not "backup domain hijacking failure", then the backup domain and access parameters are stored hierarchically in the backup domain partition of the ordered retry queue, and the queue status type is marked as the backup domain abnormal status identifier; subsequently, the next backup domain with comprehensive priority is selected from the optimal backup domain access set, and the above access link construction, access initiation, and monitoring and judgment process is repeated; if all backup domains fail to access, and there is a backup domain hijacking failure result or cross-domain anomaly, then the backup domain access is terminated. If an associated identifier is found, it is determined to be a global domain hijacking, triggering the local cached Internet Protocol address access process. If all backup domain accesses fail but no such identifier is found, the primary domain or backup domain is extracted from the ordered retry queue according to retry priority, and a limited number of secondary retries are performed (the number of retries does not exceed a preset limit). During the secondary retries, adjusted network parameters are used (such as switching to other network interfaces or extending the timeout period). If all secondary retries still fail, a result of all domain access failures is generated. This iterative switching and queue scheduling design ensures the full utilization of all backup domain resources, reduces the probability of access failures caused by occasional network anomalies through secondary retries, and accurately identifies global domain hijacking scenarios, providing clear triggering conditions for subsequent access method switching.

[0062] Optionally, if access to the backup domain fails, an Internet Protocol address is selected from the time-sensitive client-side local DNS resolution cache Internet Protocol address set, and the domain name is replaced before access is initiated to achieve network service access in the scenario of DNS hijacking. This includes: if access to the backup domain fails, selecting an Internet Protocol address from the time-sensitive client-side local DNS resolution cache Internet Protocol address set; retaining the original network request's protocol type, port number, and other parameters, and replacing the domain name in the access address with the selected Internet Protocol address; and initiating access in the corresponding network based on the replaced access address to achieve network service access in the scenario of DNS hijacking.

[0063] Preferably, in one scenario, the specific implementation process of intelligent filtering and priority sorting of locally cached Internet Protocol addresses is as follows: Based on the time-sensitive client-side local DNS resolution cache Internet Protocol address set and the backup domain name access failure results, the Internet Protocol addresses are subjected to multi-dimensional filtering and dynamic sorting to generate an optimal fallback Internet Protocol address list; specifically, a hierarchical Internet Protocol address set is extracted from the time-sensitive client-side local DNS resolution cache Internet Protocol address set, combined with the failure type in the backup domain name access failure results (such as cross-domain anomaly association identifier, backup domain name...). The first round of screening uses suspected hijacking identifiers to retain high-priority and medium-priority addresses, while removing addresses that are nearing expiration (with remaining validity time less than a preset duration) and those with historical connectivity rates below a preset threshold. Subsequently, a multi-dimensional ranking model is constructed, using address priority, historical access success rate, recent connection time, and compatibility with the current network as core indicators. The weight of each indicator is determined using the entropy weight method, and a comprehensive score is calculated for each address. Addresses are then ranked from highest to lowest score to generate an optimal fallback Internet Protocol (IP) address list. This screening and ranking mechanism ensures that high-quality, highly available IP addresses are prioritized, improving the fallback access success rate.

[0064] Preferably, in the specific technical implementation of domain name replacement and structured reconstruction of the access address: based on the optimal fallback Internet Protocol address list and the original network request parameters, the access address is precisely replaced and the protocol parameters are adapted to generate a legitimate fallback access address; specifically, the Internet Protocol address with the highest comprehensive score is selected from the optimal fallback Internet Protocol address list, and the core parameters in the original network request are extracted, including protocol type (such as HTTP, HTTPS), port number, request path, request parameters, etc.; all core parameters are kept unchanged, and only the domain name part in the original access address is replaced with the selected Internet Protocol address. At the same time, for HTTPS protocol scenarios, certificate adaptation processing is performed—if the target service enables domain name-based certificate verification, the preset compatible certificate configuration is automatically loaded (such as ignoring domain name verification or using wildcard certificates) to avoid certificate verification failure due to address replacement; the replaced address and the adapted protocol parameters are integrated to generate a legitimate fallback access address. This structured reconstruction design ensures the legitimacy of the access address and protocol compatibility, breaking through the protocol conflict problem that is prone to occur in traditional domain name replacement.

[0065] Preferably, in one scenario, the specific implementation of the fallback access link optimization and result verification is as follows: Based on the network information of the legitimate fallback access address and the adapted backup domain name access link, targeted optimization and closed-loop verification of the access result are performed on the fallback access link to enable network service access in the scenario of domain name system hijacking; specifically, the available network interfaces in the adapted backup domain name access link are used, and the transport layer parameters (such as TCP retransmission timeout time, maximum segment size) are adjusted according to the server network characteristics corresponding to the legitimate fallback access address, and a fast link establishment mechanism is enabled (such as reusing TCP connection pool or enabling fast handshake protocol); after the access request is initiated based on the legitimate fallback access address, the closed-loop verification of the access result is started, and the transport layer connection status and application layer response status code are monitored in real time. To ensure data transmission integrity, if the response status code belongs to the preset success status code set and the data transmission is complete, the access is confirmed as successful, enabling network service access in scenarios where the Domain Name System (DNS) is hijacked. If the current Internet Protocol (IP) address access fails, the next address is tried sequentially according to the optimal fallback IP address list until access is successful or all addresses have been tried. During the access process, the access result (success / failure, response latency, transmission quality) of each address is updated to the time-sensitive client-side local DNS resolution cache IP address set, providing data support for subsequent cache refresh and address filtering. This link optimization and closed-loop verification design not only ensures the efficiency of fallback access but also enables dynamic iteration of address performance data, further improving the reliability of subsequent accesses. This application also provides a network access device for DNS hijacking scenarios, including: Cache checking unit: Used to check the client's local domain name resolution cache. If there is an unexpired IP address cache corresponding to the target domain name, it is obtained directly. Otherwise, the IP address is used to directly initiate a network request to the preset trusted service interface to bypass the domain name system resolution and generate a list of IP addresses corresponding to the target domain name. Cache management unit: Used to generate a time-sensitive set of local domain name resolution cache IP addresses for the client based on the list of IP addresses corresponding to the target domain name; Policy generation unit: Based on a set of time-sensitive client-side local domain name resolution cached IP addresses, it obtains the primary domain name, backup domain name, and local cached IP address associated with the target domain name, and configures multi-network enabling and priority IP address access to generate a domain name-priority progressive failover access strategy. Access Execution Unit: Used for a domain-priority-based progressive failover access strategy, executing a switch to the local cached IP address to initiate access to the target resource server.

[0066] This application also provides a computer device, comprising a processor and a memory. The memory stores at least one instruction or at least one program, which is loaded and executed by the processor to implement the network access method under the DNS hijacking scenario. The memory can be used to store software programs and modules. The processor executes various functional applications and the network access method under the DNS hijacking scenario by running the software programs and modules stored in the memory. The memory mainly includes a program storage area and a data storage area. The program storage area can store the operating system, application programs required for functions, etc.; the data storage area can store data created according to the use of the device, etc. In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory may also include a memory controller to provide the processor with access to the memory.

[0067] The methods and embodiments provided in this application can be executed in electronic devices such as mobile terminals, computer terminals, servers, or similar computing devices. Fig. 3 This is a hardware structure block diagram of an electronic device for a network access method in a DNS hijacking scenario provided in an embodiment of this application. (See diagram for example.) Fig. 3 As shown, the electronic device 900 can vary significantly due to differences in configuration or performance. It may include one or more central processing units (CPUs) 910 (CPUs 910 may include, but are not limited to, microprocessors such as MCUs or programmable logic devices such as FPGAs), a memory 930 for storing data, and one or more storage media 920 (e.g., one or more mass storage devices) for storing application programs 923 or data 922. The memory 930 and storage media 920 may be temporary or persistent storage. The program stored in the storage media 920 may include one or more modules, each module may include a series of instruction operations on the electronic device. Furthermore, the CPU 910 may be configured to communicate with the storage media 920 and execute the series of instruction operations in the storage media 920 on the electronic device 900. Electronic device 900 may also include one or more power supplies 960, one or more wired or wireless network interfaces 950, one or more input / output interfaces 940, and / or one or more operating systems 921, such as Windows Server™, MacOSX™, Unix™, Linux™, FreeBSD™, etc.

[0068] The input / output interface 940 can be used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the electronic device 900. In one example, the input / output interface 940 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the input / output interface 940 may be a radio frequency (RF) module used for wireless communication with the Internet.

[0069] Embodiments of this application also provide a computer-readable storage medium, which can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a network access method in a DNS hijacking scenario in the method embodiment. The at least one instruction or the at least one program is loaded and executed by the processor to implement the network access method in a DNS hijacking scenario provided in the above method embodiment.

[0070] Optionally, in this embodiment, the storage medium may be located at at least one of the multiple network servers in a computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0071] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the network access method for DNS hijacking scenarios provided in the various optional implementations described above.

[0072] It should be understood that this application is not limited to the processes and structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A network access method in a DNS hijacking scenario, characterized in that, The method comprises the following steps: checking the local domain name resolution cache of the client, if there is a non-expired IP address cache corresponding to the target domain name, directly obtaining the IP address list corresponding to the target domain name, otherwise, directly initiating a network request to the preset trusted service interface using the IP address to bypass the domain name system resolution, to generate the IP address list corresponding to the target domain name; generating a time-limited client local domain name resolution cache IP address set according to the IP address list corresponding to the target domain name; based on the time-limited client local domain name resolution cache IP address set, obtaining the primary domain name, backup domain name and local cache IP address associated with the target domain name, and performing multi-network enabling and priority IP address access configuration to generate a domain name priority progressive failover access strategy; based on the domain name priority progressive failover access strategy, switching to the local cache IP address to initiate access to the target resource server.

2. The network access method in a DNS hijacking scenario according to claim 1, characterized in that, The method comprises the following steps: checking the local domain name resolution cache of the client, if there is a non-expired IP address cache corresponding to the target domain name, directly obtaining the IP address list corresponding to the target domain name, otherwise, directly initiating a network request to the preset trusted service interface using the IP address to bypass the domain name system resolution, to generate the IP address list corresponding to the target domain name, including: checking the existence of the local domain name resolution cache of the client, scanning the preset cache storage directory, finding the cache file with the target domain name as the unique identifier, to obtain the cache existence result or the cache nonexistence result; if the cache existence result is obtained, checking the cache file for time limit, extracting the cache expiration time in the cache file and comparing it with the current system time, to obtain the cache non-expiration result or the cache expiration result; if the cache nonexistence result or the cache expiration result is obtained, directly initiating a network request using the IP address of the preset trusted service interface, eliminating invalid IP addresses after signature verification and response analysis, to generate the IP address list corresponding to the target domain name; 3. The network access method in a DNS hijacking scenario according to claim 2, characterized in that, if the cache non-expiration result is obtained, directly extracting the IP address list corresponding to the target domain name from the cache file. The method comprises the following steps: if the cache existence result is obtained, checking the cache file for time limit, extracting the cache expiration time in the cache file and comparing it with the current system time, to obtain the cache non-expiration result or the cache expiration result, including: reading the cache file corresponding to the cache existence result, extracting the metadata field in the file, which contains the cache generation time and the preset valid time length; 4. The network access method in a DNS hijacking scenario according to claim 2, characterized in that, calculating the cache expiration time by the cache generation time and the preset valid time length; converting the cache expiration time and the current system time into a unified time format and comparing them, if the current system time is not more than the cache expiration time, the cache non-expiration result is obtained, otherwise, the cache expiration result is obtained. if the cache nonexistence result or the cache expiration result is obtained, directly initiating a network request using the IP address of the preset trusted service interface, eliminating invalid IP addresses after signature verification and response analysis, to generate the IP address list corresponding to the target domain name; if the cache non-expiration result is obtained, directly extracting the IP address list corresponding to the target domain name from the cache file, including: Extract the preset trusted service interface IP address from the local configuration file, splice the target domain name with the current timestamp, and generate signature data through a hash encryption algorithm; Encapsulate the target domain name, timestamp, and signature data into a network request data packet, and directly initiate a network request to the trusted service interface IP address, bypassing the domain name system resolution; Receive the response data returned by the trusted service, verify the consistency of the server signature in the response data with the locally generated signature data, and extract the IP address list after the analysis passes, and eliminate invalid IP addresses to generate an IP address list corresponding to the target domain name.

5. The network access method in a DNS hijacking scenario according to claim 1, characterized in that, Generate a time-limited client local domain name resolution cache IP address set based on the IP address list corresponding to the target domain name, including: Based on the IP address list corresponding to the target domain name, supplement the resolution time, cache generation time, cache expiration time, and whether it is a preset domain name identifier to generate a time-limited client local domain name resolution cache IP address set; Serialize the time-limited client local domain name resolution cache IP address set into a specified format data and write it into a local cache file to realize persistent storage; Start an independent cache refresh thread to trigger cache checking and updating process at a preset period, and reacquire the latest IP address list through the existence and timeliness double judgment mechanism to update the local domain name resolution cache.

6. The network access method in a DNS hijacking scenario according to claim 5, characterized in that, The time-limited client local domain name resolution cache IP address set based on the IP address list corresponding to the target domain name, supplementing the resolution time, cache generation time, cache expiration time, and whether it is a preset domain name identifier, includes: Extract all IP addresses in the IP address list corresponding to the target domain name; Record the current system time as the resolution time and cache generation time, and calculate the cache expiration time based on the preset valid time length; Determine whether the target domain name is the domain name corresponding to a specific player, generate a preset domain name identifier, and integrate the IP address list, resolution time, cache generation time, cache expiration time, and preset domain name identifier to generate a time-limited client local domain name resolution cache IP address set.

7. The network access method in a DNS hijacking scenario according to claim 1, characterized in that, The time-limited client local domain name resolution cache IP address set based on the time-limited client local domain name resolution cache IP address set, obtains the main domain name, backup domain name, and local cache IP address associated with the target domain name, and performs multi-network enablement and priority IP address access configuration to generate a domain name priority progressive failover access strategy, including: Extract the local cache IP address from the time-limited client local domain name resolution cache IP address set, and obtain the main domain name and backup domain name corresponding to the target domain name from the preset domain name association configuration; Read the network configuration parameters of the client, determine whether to enable multi-network function, if enabled, detect the current available network type and sort and lock the priority network according to the rules; Read the access priority configuration of the client, determine whether to use IP address access preferentially, and combine the main domain name, backup domain name, local cache IP address, and network configuration result to generate a domain name priority progressive failover access strategy.

8. The network access method in a DNS hijacking scenario according to claim 7, characterized in that, The local cache IP address is extracted from the client local domain name resolution cache IP address set with time limit, the primary domain name and the backup domain name corresponding to the target domain name are obtained from the preset domain name association configuration, and the method comprises the steps of: Resolving the client local domain name resolution cache IP address set with time limit, extracting the IP address list as the local cache IP address; Accessing the preset domain name association configuration file, which stores the mapping relationship between the target domain name and the primary domain name and the backup domain name; According to the target domain name, the mapping relationship is queried, and the corresponding primary domain name and backup domain name are extracted.

9. The network access method in a DNS hijacking scenario according to claim 1, characterized in that, The domain name priority-based progressive failover access strategy is used to switch to the local cache IP address to initiate access to the target resource server, comprising: Based on the domain name priority-based progressive failover access strategy, the primary domain name is used to initiate access in the priority network or the current active network, and the access response result is monitored; If the primary domain name access fails, switch to the backup domain name to initiate access, and monitor the backup domain name access response result; If the backup domain name access fails, select an IP address from the client local domain name resolution cache IP address set with time limit, replace the domain name and initiate access, and realize network service access in the domain name system hijacking scenario.

10. A network access device in a DNS hijacking scenario, the network access device comprising: It comprises: Cache checking unit: used for checking the local domain name resolution cache of the client, if there is an unexpired IP address cache corresponding to the target domain name, it is directly obtained, otherwise the IP address is directly used to initiate a network request to the preset trusted service interface to bypass the domain name system resolution, to generate an IP address list corresponding to the target domain name; Cache management unit: used for generating a client local domain name resolution cache IP address set with time limit according to the IP address list corresponding to the target domain name; Strategy generation unit: used for generating a domain name priority-based progressive failover access strategy based on the client local domain name resolution cache IP address set with time limit, obtaining the primary domain name, backup domain name and local cache IP address associated with the target domain name, and performing multi-network enabling and priority IP address access configuration; Access execution unit: used for executing the domain name priority-based progressive failover access strategy to switch to the local cache IP address to initiate access to the target resource server.

11. A computer device, comprising: The device comprises a processor and a memory, and the memory stores at least one instruction or at least one program, which is loaded and executed by the processor to realize the network access method in the DNS hijacking scenario as claimed in any one of claims 1-9.

12. A computer program product or computer program, characterized in that, The computer program product or computer program comprises computer instructions, which are executed by the processor to realize the network access method in the DNS hijacking scenario as claimed in any one of claims 1-9.

Images