Predictive DNS Cache for Improving Security and Performance

Abstract

The present application discloses a method, system, and computer system for predicting a response to a DNS query, the method including: receiving a DNS query from a client device, the DNS query including a subdomain portion and a root domain portion; determining whether to obtain target address information corresponding to the DNS from a predictive cache in response to determining to obtain target address information from a predictive cache; obtaining the target address information from the predictive cache; and providing the target address information to the client device.

Description

Background Art

[0001] Malicious individuals attempt to compromise computer systems in various ways. As one example, such individuals may embed malicious software (“malware”) in an email attachment or otherwise include it and send or cause to be sent the malware 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, the malware can turn the compromised computer into a “bot” in a “botnet” that receives instructions and / or reports data from a command and control (C&C) server under the control of a malicious individual. One approach to reducing the damage caused by malware is for a security company (or other appropriate entity) to attempt to identify the malware and prevent it from reaching / being executed on end-user computers. Another approach is to attempt to prevent a compromised computer from communicating with a 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. Accordingly, there remains a need for improved techniques for detecting malware and preventing its harm.

Brief Description of the Drawings

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

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

[0003] The present invention can be implemented in a number of ways, including a process, an apparatus, a system, a composition, a computer program product embodied on a computer-readable storage medium, and / or instructions stored in a memory and / or executed by a processor coupled to the memory and / or provided by a processor configured to execute the instructions. As used herein, these implementations, or any other form that the present invention may take, may be referred to as a technique. Generally, the order of steps of the disclosed process may be changed within the scope of the present invention. Unless otherwise specified, components such as a processor or a memory described as being configured to perform a task are implemented as a general-purpose component temporarily configured to perform the task at a given time or as a specific component 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 the accompanying drawings that illustrate the principles of the present invention. The present invention is described in relation to such embodiments, but the present invention is not limited to any particular embodiment. The scope of the present invention is limited only by the claims and the present invention includes numerous alternatives, modifications, and equivalents. In order to provide a complete understanding of the present invention, numerous specific details are set forth in the following description. These details are provided for illustrative purposes only and the present invention may be practiced in accordance with the claims without some or all of these specific details. Technical material known in the technical field related to the present invention is not 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. The system includes one or more processors and a memory. The one or more processors are configured to receive a DNS query, determine whether to obtain target address information corresponding to the DNS query from a prediction cache, obtain the target address information from the prediction cache in response to determining to obtain the target address information from the prediction cache, and provide the target address information to a client device.

[0006] DNS tunneling is popular among data exfiltration attackers because most networks generally permit DNS traffic and do not provide secure control over DNS traffic. Controlling DNS traffic is difficult because most DNS traffic is generally benign and the traffic patterns of DNS traffic are diverse. For example, systems generally do not provide a mechanism for preventing malicious low-speed tunneling, such as the use of many queries, each containing a small amount of malicious information (e.g., on the order of 1 byte), but providing a large amount of malicious information as a whole. Queries from malicious clients (e.g., infected clients) generally communicate in an encoded stream. Further, the address information in response to a query is often not stored in a legacy cache, and in response to a decision that the legacy cache does not store such address information, the data is transferred to an authoritative nameserver. It is generally the intention of the malicious party behind the attack to cause malicious traffic to be transferred to the authoritative nameserver. Conversely, a benign client communicating a DNS query does not consider how the response information is generated or where such information is obtained. Rather, the benign client simply desires a timely response containing accurate address information (e.g., an IP address). Various embodiments implement a predictive cache that estimates / predicts information in response to a DNS query to limit or eliminate the need for a query to an authoritative nameserver to resolve the address information of the DNS query. The use of the predictive cache thus prevents malicious traffic from being transferred to the authoritative nameserver and provides timely and accurate information in response to a benign DNS query.

[0007] According to various embodiments, a system and / or method for determining a response to a DNS query is provided. In some embodiments, the system uses a prediction cache to determine a response to a received DNS query. For example, the system determines target address information (e.g., address information estimated to respond to the DNS query) without accessing (e.g., querying) the authoritative name server (e.g., aDNS) of the domain included in the DNS query. In response to the determination that a response to the DNS query is generated using the prediction cache rather than a legacy cache or a query to an authoritative name server (e.g., address information responding to the DNS query is estimated), the prediction cache determines target address information corresponding to the DNS query. In some embodiments, the prediction cache stores prediction address information (e.g., prediction subdomains of various domains). In some embodiments, the prediction cache determines target address information (e.g., prediction address information responding to the DNS query) simultaneously with the DNS request. For example, in response to the determination that the prediction cache is used in connection with generating a response to a DNS query, the prediction cache obtains one or more records associated with the domain included in the DNS query, provides the one or more records to a model (e.g., a machine learning model), and obtains (e.g., determines) target address information corresponding to the DNS query. As an example, the target address information includes estimated address information of a specific domain included in the DNS query. In some embodiments, the one or more records associated with the domain are records regarding multiple subdomains of a specific top-level domain, such as the top-level domain of the domain included in the DNS query.

