DNS request obfuscation

Abstract

The DNS request obfuscation includes generating a bait domain name system (DNS) request for obfuscating DNS request activity processed by a private DNS server for organization, and sending the bait DNS request to an external DNS server (s) for parsing, receiving a DNS request seeking a DNS lookup for a client device, the DNS requests are confused by sending to an external DNS server of the external DNS server (s) a DNS request mixed with at least some of the generated bait DNS requests sent to the external DNS server, receiving a DNS response to the sent DNS request from the external DNS server, and providing the DNS response to a source of the DNS request.

Description

Background Art

[0001] When a user interacts with a client device to enter a website address (sometimes a text string called a Uniform Resource Locator (URL)) into the address box of a web browser on the client device, a DNS request for a Domain Name System (DNS) lookup frequently occurs on the network-connected client device. Typically, a DNS request is sent from the client device to a DNS server, which searches for and locates the Internet Protocol (IP) address that is mapped to the entered text string (more specifically, to the specific domain name present in the string). This activity is called resolution. The IP address is identified to the web browser via the response to the DNS request, and the browser then sends a Hypertext Transfer Protocol (HTTP) request to the server identified by the IP address. The HTTP request is a request for the server to provide the client with a copy of the requested website. If the request is approved, the server sends the data to the web browser, which then assembles the data received from the server into a completed website that the user can view. This is how modern web browsing typically works. Summary of the Invention

[0002] A computer-implemented method is provided to overcome the shortcomings of the prior art and provide additional advantages. The method generates decoy DNS requests for obfuscating Domain Name System (DNS) request activity processed by a private DNS server for an organization and sends the decoy DNS requests to one or more external DNS servers for resolution. The process comprises receiving a DNS request seeking a DNS lookup for a client device by the private DNS server. The method obfuscates the DNS request by sending a DNS request interspersed with at least some of the generated decoy DNS requests sent to the external DNS server to an external DNS server of the one or more external DNS servers. In addition, the method receives a DNS response to the sent DNS request from the external DNS server. The method also provides the DNS response to the source of the DNS request.

[0003] Furthermore, a computer system is provided that includes a memory and a processor in communication with the memory, wherein the computer system is configured to perform a method. The method generates decoy DNS requests for obfuscating Domain Name System (DNS) request activity processed by a private DNS server for an organization, and sends the decoy DNS requests to one or more external DNS servers for resolution. The process comprises receiving a DNS request seeking a DNS lookup for a client device by the private DNS server. The method obfuscates the DNS request by sending a DNS request to an external DNS server of the one or more external DNS servers that is mixed with at least some of the generated decoy DNS requests sent to the external DNS server. In addition, the method receives a DNS response to the sent DNS request from the external DNS server. The method also provides the DNS response to the source of the DNS request.

[0004] In addition, a computer program product is provided that includes a computer-readable storage medium that is readable by a processing circuit and stores instructions for execution by the processing circuit for performing a method. The method generates decoy DNS requests for obfuscating Domain Name System (DNS) request activity processed by a private DNS server for an organization, and sends the decoy DNS requests to one or more external DNS servers for resolution. The process comprises receiving a DNS request seeking a DNS lookup for a client device by the private DNS server. The method obfuscates the DNS request by sending a DNS request to an external DNS server of the one or more external DNS servers that is mixed with at least some of the generated decoy DNS requests sent to the external DNS server. In addition, the method receives a DNS response to the sent DNS request from the external DNS server. The method also provides the DNS response to the source of the DNS request.

[0005] Additional features and advantages are realized through the concepts described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The aspects described herein are particularly pointed out and distinctly claimed as examples in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the present disclosure will become apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0007] Figure 1 Depicts an example computing environment for incorporating and / or using aspects described herein;

[0008] Figure 2 Depicts a sample environment for DNS request obfuscation;

[0009] Figure 3Describes further details of an example DNS obfuscator module for incorporating and / or using aspects described herein; and

[0010] Figure 4 Depicted is an example process for DNS request obfuscation according to aspects described herein. DETAILED DESCRIPTION

[0011] The problem with the DNS resolution methods described above (particularly the problem of providing DNS requests to DNS server(s) for resolution) is that these DNS server(s) know which websites are being requested and the timing of these requests. Thus, an observer of DNS activity can gain an understanding of potentially sensitive information, such as a user's browsing habits, including the timing and frequency of internet activity, the content the user is requesting and viewing, and the user's location based on the IP addresses of DNS requests. As another example, a given web page might be uniquely identified via a "signature" of the set of domains resolved (and potentially the order of those resolutions, if sufficient knowledge is available about a given web browser implementation). Consider a given web page that links to images or other web-based artifacts (some of which may be hosted on other domains). Further identification is possible if an attacker can watermark the given web page with additional (possibly hidden) web resources that need to be resolved in order to render the web page. This is a similar technique to "tracking pixels," except that it is based on inserting a small or invisible element on a web page originating from a unique domain. These are just a few examples of how DNS request activity can be compromised against a user. Users can trust DNS servers not to provide user data to third parties. However, the motives of the DNS server owner may be malicious, for example, they may sell DNS request data to third parties or, as previously mentioned, conduct eavesdropping. Besides malicious behavior by the DNS server itself, there are other ways to compromise the security and sensitivity of this external service. For example, the external DNS server itself could be compromised by a malicious actor, or a malicious actor could observe network traffic flowing to and from the DNS server.

[0012] Described herein is a method for DNS request resolution, including obfuscation of DNS requests that are made by (one or more) clients on a private network and are sent to an external DNS server for resolution. For example, a method is provided for anonymizing DNS requests and making them more private by means of DNS request obfuscation, which obfuscates user DNS request data so that third parties, including those operating external DNS servers, cannot accurately identify user browsing trends and other sensitive data that may otherwise be collected from user DNS requests. In some aspects, a system with (one or more) private DNS servers is used to obfuscate legitimate client DNS requests within the noise of decoy requests, which are generated and sent for external resolution but are not actual legitimate DNS requests from the requesting user device. If subsequent legitimate DNS requests are received for those resolved legitimate or decoy requests, the responses to the legitimate DNS requests and the decoy requests can be stored in (one or more) local DNS caches of (one or more) private DNS servers. Storing the results in the local cache for at least a period of time will avoid the need to send future external requests to external sources for the same resolution.

