Predictive dns caching for improved security and performance

Abstract

Methods, systems, and computer systems for predicting responses to DNS queries are disclosed. The method includes receiving, from a client device, a DNS query comprising a subdomain portion and a root domain portion; determining whether to obtain target address information corresponding to the DNS from a predictive cache; responsive to determining to obtain the target address information from the predictive cache, obtaining the target address information from the predictive cache; and providing the target address information to the client device.

Description

Background Technology

[0001] Unethical individuals attempt to compromise computer systems in various ways. As an example, such individuals may embed or otherwise include malicious software (“malicious software”) in email attachments and transmit (or cause malicious software to be transmitted) to unsuspecting users. When executed, the malicious software harms the victim's computer. Some types of malicious software instruct the compromised computer to communicate with a remote host. For example, malicious software can turn a compromised computer into a “zombie” in a “botnet,” receiving instructions from and / or reporting data to a command and control (C&C) server under the control of an unethical individual. One way to mitigate the harm caused by malicious software is for security companies (or other appropriate entities) to attempt to identify the malicious software and prevent it from reaching / executing on the end-user's computer. Another approach is to attempt to prevent the compromised computer from communicating with a C&C server. Unfortunately, malicious software authors are using increasingly sophisticated techniques to obfuscate how their software works. As an example, some types of malicious software use Domain Name System (DNS) queries to leak data. Therefore, there is a continuous need for improved techniques to detect malicious software and prevent its harm. Attached Figure Description

[0002] Various embodiments of the present invention are disclosed in the following detailed description and accompanying drawings.

[0003] Figure 1 The illustration shows an example of an environment where malware was detected or suspected and its harm was mitigated.

[0004] Figure 2 This is a block diagram of a system for providing predicted addresses according to various embodiments of this application.

[0005] Figure 3 This is a diagram illustrating a system that uses predictive caching in response to Domain Name System (DNS) queries.

[0006] Figure 4 This is a diagram used to determine a system that uses predictive caching in response to DNS queries.

[0007] Figure 5 This is a diagram of a system used to respond to DNS queries.

[0008] Figure 6 This is a flowchart of a method for using predictive caching in response to DNS queries.

[0009] Figure 7 This is a flowchart of a method for using predictive caching in response to DNS queries.

[0010] Figure 8 This is a flowchart of a method for determining the target address information corresponding to a DNS query.

[0011] Figure 9 It is a flowchart of a method for determining a machine learning model to predict the record structure associated with a domain. Detailed Implementation

[0012] This invention can be implemented in many ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer-readable storage medium; and / or a processor, such as a processor configured to execute instructions stored on and / or provided by memory coupled to the processor. In this specification, these embodiments or any other form of the invention may take may be referred to as technology. Generally, the order of steps of the disclosed processes may be changed within the scope of this invention. Unless otherwise stated, components such as processors or memory described as being configured to perform a task may be implemented as general components temporarily configured to perform that task at a given time, or manufactured as specific components to perform that task. As used herein, the term "processor" refers to one or more devices, circuits, and / or processing cores configured to process data, such as computer program instructions.

[0013] The following provides a detailed description of one or more embodiments of the present invention, together with accompanying drawings illustrating the principles of the invention. The invention has been described in conjunction with such embodiments, but the invention is not limited to any particular embodiment. The scope of the invention is limited only by the claims, and the invention covers many alternatives, modifications, and equivalents. To provide a thorough understanding of the invention, numerous specific details are set forth in the following description. These details are provided for illustrative purposes, and the invention can be practiced according to the claims without requiring some or all of these specific details. For clarity, technical materials known in the art related to the invention have not been described in detail so as not to unnecessarily obscure the invention.

[0014] A system for predicting target address information in response to a Domain Name System (DNS) query is disclosed. The system includes one or more processors and a memory. The one or more processors are configured to: receive a DNS query; determine, in response to determining whether to obtain target address information from a predictive cache, whether to obtain target address information corresponding to the DNS query from the predictive cache; obtain the target address information from the predictive cache; and provide the target address information to a client device.

[0015] Because most networks generally allow DNS traffic and do not provide secure controls over it, DNS tunneling is a common method for attackers to conduct data breaches. Controlling DNS traffic is difficult because most DNS traffic is generally benign, and DNS traffic patterns are diverse. For example, systems generally do not provide mechanisms to prevent malicious slow tunneling, such as using many queries, each including a small amount of malicious information (e.g., about 1 byte), but which collectively provides a lot of malicious information. Queries from malicious clients (e.g., infected clients) are generally transmitted in an encoded stream. Furthermore, the address information in response to the query is usually not stored in a traditional cache, and in response to the determination that a traditional cache does not store such address information, the data is forwarded to the authoritative name server. Forwarding malicious traffic to the authoritative name server is generally the intention of the malicious party behind the attack. Conversely, benign clients transmitting DNS queries do not care how the response information is generated or where such information comes from. Instead, benign clients simply expect a timely response including accurate address information (e.g., IP address). Various embodiments implement predictive caching that estimates / predicts information in response to DNS queries, thereby limiting or eliminating the need to query authoritative name servers to resolve address information for DNS queries. Therefore, using predictive caching prevents malicious traffic from being forwarded to authoritative name servers and provides timely and accurate information in response to benign DNS queries.

[0016] According to various embodiments, systems and / or methods are provided for determining a response to a DNS query. In some embodiments, the system uses a predictive cache to determine a response to a received DNS query. For example, the system determines target address information (e.g., address information estimated in response to a DNS query) without accessing (e.g., querying) an authoritative name server (e.g., aDNS) for the domain included in the DNS query. In response to determining that a predictive cache should be used instead of a conventional cache or a query to an authoritative name server to generate a response to a DNS query (e.g., to estimate address information in response to a DNS query), the predictive cache determines the target address information corresponding to the DNS query. In some embodiments, the predictive cache stores predicted address information (e.g., predicted subdomains for various domains). In some embodiments, the predictive cache determines the target address information (e.g., predicted address information in response to a DNS query) concurrently with a DNS request. For example, in response to determining that the predictive cache should be used in conjunction with generating a response to a DNS query, the predictive cache obtains one or more records associated with the domain included in the DNS query, provides one or more records to a model (e.g., a machine learning model), and obtains (e.g., determines) the target address information corresponding to the DNS query. As an example, the target address information includes estimated address information for a specific domain included in a DNS query. In some embodiments, one or more records associated with a domain are records of multiple subdomains related to a specific top-level domain (such as the top-level domain of the domain included in a DNS query).