[0008] In some embodiments, the system obtains one or more records associated with the domain included in the DNS query, at least in part based on determining a set of domains associated with the top-level domain corresponding to the domain included in the DNS query. As one example, determining a set of domains associated with the top-level domain includes determining a set of domains that are lexically similar to a particular domain. For example, if a particular domain is "abc.root.com", the set of domains can 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 to be similar (e.g., lexically similar) to a particular domain based on a determination (e.g., calculation) of a value indicating a degree of similarity and a determination that the value indicating the degree of similarity is greater than a predefined 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 the set of domains to a model (e.g., a machine learning model) and uses that model to estimate the address information in response to the DNS query. As one example, the model uses the relationship and / or pattern of address information between the set of domains and / or a training set to estimate the address information in response to the DNS query.

[0009] Various embodiments determine whether to use a predictive cache in connection with a DNS query, at least in part based on a determination of whether the DNS query corresponds to suspicious traffic (e.g., whether the DNS query is suspicious or the device receiving 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 the traffic is suspicious. Examples of systems, methods, and / or devices used in analyzing traffic and / or determining whether the traffic is suspicious are provided in U.S. Patent Application No. 16 / 799,655, corresponding to U.S. Patent Application Publication No. 2021 / 0266293. U.S. Patent Application No. 16 / 799,655 is incorporated by reference in its entirety. In accordance with various embodiments, in response to a determination that traffic (e.g., a DNS query) corresponds to suspicious traffic, the system determines to use a predictive cache in connection with determining target address information (the address information that responds 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 query applicable authorities for the 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 considered suspicious traffic (e.g., the percentage of true traffic determined to be suspicious exceeds a traffic threshold).

[0010] In accordance with various embodiments, a system and / or method uses a model (e.g., a machine learning model) to estimate (e.g., predict) the structure of a domain and / or target address information in response to a DNS query. For example, a prediction cache may implement a machine learning model in relation to determining target address information. The model can be trained using various machine learning processes. Examples of machine learning processes that may be implemented in relation to training the model include random forest, linear regression, support vector machine, naive Bayes, logistic regression, K-nearest neighbor, decision tree, gradient boosted decision tree, K-means clustering, hierarchical clustering, density-based spatial clustering of applications with noise (DBSCAN) clustering, principal component analysis, and the like. In some embodiments, the model used in relation to estimating address information for a domain is trained using a set of training domains. The set of training domains can be pre-set. For example, the set of training domains can include a pre-selected set of domains (e.g., google.com, etc.) that are considered to be benign. In accordance with various embodiments, using a model to estimate address information includes obtaining records of subdomains of the domain associated with the DNS query (e.g., the top-level domain of the particular domain being queried), obtaining records of the set of training 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 for the particular domain included in the DNS query, and using a machine learning process to generate a model for estimating address information in response to the DNS query (e.g., for 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 that services one or more prediction caches.In response to a determination that a model is to be used to generate an estimated value of domain address information, a prediction cache can query a remote server (e.g., on which a machine learning model is implemented) about the estimated value (e.g., the predicted address information of the domain).

[0011] The prediction cache can be implemented at various locations on the network. For example, the prediction cache can be disposed on a DNS resolver. As another example, the prediction cache can be disposed on a firewall. As another example, the prediction cache is a service provided in a DNS resolver (e.g., the prediction cache is deployed on a remote server that services queries from a DNS resolver about the predicted address information of a domain).

[0012] The system improves the processing of DNS traffic (e.g., responses 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. Further, the system can provide accurate and low-latency responses to benign DNS traffic. Accordingly, the system prevents the spread of malicious traffic while providing the same level of service, or a better level of service, to genuine traffic (e.g., when the prediction cache stores the target information of DNS queries, querying the authoritative name server is not required).

[0013] FIG. 1 shows one example of an environment in which malware is detected, or suspected of being present, and its harm is reduced. In the example shown, client devices 104-108 are laptop computers, desktop computers, and tablets (respectively) that are present within enterprise network 110 (which belongs to “Acme Company”). Data appliance 102 is configured to enforce policies regarding communication between client devices, such as client devices 104 and 106, and nodes external to enterprise network 110 (e.g., reachable via external network 118). Examples of such policies include those that manage traffic shaping, quality of service, and traffic routing. Other examples of policies include security policies that require scanning for threats in incoming (and / or outgoing) email attachment files, 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 can be configured to operate in cooperation with remote security platform 140. Security platform 140 can provide various services, including performing static and dynamic analysis on malware samples and providing a list of signatures of known malicious files for data appliances such as data appliance 102 as part of a subscription. In various embodiments, the results of the analysis (and additional information regarding applications, domains, etc.) are stored in database 160. In various embodiments, security platform 140 comprises one or more dedicated commercially available hardware servers (e.g., a multi-core processor, 32G+ of RAM, a gigabit network interface adapter, and having a hard drive) that execute a typical server-class operating system (e.g., Linux®). Security platform 140 can be implemented across a scalable infrastructure that includes multiple such servers, solid state drives, and / or other applicable high-performance hardware. Security platform 140 can comprise several distributed components, including components provided by one or more third parties. For example, part or all of security platform 140 can be implemented using Amazon Elastic Compute Cloud (EC2) and / or Amazon Simple Storage Service (S3). Further, whenever security platform 140 is referred to as performing tasks such as storing or processing data, similar to data appliance 102, it should be understood that sub-components or multiple sub-components of security platform 140 can cooperate (either individually or in cooperation with third-party components) to perform that task. As one example, security platform 140 can optionally perform static / dynamic analysis in cooperation with one or more virtual machine (VM) servers.One example of a virtual machine server is a commercial server-class hardware (e.g., a multi-core processor, 32+ gigabytes of RAM, and one or more gigabit network interface adapters) that runs commercial virtualization software such as VMware ESXi, Citrix XenServer, or Microsoft Hyper-V. In some embodiments, the virtual machine server is omitted. Further, the virtual machine server may be under the control of the same entity that manages the security platform 140, or it may be provided by a third party. As one example, the virtual machine server can rely on EC2, and the remainder of the security platform 140 is provided by dedicated hardware owned by and under the control of the operator of the security platform 140.

[0015] According to various embodiments, the security platform 140 includes a DNS tunneling detector 138 and / or a prediction cache 170. In some embodiments, the prediction 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.

[0016] The detector module 172 is used in connection with determining whether to use a prediction cache in relation to a DNS query. In some embodiments, the detector module determines whether to obtain a predicted address in response to a DNS query, at least in part based on a determination of whether the DNS query corresponds to suspicious traffic. As an 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 obtain a predicted address in response to a DNS query, at least in part based on a latency setting corresponding to DNS traffic. The latency setting may be configurable at least in part based on the profile of the user or organization for which the DNS traffic is being processed (e.g., a customer's latency setting may be set at least in part based on the level of service provided to / agreed upon with the customer). In an implementation where the latency for responding to a DNS query is low, the prediction cache can be determined to obtain a predicted address (e.g., target address information) in response to the DNS query 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 the prediction cache (e.g., cache 178). In response to determining that the target address information was not previously determined and / or was not stored in the prediction cache, the detector module 172 determines to obtain the target address information based on predicting an address in response to the 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 the DNS query.Conversely, in response to the target address information having been previously determined by the prediction cache and / or having been determined to be stored in the prediction cache, the previously determined predicted address is used as the target address information.

[0017] The prediction engine 174 is used to predict address information corresponding to a domain, such as target address information that responds to a DNS query. In some embodiments, the 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 the machine learning model 176 to obtain the target address information corresponding to the domain. In some embodiments, the query to the machine learning model 176 includes one or more of an indication of a domain associated with the DNS query (e.g., a top-level domain), 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 a set of training domains. In some implementations, the machine learning model 176 is pre-trained, and the prediction 174 does not need to provide the set of training domains to the machine learning model 176 at the same time as the query for the target address information.

[0018] The machine learning model 176 predicts address information corresponding to a specific domain, at least in part based on the model. As one example, the model is stored in advance and / or trained in advance. The model can be trained using various machine learning processes. Examples of machine learning processes that can be implemented in connection with training the model include random forest, linear regression, support vector machine, naive Bayes, logistic regression, k-nearest neighbor, decision tree, gradient boosted decision tree, k-means clustering, hierarchical clustering, density-based spatial clustering of applications with noise (DBSCAN) clustering, principal component analysis, and the like. According to various embodiments, the machine learning model 176 uses the relationship and / or pattern of address information between a set of domains and / or a training set to estimate the address information in response 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 a set of top-level domain information, and uses the set of relationships between the one or more subdomains and the one or more top-level domains to generate a prediction model for predicting the target address information of a DNS query. In response to predicting the target address information of a DNS query, the predicted target address information is stored in a prediction cache 170, such as the cache 178.

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

[0020] Returning to FIG. 1, assume that a malicious individual (using System 120) creates malware 130. The malicious individual wants a client device, such as client device 104, to execute a copy of malware 130, exposing the client device to danger and causing the client device to become a bot within a botnet. The exposed client device can then be instructed to perform tasks (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 tasks, etc.) to an external entity, such as command and control (C&C) server 150, and, where applicable, receive instructions from C&C server 150.

[0021] Malware 130 can attempt to directly communicate with C&C server 150 to a client device exposed to danger (e.g., by causing the client to send an email to the C&C server 150), but such obvious communication attempts can be flagged as suspicious / harmful (e.g., by data appliance 102) and blocked. Instead, increasingly, malware authors are using a technique called DNS tunneling herein. DNS is a protocol that converts 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 the client-server model. In one example of an attack, an attacker registers a domain such as badsite.com. The domain's name server points to the attacker's server where the tunneling malware program is installed. The attacker infects a computer. Since DNS requests are conventionally permitted to move in and out of security devices, the infected computer is permitted to send a query to the DNS resolver (e.g., for kj32hkjqfeuo32ylhkjshdflu23.badsite.com, where the subdomain portion of the query encodes information for consumption by the C&C server). The 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 where the tunneling program is installed. Now, a connection is 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 various reasons. The first reason is explained in FIG. 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 sub - domain portion of domain names to encode information to assist in supporting the use of those legitimate services. The encoding patterns used by such legitimate services vary widely among providers, and (as shown in FIG. 3) benign sub - domains may appear visually indistinguishable from malicious sub - domains. The second reason is that, unlike other areas (e.g., computer research) that have large corpora of both known benign training set data and known malicious training set data, the training set data for DNS queries is highly skewed (e.g., having millions of benign root domain examples and a very small number of malicious examples). Despite such difficulties, and using the techniques described herein, malicious DNS tunneling can be efficiently detected and stopped in real - time.

[0023] The environment shown in FIG. 1 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 other devices, such as computing assets located within network 110 and those located within other networks (e.g., networks 114 and 116)). DNS server 126 is publicly accessible but under the control of the malicious operator of the C&C server 150. The 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 applicable domain names.

[0024] As described above, in order 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 the corresponding Internet Protocol (IP) address. One way such resolution can be performed is for client device 104 to forward a request to DNS server 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, in order to connect to malicious C&C server 150, client device 104 needs to resolve the domain "kj32hkjqfeuo32ylhkjshdflu23.badsite.com" to the corresponding Internet Protocol (IP) address. In this example, malicious DNS server 126 has authority for *.badsite.com, and the request from client device 104 is forwarded to DNS server 126 for resolution (e.g.), ultimately enabling C&C server 150 to receive data from client device 104.

[0025] 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 malicious DNS tunneling and / or to prevent connections to malicious DNS servers (e.g., by client devices 104 - 108). DNS module 134 is integrated into appliance 102 (as shown in FIG. 1) and, in various embodiments, can also operate as a stand-alone appliance. And, similar to the other components shown in FIG. 1, DNS module 134 is provided by the same entity that provides appliance 102 (or security platform 140) and can also be provided by a third party (e.g., different from the provider of appliance 102 or security platform 140). Further, in addition to preventing connections to malicious DNS servers, DNS module 134 can take other actions such as individualized logging of tunneling attempts made by clients (indicating that a given client is at risk 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, the DNS module 134 uses the domain as a query to the security platform 140. This query can be executed simultaneously with the resolution of the domain (e.g., simultaneously with requests sent to DNS servers 122, 124, and / or 126, and to the security platform 140). As an example, the DNS module 134 can send a query (e.g., in JSON format) to the front end 142 of the security platform 140 via a REST API. Using the processes described in more detail below, the security platform 140 determines whether the queried domain exhibits an attempt at malicious DNS tunneling (e.g., using the DNS tunneling detector 138), and then returns and provides the result (e.g., "malicious DNS tunneling" or "non-tunneling") to the DNS module 134.

[0027] In various embodiments, the DNS tunneling detector 138 (implemented either on the security platform 140, on the data appliance 102, or at any other suitable location / location combination) uses a two - pronged approach when identifying malicious DNS tunneling. The first approach uses an 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 can occur. To block the first DNS tunneling packet, the similarity detector 144 complements the anomaly detector 146 and extracts signatures from the 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 similar to the detected root domain.

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

[0029] The DNS tunneling detector 138 maintains, for each appliance (where data is received), a set of fully qualified domain names (FQDNs) that are grouped with respect to those root domains (collectively shown in FIG. 1 as domain profiles 156). (Grouping by root domain is generally described herein, but it should be understood that the techniques described herein can also be extended to any level of domain.) In various embodiments, information regarding received queries for a given domain is persisted within the profile for a fixed amount of time (e.g., a 10-minute sliding time window).

[0030] As one example, DNS query information received from data appliance 102 for various foo.com sites is grouped as follows (into the domain profile for root domain foo.com). G(foo.com) = [mail.foo.com, coolstuff.foo.com, domain234.foo.com]. A second root domain will 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 using a set of characteristics unique to malicious DNS tunneling, such that even if benign DNS patterns are diverse (e.g., k2jh3i8y35.legitimatesite.com, xxx888222000444.otherlegitimatesite.com), the likelihood that they will be misclassified as malicious tunneling is very low. The following are exemplary characteristics that can be extracted as features for a given group of domains (i.e., those sharing a root domain) (e.g., into a feature vector).

[0031] Figure 2 is a block diagram of a system that provides predicted addresses, according to various embodiments of the present application. According to various embodiments, system 200 is implemented in connection with system 100 of FIG. 1, such as for predicted cache 170. In various embodiments, system 200 is implemented in connection 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 at various locations on a network. For example, the predicted cache may be located on a DNS resolver. As another example, the predicted cache may be located on a firewall. As another example, the predicted cache is a service provided to a DNS resolver (e.g., the predicted cache is located on a remote server that services queries from the DNS resolver for predicted address information for domains).

[0033] In the example shown, system 200 implements one or more modules related to predicting an address corresponding to a domain, such as for predicting and / or providing target address information in response to a DNS query. 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.

[0034] In some embodiments, system 200 includes a communication module 225. System 200 uses communication module 225 to communicate with user systems such as various client terminals or administrator systems. For example, communication module 225 provides the information to be communicated to communication interface 205. As another example, communication interface 205 provides the 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 a firewall, a DNS resolver, etc. Communication 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 the configuration of a model (e.g., a machine learning model), the indication of 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 permitted to be sent to an aDNS to which the query is applicable), 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 at least partially based on, or for which a response to a DNS query should not be provided, an address predicted for the DNS query).

[0035] In some embodiments, system 200 includes a detector module 230. System 200 uses detector module 230 in connection with determining whether a DNS query corresponds to suspicious traffic 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 a predicted address for a domain (e.g., a specific domain corresponding to a DNS query). System 200 can manage a model (e.g., a machine learning model) via model module 235. Model module 235 determines a model that is used to generate a predicted address 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 an address. 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 a predicted address in response to a DNS query. Model update module 240 can be updated using records for one or more domains, such as domains considered benign (e.g., google.com, Microsoft.com, apple.com, etc.). As one example, model update module 240 obtains zone file information related to one or more domains (e.g., from a trusted aDNS).

[0038] 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 that responds to a DNS query. For example, prediction module 245 uses model module 235 in connection with predicting target address information in response to a particular DNS query and / or determines 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 the predicted address (e.g., so that system 200 provides such a predicted address as target address information in response to a DNS query). In some implementations, prediction module 245 corresponds to, or is similar to, prediction engine 174.

[0039] 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 the DNS query. As another example, query response module 250 provides target address information to a DNS resolver, a client from which the 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 in response to the system 200 determining that the 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, prediction 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 data sets (e.g., one or more data sets for one or more tenants, etc.). File system data 260 includes data sets for training machine learning processes, historical information regarding DNS queries, a white list of domains considered to be safe (e.g., not suspicious), a black list of domains corresponding to traffic considered to be suspicious or malicious, information associated with suspicious or malicious traffic such as trends or relationships, data of information associated with secure or safe traffic such as trends or relationships, etc.

[0042] Model data 262 includes data regarding one or more models. As one example, data regarding one or more models includes relationships and associations between domains (e.g., top-level domains, sub-domains, etc.) and address information such as IP addresses. Model data 262 can store information regarding one or more machine learning processes and / or configurations for implementation of one or more machine learning processes to predict address information.

[0043] Prediction cache data 264 includes address information predicted for one or more domains. As one example, prediction cache data 264 stores predicted address information determined for one or more previous DNS queries.

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

[0045] According to various embodiments, the memory 220 includes execution application data 275. The execution application data 275 includes data that is 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 an embodiment, the application includes one or more applications that perform one or more of receiving and / or executing a query or task, generating a report and / or constructing information in response to an executed query or task, and / or providing information in response to a query or task to a user. Other applications include any other suitable applications (e.g., an index maintenance application, a communication application, a machine learning model application, an application for detecting suspicious traffic, a document creation application, a report creation application, a user interface application, a data analysis application, an anomaly detection application, a user authentication application, etc.).

[0046] FIG. 3 is a diagram of a system for using a prediction cache in connection with responding to a domain name system (DNS) query. According to various embodiments, the system 300 is implemented in relation to the system 100 and / or the system 200 of FIG. 2. In various embodiments, the system 300 is implemented in relation to the process 600 of FIG. 6, the process 700 of FIG. 7, the process 800 of FIG. 8, and / or the process 900 of FIG. 9.

[0047] In the example shown in FIG. 3, traffic is generated at the infected client 310 and sent to the 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, instead of sending the DNS traffic to the DNS tunneling server 340 associated with querying the aDNS, the DNS resolver 320 sends the traffic to the prediction cache 350. For example, the DNS resolver 320 determines to use the prediction 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 prediction cache 350 to obtain target address information for responding to the DNS query, at least in part based on the determination that the DNS query communicated from the infected client 310 corresponds to suspicious traffic or malicious traffic. In response to receiving the query from the DNS resolver 320, the prediction cache 350 determines (e.g., predicts) the address information corresponding to the domain indicated by the query. In some embodiments, the prediction cache 350 uses a machine learning model to predict the address information corresponding to the domain. In response to the determination of the predicted address, the prediction cache 350 returns the predicted address to the infected client 310 (e.g., the DNS resolver 320) as the target address information for responding to the DNS query.

[0048] FIG. 4 is a diagram related to a system for determining to use a prediction cache in relation to responding to a DNS query. According to various embodiments, the system 400 is implemented in relation to the system 100 and / or the system 200 of FIG. 2. In various embodiments, the system 400 is implemented in relation to the process 600 of FIG. 6, the process 700 of FIG. 7, the process 800 of FIG. 8, and / or the process 900 of FIG. 9.

[0049] In the example shown in FIG. 4, DNS query 410 communicates with a network such as a DNS resolver. As 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, the detector 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 a domain. In response to determining the predicted address, prediction cache 430 returns the predicted address as the target address information to respond to DNS query 410.

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

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

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

[0054] In response to the decision that the DNS query corresponds to trusted traffic, in step 2a, the traffic is directed to the 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 the decision that the DNS query corresponds to untrusted traffic, in step 2b, the traffic is directed to the prediction cache to obtain predicted address information.

[0056] In response to receiving a query for address information, in step 3, the prediction cache obtains 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 prediction cache requests (e.g., obtains past resolutions of the top-level domain) from applicable passive DNS records for other subdomains of the top-level domain corresponding to the DNS query. As an example for illustration, in the case of the top-level domain "root.com", the prediction cache obtains all records of the subdomains under "root.com" from passive DNS. In some embodiments, the prediction cache determines a set of subdomains that are lexically similar to the domain included in the DNS query, and 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 prediction cache provides to the machine learning model the address information obtained from passive DNS, the address information related to the training set (e.g., address information of subdomains of various benign domains), and / or the address information corresponding to the set of subdomains that are lexically similar to the domain included in the DNS query.

[0058] In step 5, the prediction cache uses a machine learning model to predict the address information of the domain included in the DNS query. In some embodiments, the machine learning model is pre-trained based on the relationship between the subdomain and the domain, and / or the address information corresponding to the subdomain previously resolved for the top-level domain. The machine learning model uses a machine learning process to predict the address information (e.g., IP address) of the domain included in the DNS query. In response to the machine learning model that determines the predicted address information, the prediction cache provides the predicted address information as the target address information for responding to the DNS query. As an example, the prediction cache provides the predicted address information to the DNS resolver, and the DNS resolver then provides such information as the target address information to the client from which the DNS query was sent.

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

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

[0061] At 620, it is determined to obtain target address information from the prediction cache. As an example, the target address information corresponds to the address for responding to the DNS query. In some embodiments, the system determines to obtain target address information from the prediction 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 the prediction 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., in response to receiving a DNS query, the prediction cache estimates the predicted address). In some embodiments, the predicted address is obtained from a storage device when address information corresponding to a domain has been previously estimated, etc.

[0063] At 640, target address information is provided. In response to obtaining target address information from the prediction cache, the target address information is communicated in response to a DNS query. For example, the system provides the target address information to the client from which the DNS query was sent.

[0064] At 650, a determination is made as to whether process 600 has been 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) should be processed, and the administrator indicates that process 600 should be paused or stopped, etc. In response to a determination that process 600 has been completed, process 600 ends. In response to a determination that process 600 has not been completed, process 600 returns to 610.

[0065] FIG. 7 is a flowchart of a method for using a prediction cache in connection with responding to a DNS query. In accordance with 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 traffic that is suspicious. 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: detection of anomalies in the 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 retrieved from the prediction cache. In some embodiments, retrieving target information from the prediction cache is performed in the same or a similar manner as 630 of process 600 of FIG. 6.

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

[0070] At 780, a determination is made as to whether process 700 has been 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) should be processed, and the administrator indicates that process 700 should be paused or stopped, etc. In response to a determination that process 700 has been completed, process 700 ends. In response to a determination that process 700 has not been completed, process 700 returns to 710.

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

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

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

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