[0013] Obfuscation activities as described herein help anonymize and obfuscate legitimate DNS requests made from client computers, thereby making it difficult or impossible for outsiders to snoop on "meaningful" legitimate requests made by those clients. Even in other approaches where client traffic flows through the encrypted communication tunnel of a virtual private network (VPN) connection to reach its destination, client DNS requests can still be read by the DNS servers relied upon by the VPN host. Therefore, even if the client connection to the network is secure, the VPN's DNS servers can still be trusted to have a completely secure connection. In contrast, the aspects described herein reduce the need for trustworthiness of the external DNS server(s) used by obfuscating the data (DNS requests) sent to the external DNS servers with noise in the form of decoy DNS requests. All data (e.g., resolutions) returned based on these outgoing legitimate and decoy DNS requests is thus secure and anonymous, greatly reducing the ability of someone to snoop on legitimate DNS requests made from clients exploiting the DNS obfuscation. Various aspects also provide credible deniability by making it difficult to trace individual DNS requests made at a specific point in time back to a single user or IP. Furthermore, because resolutions to both legitimate and decoy DNS requests can be cached locally and anonymized, this enables a reduction in the time it takes to complete a DNS lookup because resolution of future DNS requests can first be attempted against the local DNS cache(s) before determining that an external DNS request (e.g., to a public DNS server) is required.

[0014] Thus, aspects described in further detail herein can provide secure communication to servers, conceal browsing activity in a steady stream of upstream lookups, distribute DNS requests to multiple different upstream servers, and add noise in the form of decoy DNS requests to obscure legitimate DNS requests made by actual users. As the number of users of the solution increases, the solution becomes more robust because a larger amount of caching occurs and, therefore, fewer external DNS resolutions are requested.

[0015] One or more embodiments described herein may be incorporated into, executed by, and / or used in a computing environment, such as Figure 1 The computing environment 100 may be a computing environment of various architectures and types, including, but not limited to, personal computing, client-server, distributed, virtual, simulated, partitioned, non-partitioned, cloud-based, quantum, grid, time-sharing, clustered, peer-to-peer, mobile, with one or more nodes, with one or more processors, and / or any other type of environment and / or configuration capable of performing any combination of one or more aspects described herein. Therefore, the aspects described and claimed herein are not limited to a particular architecture or environment.

[0016] Various aspects of the present disclosure are described by narrative text, flow charts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. With respect to any flow chart, depending on the technology involved, the operations may be performed in an order different from the order shown in a given flow chart. For example, again depending on the technology involved, two operations shown in consecutive flow chart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in a manner that at least partially overlaps in time.

[0017] Computer program product embodiments ("CPP embodiments" or "CPPs") are terms used in this disclosure to describe any collection of one or more storage media (also referred to as "media") that are collectively included in a collection of one or more storage devices that collectively include machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A "storage device" is any tangible device that can hold and store instructions for use by a computer processor. Without limitation, a computer-readable storage medium can be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include magnetic disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punch cards or pits / land formed in a major surface of a disk), or any suitable combination of the foregoing. Computer-readable storage media, as the term is used in this disclosure, should not be construed as storage devices that take the form of transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, light pulses through fiber optic cables, electrical signals transmitted through wires, and / or other transmission media. As will be understood by those skilled in the art, data is typically moved at certain occasional points during the normal operation of the storage device, such as during access, defragmentation, or garbage collection, but this does not make the storage device transitory because the data is not transitory while it is stored.

[0018] Computing environment 100 includes an example of an environment for executing at least some of the computer code involved in performing the methods of the present invention, such as the code of DNS obfuscator module 300. In addition to block 300, computing environment 100 includes, for example, computer 101, wide area network (WAN) 102, end-user device (EUD) 103, remote server 104, public cloud 105, and private cloud 106. In this embodiment, computer 101 includes a processor set 110 (including processing circuitry 120 and cache 121), communication fabric 111, volatile memory 112, persistent storage 113 (including operating system 122 and block 300, as identified above), peripheral device set 114 (including user interface (UI) device set 123, storage 124, and Internet of Things (IoT) sensor set 125), and network module 115. Remote server 104 includes remote database 130. The public cloud 105 includes a gateway 140 , a cloud orchestration module 141 , a host physical machine group 142 , a virtual machine group 143 , and a container group 144 .

[0019] Computer 101 may take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device now known or developed in the future that is capable of running programs, accessing a network, or querying a database (such as remote database 130). As is well known in the art of computer technology, and depending on the technology, the execution of computer-implemented methods may be distributed among multiple computers and / or among multiple locations. On the other hand, in this presentation of computing environment 100, the detailed discussion focuses on a single computer, particularly computer 101, to keep the presentation as simple as possible. Computer 101 may be located in the cloud, even though it is in a Figure 1 On the other hand, computer 101 need not be in the cloud except to the extent that can be positively indicated.

[0020] The processor set 110 includes one or more computer processors of any type now known or to be developed in the future. The processing circuitry 120 may be distributed across multiple packages, such as multiple cooperating integrated circuit chips. The processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is memory located in the processor chip package(s) and is typically used for data or code that should be quickly accessed by threads or cores running on the processor set 110. Cache memory is typically organized into multiple levels based on relative proximity to the processing circuitry. Alternatively, some or all of the caches for the processor set may be located "off chip." In some computing environments, the processor set 110 may be designed to work with qubits and perform quantum computations.

[0021] Computer-readable program instructions are typically loaded onto the computer 101 to cause a series of operating steps to be executed by the processor set 110 of the computer 101, thereby implementing a computer-implemented method, such that the instructions so executed will instantiate the method specified in the flowchart and / or narrative description of the computer-implemented method (collectively referred to as the "inventive method") included in this document. These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 121 and other storage media discussed below. The program instructions and associated data are accessed by the processor set 110 to control and direct the execution of the inventive method. In the computing environment 100, at least some of the instructions for performing the inventive method may be stored in the persistent storage device 113 in the block 300.

[0022] Communications fabric 111 is the signaling pathway that allows the various components of computer 101 to communicate with each other. Typically, the fabric is comprised of switches and conductive pathways, such as those that constitute a bus, a bridge, physical input / output ports, etc. Other types of signal communication pathways may be used, such as fiber optic communication pathways and / or wireless communication pathways.

[0023] Volatile memory 112 is any type of volatile memory now known or developed in the future. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory 112 is characterized as random access, but this is not required unless explicitly stated. In computer 101, volatile memory 112 is located in a single package and is internal to computer 101, but alternatively or additionally, volatile memory may be distributed across multiple packages and / or located externally relative to computer 101.

[0024] Persistent storage 113 is any form of non-volatile storage for computers, now known or developed in the future. The non-volatility of the storage means that the stored data is retained regardless of whether power is supplied to computer 101 and / or directly to persistent storage 113. Persistent storage 113 may be a read-only memory (ROM), but typically, at least a portion of the persistent storage allows writing, deleting, and rewriting of data. Some common forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 122 may take several forms, such as various known proprietary operating systems or operating systems of the open source portable operating system interface type that employs a kernel. The code included in box 300 typically includes at least some computer code involved in executing the method of the present invention.

