Domain name resolution method, device, computer equipment and readable storage medium

Abstract

The embodiments of the present application provide a domain name resolution method, apparatus, computer device, and readable storage medium. The method includes: in response to a domain name resolution request, resolving a domain name to be resolved to obtain a corresponding first Internet Protocol address; determining a target historical snapshot corresponding to the domain name to be resolved at the previous historical time step from a local disaster recovery database; the target historical snapshot being snapshot data of the historical resolution log data when the predicted resolution log data at the second time step does not deviate from the expected log range; extracting the second Internet Protocol address obtained by resolving the domain name to be resolved at the previous historical time step from the target historical snapshot, and comparing the first Internet Protocol address with the second Internet Protocol address. When the comparison result indicates that the first Internet Protocol address and the second Internet Protocol address are inconsistent, determining the second Internet Protocol address as the domain name resolution result for the domain name to be resolved. In this way, the speed and accuracy of domain name resolution can be improved.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to a domain name resolution method, apparatus, computer equipment, and readable storage medium. Background Art

[0002] The Domain Name System (DNS) is a core service of the internet. Its role is to convert easily memorable domain names (such as www.example.com) into Internet Protocol (IP) addresses (such as 192.0.2.1) used by computers for network communication, ensuring smooth access to relevant websites. However, as the internet has become a vital platform for information exchange, DNS not only performs domain name resolution but also becomes a vulnerable target for network security attacks, such as DNS hijacking and Distributed Denial of Service (DDoS) attacks. If the DNS is hijacked, it may return incorrect IP addresses, leading users to risky websites and even triggering security incidents.

[0003] In related technologies, the cooperation of domain name owners is often required to achieve security protection for the DNS resolution process. For example, domain name owners may use tools and services provided by security providers, such as Domain Name System Security Extensions (DNSSEC) and DDoS protection tools, to increase the security of DNS. However, this will also cause some potential problems. For example, when facing ever-changing network threats, rapid adjustments and responses are required. Relying on the cooperation of domain name owners may limit this flexibility, resulting in resolution delays; and improving resolution speed often requires simplifying the verification process, such as omitting checks on DNSSEC tools, which may result in the inability to detect tampering or erroneous resolution results in a timely manner, reducing the accuracy of resolution. In summary, related technologies cannot take into account both the resolution speed and accuracy of the domain name resolution process. Summary of the Invention

[0004] The main purpose of the embodiments of the present application is to propose a domain name resolution method, apparatus, computer equipment and readable storage medium, which can improve the domain name resolution speed while ensuring the accuracy of the resolution process.

[0005] To achieve the above objectives, a first aspect of an embodiment of the present application provides a domain name resolution method, the method comprising:

[0006] In response to the domain name resolution request, resolving the domain name to be resolved included in the domain name resolution request to obtain a corresponding first Internet Protocol address;

[0007] Determine the target historical snapshot corresponding to the domain name to be resolved at the previous historical time step from the local disaster recovery database;

[0008] The target historical snapshot is snapshot data of the historical parsing log data when the predicted parsing log data at the second time step does not deviate from the expected log range; the predicted parsing log data is predicted by the target model based on the historical parsing log data generated when the domain name to be resolved is parsed to obtain the Internet Protocol address at the first time step; the first time step is located before the second time step;

[0009] extracting, from the target historical snapshot, a second Internet Protocol address obtained by resolving the domain name to be resolved at the previous historical time step, and comparing the first Internet Protocol address with the second Internet Protocol address to obtain a comparison result;

[0010] When the comparison result indicates that the first Internet Protocol address and the second Internet Protocol address are inconsistent, the second Internet Protocol address is determined as the domain name resolution result of the domain name to be resolved.

[0011] Accordingly, a second aspect of the embodiments of the present application provides a domain name resolution device, the device comprising:

[0012] a response module, configured to, in response to a domain name resolution request, resolve the domain name to be resolved contained in the domain name resolution request to obtain a corresponding first Internet Protocol address;

[0013] A first determination module is configured to determine, from a local disaster recovery database, a target historical snapshot corresponding to the domain name to be resolved at a previous historical time step; wherein the target historical snapshot is snapshot data of historical resolution log data when the predicted resolution log data at the second time step does not deviate from an expected log range; the predicted resolution log data is predicted using a target model based on historical resolution log data generated when the domain name to be resolved obtains an Internet Protocol address at the first time step; and the first time step is located before the second time step.

[0014] an extraction module, configured to extract, from the target historical snapshot, a second Internet Protocol address obtained by resolving the domain name to be resolved at the previous historical time step, and compare the first Internet Protocol address with the second Internet Protocol address to obtain a comparison result;

[0015] The second determining module is configured to determine the second Internet Protocol address as a domain name resolution result of the domain name to be resolved when the comparison result indicates that the first Internet Protocol address and the second Internet Protocol address are inconsistent.

[0016] In some embodiments, the domain name resolution device further includes a prediction module configured to:

[0017] Obtaining a plurality of preset domain names included in a preset list of re-protected domain names, and for each preset domain name, obtaining historical resolution log data generated when each preset domain name is resolved to obtain a corresponding Internet Protocol address at a first time step;

[0018] For each of the preset domain names, the corresponding historical parsing log data is input into the target model to obtain predicted parsing log data corresponding to a second time step of the historical parsing log data; wherein the first time step is located before the second time step;

[0019] Obtaining an expected log range set for each of the historical parsed log data, and comparing each of the predicted parsed log data with the corresponding expected log range to obtain a comparison result; wherein the expected log range includes at least one reference candidate event predicted to occur in the next time step by the predicted parsed log data;

[0020] When the comparison result indicates that the predicted parsing log data is within the expected log range, the historical parsing log data is stored in a location of the corresponding preset domain name in the local disaster recovery database.

[0021] In some embodiments, the prediction module is further configured to:

[0022] For the historical parsing log data of each preset domain name, intercepting a corresponding sequence to be predicted from the historical parsing log data at the current time step through a sliding window;

[0023] Inputting the sequence to be predicted into a target model, and generating a first hidden state vector of the sequence to be predicted by a first encoder in the target model in a forward time sequence, and generating a second hidden state vector of the sequence to be predicted by a second encoder in the target model in a reverse time sequence;

[0024] Predicting, by a decoder of the target model, a predicted character for the next time step based on a fused hidden state vector of the first hidden state vector and the second hidden state vector;

[0025] Updating the predicted character to the sequence to be predicted at the current time step, moving the sliding window to update the sequence to be predicted at the next time step, inputting the sequence to be predicted at the current time step into the target model, and predicting the predicted character at the next time step based on the sequence to be predicted at the current time step by the target model;

[0026] Repeating the steps of updating the predicted character to the sequence to be predicted at the current time step, moving the sliding window to update the sequence to be predicted at the current time step, inputting the sequence to be predicted at the current time step into the target model, and predicting the predicted character at the next time step based on the sequence to be predicted at the current time step by the target model, until the number of the updated plurality of predicted characters reaches a preset number threshold;

[0027] Based on the multiple predicted characters, the predicted parsing log data of the historical parsing log data corresponding to the second time step is obtained.

[0028] In some embodiments, the prediction module is further configured to:

[0029] For the historical parsing log data of each preset domain name, intercepting the corresponding log to be predicted from the historical parsing log data at the current time step through a sliding window;

[0030] Obtaining a preset character conversion dictionary, and determining a conversion value corresponding to each character in the log to be predicted using the character conversion dictionary;

[0031] The corresponding characters in the log to be predicted are replaced by each conversion value to obtain the corresponding sequence to be predicted.

[0032] In some embodiments, the domain name resolution device further includes a training module for:

[0033] Obtaining a sample sequence to be predicted corresponding to sample history parsing log data, and inputting the sample sequence to be predicted into a preset model to obtain a plurality of sample prediction probabilities corresponding to a plurality of sample prediction characters predicted by the preset model at subsequent sample time steps of the sample sequence to be predicted;

[0034] Obtaining a true sample label character at a sample time step subsequent to the sample to be predicted sequence, and calculating the target loss of the preset model based on the true sample label character, the plurality of sample prediction characters, and the corresponding plurality of sample prediction probabilities;

[0035] The preset model is trained based on the target loss to obtain a target model.

[0036] In some embodiments, the training module is further configured to:

[0037] For each of the sample predicted characters, determining a sample prediction probability corresponding to the sample predicted character;

[0038] Determine a first sub-loss corresponding to the corresponding sample prediction character according to the sample prediction probability and the true sample label character;

[0039] The target loss of the preset model is determined according to the multiple first sub-losses corresponding to the multiple sample prediction characters.

[0040] In some embodiments, the domain name resolution device further includes an update module configured to:

[0041] When there is a historical snapshot update of a preset domain name in the local disaster recovery database, determining a to-be-updated area corresponding to the updated historical snapshot;

[0042] In the local disaster recovery database, the historical snapshot in the area to be updated is overwritten based on the updated historical snapshot.

[0043] Correspondingly, the third aspect of the embodiments of the present application proposes a computer device, which includes a memory and a processor, the memory stores a computer program, and the processor implements the domain name resolution method described in any one of the embodiments of the first aspect of the present application when executing the computer program.

[0044] Correspondingly, the fourth aspect of the embodiments of the present application proposes a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the domain name resolution method described in any one of the embodiments of the first aspect of the present application.

