DNS Request Obfuscation

Abstract

DNS request obfuscation includes generating decoy Domain Name System (DNS) requests to obfuscate DNS request activity processed by the organization's private DNS server, sending the decoy DNS requests to an external DNS server for resolution, receiving DNS requests for DNS lookups on behalf of client devices, sending the DNS requests to an external DNS server of the external DNS server interspersed with at least some of the generated decoy DNS requests sent to the external DNS server, receiving DNS responses to the sent DNS requests from the external DNS server, and providing the DNS responses to the source of the DNS requests (Figure 3).

Description

[Background technology]

[0001] Domain Name System (DNS) requests for DNS lookups frequently occur on networked client devices when a user uses the client device to enter a website address, a string sometimes referred to as a Uniform Resource Locator (URL), into the address box of a web browser on the client device. Typically, a DNS request is sent from the client device to a DNS server, which looks up and identifies the Internet Protocol (IP) address that maps to the entered string, or more specifically, the specific domain name present in the string. This activity is known as 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 (HTTPS) request to the server identified by the IP address, requesting that the server provide a copy of the requested website to the client. If the request is approved, the server transmits this data to the web browser, which then assembles the data received from the server into a complete website that the user can view. Modern web browsing generally works like this. Summary of the Invention

[0002] Shortcomings of the prior art are overcome and additional advantages are provided through the provision of a computer-implemented method. The method generates decoy Domain Name System (DNS) requests to obfuscate DNS request activity processed by an organization's private DNS server and sends the decoy DNS requests to one or more external DNS servers for resolution. The process receives DNS requests for DNS lookups for client devices by the private DNS server. The method obfuscates the DNS requests by sending the DNS requests to an external DNS server of the one or more external DNS servers, interspersing at least some of the decoy DNS requests generated and sent to the external DNS server. Additionally, the method receives DNS responses from the external DNS servers for the sent DNS requests. The method also provides the DNS responses to a source of the DNS requests.

[0003] Further provided is a computer system including a memory and a processor in communication with the memory, the computer system configured to execute a method. The method generates decoy Domain Name System (DNS) requests to obfuscate DNS request activity processed by an organization's private DNS server and sends the decoy DNS requests to one or more external DNS servers for resolution. The process receives DNS requests for DNS lookups for client devices by the private DNS server. The method obfuscates the DNS requests by sending the DNS requests to an external DNS server of the one or more external DNS servers, interspersing at least some of the generated decoy DNS requests sent to the external DNS server. Additionally, the method receives a DNS response to the sent DNS request from the external DNS server. The method also provides the DNS response to a source of the DNS request.

[0004] Still further, a computer program product is provided that includes a computer-readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing a method. The method generates decoy Domain Name System (DNS) requests to obfuscate DNS request activity processed by an organization's private DNS server and sends the decoy DNS requests to one or more external DNS servers for resolution. The process receives DNS requests for DNS lookups for client devices by the private DNS server. The method obfuscates the DNS requests by sending the DNS requests to an external DNS server of the one or more external DNS servers, interspersing at least some of the generated decoy DNS requests sent to the external DNS server. Additionally, the method receives a DNS response to the sent DNS request from the external DNS server. The method also provides the DNS response to a source of the DNS request.

[0005] Additional features and advantages are realized through the concepts described herein. [Brief explanation of the drawings]

[0006] The aspects described herein are particularly pointed out and distinctly claimed as examples in the claims at the end 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.

[0007] [Figure 1] 1 illustrates an example computing environment that incorporates and / or uses aspects described herein.

[0008] [Figure 2] 1 illustrates an exemplary environment for DNS request obfuscation.

[0009] [Figure 3] 1 illustrates in further detail an example DNS Obfuscation module incorporating and / or using aspects described herein.

[0010] [Figure 4] 1 illustrates an example process of DNS request obfuscation according to aspects described herein. DETAILED DESCRIPTION OF THE INVENTION

[0011] As a result of the above-described techniques for DNS resolution—specifically, providing DNS requests to DNS servers for resolution—these DNS servers become aware of what websites are being requested to view and the timing of these requests. This allows observers of DNS activity to gain an understanding of potentially sensitive information such as users' browsing habits, including, for example, the timing and frequency of Internet activity, the content users request and view, and their location based on the IP addresses of DNS requests. As another example, it may be possible to uniquely identify a given web page via the "signature" of the set of domains resolved (and possibly, if well-known for a given web browser implementation, their resolution order). Consider a given web page that links to images or other web-based artifacts, some of which may be hosted on other domains. It may be possible to take identification even further if an attacker has the ability to watermark a given web page with additional (potentially hidden) web resources that need to be resolved in order for the page to render. This is a similar trick to a "tracking pixel," except that it is based on inserting a small or invisible element on web pages originating from a unique domain. These are just a few examples of how DNS request activity can be disruptive to users. Users can only trust that the DNS server will not provide user data to third parties. However, the DNS server owner may have nefarious motives, such as selling DNS request data to third parties or snooping as mentioned above. Besides nefarious activity on the DNS server itself, there are other ways the security and confidentiality of this external traffic can be compromised. For example, the external DNS server itself may be compromised by a malicious actor, or a malicious actor may observe network traffic to and from the DNS server.

[0012] Described herein are techniques for DNS request resolution that include obfuscating DNS requests that flow to an external DNS server for resolution, where the DNS requests are made by a client on a private network. Techniques are provided for anonymizing DNS requests and making them more private by obfuscating user DNS request data so that third parties, including those operating external DNS servers, cannot accurately identify a user's browsing trends and other sensitive data that might otherwise be obtained from the user's DNS requests. In some aspects, a system of private DNS servers is deployed that obfuscates legitimate client DNS requests within the noise of decoy requests that are generated and sent for external resolution but are not the actual legitimate DNS requests originating from the requesting user device. Responses to legitimate and decoy requests can be stored in the private DNS server's local DNS cache in case a subsequent legitimate DNS request is received for the resolved legitimate or decoy request. Storing the results in the local cache avoids the need to send future external requests for the same resolution to an external source, at least for a certain period of time.

