Predictive DNS cache to improve security and performance

Abstract

To disclose a method, system, and computer system for predicting responses to DNS queries.SOLUTION: A method includes the steps of: receiving a DNS query comprising a subdomain portion and a root domain portion from a client device; determining whether or not to obtain target address information corresponding to the DNS from a predictive cache, in response 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.SELECTED DRAWING: Figure 6

Description

[Background technology]

[0001] Malicious individuals attempt to compromise computer systems in a variety of ways. As one example, such individuals may embed or otherwise include malicious software (“malware”) in email attachments and then send or have the malware sent to unsuspecting users. When executed, the malware compromises the victim's computer. Some types of malware instruct the compromised computer to communicate with a remote host. For example, malware can turn a compromised computer into a “bot” in a “botnet,” which receives instructions and / or reports data from a command and control (C&C) server under the malicious individual's control. One approach to mitigating the damage caused by malware is for security companies (or other appropriate entities) to identify the malware and attempt to prevent it from reaching / executing on end-user computers. Another approach is to try to prevent the compromised computer from communicating with the C&C server. Unfortunately, malware authors are using increasingly sophisticated techniques to obfuscate the workings of their software. As one example, some types of malware use Domain Name System (DNS) queries to exfiltrate data. Thus, there remains a need for improved techniques for detecting malware and preventing its harm. [Brief explanation of the drawings]

[0002] Various embodiments of the present invention are disclosed in the following detailed description and accompanying drawings. [Figure 1] FIG. 1 illustrates an example of an environment in which malware is detected or suspected and its harm is mitigated. [Figure 2] FIG. 2 is a block diagram of a system for providing a predicted address according to various embodiments of the present application. [Figure 3] FIG. 3 is a diagram of a system for using a predictive cache in connection with responding to Domain Name System (DNS) queries. [Figure 4] FIG. 4 is a diagram of a system for determining to use a predictive cache in connection with responding to a DNS query. [Figure 5] FIG. 5 is a diagram of a system for responding to DNS queries. [Figure 6] FIG. 6 is a flow chart of a method for using a predictive cache in connection with responding to a DNS query. [Figure 7] FIG. 7 is a flow chart of a method for using a predictive cache in connection with responding to a DNS query. [Figure 8] FIG. 8 is a flow chart of a method for determining target address information corresponding to a DNS query. [Figure 9] FIG. 9 is a flow chart of a method for determining a machine learning model for predicting a record structure associated with a domain. DETAILED DESCRIPTION OF THE INVENTION

[0003] The present invention can be implemented in numerous 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 instructions stored on a memory and / or a processor configured to execute instructions stored and / or provided by a memory coupled to the processor. These implementations, or any other form the present invention may take, may be referred to herein as techniques. In general, the order of steps in disclosed processes may be varied within the scope of the present invention. Unless otherwise specified, components, such as a processor or memory, described as configured to perform a task may be implemented as general-purpose components temporarily configured to perform the task at a given time, or as specific components manufactured to perform the 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.

[0004] A detailed description of one or more embodiments of the present invention is provided below along with accompanying figures that illustrate the principles of the invention. While the present invention will be described in connection with such embodiments, the present invention is not limited to any embodiment. The scope of the present invention is limited only by the claims, and the present invention encompasses numerous alternatives, modifications, and equivalents. Numerous specific details are set forth in the following description to provide a thorough understanding of the present invention. These details are provided for the purpose of example, and the present invention may be practiced according to the claims without some or all of these specific details. For the purposes of clarity, technical material known in the art related to the present invention has not been described in detail so as not to unnecessarily obscure the present invention.

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

[0006] DNS tunneling is popular with data exfiltration attackers because most networks generally allow DNS traffic and do not provide secure control over it. Controlling DNS traffic is difficult because most DNS traffic is generally benign and its traffic patterns are diverse. For example, systems generally do not provide mechanisms to prevent malicious, slow tunneling, such as the use of many queries, each containing a small amount of malicious information (e.g., on the order of one byte) but collectively providing a large amount of malicious information. Queries from malicious clients (e.g., infected clients) are typically communicated in encoded streams. Furthermore, address information responsive to queries is often not stored in legacy caches, and in response to determining that a legacy cache does not store such address information, the data is forwarded to an authoritative name server. Having malicious traffic forwarded to an authoritative name server is typically the intent of the malicious parties behind the attack. Conversely, a benign client communicating a DNS query does not care how the response information is generated or where such information is obtained. Rather, the benign client simply desires a timely response that includes accurate address information (e.g., an IP address). Various embodiments implement a predictive cache that infers / predicts information in response to a DNS query, limiting or eliminating the need for queries to authoritative name servers to resolve the DNS query's address information. The use of a predictive cache thus prevents malicious traffic from being forwarded to authoritative name servers and provides timely and accurate information in response to benign DNS queries.