[0075] 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 estimated value of address information corresponding to a domain. As one example, the model is a machine learning model that implements a machine learning model to generate a 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 passive DNS (e.g., PDNS), and / or (ii) a set of records for a list of domains of lexically similar subdomains from 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., the predicted address estimated using the model), the target address information is communicated to a client or the like in response to a DNS query. For example, the system provides the target address information to the client from which the DNS query was originated.

[0077] At 860, a determination is made as to whether process 800 has completed. In some embodiments, process 800 is determined to have completed in response to a determination that no further address information needs to be determined for a domain, and the administrator indicates that process 800 should be paused or stopped, etc. In response to a determination that process 800 has completed, process 800 ends. In response to a determination that process 800 has not completed, process 800 returns to 810.

[0078] FIG. 9 is a flowchart relating to 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 a benign domain and corresponding sub-domains. The set of domains and corresponding sub-domains can be determined based on a selection, such as a selection by an administrator of the prediction system (e.g., the model developer) or configuration. As one example, the plurality of training domains correspond to domains that are considered to be reliable or benign.

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

[0081] At 930, a plurality of records are used to determine the relationship between the training domain and the sub-domain. In some embodiments, a machine learning process is used for the relationship between the training domain and the sub-domain, at least in part, based on the plurality of records for the plurality of training domains. Examples of machine learning processes that can be implemented in connection with training the model include random forest, linear regression, support vector machine, naive bayes, logistic regression, K-nearest neighbor, decision tree, gradient boosted decision tree, K-means clustering, hierarchical clustering, density-based spatial clustering of applications with noise (DBSCAN) clustering, principal component analysis, etc. The set of training domains can be pre-set.