[0013] The obfuscation activities 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 communications tunnel of a virtual private network (VPN) connection to a target, client DNS requests can still be read by the DNS server utilized by the VPN host; therefore, even if the client connection to the web is secure, trust is still placed in the VPN’s DNS server to have a sufficiently secure connection. In contrast, the aspects described herein reduce the need to trust the external DNS server being used by obfuscating the data (DNS requests) sent to the external DNS server with noise sent in the form of decoy DNS requests. All data (e.g., resolutions) returned based on these outgoing, legitimate and decoy DNS requests is secure and anonymous, significantly reducing the ability of someone to snoop on legitimate DNS requests made by clients utilizing this DNS obfuscation. Aspects also provide convincing deniability by making it difficult to trace individual DNS requests made at a particular point in time back to a single user or IP. Additionally, because the resolutions of both legitimate and decoy DNS requests can be cached locally and are already anonymized, this allows for a reduction in the time it takes for DNS lookups to complete, because resolution of future DNS requests can be attempted first against the local DNS cache before an external DNS request (e.g., to a public DNS server) is deemed necessary.

[0014] Thus, aspects described in more detail herein can provide secure communications to servers, hiding browsing activity in a constant stream of upstream lookups, distributing DNS requests to multiple different upstream servers, and adding noise in the form of decoy DNS requests that, from an observational point of view, drown out legitimate DNS requests made by real users. As the number of users of a solution increases, the solution becomes more powerful as a lot of caching occurs and therefore fewer external DNS resolutions are required.

[0015] One or more embodiments described herein may be incorporated by, executed by, and / or used by a computing environment, such as computing environment 100 of Figure 1. By way of example, the computing environment may be of a variety of architectures and types, including, but not limited to, personal computing, client-server, distributed, virtual, emulated, partitioned, non-partitioned, cloud-based, quantum, grid, time-sharing, cluster, peer-to-peer, mobile, having one node or multiple nodes, having one processor or multiple processors, and / or any other type of environment and / or configuration capable of running processes that perform any combination of one or more aspects described herein. Accordingly, the aspects described and claimed herein are not limited to any particular architecture or environment.

[0016] Various aspects of the present disclosure are described through text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in embodiments of a computer program product (CPP). With respect to any flowchart, depending on the technology involved, it is possible to perform operations in an order different from that shown in the particular flowchart. For example, again depending on the technology involved, two operations shown in successive flowchart blocks may be performed in the reverse order, as a single integrated step, simultaneously, or in an at least partially overlapping manner.

[0017] A computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media (also referred to as "media") collectively contained in one or more storage devices that collectively contain 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 capable of holding and storing instructions for use by a computer processor. The computer-readable storage medium may be, but is not limited to, 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 diskettes, 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 disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded device (such as pits / lands formed on a major surface of a punch card or disk), or any suitable combination of the foregoing. Computer-readable storage media, as the term is used in this disclosure, is not to be construed as storage in the form of transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through fiber optic cables, electrical signals transmitted through wires, and / or other transmission media. As will be appreciated by those skilled in the art, data is typically moved at some infrequent time during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but this does not make the storage device transient because the data is not transient while it is stored.

[0018] Computing environment 100 includes an example of an environment for executing at least a portion of computer code involved in performing the method of the invention, such as the code of DNS obfuscation 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 set of processors 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 shown above), a set of peripheral devices 114 (including a set of user interface (UI) devices 123, storage 124, and a set of Internet of Things (IoT) sensors 125), and network module 115. Remote server 104 includes a remote database 130. The public cloud 105 includes a gateway 140, a cloud orchestration module 141, a set of host physical machines 142, a set of virtual machines 143, and a set of containers 144.

[0019] Computer 101 may take the form of a desktop computer, a laptop computer, a tablet computer, a smartphone, a smartwatch or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device now known or later developed that is capable of executing programs, accessing a network, or querying a database, such as remote database 130. As is well understood in the art of computer technology, and in accordance with such technology, execution of a computer-implemented method may be distributed among multiple computers and / or multiple locations. While in this description of computing environment 100, to keep the description as concise as possible, the detailed discussion focuses on a single computer, and in particular computer 101. Although computer 101 is not depicted in the cloud in FIG. 1 , it may be located in a cloud. However, it is not required that computer 101 be in a cloud, except to any extent that may be affirmatively indicated.

[0020] Processor set 110 includes one or more computer processors of any type now known or later developed. Processing circuitry 120 may be distributed across multiple packages, e.g., multiple integrated circuit chips coupled together. Processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is memory located within the processor chip package and is typically used for data or code that should be available for fast access by threads or cores running on processor set 110. Cache memory is typically divided into multiple levels depending on relative proximity to the processing circuitry. Alternatively, some or all of the cache for a processor set may be located “off-chip.” In some computing environments, processor set 110 may be designed for operation with qubits and for performing quantum computing.

[0021] Computer-readable program instructions are typically loaded onto computer 101 and cause processor set 110 of computer 101 to perform a series of operational steps, thereby implementing a computer-implemented method. As a result, the instructions so executed instantiate the method set forth in the flowcharts and / or descriptions of the computer-implemented method (collectively, the "methods of the present invention") contained herein. These computer-readable program instructions are stored on various types of computer-readable storage media, such as cache 121 and other storage media described below. The program instructions and associated data are accessed by processor set 110 to control and direct the execution of the methods of the present invention. In computing environment 100, at least a portion of the instructions for executing the methods of the present invention may be stored in block 300 of persistent storage 113.

[0022] Communications fabric 111 is the signal-conducting pathway that allows various components of computer 101 to communicate with one another. Typically, this fabric is made up of switches and conductive pathways, such as those that make up buses, bridges, physical input / output ports, and the like. Other types of signal communication pathways may also be used, such as fiber optic communication pathways and / or wireless communication pathways.