[0025] The peripheral device group 114 includes a collection of peripheral devices of the computer 101. The data communication connection between the peripheral devices and other components of the computer 101 can be implemented in various ways, such as a Bluetooth connection, a near field communication (NFC) connection, a connection by a cable (such as a universal serial bus (USB) type cable), a plug-in connection (e.g., a secure digital (SD) card), a connection through a local area communication network, and even a connection through a wide area network (such as the Internet). In various embodiments, the UI device group 123 can include components such as a display screen, a speaker, a microphone, a wearable device (such as goggles and a smart watch), a keyboard, a mouse, a printer, a touchpad, a game controller, and a haptic device. The storage device 124 is an external storage device, such as an external hard drive, or a plug-in storage device, such as an SD card. The storage device 124 can be permanent and / or volatile. In some embodiments, the storage device 124 can take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 101 requires a large amount of storage (e.g., computer 101 locally stores and manages a large database), the storage may be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. IoT sensor set 125 consists of sensors that can be used in IoT applications. For example, one sensor may be a thermometer, while another sensor may be a motion detector.

[0026] The network module 115 is a collection of computer software, hardware, and firmware that allows the computer 101 to communicate with other computers via the WAN 102. The network module 115 may include hardware such as a modem or a Wi-Fi signal transceiver, software for packetizing and / or depacketizing data transmitted over a communication network, and / or web browser software for transmitting data over the Internet. In some embodiments, the network control function and the network forwarding function of the network module 115 are executed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software-defined networking (SDN)), the control function and the forwarding function of the network module 115 are executed on physically separate devices so that the control function manages several different network hardware devices. The computer-readable program instructions for executing the method of the present invention can typically be downloaded to the computer 101 from an external computer or external storage device via a network adapter card or network interface included in the network module 115.

[0027] WAN 102 is any wide area network (e.g., the Internet) capable of transmitting computer data over non-local distances using any technology now known or later developed for transmitting computer data. In some embodiments, WAN 102 may be replaced and / or supplemented by a local area network (LAN) designed to transmit data between devices located in a local area, such as a Wi-Fi network. A WAN and / or LAN typically includes computer hardware, such as copper transmission cables, optical transmission cables, wireless transmission, routers, firewalls, switches, gateway computers, and edge servers.

[0028] An end-user device (EUD) 103 is any computer system used and controlled by an end-user (e.g., a customer of an enterprise operating computer 101), and may take any of the forms discussed above in connection with computer 101. EUD 103 typically receives helpful and useful data from the operation of computer 101. For example, in the hypothetical scenario where computer 101 is designed to provide recommendations to an end-user, the recommendations would typically be transmitted from network module 115 of computer 101 over WAN 102 to EUD 103. In this manner, EUD 103 may display or otherwise present the recommendations to the end-user. In some embodiments, EUD 103 may be a client device, such as a thin client, a heavy client, a mainframe computer, a desktop computer, or the like.

[0029] Remote server 104 is any computer system that provides at least some data and / or functionality to computer 101. Remote server 104 may be controlled and used by the same entity that operates computer 101. Remote server 104 represents a machine(s) that collects and stores helpful and useful data for use by other computers, such as computer 101. For example, if computer 101 is designed and programmed to provide recommendations based on historical data, this historical data may be provided to computer 101 from remote database 130 of remote server 104.

[0030] Public cloud 105 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer capabilities, particularly data storage (cloud storage) and computing power, without requiring direct, active management by users. Cloud computing typically leverages the sharing of resources to achieve consistency and economies of scale. Direct and active management of the computing resources of public cloud 105 is performed by computer hardware and / or software of cloud orchestration module 141. The computing resources provided by public cloud 105 are typically implemented as virtual computing environments running on various computers comprising host physical machine group 142, which is the universe of physical computers in and / or available to public cloud 105. Virtual computing environments (VCEs) typically take the form of virtual machines from virtual machine group 143 and / or containers from container group 144. It should be understood that these VCEs can be stored as images and can be transferred between various physical machine hosts either as images or after instantiation of the VCEs. Cloud orchestration module 141 manages the transfer and storage of images, deploys instantiation of new VCEs, and manages active instantiation of VCE deployments. Gateway 140 is a collection of computer software, hardware, and firmware that allows public cloud 105 to communicate over WAN 102 .

[0031] Some further explanation of virtualized computing environments (VCEs) will now be provided. A VCE can be stored as an "image." New active instances of a VCE can be instantiated from an image. Two common types of VCEs are virtual machines and containers. Containers are VCEs that use operating system-level virtualization. This refers to an operating system feature where the kernel allows the existence of multiple isolated user space instances (called containers). These isolated user space instances typically appear to be real computers from the perspective of the programs running in them. Computer programs running on a normal operating system can make use of all of the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running within a container can only use the contents of the container and the devices assigned to the container, a feature known as containerization.

[0032] 105 . Private cloud 106 is similar to public cloud 105 , except that the computing resources are only available to a single enterprise. Although private cloud 106 is depicted as communicating with WAN 102 , in other embodiments, the private cloud may be completely disconnected from the Internet and accessible only through a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types), typically implemented by different vendors. Each of the multiple clouds remains a separate and discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the multiple constituent clouds. In this embodiment, public cloud 105 and private cloud 106 are both part of a larger hybrid cloud.

[0033] The above description Figure 1 The computing environment in is only one example of a computing environment in which aspects of the present invention may be incorporated, executed, and / or used. Other examples are possible. For example, in one or more embodiments, Figure 1 One or more components / modules are not included in the computing environment and / or are not used for one or more aspects of the present invention. Further, in one or more embodiments, additional and / or other components / modules may be used. Other variations are possible.

[0034] Figure 2 Another example environment for DNS request obfuscation is depicted. Environment 200 includes a private network 202 having client computer systems / (one or more) devices 204 and private DNS servers 206a, 206b, ..., 206n. (One or more) client devices 204 transmit DNS requests to private DNS servers 206a, 206b, ..., 206n via communication path 210 and receive responses therefrom. The communication path can be (one or more) wired and / or wireless communication links, such as Ethernet-based wired or wireless connections, but more generally can be any suitable wireless and / or wired communication links for transmitting data. Typically, although not always, the communication path is implemented via hardware and software-based network facilities. In the example, client device 204 and private DNS server 206 can be partially or fully co-located with each other or separate discrete physical devices located remotely.

[0035] The environment also includes external DNS servers 208a, 208b, ..., 208m, which are external to the private network 202. The external DNS servers may be public DNS servers and / or available across another network (public or private; not shown) to which the private network 202 is connected.