[0082] At 940, a prediction model is determined based at least in part on the relationship between the training domain and the sub - domain. In some embodiments, a machine learning process is used to determine the prediction model. The prediction model is determined to provide an estimated value 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 in FIG. 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 the sub - domain 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 in FIG. 8.

[0085] At 970, prediction target address information is determined. In some embodiments, determining prediction address information such as that used as target address information is performed in a manner similar to system 500 of FIG. 5, process 730 of process 700 in FIG. 7, and 830 and 840 of process 800 in 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 for the domain needs to be determined, and the administrator indicates that process 900 should be paused or stopped, etc. In response to a determination that process 900 is complete, process 900 ends. In response to a determination that process 900 is not complete, process 900 returns to 910.

[0087] The various examples of the embodiments described herein are explained in relation to flowcharts. An example may include several steps to be executed in a specific order, but according to various embodiments, the various steps may be executed in various orders and / or the various steps may be combined into a single step or in parallel.

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

Claims

1. A system comprising one or more processors and a memory, wherein the one or more processors: receive a DNS query; determine whether to obtain target address information corresponding to the DNS query from a prediction cache; in response to determining to obtain the target address information from the prediction cache, obtain the target address information from the prediction cache and, provide the target address information to a client device; use a machine learning model to determine predicted target address information and, provide the predicted target address information to the client device, and is configured to: Using the machine learning model to determine the predicted target address information includes: obtaining top-level domain information regarding a domain associated with the DNS query, and generating address information for one or more subdomains related to the domain associated with the DNS query; The machine learning model: uses a machine learning process to analyze a set of relationships between the one or more subdomains and one or more top-level domains included in the set of top-level domain information, and generates a prediction model for predicting target address information of a DNS query using the set of relationships between the one or more subdomains and the one or more top-level domains; and is configured to: At least partially based on the machine learning model, address information for one or more subdomains is estimated; The memory: is coupled to the processor and provides instructions to the processor, and is configured to: System.

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