[0017] In some embodiments, the system obtains one or more records associated with a domain included in a DNS query, at least in part, based on determining a set of domains associated with a top-level domain corresponding to a domain included in a DNS query. As an example, determining the set of domains associated with a top-level domain includes determining a set of domains that are lexically similar to a particular domain. For example, if the particular domain is “abc.root.com”, the set of domains could be determined to include “dbc.root.com”, “aec.root.com”, etc. In response to determining the set of domains, the system queries an authoritative name server for address information related to the set of domains. As an example, a domain is considered similar to a particular domain (e.g., lexically similar) based on the determination (e.g., calculation) of a value indicating similarity and the determination that the value indicating similarity is greater than a predefined similarity threshold. In response to receiving address information related to the set of domains (e.g., from aDNS), the system uses such address information to predict target address information for the domain included in the DNS query. For example, the system provides the address information of the set of domains to a model (e.g., a machine learning model) and uses the model to estimate the address information in response to the DNS query. As an example, the model uses relationships and / or patterns of address information in the domain set and / or training set to estimate address information in response to DNS queries.

[0018] Various embodiments determine whether to use a predictive cache in conjunction with DNS queries, at least in part, based on the determination that a DNS query corresponds to suspicious traffic (e.g., the DNS query is suspicious or the device from which it receives the DNS query is suspicious). In some embodiments, the system uses a detector module to detect (e.g., determine) whether a DNS query is suspicious. For example, the detector module performs real-time detection of whether traffic is suspicious. Examples of systems, methods, and / or devices used in conjunction with analyzing traffic and / or determining whether traffic is suspicious are provided in U.S. Patent Application No. 16 / 799655, corresponding to U.S. Patent Application Publication No. 2021 / 0266293. U.S. Patent Application No. 16 / 799655 is incorporated herein by reference in its entirety. According to various embodiments, in response to the determination that traffic (e.g., a DNS query) corresponds to suspicious traffic, the system determines to use a predictive cache in conjunction with determining destination address information (address information in response to the DNS query). Conversely, in response to the determination that traffic does not correspond to suspicious traffic, the system determines to use a conventional cache or query the corresponding destination address information from an applicable authority. In some embodiments, the detector module is configurable. For example, administrators can configure the detector module based on desired sensitivity or in response to the determination that unwanted traffic levels are incorrectly identified as suspicious traffic (e.g., the percentage of genuine traffic identified as suspicious exceeds a traffic threshold).

[0019] According to various embodiments, a system and / or method are provided for using a model (e.g., a machine learning model) to estimate (e.g., predict) the structure of domain and / or target address information in response to a DNS query. For example, a predictive cache may incorporate the determination of target address information to implement the machine learning model. Various machine learning procedures can be used to train the model. Examples of machine learning procedures that can be incorporated into training the model include random forests, linear regression, support vector machines, Naive Bayes, logistic regression, K-nearest neighbors, decision trees, gradient-boosted decision trees, K-means clustering, hierarchical clustering, density-based noisy applied spatial clustering (DBSCAN), principal component analysis, etc. In some embodiments, a training domain set is used to train the model incorporating address information of the estimated domain. The training domain set may be pre-selected. For example, the training domain set may include a set of pre-selected domains considered benign (e.g., google.com, etc.). According to various embodiments, using a model to estimate address information includes obtaining records of subdomains of the domain associated with a DNS query (e.g., the top-level domain of the specific domain being queried), obtaining records of a training set of domains (e.g., records of the top-level domain and one or more subdomains), querying the corresponding authoritative name server for a list of similar domains or subdomains related to the specific domain included in the DNS query, and using a machine learning process to generate a model to estimate address information in response to the DNS query (e.g., determining target address information). In some embodiments, the model is implemented on a remote server. For example, one or more remote servers implement a machine learning model serving one or more predictive caches. In response to determining an estimate of the address information of a domain to be generated using the model, the predictive cache may query the estimate (e.g., predicted address information of the domain) from the remote server (e.g., on which the machine learning model is implemented).

[0020] Predictive caching can be implemented in various locations on a network. For example, a predictive cache can be deployed on a DNS resolver. As another example, a predictive cache can be deployed on a firewall. As yet another example, a predictive cache is a service provided to a DNS resolver (e.g., a predictive cache is deployed on a remote server that serves queries for predicted address information for a domain from the DNS resolver).

[0021] This system improves the handling of DNS traffic (e.g., responding to DNS traffic) by preventing (or improving the prevention of) malicious traffic from being sent to authoritative name servers. Additionally, the system can provide accurate and low-latency responses to benign DNS traffic. Therefore, the system prevents the spread of malicious traffic while providing genuine traffic with the same or better service level (e.g., if the predictive cache stores the target information for DNS queries, there is no need to query the authoritative name server).

[0022] Figure 1 The illustration depicts an example of an environment in which malware is detected or suspected and its harm is mitigated. In the example shown, client devices 104-108 are, respectively, laptops, desktop computers, and tablets present in corporate network 110 (belonging to "Acme Corporation"). Data appliance 102 is configured to implement policies regarding communication between client devices (such as client devices 104 and 106) and nodes outside corporate network 110 (e.g., reachable via external network 118). Examples of such policies include policies managing traffic shaping, quality of service, and traffic routing. Other examples of policies include security policies such as requiring the scanning of incoming (and / or outgoing) email attachments, website content, files exchanged via instant messaging programs, and / or other file transfers for threats. In some embodiments, data appliance 102 is also configured to implement policies regarding traffic residing within corporate network 110.

[0023] Data appliance 102 can be configured to work in conjunction with a remote security platform 140. Security platform 140 can provide various services, including performing static and dynamic analysis on malware samples and providing data appliances such as data appliance 102 with a list of signed known malicious files as part of a subscription. In various embodiments, the results of the analysis (along with additional information related to applications, domains, etc.) are stored in a database 160. In various embodiments, security platform 140 includes one or more dedicated commercially available hardware servers (e.g., having one or more multi-core processors, 32GB+ of RAM, one or more gigabyte network interface adapters, and one or more hard drives) running a typical server-class operating system (e.g., Linux). Security platform 140 can be implemented across a scalable infrastructure including multiple such servers, solid-state drives, and / or other suitable high-performance hardware. Security platform 140 can include several distributed components, including components provided by one or more third parties. For example, portions or all of security platform 140 can be implemented using Amazon Elastic Compute Cloud (EC2) and / or Amazon Simple Storage Service (S3). Additionally, as with data appliance 102, whenever security platform 140 is referred to perform a task such as storing or processing data, it should be understood that one or more sub-components of security platform 140 (either individually or in collaboration with third-party components) may collaborate to perform that task. As an example, security platform 140 may optionally collaborate with one or more virtual machine (VM) servers to perform static / dynamic analysis. Examples of VM servers are physical machines comprising commercially available server-class hardware (e.g., multi-core processors, 32+ gigabytes of RAM, and one or more gigabit network interface adapters) running commercially available virtualization software such as VMware ESXi, Citrix XenServer, or Microsoft Hyper-V. In some embodiments, the VM server is omitted. Furthermore, the VM server may be under the control of the same entity managing security platform 140, but may also be provided by a third party. As an example, the VM server may rely on EC2, where the remainder of security platform 140 is owned by the operator of security platform 140 and provided by dedicated hardware under the control of the operator of security platform 140.