[0045] The embodiment of the present application resolves the domain name to be resolved contained in the domain name resolution request in response to the domain name resolution request to obtain the corresponding first Internet Protocol address; determines the target historical snapshot corresponding to the domain name to be resolved at the previous historical time step from the local disaster recovery database; wherein the target historical snapshot is snapshot data of the historical resolution log data when the predicted resolution log data at the second time step does not deviate from the expected log range; the predicted resolution log data is predicted by the target model based on the historical resolution log data generated when the domain name to be resolved is resolved to obtain the Internet Protocol address at the first time step; the first time step is located at the front of the second time step; from the target historical snapshot, extracts the second Internet Protocol address obtained by resolving the domain name to be resolved at the previous historical time step, and compares the first Internet Protocol address with the second Internet Protocol address to obtain a comparison result; when the comparison result indicates that the first Internet Protocol address and the second Internet Protocol address are inconsistent, determines the second Internet Protocol address as the domain name resolution result of the domain name to be resolved. In this way, the log trend of the subsequent historical parsing log can be predicted through the target model to obtain the predicted parsing log data, so as to save the historical parsing log data that belongs to the expected log range, that is, the historical parsing log data that belongs to the normal log range as a snapshot, thereby ensuring that only normal historical parsing log data will be saved as a historical snapshot, thereby improving the accuracy and reliability of the data; in addition, the first Internet Protocol address currently obtained by the resolution is compared with the target historical snapshot in the local disaster recovery database to quickly verify and / or correct the correctness of the first Internet Protocol address, without the direct cooperation of the domain name owner, and not subject to the response speed of the domain name owner, etc., thereby improving the response speed and flexibility of the system. In summary, the present application can ensure the accuracy of the resolution process while improving the speed of domain name resolution. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 This is a schematic diagram of the architecture of the domain name resolution system provided by an embodiment of the present application;

[0047] Figure 2 This is a flowchart of the domain name resolution method provided by an embodiment of the present application;

[0048] Figure 3 This is an example diagram of a fused hidden state vector obtained by splicing provided in an embodiment of the present application;

[0049] Figure 4 This is a flowchart of step-by-step generation of a sequence to be predicted provided by an embodiment of the present application;

[0050] Figure 5 This is an overall flow chart of the domain name resolution method provided by the embodiment of the present application;

[0051] Figure 6This is a schematic diagram of the functional modules of the domain name resolution device provided in an embodiment of the present application;

[0052] Figure 7 This is a schematic diagram of the hardware structure of the computer device provided in the embodiment of the present application. DETAILED DESCRIPTION

[0053] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0054] It should be noted that although the device schematics illustrate functional module divisions and the flowcharts illustrate logical sequences, in certain circumstances, the steps shown or described may be performed in a sequence that differs from the module divisions in the device or the sequence in the flowcharts. The terms "first," "second," and so on, in the specification, claims, and drawings, are used to distinguish similar items and are not necessarily used to describe a specific sequence or precedence.

[0055] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0056] The Domain Name System (DNS) is a core service of the internet. Its role is to convert easily memorable domain names (such as www.example.com) into Internet Protocol (IP) addresses (such as 192.0.2.1) used by computers for network communication, ensuring smooth access to relevant websites. However, as the internet has become a vital platform for information exchange, DNS not only performs domain name resolution but also becomes a vulnerable target for network security attacks (such as DNS hijacking and DDoS attacks). If the DNS is hijacked, it may return incorrect IP addresses, leading users to risky websites and even triggering security incidents.

[0057] Related technologies often require the cooperation of domain name owners to implement security protections for the DNS resolution process. For example, domain name owners may employ tools and services provided by security providers, such as DNSSEC and DDoS protection tools, to enhance DNS security. However, this can also create potential problems. For example, relying on the cooperation of domain name owners can limit flexibility in the face of ever-changing cyber threats, requiring rapid adjustments and responses, leading to resolution delays. Improving resolution speed often requires simplifying the verification process, such as omitting checks on DNSSEC tools. This can result in inability to promptly detect tampered or erroneous resolution results, reducing resolution accuracy. In summary, related technologies fail to balance resolution speed and accuracy in the domain name resolution process.

[0058] Based on this, the embodiments of the present application provide a domain name resolution method, apparatus, computer device, and readable storage medium, which can improve the speed of domain name resolution while ensuring the accuracy of the resolution process.

[0059] The domain name resolution method, apparatus, computer device, and readable storage medium provided in the embodiments of the present application are specifically described through the following embodiments. First, the domain name resolution system in the embodiments of the present application is described.

[0060] Please refer to Figure 1 In some implementations, an embodiment of the present application provides a domain name resolution system, including a terminal 11 and a server 12.

[0061] Exemplarily, the terminal 11 may be a user device, such as a personal computer, a smart phone, or other network device. When a user enters a domain name in a browser or the system attempts to access a corresponding service, the terminal 11 may send a domain name resolution request to the server 12.

[0062] In some embodiments, the server 12 may be a computer device, which may be a dedicated physical server, a virtual server, or a cloud server. The server 12 may include a DNS server, a root domain name server, a local disaster recovery backup server, etc. The server 12 may be used to store and process DNS resolution data. When it is found that the resolved Internet Protocol address has been tampered with, the server 12 may return the correct Internet Protocol address through the local disaster recovery database stored in the local disaster recovery backup server. Alternatively, when the system cannot provide domain name resolution services, the server 12 may return the correct Internet Protocol address through the local disaster recovery database stored in the local disaster recovery backup server, etc.

[0063] The domain name resolution method in the embodiments of the present application can be illustrated by the following embodiments.

[0064] It should be noted that in each specific embodiment of the present application, when it comes to the need to perform relevant processing based on data related to user identity or characteristics such as user information, user behavior data, user historical data, and user location information, the user's permission or consent will be obtained first. Moreover, the collection, use, and processing of these data will comply with relevant laws, regulations, and standards. In addition, when the embodiment of the present application needs to obtain the user's sensitive personal information, the user's separate permission or consent will be obtained through a pop-up window or by jumping to a confirmation page. After clearly obtaining the user's separate permission or consent, the necessary user-related data for the normal operation of the embodiment of the present application will be obtained.

[0065] In the embodiment of the present application, the domain name resolution device will be described from the perspective of the domain name resolution device, which can be integrated into a computer device. Figure 2 , Figure 2 This is a flowchart of the steps of the domain name resolution method provided in an embodiment of the present application. In this embodiment of the present application, the domain name resolution device is specifically integrated into a terminal or server as an example. When the processor on the terminal or server executes the program instructions corresponding to the domain name resolution method, the specific process is as follows:

[0066] Step 101: In response to a domain name resolution request, the domain name to be resolved included in the domain name resolution request is resolved to obtain a corresponding first Internet Protocol address.

[0067] In some implementations, in order to facilitate the device to locate and connect to the target server through the network, the domain name to be resolved can be resolved to obtain the first Internet Protocol address, so as to obtain the actual pointing of the domain name in the current network environment.

[0068] A domain name resolution request may be a query request sent by a user to a DNS server via a terminal to convert a user-friendly domain name to be resolved into a machine-readable IP address, thereby establishing communication on the network. For example, a domain name resolution request may include information such as the domain name to be resolved, the request type (e.g., an A record requesting an IPv4 address, or an AAAA record requesting an IPv6 address), and so on.

[0069] The domain name to be resolved may be the domain name corresponding to the service or website that the user needs to access. For example, "example.com" is a domain name to be resolved, which identifies a specific service or website on the Internet.

[0070] The first Internet Protocol address can be the IP address associated with the domain name to be resolved, which is one of the target outputs in the DNS resolution process. When the domain name resolution request includes an A record request, the first Internet Protocol address can be the IPv4 address assigned to the domain name to be resolved; when the domain name resolution request includes an AAAA record request, the first Internet Protocol address can be the IPv6 address assigned to the domain name to be resolved. The first Internet Protocol address is used to instruct devices on the network to locate and connect to the service or resource represented by the domain name to be resolved.

[0071] For example, if the domain name to be resolved is www.example.com, when a user initiates a domain name resolution request through a browser or application on a terminal, the domain name resolution request can be sent to a local recursive server. The local recursive server can then send a request to a root server, querying the top-level domain name server responsible for the .com top-level domain. The root server then returns the address of the top-level domain name server responsible for .com. The local recursive server then sends a request to the top-level domain name server, which returns the address of the authoritative name server responsible for the example.com domain. Based on the address of the authoritative name server, the local recursive server then sends a request to the authoritative name server. In this way, after receiving the request, the authoritative name server can find the first Internet Protocol address corresponding to www.example.com and return the first Internet Protocol address to the local recursive server. The local recursive server then returns the obtained first Internet Protocol address to the terminal. After receiving the first Internet Protocol address, the terminal stores it in the local recursive server cache and uses the first Internet Protocol address to establish a connection with the target server.

[0072] In some implementations, the local recursive server may also cache the Internet Protocol address of the domain name to be resolved, and upon receiving the domain name resolution request from the terminal, may directly return the cached Internet Protocol address.

[0073] In the above manner, the terminal can quickly obtain the first Internet Protocol address obtained by resolving the domain name to be resolved by the domain name resolution server, so as to facilitate subsequent analysis of whether the first Internet Protocol address has been tampered with.