[0007] According to various embodiments, systems and / or methods for determining a response to a DNS query are provided. 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 that is predicted to respond to the DNS query) without accessing (e.g., querying) an authoritative name server (e.g., aDNS) for a domain included in the DNS query. In response to determining that a response to the DNS query will be generated (e.g., address information that is predicted to respond to the DNS query) using the predictive cache rather than a legacy cache or a query to an authoritative name server, the predictive cache determines target address information corresponding to the DNS query. In some embodiments, the predictive cache stores predicted address information (e.g., predicted subdomains of various domains). In some embodiments, the predictive cache determines the target address information (e.g., predicted address information that is predicted to respond to the DNS query) contemporaneously with the DNS request. For example, in response to determining that the predictive cache is to be used in connection with generating a response to a DNS query, the predictive cache retrieves one or more records associated with a domain included in the DNS query, provides the one or more records to a model (e.g., a machine learning model), and retrieves (e.g., determines) target address information corresponding to the DNS query. As one example, the target address information includes estimated address information for a particular domain included in the DNS query. In some embodiments, the one or more records associated with the domain are records for multiple subdomains of a particular top-level domain, such as the top-level domain of the domain included in the DNS query.

[0008] In some embodiments, the system retrieves one or more records associated with the domain included in the DNS query based at least in part on determining a set of domains associated with a top-level domain corresponding to the domain included in the DNS query. As one example, determining the set of domains associated with the top-level domain includes determining a set of domains that are lexically similar to the particular domain. For example, if the particular domain is "abc.root.com," the set of domains may 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 regarding the set of domains. As one example, a domain is considered similar (e.g., lexically similar) to the particular domain based on determining (e.g., calculating) a value indicating a degree of similarity and determining that the value indicating the degree of similarity is greater than a predetermined similarity threshold. In response to receiving address information related to the set of domains (e.g., from an 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 address information for a set of domains to a model (e.g., a machine learning model) and uses the model to predict address information in response to a DNS query. In one example, the model uses relationships and / or patterns in the address information among the set of domains and / or a training set to predict address information in response to a DNS query.

[0009] Various embodiments determine whether to use a predictive cache in connection with a DNS query based at least in part on a determination of whether the DNS query corresponds to suspicious traffic (e.g., whether the DNS query is suspicious or whether the device from which the DNS query is received is suspicious). In some embodiments, the system uses a detector module to detect (e.g., determine) whether the DNS query is suspicious. For example, the detector module performs real-time detection of whether the traffic is suspicious. Examples of systems, methods, and / or devices used in connection with analyzing traffic and / or determining whether the traffic is suspicious are provided in U.S. Patent Application No. 16 / 799,655, which corresponds to U.S. Patent Application Publication No. 2021 / 0266293. U.S. Patent Application No. 16 / 799,655 is incorporated by reference in its entirety. According to various embodiments, in response to a determination that the traffic (e.g., the DNS query) corresponds to suspicious traffic, the system determines to use a predictive cache in connection with determining target address information (address information responsive to the DNS query). Conversely, in response to a determination that the traffic does not correspond to suspicious traffic, the system determines to use a legacy cache or to query an applicable authority for corresponding target address information. In some embodiments, the detector module is configurable. For example, an administrator can configure the detector module based on a desired sensitivity or in response to a determination that an undesirable level of traffic is being inappropriately deemed suspicious traffic (e.g., the percentage of true traffic determined to be suspicious exceeds a traffic threshold).

[0010] According to various embodiments, a system and / or method uses a model (e.g., a machine learning model) to infer (e.g., predict) the structure and / or target address information of a domain in response to a DNS query. For example, a predictive cache may implement a machine learning model in connection with determining target address information. The model can be trained using various machine learning processes. Examples of machine learning processes that may be implemented in connection 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 spatial clustering of applications with noise (DBSCAN) clustering, principal component analysis, etc. In some embodiments, a model used in connection with inferring address information for a domain is trained using a set of training domains. The set of training domains may be pre-configured. For example, the set of training domains may include a pre-selected set of domains (e.g., google.com, etc.) that are considered benign. According to various embodiments, using the model to infer address information includes obtaining records of a subdomain of a domain associated with the DNS query (e.g., the top-level domain of the particular domain being queried), obtaining records of a set of training domains (e.g., records of the top-level domain and one or more subdomains), querying corresponding authoritative name servers for a list of domains or subdomains similar to the particular domain included in the DNS query, and using a machine learning process to generate a model for inferring address information in response to the DNS query (e.g., to determine target address information). In some embodiments, the model is implemented on a remote server. For example, one or more remote servers implement machine learning models that service one or more predictive caches.In response to determining that the model is to be used to generate an estimate of address information for the domain, the prediction cache can query a remote server (e.g., on which the machine learning model is implemented) for the estimate (e.g., the predicted address information for the domain).

[0011] A predictive cache may be implemented in various locations on a network. For example, a predictive cache may be located on a DNS resolver. As another example, a predictive cache may be located on a firewall. As another example, a predictive cache is a service provided at a DNS resolver (e.g., a predictive cache is deployed on a remote server that services queries from a DNS resolver for predictive address information for a domain).

[0012] The 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 in connection with responding to DNS traffic. Additionally, the system can provide accurate and low-latency responses to benign DNS traffic. Thus, the system prevents the proliferation of malicious traffic while providing the same or a better level of service to genuine traffic (e.g., querying authoritative name servers is not required when a predictive cache stores target information for DNS queries).

[0013] FIG. 1 illustrates an example environment in which malware is detected or suspected and its harm mitigated. In the illustrated example, client devices 104-108 are a laptop computer, a desktop computer, and a tablet (respectively) residing within enterprise network 110 (belonging to "Acme Company"). Data appliance 102 is configured to enforce policies regarding communications between client devices, such as client devices 104 and 106, and nodes outside enterprise network 110 (e.g., reachable via external network 118). Examples of such policies include those governing traffic shaping, quality of service, and traffic routing. Other example policies include security policies, such as those requiring scanning for threats in incoming (and / or outgoing) email attachments, website content, files exchanged via instant messaging programs, and / or other file transfers. In some embodiments, data appliance 102 is also configured to enforce policies regarding traffic remaining within enterprise network 110.

[0014] Data appliance 102 may be configured to operate in cooperation with remote security platform 140. Security platform 140 may provide various services, including performing static and dynamic analysis on malware samples and providing a list of signatures of known malicious files to a data appliance, such as data appliance 102, as part of a subscription. In various embodiments, the results of the analysis (and additional information about applications, domains, etc.) are stored in database 160. In various embodiments, security platform 140 comprises one or more dedicated, off-the-shelf hardware servers (e.g., having multi-core processors, 32G+ RAM, Gigabit network interface adapters, and hard drives) running a typical server-class operating system (e.g., Linux). Security platform 140 may be implemented across a scalable infrastructure including multiple such servers, solid-state drives, and / or other applicable high-performance hardware. Security platform 140 may comprise several distributed components, including components provided by one or more third parties. For example, some or all of security platform 140 may be implemented using Amazon Elastic Compute Cloud (EC2) and / or Amazon Simple Storage Service (S3). Additionally, similar to data appliance 102, whenever security platform 140 is referred to as performing a task, such as storing data or processing data, it should be understood that a subcomponent or multiple subcomponents of security platform 140 may cooperate (individually or in cooperation with third-party components) to perform that task. As one example, security platform 140 may cooperate with one or more virtual machine (VM) servers to optionally perform static and dynamic analysis.One example of a virtual machine server is a physical machine that includes commercially available server-class hardware (e.g., a multi-core processor, 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 virtual machine server is omitted. Furthermore, the virtual machine server may be under the control of the same entity that manages security platform 140, but may also be provided by a third party. As one example, the virtual machine server may rely on EC2, and the remainder of security platform 140 may be provided by dedicated hardware owned and under the control of the operator of security platform 140.

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

[0016] The detector module 172 is used in connection with determining whether to use a predictive cache in connection with a DNS query. In some embodiments, the detector module determines whether to retrieve a predicted address in response to a DNS query based at least in part on determining whether the DNS query corresponds to suspicious traffic. By way of example, the detector module 172 uses information obtained from a DNS tunneling detector in connection with determining whether the DNS query corresponds to suspicious traffic. In some embodiments, the detector module 172 determines whether to retrieve 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 a profile of the user or organization for which the DNS traffic is processed (e.g., a customer's latency setting may be set at least in part based on the level of service provided / subscribed to the customer). In implementations with low latency for responding to DNS queries, the predictive cache may determine to retrieve a predicted address (e.g., target address information) in response to a determination that the legacy cache does not store the target address information. In response to determining that the legacy cache does not store the target address information, the detector module determines whether the target address information was a previously determined predicted address and / or was stored in a predictive cache (e.g., cache 178). In response to determining that the target address information is not previously determined and / or not stored in a predictive cache, the detector module 172 determines to obtain the target address information based on predicting an address in response to a DNS query (e.g., using a machine learning model). For example, the detector module 172 requests the prediction engine 174 to predict an address in response to a DNS query.Conversely, in response to determining that the target address information has previously been determined by and / or stored in the predictive cache, the previously determined predicted address is used as the target address information.

[0017] 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 address information corresponding to a domain. For example, the prediction engine sends a query to machine learning model 176 to obtain target address information corresponding to the domain. In some embodiments, the query to machine learning model 176 includes one or more of an indication of a domain (e.g., a top-level domain) associated with the DNS query, an indication of a requested domain (e.g., a particular subdomain), a set of domains associated with the top-level domain corresponding to the DNS query, and / or a set of training domains. In some implementations, machine learning model 176 is pre-trained, and prediction 174 does not need to provide the set of training domains to machine learning model 176 simultaneously with the query for target address information.

[0018] The machine learning model 176 predicts address information corresponding to a particular domain based at least in part on the model. As one example, the model is pre-stored and / or pre-trained. The model may be trained using various machine learning processes. Examples of machine learning processes that may be implemented in connection 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 spatial clustering of applications with noise (DBSCAN) clustering, principal component analysis, etc. According to various embodiments, the machine learning model 176 uses relationships and / or patterns of address information among a set of domains and / or a training set to infer address information responsive to a DNS query. For example, the machine learning model 176 uses a machine learning process to analyze a set of relationships between one or more subdomains and one or more top-level domains included in the set of top-level domain information, and then generates a predictive model for predicting target address information of a DNS query using the set of relationships between one or more subdomains and one or more top-level domains. In response to predicting the target address information for the DNS query, the predicted target address information is stored in a prediction cache 170, such as cache 178.

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

[0020] 1 , assume that a malicious individual (using system 120) has created malware 130. The malicious individual wants a client device, such as client device 104, to run a copy of malware 130, compromising the client device and causing it to become a bot in a botnet. The compromised client device can then be instructed to perform a task (e.g., cryptocurrency mining or participating in a denial-of-service attack) and / or report information (e.g., theft of confidential corporate data associated with such a task) to an external entity, such as command and control (C&C) server 150, and, if applicable, receive instructions from C&C server 150.

[0021] Malware 130 can attempt to get a compromised client device to communicate directly with C&C server 150 (e.g., by having the client send an email to C&C server 150), but such overt communication attempts may be flagged (e.g., by data appliance 102) as suspicious / harmful and blocked. Increasingly, instead of generating such direct communication, malware authors are using a technique referred to herein 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 one example attack, an attacker registers a domain, such as badsite.com. The domain's name servers point to the attacker's server, where a tunneling malware program is installed. The attacker then infects a computer. Because DNS requests are traditionally allowed to travel in and out of security devices, the infected computer is allowed to send a query to a DNS resolver (e.g., for kj32hkjqfeuo32ylhkjshdflu23.badsite.com, where the subdomain portion of the query encodes information for consumption by the C&C server). A DNS resolver is a server that relays requests for IP addresses to root and top-level domain servers. The DNS resolver routes the query to the attacker's C&C server, which has a tunneling program installed. A connection has now been established between the victim and the attacker through the DNS resolver. This tunnel can be used to steal data or for other malicious purposes.

[0022] Detecting and preventing DNS tunneling attacks is difficult for a variety of reasons. The first reason is illustrated in Figure 3, which shows both benign DNS query information (302, 304) and malicious DNS query information (306-312). Many legitimate services (e.g., content delivery networks, web hosting companies, etc.) legitimately use the subdomain portion of a domain name to encode information to help support the use of their legitimate services. The encoding patterns used by such legitimate services vary greatly between providers, and benign subdomains (as shown in Figure 3) may appear visually indistinguishable from malicious subdomains. The second reason is that, unlike other domains (e.g., computer research) that have large corpora of both known benign and known malicious training set data, training set data for DNS queries is heavily biased (e.g., with millions of benign root domain examples and very few malicious examples). Despite these challenges, and using the techniques described herein, malicious DNS tunneling can be efficiently detected and stopped in real time.

[0023] 1 includes three Domain Name System (DNS) servers (122-126). As shown, DNS server 122 is under ACME's control (for use by computing assets located within network 110), while DNS server 124 is publicly accessible (and may also be used by computing assets located within network 110 as well as other devices, such as those located within other networks (e.g., networks 114 and 116)). DNS server 126 is publicly accessible but under the control of malicious operators of C&C server 150. Corporate DNS server 122 is configured to resolve corporate 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 applicable domain names.

[0024] As described above, to connect to a legitimate domain (e.g., www.example.com, shown as site 128), a client device, such as client device 104, needs to resolve the domain to a corresponding Internet Protocol (IP) address. One way such resolution can occur is for client device 104 to forward a request to DNS servers 122 and / or 124 to resolve the domain. In response to receiving a valid IP address for the requested domain name, client device 104 can use the IP address to connect to website 128. Similarly, to connect to malicious C&C server 150, client device 104 needs to resolve the domain "kj32hkjqfeuo32ylhkjshdflu23.badsite.com" to a corresponding Internet Protocol (IP) address. In this example, the malicious DNS server 126 is authoritative for *.badsite.com, and the client device 104 request is forwarded to the DNS server 126 for resolution (for example), ultimately allowing the C&C server 150 to receive data from the client device 104.

[0025] In various embodiments, the data appliance 102 includes a DNS module 134 configured to facilitate determining whether a client device (e.g., a client device 104-108) is attempting to engage in malicious DNS tunneling and / or prevent connections (e.g., by a client device 104-108) to malicious DNS servers. The DNS module 134 can be integrated into the appliance 102 (as shown in FIG. 1 ) or, in various embodiments, operate as a standalone appliance. And, like the other components shown in FIG. 1 , the DNS module 134 can be provided by the same entity that provides the appliance 102 (or security platform 140) or by a third party (e.g., different from the provider of the appliance 102 or security platform 140). Furthermore, in addition to preventing connections to malicious DNS servers, the DNS module 134 can take other actions, such as individualized logging of tunneling attempts made by clients (indicating that a given client has been compromised and should be quarantined or otherwise investigated by an administrator).

[0026] In various embodiments, when a client device (e.g., client device 104) attempts to resolve a domain, DNS module 134 uses the domain as a query to security platform 140. This query may be performed simultaneously with the resolution of the domain (e.g., simultaneously with requests sent to DNS servers 122, 124, and / or 126 and security platform 140). As one example, DNS module 134 may send a query (e.g., in JSON format) to front end 142 of security platform 140 via a REST API. Using a process described in more detail below, security platform 140 determines (e.g., using DNS tunneling detector 138) whether the queried domain indicates a malicious DNS tunneling attempt and provides a result (e.g., “malicious DNS tunneling” or “not tunneling”) back to DNS module 134.

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

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

[0029] For each appliance (for which data is received), DNS tunneling detector 138 maintains a set of fully qualified domain names (FQDNs) grouped about their root domain (collectively shown in FIG. 1 as domain profile 156). (While grouping by root domain is generally described herein, it should be understood that the techniques described herein can also be extended to any level of domain.) 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 10 minutes).

[0030] As one example, DNS query information received from data appliance 102 for various foo.com sites may be grouped (into a domain profile for the root domain foo.com) as follows: G(foo.com) = [mail.foo.com, coolstuff.foo.com, domain234.foo.com]. A second root domain would have a second profile with similar application information (e.g., G(baddomain.com) = [lskjdf23r.baddomain.com, kj235hdssd233.baddomain.com]). Each root domain (e.g., foo.com or baddomain.com) is modeled with a set of characteristics specific to malicious DNS tunneling, so that even if benign DNS patterns are diverse (e.g., k2jh3i8y35.legitimatesite.com, xxx888222000444.otherlegitimatesite.com), they are highly unlikely to be misclassified as malicious tunneling. The following are example characteristics that may be extracted as features (eg, into a feature vector) for a given group of domains (ie, those sharing a root domain):

[0031] 2 is a block diagram of a system for providing a predicted address according to various embodiments of the present application. According to various embodiments, system 200 is implemented in conjunction with system 100 of FIG. 1, such as for predictive cache 170. In various embodiments, system 200 is implemented in conjunction with system 300 of FIG. 3, system 400 of FIG. 4, system 500 of FIG. 5, process 600 of FIG. 6, process 700 of FIG. 7, process 800 of FIG. 8, and / or process 900 of FIG. 9.

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

[0033] In the illustrated example, system 200 implements one or more modules related to predicting addresses corresponding to a domain, such as for predicting and / or providing target address information in response to a DNS query. System 200 includes a communications interface 205, one or more processors 210, a storage device 215, and / or memory 220. One or more processors 210 include one or more of a communications 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.

[0034] In some embodiments, system 200 includes a communications module 225. System 200 uses communications module 225 to communicate with user systems, such as various client terminals or administrator systems. For example, communications module 225 provides communications information to communications interface 205. As another example, communications interface 205 provides information received by system 200 to communications module 225. Communications module 225 is configured to receive one or more DNS queries from various client terminals or systems, such as firewalls, DNS resolvers, etc. Communications module 225 is configured to receive one or more settings or configurations from an administrator. Examples of the one or more settings or configurations include configuration of a model (e.g., a machine learning model), instructions for a training set for the model, information regarding a whitelist of domains (e.g., domains that are not considered suspicious and for which queries are allowed to be sent to applicable aDNS), and information regarding a blacklist of domains (e.g., domains that are considered suspicious and for which a response to a DNS query should be based at least in part on a predicted address or for which no response to a DNS query should be provided).

[0035] In some embodiments, system 200 includes detector module 230. System 200 uses detector module 230 in connection 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.

[0036] In some embodiments, system 200 includes a model module 235. System 200 uses model module 235 to determine predicted addresses for domains (e.g., particular domains responsive to DNS queries). System 200 can manage models (e.g., machine learning models) via model module 235. Model module 235 determines the model used to generate predicted addresses based at least in part on a machine learning process and one or more training sets. In some implementations, model module 235 corresponds to or is similar to machine learning model 176.

[0037] In some embodiments, system 200 includes a model update module 240. System 200 uses model update module 240 to update the model used to predict addresses. Model update module 240 updates the model based at least in part on one or more training sessions and / or feedback provided in response to system 200 providing predicted addresses in response to DNS queries. Model update module 240 may be updated with records of one or more domains, such as domains considered benign (e.g., google.com, Microsoft.com, apple.com, etc.). In one example, model update module 240 obtains zone file information (e.g., from a trusted aDNS) associated with one or more domains.

[0038] In some embodiments, system 200 includes 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 connection 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 prediction cache data 264. As one example, in response to determining to use model module 235 in connection with predicting target address information for a DNS query, prediction module 245 sends a query to model module 235 for a predicted address (e.g., so that system 200 provides such predicted address as target address information in response to the DNS query). In some implementations, prediction module 245 corresponds to or is similar to prediction engine 174.

[0039] In some embodiments, system 200 includes 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 the 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 the target address information to a DNS resolver, a client from which a DNS query originated, etc. As another example, query response module 250 provides target address information for a domain obtained from a legacy cache or aDNS, such as in response to system 200 determining that a DNS query is not suspicious or malicious.

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

[0041] In some embodiments, file system data 260 comprises a database, such as one or more datasets (e.g., one or more datasets for one or more tenants, etc.), including datasets for training a machine learning process, historical information about 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, information associated with secure or safe traffic, such as trends or relationships, etc.

[0042] Model data 262 includes data related to one or more models. As one example, the data related to the 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 can store information related to one or more machine learning processes and / or configurations for implementing the one or more machine learning processes to predict address information.

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

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

[0045] According to various embodiments, memory 220 includes execution application data 275. Execution application data 275 includes data obtained or used in connection with the execution of an application, such as an application that executes a machine learning process or to configure a machine learning model. In embodiments, the applications include one or more applications that perform one or more of: receiving and / or executing queries or tasks; generating reports and / or configuring information responsive to executed queries or tasks; and / or providing information responsive to queries or tasks to a user. The other applications include any other suitable applications (e.g., index maintenance applications, communications applications, machine learning model applications, applications for detecting suspicious traffic, document creation applications, report creation applications, user interface applications, data analysis applications, anomaly detection applications, user authentication applications, etc.).

[0046]

[0023] Figure 3 is a diagram of a system for using a predictive cache in connection with responding to Domain Name System (DNS) queries. According to various embodiments, system 300 is implemented in connection with system 100 and / or system 200 of Figure 2. In various embodiments, system 300 is implemented in connection with process 600 of Figure 6, process 700 of Figure 7, process 800 of Figure 8, and / or process 900 of Figure 9.

[0047] In the example shown in FIG. 3, traffic originates at an infected client 310 and is sent to a DNS resolver 320. For example, the infected client 310 communicates DNS traffic (e.g., a DNS query) to the DNS resolver 320. As shown in FIG. 3, rather than sending the DNS traffic to a DNS tunneling server 340, such as in connection with querying a DNS, the DNS resolver 320 sends the traffic to a predictive cache 350. For example, the DNS resolver 320 determines to use the predictive cache 350 to obtain a response to the DNS query sent from the infected client 310. In some embodiments, the DNS resolver 320 determines to use the predictive cache 350 to obtain target address information in response to the DNS query based at least in part on determining that the DNS query communicated from the infected client 310 corresponds to suspicious or malicious traffic. In response to receiving a query from the DNS resolver 320, the 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 address information corresponding to a 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 target address information in response to a DNS query.

[0048]

[0023] Figure 4 is a diagram of a system for determining to use a predictive cache in connection with responding to a DNS query. According to various embodiments, system 400 is implemented in connection with system 100 and / or system 200 of Figure 2. In various embodiments, system 400 is implemented in connection with process 600 of Figure 6, process 700 of Figure 7, process 800 of Figure 8, and / or process 900 of Figure 9.

[0049] 4, DNS query 410 is communicated with a network, such as a DNS resolver. In one example, DNS query 410 is communicated 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 traffic or malicious traffic. For example, detector 420 determines whether DNS query 410 corresponds to untrusted traffic or trusted traffic. In some embodiments, detector 420 determines whether DNS query 410 corresponds to untrusted traffic or trusted traffic based at least in part on an analysis of DNS query 410 and / or the client from which the DNS query is received.

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

[0051] 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 an aDNS. In response to legacy cache 440 determining that it does not contain address information mapped to the domain of DNS query 410, a query is sent to the aDNS for address information corresponding to the domain, and in response to receiving the address information from the aDNS, the address information is returned as target address information in response to DNS query 410.

[0052] Figure 5 is a diagram of a system for responding to DNS queries. According to various embodiments, system 500 is implemented in conjunction with system 100 and / or system 200 of Figure 2. In various embodiments, system 500 is implemented in conjunction with process 600 of Figure 6, process 700 of Figure 7, process 800 of Figure 8, and / or process 900 of Figure 9.

[0053] In the illustrated example, a DNS resolver receives a DNS query (e.g., a query directed to the encoded-data-1.test.com domain) in step 1. 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.

[0054] In response to a determination that the DNS query corresponds to authoritative traffic, in step 2a, the traffic is directed to a legacy 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).

[0055] In response to determining that the DNS query corresponds to untrusted traffic, in step 2b, the traffic is directed to a prediction cache to obtain predicted address information.

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

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

[0058] In step 5, the predictive cache uses a machine learning model to predict address information for the domain included in the DNS query. In some embodiments, the machine learning model is pre-trained based on relationships between subdomains and domains and / or address information corresponding to previously resolved subdomains for a top-level domain. The machine learning model uses a machine learning process to predict address information (e.g., IP addresses) for the domain 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 target address information in response to the DNS query. In one example, the predictive cache provides the predicted address information to a DNS resolver, which then provides such information as target address information to the client from which the DNS query originated.

[0059] 6 is a flow chart of a method for using a predictive cache in connection with responding to DNS queries. According to various embodiments, process 600 is implemented in connection with system 100 of FIG. 1 and / or system 200 of FIG. 2.

[0060] A DNS query is received at 610. In some embodiments, the system receives a DNS query from a client, such as via a DNS resolver.

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

[0062] At 630, target address information is obtained from a 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 contemporaneously with the DNS query (e.g., the predictive cache estimates the predicted address in response to receiving a DNS query). In some embodiments, the predicted address is obtained from a storage device, such as when address information corresponding to the domain has been previously estimated.

[0063] At 640, target address information is provided. In response to retrieving the target address information from the predictive cache, the target address information is communicated in response to the DNS query. For example, the system provides the target address information to the client from which the DNS query originated.

[0064] At 650, a determination is made as to whether process 600 is complete. In some embodiments, process 600 is determined to be complete in response to a determination that no further DNS traffic (e.g., DNS queries) should be processed, an administrator indicates that process 600 should be paused or stopped, etc. In response to a determination that process 600 is complete, process 600 terminates. In response to a determination that process 600 is not complete, process 600 returns to 610.

[0065] 7 is a flow chart of a method for using a predictive cache in connection with responding to DNS queries. According to various embodiments, process 700 is implemented in connection with system 100 of FIG. 1 and / or system 200 of FIG. 2.

[0066] At 710, a DNS query is received.

[0067] At 720, a determination is made as to whether the DNS query corresponds to suspicious traffic. In some embodiments, the system uses a detection module in connection with determining whether the DNS query is suspicious. As one example, the detection module determines whether the DNS query is suspicious based at least in part on one or more of: detecting anomalies in DNS traffic; a whitelist identifying trusted domains; a blacklist identifying untrusted domains; etc.

[0068] In response to determining at 720 that the DNS query corresponds to suspicious traffic, process 700 proceeds to 730, where target address information is obtained from the predictive cache. In some embodiments, obtaining the target information from the predictive cache is performed in the same or similar manner as 630 of process 600 of FIG. 6.

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

[0070] At 780, a determination is made as to whether process 700 is complete. In some embodiments, process 700 is determined to be complete in response to a determination that no further DNS traffic (e.g., DNS queries) should be processed, an administrator indicates that process 700 should be paused or stopped, etc. In response to a determination that process 700 is complete, process 700 terminates. In response to a determination that process 700 is not complete, process 700 returns to 710.

[0071] 8 is a flowchart of a method for determining target address information corresponding to a DNS query. According to various embodiments, process 800 is implemented in conjunction with system 100 of FIG. 1 and / or system 200 of FIG. 2.

[0072] At 810, the domain is determined. In some embodiments, the domain is included in DNS traffic, such as a DNS query. In one example, a firewall or DNS resolver obtains the domain from the DNS traffic and provides the domain to a predictive cache.

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

[0074] At 830, records for subdomains under the domain are provided to the model. The system provides records for the subdomains to the model in association with a request to obtain a predicted address. For example, the system provides to the model previously resolved address information for other subdomains associated with the top-level domain of the previously resolved DNS query, and address information for domains similar to the domain included in the DNS query.

[0075] At 840, target address information is determined based at least in part on the model. In some embodiments, the model determines a predicted address corresponding to an estimate of the address information corresponding to the domain. As one 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 conjunction with one or more of: (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 for a list of domains of lexically similar subdomains from an aDNS. In some embodiments, the model is trained using address information for a set of domains, such as benign domains and corresponding subdomains.

[0076] At 850, target address information is provided. In response to obtaining the target address information (e.g., a predicted address estimated using the model), the target address information is communicated to a client, such as in response to a DNS query. For example, the system provides the target address information to the client from which the DNS query originated.

[0077] At 860, a determination is made as to 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 indicates that process 800 should be paused or stopped, etc. In response to a determination that process 800 is complete, process 800 terminates. In response to a determination that process 800 is not complete, process 800 returns to 810.

[0078] FIG. 9 is a flow chart of a method for determining a machine learning model for predicting a record structure associated with a domain.

[0079] At 910, a plurality of training domains are determined. In some embodiments, the system determines a set of domains, such as benign domains and corresponding subdomains. The set of domains and corresponding subdomains may be determined based on a choice, such as a selection or configuration, by an administrator of the prediction system (e.g., a model developer). In one example, the plurality of training domains correspond to domains that are considered reliable or benign.

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

[0081] At 930, the plurality of records is 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 the plurality of records for the plurality of training domains. Examples of machine learning processes that may be implemented in connection 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 spatial clustering of applications with noise (DBSCAN) clustering, principal component analysis, etc. The set of training domains may be preset.

[0082] At 940, a predictive model is determined based at least in part on the relationship between the training domain and the subdomain. In some embodiments, a machine learning process is used to determine the predictive model. The predictive model is determined to provide an estimate of an address (e.g., a predicted address) for a particular domain.

[0083] At 950, the domain corresponding to the DNS query is obtained. In some embodiments, the domain is determined in a manner similar to 810 of process 800 of Figure 8. For example, the domain is the top-level domain corresponding to the domain of the DNS query.

[0084] At 960, one or more records for subdomains of the domain are obtained. In some embodiments, one or more records for the domain are obtained in a manner similar to 820 of process 800 of FIG.

[0085] At 970, predicted target address information is determined. In some embodiments, determining predicted address information, such as to be used as target address information, is performed in a manner similar to system 500 of FIG. 5, process 730 of process 700 of FIG. 7, and 830 and 840 of process 800 of FIG. 8.

[0086] At 980, a determination is made as to whether process 900 is complete. In some embodiments, process 900 is determined to be complete in response to a determination that no further address information needs to be determined for the domain, an administrator indicates that process 900 should be paused or stopped, etc. In response to a determination that process 900 is complete, process 900 terminates. In response to a determination that process 900 is not complete, process 900 returns to 910.

[0087] Various examples of the embodiments described herein are described with reference to flowcharts. Although the examples may include some steps performed in a particular order, according to various embodiments, various steps may be performed in different orders and / or various steps may be combined into a single step or in parallel.

[0088] Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not limiting.

Claims

1. A system comprising one or more processors and a memory, The one or more processors: receiving instructions to obtain target address information for a domain; generating predicted target address information for queries of the domain based at least in part on querying a machine learning model; and providing the predicted target address information as the target address information for the domain; It is structured as follows: The memory includes: a processor coupled to the processor and providing instructions to the processor; It is configured as follows: system.

2. The one or more processors further In response to receiving a DNS query, querying a predictive cache to obtain predicted target information for the domain associated with the DNS query; and and determining the predicted target address information using the machine learning model in response to determining that the predictive cache does not currently store target address information. It is structured as follows: the predicted target address information is provided to a client device. The system of claim 1 .

3. the machine learning model determines the predicted target address information without transmitting the received DNS query to an authoritative server corresponding to a domain associated with the DNS query. The system of claim 1 .

4. determining the predicted target address information using the machine learning model, obtaining top-level domain information for the domain associated with the DNS query; and generating address information for one or more sub-level domains related to the domain associated with the DNS query; Including, the address information for one or more sub-level domains is inferred based, at least in part, on the machine learning model; The system of claim 1 .

5. The top-level domain information is obtained at least in part based on querying a database storing registered users or assignees of Internet resources; The system of claim 4.

6. The one or more processors further In response to receiving a DNS query, querying a prediction cache to obtain predicted target information for the domain associated with the DNS query; and blocking the DNS query in response to determining that the predictive cache does not currently store the target address information. It is configured as follows: The system of claim 1 .

7. the DNS queries are blocked based, at least in part, on a configuration set by an administrative user; The system of claim 6.

8. The predicted target address information is stored in a prediction cache; and the predictive cache stores a set of target addresses that are predicted based at least in part on corresponding top-level domain information; The system of claim 1 .

9. the records included in the prediction cache are generated using a machine learning process; The system of claim 8.

10. The one or more processors further In response to receiving a DNS query, determining whether to retrieve target information corresponding to the domain from a predictive cache. It is structured as follows: Determining whether to obtain target address information corresponding to a DNS query from a predictive cache includes: Determining a query frequency for a domain associated with a DNS query; and comparing the query frequency to a frequency threshold; Including, The system of claim 1 .

11. The one or more processors further responsive to determining that the query frequency meets the frequency threshold, querying a corresponding authoritative DNS server for the target address information; It is configured as follows: The system of claim 10.

12. The one or more processors further determining, in response to determining that the query frequency does not satisfy the frequency threshold, to obtain the target address information from the predictive cache; It is configured as follows: The system of claim 10.

13. if the target address information provided in response to a DNS query is obtained from a predictive cache, the DNS query is not communicated to an authoritative server corresponding to a domain associated with the DNS query; The system of claim 1 .

14. The one or more processors further In response to receiving the DNS query, determine whether to retrieve target information corresponding to the DNS query from the predictive cache; It is structured as follows: Determining whether to obtain target address information corresponding to a DNS query from the predictive cache includes: determining whether the DNS query corresponds to suspicious traffic; and determining that the target address information is obtained from the predictive cache in response to determining that the DNS query corresponds to suspicious traffic; Including, The system of claim 1 .

15. Determining whether the DNS query corresponds to suspicious traffic includes: providing the DNS query to a suspicious traffic detector; The system of claim 14 , comprising:

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

17. the predictive cache is contained within a DNS resolver; The system of claim 2 .

18. the predicted target address information is provided as the target address information for the domain in response to a DNS query. The system of claim 1 .

19. 1. A method comprising: receiving an instruction to obtain target address information for a domain; generating predicted target address information for the domain based at least in part on querying the machine learning model; providing the predicted target address information as the target address information for the domain; A method comprising:

20. A computer program stored on a non-transitory computer-readable medium, the computer program comprising computer instructions; When executed, the instructions cause the computer to: receiving an instruction to obtain target address information for a domain; generating predicted target address information for the domain based at least in part on querying the machine learning model; providing the predicted target address information as the target address information for the domain; A computer program that performs the above.

Images