[0023] Volatile memory 112 may be any type of volatile memory now known or later developed. Examples include dynamic type random access memory (RAM) or static type RAM. Typically, volatile memory 112 is characterized by random access, although this is not required unless affirmatively indicated. In computer 101, volatile memory 112 is located in a single package and internal to computer 101, although alternatively or additionally, volatile memory may be distributed across multiple packages and / or located external to computer 101.

[0024] Persistent storage 113 is any form of non-volatile storage for a computer, now known or later developed. The term non-volatile storage means that stored data remains regardless of whether power is supplied to computer 101 and / or to persistent storage 113 directly. While persistent storage 113 may be read-only memory (ROM), typically at least a portion of persistent storage allows data to be written, data to be erased, and data to be rewritten. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 122 can take several forms, including various known proprietary operating systems employing a kernel or open-source Portable Operating System Interface-style operating systems. The code contained in block 300 typically includes at least a portion of the computer code involved in performing the methods of the present invention.

[0025] Peripheral device set 114 includes a set of peripheral devices of computer 101. Data communication connections between peripheral devices and other components of computer 101 may be implemented in various ways, such as Bluetooth connections, near field communication (NFC) connections, connections made by cable (such as a universal serial bus (USB)-type cable), insertable connections (e.g., a Secure Digital (SD) card), connections made by a local area communication network, and even connections made by a wide area network such as the Internet. In various embodiments, UI device set 123 may include multiple components, such as a display screen, speakers, a microphone, wearable devices (such as goggles and smartwatches), a keyboard, a mouse, a printer, a touchpad, a game controller, and a haptic device. Storage 124 may be external storage, such as an external hard drive, or insertable storage, such as an SD card. Storage 124 may be persistent and / or volatile. In some embodiments, storage 124 may take the form of a quantum computing storage device that stores data in the form of qubits. In embodiments where computer 101 needs to have large amounts of storage (e.g., computer 101 stores and manages large databases locally), this 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 Internet of Things applications. For example, one sensor may be a thermometer and another sensor may be a motion detector.

[0026] Network module 115 is a collection of computer software, hardware, and firmware that enables computer 101 to communicate with other computers over WAN 102. Network module 115 may include hardware such as a modem or Wi-Fi® signal transceiver, software for packetizing and / or de-packetizing data for communication network transmission, and / or web browser software for communicating data over the Internet. In some embodiments, the network control and network forwarding functions of network module 115 execute on the same physical hardware device. In other embodiments (e.g., those utilizing software-defined networking (SDN)), the control and forwarding functions of network module 115 execute on physically separate devices, whereby the control function manages multiple different network hardware devices. Computer-readable program instructions for implementing the methods of the present invention may be downloaded to computer 101, typically from an external computer or external storage device, through a network adapter card or network interface included in network module 115.

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

[0028] End-user device (EUD) 103 is any computer system used and controlled by an end user (e.g., a customer of the enterprise that operates computer 101) and may take any of the forms described above with respect to computer 101. EUD 103 typically receives useful and useful data from the operation of computer 101. For example, in the hypothetical case where computer 101 is designed to provide recommendations to the end user, the recommendations would typically be communicated from network module 115 of computer 101 over WAN 102 to EUD 103. EUD 103 can then 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, etc.

[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 that collects and stores useful and useful data for use by other computers, such as computer 101. For example, in the hypothetical case where 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] A 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 capacity, without requiring direct, active management by users. Cloud computing typically leverages resource sharing to achieve consistency and economies of scale. Direct, active management of the computing resources of the public cloud 105 is performed by computer hardware and / or software in a cloud orchestration module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers comprising a host physical machine set 142, which is the entire set of physical computers included in and / or available to the public cloud 105. Virtual computing environments (VCEs) typically take the form of virtual machines in a virtual machine set 143 and / or containers in a container set 144. It is understood that these VCEs may be stored as images and may 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 newly instantiated VCEs, and manages active instances of VCE deployments. Gateway 140 is a collection of computer software, hardware, and firmware that enables public cloud 105 to communicate over WAN 102.

[0031] Here, we provide some further explanation of virtual computing environments (VCEs). A VCE can be stored as an "image." From this image, a new, active instance of the VCE can be instantiated. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to a feature of an operating system where the kernel allows the existence of multiple isolated user space instances called containers. These isolated user space instances typically behave as actual computers from the perspective of the programs running within them. A computer program running on a typical operating system can use all of the computer's resources, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running inside a container can only use the contents of the container and the devices assigned to the container; this feature is known as containerization.

[0032] A private cloud 106 is similar to a public cloud 105, except that its computing resources are available only for use by a single enterprise. While the private cloud 106 is shown as interacting with the 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 composite of multiple clouds of different types (e.g., private, community, or public cloud types), often implemented by different vendors. Each of the multiple clouds remains a separate, isolated entity, but in a larger hybrid cloud architecture, they are joined by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the constituent clouds. In this embodiment, both the public cloud 105 and the private cloud 106 are part of a larger hybrid cloud.

[0033] The computing environment described above in Figure 1 is only one example of a computing environment for incorporating, executing, and / or using aspects of the present invention. Other examples are possible. For example, in one or more embodiments, one or more of the components / modules of Figure 1 are not included in the computing environment and / or are not used in one or more aspects of the present invention. Furthermore, in one or more embodiments, additional and / or other components / modules may be used. Other variations are possible.

[0034] 2 illustrates another exemplary environment for DNS request obfuscation. The environment 200 includes a private network 202 with a client computer system / device 204 and private DNS servers 206a, 206b, ..., 206n. The client device 204 communicates DNS requests to, and receives responses from, the private DNS servers 206a, 206b, ..., 206n over a communication path 210. The communication path may be a wired and / or wireless communication link, such as an Ethernet-based wired or wireless connection, but more generally may be any suitable wireless and / or wired communication link for communicating data. Often, but not always, the communication path is implemented by hardware and software-based network equipment. The client device 204 and the private DNS server 206 may, in examples, be separate, discrete physical devices that are partially or completely co-located with, or remotely located from, each other.

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