[0074] Step 102, determining the target historical snapshot corresponding to the domain name to be resolved in the previous historical time step from the local disaster recovery database; wherein the target historical snapshot is the snapshot data of the historical resolution log data when the predicted resolution log data in the second time step does not deviate from the expected log range; the predicted resolution log data is predicted by the target model based on the historical resolution log data generated when the domain name to be resolved obtains the Internet Protocol address in the first time step; the first time step is located at the front of the second time step.

[0075] In some implementations, to ensure consistency and security of domain name resolution results, a target historical snapshot corresponding to the domain name to be resolved at the previous historical time step may be determined from a local disaster recovery database to enhance security and reliability of the domain name resolution process.

[0076] The local disaster recovery database can be a database used to store snapshots of historical resolution log data for each pre-set domain name in the list of re-protected domain names (including the domain names to be resolved). The local disaster recovery database can provide fast and reliable domain name resolution services when the primary service fails, such as when the local recursive server fails, or return the correct Internet Protocol address when a domain name is tampered with, thereby improving system stability.

[0077] The previous historical time step can be the time step corresponding to the historical snapshot of the domain name to be resolved in the local disaster recovery database with the smallest time interval from the current time step. For example, in the local disaster recovery database, domain name A to be resolved has historical snapshot 1 stored at 12:15 and historical snapshot 2 stored at 12:20. If the current time step is 12:25, then the time step corresponding to the historical snapshot with the smallest time interval from the current time step is 12:20.

[0078] The target historical snapshot may be a historical snapshot of the domain name to be resolved stored in the local disaster recovery database with the shortest time interval between the snapshot and the current time step.

[0079] Among them, the second time step can be used to describe the time point when the prediction of the predictive parsing log data occurs. The second time step is not used to refer to a specific time, but is used to limit the time step of generating the predictive parsing log data to be after the time step of generating the historical parsing log data.

[0080] The predicted resolution log data may be a result of using a target model (such as a BiLSTM model) to predict the domain name resolution behavior of the historical resolution log at the second time step, and is used to identify potential problems or abnormal situations in advance.

[0081] The expected log range can be a reasonable set of log entries based on historical parsed log data, which is used to compare with the predicted parsed log data to identify whether the predicted parsed log data is abnormal. For example, if the predicted parsed log data is included in the expected log range, the predicted parsed log data is determined to be normal; otherwise, the predicted parsed log data is determined to be abnormal.

[0082] The historical resolution log data may be data recorded during historical periods when a domain name to be resolved was resolved to obtain a corresponding Internet Protocol address. The historical resolution log data includes, but is not limited to, information such as the request type (e.g., A or AAAA) and historical domain name resolution results.

[0083] The target model can be a machine learning model that predicts subsequent log data based on historical resolution log data, such as a BiLSTM model. The target model can learn common patterns in domain name resolution and predict future resolution logs.

[0084] The first time step may be the time step at which the historical parsing log data is generated. The first time step does not refer to a specific time, but is used to limit the time step at which the historical parsing log data is generated to be located before the time step at which the predicted parsing log data is generated.

[0085] In some implementations, this process ensures that only logs that meet expectations are snapshotted and stored in a local disaster recovery database for future use.

[0086] Specifically, you can query the local disaster recovery database based on the domain name to be resolved to quickly determine the target historical snapshot corresponding to the domain name to be resolved at the previous historical time step. For example, if the domain name to be resolved is www.example.com and the current time step is 16:00, and if the local disaster recovery database stores multiple target historical snapshots corresponding to www.example.com, where the historical snapshot closest to the current time step is snapshot A and the resolution time corresponding to snapshot A is 15:00, then snapshot A can be used as the target historical snapshot for the domain name to be resolved at the previous historical time step of 15:00.

[0087] In some embodiments, each historical snapshot stored in the local disaster recovery database for the domain name to be resolved is obtained by saving a snapshot of the historical resolution log data that has been verified to be correctly resolved. When verifying each historical resolution log data corresponding to the first time step, the future log generation trend of each historical resolution log data can be predicted through a pre-trained target model to obtain the predicted resolution log data generated in the second time step. Afterwards, the predicted resolution log data can be judged as abnormal based on the predefined expected log range. When the predicted resolution log data does not deviate from the expected log range, it indicates that the predicted resolution log data belongs to normal log data, and the generation trend of the historical resolution log data corresponding to the predicted resolution log data does not show any abnormality. The historical resolution log data also belongs to normal log data. The historical resolution log data can be snapshotted and saved to obtain the target historical snapshot corresponding to the domain name to be resolved. In this way, not only the security and reliability of domain name resolution are improved, but also a rapid recovery mechanism is provided, which enhances the stability and responsiveness of the system.

[0088] For example, if the predicted parsing log data predicted for the historical parsing log data according to the target model is 192.0.2.1, and if the expected log range is predefined as 192.0.2.1 and 192.0.2.2 based on reasonable Internet Protocol address changes, and 192.0.2.1 falls within the expected log range, then the historical parsing log data snapshot corresponding to 192.0.2.1 can be saved as a historical snapshot.

[0089] Through the above method, the most recent target historical snapshot can be quickly extracted from the local disaster recovery database when a domain name resolution request is made, so as to provide a local anomaly judgment mechanism, speed up the resolution speed, and enhance network security.

[0090] Step 103 : extracting the second Internet Protocol address obtained by resolving the domain name to be resolved at the previous historical time step from the target historical snapshot, and comparing the first Internet Protocol address with the second Internet Protocol address to obtain a comparison result.

[0091] In some embodiments, when a DNS server has a vulnerability or is infected by software, an attacker may tamper with the records on the DNS server through DNS hijacking, resulting in an incorrect Internet Protocol address after domain name resolution. Therefore, in order to confirm whether the first Internet Protocol address currently resolved has been tampered with, the second Internet Protocol address corresponding to the domain name to be resolved can be extracted from the local disaster recovery database to verify the first Internet Protocol address, thereby achieving non-cooperative domain name resolution (i.e., resolution without the direct cooperation of the domain name owner) to ensure the security and consistency of the domain name resolution results.

[0092] The second Internet Protocol address may be an Internet Protocol address extracted from the target historical snapshot and obtained by resolving the domain name to be resolved at the previous historical time step. The second Internet Protocol address represents a credible resolution result of the domain name to be resolved.

[0093] The comparison result may be a result of comparing the first IP address currently parsed with the second IP address extracted from the target historical snapshot. The comparison result is used to determine whether the current parsed result is consistent with the previously recorded result, thereby identifying any possible tampering or other anomalies.

[0094] For example, taking the domain name to be resolved as www.example.com, when historical snapshot A at T2 (12:00 noon) is determined to be the target historical snapshot, the second IP address of www.example.com resolved at T2 recorded in snapshot A can be obtained. If the second IP address is 93.184.216.34, the system compares the first IP address 93.184.216.35 resolved at the current time with the second IP address 93.184.216.34 in snapshot A. The comparison result shows that the first IP address (93.184.216.35) is inconsistent with the second IP address (93.184.216.34), indicating that the resolution result may be abnormal or tampered with.

[0095] By comparing the currently resolved first Internet Protocol address with the historically trusted second Internet Protocol address, any potential anomalies or tampering can be quickly detected and responded to, thereby improving the stability and reliability of the system to ensure that when problems occur, the correct resolution state can be quickly restored.

[0096] Step 104: When the comparison result indicates that the first Internet Protocol address and the second Internet Protocol address are inconsistent, the second Internet Protocol address is determined as the domain name resolution result of the domain name to be resolved.

[0097] In some embodiments, in order to ensure the security and consistency of the domain name resolution results, when the comparison results show that the first Internet Protocol address currently resolved is inconsistent with the second Internet Protocol address extracted from the target historical snapshot, the trusted historical resolution result, that is, the second Internet Protocol address, can be used as the final domain name resolution result to effectively prevent resolution errors caused by malicious attacks, ensure the accuracy and reliability of the resolution results, and ensure that users can access correct and secure services.

[0098] The domain name resolution result may be a specific direction finally determined by the process of converting the domain name to be resolved into a machine-readable Internet Protocol address.

[0099] In some embodiments, when the comparison result indicates that the first Internet Protocol address and the second Internet Protocol address are consistent, for example, when both are 93.200.200.35, it indicates that the resolution result has not been abnormal or tampered with, and the first Internet Protocol address can be used as the domain name resolution result of the domain name to be resolved.

[0100] For example, taking the domain name to be resolved as www.example.com, when the first Internet Protocol address is 93.112.200.00 and the second Internet Protocol address is 93.184.216.34, it indicates that the resolution result may be abnormal or tampered with. At this time, you can switch to the correct resolution result provided by the local disaster recovery database (that is, the second Internet Protocol address), and determine the second Internet Protocol address as the domain name resolution result of the domain name to be resolved and return it to the terminal.