[0024] According to various embodiments, the security platform 140 includes a DNS tunnel detector 138 and / or a predictive cache 170. In some embodiments, the predictive cache includes one or more of a detector module 172, a prediction engine 174, a machine learning (ML) model 176, and / or a cache 178.

[0025] The detector module 172 is used in conjunction with determining whether to use a predictive cache in conjunction with a DNS query. In some embodiments, the detector module determines whether to obtain a predicted address in response to a DNS query based at least in part on the determination that a DNS query corresponds to suspicious traffic. As an example, the detector module 172 uses information obtained from a DNS tunnel detector in conjunction with the determination that a DNS query corresponds to suspicious traffic. In some embodiments, the detector module 172 determines whether to obtain a predicted address in response to a DNS query based at least in part on a latency setting corresponding to the DNS traffic. The latency setting may be configurable based at least in part on the profile of the user or organization handling the DNS traffic (e.g., the latency setting for a customer may be set at least in part based on the service level to be provided to / contracted with the customer). In embodiments with low latency in response to a DNS query, the predictive cache may then determine to obtain a predicted address (e.g., target address information) in response to a determination that the conventional cache does not store target address information. In response to the determination that the conventional cache does not store target address information, the detector module determines whether the target address information is a previously determined predicted address and / or stored in the predictive cache (e.g., in cache 178). In response to determining that the target address information was not previously determined and / or stored in the predictive cache, detector module 172 determines to obtain the target address information based on the address predicted in response to a DNS query (e.g., using a machine learning model). For example, detector module 172 predicts the address in response to a DNS query request prediction engine 174. Conversely, in response to determining that the target address information was previously determined by and / or stored in the predictive cache, the previously determined predicted address is used as the target address information.

[0026] Prediction engine 174 is used to predict address information corresponding to a domain, such as target address information in response to a DNS query. In some embodiments, prediction engine 174 uses a model (e.g., a machine learning model) to accurately predict the address information corresponding to the domain. For example, the prediction engine sends a query to machine learning model 176 to obtain target address information corresponding to a domain. In some embodiments, the query to machine learning model 176 includes an indication of the domain (e.g., top-level domain) associated with the DNS query, an indication of the requested domain (e.g., a specific subdomain), a set of domains associated with the top-level domain corresponding to the DNS query, and / or one or more of a training set of domains. In some implementations, machine learning model 176 is pre-trained, and prediction 174 does not need to provide the training set of domains to machine learning model 176 simultaneously with querying the target address information.

[0027] Machine learning model 176 is at least partially based on model predictions of address information corresponding to a specific domain. As an example, the model is pre-stored and / or pre-trained. Various machine learning procedures can be used to train the model. Examples of machine learning procedures that can be combined with training the model include random forests, linear regression, support vector machines, Naive Bayes, logistic regression, K-nearest neighbors, decision trees, gradient-boosted decision trees, K-means clustering, hierarchical clustering, density-based noisy applied spatial clustering (DBSCAN), principal component analysis, etc. According to various embodiments, machine learning model 176 uses relationships and / or patterns of address information within the domain set and / or training set to estimate address information in response to DNS queries. For example, machine learning model 176 uses machine learning procedures to analyze a set of relationships between one or more subdomains and one or more top-level domains included in the top-level domain set information, and uses this set of relationships to generate a predictive model for predicting the target address information for DNS queries. In response to predicting the target address information for DNS queries, the predicted target address information is stored in a predictive cache 170, such as cache 178.

[0028] Cache 178 stores address information for one or more domains. In some embodiments, cache 178 includes a conventional cache. For example, a conventional cache stores address information for one or more domains based at least in part on one or more queries to an applicable authoritative name server(s). In some embodiments, cache 178 includes a cache for predicting addresses. For example, a cache for predicting addresses stores one or more predicted addresses for one or more domains (e.g., predicted addresses in response to one or more previous DNS queries).

[0029] Return to Figure 1 Suppose a malicious individual (using system 120) has created malware 130. This malicious individual intends for a client device, such as client device 104, to execute a copy of malware 130, compromise that client device, and turn it into a botnet. The compromised client device can then be instructed to perform tasks (e.g., cryptocurrency mining, or participating in denial-of-service attacks) and / or report information to external entities (such as command and control (C&C) server 150) (e.g., associated with such tasks, leaking sensitive corporate data, etc.), and receive instructions from C&C server 150 (if applicable).

[0030] While malware 130 might attempt to make compromised client devices communicate directly with C&C server 150 (e.g., by having the client send emails to C&C server 150), such overt communication attempts can be flagged as suspicious / harmful and blocked (e.g., via data appliance 102). Instead of enabling such direct communication, malware authors increasingly use a technique referred to in this paper as DNS tunneling. DNS is a protocol that translates human-friendly URLs (such as paloaltonetworks.com) into machine-friendly IP addresses (such as 199.167.52.137). DNS tunneling utilizes the DNS protocol to tunnel malware and other data through a client-server model. In the example attack, the attacker registered a domain such as badsite.com. The domain name server pointed to the attacker's server, where the tunneling malware program was installed. The attacker infected a computer. Because DNS requests are traditionally allowed to be moved in and out of security devices, an infected computer is permitted to send queries to a DNS resolver (e.g., to kj32hkjqfeuo32ylhkjshdflu23.badsite.com, where the subdomain portion of the query is encoded for consumption by the C&C server). A DNS resolver is a server that relays requests for IP addresses to the root domain and top-level domain servers. The DNS resolver routes the query to the attacker's C&C server, where a tunneling program is installed. A connection is now established between the victim and the attacker via the DNS resolver. This tunnel can be used to leak data or for other malicious purposes.