[0036] Communication paths 212a, 212b, ..., 212n represent communications to and from private DNS servers 206a, 206b, ..., 206n, respectively. For example, a private DNS server can issue externally directed DNS requests to any / all external DNS servers 208a, 208b, ..., 208m and receive responses in response to these requests. Communication paths 214a, 214b, ..., 214n represent communications to and from external DNS servers 208a, 208b, ..., 208m, respectively. An external DNS server can receive DNS requests from any / all private DNS servers 206a, 206b, ..., 206n and issue responses in response to these requests. Traffic flows between the private DNS servers and the external DNS servers can be implemented using, for example, DNS over TLS or DNS over HTTPS for increased security. Additionally, private DNS servers 206a, 206b, ..., 206n communicate with one another, eg, as represented by communication path 211 between private DNS servers 206a and 206b, for communication of DNS requests and / or other types of communications.

[0037] The activities of the client device(s) 204 include issuing DNS requests to one or more private DNS servers on the network 202. Programs such as web browsers initiate DNS lookups in order to retrieve and render requested content provided by the network. The private network 202 and its components are considered a trusted network for the client device 204, and therefore, the private DNS server 206 is considered a trusted entity for the client device 204. The client device 204 provides DNS requests within the private network 202 to the private DNS server 206 for resolution.

[0038] In an example, private network 202 is an organization's network, whereby the organization provides one or more private DNS servers to handle client DNS requests.

[0039] Various activities of private DNS server 206 in providing DNS obfuscation are described in detail herein. In one aspect, private DNS server 206 of private network 202 receives a DNS request seeking a DNS lookup for client device 204. In some examples, the DNS request is received from client device 204 itself. In other examples described herein, it is received from another private DNS server 206 of private network 202. The private DNS server that receives the DNS request may perform a process to resolve the DNS request or assist in resolving the DNS request. If private DNS server 206 does not have a cached resolution for the request, it may issue an external DNS request, for example, to an external DNS server 208, or pass the request to another private DNS server 206. Various scenarios are possible and are described herein.

[0040] Notice, Figure 2 The example environment of the present invention depicts multiple (n) private DNS servers and multiple (m) external DNS servers by way of example only and not limitation. The aspects described herein include situations in which there are any number (including only one) of (one or more) private DNS servers and / or any number (including only one) of (one or more) external DNS servers.

[0041] In one aspect described herein, DNS requests issued by and / or seeking DNS lookups for client device(s) 204 (which may be referred to herein as "real" or legitimate DNS requests) are obfuscated within a collection of noise, the noise taking the form of other DNS requests generated as decoys for legitimate DNS requests for client device(s) 204. In this regard, process(es) perform the generation or acquisition of decoy DNS requests for use in obfuscating DNS request activity (legitimate DNS requests) being processed by the organization's private DNS server(s). The decoys may necessarily request a different resolution than the legitimate requests they are helping to obfuscate. The process(es) may send these decoy DNS requests to external DNS server(s) for resolution, strategically doing so to obfuscate legitimate DNS requests being sent externally for resolution. Thus, the generated noise helps obfuscate legitimate DNS requests issued by the private DNS server(s) to the external DNS server(s).

[0042] More specifically, multiple DNS lookup requests may be sent to an external DNS server, where these multiple DNS requests include both (i) legitimate DNS requests made on behalf of client device 204 and (ii) decoy DNS requests generated for the purpose of obfuscating / obfuscating those legitimate DNS requests. The legitimate DNS requests are obfuscated by sending DNS requests to external DNS server 208 intermixed with at least some of the generated decoy DNS requests sent to the external DNS server—in other words, intermixed with some of the decoy DNS requests sent along with, before, and / or after, the legitimate DNS requests. As part of this obfuscation and intermixing, the decoy DNS requests may be sent simultaneously with the legitimate DNS requests so that an actor observing DNS request activity from outside private network 202 will only "see" the legitimate DNS requests as part of a larger set of DNS requests flowing out of private network 202 to the external DNS server(s). Note that some of the decoy DNS requests used to obfuscate the legitimate DNS requests do not need to be sent to the same external DNS server as the legitimate DNS requests; the decoy DNS requests may go to various external DNS servers, only one of which is the target of the legitimate DNS request. An observer of all DNS request activity leaving the private network will see DNS requests going to every external server, thereby convolving any given legitimate DNS request with requests going to more than just the target server to handle that legitimate DNS request.

[0043] Legitimate DNS requests that are to be resolved externally can be sent to different external DNS servers 208, and decoy DNS requests can be generated and sent to obfuscate legitimate DNS activity. In this way, different legitimate DNS requests for DNS lookups for (one or more) client devices are obfuscated by randomly or otherwise selecting from different external DNS servers and sending to the selected external DNS servers. These legitimate DNS requests can be mixed in with decoy DNS requests that also flow to different external DNS servers. By distributing these requests to different external servers (and corresponding locations / sites, if the external DNS servers are far away from each other), this greatly reduces the risk that an attacker will see all upstream (external) DNS request activity, as it may be easier for an attacker to compromise only a single external server rather than the entire set of external servers used, thus making it more difficult to determine what is actually being looked up.

[0044] The generation and sending of decoy DNS requests can be performed according to configurable criteria, such as criteria that specify the lookup target (e.g., the requested content) for the generated decoy DNS request. In other words, the decoy DNS request can request resolution for a site / page that is specifically and intentionally targeted rather than randomly selected, although random selection of the decoy target is also possible.

[0045] By way of example and not limitation, if a legitimate client DNS request is targeted at retrieving news articles related to biotechnology, decoy DNS requests may be generated such that they target resolutions customized based on the lookup target of the legitimate client DNS request. Decoy requests may target, for example, other news article servers or other servers hosting content related to biotechnology. If the target is biotechnology news from a news website, some decoy requests may request resolutions pointing to other types of content from that website and / or biotechnology or other types of content from other news websites.

[0046] Thus, the configurable criteria according to which decoy DNS requests are generated can specify a relevance level for the process to use when generating the decoy DNS requests. For example, the relevance level indicates a desired level of relationship between the lookup target for the generated decoy DNS request(s) and the lookup target for legitimate DNS requests. In one embodiment, the relevance level is implemented as a sliding scale that allows a user of a client device making a DNS request (or an administrator of the system) to adjust the relevance of the decoy DNS request to the client's DNS query. At one end of the scale, the decoy may be directed to something very similar to the user's current DNS request, while at the other end of the scale, the query may be unrelated to the user's request.