[0101] In some embodiments, the cache data stored in the historical resolution process of the domain name to be resolved can be first obtained from the local DNS server to obtain the cached Internet Protocol address, and the first Internet Protocol address and the cached Internet Protocol address are compared. When the first Internet Protocol address and the cached Internet Protocol address are inconsistent, the target historical snapshot corresponding to the domain name to be resolved at the previous historical time step is obtained from the local disaster recovery database. From the target historical snapshot, the second Internet Protocol address obtained by resolving the domain name to be resolved at the previous historical time step is extracted, and the second Internet Protocol address is determined as the domain name resolution result of the domain name to be resolved. In this way, the cached data can be fully utilized to quickly and accurately resolve the domain name to be resolved. It is understandable that the cached Internet Protocol address will be cached in the local DNS server only when the resolution process is correct.

[0102] The embodiment of the present application resolves the domain name to be resolved contained in the domain name resolution request in response to the domain name resolution request to obtain the corresponding first Internet Protocol address; determines the target historical snapshot corresponding to the domain name to be resolved at the previous historical time step from the local disaster recovery database; wherein the target historical snapshot is snapshot data of the historical resolution log data when the predicted resolution log data at the second time step does not deviate from the expected log range; the predicted resolution log data is predicted by the target model based on the historical resolution log data generated when the domain name to be resolved is resolved to obtain the Internet Protocol address at the first time step; the first time step is located at the front of the second time step; from the target historical snapshot, extracts the second Internet Protocol address obtained by resolving the domain name to be resolved at the previous historical time step, and compares the first Internet Protocol address with the second Internet Protocol address to obtain a comparison result; when the comparison result indicates that the first Internet Protocol address and the second Internet Protocol address are inconsistent, determines the second Internet Protocol address as the domain name resolution result of the domain name to be resolved. In this way, the log trend of the subsequent historical parsing log can be predicted through the target model to obtain the predicted parsing log data, so as to save the historical parsing log data that belongs to the expected log range, that is, the historical parsing log data that belongs to the normal log range as a snapshot, thereby ensuring that only normal historical parsing log data will be saved as a historical snapshot, thereby improving the accuracy and reliability of the data; in addition, the first Internet Protocol address currently obtained by the resolution is compared with the target historical snapshot in the local disaster recovery database to quickly verify and / or correct the correctness of the first Internet Protocol address, without the direct cooperation of the domain name owner, and not subject to the response speed of the domain name owner, etc., thereby improving the response speed and flexibility of the system. In summary, the present application can ensure the accuracy of the resolution process while improving the speed of domain name resolution.

[0103] In some implementations, to ensure the security and consistency of domain name resolution, a local disaster recovery database may be established to detect and respond to potential resolution anomalies or security threats. For example, the domain name resolution method may further include:

[0104] (A.1) obtaining a plurality of preset domain names included in a preset list of re-protected domain names, and for each preset domain name, obtaining historical resolution log data generated when each preset domain name is resolved to obtain a corresponding Internet Protocol address at a first time step;

[0105] (A.2) For each preset domain name, input the corresponding historical parsing log data into the target model to obtain predicted parsing log data corresponding to the second time step of the historical parsing log data; wherein the first time step is located before the second time step;

[0106] (A.3) obtaining an expected log range set for each historical parsed log data, and comparing each predicted parsed log data with the corresponding expected log range to obtain a comparison result; wherein the expected log range includes at least one reference candidate event predicted to occur in the next time step of the predicted parsed log data;

[0107] (A.4) When the comparison result indicates that the predicted parsing log data is within the expected log range, the historical parsing log data is stored in the location of the corresponding preset domain name in the local disaster recovery database.

[0108] The preset domain name can be a pre-determined important domain name that requires special protection and detection. The preset domain name can be a key business service, government website, or enterprise portal, etc., and has strict requirements on the consistency and security of its resolution results.

[0109] The first time step may be the time step of the most recent resolution operation for the preset domain name. The first time step is not limited to a specific time, and the first time step corresponds to historical resolution log data collected by the system related to the actual resolution of the preset domain name to obtain the Internet Protocol address.

[0110] The second time step can be a time step that is subsequent to the first time step and is used to describe the time point of the predicted parsing log data. In other words, the historical parsing log data of the first time step is located before the predicted parsing log data of the second time step. The first time step and the second time step do not refer to specific times, but are mainly used to calibrate the order of the time steps.

[0111] A reference candidate event can be an event predicted to occur in the next time step of at least one predicted resolution log data item within the expected log range. This event can serve as a benchmark for determining whether the predicted resolution log data is reasonable. A reference candidate event can be a normal DNS query response, a specific type of record update (such as an A record or AAAA record), or any other behavior that may affect domain name resolution results.

[0112] Exemplarily, if the list of re-protected domain names includes two preset domain names, namely www.example.com and mail.example.com. Taking www.example.com as an example, at T1, www.example.com resolves to obtain the Internet Protocol address 192.0.2.1, and uses the parsing log data during the parsing process as the historical parsing log data of the first time step (T1). For example, the historical parsing log data may include information such as the parsing request, response time, and the Internet Protocol address obtained by parsing (such as 192.0.2.1). Exemplarily, the historical parsing log data may be: timestamp: 2024-12-10 10:00:00; parsing result (Internet Protocol address): 192.0.2.1; Time To Live (TTL) value: 3600 seconds; response time: 250 milliseconds; status code: NOERROR.

[0113] Furthermore, the expected log range may include multiple reference candidate events, that is, reference candidate events that reasonably develop historical parsed log data under normal circumstances. For example, the expected log range may include the following three reference candidate events:

[0114] IP address: 192.0.2.1, TTL value: 3550 seconds, response time: 240 milliseconds, status code: NOERROR;

[0115] IP address: 192.0.2.2, TTL value: 3600 seconds, response time: 260 milliseconds, status code: NOERROR;

[0116] IP address: 192.0.2.3, TTL value: 3650 seconds, response time: 270 milliseconds, status code: NOERROR;

[0117] Furthermore, through the target model, prediction is made based on the historical parsing log data, and the predicted parsing log data at the second time step can be: timestamp: 2024-12-10 10:05:00; predicted parsing result (IP address): 192.0.2.2; predicted TTL value: 3600 seconds; predicted response time: 260 milliseconds; predicted status code: NOERROR.

[0118] From this, it can be seen that the predicted and parsed log data completely matches the second reference candidate event in the expected log range. Therefore, the predicted and parsed log data is log data generated under normal conditions. From this, it can be seen that the historical parsed log data corresponding to the predicted and parsed log data is in the expected log range and is log data obtained by normal parsing. The historical parsed log data can be stored in the corresponding preset domain name in the local disaster recovery database.

[0119] In some embodiments, the reference candidate event may not specify a specific value, but rather a numerical range. For example, the predicted TTL value may be 3400 to 3600 seconds, and so on.

[0120] In some embodiments, the similarity between the predicted parsed log data and each reference candidate event in the expected log range can be calculated to determine whether the predicted parsed log data is generated according to a normal log generation trend. For example, the similarity between the predicted parsed log data and each reference candidate event can be calculated. When the similarity between the predicted parsed log data and at least one reference candidate event is greater than a similarity threshold, it can be determined that the predicted parsed log data is within the expected log range. Exemplarily, the similarity threshold can be set to 80%, 90%, etc., and is set according to actual circumstances.

[0121] In some embodiments, the similarity between the predictive parsed log data and each reference candidate event can be calculated using methods such as Euclidean distance, cosine similarity, etc. Furthermore, different similarity weights can be set for each log item. For example, a similarity weight of 30% can be set for the IP address, 30% for the TTL value, 20% for the response time, and 20% for the status code.

[0122] It is understandable that the above-mentioned parsed log data is only used as an example. In actual situations, historical parsed log data, predicted parsed log data, and reference candidate events can have many different forms, but the idea of ​​determining whether historical parsed log data is normal parsed log data is the same as above. Please refer to the above for details and will not go into details here.

[0123] Furthermore, when the predicted parsing log data is not within the expected log range, the historical parsing log data is determined to be abnormal parsing log data. At this time, the abnormal parsing log data can be discarded, or technical personnel can be notified to handle it; when the predicted parsing log data is within the expected log range, the corresponding historical parsing log data will be added to the local disaster recovery database.

[0124] In some embodiments, the local disaster recovery database has a rapid recovery mechanism. Specifically, when the main service fails (such as a local DNS server failure) or a domain name is tampered with, the target historical snapshot of the resolution that has been verified as correct can be used to quickly restore to the most recent reliable resolution state to ensure uninterrupted service. Further, the local disaster recovery database has a mechanism to prevent malicious tampering. Specifically, when it is detected that the first Internet Protocol address of the current resolution result is inconsistent with the second Internet Protocol address in the historical snapshot, the system can switch to the correct resolution result provided by the local disaster recovery database, that is, the second Internet Protocol address, after identifying the anomaly. Further, the local disaster recovery database can improve the consistency of the resolution. Even when the network environment changes, it can be compared based on the most recent trusted state, reducing the possibility of false positives due to environmental changes and ensuring the consistency and security of the resolution results. Further, the local disaster recovery database can enhance system stability by continuously monitoring and recording resolution logs and using machine learning models to predict future resolution behavior. Only when the predicted resolution log data does not deviate from the predefined expected log range will the corresponding historical resolution log data be saved as a snapshot, ensuring that the stored data are all verified normal data.