[0036] Communication paths 212a, 212b, ..., 212n represent outbound and inbound communications to private DNS servers 206a, 206b, ..., 206n, respectively. For example, a private DNS server may issue outbound DNS requests to any / all of external DNS servers 208a, 208b, ..., 208m and receive responses in response to those requests. Communication paths 214a, 214b, ..., 214n represent inbound and outbound communications to external DNS servers 208a, 208b, ..., 208m, respectively. An external DNS server may receive DNS requests from any / all of private DNS servers 206a, 206b, ..., 206n and issue responses in response to those requests. Traffic flowing between the private DNS servers and external DNS servers may be implemented using DNS over TLS or DNS over HTTPS, for example, to increase security. Additionally, private DNS servers 206a, 206b, ..., 206n communicate with each other, as represented by communication path 211 between, for example, private DNS servers 206a and 206b, for communicating DNS requests and / or other types of communication.

[0037] The activities of the client device 204 include issuing DNS requests to one or more of the private DNS servers on the network 202. Programs such as web browsers prompt DNS lookups to retrieve and render requested web-served content. The private network 202 and its components are considered a trusted network by the client device 204, and therefore the private DNS server 206 is considered a trusted entity by 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 for handling client DNS requests.

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

[0040] Note that the exemplary environment of Figure 2 illustrates a plurality (n) of private DNS servers and a plurality (m) of external DNS servers by way of example only and not limitation. Aspects described herein encompass situations where there are any number (including only one) of private DNS servers and / or any number (including only one) of external DNS servers.

[0041] In the aspects described herein, DNS requests issued by and / or for DNS lookups on behalf of the client device 204, which may be referred to herein as “real” or legitimate DNS requests, are buried in a collection of noise, the noise taking the form of other DNS requests generated to decoy legitimate DNS requests for the client device 204. In this regard, a process involves generating or obtaining decoy DNS requests to obfuscate DNS request activity (legitimate DNS requests) processed by an organization's private DNS server. The decoys necessarily request resolutions different from legitimate requests, which may aid in obfuscation. The process can send these decoy DNS requests to an external DNS server for resolution, and by doing so strategically, can obfuscate legitimate DNS requests sent out for resolution. In this manner, the generated noise helps obfuscate legitimate DNS requests sent by the privacy DNS server to the external DNS server.

[0042] More specifically, multiple DNS lookup requests may be sent to the external DNS server, including both (i) legitimate DNS requests made on behalf of the client device 204 and (ii) decoy DNS requests generated to obfuscate / bury the legitimate DNS requests. The legitimate DNS requests are obfuscated by interspersing at least some of the decoy DNS requests generated and sent to the external DNS server, i.e., by sending the legitimate DNS requests to the external DNS server 208 with several decoy DNS requests sent along with, before, and / or after the legitimate DNS requests. As part of this obfuscation and interspersing, the decoy DNS requests are sent simultaneously with the legitimate DNS requests so that an actor observing DNS request activity from outside the private network 202 will only “see” the legitimate DNS requests as part of a larger set of DNS requests flowing from the private network 202 to the external DNS server. Note that the several decoy DNS requests that obfuscate the legitimate DNS requests do not necessarily need to be sent to the same external DNS server as the legitimate DNS requests. It is possible that the decoy DNS requests 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 flowing out of the private network will see a DNS request going to each of the external servers, so any given legitimate DNS request will be convoluted with requests going to more than just the target server for handling the legitimate DNS request.

[0043] Legitimate DNS requests resolved externally may be sent to different external DNS servers 208, as well as decoy DNS requests that are generated and sent to obfuscate legitimate DNS activity. In this manner, different legitimate DNS requests for DNS lookups for a client device may be obfuscated by being sent from different external DNS servers to randomly or otherwise selected external DNS servers. These legitimate DNS requests may be interspersed among decoy DNS requests that also flow to different external DNS servers. Spreading these requests to different external servers (and corresponding locations / sites, if the external DNS servers are located remotely from one another) significantly reduces the risk of an attacker seeing all of the upstream (external) DNS request activity, because it is easier for an attacker to compromise only a single external server rather than the entire set of external servers used, making it much more difficult to determine what is actually being looked up.

[0044] The generation and transmission of the decoy DNS requests may be performed according to configurable criteria, for example, criteria that dictate the lookup target of the generated decoy DNS request, e.g., the content requested. In other words, the decoy DNS requests may request resolution for specifically and intentionally targeted sites / pages rather than randomly selected ones, although random selection of decoy targets is also possible.

[0045] By way of example and not limitation, if a legitimate client DNS request targets retrieving news articles related to biotechnology, decoy DNS requests may be generated to target resolutions that are tailored based on the lookup target of the legitimate client DNS request. The decoy requests may target, for example, other news article servers or other servers that host content related to biotechnology. If the target is biotechnology news from one news website, some decoy requests may request resolutions that point to other types of content from that website and / or may request biotechnology or other types of content from other news websites.

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

[0047] The relevance level may be set with the primary consideration and goal being to generate decoys that appear least effective to outsiders spying on DNS requests emanating from the private network 202 with respect to legitimate user activity. It is logically predictable, without the need to snoop on DNS activity, that biotechnology companies and their particular client devices will issue a large number of resolution requests to biotechnology-related resources. If the noise (decoy DNS requests) generally pertain to content across a very broad set of topics unrelated to biotechnology, it may be informative to an unauthorized outside observer that those DNS requests are noise / decoys only, and that the legitimate DNS requests are biotechnology-related. In that example, the legitimate DNS requests are not properly obfuscated because they are relatively easily recognizable to an outside observer. On the other hand, if there are no or very few decoys targeting non-biotechnology content, legitimate DNS requests targeting non-biotechnology content may not be properly obfuscated. Thus, the relevance level may depend on the situation. Organizations whose legitimate DNS requests span a wide variety of subjects will not want their noise to be concentrated on just one subject, and organizations whose substantial amounts of legitimate DNS requests target very niche subtopics of broader categories will want their noise to be substantially within that broader category and not far from it.