[0047] The relevance level can be set with the primary consideration and goal being to generate decoys that appear to tell the least to an outsider snooping on the DNS requests sent from the private network 202 about legitimate user activity. It can be logically expected, and without snooping on the DNS activity, that a biotech company and its specific client devices issue a large number of requests for resolution of biotech-related resources. If the noise (decoy DNS requests) typically point to content spanning a very wide range of topics unrelated to biotech, then to a malicious outside observer it may be information that those DNS requests are just noise / decoys and that legitimate DNS requests are requests centered around biotech. In this example, legitimate DNS requests have not been sufficiently obfuscated because legitimate DNS requests are relatively easy to discern for an outside observer. On the other hand, if there are no decoys or only very few decoys targeting content unrelated to biotech, then legitimate DNS requests targeting something unrelated to biotech may not be sufficiently obfuscated. Therefore, the relevance level can depend on the environment. An organization with legitimate DNS requests covering a variety of topics will not want noise concentrated on just one topic, and an organization with a large number of legitimate DNS requests covering very niche subtopics of a broad category may want noise that is substantially within that broad category and does not stray very far from it.

[0048] Note that the generation of baits for sending can take into account individual DNS requests as well as aggregations of DNS requests made over time. Bait generated from past activity may be used to obfuscate future DNS requests. Some of the baits sent concurrently with a given legitimate DNS request may have been generated based on the request itself, while the baits may have been generated based on previous legitimate DNS requests by the same client device or otherwise and / or at an earlier time. Previous legitimate DNS requests can help inform the generation of additional baits for use in obfuscating future legitimate DNS requests. The effectiveness of the obfuscation is enhanced when there are multiple active client devices making DNS queries because it will increase the raw or seed data used as a basis for generating related decoy DNS queries.

[0049] Thus, decoy requests can be pre-generated based on previous legitimate requests for use in obfuscating later legitimate requests. This can reduce the latency in identifying and obtaining decoys to be sent simultaneously with legitimate DNS requests, which may be temporarily blocked from external transmission until the decoys to be used can be identified, and at least some decoys can be sent externally before legitimate DNS requests are sent. This also ensures that the impact of legitimate requests on the generation of decoys used for obfuscation is extended over time, as those decoys can be used at a later time in conjunction with other legitimate DNS requests.

[0050] As an example, if no decoy requests were generated from previous legitimate DNS requests and available for use with a given legitimate DNS request, the decoys may come from seed requests based on very popular websites and / or from decoys generated based on legitimate requests at that time.

[0051] Additional examples of sources from which decoy requests may be generated include one or more of the following, which may help ensure that the noise matches the selected relevance level:

[0052] - Scraping results from search engine(s): This refers to searching for results related to the content provided at the lookup target of the legitimate DNS request. If the legitimate DNS request is for a resolution of a site with biotechnology news, then the search engine(s) can be used to perform an automated search for biotechnology news. The results from the search(s) can inform other sites targeted by the decoy request. For example, a decoy request can be generated requesting the resolution of those search results.

[0053] - Crowdsourcing from other legitimate DNS requests (and / or decoys for those requests) in the organization's or user's organizational area: The organization's other legitimate DNS requests and / or decoy DNS request(s) generated based on those legitimate DNS requests or similar DNS requests can be used as decoy DNS requests to be used with later legitimate requests or to inform the generation of decoy DNS requests. For example, in an organization where many users view a variety of different news sources, their client devices will generate legitimate DNS requests with lookups related to news content. This can prompt the generation of various decoy requests to be used in obfuscation of those requests. Further, the target content of loading such requests is expected to load various additional content (advertisements, etc.) that itself prompts additional legitimate DNS requests. When a legitimate DNS request for news content arrives at a later time, the previous legitimate news content DNS request and the decoys generated therefrom and / or used in its obfuscation can inform the possible source of decoys to be generated and used in obfuscating later legitimate DNS requests.

[0054] - Admin-provided selection of decoy / noise sources: Administrators or standard users can choose their own noise to hide legitimate requests, for example using the option to configure which topics or links to use for obfuscation.

[0055] As described above, where there are multiple external DNS servers 208 available to handle upstream DNS requests, both legitimate DNS requests and decoy DNS requests can be spread across multiple external servers 208. In some examples, any given outgoing / external DNS request (legitimate or decoy) is sent to only one upstream (external) DNS server. In other words, the same request is not sent to multiple external servers as part of obfuscating a given legitimate DNS request. By using multiple external DNS servers, this ensures that no single external server has a complete picture of the DNS history, and that the DNS lookup history held by any given external server is a DNS lookup history that includes both legitimate DNS requests and decoy DNS requests.

[0056] Additionally, when multiple private DNS servers 206 are available to handle legitimate DNS requests from client device 204, these DNS requests can be distributed among them to further decentralize the specific source of the request. In other words, a private DNS server receiving a DNS request from a client can provide the request to a different private DNS server for processing. The request can be passed around the private network any number of times, after which the most recent private DNS server that holds the request sends it to an external DNS server. The external DNS server knows that the request came from the most recent private DNS server, but is unaware of the intermediate private DNS servers the request passed through.

[0057] The generation and sending of decoy DNS requests can also be performed according to configurable criteria that dictate the timing of sending the decoy DNS requests. In one example, a continuous "heartbeat" of decoy requests is sent to ensure that a user's activity cannot be understood by monitoring the frequency and timing of DNS requests. For example, the method would send decoy DNS requests that obfuscate legitimate DNS requests sent after the organization's regular business hours. If a user working after hours initiates a DNS request, the periodic sending of decoys will help obfuscate the legitimate request, making it unclear to an outside observer which client is making the request, or even that any DNS requests leaving the private network 202 around that time are legitimate DNS requests.

[0058] Thus, configurable criteria can include the rate at which DNS requests are sent to the external DNS server(s). This rate can include the number of DNS requests to be sent per time period, and this number can be the sum of both legitimate and decoy DNS requests to be sent. As an example, the private DNS servers of a private network can be configured to collectively send 5,000 DNS requests per hour. The system can assume that all of these requests will be decoy requests unless there are legitimate requests to send. Because the number of legitimate DNS requests that occur during that hour will vary based on user activity and is generally uncontrollable, the default practice can be to schedule decoy DNS requests to be sent unless a legitimate DNS request is pending. To ensure that this "heartbeat" number of requests is essentially constant, the number of legitimate DNS requests being sent can be subtracted from this number of heartbeats to indicate the number of decoy requests to utilize. In this way, the number of decoy DNS requests to be sent in a time period is based on the number of legitimate client DNS requests sent (including received DNS requests) during that time period. The granularity of these numbers can be varied as needed. For example, the number of heartbeats can be set per user, client device, client device group, the aggregate of all client devices in the network, or at any other granularity. For example, if a user generates 100 requests per hour, and the number of heartbeats for the user's total DNS requests sent externally per hour is 5,000, the system can reduce the number of decoy requests to be sent from 100 to 5,000-100=4,900 decoy requests to be sent during that hour.