[0125] By obtaining the historical resolution log data of the preset protected domain name, and using the target model to predict the future resolution log data, and comparing it with the reference candidate events within the predefined expected log range, it can be ensured that only the historical resolution log data verified to be normal is saved to the local disaster recovery database, thereby improving the consistency and security of the domain name resolution results, enhancing the stability and reliability of the system, and providing a rapid recovery mechanism to deal with potential security threats and resolution anomalies.

[0126] In some implementations, to facilitate prediction of characters in subsequent predicted log parsing data, a sliding window can be set up to extract a sequence to be predicted from existing historical parsed log data. This allows contextual information to be obtained about the sequence after the current time step, allowing accurate prediction of the characters after the current time step. For example, (A.2) can include:

[0127] (A.2.1) For each preset domain name's historical parsing log data, extract the corresponding sequence to be predicted from the historical parsing log data at the current time step using a sliding window;

[0128] (A.2.2) Inputting the sequence to be predicted into the target model, generating a first hidden state vector of the sequence to be predicted using a first encoder in the target model in a forward time sequence, and generating a second hidden state vector of the sequence to be predicted using a second encoder in the target model in a reverse time sequence;

[0129] (A.2.3) predicting a predicted character for the next time step based on a fused hidden state vector of the first hidden state vector and the second hidden state vector by the decoder of the target model;

[0130] (A.2.4) Update the predicted character to the sequence to be predicted at the current time step, move the sliding window to update the sequence to be predicted at the next time step, input the sequence to be predicted at the current time step into the target model, and use the target model to predict the predicted character for the next time step based on the sequence to be predicted at the current time step;

[0131] (A.2.5) Repeat the steps of updating the predicted character to the sequence to be predicted at the current time step, moving the sliding window to update the sequence to be predicted at the current time step, inputting the sequence to be predicted at the current time step into the target model, and predicting the predicted character at the next time step based on the sequence to be predicted at the current time step by the target model, until the number of the updated plurality of predicted characters reaches a preset threshold number;

[0132] (A.2.6) Based on the multiple predicted characters, the predicted parsing log data corresponding to the second time step of the historical parsing log data is obtained.

[0133] The sliding window can be a fixed-size movable window that moves across the historical parsed log data, each time it moves one time step, i.e., one character. Each time a predicted character is predicted, the sliding window is slid to cover the predicted character and predict the next character after it. Specifically, the length of the sliding window can be preset based on actual circumstances, for example, a length of 5 characters, 10 characters, etc.

[0134] The current time step may be a time point for starting to predict a character, and subsequently the character of the next time step after the current time step needs to be predicted.

[0135] The sequence to be predicted can be a partial sequence extracted from historical parsed log data using a sliding window. To predict ungenerated log characters, the sequence to be predicted can be selected from the last segment of generated or predicted historical parsed log data. For example, if the historical parsed log data is binca.com and the character at the next time step needs to be predicted, and the sliding window length is 3, the sequence to be predicted could be com.

[0136] The target model can be a trained bidirectional long short-term memory network (Bi-directional Long Short-Term Memory, BiLSTM). The target model can capture the context information of the sequence to be predicted by introducing a first encoder (forward LSTM layer) and a second encoder (reverse LSTM layer) to more comprehensively understand the contextual relationship of the sequence to be predicted.

[0137] The first encoder may be a forward long short-term memory (LSTM) unit in the target model. The first encoder may process the sequence to be predicted in forward time order, i.e., starting from the first character of the sequence to be predicted, and processing one by one in time order until the last character of the sequence to be predicted. For each time step of the sequence to be predicted, the first encoder generates a hidden state vector in forward time order. The hidden state vector represents the information of the corresponding time step and is based on all information before the time step in the sequence to be predicted, until the first hidden state vector of the last time step of the sequence to be predicted is obtained. The first hidden state vector may contain information of multiple forward time steps of the entire sequence to be predicted.

[0138] The first hidden state vector may be a combination of hidden states consisting of multiple hidden states generated by the first encoder at multiple time steps of the sequence to be predicted. The first hidden state vector contains all information of the sequence to be predicted from the first time step to the last time step.

[0139] The second encoder can be a reverse LSTM long short-term memory (LSTM) unit in the target model. The first encoder can process the sequence to be predicted in reverse chronological order, that is, starting from the last character of the sequence to be predicted, and processing one by one in chronological order until the first character of the sequence to be predicted. For each time step of the sequence to be predicted, the first encoder generates a hidden state vector in reverse chronological order. The hidden state vector represents the information of the corresponding time step and is based on all information after the time step in the sequence to be predicted, until the second hidden state vector of the first time step of the sequence to be predicted is obtained. The second hidden state vector can contain information of multiple reverse time steps of the entire sequence to be predicted.

[0140] The second hidden state vector may be a combination of hidden states consisting of multiple hidden state vectors generated by the second encoder at multiple time steps of the sequence to be predicted. The second hidden state vector contains all information of the sequence to be predicted from the last time step to the first time step.

[0141] The fused hidden state vector may be a vector formed by concatenating the first hidden state vector and the second hidden state vector according to each time step in the target model.

[0142] The predicted character may be in the target model, and the decoder predicts the next character of the sequence to be predicted based on the fused hidden state vector.

[0143] For example, suppose that a historical parsing log data S=[s1,s2,...,s N ], the length of the sliding window is W. Further, if it is necessary to predict the character at the next time step i+W, a sequence to be predicted with a length of W can be extracted from the historical parsing log data S [s i ,s i+1 ,...,s i+w-1 ], the sequence to be predicted may include multiple characters, where i represents the starting position of the sliding window.

[0144] Input sequence: [s i ,s i+1 ,...,s i+w-1 ];

[0145] The goal is to predict the character at i+w: y i =s i+w ;

[0146] In some embodiments, the length of the sequence to be predicted captured by the sliding window can be adjusted based on sequence regularity. For example, if the sequence regularity indicates that the length of the main portion varies between 3 and 7 characters, and the top-level domain is typically .com, the sliding window length can be set to 7 characters plus the length of the top-level domain, or 11 characters. It will be appreciated that the selected sequence to be predicted should be able to fully convey the contextual information of the character to be predicted to accurately predict the character. Furthermore, the sequence to be predicted should not be too long, as this may affect the prediction process.

[0147] For example, let's say the sequence to be predicted is example.com. The target model's first encoder processes the sequence starting from the leftmost character, reading each character in turn. For the sequence "example.com," the first character processed is "e," then "x," and so on, until the last character, "m," is reached.

[0148] As the first encoder processes each character, it updates its internal state, generating a forward hidden state vector. When the first encoder completes processing the entire sequence to be predicted, the hidden state vector at the last time step contains the forward information about the sequence to be predicted, that is, all information from the start character to the end character. Subsequently, multiple forward hidden state vectors based on multiple time steps can be combined to form the first hidden state vector.

[0149] Furthermore, the target model's first encoder starts processing from the rightmost character of the sequence to be predicted, reading each character in turn. For the sequence to be predicted "example.com", the first character processed is "m", then "o", and so on, until the first character "e" is processed.

[0150] As the second encoder processes each character, it updates its internal state, generating a reverse hidden state vector. When the second encoder completes processing the entire sequence to be predicted, the hidden state vector at the first time step contains reverse information about the sequence to be predicted, i.e., all information from the end character to the start character. Subsequently, multiple reverse hidden state vectors from multiple time steps can be used to form the second hidden state vector.

[0151] Please refer to Figure 3 In some embodiments, combined Figure 3 The process of concatenating the first hidden state vector and the second hidden state vector to obtain the fused hidden state vector is given as an example. For example, if there is a sequence A to be predicted, in the process of predicting the predicted character of the next time step through the sequence to be predicted, the first hidden state vector is raeb and the corresponding forward cell state, and the second hidden state vector is bear and the corresponding reverse cell state (the cell state can be represented by LSTM Cell, for the specific direction of the cell state, please refer to Figure 3 ), a fused hidden state vector can be obtained by concatenating the first hidden state vector and the second hidden state vector, and concatenating the forward cell state and the reverse cell state. Specifically, the fused hidden state vector can be obtained by concatenating "r" and "b" and the corresponding cell state of the first time step, concatenating "a" and "e" and the corresponding cell state of the second time step, concatenating "e" and "a" and the corresponding cell state of the third time step, and concatenating "b" and "r" and the corresponding cell state of the fourth time step.

[0152] Furthermore, the decoder of the target model can predict the predicted character for the next time step based on the fused hidden state vector. The decoder usually uses a linear layer to convert the fused hidden state vector into a prediction distribution and then selects the character with the highest probability as the predicted character.

[0153] For example, please refer to Figure 4 The decoder usually uses a linear layer to convert the fused hidden state vector into a prediction distribution, and then selects the character with the highest probability as the predicted character. When predicting the sequence "192.0.2.1 3600", the predicted character for the next time step can be predicted as "N" based on the fused hidden state vector corresponding to the sequence to be predicted.

[0154] Please refer to Figure 4 Assume that the sequence to be predicted at the current time step is "192.0.2.1 3600." Based on the fused hidden state vector of "192.0.2.13600," the predicted character for the current time step is predicted to be "N." Furthermore, since the sliding window length is fixed, the predicted character "N" can be updated to the sequence to be predicted at the current time step, resulting in "192.0.2.1 3600N." The sliding window is then moved to obtain the sequence to be predicted at the next time step, "92.0.2.1 3600N." Furthermore, the target model predicts that the predicted character for the next time step will be "O."