[0048] Note that the generation of decoys for transmission can take into account both individual DNS requests and collections of DNS requests generated over time. Decoys generated from past activity can be used to obfuscate future DNS requests. While some decoys transmitted simultaneously with a given legitimate DNS request can be generated based on the request itself, decoys can also be generated based on previous legitimate DNS requests, either by the same client device or otherwise and / or at an earlier time. Previous legitimate DNS requests can help inform the generation of additional decoys for use in obfuscating future legitimate DNS requests. The effectiveness of obfuscation is enhanced when there are multiple active client devices making DNS queries, as this increases the original, or seed, data that serves as the basis for generating relevant decoy DNS queries.

[0049] Thus, decoy requests may be pre-generated based on previous legitimate requests for use in obfuscating subsequent legitimate requests. This may reduce the latency of identifying and obtaining decoys to send simultaneously with legitimate DNS requests, allowing legitimate DNS requests to be temporarily halted from being sent out until decoys to be used are identified and at least some are available for outbound transmission before sending the legitimate DNS requests. This also ensures that the effect of legitimate requests on generating decoys for obfuscation is spread over time, because those decoys may be used at a later point in time in connection with other legitimate DNS requests.

[0050] If there are no decoy requests generated from previous legitimate DNS requests and available for use with a given legitimate DNS request, then, by way of example, the decoys could be derived from seed requests based on very popular websites and / or decoys generated at the time based on legitimate requests.

[0051] Additional examples of sources from which decoy requests may be generated include one or more of the following to help ensure that noise matches the selected relevance level: Scrape results from search engines: This refers to search results for content provided at the lookup target of a legitimate DNS request. If the legitimate DNS request resolves to a site with biotechnology news, an automated search for biotechnology news can be performed using a search engine. The results from the search can inform other sites targeted by decoy requests. For example, decoy requests can be generated requesting the resolution of those search results. Crowdsourcing from other legitimate DNS requests (and / or decoys used therein) in the organization or user's organizational area: Other legitimate and / or decoy DNS requests for the organization generated based on those legitimate or similar DNS requests can be used as or inform the generation of decoy DNS requests for use with later legitimate requests. For example, in an organization where many users view a variety of different news sources, users' client devices generate legitimate DNS requests with lookups related to news content, which can prompt the generation of various decoy requests used in obfuscating those requests. Furthermore, loading the target content for such requests is expected to load various additional content (e.g., advertisements) that themselves prompt additional legitimate DNS requests. When a legitimate DNS request for news content arrives at a later point in time, the earlier legitimate news content DNS requests and the decoys generated from and / or used in their obfuscation can inform the source of decoys that may be generated and used in obfuscating later legitimate DNS requests. Administrator-provided choice of decoy / noise sources: Administrators or standard users can choose their own noise, for example with the option to configure which topics or links to use for obfuscation, hiding legitimate requests.

[0052] As described, in situations where there are multiple external DNS servers 208 available to process upstream DNS requests, both legitimate and decoy DNS requests may be spread across the multiple external servers 208. In some examples, any given outbound / external DNS request (legitimate or decoy) is sent to only one upstream (external) DNS server. In other words, as part of the obfuscation of a given legitimate DNS request, the same request is not sent to multiple external servers. By using multiple external DNS servers, this ensures that no single external server has the entire picture of the DNS history, and that the DNS lookup history maintained by any given external server includes both legitimate and decoy DNS requests.

[0053] Additionally, when there are multiple private DNS servers 206 handling legitimate DNS requests for client devices 204, such DNS requests can be distributed among them to further decentralize the specific source of the requests. In other words, a private DNS server receiving a DNS request from a client can have a different one of the private DNS servers serve the request for processing. After the request has been passed around internally within the private network any number of times, the last private DNS server that holds the request sends it to an external DNS server. The external DNS server sees that the request came from the last private DNS server but is unaware that the request passed through an intermediary private DNS server.

[0054] The generation and transmission of decoy DNS requests may also be performed according to configurable criteria that dictate when to send the decoy DNS requests. In one example, a continuous "heartbeat" of decoy requests is sent to ensure that user activity cannot be understood by monitoring the frequency and duration of DNS requests. This approach sends decoy DNS requests that obfuscate legitimate DNS requests sent, for example, after an organization's normal business hours. In cases where a user working after hours initiates a DNS request, the periodic sending of decoys helps obfuscate the legitimate requests, making it unclear to an outside observer which client is making the request and, further, which DNS requests streaming out of the private network 202 around that time are legitimate DNS requests.

[0055] Thus, configurable criteria may include the rate at which DNS requests are sent to external DNS servers. The rate may include the number of DNS requests sent per time segment, which may be the sum of both legitimate and decoy DNS requests sent. As an example, a private DNS server in a private network may be configured to send a total of 5,000 DNS requests per hour. The system may assume that all such requests are decoy requests unless a legitimate request is sent. Because the number of legitimate DNS requests made in that hour varies depending on user activity and is generally uncontrollable, a default practice may be to schedule decoy DNS requests to be sent unless a legitimate DNS request is pending. To ensure this "heartbeat" number of requests is substantially constant, the number of legitimate DNS requests sent is subtracted from the heartbeat number to determine the number of decoy requests to utilize. In this way, the number of decoy DNS requests to send in a time segment is based on the number of legitimate client DNS requests sent in that time segment, including the received DNS requests. The granularity of these numbers may be varied as desired. For example, the heartbeat count can be set per user, per client device, per group of client devices, per collection of all client devices in the network, or by any other level of granularity. For example, if a user generates 100 requests per hour and the heartbeat count for all outgoing DNS requests per hour for that user is 5,000, the system can reduce the number of decoy requests sent by 100, reaching 5,000-100=4,900 decoy requests sent in that time window.