3. The top-level domain information is obtained at least partially based on querying a database storing registrations of users or assignees of Internet resources. The system according to claim 1.

4. The one or more processors are further configured to: block the DNS query. The system according to claim 1, configured as such.

5. The DNS query is blocked, at least in part, based on a configuration set by a managing user. The system according to claim 4.

6. The prediction cache stores a set of target addresses that are estimated, at least in part, based on corresponding top-level domain information. The system according to claim 1.

7. The prediction cache is generated using a machine learning process. The system according to claim 1.

8. When the target address information is obtained from the prediction cache, the DNS query is not communicated to an authoritative server corresponding to the domain associated with the DNS query. The system according to claim 1.

9. Determining whether to obtain target address information corresponding to the DNS query from the prediction cache includes determining whether the DNS query corresponds to suspicious traffic, and in response to determining that the DNS query corresponds to suspicious traffic, determining that the target address information should be obtained from the prediction cache. The system according to claim 1, including the above.

10. Determining whether the DNS query corresponds to suspicious traffic includes providing the DNS query to a suspicious traffic detector. The system according to claim 9, including the above.

11. The DNS query is determined to correspond to suspicious traffic, at least in part, based on whether the corresponding DNS is trustworthy or untrustworthy. The system according to claim 9.

12. The prediction cache is included in a DNS resolver. The system according to claim 1.