[0155] Please refer to Figure 4 For example, if the sequence to be predicted corresponding to the current time step is "192.0.2.1 3600", and the predicted character for the next time step is predicted to be "N" based on the sequence to be predicted, "N" is updated to the sequence to be predicted for the current time step, resulting in "192.0.2.1 3600N". Furthermore, the sliding window is moved to update the sequence to be predicted for the current time step to "92.0.2.1 3600N". Based on "92.0.2.13600N", the predicted character for the next time step is predicted to be "O". "O" is updated to the sequence to be predicted for the current time step, resulting in "92.0.2.1 3600NO". Furthermore, the sliding window is moved to update the sequence to be predicted at the current time step to "2.0.2.1 3600NO", and the predicted character for the next time step is predicted to be "E" based on "2.0.2.1 3600NO", and the cycle is repeated until the number of the updated multiple predicted characters reaches the preset number threshold. Please refer to the above for the specific method of cyclically generating predicted characters, which will not be listed here one by one.

[0156] In some embodiments, the number of characters (or character length) of the sequence to be predicted can be determined according to actual conditions. For example, the character length of the sequence to be predicted can be 10, 20, 50, etc., as long as the prediction result can be ensured to be accurate. The embodiments of the present application do not make specific limitations on this.

[0157] Furthermore, the preset number threshold can be determined based on the volume of historical parsed log data corresponding to the time period to be predicted. For example, when the volume of historical parsed log data is small, a smaller preset number threshold can be set, such as 200, 300, etc.; when the volume of historical parsed log data is large, a larger preset number threshold can be set, such as 500, 1000, etc. The specific setting depends on the actual situation and is not specifically limited in the embodiments of this application.

[0158] In some embodiments, when the sequence to be predicted corresponding to the historical parsed log data corresponds to a first time step, and a prediction is required for the predicted parsed log data for a second time step, and the first time step is located before the second time step, the predicted character for the next time point can be repeatedly obtained until the updated predicted parsed log data no longer contains characters from the initial sequence to be predicted corresponding to the first time step, thereby obtaining multiple predicted characters corresponding to the second time step. Alternatively, until the number of characters in the updated predicted parsed log data reaches a preset number of log characters, such as 100, 500, etc., the generation of predicted characters can be stopped, and the predicted parsed log data for the second time step can be sequentially aggregated based on the multiple predicted characters.

[0159] In some embodiments, when the sequence to be predicted is based on a character conversion dictionary, and each log character is converted into a specific numerical character for the purpose of prediction, the sequence to be predicted in the above embodiment can be a sequence composed of numerical values. For example, "192.0.2.1 3600" can be converted into "19210.211036000" based on the character conversion dictionary (only as an example, the specific conversion rules need to refer to the character conversion dictionary). The prediction process and concept are the same as above. During the implementation process, please refer to the prediction process introduced above, which will not be repeated here.

[0160] By using a sliding window to dynamically extract the sequence to be predicted from historical parsing log data and adopting a bidirectional encoder structure, the hidden state vectors of the forward and reverse encoders can be integrated, enabling the model to fully capture and understand the contextual information of the sequence to be predicted, thereby better understanding the contextual relationship of the sequence, more accurately predicting the characters of the next time step, and generating accurate predicted parsing log sequences.

[0161] In some implementations, to improve the prediction accuracy and security of domain name resolution, characters in the log can be converted to numerical values ​​to standardize the data so that the target model can more effectively process and analyze the log information. For example, (A.2.1) can include:

[0162] (A.2.1.1) For each preset domain name's historical parsing log data, extract the corresponding log to be predicted from the historical parsing log data at the current time step using a sliding window;

[0163] (A.2.1.2) Obtaining a preset character conversion dictionary, and determining the conversion value corresponding to each character in the log to be predicted using the character conversion dictionary;

[0164] (A.2.1.3) Use each conversion value to replace the corresponding character in the log to be predicted to obtain the corresponding sequence to be predicted.

[0165] The character conversion dictionary can be a pre-set mapping table that converts characters in log files (such as domain names, IP addresses, and timestamps) into numerical representations. The character conversion dictionary's mapping relationships are fixed, meaning each specific character or character sequence has a unique numerical value. This allows non-numeric log information to be understood and processed by machine learning models.

[0166] The conversion value can be a numerical representation of each character in the log, determined using a character conversion dictionary. The conversion value encodes the original characters, facilitating mathematical operations and pattern recognition on a computer. This allows the target model to effectively learn features from the log data and make predictions.

[0167] For example, there is a preset domain name www.example.com, and its corresponding historical resolution log data at T1 is: timestamp: 2024-12-10 16:00:00; resolution result (IP address): 93.184.216.34; TTL value: 3600; response time: 6ms; status code: NOERROR.

[0168] In some embodiments, the preset character conversion dictionary may correspond to the following mapping relationships: Timestamp: convert the number of seconds into the number of seconds since a certain reference time point (such as the Unix epoch). IP address: convert each eight-bit byte into a numerical value. TTL value: use the numerical value directly. Response time: convert milliseconds into a numerical value. Status code: convert the status code into a specific numerical value (such as converting NOERROR to 0). It is understandable that other ways of converting the character conversion dictionary may also be set, and the embodiments of the present application do not impose specific restrictions on this.

[0169] For example, a sliding window can be used to intercept the corresponding log to be predicted: 2024-12-10 16:00:00, 93.184.216.34, 3600, 6ms, NOERROR. By searching the character conversion dictionary, the intercepted log to be predicted can be converted to: timestamp: 1702236000; IP address: 93,184,216,34; TTL value: 3600; response time: 6; status code: 0. Based on the above conversion values, the characters in the log to be predicted are replaced with the corresponding values ​​to form a sequence to be predicted, resulting in [1702236000, 93,184,216,34, 3600, 6, 0].

[0170] By converting raw text log data into a numerical sequence, the target model can use the sequence to predict the next time step of parsed log data. This numerical processing enables the model to more effectively learn and predict the generation trend of log data, thereby improving prediction accuracy and system security.

[0171] In some implementations, to improve the accuracy and interception efficiency of the target model in predicting parsed log data, a preset model can be trained to obtain a target model. This allows the trained target model to grasp the generation patterns of historical parsed log data, thereby accurately predicting the predicted parsed log data for subsequent time steps. For example, the target model can be trained in the following manner:

[0172] (B.1) Obtaining a sample sequence to be predicted corresponding to the sample historical parsing log data, and inputting the sample sequence to be predicted into a preset model to obtain multiple sample prediction probabilities corresponding to multiple sample prediction characters at subsequent sample time steps predicted by the preset model;

[0173] (B.2) Obtaining the true sample label character at the sample time step that is subsequent to the sample to be predicted sequence, and calculating the target loss of the preset model based on the true sample label character, the multiple sample prediction characters, and the corresponding multiple sample prediction probabilities;

[0174] (B.3) Train the preset model based on the target loss to obtain the target model.

[0175] The sample sequence to be predicted may be a sequence of sample characters contained in a sample sliding window of fixed length. Based on the sample sequence to be predicted, the sample characters of the sample prediction parsing log data following the sample sequence to be predicted may be predicted.

[0176] The preset model can be based on a BiLSTM model, which uses an encoder-decoder structure, where the encoder uses a BiLSTM network model and the decoder uses an LSTM layer and a fully connected layer. By training the preset model, a target model can be obtained.

[0177] The sample predicted character may be the character of the next sample time step predicted by a preset model based on the sample sequence to be predicted.

[0178] The sample prediction probability may be a probability value assigned by a preset model to each character in the index dictionary that may be a prediction result, and multiple probability values ​​constitute a probability distribution.

[0179] The true sample label character may be the character that actually appears in the next time step of the sample sequence to be predicted.

[0180] Among them, the target loss can be used to measure the difference between the probability distribution of the sample predicted characters output by the preset model and the real sample label characters. Exemplarily, the target loss can be a multivariate cross entropy loss.

[0181] In some embodiments, multiple sample sequences to be predicted can be obtained from a sample sequence through a sample sliding window, and predictions can be performed on the multiple sample sequences to be predicted. Based on the multiple sample prediction characters predicted for a sample sequence to be predicted each time and the corresponding multiple sample prediction probabilities, the target loss corresponding to the sample sequence to be predicted is calculated, and the parameters of the preset model are continuously adjusted accordingly to obtain a target model.

[0182] For example, if the sample sequence to be predicted is "exampleco", the input value of "exampleco" is preset in the model, and the preset model predicts the sample characters of the next sample time step of "exampleco". If the preset model predicts multiple characters of the next sample time step, they are "m", and the corresponding sample prediction probability is 0.6, ".", and the corresponding sample prediction probability is 0.2. The sample prediction probabilities of other characters are 0.2 in total, which will not be elaborated here.

[0183] Furthermore, the target loss of the preset model can be calculated based on the true sample label character, multiple sample predicted characters, and the corresponding multiple sample prediction probabilities. Specifically, the difference between each character and the true sample label character can be determined based on the multiple sample prediction probabilities, and the target loss can be determined based on the difference. For example, if "m" is the correct character for the next sample time step, the target loss will be low; otherwise, the target loss will be high.