[0031] Detecting and preventing DNS tunneling attacks is difficult for various reasons. The first reason is... Figure 3 The diagram in the middle shows, Figure 3 This illustrates both benign DNS query messages (302, 304) and malicious DNS query messages (306-312). Many legitimate services (e.g., content delivery networks, web hosting companies, etc.) legitimately use subdomain portions of domain names to encode information to help support the use of those legitimate services. The encoding patterns used by such legitimate services can vary greatly between providers, and (e.g.) Figure 3 (As illustrated in the diagram) Benign subdomains may not be visually distinguishable from malicious subdomains. A second reason is that, unlike other fields (e.g., computer science) with large corpora containing training data of both known benign and known malicious domains, the training data used for DNS queries is severely imbalanced (e.g., with millions of benign root domain examples and very few malicious examples). Despite these difficulties, and using the techniques described in this paper, malicious DNS tunneling can be efficiently detected and stopped in real time.

[0032] Figure 1The environment shown includes three Domain Name System (DNS) servers (122-126). As shown, DNS server 122 is under the control of ACME (for use by computing assets located within network 110), while DNS server 124 is publicly accessible (and can also be used by computing assets located within network 110 and other devices, such as devices located within other networks (e.g., networks 114 and 116)). DNS server 126 is publicly accessible but under the control of a malicious operator of C&C server 150. Enterprise DNS server 122 is configured to resolve enterprise domain names to IP addresses and is further configured to communicate with one or more external DNS servers (e.g., DNS servers 124 and 126) to resolve domain names (where applicable).

[0033] As mentioned above, in order to connect to a legitimate domain (e.g., www.example.com, depicted as site 128), a client device (such as client device 104) will need to resolve the domain to its corresponding Internet Protocol (IP) address. One way this resolution can occur is that client device 104 forwards a request to DNS servers 122 and / or 124 to resolve the domain. Upon receiving a valid IP address for the requested domain name, client device 104 can use that IP address to connect to website 128. Similarly, in order to connect to a malicious C&C server 150, client device 104 will need to resolve the domain “kj32hkjqfeuo32ylhkjshdflu23.badsite.com” to its corresponding Internet Protocol (IP) address. In this example, malicious DNS server 126 is authoritative for *.badsite.com, and client device 104's request will be forwarded (e.g.) to DNS server 126 for resolution, ultimately allowing C&C server 150 to receive data from client device 104.

[0034] In various embodiments, data appliance 102 includes a DNS module 134 configured to facilitate determining whether client devices (e.g., client devices 104-108) are attempting to participate in a malicious DNS tunnel, and / or to prevent (e.g., via client devices 104-108) connections to malicious DNS servers. The DNS module 134 may be integrated into appliance 102 (e.g., ...). Figure 1 (as shown in the illustration), and in various embodiments can also be operated as a stand-alone appliance. Furthermore, as... Figure 1Like the other components shown, DNS module 134 can be provided by the same entity that provides appliance 102 (or security platform 140), and it can also be provided by a third party (e.g., a third party different from the provider of appliance 102 or security platform 140). In addition to preventing connections to malicious DNS servers, DNS module 134 can also take other actions, such as personalizing the logging of tunneling attempts made by clients (indicating that a given client is compromised and should be isolated or otherwise investigated by an administrator).

[0035] In various embodiments, when a client device (e.g., client device 104) attempts to resolve a domain, the DNS module 134 uses the domain as a query to the security platform 140. This query can be performed concurrently with domain resolution (e.g., with requests sent to DNS servers 122, 124, and / or 126 and the security platform 140). As an example, the DNS module 134 can send the query (e.g., in JSON format) to the front end 142 of the security platform 140 via a REST API. Using the processing described in more detail below, the security platform 140 will (e.g., using a DNS tunnel detector 138) determine whether the queried domain indicates a malicious DNS tunneling attempt and provide the result back to the DNS module 134 (e.g., "malicious DNS tunnel" or "non-tunnel").

[0036] In various embodiments, the DNS tunnel detector 138 (whether implemented on security platform 140, data appliance 102, or other suitable location / combination) employs a two-pronged approach in identifying malicious DNS tunnels. The first approach uses an anomaly detector 146 (e.g., implemented in Python) to construct a set of real-time profiles (156) of DNS traffic to the root domain. The second approach uses signature generation and matching (also referred to herein as similarity detection, and implemented, for example, in Go). These two approaches are complementary. The anomaly detector serves as a general detector that can identify previously unknown tunnel traffic. However, the anomaly detector may need to observe multiple DNS queries before performing detection. To block the first DNS tunneling packet, the similarity detector 144 complements the anomaly detector 146 and extracts signatures from the detected tunnel traffic. These signatures can be used to identify situations where an attacker has registered a new malicious tunnel root domain but has done so using tools / malware similar to the detected root domain.

[0037] When data appliance 102 receives a DNS query (e.g., from DNS module 134), it provides it to security platform 140, which performs both anomaly detection and similarity detection. In various embodiments, if either detector flags a domain, that domain (e.g., as provided in the query received by security platform 140) is classified as a malicious DNS tunneling root domain.