13. A method comprising: receiving, from a client device, a DNS query including a subdomain part and a root domain part; determining whether to obtain target address information corresponding to the DNS query from a prediction cache; and in response to determining to obtain the target address information from the prediction cache, obtaining the target address information from the prediction cache. providing the target address information to the client device; using a machine learning model to determine predicted target address information; providing the predicted target address information to the client device; comprising; the step of using the machine learning model to determine the predicted target address information comprises: obtaining top-level domain information regarding a domain associated with the DNS query, and generating address information for one or more subdomains related to the domain associated with the DNS query; the machine learning model is configured to: use a machine learning process to analyze a set of relationships between the one or more subdomains and one or more top-level domains included in the set of top-level domain information, and generate a prediction model for predicting target address information of a DNS query using the set of relationships between the one or more subdomains and the one or more top-level domains; wherein; address information for one or more subdomains is estimated at least partially based on the machine learning model; a method.

14. A computer program stored on a non-transitory computer-readable medium, comprising computer instructions that, when executed by a computer, cause the computer to: receive, from a client device, a DNS query comprising a subdomain portion and a root domain portion; determine whether to obtain target address information corresponding to the DNS query from a prediction cache; in response to determining to obtain the target address information from the prediction cache, obtain the target address information from the prediction cache; provide the target address information to the client device; use a machine learning model to determine predicted target address information; provide the predicted target address information to the client device; and cause the computer to perform; the step of using the machine learning model to determine the predicted target address information comprises: ​ obtaining top-level domain information regarding a domain associated with the DNS query, and generating address information for one or more subdomains related to the domain associated with the DNS query, wherein the machine learning model uses a machine learning process to analyze a set of relationships between the one or more subdomains and one or more top-level domains included in the set of top-level domain information, and generates a prediction model for predicting target address information of a DNS query using the set of relationships between the one or more subdomains and the one or more top-level domains, is configured to estimate address information for one or more subdomains, at least in part based on the machine learning model, a computer program.

Images