[0184] Furthermore, the preset model can be trained using multiple sample sequences to be predicted until the preset model reaches a convergence condition, and a target model can be obtained. The convergence condition can be that the number of times the preset model is trained reaches a preset number of training times, for example, the preset number of training times can be 500 times. When the number of times the preset model is trained reaches 500 times, the training of the preset model can be stopped to obtain the target model. The preset number of training times can be adjusted according to actual conditions. Alternatively, the convergence condition can also be that the number of times the target loss is continuously lower than a preset threshold exceeds the target number of times, for example, the target number of times is 10 times. When the number of times the target loss is continuously lower than the preset threshold exceeds 10 times, the training of the preset model can be stopped to obtain the target model.

[0185] By training the preset model and continuously adjusting the model parameters to obtain the target model, the target model can make advance predictions on the predicted parsing log data for future time periods, thereby improving the accuracy of the predicted parsing log data.

[0186] In some embodiments, in order to effectively quantify the difference between the sample predicted characters and the true sample label characters, a first sub-loss between each sample predicted character and the true sample label character can be calculated, so as to calculate the target loss of the target model based on multiple first sub-losses, so that the model can better learn the mapping relationship between input and output, thereby improving the accuracy of prediction. For example, (B.2) may include:

[0187] (B.2.1) for each sample predicted character, determining a sample prediction probability corresponding to the sample predicted character;

[0188] (B.2.2) Determine the first sub-loss corresponding to the corresponding sample prediction character based on the sample prediction probability and the true sample label character;

[0189] (B.2.3) Determine the target loss of the preset model based on multiple first sub-losses corresponding to the characters predicted by multiple samples.

[0190] The first sub-loss may be a quantified value of the difference between the predicted character of each sample and the true sample label character at the next time step of the corresponding sample sequence to be predicted.

[0191] For example, a multivariate cross entropy function can be used to calculate the target loss of the preset model when predicting the sample sequence to be predicted. Specifically, the fully connected layer in the preset model can receive the output from the decoder, and the sample fusion hidden state vector corresponding to the sample sequence to be predicted is subjected to a linear transformation and a Softmax activation function to generate the sample prediction probability of the target character category in all character indexes. All character indexes are index dictionaries composed of all sample characters that have appeared in the input sample training set, and the sample prediction probability distribution corresponding to multiple sample prediction characters is generated.

[0192] Among them, the output y of the fully connected layer t The mathematical expression is as follows:

[0193] y t =W fc h t +b fc ;

[0194] Among them, W fc is the weight matrix of the fully connected layer, h t is the sample fusion hidden state vector, b fc is the bias of the fully connected layer.

[0195] Specifically, the output y of the fully connected layer is converted into t Convert to sample prediction probability distribution The formula is as follows:

[0196]

[0197] Among them, t represents the sample time step, K represents the type of character index, and num_class represents the number of types of character index.

[0198] Furthermore, the target loss of the preset model can be calculated based on the sample prediction probability distribution. The specific formula for calculating the target loss LossL is as follows:

[0199]

[0200] Among them, n is the total number of sample prediction characters, d i is the one-hot encoding of the real sample label character, It is the sample prediction probability of the i-th sample prediction character among multiple sample prediction characters output by the preset model.

[0201] For example, if the true sample label character is "b", and the sample prediction probability distribution predicted by the preset model is P("a") = 0.2, P("b") = 0.5, P("c") = 0.3, then for the next sample time step, the first sub-loss of "a" and the first sub-loss of "c" are both 0, and the first sub-loss of "b" is -log(P("b")) = -log(0.5).

[0202] Furthermore, by summing the multiple first sub-losses corresponding to the predicted characters of the multiple samples, the target loss of the preset model can be obtained. The preset model can use the target loss as a target and adjust the model parameters through optimization algorithms such as gradient descent to gradually reduce the target loss, thereby making the preset model's prediction of the sample sequence to be predicted increasingly close to the actual sample label character.

[0203] By training the preset model by minimizing the target loss, the preset model can be forced to continuously learn the rules of the sample sequence to be predicted during the training process, and more accurately learn the mapping relationship between input data and output labels, so as to improve the prediction performance of the preset model, facilitate accurate prediction of the sample characters in the next sample time step, and thus achieve accurate prediction of the prediction and parsing log data.

[0204] In some implementations, to ensure that the resolution log data in the local disaster recovery database remains up-to-date and accurate, historical data in the area to be updated can be accurately located and overwritten to maintain data consistency and timeliness, thereby improving the security, stability, and reliability of domain name resolution and optimizing storage resource utilization. For example, the domain name resolution method may also include:

[0205] (C.1) When a historical snapshot of a preset domain name is updated in the local disaster recovery database, determine the area to be updated corresponding to the updated historical snapshot;

[0206] (C.2) In the local disaster recovery database, the historical snapshot in the area to be updated is overwritten based on the updated historical snapshot.

[0207] The area to be updated may be a specific part or range in the local disaster recovery database that needs to be updated according to the latest parsed log data.

[0208] For example, if the preset domain name is www.example.com, its historical resolution log data generates a snapshot at time T1 and is saved in the local disaster recovery database, and the resolution result is the IP address 93.184.216.34. Some time later, at time T2, due to factors such as changes in network configuration, the correct resolution result of www.example.com is changed to 93.184.216.35. After the system detects that the resolution log data of www.example.com has been updated normally, it can generate a new historical snapshot. At this time, it can be determined that the historical snapshot is in the area to be updated in the local disaster recovery database, and in the area to be updated, the original historical snapshot in the area to be updated is overwritten by the updated historical snapshot to quickly respond to changes in the network environment.

[0209] Through the above methods, not only the stability of the system and the reliability of data are enhanced, but also the security and consistency of domain name resolution are improved, ensuring that users can access the expected services.

[0210] Please refer to Figure 5 In some embodiments, combined Figure 5 The overall technical solution of this application is introduced.

[0211] Exemplarily, a log processing program can be run in a computer device, and the log processing program can detect in real time the dynamic changes in the resolution log data of each preset domain name in the re-protected domain name list. When the log processing program detects that the resolution log data of any preset domain name is updated, the historical resolution log data can be predicted using the target model to obtain the predicted resolution log data for the corresponding preset domain name. Furthermore, when the predicted resolution log data is determined to be abnormal, it is filtered; when the predicted resolution log data is determined to be normal, the historical resolution log snapshot corresponding to the predicted resolution log data can be stored in the local disaster recovery database, thereby realizing the storage of each preset domain name in the local disaster recovery database.

[0212] In some embodiments, when resolving a domain name to be resolved, taking the domain name to be resolved as www.example.com as an example, when the terminal sends a domain name resolution request for any preset domain name in the list of re-protected domain names, the local disaster recovery backup system server can send the domain name resolution request to the local DNS server, and the local DNS server can send a request to the root DNS server to inquire about the top-level domain name server responsible for the .com top-level domain name. After that, the root DNS server returns the address of the top-level domain name server responsible for .com. The local DNS server then sends a request to the top-level domain name server, and the top-level domain name server returns the address of the authoritative DNS server responsible for the example.com domain. The local DNS server then sends a request to the authoritative DNS server based on the address of the authoritative DNS server. In this way, after receiving the request, the authoritative DNS server can find the first Internet Protocol address corresponding to www.example.com and return the first Internet Protocol address to the local DNS server. Furthermore, the local DNS server can call the target historical snapshot corresponding to www.example.com in the local disaster recovery database, and extract the second Internet Protocol address of www.example.com from the target historical snapshot. When the first Internet Protocol address and the second Internet Protocol address are consistent, it indicates that the resolution result of www.example.com has not been tampered with, and the first Internet Protocol address can be used as the domain name resolution result of www.example.com; or, obtain the cached Internet Protocol address from the local storage, compare the first Internet Protocol address and the cached Internet Protocol address. When the first Internet Protocol address and the cached Internet Protocol address are inconsistent, obtain the second Internet Protocol address from the local disaster recovery database, and use the second Internet Protocol address as the domain name resolution result of the domain name to be resolved.

[0213] When the first Internet Protocol address and the second Internet Protocol address are inconsistent, it indicates that the resolution result of www.example.com has been tampered with by an attacker, or the resolution result is incorrect due to other factors. At this time, the correct second Internet Protocol address can be obtained through the local disaster recovery database as the domain name resolution result of www.example.com, and an alarm can be issued to remind you of the abnormal comparison, so that the system can automatically protect itself.

[0214] See also Figure 6 The embodiment of the present application further provides a domain name resolution device that can implement the above domain name resolution method. The domain name resolution device includes:

[0215] A response module 61 is configured to respond to a domain name resolution request and resolve the domain name to be resolved included in the domain name resolution request to obtain a corresponding first Internet Protocol address;

[0216] A first determination module 62 is configured to determine, from a local disaster recovery database, a target historical snapshot corresponding to the domain name to be resolved at a previous historical time step; wherein the target historical snapshot is a snapshot of the historical resolution log data when the predicted resolution log data at the second time step does not deviate from the expected log range; the predicted resolution log data is predicted using a target model based on the historical resolution log data generated when the domain name to be resolved was resolved to obtain an Internet Protocol address at the first time step; the first time step is located before the second time step;