[0056] As an enhancement to this heartbeat concept, the heartbeat rate can be dynamically adjusted based on the overall client DNS request activity load. Again, the granularity can be per single user, user group, organization, or any other level of granularity desired. In this approach, the system dynamically adjusts the rate of decoy request transmission based on the level of legitimate DNS requests over a period of time. Using the example above of 5,000 requests per hour, this rate may be sufficient to bury (by way of example) 100 or fewer legitimate requests per hour, but may be insufficient to adequately bury 3,000 legitimate requests per hour. An exemplary scheme provides thresholds or ranges of legitimate requests (e.g., 1 to 100, 101 to 500, 501 to 1,000, etc.) and respective heartbeat rates corresponding to those ranges (e.g., 5,000 requests, 20,000 requests, 50,000 requests, etc.) to ensure that a sufficient amount of noise is provided in the form of decoy requests to drown out the legitimate requests. Another approach to dynamic adjustment is to scale the number of decoy requests sent per unit of time based on the actual number, average number, or some other statistical number of legitimate requests actually serviced and / or estimated to be serviced during a unit of time. For example, the number of decoy requests sent can be a function (e.g., 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 a timespan, or the estimated number of legitimate requests to process during a unit of time. There may also be a target number of decoy requests sent for each legitimate request sent. Additionally, by monitoring in real time the number of legitimate DNS requests actually sent for external resolution during a unit of time, and dynamically adjusting the rate at which decoys are sent during that unit of time, the desired total number of requests sent during that period can be achieved.

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

[0058] In some scenarios with 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. While a legitimate DNS request ultimately originates from a client device, the request may pass through one or more private DNS server hops before reaching the private DNS server, which makes the external request to the external DNS server. In such a situation, the "source" of a DNS request requested by a private DNS server that sends to an external server and receives a response from it may include the client device from which the DNS request originated and / or any intervening private DNS servers to which the request was routed. Once the private DNS server communicates with the external server to resolve the request, it may provide the resolution to the client device, any one or more other private DNS servers in the private network, or a combination of the two. In certain embodiments, the resolution flows in the reverse direction of the path traveled from the client device to the private DNS server making the external request.

[0059] Another aspect described herein caches DNS responses by a private DNS server, and in some instances, retains the resolution for as long as possible, e.g., until the time to live (TTL) expires, at which point the record becomes invalid. A more extensive caching measure allows the system to minimize the number of legitimate DNS requests that are forced to flow from the private network to untrusted external DNS servers. Thus, processing by the private DNS server may further include, based on receipt of the DNS request, determining whether the resolution of the DNS request has been cached by the private DNS server, and then, based on a determination that the resolution of the DNS request has not been cached by the private DNS server, obfuscating the DNS request as part of the external lookup.

[0060] Extending this, the private DNS server handling the request can utilize other private DNS servers on the network by initiating an attempt to resolve the DNS request with one or more of them, for example, by sending the request to one or more of them and / or by asking whether any one or more of them have a cached resolution for the request or access to it. By assuming that the DNS records cached on the private network are valid, the system may attempt an authoritative DNS resolution to one of the private DNS servers and avoid making an external request if possible. In fact, large organizations are likely to run "clusters" of private DNS servers that cooperate to avoid making duplicate lookups to any external servers if the cached resolution on one of the private DNS servers is valid. The receiving private DNS server can check whether the resolution is cached on any other private DNS servers on the network and, if no other private DNS servers on the network have the resolution, decide to obfuscate the request as part of the server's external query to an external DNS server. Alternatively, the DNS server can pass the request to one or more other private DNS servers to process in a similar manner. Another approach could be for example for the receiving DNS server to know what resolutions other private DNS servers in the network have cached, using a distributed data structure where private DNS servers tell each other what they have cached. Another option could be to have cooperating devices on the network that determine what each private DNS server has cached and inform the querying private DNS server where to send the DNS request for resolution, for example, whether to send the DNS request to a specific other private DNS server on the network, or to an external DNS server.

[0061] A private DNS server that sends a DNS request for external resolution may receive and cache the resolution. In addition, it may send the resolution to other private DNS servers in the network. In a situation where a first private DNS server sends a DNS request for processing by one or more other private DNS servers and the DNS request is resolved by a second private DNS server in the network, a DNS response may be returned to the first server and cached, either from a cached resolution held by the second private DNS server or by an external lookup. In this way, the first private DNS server may receive a DNS response from the second private DNS server in response to a DNS request sent by the first private DNS server to the second server, and cache this DNS response as the resolution for the DNS request sent by the first server to the second server.

[0062] In some embodiments, the activity of obfuscating DNS requests sent to external servers can be selectively enabled and disabled. A business or individual user may not always want decoy DNS requests generated and sent as noise, and in such cases, this activity can be controlled by enabling / disabling it via an appropriate entity. Thus, the process may provide for selective enabling and disabling of obfuscation of DNS request activity handled by a private DNS server. Disabling can be a scheduled or otherwise temporary action. This may be desirable in situations where providing decoy requests would be problematic. Disabling the activity may be desirable, for example, during nighttime hours or in situations where an external DNS server identifies a large number of requests coming from a private network.

[0063] Aspects described herein advantageously provide enterprise-level DNS obfuscation. In a business or enterprise network, the system provides the ability to effectively hide user DNS traffic from traditional vectors of information disclosure / confidentiality data leakage. It also significantly reduces the "chain of trust" required to securely make DNS requests, avoiding unnecessary reliance on external entities and their potentially flawed security implementations. By hosting trusted local DNS servers, an organization gains control over DNS requests following 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 identities of websites visited by the organization's users from attackers. This can be effective in addressing situations where an attacker knows that a particular website is frequently visited by the organization and therefore exploits the website's weak security to compromise the site and add malicious payloads there as a means to infiltrate the organization's systems (watering hole attacks).

[0064] Additionally, the aspects described herein do not depend on the effectiveness of security measures implemented by external DNS servers to ensure security. For example, some approaches encrypt DNS requests passing through untrusted servers to hide the domain being queried. In this approach, the DNS request is encrypted and attached to a request made to an external server, but the external server is assumed to be trusted because the external server decrypts and resolves the request before encrypting and passing the result to the client. Such an approach is intended not to hinder third-party monitoring (not involving the external DNS server itself) and still allows external DNS server operators to track and monitor queries and associate them with source IP addresses or specific users. It does not hinder monitoring by DNS operators. In contrast, the effectiveness of the obfuscation strategies described herein does not depend on the trust status of the external DNS servers involved.

[0065] FIG. 3 illustrates in further detail an example DNS request obfuscation module (e.g., DNS obfuscation module 300 of FIG. 1 ) for incorporating and / or using aspects described herein. In one or more aspects, DNS request obfuscation module 300 includes various sub-modules used, in one example, to perform DNS request obfuscation. The sub-modules may be or include, for example, computer-readable program code (e.g., instructions) in a computer-readable medium, for example, persistent storage (e.g., persistent storage 113, such as a disk) and / or a cache (e.g., cache 121). The computer-readable medium may be part of a computer program product, which may be executed by and / or using one or more computers or devices and / or processors or processing circuitry thereof, such as, for example, computer 101, EUD 103, remote server 104, or a computer in cloud 105 / 106 of FIG. 1 , which may be or include, for example, one or more private DNS servers 206.

[0066] Referring to FIG. 3, the DNS obfuscation module 300 includes a decoy DNS request generator submodule 302 for generating decoy DNS requests to send to an external DNS server, a DNS request receiving submodule 304 for receiving legitimate DNS requests, for example, from a client device and / or other private DNS servers in the network, a DNS request resolution determination submodule 306 for determining whether the resolution of the received DNS request has been cached by the private DNS server, a DNS request obfuscation submodule 308 for obfuscating the DNS request by sending the DNS request to an external DNS server interspersed with the generated decoy DNS requests, a DNS response receiving submodule 310 for receiving DNS responses to the sent DNS requests from the external DNS server, and a DNS response providing submodule 312 for providing the DNS response to the source of the received DNS request.

[0067] In an example, the DNS obfuscation module 300 runs on each private DNS server of one or more private DNS servers in an organization's private network.

[0068] 4 illustrates an exemplary process for DNS request obfuscation according to aspects described herein. The process may, in one or more examples, be performed by a processor or processing circuitry of one or more computers / computer systems, such as those described herein, and more particularly, those described with reference to FIG. 1. In one example, code or instructions implementing the process of FIG. 4 are part of a module, such as private DNS server module 300, of one or more private DNS servers working in conjunction with each other as described herein to fulfill client DNS requests. In other examples, the code may be included in one or more modules and / or one or more sub-modules of one or more modules. Various options are available.

[0069] 4 includes generating 402 decoy Domain Name System (DNS) requests to obfuscate DNS request activity processed by one or more private DNS servers of an organization and transmitting the decoy DNS requests to one or more external DNS servers for resolution. The generation and transmission of the decoy DNS requests may be performed according to configurable criteria that dictate the lookup target for the generated decoy DNS requests and the timing for transmitting the decoy DNS requests. For example, the configurable criteria may specify a relevance level to use in generating the decoy DNS requests, where the relevance level indicates a desired level of relevance between the lookup target for the generated decoy DNS requests and the lookup target of the processed DNS requests.

[0070] 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 processed DNS request and / or by crowdsourcing other DNS requests of the organization, where the generated decoy DNS requests include (i) similar DNS requests from the other crowdsourced DNS requests, and / or (ii) at least one decoy DNS request generated based on the similar DNS requests.

[0071] 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 the number of DNS requests to send per time segment, where the number of decoy DNS requests to send in a time segment is based on the number of client DNS requests sent in the time segment, and the rate may be dynamically adjusted based on the overall client DNS request activity load.

[0072] The process of Figure 4 continues with receiving (404) a DNS request for a DNS lookup on behalf of the client device by the private DNS server. The DNS request may be received from the client device or from another private DNS server of the organization, for example. The private DNS performing the process of Figure 4 may handle this request differently, depending on the circumstances, for example, by making an external request for resolution and / or by providing it to another private DNS server of the organization for resolution.

[0073] In the example of FIG. 4 , the process continues by determining (406) whether the resolution of the DNS request has been cached by the private DNS server based on receiving the DNS request. If so (406, Y), the process provides (408) a response to the client using the cached resolution. Otherwise (406, N), the process continues by obfuscating (410) the DNS request by sending the DNS request to one or more external DNS servers, interspersing at least some of the decoy DNS requests that are generated and sent to the external DNS server. 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 receives (404) the DNS request from the client device itself and may therefore provide the DNS response to the client device. Alternatively, a private DNS server may receive DNS requests from another private DNS server of the organization and provide DNS responses accordingly to (at least) that other private DNS server and / or the client device.

[0074] As an enhancement, the process can provide for selective enabling and disabling of obfuscation of DNS request activity processed by the private DNS server, and generating (402) decoy DNS requests and obfuscating (410) received DNS requests is performed based on the selective enabling of obfuscation of DNS request activity processed by the private DNS server.

[0075] Additionally, an exemplary process executed by a private DNS server, e.g., its DNS obfuscation module, may receive a DNS request from a client device or another private DNS server and send the DNS request to another one of the private DNS servers for processing. The process may receive the DNS request, determine that the resolution of the DNS request is not cached by the private DNS server, and initiate an attempt to resolve the DNS request with at least one other private DNS server of the organization. For example, the private DNS server may send the request to the identified other private DNS servers. For example, a minimum number of hops to other private DNS servers may be required before the DNS request is sent for external resolution.

[0076] 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 this DNS response as a resolution for the DNS request, so that the resolution is cached and available to resolve further DNS requests at a later point in time if needed.

[0077] Although various embodiments have been described above, these are examples only.

[0078] 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 is further understood that as used herein, the terms "comprise" and / or "comprising" specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0079] It is intended to include corresponding structure, material, or acts of any means or step-plus-function element in the following claims, and their equivalents, where available, for performing that function in combination with other claimed elements as specifically claimed. While a description of one or more embodiments has been presented for purposes of illustration and description, it is not intended to be exhaustive or to be limited to the disclosed form. Many modifications and variations will be apparent to those skilled in the art. The embodiments were chosen and described to best explain various aspects and practical applications, and to enable those skilled in the art to understand various embodiments with various modifications as suitable for the particular use contemplated.