[0059] As an enhancement to the heartbeat concept, the heartbeat rate can be dynamically adjusted based on the total client DNS request activity load. Again, the granularity can be per individual user, user group, organization, or any other level of desired granularity. Under this method, the system dynamically adjusts the rate at which decoy requests are transmitted based on the level of legitimate DNS requests during that time period. Using the above example of 5,000 requests per hour, this rate may be sufficient to confuse 100 or fewer legitimate requests per hour (as an example), but not sufficient to confuse 3,000 legitimate requests per hour. An exemplary solution may provide thresholds or ranges of legitimate requests (i.e., 1-100, 101-500, 501-1,000, etc.) and corresponding heartbeat rates corresponding to those ranges (i.e., 5,000 requests, 20,000 requests, 50,000 requests, etc.) to ensure that a sufficient amount of noise in the form of decoy requests is provided to confuse legitimate requests. Another method of dynamic adjustment is to scale the number of decoy requests to be sent per time unit based on the actual, average or some other statistical number of legitimate requests that are actually served and / or estimated to be served during the time unit. For example, the number of decoy requests to be sent can be a function (such as a scalar multiple) of the actual number of legitimate requests pushed out in the previous time unit, the average number of requests processed per time unit of the time span, or the estimated number of legitimate requests to be processed during the time unit. For each legitimate request sent, there may be a target number of decoy requests to be sent. In addition, the number of legitimate DNS requests that are actually sent for external resolution during the time unit can be monitored in real time, and the decoy sending rate during the time unit can be dynamically adjusted to achieve the desired total number of requests to be sent during the time period. Various methods are possible.

[0060] Finally, the private DNS server that made the external DNS request to the external DNS server receives the DNS response from the external DNS server. At this point, the receiving private DNS server can provide the DNS response to the source of the DNS request and perform any other desired processing. In some scenarios, such as when there is only one private DNS server, the private DNS server receives the response and provides the resolution to the requesting client device that was the source of the DNS request.

[0061] In some scenarios where there are two or more private DNS servers, a private DNS server receives a DNS request from another private DNS server, which itself receives the request from a client device or another private DNS server. Although a legitimate DNS request ultimately originates from a client device, the request may hop through one or more private DNS servers before reaching the private DNS server that makes the external request to the external DNS server. In these cases, the "source" of the DNS request requested by the private DNS server that sends the request to the external server and receives a response from it can include the client device from which the DNS request originated and / or any intermediate private DNS servers through which the request was routed. The private DNS server that communicates with the external server to resolve the request can receive the resolution and provide it to the client device, any one or more of the other private DNS servers in the private network, or a combination of both. In certain embodiments, the resolution flows in the opposite direction of the path it took from the client device to the private DNS server that made the external request.

[0062] Another aspect described herein is caching of DNS responses by the private DNS server, and in some examples, retaining the resolution for as long as possible, e.g., until a time to live (TTL) has passed before the record loses validity. A wider range of caching devices enables the system to minimize the number of legitimate DNS requests that need to flow out of the private network to untrusted external DNS servers. Thus, processing by the private DNS server may further include: based on receiving the DNS request, determining whether a resolution for the DNS request is cached by the private DNS server, and then, based on determining that no resolution for the DNS request is cached by the private DNS server, obfuscating the DNS request as part of an external lookup.

[0063] Expanding on this, the private DNS server handling the request can leverage the network's other private DNS servers by initiating an attempted resolution of the DNS request by one or more of the network's other private DNS servers, for example by sending a request to one or more of them and / or asking any one or more of them whether they possess or have access to a cached resolution for the request. By assuming that the DNS records cached within the private network are valid, the system can attempt to trust a private DNS server for DNS resolution and, if possible, avoid making external requests. In practical terms, if any private DNS server has a valid cached resolution, a large organization will likely operate a "cluster" of private DNS servers that coordinate to avoid repeated lookups to any external servers. The receiving private DNS server can check whether the resolution is cached on any other private DNS server on the network and, if no other private DNS server on the network has the resolution, determine to obfuscate the request as part of an external query made by the server to an external DNS server. Alternatively, the DNS server can pass the request to one or more other private DNS servers for processing in a similar manner. Other approaches are also possible, such as one in which the receiving DNS server uses a distributed data structure (or structures) to identify which resolutions are cached by other private DNS servers (or structures) in the network. In this distributed data structure, the private DNS servers indicate to each other what they have cached. As another option, there may be a coordination device on the network that can determine what each private DNS server has cached and inform the querying private DNS server where to send the DNS request for resolution, such as to another specific private DNS server in the network or to an external DNS server.

[0064] A private DNS server that sends a DNS request for external resolution can receive and cache the resolution. Additionally, it can send the resolution to other private DNS servers in the network. In the event that a first private DNS server has issued a DNS request for processing by one or more other private DNS servers and that DNS request has been resolved by a second private DNS server in the network, the DNS response can be returned to the first server for caching, either from a cached resolution maintained by the second private DNS server or through an external lookup. In this way, a first private DNS server can receive a DNS response from a second private DNS server in response to a DNS request issued by the first private DNS server to the second server, and cache the DNS response as the resolution for the DNS request issued by the first server to the second server.

[0065] In some embodiments, the activity of obfuscating DNS requests sent to external servers can be selectively enabled and disabled. An enterprise or individual user may not always want decoy DNS requests to be generated and sent as noise, in which case an enable / disable switch can be used by the appropriate entity to control the activity. Thus, the process can provide for the selective enabling and disabling of the activity of obfuscating DNS requests being processed by (one or more) dedicated DNS servers. The disabling can be a predetermined or otherwise temporary action. This may be desirable in situations where the provision of decoy requests creates a problem. For example, disabling the activity may be desirable at night or in situations where the volume of requests identified by external DNS servers as coming from a private network is too high.

[0066] The various aspects described herein advantageously provide enterprise-level DNS obfuscation. The system provides the ability to effectively hide user DNS traffic from traditional information exposure / sensitive data leakage vectors through an enterprise or corporate network. It also significantly reduces the "chain of trust" required to make DNS requests securely, avoiding unnecessary reliance on external entities and their potentially flawed security implementations. By hosting (one or more) trusted local DNS servers, the organization gains control over the DNS requests that follow the initial DNS request, avoiding the need for at least some additional DNS traffic to exit the network to untrusted entities. It can be used to hide the identity of the websites that the organization's users are visiting from attackers. This is effective in addressing situations where an attacker learns that a particular website is frequently visited by the organization and therefore exploits the website's poor security to compromise the site and add malicious payloads to it as a way to infiltrate the organization's systems (waterhole attacks).