[0217] An extraction module 63 is configured to extract, from the target historical snapshot, a second Internet Protocol address obtained by resolving the domain name to be resolved at a previous historical time step, and compare the first Internet Protocol address with the second Internet Protocol address to obtain a comparison result;

[0218] The second determining module 66 is configured to determine the second Internet Protocol address as a domain name resolution result of the domain name to be resolved when the comparison result indicates that the first Internet Protocol address and the second Internet Protocol address are inconsistent.

[0219] The specific implementation of the domain name resolution device is basically the same as the specific embodiment of the domain name resolution method described above, and will not be repeated here. Under the premise of meeting the requirements of the embodiment of this application, the domain name resolution device can also be provided with other functional modules to implement the domain name resolution method in the above embodiment.

[0220] The present application also provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the above-described domain name resolution method when executing the computer program. The computer device can be any intelligent terminal, including a tablet computer and an in-vehicle computer.

[0221] See also Figure 7 , Figure 7 The hardware structure of a computer device according to another embodiment is shown. The computer device includes:

[0222] The processor 71 may be implemented as a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0223] The memory 72 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 72 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program codes are stored in the memory 72 and are called by the processor 71 to execute the domain name resolution method of the embodiments of this application.

[0224] Input / output interface 73, used for information input and output;

[0225] Communication interface 74, used to implement communication interaction between this device and other devices, which can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WiFi, Bluetooth, etc.);

[0226] bus 77 , which transmits information between the various components of the device (e.g., processor 71 , memory 72 , input / output interface 73 , and communication interface 74 );

[0227] The processor 71 , the memory 72 , the input / output interface 73 and the communication interface 74 are connected to each other in communication within the device via a bus 77 .

[0228] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the above-mentioned domain name resolution method is implemented.

[0229] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely arranged relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0230] The embodiments described in the embodiments of this application are intended to more clearly illustrate the technical solutions of the embodiments of this application and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0231] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than shown in the figures, or a combination of certain steps, or different steps.

[0232] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, i.e., they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of this embodiment.

[0233] Those skilled in the art will appreciate that all or some of the steps in the methods, systems, and functional modules / units in the devices disclosed above may be implemented as software, firmware, hardware, or appropriate combinations thereof.

[0234] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0235] It should be understood that in this application, "at least one (item)" and "several" refer to one or more, and "plurality" refers to two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0236] In the several embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For example, the division of the above units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0237] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0238] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0239] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes multiple instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of various embodiments of the present application. The aforementioned storage medium includes: various media that can store programs, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0240] The preferred embodiments of the present invention are described above with reference to the accompanying drawings, but are not intended to limit the scope of the present invention. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and essence of the present invention should be within the scope of the present invention.

Claims

1. A domain name resolution method, characterized in that: The method comprises: In response to the domain name resolution request, resolving the domain name to be resolved included in the domain name resolution request to obtain a corresponding first Internet Protocol address; Determine the target historical snapshot corresponding to the domain name to be resolved at the previous historical time step from the local disaster recovery database; The target historical snapshot is snapshot data of the historical parsing log data when the predicted parsing log data at the second time step does not deviate from the expected log range; the predicted parsing log data is predicted by the target model based on the historical parsing log data generated when the domain name to be resolved is parsed to obtain the Internet Protocol address at the first time step; the first time step is located before the second time step; extracting, from the target historical snapshot, a second Internet Protocol address obtained by resolving the domain name to be resolved at the previous historical time step, and comparing the first Internet Protocol address with the second Internet Protocol address to obtain a comparison result; When the comparison result indicates that the first Internet Protocol address and the second Internet Protocol address are inconsistent, the second Internet Protocol address is determined as the domain name resolution result of the domain name to be resolved.

2. The domain name resolution method according to claim 1, wherein: The method further comprises: Obtaining a plurality of preset domain names included in a preset re-protected domain name list, and obtaining, for each preset domain name, historical resolution log data generated when each preset domain name was resolved at a first time step to obtain a corresponding Internet Protocol address; wherein the re-protected domain name list is used to store a plurality of preset domain names, and the preset domain names are predetermined important domain names that require special protection and detection; For each of the preset domain names, the corresponding historical parsing log data is input into the target model to obtain predicted parsing log data corresponding to a second time step of the historical parsing log data; wherein the first time step is located before the second time step; Obtaining an expected log range set for each of the historical parsed log data, and comparing each of the predicted parsed log data with the corresponding expected log range to obtain a comparison result; wherein the expected log range includes at least one reference candidate event predicted to occur in the next time step by the predicted parsed log data; When the comparison result indicates that the predicted parsing log data is within the expected log range, the historical parsing log data is stored in a location of the corresponding preset domain name in the local disaster recovery database.

3. The domain name resolution method according to claim 2, wherein: For each of the preset domain names, inputting the corresponding historical parsing log data into the target model to obtain predicted parsing log data corresponding to the second time step of the historical parsing log data includes: For the historical parsing log data of each preset domain name, intercepting a corresponding sequence to be predicted from the historical parsing log data at the current time step through a sliding window; Inputting the sequence to be predicted into a target model, and generating a first hidden state vector of the sequence to be predicted by a first encoder in the target model in a forward time sequence, and generating a second hidden state vector of the sequence to be predicted by a second encoder in the target model in a reverse time sequence; Predicting, by a decoder of the target model, a predicted character for the next time step based on a fused hidden state vector of the first hidden state vector and the second hidden state vector; Updating the predicted character to the sequence to be predicted at the current time step, moving the sliding window to update the sequence to be predicted at the next time step, inputting the sequence to be predicted at the current time step into the target model, and predicting the predicted character at the next time step based on the sequence to be predicted at the current time step by the target model; Repeating the steps of updating the predicted character to the sequence to be predicted at the current time step, moving the sliding window to update the sequence to be predicted at the current time step, inputting the sequence to be predicted at the current time step into the target model, and predicting the predicted character at the next time step based on the sequence to be predicted at the current time step by the target model, until the number of the updated plurality of predicted characters reaches a preset number threshold; Based on the multiple predicted characters, the predicted parsing log data of the historical parsing log data corresponding to the second time step is obtained.

4. The domain name resolution method according to claim 3, wherein: The historical parsing log data for each preset domain name, intercepting a corresponding sequence to be predicted from the historical parsing log data at the current time step through a sliding window, includes: For the historical parsing log data of each preset domain name, intercepting the corresponding log to be predicted from the historical parsing log data at the current time step through a sliding window; Obtaining a preset character conversion dictionary, and determining a conversion value corresponding to each character in the log to be predicted using the character conversion dictionary; The corresponding characters in the log to be predicted are replaced by each conversion value to obtain the corresponding sequence to be predicted.

5. The domain name resolution method according to claim 1, wherein: The target model is trained in the following way: Obtaining a sample sequence to be predicted corresponding to sample history parsing log data, and inputting the sample sequence to be predicted into a preset model to obtain a plurality of sample prediction probabilities corresponding to a plurality of sample prediction characters predicted by the preset model at subsequent sample time steps of the sample sequence to be predicted; Obtaining a true sample label character at a sample time step subsequent to the sample to be predicted sequence, and calculating the target loss of the preset model based on the true sample label character, the plurality of sample prediction characters, and the corresponding plurality of sample prediction probabilities; The preset model is trained based on the target loss to obtain a target model.

6. The domain name resolution method according to claim 5, characterized in that: The calculating the target loss of the preset model based on the real sample label character, the multiple sample prediction characters, and the corresponding multiple sample prediction probabilities includes: For each of the sample predicted characters, determining a sample prediction probability corresponding to the sample predicted character; Determine a first sub-loss corresponding to the corresponding sample prediction character according to the sample prediction probability and the true sample label character; The target loss of the preset model is determined according to the multiple first sub-losses corresponding to the multiple sample prediction characters.

7. The domain name resolution method according to claim 1, wherein: The method further comprises: When there is a historical snapshot update of a preset domain name in the local disaster recovery database, determining a to-be-updated area corresponding to the updated historical snapshot; In the local disaster recovery database, the historical snapshot in the area to be updated is overwritten based on the updated historical snapshot.

8. A domain name resolution device, characterized in that: The device comprises: a response module, configured to, in response to a domain name resolution request, resolve the domain name to be resolved contained in the domain name resolution request to obtain a corresponding first Internet Protocol address; A first determination module is configured to determine, from a local disaster recovery database, a target historical snapshot corresponding to the domain name to be resolved at a previous historical time step; wherein the target historical snapshot is snapshot data of historical resolution log data when the predicted resolution log data at the second time step does not deviate from an expected log range; the predicted resolution log data is predicted using a target model based on historical resolution log data generated when the domain name to be resolved obtains an Internet Protocol address at the first time step; and the first time step is located before the second time step. an extraction module, configured to extract, from the target historical snapshot, a second Internet Protocol address obtained by resolving the domain name to be resolved at the previous historical time step, and compare the first Internet Protocol address with the second Internet Protocol address to obtain a comparison result; The second determining module is configured to determine the second Internet Protocol address as a domain name resolution result of the domain name to be resolved when the comparison result indicates that the first Internet Protocol address and the second Internet Protocol address are inconsistent.

9. A computer device, characterized in that: The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the domain name resolution method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the domain name resolution method according to any one of claims 1 to 7 is implemented.

Images