[0038] DNS tunnel detector 138 maintains a set of fully qualified domain names (FQDNs) for each device (from which it receives data), grouped according to their root domain (in... Figure 1 The unified illustration is shown as domain profile 156. (Although grouping by root domain is generally described in the specification, it should be understood that the techniques described herein can also be extended to domains at any level.) In various embodiments, information about received queries for a given domain is persisted in the profile for a fixed amount of time (e.g., a sliding time window of ten minutes).

[0039] As an example, DNS query information received from data appliance 102 for various foo.com sites is grouped (into a domain profile for the root domain foo.com) as: G(foo.com) = [mail.foo.com, coolstuff.foo.com, domain1234.foo.com]. The second root domain will have a second profile with similar applicable information (e.g., G(baddomain.com) = [lskjdf23r.baddomain.com, kj235hdssd233.baddomain.com]). Each root domain (e.g., foo.com or baddomain.com) is modeled using a set of characteristics unique to malicious DNS tunnels, making them highly unlikely to be misclassified as malicious tunnels, even though benign DNS patterns are diverse (e.g., k2jh3i8y35.legitimatesite.com, xxx888222000444.otherlegitimatesite.com). The following are example properties that can be extracted as features (e.g., extracted into feature vectors) for a given set of domains (i.e., sharing a root domain).

[0040] Figure 2 This is a block diagram of a system for providing predicted addresses according to various embodiments of this application. According to various embodiments, in conjunction with... Figure 1 System 100 implements system 200, such as for predictive cache 170. In various embodiments, combined with Figure 3 System 300 Figure 4 System 400 Figure 5 System 500 Figure 6 Process 600 Figure 7 The process 700 Figure 8 Process 800 and / or Figure 9 The process 900 is used to implement system 200.

[0041] System 200 can be implemented by one or more devices, such as servers. System 200 can be implemented at various locations on a network. For example, a predictive cache can be deployed on a DNS resolver. As another example, a predictive cache can be deployed on a firewall. As yet another example, a predictive cache is a service provided to a DNS resolver (e.g., a predictive cache is deployed on a remote server that serves queries from the DNS resolver for predicted address information for a domain).

[0042] In the illustrated example, system 200 incorporates one or more modules to predict addresses corresponding to a domain (such as for predicting and / or providing target address information in response to DNS queries). System 200 includes a communication interface 205, one or more processors 210, a storage device 215, and / or a memory 220. The one or more processors 210 include one or more of a communication module 225, a detector module 230, a model module 235, a model update module 240, a prediction module 245, and / or a query response module 250.

[0043] In some embodiments, system 200 includes a communication module 225. System 200 uses communication module 225 to communicate with various client terminals or user systems such as administrator systems. For example, communication module 225 provides information to be transmitted to communication interface 205. As another example, communication interface 205 provides information received by system 200 to communication module 225. Communication module 225 is configured to receive one or more DNS queries from various client terminals or systems (such as firewalls, DNS resolvers, etc.). Communication module 225 is configured to receive one or more settings or configurations from an administrator. Examples of one or more settings or configurations include configuration of a model (e.g., a machine learning model), indication of the model's training set, information related to a whitelist of domains (e.g., domains not considered suspicious and permitted to send queries to the applicable aDNS), and information related to a blacklist of domains (e.g., domains considered suspicious and whose responses to DNS queries are at least partially based on predicted addresses or who do not respond to DNS queries).

[0044] In some embodiments, system 200 includes detector module 230. System 200 uses detector module 230 in conjunction with determining whether a DNS query corresponds to suspicious or malicious traffic. In some embodiments, detector module 230 corresponds to or is similar to detector module 172.

[0045] In some embodiments, system 200 includes a model module 235. System 200 uses model module 235 to determine a predicted address for a domain (e.g., a specific domain corresponding to a DNS query). System 200 may manage a model (e.g., a machine learning model) via model module 235. Model module 235 determines the model used to generate the predicted address based at least in part on a machine learning process and one or more training sets. In some embodiments, model module 235 corresponds to or is similar to machine learning model 176.

[0046] In some embodiments, system 200 includes a model update module 240. System 200 uses model update module 240 to update a model for predicting addresses. Model update module 240 updates the model based at least in part on one or more training sessions and / or feedback provided by system 200 in response to a DNS query providing a predicted address. Model update module 240 may use records from one or more domains (such as domains considered benign (e.g., google.com, Microsoft.com, apple.com, etc.)) for updating. As an example, model update module 240 obtains zone file information related to one or more domains (e.g., from a trusted aDNS).

[0047] In some embodiments, system 200 includes a prediction module 245. System 200 uses prediction module 245 to predict address information corresponding to a domain, such as target address information in response to a DNS query. For example, prediction module 245 determines whether to use model module 235 in conjunction with predicting target address information in response to a particular DNS query, and / or whether to retrieve previously predicted target address information from a cache such as predictive cache data 264. As an example, in response to determining to use model module 235 in conjunction with predicting target address information from a DNS query, prediction module 245 sends a query for the predicted address to model module 235 (e.g., system 200 provides such a predicted address as target address information in response to a DNS query). In some embodiments, prediction module 245 corresponds to or is similar to prediction engine 174.

[0048] In some embodiments, system 200 includes a query response module 250. System 200 uses query response module 250 to provide target address information in response to a DNS query. For example, query response module 250 obtains a predicted address from prediction module 245 and provides the predicted address as target address information in response to a DNS query. As another example, query response module 250 provides target address information to a DNS resolver, the client from which the DNS query originates, etc. As yet another example, query response module 250 provides target address information for a domain obtained from a traditional cache or aDNS, such as in response to system 200 determining that the DNS query is not suspicious or malicious.

[0049] According to various embodiments, storage device 215 includes one or more of file system data 260, model data 262, predictive cache data 264, and / or conventional cache data 266. Storage device 215 includes shared storage devices (e.g., network storage systems) and / or database data, and / or user activity data.

[0050] In some embodiments, file system data 260 includes databases, such as one or more datasets (e.g., one or more datasets for one or more tenants). File system data 260 includes data such as datasets used to train machine learning processes, historical information related to DNS queries, whitelists of domains considered safe (e.g., not suspicious), blacklists of domains corresponding to traffic considered suspicious or malicious, information associated with suspicious or malicious traffic (such as trends or relationships), and information associated with safe or secure traffic (such as trends or relationships).

[0051] Model data 262 includes data relating to one or more models. As an example, data relating to one or more models includes relationships and associations between domains (e.g., top-level domains, subdomains, etc.) and address information (such as IP addresses). Model data 262 may store information relating to one or more machine learning processes and / or the configurations used to implement one or more machine learning processes to predict address information.

[0052] Predictive cache data 264 includes address information predicted for one or more domains. As an example, predictive cache data 264 stores predicted address information determined by one or more previous DNS queries.

[0053] Conventional cache data 266 includes address information corresponding to previous queries sent to aDNS. For example, in response to system 200 determining that a DNS query is safe or secure and that the target address information is to be obtained from aDNS rather than from a prediction (e.g., via prediction module 245 using model module 235), conventional cache data 266 stores address information obtained from the aDNS associated with the applicable DNS.

[0054] According to various embodiments, memory 220 includes application execution data 275. Application execution data 275 includes data acquired or used in conjunction with the execution of an application such as performing a machine learning process or configuring a machine learning model. In embodiments, the application includes one or more applications that perform one or more of the following: receiving and / or executing queries or tasks, generating reports and / or configuration information in response to executed queries or tasks, and / or providing information to a user in response to queries or tasks. Other applications include any other suitable applications (e.g., index maintenance applications, communication applications, machine learning model applications, applications for detecting suspicious traffic, document preparation applications, report preparation applications, user interface applications, data analysis applications, anomaly detection applications, user authentication applications, etc.).

[0055] Figure 3 This is a diagram illustrating a system that uses predictive caching in response to Domain Name System (DNS) queries. According to various embodiments, it combines... Figure 2 System 300 is implemented using system 100 and / or system 200. In various embodiments, it is combined with... Figure 6 Process 600 Figure 7 The process 700 Figure 8 Process 800 and / or Figure 9 The process 900 is used to implement system 300.

[0056] exist Figure 3 In the example shown, traffic originates from the infected client 310 and is sent to the DNS resolver 320. For example, the infected client 310 sends DNS traffic (e.g., DNS queries) to the DNS resolver 320. Figure 3 As illustrated, DNS resolver 320 sends traffic to predictive cache 350 instead of DNS traffic to NDS tunnel server 340, such as in conjunction with query aDNS. For example, DNS resolver 320 determines to use predictive cache 350 to obtain a response to a DNS query sent from infected client 310. In some embodiments, DNS resolver 320 determines to use predictive cache 350 to obtain target address information in response to a DNS query, at least in part based on the determination that the DNS query transmitted from infected client 310 corresponds to suspicious or malicious traffic. In response to receiving a query from DNS resolver 320, predictive cache 350 determines (e.g., predicts) address information corresponding to the domain indicated by the query. In some embodiments, predictive cache 350 uses a machine learning model to predict the address information corresponding to the domain. In response to determining the predicted address, predictive cache 350 returns the predicted address to infected client 310 (e.g., DNS resolver 320) as the target address information in response to the DNS query.

[0057] Figure 4 This is a diagram illustrating a system for determining the use of predictive caching in response to DNS queries. According to various embodiments, [the system] combines... Figure 2 System 400 is implemented using system 100 and / or system 200. In various embodiments, it is combined with... Figure 6 Process 600 Figure 7 The process 700 Figure 8 Process 800 and / or Figure 9 The process 900 is used to achieve system 400.

[0058] exist Figure 4 In the example shown, DNS query 410 is transmitted to the network, such as to a DNS resolver. As an example, DNS query 410 is transmitted by a client (e.g., an infected or malicious client, a benign or secure client, etc.). Detector 420 receives DNS query 410 and determines whether the DNS query corresponds to suspicious or malicious traffic. For example, detector 420 determines whether DNS query 410 corresponds to untrusted or trusted traffic. In some embodiments, the detector determines whether DNS query 410 corresponds to untrusted or trusted traffic based at least in part on analysis of DNS query 410 and / or the client from which it receives the DNS query.

[0059] In response to detector 420 determining that DNS query 410 corresponds to untrusted traffic, a query is sent to predictive cache 430 to obtain predicted address information for the domain included in DNS query 410. In some embodiments, predictive cache 430 uses a machine learning model to predict the address information corresponding to the domain. In response to determining the predicted address, predictive cache 430 returns the predicted address as the target address information in response to DNS query 410.

[0060] In response to detector 420 determining that DNS query 410 corresponds to trusted traffic, a query is sent to legacy cache 440 to obtain predicted address information for the domain included in DNS query 410. In some embodiments, legacy cache 440 determines cached address information corresponding to the domain and returns such cached address information as target address information in response to DNS query 410. The cached address information may correspond to address information previously obtained from aDNS. In response to determining that legacy cache 440 does not include address information for the domain mapped to DNS query 410, a query is sent to aDNS for address information corresponding to the domain, and in response to receiving address information from aDNS, this address information is returned as target address information in response to DNS query 410.

[0061] Figure 5 This is a diagram of a system used to respond to DNS queries. According to various embodiments, combined with... Figure 2 System 500 is implemented using system 100 and / or system 200. In various embodiments, it is combined with... Figure 6 Process 600 Figure 7 The process 700 Figure 8 Process 800 and / or Figure 9 The process of 900 is used to achieve system 500.

[0062] In the example shown, the DNS resolver receives a DNS query at step 1 (e.g., a query for the encoded-data-1.test.com domain). In response to receiving the DNS query, the DNS resolver determines whether the DNS query corresponds to trusted or untrusted traffic. For example, the DNS resolver determines whether the DNS query corresponds to suspicious or malicious traffic.

[0063] In response to the determination that the DNS query corresponds to trusted traffic, at step 2a, the traffic is directed to a conventional cache or aDNS to obtain address information corresponding to the domain included in the DNS query (e.g., the encoded-data-1.test.com domain).

[0064] In response to the determination of untrusted traffic by the DNS query, at step 2b, the traffic is directed to a predictive cache to obtain predictive address information.

[0065] In response to receiving a query for address information, at step 3, the predictive cache obtains from aDNS one or more records relating to (e.g., adjacent) a list of previously resolved addresses associated with the domain of the DNS query and / or the top-level domain. In some embodiments, the predictive cache requests from applicable passive DNS records other subdomains corresponding to the top-level domain of the DNS query (e.g., obtaining past resolutions of the top-level domain). As an illustrative example, in the case of the top-level domain "root.com", the predictive cache obtains all records for subdomains under "root.com" from the passive DNS. In some embodiments, the predictive cache determines a set of subdomains lexically similar to the domain included in the DNS query and queries aDNS for address information corresponding to (e.g., mapped to) the set of subdomains lexically similar to the domain included in the DNS query.

[0066] At step 4, the predictive cache provides the machine learning model with address information obtained from the passive DNS, address information related to the training set (e.g., address information of subdomains of various benign domains), and / or address information corresponding to a set of subdomains that are lexically similar to the domains included in the DNS query.

[0067] At step 5, the predictive cache uses a machine learning model to predict the address information of the domains included in the DNS query. In some embodiments, the machine learning model is pre-trained based on the relationships between subdomains and domains and / or the address information of previously resolved subdomains corresponding to the top-level domain. The machine learning model uses a machine learning process to predict the address information (e.g., IP address) of the domains included in the DNS query. In response to the machine learning model determining the predicted address information, the predictive cache provides the predicted address information as the target address information in response to the DNS query. As an example, the predictive cache provides the predictive address information to the DNS resolver, which in turn provides such information as the target address information to the client from which the DNS query originated.

[0068] Figure 6 This is a flowchart for incorporating a predictive cache in response to DNS queries. According to various embodiments, process 600 incorporates... Figure 1 System 100 and / or Figure 2 The system 200 is used to achieve this.

[0069] At 610, a DNS query is received. In some embodiments, the system receives DNS queries from the client, such as via a DNS resolver.

[0070] At 620, it is determined that the target address information is obtained from the predictive cache. As an example, the target address information corresponds to the address in response to a DNS query. In some embodiments, the system determines to obtain the target address information from the predictive cache based at least in part on the determination that the DNS query corresponds to untrusted traffic (e.g., suspicious traffic, malicious traffic, etc.).

[0071] At 630, target address information is obtained from the predictive cache. In some embodiments, the target address information corresponds to predicted address information, such as a predicted IP address. For example, the predicted address information is estimated using a model such as a machine learning model. In some embodiments, the predicted address is estimated simultaneously with a DNS query (e.g., the predictive cache estimates the predicted address in response to a received DNS query). In some embodiments, the predicted address is obtained from a storage device, such as in the case of address information corresponding to a previously estimated domain.

[0072] At position 640, target address information is provided. This is done in response to obtaining target address information from the predictive cache or in response to a DNS query. For example, the system provides target address information to clients from which the DNS query originated.

[0073] At 650, a determination is made regarding whether process 600 has completed. In some embodiments, process 600 is determined to be complete in response to a determination that no further DNS traffic (e.g., DNS queries) needs to be processed, an administrator instructing process 600 to be paused or stopped, etc. In response to the determination that process 600 has completed, process 600 ends. In response to the determination that process 600 has not completed, process 600 returns to 610.

[0074] Figure 7 This is a flowchart for incorporating a predictive cache in response to DNS queries. According to various embodiments, process 700 incorporates... Figure 1 System 100 and / or Figure 2 The system 200 is used to achieve this.

[0075] At position 710, a DNS query is received.

[0076] At point 720, a determination is made as to whether the DNS query corresponds to suspicious traffic. In some embodiments, the system uses the detection module in conjunction with the determination of whether the DNS query is suspicious. As an example, the detection module determines whether the DNS query is suspicious based at least in part on one or more of anomaly detection in DNS traffic, a whitelist identifying trusted domains, a blacklist identifying untrusted domains, etc.

[0077] In response to the determination at 720 that the DNS query corresponds to suspicious traffic, process 700 continues to 730, where the target address information is obtained from the predictive cache. In some implementations, this is done in conjunction with... Figure 6 The process of obtaining target information from the predictive cache is performed in the same or similar manner as that of 630 in process 600.

[0078] In response to determining at 720 that the DNS query does not correspond to suspicious traffic, process 700 continues to 50, where the system determines whether the cache stores address information mapped to the domain included in the DNS query. In response to determining at 750 that the address information mapped to the domain is stored in the cache, process 700 continues to 760, where, in response to the DNS query, the address information is obtained from the cache and returned as the target address information. In response to determining at 750 that the address information mapped to the domain is not stored in the cache, process 700 continues to 770, where an authoritative name server (e.g., aDNS) is queried. For example, the system queries aDNS for address information corresponding to the domain included in the DNS query. In response to receiving the address information corresponding to that domain, the system provides such information as the target address information in response to the DNS query.

[0079] At 780, a determination is made regarding whether process 700 has completed. In some embodiments, process 700 is determined to be complete in response to a determination that no further DNS traffic (e.g., DNS queries) needs to be processed, an administrator instructing process 700 to be paused or stopped, etc. In response to the determination that process 700 has completed, process 700 ends. In response to the determination that process 700 has not completed, process 700 returns to 710.

[0080] Figure 8 This is a flowchart of a method for determining target address information corresponding to a DNS query. According to various embodiments, process 800 is combined with… Figure 1 System 100 and / or Figure 2 The system 200 is used to achieve this.

[0081] At 810, the domain is determined. In some embodiments, the domain is included in DNS traffic such as DNS queries. As an example, a firewall or DNS resolver obtains the domain from DNS traffic and provides it to a predictive cache.

[0082] At 820, a record for the subdomain is queried. In some embodiments, the system determines the top-level domain (e.g., the top-level domain of the DNS query) associated with the domain and obtains records for the subdomains of such top-level domain. According to various embodiments, the system (i) obtains a set of records under the top-level domain from a passive DNS (e.g., PDNS), and / or (ii) obtains a set of records for a list of lexically similar subdomains from an aDNS. As an example of (i), the system determines previously resolved address information for other subdomains associated with the top-level domain of the DNS query. As an example of (ii), the system generates a list of domains similar to the subdomains included in the aDNS and queries the aDNS for the corresponding address information.

[0083] At position 830, records for subdomains under the domain are provided to the model. The system provides records for subdomains to the model in conjunction with the request to obtain the predicted address. For example, the system provides the model with previously resolved address information for other subdomains associated with the top-level domain whose address information was previously resolved in the DNS query, as well as address information for domains similar to those included in the DNS query.

[0084] At 840, the target address information is determined at least in part based on a model. In some embodiments, the model determines a predicted address corresponding to an estimate of the address information corresponding to the domain. As an example, the model is a machine learning model that implements a machine learning model to generate the predicted address. In some embodiments, determining the predicted address includes using the model in combination with one or more of the following: (i) a set of records under a top-level domain from a passive DNS (e.g., a PDNS), and / or (ii) a set of records from a list of lexically similar subdomains from an aDNS. In some embodiments, the model is trained using address information from a set of domains such as benign domains and corresponding subdomains.

[0085] At 850, target address information is provided. In response to obtaining the target address information (e.g., a predicted address estimated using a model), the target address information is transmitted to clients, such as those originating from DNS queries. For example, the system provides target address information to clients from which DNS queries originate.

[0086] At 860, a determination is made regarding whether process 800 is complete. In some embodiments, process 800 is determined to be complete in response to a determination that no further address information needs to be determined for the domain, an administrator instruction to pause or stop process 800, etc. In response to the determination that process 800 is complete, process 800 ends. In response to the determination that process 800 is not complete, process 800 returns to 810.

[0087] Figure 9 It is a flowchart of a method for determining a machine learning model to predict the record structure associated with a domain.

[0088] At 910, multiple training domains are identified. In some embodiments, the system determines a set of domains (such as benign domains) and corresponding subdomains. The set of domains and corresponding subdomains can be determined based on selection, such as the choice or configuration of the administrator of the prediction system (e.g., the model developer). As an example, multiple training domains correspond to domains that are considered trustworthy or benign.

[0089] At 920, multiple records for multiple training domains are queried. In some embodiments, the system queries a previously resolved set of address information for address information mapped to multiple training domains and / or address information mapped to multiple training domains at an authoritative name server. For example, regarding the previously resolved set of address information, the system queries the pDNS for the corresponding address information. As an example, regarding the address information stored at the authoritative name server, the system queries the applicable aDNS for address information corresponding to multiple training domains.

[0090] At position 930, multiple records are used to determine the relationship between the training domain and the subdomain. In some embodiments, a machine learning process is used to determine the relationship between the training domain and the subdomain, based at least in part on multiple records of multiple training domains. Examples of machine learning processes that can be implemented in conjunction with a training model include random forests, linear regression, support vector machines, Naive Bayes, logistic regression, K-nearest neighbors, decision trees, gradient boosting decision trees, K-means clustering, hierarchical clustering, density-based noisy applied spatial clustering (DBSCAN), principal component analysis, etc. In some embodiments, a set of training domains is used to train a model that incorporates address information from the estimated domain. The set of training domains can be predefined.

[0091] At 940, the prediction model is determined at least in part based on the relationship between the training domain and subdomains. In some embodiments, a machine learning process is used to determine the prediction model. The prediction model is determined to provide address estimates (e.g., predicted addresses) for a specific domain.

[0092] At position 950, the domain corresponding to the DNS query is obtained. In some embodiments, this is similar to... Figure 8 The process 800, or 810, determines the domain. For example, the domain is the top-level domain corresponding to the domain in the DNS query.

[0093] At 960, obtain one or more records of the subdomains of the domain. In some embodiments, this is done in a manner similar to... Figure 8 The process 800 or 820 obtains one or more records of the domain.

[0094] At 970, the predicted target address information is determined. In some embodiments, this is similar to... Figure 5 System 500 Figure 7 Process 700, process 730, and Figure 8 The process of 800, 830, and 840 is performed to determine predictive address information, such as the target address information.

[0095] At 980, a determination is made regarding whether process 900 is complete. In some embodiments, process 800 is determined to be complete in response to a determination that no further address information needs to be determined for the domain, an administrator instructing process 900 to pause or stop, etc. In response to the determination that process 900 is complete, process 900 ends. In response to the determination that process 900 is not complete, process 900 returns to 910.

[0096] Various examples of embodiments described herein are illustrated in conjunction with flowcharts. Although examples may include certain steps performed in a particular order, according to various embodiments, various steps may be performed in various orders and / or various steps may be combined into a single step or may be performed in parallel.

[0097] Although the foregoing embodiments have been described in detail for clarity of understanding, the invention is not limited to the details provided. Many alternative ways of implementing the invention exist. The disclosed embodiments are illustrative and not restrictive.

Claims

1. A system for predicting responses to DNS queries, comprising: One or more processors are configured as follows: Receive DNS queries; Determine whether to retrieve the target address information corresponding to the DNS query from the predictive cache; In response to determining that the target address information is obtained from the predictive cache, the target address information is obtained from the predictive cache and provided to the client device; and In response to determining that the predictive cache does not currently store target address information, a machine learning model is used to determine the predicted target address information, and this predicted target address information is provided to the client device, wherein: Using machine learning models to determine the predicted target address information includes: Obtain top-level domain information related to the domain associated with the DNS query; and Generate address information for one or more subdomains associated with the domain in the DNS query; and At least in part, it relies on machine learning models to estimate the address information of one or more sub-domains; and The memory is coupled to the processor and configured to provide instructions to the processor.

2. The system of claim 1, wherein the machine learning model determines the predicted target address information without sending the DNS query to the authoritative server corresponding to the domain associated with the DNS query.

3. The system of claim 1, wherein the top-level domain information is obtained at least in part based on querying a database of registered users or assignees of Internet resources.

4. The system of claim 1, wherein the one or more processors are further configured to: In response to the determination that the predictive cache does not currently store target address information, DNS queries are blocked.

5. The system according to claim 4, wherein: At least in part, DNS queries are blocked based on configurations set by the administrative user.

6. The system of claim 1, wherein the predictive cache stores a set of target addresses, the target addresses being estimated at least in part based on corresponding top-level domain information.

7. The system of claim 1, wherein the predictive cache is generated using a machine learning process.

8. The system of claim 1, wherein determining whether to obtain target address information corresponding to a DNS query from a predictive cache comprises: Determine the query frequency of the domain associated with the DNS query; and Compare the query frequency with a frequency threshold.

9. The system of claim 8, wherein the one or more processors are further configured to: query target address information from the corresponding authoritative DNS server in response to determining that the query frequency meets a frequency threshold.

10. The system of claim 8, wherein the one or more processors are further configured to: determine, in response to determining that the query frequency does not meet a frequency threshold, obtain target address information from a predictive cache.

11. The system of claim 1, wherein in the event of obtaining target address information from the predictive cache, the DNS query is not transmitted to the authoritative server corresponding to the domain associated with the DNS query.

12. The system of claim 1, wherein determining whether to obtain target address information corresponding to a DNS query from a predictive cache comprises: Determine if the DNS query corresponds to suspicious traffic; and In response to determining that a DNS query corresponds to suspicious traffic, it is determined that target address information should be obtained from the predictive cache.

13. The system of claim 12, wherein determining whether a DNS query corresponds to suspicious traffic includes providing the DNS query to a suspicious traffic detector.

14. The system of claim 12, wherein the DNS query is determined to correspond to suspicious traffic based at least in part on whether the corresponding DNS is trusted or untrusted.

15. The system of claim 1, wherein the predictive cache is included in the DNS resolver.

16. A method for predicting the response to a DNS query, comprising: Receive DNS queries from the client device, including the subdomain portion and the root domain portion; Determine whether to obtain the target address information corresponding to the DNS from the predictive cache; In response to determining that the target address information is obtained from the predictive cache, the target address information is obtained from the predictive cache and provided to the client device; and In response to determining that the predictive cache does not currently store target address information, a machine learning model is used to determine the predicted target address information, and this predicted target address information is provided to the client device, wherein: Using machine learning models to determine the predicted target address information includes: Obtain top-level domain information related to the domain associated with the DNS query; and Generate address information for one or more subdomains associated with the domain in the DNS query; and The address information of one or more sub-domains is estimated, at least in part, based on machine learning models.

17. A computer program product stored in a non-transitory computer-readable medium and comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the following method steps: Receive DNS queries from the client device, including the subdomain portion and the root domain portion; Determine whether to obtain the target address information corresponding to the DNS from the predictive cache; In response to determining that the target address information is obtained from the predictive cache, the target address information is obtained from the predictive cache and provided to the client device; and In response to determining that the predictive cache does not currently store target address information, a machine learning model is used to determine the predicted target address information, and this predicted target address information is provided to the client device, wherein: Using machine learning models to determine the predicted target address information includes: Obtain top-level domain information related to the domain associated with the DNS query; and Generate address information for one or more subdomains associated with the domain in the DNS query; and The address information of one or more sub-domains is estimated, at least in part, based on machine learning models.

Images