[0067] Additionally, the aspects described herein do not rely on the effectiveness of security measures implemented by external DNS servers to ensure security. For example, some approaches encrypt DNS requests passed through untrusted servers in order to hide the domain being queried. Under this approach, the DNS request is encrypted and appended to the request made to the external server, but the external server is assumed to be trusted because it decrypts and resolves the request before encrypting and transmitting the result back to the client. This approach is intended to prevent surveillance by third parties (excluding the external DNS server itself); it will still allow the external DNS server operator to track and monitor queries and associate them with source IP addresses or specific users. It does not prevent surveillance by the DNS operator. In contrast, the effectiveness of the obfuscation strategies discussed herein does not rely on the trust status of the external DNS server(s) involved.

[0068] Figure 3 Depicted are example DNS request obfuscator modules (e.g., Figure 1Further details of the DNS obfuscator module 300 of the present invention are provided. In one or more aspects, in one example, the DNS request obfuscator module 300 includes various sub-modules for performing DNS request obfuscation. The sub-modules can be or include, for example, computer-readable program code (e.g., instructions) in a computer-readable medium (e.g., a persistent storage device (persistent storage device 113, such as a disk) and / or a cache (such as cache 121)). The computer-readable medium can be part of a computer program product and can be executed by and / or using one or more computers or devices and / or their (one or more) processors or processing circuits, for example Figure 1 The computer(s) 101 , EUD 103 , remote server 104 , or computer of the cloud 105 / 106 , as examples, may be or include, for example, one or more private DNS servers 206 .

[0069] refer to Figure 3 The DNS obfuscator module 300 includes: a decoy DNS request generator submodule 302 for generating decoy DNS requests for sending to (one or more) external DNS servers; a DNS request receiving submodule 304 for receiving legitimate DNS requests, such as from (one or more) client devices and / or other private DNS servers of a network; a DNS request resolution determination submodule 306 for determining whether the resolution of the received DNS request is cached by the private DNS server; a DNS request obfuscation submodule 308 for obfuscating the DNS request by sending a DNS request mixed with the generated decoy request to (one or more) external DNS servers; a DNS response receiving submodule 310 for receiving (one or more) DNS responses to the sent (one or more) DNS requests from (one or more) external DNS servers; and a DNS response providing submodule 312 for providing a DNS response to the source of the received DNS request.

[0070] In an example, the DNS obfuscator module 300 executes on each of one or more private DNS servers of an organization's private network.

[0071] Figure 4 An example process for DNS request obfuscation according to various aspects described herein is depicted. In one or more examples, the process can be performed by a processor or processing circuit of one or more computers / computer systems, such as described herein, more particularly, with reference to Figure 1 In one example, the implementation Figure 4The code or instructions for the process(es) are part of a module, for example, module 300, of a private DNS server in one or more private DNS servers that work in conjunction with each other to complete client DNS requests as described herein. In other examples, the code may be included in one or more modules and / or in one or more submodules of one or more modules. Various options are available.

[0072] Figure 4 The process includes generating (402) a decoy Domain Name System (DNS) request for obfuscating DNS request activity being processed by one or more private DNS servers of an organization, and sending the decoy DNS request to one or more external DNS servers for resolution. The generation and sending of the decoy DNS request can be performed according to configurable criteria that specify a lookup target for the generated decoy DNS request and a timing for sending the decoy DNS request. For example, the configurable criteria can specify a correlation level to be used when generating the decoy DNS request, the correlation level indicating a desired level of relationship between a lookup target for the generated decoy DNS request and a lookup target of the DNS request being processed.

[0073] Additionally or alternatively, at least some of the decoy DNS requests may be generated based on search results related to content provided at the lookup target of the DNS request being processed and / or crowdsourcing other DNS requests for the organization, wherein (i) similar DNS requests to the crowdsourced other DNS requests and / or (ii) at least one decoy DNS request generated based on the similar DNS requests are included in the generated decoy DNS requests.

[0074] Additionally or alternatively, the configurable criteria may include a rate at which DNS requests are sent to one or more external DNS servers, the rate including a number of DNS requests to be sent per time period, wherein the number of decoy DNS requests to be sent in a time period is based on the number of client DNS requests sent in the time period. The rate may be dynamically adjusted based on the total client DNS request activity load.

[0075] continue Figure 4 The process of receiving (404) a DNS request by a private DNS server seeking a DNS lookup for a client device. As an example, the DNS request may be received from the client device, or may be received from another private DNS server of the organization. Figure 4 The private DNS server of the organization may handle the request differently depending on the circumstances, for example, by making an external request for resolution and / or providing the request to the organization's other (one or more) private DNS servers for resolution.

[0076] exist Figure 4 In an example of , the process continues by determining (406) whether the resolution of the DNS request is cached by the private DNS server based on receiving the DNS request. If so (406, yes), the process provides (408) a response with the cached resolution to the client. Otherwise (406, no), the process continues by obfuscating (410) the DNS request by sending a DNS request mixed with at least some of the generated decoy DNS requests sent to the external DNS server to an external DNS server of one or more external DNS servers. In some embodiments, each decoy DNS request is sent to only one upstream (external) DNS server. The process continues at 412 by receiving a DNS response to the sent DNS request from the external DNS server and providing the DNS response to the source of the DNS request. The private DNS server may have received the DNS request from the client device itself (at 404) and therefore provides the DNS response to the client device. Alternatively, the private DNS server may have received the DNS request from another private DNS server of the organization and therefore provides the DNS response to (at least) the other private DNS server and / or the client device.

[0077] As an enhancement, the processing may provide for selective enabling and disabling of obfuscation of DNS request activity handled by the private DNS server, wherein generating (402) the decoy DNS request and obfuscating (410) the received DNS request are performed based on the selective enabling of obfuscation of DNS request activity handled by the private DNS server.

[0078] Further, an example process performed by a private DNS server (e.g., its DNS obfuscator module) can receive a DNS request from a client device or other private DNS server and send the DNS request to another private DNS server for processing. The process can receive the DNS request, determine that a resolution to the DNS request is not cached by the private DNS server, and initiate an attempted resolution of the DNS request by at least one other private DNS server of the organization. For example, the private DNS server sends the request to the identified other private DNS server. For example, there can be a minimum number of hops required to the other private DNS server before the DNS request is issued for external resolution.

[0079] A private DNS server that forwards a DNS request to another private DNS server for resolution may later receive a DNS response from the other private DNS server in response to the forwarded DNS request and cache the DNS response as the resolution of the DNS request so that the resolution is cached and can be used to resolve other DNS requests later when needed.

[0080] While various embodiments are described above, these are merely examples.

[0081] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the terms "comprises" and / or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0082] The corresponding structures, materials, actions, and equivalents (if any) of all means or step plus function elements in the claims below are intended to include any structure, material, or action for performing the function in combination with other claimed elements for which protection is specifically claimed. The description of one or more embodiments has been presented for the purposes of illustration and description, but the description is not intended to be exhaustive or limited to the disclosed forms. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiments are selected and described in order to best explain the various aspects and practical applications, and to enable others of ordinary skill in the art to understand the various embodiments with various modifications suitable for the specific purposes envisioned.