Claims

1. generating decoy Domain Name System (DNS) requests to obfuscate DNS request activity processed by the organization's private DNS servers and sending the decoy DNS requests to one or more external DNS servers for resolution; receiving, by the private DNS server, a DNS request for a DNS lookup on behalf of 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 interspersed with at least some of the decoy DNS requests generated and sent to the external DNS server; receiving a DNS response from the external DNS server for the transmitted DNS request; and Providing the DNS response to the source of the DNS request.

1. A computer-implemented method comprising:

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

3. 3. The method of claim 2, wherein the configurable criteria includes 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 send per time segment, and wherein the number of decoy DNS requests to send in a time segment is based on a number of client DNS requests sent in the time segment, including the received DNS request.

4. The method of claim 3 , wherein the rate is dynamically adjusted based on overall client DNS request activity load.

5. 3. The method of claim 2, wherein the configurable criteria specify a relevance level to use in generating the decoy DNS request, the relevance level indicating a desired level of relevance between the lookup target of the generated decoy DNS request and a lookup target of the DNS request.

6. At least a portion of the decoy DNS request: Search results relating to content provided at the lookup target of the DNS request; and crowdsourcing other DNS requests for the organization, wherein the generated decoy DNS requests include at least one selected from the group consisting of: (i) similar DNS requests among the crowdsourced other DNS requests; and (ii) at least one decoy DNS request generated based on the similar DNS requests; The method of claim 5 , wherein the generated signal is generated based on at least one selected from the group consisting of:

7. The method of 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. 2. The method of claim 1, wherein the private DNS server receives the DNS request from another private DNS server of the organization, and the private DNS server provides the DNS response to at least one selected from the group consisting of other private DNS servers and the client device.

9. 2. The method of claim 1, further comprising determining, based on receipt of the DNS request, whether a resolution of the DNS request has been cached by the private DNS server, and wherein obfuscation of the DNS request is performed based on a determination that a resolution of the DNS request has not been cached by the private DNS server.

10. 2. The method of claim 1, further comprising providing selective enabling and disabling of obfuscation of DNS request activity processed by the private DNS server, wherein generating the decoy DNS requests and obfuscating the received DNS requests is performed based on selective enabling of obfuscation of DNS request activity processed by the private DNS server.

11. 2. The method of claim 1, wherein the DNS request is a first DNS request; The method further comprises: receiving a second DNS request; determining that a resolution of the second DNS request is not cached by the private DNS server; and initiating a resolution attempt of the second DNS request with at least one other private DNS server of the organization. A method comprising:

12. receiving a DNS response from another private DNS server of the at least one other private DNS server in response to the second DNS request, and caching the DNS response as a resolution for the second DNS request. The method of claim 11 further comprising:

13. 2. The method of claim 1, wherein the one or more external DNS servers include a plurality of external DNS servers; The method further comprises: receiving a plurality of other DNS requests for DNS lookups for the client device; and repeating the obfuscation for each of the other DNS requests; For each of the other DNS requests, a different external DNS server of the plurality of external DNS servers is selected to send the other DNS request interspersed with respective other decoy DNS requests.

14. 14. The method of claim 13, wherein obfuscating the DNS request further comprises 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. memory; and a processor in communication with the memory 1. A computer system comprising: generating decoy Domain Name System (DNS) requests to obfuscate DNS request activity processed by the organization's private DNS servers and sending the decoy DNS requests to one or more external DNS servers for resolution; receiving, by the private DNS server, a DNS request for a DNS lookup on behalf of 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 interspersed with at least some of the decoy DNS requests generated and sent to the external DNS server; receiving a DNS response from the external DNS server for the transmitted DNS request; and Providing the DNS response to the source of the DNS request.

10. A computer system configured to perform a method comprising:

16. 16. The computer system of claim 15, wherein the step of generating and sending the decoy DNS requests is performed according to configurable criteria that dictate 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 send per time segment, and wherein the number of decoy DNS requests to send in a time segment is based on a number of client DNS requests sent in the time segment, including the received DNS request.

17. 16. The computer system of claim 15, wherein the step of generating and sending the decoy DNS request is performed according to configurable criteria that dictate a lookup target of the generated decoy DNS request and a timing for sending the decoy DNS request, wherein the configurable criteria specify a relevance level to use in generating the decoy DNS request, the relevance level indicating a desired level of relevance between the lookup target of the generated decoy DNS request and a lookup target of the DNS request.

18. 16. The computer system of 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 other private DNS servers and the client device.

19. 16. The computer system of claim 15, wherein the one or more external DNS servers include a plurality of external DNS servers; The method further comprises: receiving a plurality of other DNS requests for DNS lookups for the client device; and repeating the obfuscation for each of the other DNS requests; 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 requests interspersed with respective other decoy DNS requests.

20. is readable by processing circuitry; generating decoy Domain Name System (DNS) requests to obfuscate DNS request activity processed by the organization's private DNS servers and sending the decoy DNS requests to one or more external DNS servers for resolution; receiving, by the private DNS server, a DNS request for a DNS lookup on behalf of 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 interspersed with at least some of the decoy DNS requests generated and sent to the external DNS server; receiving a DNS response from the external DNS server for the transmitted DNS request; and Providing the DNS response to the source of the DNS request. a computer-readable storage medium storing instructions for execution by the processing circuitry to perform a method comprising:

1. A computer program product comprising:

Images