Claims

1. A computer-implemented method comprising: generating decoy DNS requests for obfuscating DNS request activity processed by a private Domain Name System (DNS) server for an organization, and sending the decoy DNS requests to one or more external DNS servers for resolution; receiving, by the private DNS server, a DNS request seeking a DNS lookup for a client device; obfuscating the DNS requests by sending the DNS requests to an external DNS server of the one or more external DNS servers mixed with at least some of the generated decoy DNS requests sent to the external DNS server; receiving a DNS response to the sent DNS request from the external DNS server; as well as The DNS response is provided to the source of the DNS request.

2. The method according to claim 1, wherein Generating and sending the decoy DNS request is performed according to configurable criteria that dictate the lookup target for the generated decoy DNS request and the timing of sending the decoy DNS request.

3. The method according to claim 2, wherein: The configurable criteria include a rate at which DNS requests are sent to the one or more external DNS servers, the rate including a number of DNS requests to be sent per time period, wherein the number of decoy DNS requests to be sent in a time period is based on a number of client DNS requests sent in the time period, including the received DNS requests.

4. The method according to claim 3, wherein: The rate is dynamically adjusted based on the total client DNS request activity load.

5. The method according to claim 2, wherein: The configurable criteria specifies a correlation level used in generating the decoy DNS request, the correlation level indicating a desired level of relationship between the lookup target for the generated decoy DNS request and a lookup target of the DNS request.

6. The method according to claim 5, wherein: At least some of the decoy DNS requests are generated based on at least one item selected from the group consisting of: Search results related to the content provided at the lookup target of the DNS request; and Crowdsourcing other DNS requests of the organization, wherein at least one item selected from the group consisting of: (i) similar DNS requests of the crowdsourced other DNS requests and (ii) at least one decoy DNS request generated based on the similar DNS requests is included in the generated decoy DNS requests.

7. The method according to claim 1, wherein The private DNS server receives the DNS request from the client device and provides the DNS response to the client device.

8. The method according to claim 1, wherein The private DNS server receives the DNS request from another private DNS server of the organization, and wherein the private DNS server provides the DNS response to at least one selected from the group consisting of: the another private DNS server, and the client device.

9. The method according to claim 1, further comprising: Based on receiving the DNS request, determining whether a resolution of the DNS request is cached by the private DNS server, and wherein obfuscating the DNS request is based on determining that the resolution of the DNS request is not performed by the private DNS server cache.

10. The method according to claim 1, further comprising: Selective enabling and disabling of obfuscation of DNS request activity processed by the private DNS server is provided, wherein generating the decoy DNS request and obfuscating the received DNS request are performed based on the selective enabling of obfuscation of DNS request activity processed by the private DNS server.

11. The method according to claim 1, wherein The DNS request is a first DNS request, and wherein the method further comprises: receiving a second DNS request; determining that a resolution to the second DNS request is not cached by the private DNS server; and An attempted resolution of the second DNS request by at least one other private DNS server of the organization is initiated.

12. The method according to claim 11, further comprising: A DNS response in response to the second DNS request is received from another private DNS server of the at least one other private DNS server, and the DNS response is cached as a resolution to the second DNS request.

13. The method according to claim 1, wherein The one or more external DNS servers include a plurality of external DNS servers, and wherein the method further comprises: receiving a plurality of other DNS requests seeking a DNS lookup for the client device; and The obfuscation is repeated for each of the other DNS requests, wherein, for each of the other DNS requests, a different external DNS server from the plurality of external DNS servers is selected to send the other DNS request mixed with the corresponding other decoy DNS request.

14. The method according to claim 13, wherein Obfuscating the DNS request further includes sending one or more of the generated decoy DNS requests to another external DNS server of the plurality of external DNS servers simultaneously with sending the DNS request.

15. A computer system comprising: Memory; as well as a processor in communication with the memory, wherein the computer system is configured to perform a method comprising: generating decoy DNS requests for obfuscating DNS request activity processed by a private Domain Name System (DNS) server for an organization, and sending the decoy DNS requests to one or more external DNS servers for resolution; receiving, by the private DNS server, a DNS request seeking a DNS lookup for a client device; obfuscating the DNS requests by sending the DNS requests to an external DNS server of the one or more external DNS servers mixed with at least some of the generated decoy DNS requests sent to the external DNS server; receiving a DNS response to the sent DNS request from the external DNS server; and The DNS response is provided to the source of the DNS request.

16. The computer system according to claim 15, wherein: Generating and sending the decoy DNS requests is performed according to configurable criteria that specify a lookup target for the generated decoy DNS requests and a timing for sending the decoy DNS requests, wherein the configurable criteria include a rate at which DNS requests are sent to the one or more external DNS servers, the rate including a number of DNS requests to be sent per time period, wherein the number of decoy DNS requests to be sent in a time period is based on a number of client DNS requests including the received DNS requests sent in the time period.

17. The computer system according to claim 15, wherein: Generating and sending the decoy DNS request is performed according to a configurable standard that specifies a lookup target for the generated decoy DNS request and a timing for sending the decoy DNS request, wherein the configurable standard specifies a correlation level to be used when generating the decoy DNS request, the correlation level indicating an expected level of relationship between the lookup target for the generated decoy DNS request and the lookup target of the DNS request.

18. The computer system according to claim 15, wherein: The private DNS server receives the DNS request from another private DNS server of the organization, and wherein the private DNS server provides the DNS response to at least one selected from the group consisting of: the another private DNS server, and the client device.

19. The computer system according to claim 15, wherein: The one or more external DNS servers include a plurality of external DNS servers, and wherein the method further comprises: receiving a plurality of other DNS requests seeking a DNS lookup for the client device; and The obfuscation is repeated for each of the other DNS requests, wherein, for each of the other DNS requests, a different external DNS server from the plurality of external DNS servers is selected to send the other DNS request mixed with the corresponding other decoy DNS request.

20. A computer program product comprising: A computer-readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit to perform a method comprising: generating a decoy DNS request for obfuscating DNS request activity processed by a private Domain Name System (DNS) server for an organization, and sending the decoy DNS request to one or more external DNS servers for resolution; receiving, by the private DNS server, a DNS request seeking a DNS lookup for a client device; obfuscating the DNS requests by sending the DNS requests to an external DNS server of the one or more external DNS servers mixed with at least some of the generated decoy DNS requests sent to the external DNS server; receiving a DNS response to the sent DNS request from the external DNS server; and The DNS response is provided to the source of the DNS request.

Images