Identity-based application of domain filtering rules using Domain Name System (DNS) platforms

Abstract

Aspects of the present disclosure relate to identity-based DNS traffic routing and monitoring. A computing platform may establish a secure DNS session by performing an encrypted session handshake with a client device using an encrypted DNS process, including receiving a security certificate for the encrypted DNS process that identifies a user of the client device. The computing platform may receive an encrypted DNS query request comprising a request for an IP address of a specified domain name. The computing platform may determine the identity of the user based on the security certificate. The computing platform may determine a security policy indicating domain match criteria and corresponding actions to be taken for matching domain names based on the user's identity. The computing platform may determine a first action corresponding to the domain name and, based on the first action, determine an encrypted DNS query response.

Description

[Technical Field]

[0001] The present disclosure relates to identity-based application of domain filtering rules using a Domain Name System (DNS) platform. CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application No. 63,469,158, filed May 26, 2023, entitled "Identity-Based Application of Domain Filtering Rules Using Domain Name System (DNS) Platform," and U.S. Provisional Patent Application No. 63 / 410,544, filed September 27, 2022, entitled "Identity-Based Application of Domain Filtering Rules Using Domain Name System (DNS) Platform," both of which are incorporated herein by reference in their entireties. [Background technology]

[0003] Aspects of the present disclosure relate to computing hardware and software, particularly distributed computing hardware and software configured to process Domain Name System (DNS) queries. In some examples, DNS policies and / or other threat intelligence may be applied to a protected network (e.g., an entity network) and accessed from a particular location (e.g., an entity office). However, in some examples, individuals may access the entity network from a remote location and such DNS policies may not apply. As remote access becomes increasingly prevalent, it may be important to improve the threat intelligence deployed to such remote devices. Summary of the Invention [Problem to be solved by the invention]

[0004] In some examples, encrypted DNS (such as that standardized in RFC 7858 and RFC 8310) can be used to enhance communication security and user privacy in the transmission of DNS queries and responses. For example, communications can be secured using DNS over Transport Layer Security (DOT). DNS over TLS can involve embedding DNS messages in a secure TLS channel. For example, a client device and a DNS server can exchange TLS handshake messages to establish a secure TLS channel. In such a case, the client device notifies the DNS server of its TLS capabilities, and the DNS server can respond to confirm TLS parameters that can be used to secure the TLS channel. For example, the DNS server can send a message containing a certificate identifying the DNS server and the DNS server's digital signature, which is verified by the client device (e.g., by checking a trusted certificate authority list, public key pinning, and / or other methods). Once this handshake is complete, the client device and the DNS server can exchange encrypted messages (e.g., DNS query requests, DNS query responses, and other information). In such a case, a common DNS server can be shared among multiple client devices, allowing a generic or common DNS policy to be applied among these devices. As adoption of encrypted DNS increases, improving or refining DNS policy enforcement may be important. [Means for solving the problem]

[0005] Aspects of the present disclosure provide effective, efficient, scalable, and convenient technical solutions that address and overcome technical problems related to traffic routing and monitoring. According to one or more embodiments of the present disclosure, an ID-based DNS routing platform configured to apply security policies specific to an identified user to DNS queries, and including at least one processor, a communications interface, and a memory storing computer-readable instructions, may establish a secure DNS session using an encrypted DNS process, including performing an encrypted session handshake between the ID-based DNS routing platform and a client device, and performing the encrypted session handshake may include receiving, from the client device, a security certificate for the encrypted DNS process that identifies a user of the client device. While the secure DNS session is established, the computing platform may receive, from the client device, an encrypted DNS query request that includes a request for an Internet Protocol (IP) address of a domain name, where the encrypted DNS query request specifies the domain name. The computing platform may determine the identity of the user based on the security certificate. The computing platform can determine a user-specific security policy based on the user's identity, the security policy including one or more domain name filtering rules, each domain name filtering rule including a respective domain match criterion and a corresponding action to be taken for a matching domain name. The computing platform can determine, based on the domain name in the encrypted DNS query request, a first action corresponding to the domain name in response to the encrypted DNS query request using the one or more domain name filtering rules.The computing platform can determine an encrypted DNS query response based on the first action corresponding to the domain name, and determining the encrypted DNS query response can further include performing an upstream request to the IP address of the domain name to identify the IP address of the domain name. The computing platform can send the encrypted DNS query response to the client device.

[0006] In one or more examples, the security policy is user-specific based on an organization associated with the user of the client device, and the encrypted DNS query request can be received from the client device while the client device is transmitting the encrypted DNS query request from outside the organization's protected network. In one or more examples, the corresponding action taken for the matching domain names can indicate whether traffic should be blocked, allowed, or logged for each of the matching domain names.

[0007] In one or more examples, determining the first action corresponding to the domain name may include determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be blocked. In one or more examples, the encrypted DNS query response may be an IP address of a block notification page.

[0008] In one or more examples, the encrypted DNS query response may be a notification that the requested IP address has been blocked. In one or more examples, determining the first action corresponding to the domain name may include determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be allowed.

[0009] In one or more examples, the encrypted DNS query response may be an IP address notification of a server associated with the domain name in the encrypted DNS query request. In one or more examples, determining the first action corresponding to the domain name may include determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be logged by the proxy server.

[0010] In one or more examples, the encrypted DNS query response may be an IP address of a proxy server. In one or more examples, the encrypted DNS query response is configured such that outgoing and incoming traffic to and from the IP address of a server associated with the domain name of the encrypted DNS query request is conducted through the proxy server.

[0011] In one or more examples, the proxy server (1) receives outgoing network traffic from the client device, the outgoing network traffic (a) indicating a proxy IP address of the proxy server as a destination IP address and (b) including data destined for a server associated with the domain name; (2) receives inbound network traffic from the server associated with the domain name, the inbound network traffic including a response to the outgoing network traffic; (3) logs the network traffic based on a domain match criterion of the domain name and a corresponding action performed on the domain name, the network traffic including one or more of the outgoing network traffic and the inbound network traffic; and (4) can send the inbound network traffic to the client device.

[0012] In one or more examples, the proxy server can (1) prompt the client device to provide a security credential; (2) determine one or more network policies based on the security credential, the one or more network policies indicating (a) traffic associated with a potential security threat for which traffic should be logged and (b) metadata to be collected about the traffic related to the potential security threat; (3) collect metadata for the traffic associated with the potential security threat; and (4) send the metadata to the ID-based DNS routing platform.

[0013] In one or more examples, the network interface of the client device may be pre-configured to send DNS requests to an IP address of the identity-based DNS routing platform, and a security certificate may be installed on the client device prior to receiving the encrypted DNS query request. In one or more examples, the client device is pre-configured based on installation of an entity security profile on the client device, which causes the client device to send DNS requests to the IP address of the identity-based DNS routing platform. In one or more examples, determining a security policy for the user may include determining to apply one of a user-specific policy, an organization-level policy, or a default policy to the user. In one or more examples, the one or more domain name filtering rules may include a whitelist, a blacklist, and a watchlist, and each matching domain name may be included in one of the whitelist, the blacklist, or the watchlist.

[0014] In one or more examples, determining the first action to take for the domain name includes identifying whether the domain name is on a whitelist, a blacklist, or a watchlist, and (1) the first action is to block traffic to the IP address of the domain name if the domain name is on the blacklist, (2) the first action is to log traffic to the IP address of the domain name if the domain name is on the watchlist, and (3) the first action is to allow traffic to the IP address of the domain name if the domain name is on the whitelist. In one or more examples, the encrypted session handshake can be a Transport Layer Security (TLS) handshake.

[0015] In one or more examples, determining the identity of the user may further include determining the identity of the user based on at least the first identity and the second identity. In one or more examples, the first identity and the second identity may be embedded in an encrypted DNS query request at the client device.

[0016] In one or more examples, the first encrypted DNS query request may be a path of the first encrypted DNS query request that is routed along a DNS path from the client device to the ID-based DNS routing platform and recurses through different DNS servers to build a response back to the client device. In one or more examples, a first ID may be embedded in the encrypted DNS query request at the client device and a second ID may be embedded in the encrypted DNS query request at an intermediate server along the DNS path. In one or more examples, the first ID corresponds to a first domain name filtering rule and the second ID corresponds to a second domain name filtering rule, and determining the security policy may include resolving a conflict between the first domain name filtering rule and the second domain name filtering rule.

[0017] These features, along with many others, are described in detail below. [Brief explanation of the drawings]

[0018] The present disclosure is illustrated by way of example, and not limitation, in the accompanying drawings in which like reference numerals indicate similar elements and in which: [Figure 1A] FIG. 1A illustrates an exemplary computing environment configured to provide improved traffic routing and monitoring, in accordance with one or more exemplary embodiments. [Figure 1B] FIG. 1B illustrates an exemplary computing environment configured to provide improved traffic routing and monitoring, in accordance with one or more exemplary embodiments. [Figure 1C] FIG. 1C illustrates an exemplary computing environment configured to provide improved traffic routing and monitoring in accordance with one or more exemplary embodiments. [Figure 2A] FIG. 2A illustrates an example sequence of events for improved traffic routing and monitoring in accordance with one or more example embodiments. [Figure 2B] FIG. 2B illustrates an example sequence of events for improved traffic routing and monitoring in accordance with one or more example embodiments. [Figure 2C] FIG. 2C illustrates an example sequence of events for improved traffic routing and monitoring in accordance with one or more example embodiments. [Figure 2D] FIG. 2D illustrates an example sequence of events for improved traffic routing and monitoring in accordance with one or more example embodiments. [Figure 2E] FIG. 2E illustrates an exemplary sequence of events for improved traffic routing and monitoring in accordance with one or more exemplary embodiments. [Figure 2F]FIG. 2F illustrates an exemplary sequence of events for improved traffic routing and monitoring in accordance with one or more exemplary embodiments. [Figure 2G] FIG. 2G illustrates an example sequence of events for improved traffic routing and monitoring in accordance with one or more example embodiments. [Figure 2H] FIG. 2H illustrates an exemplary sequence of events for improved traffic routing and monitoring in accordance with one or more exemplary embodiments. [Figure 2I] FIG. 2I illustrates an exemplary sequence of events for improved traffic routing and monitoring in accordance with one or more exemplary embodiments. [Figure 2J] FIG. 2J illustrates an exemplary sequence of events for improved traffic routing and monitoring in accordance with one or more exemplary embodiments. [Figure 2K] FIG. 2K illustrates an exemplary sequence of events for improved traffic routing and monitoring in accordance with one or more exemplary embodiments. [Figure 3] FIG. 3 illustrates an example method for improved traffic routing and monitoring in accordance with one or more example embodiments. [Figure 4] FIG. 4 shows an example diagram for illustrating improved traffic routing and monitoring in accordance with one or more example embodiments. [Figure 5] FIG. 5 shows an example diagram for illustrating improved traffic routing and monitoring in accordance with one or more example embodiments. [Figure 6A] FIG. 6A illustrates an example sequence of events for improved traffic routing and monitoring in accordance with one or more example embodiments. [Figure 6B] FIG. 6B illustrates an example sequence of events for improved traffic routing and monitoring in accordance with one or more example embodiments. [Figure 6C] FIG. 6C illustrates an example sequence of events for improved traffic routing and monitoring in accordance with one or more example embodiments. [Figure 6D] FIG. 6D illustrates an example sequence of events for improved traffic routing and monitoring in accordance with one or more example embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0019] In the following description of various exemplary embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration various embodiments in which aspects of the present disclosure may be practiced. In some instances, other embodiments may be utilized, and structural and functional changes may be made without departing from the scope of the present disclosure.

[0020] Various connections between elements are described below. It should be noted that these connections are general and, unless otherwise specified, may be direct or indirect, wired or wireless, and the specification is not intended to be limiting in this respect.

[0021] As a brief introduction to concepts described further herein, one or more aspects of the disclosure relate to identity-based traffic routing and monitoring. For example, an individual may work from home or may work remotely from the physical location of the entity to which the employee belongs. In such cases, the individual may not have local access to the entity's network but may instead operate from a home or other remote network. For example, an individual may work remotely and use a virtual provisioning network (VPN) to tunnel traffic through one or more enterprise security devices. Below are some examples: In the first example, an employee works from home and connects to the enterprise network through a home router. In the second example, an employee works from home and connects to the enterprise network via a mobile / cellular network. In the third example, an employee works on the employer's premises but connects to the enterprise network via public Wi-Fi or a mobile / cellular network. In the fourth example, an employee works from a location other than the employer's premises (e.g., a coffee shop or other location) and connects to the enterprise network via public / commercial Wi-Fi or a mobile / cellular network. In a fifth example, an employee works from the employer's premises and is directly connected to the private corporate network via Wi-Fi or a wired connection. In a sixth example, an employee may be connected to the Internet in any of the situations described in examples 1 through 4 and may use a VPN to connect to the corporate network so that traffic (including DNS requests) is partially or fully routed through the corporate network gateway. In a seventh example, an employee may be connected to the Internet as described in any of the situations described in examples 1 through 4, but may not be connected to the corporate VPN.In an eighth example, an employee may connect using multiple devices (e.g., a phone, a laptop computer, a desktop computer, and / or other devices) from the same location, but one or more of the devices may connect to the corporate network through different methods described in Examples 1 through 5. In a ninth example, an employee may connect from a single device that supports multiple virtual devices, such as virtual machines (VMs) and / or profiles (e.g., a personal profile, a work profile, and / or other profiles), and one VM or profile may connect in a different way with another virtual machine or profile (e.g., a work profile connected to a corporate VPN and a personal profile connected directly to the Internet without using a VPN).

[0022] As described in further detail below with respect to exemplary sequences of events, in any or all of these examples, all traffic from individual devices may be routed through an enterprise network gateway, which may be configured as a packet filtering device, e.g., the gateway may have packet filtering rules and / or other network rules tailored to the enterprise that may be applied to the traffic.

[0023] However, in some instances, individuals may perform multiple work-related tasks and functions using one or more computing devices (e.g., mobile devices, etc.), virtual devices, profiles, applications (e.g., browsers, etc.), and / or systems / applications, which may not always be connected to the enterprise network when work-related tasks are being performed. Therefore, traffic from mobile devices may not pass through existing enterprise security appliances, such as packet filtering devices. Therefore, in such cases, packet filtering and / or other network rules may not be applied to traffic from mobile devices, potentially exposing the device and / or enterprise to malicious attacks vectored via Internet traffic. Similarly, simply deploying packet filtering functionality on mobile devices for local operation may be ineffective because deploying packet filtering functionality is a process that requires hardware performance beyond that available on typical mobile devices, and packet filtering rules may be updated periodically and / or dynamically.

[0024] Thus, what is described herein is a solution to this technical problem. A user is directed to an ID-based DNS routing platform, which can identify the user and apply user-specific routing rules to traffic to and from the user's mobile device. For example, a client device may establish a secure DNS channel with the ID-based DNS routing platform and send encrypted DNS query requests and responses. In some examples, upon establishing the secure DNS channel, the client device provides the ID-based DNS routing platform with an encrypted DNS certificate, which can be customized on a granular (or other individualized) basis to identify the originating device or user within the protected enterprise environment and which the ID-based DNS routing platform can use to identify the respective user. Once the identity is determined, the ID-based DNS routing platform may identify routing rules (which may be defined, for example, by the enterprise) specific to that user and provide an encrypted DNS query response based on the routing rules, which may indicate, for example, the requested IP address, indicate that the requested IP address is blocked, indicate a proxy IP address (such as a proxy server that can monitor traffic between the client device and the target server), and other information.

[0025] Further described herein is the use of unencrypted DNS query requests to embed identity information (e.g., as opposed to the encrypted DNS methods described above). In some examples, the identity information may not be encrypted within the unencrypted DNS query. For example, the identity information may be embedded using clear text in the unencrypted DNS query request. In some examples, the identity information may not be encrypted within the unencrypted DNS query.

[0026] In some examples, multiple identities may be embedded in a DNS query request. For example, multiple systems may add, replace, remove, and / or modify identities along the path of the DNS query request. In some examples, these multiple identities may be included in a daisy chain of DNS query requests. In some examples, each identity has a corresponding policy, so attaching multiple different identities may result in one or more policies that conflict with each other. In such cases, the policies can be reconciled and / or conflicts can be resolved to create an overall policy for the application.

[0027] In some examples, various servers along the DNS path (e.g., authoritative servers, etc.) may be analyzed based on the threat context, and the DNS path may be modified accordingly. Similarly, the initial routing of subsequent DNS query requests may be controlled accordingly (which may be for a predetermined period of time, or indefinitely, in some examples).

[0028] In some examples, DNS responses may be modified to enable routing of traffic through a proxy or gateway, along with further monitoring / logging. Additionally or alternatively, DNS responses may be modified to include local rules that are implemented (e.g., enabling client-side blocking, allowing, monitoring / logging, and / or other actions). In some examples, DNS responses may be modified to shorten the time-to-live (TTL) for certain domains (e.g., the domain is on a watchlist, little or no cyber threat intelligence is known for the domain, etc.), which may cause the domain to be evicted from the cache after a short period of time.

[0029] Operating in this manner, the DNS infrastructure can be leveraged to perform actions and / or implement solutions not originally intended. For example, the DNS infrastructure may be used to essentially implement distributed authoritative record delegation. Furthermore, authoritative servers may be configured to allow the owner of a given domain to control what information exists about that domain. However, the DNS infrastructure was not originally designed to evict bad domain information from caches within a short period of time (e.g., 5 seconds), as described herein. Similarly, the DNS infrastructure was not originally designed to implement intelligence command delivery, as further described herein. These capabilities result in improved threat detection and prevention, among other capabilities described herein. Thus, the systems and methods described herein can leverage the DNS infrastructure to perform actions not originally intended, thus providing technical advantages and solutions. These and other features are described in more detail below.

[0030] 1A through 1C illustrate an exemplary computing environment that provides improved traffic routing and monitoring in accordance with one or more exemplary embodiments. With reference to FIG. 1A, computing environment 100 may include one or more computer systems. For example, computing environment 100 may include a traffic routing and monitoring platform 102, a proxy server 103, a first client device 105, a second client device 106, a third client device 107, a target server 108, and a gateway server 115.

[0031] As described further below, the traffic routing and monitoring platform 102 may be a computer system including one or more computing devices (e.g., servers, server blades, etc.) and / or other computer components (e.g., processors, memory, communication interfaces), which may be used for traffic routing, traffic monitoring, DNS responses, and / or other functions as described further below. In these examples, the traffic routing and monitoring platform 102 may be configured to identify a user based on security credentials and apply personalized rules to traffic received from that user (which may include, for example, allowing, blocking, and / or monitoring traffic). For example, the traffic routing and monitoring platform may be configured for identity-based DNS routing.

[0032] In some examples, the traffic routing and monitoring platform 102 may be a DNS server and may be configured to provide DNS responses to DNS queries. For example, the traffic routing and monitoring platform 102 may be configured to provide an IP address (e.g., the IP address of the target server 108) corresponding to a provided domain name (e.g., a domain name corresponding to the target server 108). In some examples, a separate DNS server, separate from the traffic routing and monitoring platform 102, may be used to process the DNS queries.

[0033] The proxy server 103 may be and / or may include one or more computing devices (e.g., servers, server blades, and / or other devices) and / or other computer components (e.g., processors, memory, communication interfaces) that may act as an intermediary between client devices (e.g., first client device 105, second client device 106, third client device 107, and / or other client devices) and target server 108. For example, the proxy server 103 may be configured to receive traffic directed to the target server 108 and log both outbound and inbound traffic to the target server 108 accordingly. The proxy server 103 may further be configured to share these traffic logs with the traffic routing and monitoring platform 102.

[0034] The first client device 105 may include one or more devices, such as a laptop computer, a desktop computer, a mobile device, a tablet, a smartphone, and / or other personal computing devices. For example, the first client device 105 may be a computing device configured to provide an encrypted DNS query request (e.g., to the traffic routing and monitoring platform 102) and receive an encrypted DNS query response in response. Additionally, the first client device 105 may be configured to access an IP address once received as an encrypted DNS query response. In some examples, the first client device 105 may be configured to establish a secure session with the traffic routing and monitoring platform 102 (e.g., during which the DNS query may be sent). In these cases, the first client device 105 may provide a security credential, which may be verified and used to establish the secure session. In some examples, the first client device 105 may be configured to generate or otherwise receive a security credential, which in some cases may identify a user (e.g., a first user) of the first client device 105. In some examples, the first client device 105 may be configured to display one or more graphical user interfaces (e.g., a requested data interface, a blocked traffic interface, and / or other interfaces).

[0035] The second client device 106 may include one or more devices, such as a laptop computer, a desktop computer, a mobile device, a tablet, a smartphone, and / or other personal computing device. For example, the second client device 106 may be a computing device configured to provide an encrypted DNS query request (e.g., to the traffic routing and monitoring platform 102) and receive an encrypted DNS query response in response. Additionally, the second client device 106 may be configured to access an IP address once received as an encrypted DNS query response. In some examples, the second client device 106 may be configured to establish a secure session with the traffic routing and monitoring platform 102 (e.g., during which the DNS query may be sent). In these cases, the second client device 106 may provide a security credential, which may be verified and used to establish the secure session. In some examples, the second client device 106 may be configured to generate or otherwise receive a security credential, which in some cases may identify a user of the second client device 106 (e.g., a second user different from the first user). In some examples, the second client device 106 may be configured to display one or more graphical user interfaces (e.g., a requested data interface, a blocked traffic interface, and / or other interfaces).

[0036] The third client device 107 may include one or more devices, such as a laptop computer, a desktop computer, a mobile device, a tablet, a smartphone, and / or other personal computing device. For example, the third client device 107 may be a computing device configured to provide an encrypted DNS query request (e.g., to the traffic routing and monitoring platform 102) and receive an encrypted DNS query response in response. Additionally, the third client device 107 may be configured to access an IP address once received as an encrypted DNS query response. In some examples, the third client device 107 may be configured to establish a secure session with the traffic routing and monitoring platform 102 (e.g., during which the DNS query may be sent). In these cases, the third client device 107 may provide a security credential, which may be verified and / or used to establish the secure session. In some examples, the third client device 107 may be configured to generate or otherwise receive a security credential, which, in some cases, may identify a user of the third client device 107 (e.g., a third user different from the first or second user). In some examples, the third client device 107 may be configured to display one or more graphical user interfaces (e.g., a requested data interface, a blocked traffic interface, and / or other interfaces).

[0037] The target server 108 may include one or more computing devices (e.g., servers, server blades, and / or other devices) and / or other computer components (e.g., processors, memory, communication interfaces) that may be configured to provide data responsive to client requests. In some examples, the target server 108 may be configured to communicate directly with client devices (e.g., the first client device 105, the second client device 106, the third client device 107, and / or other client devices) or may communicate through a proxy server 103. In some examples, the target server 108 corresponds to a particular domain name (e.g., “domain.com”) and has a corresponding IP address (e.g., 123.123.123.123).

[0038] The gateway server 115 may be and / or may include one or more computing devices (e.g., servers, server blades, and / or other devices) and / or other computer components (e.g., processors, memory, communication interfaces) that may act as an intermediary between client devices (e.g., first client device 105, second client device 106, third client device 107, and / or other client devices) and target server 108. For example, the gateway server 115 may be configured to receive traffic directed to the target server 108 and log both outbound and inbound traffic to the target server 108 accordingly. The gateway server 115 may further be configured to share these traffic logs with the traffic routing and monitoring platform 102.

[0039] The computing environment 100 may also include one or more networks, which may interconnect the traffic routing and monitoring platform 102, the proxy server 103, the first client device 105, the second client device 106, the third client device 107, the target server 108, and the gateway server 115. For example, the computing environment 100 may include a network 101, which may interconnect the traffic routing and monitoring platform 102, the proxy server 103, the first client device 105, the second client device 106, the third client device 107, the target server 108, and / or the gateway server 115.

[0040] In one or more configurations, the traffic routing and monitoring platform 102, the proxy server 103, the first client device 105, the second client device 106, the third client device 107, the target server 108, and / or the gateway server 115 may be any type of computing device capable of sending and receiving requests and processing the requests accordingly. For example, the traffic routing and monitoring platform 102, the proxy server 103, the first client device 105, the second client device 106, the third client device 107, the target server 108, the gateway server 115, and / or other systems included in the computing environment 100 may be and / or include, in some examples, a server computer, a desktop computer, a laptop computer, a tablet computer, a smartphone, and / or one or more processors, memory, communication interfaces, storage devices, and / or other components. As described above and in further detail below, any and / or all of the traffic routing and monitoring platform 102, proxy server 103, first client device 105, second client device 106, third client device 107, target server 108, and / or gateway server 115 may, in some examples, be special-purpose computing devices configured to perform specific functions.

[0041] 1B , the traffic routing and monitoring platform 102 may include one or more processors 111, memory 112, and a communication interface 113. A data bus may interconnect the processor 111, the memory 112, and the communication interface 113. The communication interface 113 may be a network interface configured to support communication between the traffic routing and monitoring platform 102 and one or more networks (e.g., network 101, etc.). The memory 112 may include one or more program modules having instructions that, when executed by the processor 111, cause the traffic routing and monitoring platform 102 to perform one or more functions described herein, and / or one or more databases that store and / or maintain information that may be used by such program modules and / or the processor 111. In some examples, the one or more program modules and / or databases may be maintained by different memory units of the traffic routing and monitoring platform 102 and / or by different computing devices that may form and / or otherwise configure the traffic routing and monitoring platform 102. For example, the memory 112 may host, store, and / or include a traffic routing and monitoring module 112a and / or a traffic routing and monitoring database 112b.

[0042] The traffic routing and monitoring module 112a may instruct and / or have instructions to cause the traffic routing and monitoring platform 102 to generate user-specific rules / policies to be applied to DNS queries and / or other traffic based on user ID, which in some examples may be done by identifying users based on security credentials. The traffic routing and monitoring database 112b may store correlations between user IDs, corresponding traffic routing / monitoring rules, and / or actions corresponding to the traffic routing monitoring rules, which may be used, for example, by the traffic routing and monitoring module 112a and / or the traffic routing and monitoring platform 102 to perform advanced techniques for traffic routing and monitoring, as described in more detail below.

[0043] 1C, in addition to or as an alternative to the configuration illustrated in FIG. 1A, a configuration such as that illustrated in FIG. 1C may be implemented. For example, in addition to or as an alternative to having multiple client devices requesting access to a common target server / domain (e.g., target server 108) as illustrated in FIG. 1A, a single client device (e.g., client device 105) may attempt to access multiple target servers / domains (e.g., target servers 109-111, which correspond to first, second, and third domains, respectively). For example, first, second, and third target servers 109, 110, and 114 may be similar to target server 108, as described above, but may correspond to different domains. In these cases, first client device 105 may communicate with traffic routing and monitoring platform 102 (e.g., via an encrypted DNS session) to identify domain name filtering rules specific to the user of first client device 105 for each of the first, second, and third domains.

[0044] For example, in response to an encrypted DNS query request from a first client device 105 requesting access to a first target server 109, the traffic routing and monitoring platform 102 may use domain name filtering rules to identify that traffic between the first client device 105 and the first target server 109 should be allowed and may allow access accordingly (e.g., by providing an encrypted DNS query response that includes the IP address of the first target server 109). In these examples, the first client device 105 can access the first target server 109 using the IP address accordingly. This is similar to the actions performed in steps 202 through 210, as described further below.

[0045] Additionally, or alternatively, in response to an encrypted DNS query request from the first client device 105 requesting access to the second target server 110, the traffic routing and monitoring platform 102 may use domain name filtering rules to identify that traffic between the first client device 105 and the second target server 110 should be blocked, and may block access accordingly (e.g., by sending an encrypted DNS query response indicating that the second target server 110 is inaccessible, rather than the IP address of the second target server). In these examples, the first client device 105 may not be able to access the second target server 110. This is similar to the actions performed in steps 211 through 218, as described further below.

[0046] Additionally, or alternatively, in response to an encrypted DNS query request from the first client device 105 requesting access to the third target server 114, the traffic routing and monitoring platform 102 may use domain name filtering rules to identify that traffic between the first client device 105 and the third target server 114 should be logged and may log the traffic accordingly (e.g., by sending an encrypted DNS query response that includes the IP address of the proxy server 103 (which, in some examples, may be appended or otherwise attached to the IP address of the third target server 114). In these cases, the traffic between the first client device 105 and the third target server 114 is sent through the proxy server 103, which may monitor and log the traffic accordingly. This is similar to the actions performed in steps 219 through 234, as described further below.

[0047] 2A through 2I illustrate an exemplary sequence of events for traffic routing and monitoring in accordance with one or more exemplary embodiments. Referring to FIG. 2A , in step 201, the traffic routing and monitoring platform 102 may issue security credentials to the first client device 105, the second client device 106, the third client device 107, and / or other client devices (e.g., a first security certificate, a second security certificate, and / or a third security certificate, respectively). Additionally or alternatively, the client devices (e.g., the first client device 105, the second client device 106, and / or the third client device 107) may create the security certificates themselves and / or through interactions with another computing device. In some examples, these security credentials may include the identity, network, organization, geographic location, and other information of the user of the corresponding client device. For example, the security credentials may be fine-grained (or individually) customized to identify the client device. In some examples, the security certificates may be used to establish a secure DNS channel between the client device and the traffic routing and monitoring platform 102. For example, domain name system security extensions (DNSSEC) can use security certificates to sign DNS data to make it tamper-proof. Similarly, security certificates are used to establish encrypted TLS or similar encrypted tunnels through which DNS communications occur between client devices and the traffic routing and monitoring platform 102.

[0048] In some examples, the traffic routing and monitoring platform 102 may issue security credentials at the encryption protocol level, such as the “S” portion of TLS or DNS-over-HTTPS (Hypertext Transfer Protocol Secure). In these examples, user / device identity certificates natively supported by TLS authentication may be issued. In some examples, DNS-over-HTTPS certificates do not suggest using such certificates to determine client identity, only to authorize secure communication tunnels. Thus, in these examples, certificates may not be deployed per user / device. In contrast, certificates such as those described herein may be deployed per user / device to facilitate their use in client identification. For example, being able to distinguish between users and devices may be important if the same user connects from multiple devices (e.g., virtual devices, profiles, applications, other devices, etc.) or different DNS filtering policies need to be applied for each device. Furthermore, some devices may be more trusted than other devices, such as a company-issued laptop, which may be more trusted than the user's personal phone. Furthermore, in some examples, a device may be used by multiple users. Thus, a certificate can be used to specifically identify a user (e.g., a user identity certificate), a device (a device identity certificate), or both a user and a device (e.g., a certificate issued to a user on a specific device).

[0049] In some examples, in addition to or instead of issuing a certificate, the traffic routing and monitoring platform 102 may issue one or more user identifiers, which may be embedded in a uniform resource locator (URL). For example, the traffic routing and monitoring platform 102 may use DNS over HTTPS (DoH) to associate an identifier with a query. In some examples, these user identifiers may be specific to a combination of attributes corresponding to a user (e.g., user, profile, application, operating system, device type, network type, IP address, geographic context, etc.). Doing so may assign multiple different identities to a single user, which may be used to trigger different policies for the single user. For example, a single user may have two separate identifiers (one for each of the two browsers they use), with different policies applied while using each browser.

[0050] In step 202, once the first security credential is issued to the first client device 105, the first client device 105 may transmit the first security credential and a request to establish a secure session to the traffic routing and monitoring platform 102. For example, the first client device 105 may transmit the first security credential and a request to establish a secure session using a wired or wireless connection with the traffic routing and monitoring platform 102.

[0051] In step 203, the traffic routing and monitoring platform 102 verifies the first security credential sent in step 202. If the traffic routing and monitoring platform 102 verifies the first security credential, the traffic routing and monitoring platform 102 establishes a secure session with the first client device 105 (and may then proceed to step 204). Alternatively, if the traffic routing and monitoring platform 102 cannot verify the first security credential, the traffic routing and monitoring platform 102 may not proceed to step 204 and instead wait until a security credential is received from the first client device 105 and verified.

[0052] In some examples, upon verifying the first security certificate and establishing the secure session, the traffic routing and monitoring platform 102 may conduct an encrypted session handshake (e.g., a Transport Layer Security (TLS) or other handshake, etc.) with the first client device 105. In these examples, the traffic routing and monitoring platform 102 and the first client device 105 initiate an encrypted DNS process (which may include validation of the first security certificate in accordance with RFC 7858 and / or RFC 8310), whereby encrypted DNS query requests and encrypted DNS query responses may be exchanged between the traffic routing and monitoring platform 102 and the first client device 105. For example, the first client device 105 informs the traffic routing and monitoring platform 102 of its TLS capabilities (which may be included in the first security certificate, for example), and the traffic routing and monitoring platform 102 responds to confirm TLS parameters that may be used to secure the TLS channel. For example, the traffic routing and monitoring platform 102 may send a message including a certificate identifying the traffic routing and monitoring platform 102 and a digital signature of the traffic routing and monitoring platform 102, which may be verified by the first client device 105 (e.g., by checking a trusted certificate authority list, public key pinning, and / or other methods). Once this encrypted session handshake is complete, the traffic routing and monitoring platform 102 may exchange encrypted messages (e.g., DNS query requests, DNS query responses, and / or other information).

[0053] In step 204, the traffic routing and monitoring platform 102 identifies the user of the first client device 105. For example, based on the first security certificate, the traffic routing and monitoring platform 102 identifies the first user. For example, authentication can be supported using mutual X509 certificate authentication. In such an example, DNS over TLS can be used to enable traffic encryption over User Datagram Protocol (UDP) rather than the HTTP protocol. By managing a public / private key infrastructure, the identity of the first user is securely determined during the exchange process between the first client device 105 and the traffic routing and monitoring platform 102.

[0054] For example, the traffic routing and monitoring platform 102 may identify the first user using mutual X509 certificate authentication using DNS over TLS (e.g., encryption over UDP) protocol. In such an example, the enterprise environment has an internal / local resolver (e.g., DNS using AD). The first user may be provided with instructions for the local / internal resolver to resolve to the traffic routing and monitoring platform 102. In such an example, DNS over TLS may be used if a higher level of security is desired. The user may be provided with a client certificate and instructions for the local resolver to resolve to the traffic routing and monitoring platform 102 using DNS over TLS. In such an example, instructions to block outbound standard DNS and DNS over HTTPS are provided. Once received, the traffic routing and monitoring platform 102 can identify the first user based on the client certificate. Such mutual authentication offers technical advantages over other methods, such as enhanced security.

[0055] Although the identification of the first user is described in step 204 (e.g., before sending the first identity (ID)-embedded DNS query request), in some examples it may be performed based on information received in the first identity-embedded DNS query request, as further described in step 205. Thus, the identification of the first user may occur before or after receiving the first identity-embedded DNS query request without departing from the scope of the disclosure.

[0056] 2B , in step 205, once a secure session is established between the first client device 105 and the traffic routing and monitoring platform 102, the first client device 105 sends a first embedded DNS request (e.g., a fully encrypted DNS request, a partially encrypted DNS request, an unencrypted DNS request, or a request in which a user identity is present in a certificate, embedded in the DNS protocol itself, and / or otherwise embedded) to the traffic routing and monitoring platform 102. For example, the first client device 105 sends the domain name (e.g., domain.com) of the target server 108 and requests the IP address of the target server 108. For example, the first client device 105 can establish a TLS session over which the first identity-embedded DNS query request is made securely. For example, the TLS session may be over Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or other. Additionally or alternatively, the first client device 105 may establish a Hypertext Transfer Protocol (HTTP) session over which the DNS query request is made. For example, the HTTP session may be unencrypted via TCP, UDP, etc., or may be encrypted by a TLS session. In some examples, the first client device 105 (e.g., a network interface of the first client device 105) may be pre-configured to direct DNS queries to the traffic routing and monitoring platform 102. For example, a first security certificate is installed on the first client device 105 prior to sending the first identity-embedded DNS query request. In some examples, when sending the first identity-embedded DNS query request, the first client device 105 has access to the Internet from outside the protected network corresponding to the traffic routing and monitoring platform 102 and / or the proxy server 103.

[0057] In some examples, if the first identity-embedded DNS query request is encrypted, the traffic routing and monitoring platform 102 can use the first security credential to decrypt the first identity-embedded DNS query request. In these examples, if the first security credential has not yet been received by the traffic routing and monitoring platform 102, the traffic routing and monitoring platform 102 may prompt the first client device 105 to provide the first security credential.

[0058] In some examples, in addition to or as an alternative to identifying the first user based on the certificate, as described above in step 205, the traffic routing and monitoring platform 102 can identify and / or further verify the first user's identity (e.g., using DNS over HTTPS), such as the first user's IP, based on information embedded in the first identity-embedded DNS query request itself. In these examples, the first user may configure the first client device 105 to communicate with the traffic routing and monitoring platform 102. For example, the first user may configure DNS settings within Dynamic Host Configuration Protocol (DHCP) router settings by manually setting the traffic routing and monitoring platform 102 as DNS (e.g., DNS over UDP). In these examples, when the first identity-embedded DNS query request is sent, the traffic routing and monitoring platform 102 can identify the first user based on the first user's IP embedded in the first identity-embedded DNS query request.

[0059] Such an approach may have various technical advantages. For example, this may be the simplest form of authentication, since the traffic routing and monitoring platform 102 may only need to identify the source IP of the first-identity-embedded DNS query request. Furthermore, because various load balancers support transparent pass-through of UDP packets, the client IP can be retained in the DNS load balancer service. For example, a DNS request (e.g., a first-identity-embedded DNS query request) may be received at the IP address of a single DNS load balancer, and the DNS load balancer may extract user ID, device identity, location information, and / or other information. In these examples, the DNS load balancer may further pass this information to a DNS server on the backend (e.g., generally, or to a specific server, such as the traffic routing and monitoring platform 102, based on the information), which may be configured to handle a particular customer, client, etc. Doing so may address privacy and regulatory concerns (such as concerns about general data protection regulations or other concerns that a service and / or data associated with that service should always be directed to, processed, and / or stored in a specific DNS server infrastructure).

[0060] In some examples, the DNS load balancer service may be modified to scrape IP addresses from UDP packets, thereby configuring the traffic routing and monitoring platform 102 to provide a technical improvement over traditional DNS systems. More specifically, because many users may map to, for example, a single entity network IP address and / or because IP addresses may change rapidly (e.g., as mobile devices move between cell towers), a client's connecting IP address may not be an ideal method for user identification. Therefore, the methods described herein can identify user, device, location, and / or other information and pass it from a client device (e.g., a first client device 105) to the traffic routing and monitoring platform 102 as part of a DNS request (e.g., a first identity-embedded DNS query request) and / or the tunnel through which the DNS request was made. This DNS load balancer service may support forwarding of client IPs via several different methods, such as a proxy protocol, which preserves the original UDP message headers and may not affect the DNS load balancer service's caching (for example, as described in the DoH RFC 8484 and RFC 6570 standards for Uniform Resource Locator (URI) templates).

[0061] Additionally or alternatively, the traffic routing and monitoring platform 102 may identify the first user using a URI template. For example, authentication in DNS-over-HTTPS is supported using a URI template. Each client can be assigned a unique URI template that can include an access key. In some examples, the access key may be encrypted, unencrypted, or partially encrypted. The encrypted access key may contain sufficient information to identify the user to the traffic routing and monitoring platform 102, resulting in routing to the appropriate name server and the application of appropriate cyber threat intelligence (CTI) based on the needs of the first client. In these examples, the traffic routing and monitoring platform 102 can pass the access key (or a subset of the access key) to the corresponding name server, which can then apply the appropriate CTI for the user. Additionally, or instead of identifying the first user using a unique URI template that includes at least an access key associated with the first user, the traffic routing and monitoring platform 102 can identify the first user using one or more of an access key embedded in a standard DNS request (e.g., embedded in an EDNS field or otherwise), a certificate assigned to the first client's and / or other user's device, an IP address that may (but is not necessarily) uniquely associated with the first user and / or other users, and / or an access key embedded in a wrapper protocol forwarding the first identity-embedded DNS query request.

[0062] In some examples, a first user may manually configure a first client device 105 to point to the traffic routing and monitoring platform 102. To do this, the first user may change their browser settings using a DNS-over-HTTPS (DoH) URI template that includes a user-specific access key embedded in the path. In these examples, the first user may perform an initial authentication to obtain the aforementioned access key. If the access key is provided to the traffic routing and monitoring platform 102, the traffic routing and monitoring platform 102 can identify the first user based on the access key.

[0063] In examples where the first user is an entity user, the entity environment may include an internal / local resolver (such as a DNS that includes a directory service (e.g., Microsoft Active Directory)). In these examples, the first user may be provided with instructions to point the local resolver to the traffic routing and monitoring platform 102. In some examples, these instructions may be manually downloaded by the first user, assigned to the first user (and / or corresponding user device or application) via a certificate, automatically deployed at the operating system level, pre-configured on the first client device 105 (e.g., based on installation of an entity security profile on the first client device 105), and / or otherwise, for example, causing the first client device 105 to direct DNS requests to the IP address of the traffic routing and monitoring platform 102. For example, the first user may be provided with configuration data or an application that provides functionality for authenticating the first user to the traffic routing and monitoring platform 102, thereby enabling the download of a certificate that includes instructions from the traffic routing and monitoring platform 102. Once downloaded, the first client device 105 can automatically present the certificate when prompted using a browser and / or other application. In some examples, different certificates are provided for use with different browsers. For example, different policies may apply to the same user (e.g., work profile and personal profile) and / or different users (e.g., parent and child) on the same device. In some examples, the certificates also include password protection, so that the first user is prompted to provide the corresponding password and / or other access key along with presenting the certificate.

[0064] Similar to the home / individual use case described above, a DoH URI template is provided to the traffic routing and monitoring platform 102 through this configuration, and the traffic routing and monitoring platform 102 can identify the first user based on the embedded access key. In some examples, when DoH is implemented, the traffic routing and monitoring platform 102 may be instructed to block outbound standard DNS and / or DoT queries.

[0065] For user identification based on information in a first identity-embedded DNS query request, user and / or device identity information is embedded in the first identity-embedded DNS query request at the DNS query level (including DNS protocol and DNS-over-HTTP, before being encrypted into DNS-over-HTTPS) and / or at the encryption protocol level (where the DNS protocol or DNS-over-HTTP is encapsulated before being encrypted into DNS-over-HTTPS). At the DNS protocol level, RFC6891 Extension Mechanisms for DNS (EDNS(0)) can be used to attach custom payloads (i.e., user / device identity information) to the DNS query itself, allowing transparent leverage from lower OSI layers to higher protocol levels, up / down the DNS server hierarchy, up / down the hierarchy of the traffic routing and monitoring platform 102, and / or elsewhere. For example, a vanilla / unconfigured client may query a local resolver via an unencrypted DNS protocol, and the local resolver may embed the client's identity in the query's EDNS, wrap it in TLS, and forward that identity information as part of the DNS query over DoT. For example, a client certificate may be issued to a device (e.g., a first client device 105), and that certificate may remain on the device regardless of the user using / authenticating on that device. The user ID may be embedded in an access key embedded in a URL template, which may be identical across multiple devices used by the user. The combination of the user ID from the URL template and the device identity from the certificate then allows for unique identification that the user is on a particular device, thereby enabling enforcement of a first policy for the first device (e.g., a mobile-oriented CTI policy on the phone), a second policy for the second device (e.g., a CTI policy specific to the computing device's operating system), and so on.In these examples, the remote resolver (e.g., the traffic routing and monitoring platform 102) may extract identity information from EDNS (as described further below) and apply appropriate filtering policies. Additionally or alternatively, a configured DNS-over-HTTPS client (e.g., the first client device 105) may communicate its device identity to the traffic routing and monitoring platform 102 using a client certificate and simultaneously communicate its identity to the traffic routing and monitoring platform 102 using a URL template with embedded user ID information. This allows the traffic routing and monitoring platform 102 to apply different policies to the same user logging in from different devices (e.g., a mobile device, a desktop device, multiple users on a shared workstation, etc.) and / or to apply different policies to authenticated devices that do not have an authenticated user (e.g., not logged in) versus authenticated devices with an authenticated user versus unauthenticated devices with an authenticated user. This flexibility allows support for a variety of client capabilities, such as older clients that only support the native DNS protocol and newer clients that support DoT but not DoH. In doing so, such clients can translocate identity information into queries that are passed across the Internet to the traffic routing and monitoring platform 102 in the most secure and private manner possible.

[0066] In some examples, the first client device 105 transmits the user identifier described above in step 201 along with the first identity-embedded DNS query request using DoH, which in some examples may indicate multiple attributes of the user ID (e.g., profile, application, operating system, device, network, cluster, wide area network (WAN) IP, and / or other identifiers). In some examples, these attributes of the user ID transmitted from the first client device 105 may correspond to the profile (e.g., the first identity). For example, the user identifier may be included in a URL (e.g., an HTTP header, etc.) corresponding to the first identity-embedded DNS query request. For example, the user identifier may be a URL prefix assigned to a user upon the user's registration with the traffic routing and monitoring platform 102. In some examples, this user identifier may be a fixed value, e.g., assigned and stored to the user. In some examples, the user identifier may be dynamically adjusted using, for example, an application stored on the first client device 105 (e.g., an application to which the user has previously authenticated). In some examples, the user identifier may be generated / assigned simultaneously with the first security credential or at a later time. In some examples, this user identifier may be transmitted along with the first security credential described above in steps 201 through 203 (which may allow additional identity information to be transmitted, for example, compared to transmitting the first security credential itself). In some examples, the user identifier is transmitted in addition to or instead of the first security credential.

[0067] In some examples, the first identity-embedded DNS query request is routed to the traffic routing and monitoring platform 102 via one or more other devices (e.g., a local DNS resolver, etc.). In some examples, a second identity (e.g., an identity corresponding to an intermediate device) may be attached to the first identity-embedded DNS query request. For example, the intermediate device is associated with an entity, and thus the entity's identity is attached to the first identity-embedded DNS query request. Thus, one or more identities may be attached to the first identity-embedded DNS query request along its path between the first client device 105 and the traffic routing and monitoring platform 102.

[0068] As a particular example, the first identity (ID) may indicate a particular user ID and the browser the user is operating, and the second identity (ID) may identify a business entity. While first and second identities are described, in some examples, a single identity, or any number of identities, may be included in the first identity-embedded DNS query request without departing from the disclosure. Further examples of these user IDs are described below in connection with FIG. 4.

[0069] In some examples, if the first client device 105 is not configured for DoT or DoH communication, the first client device 105 can embed these identities in the first identity-embedded DNS query request using cleartext. For example, the first client device 105 may be customized and / or otherwise configured to perform such embedding. In some examples, the cleartext identity information is embedded in an unencrypted DNS request (e.g., in a field of the DNS request protocol, etc.). Alternatively, the identity information can be encrypted (in whole or in part) and embedded in the unencrypted DNS request. For example, the identity information is run through an encryption protocol before being embedded in the DNS request. In some examples, the first client device 105 may communicate with a local resolver (e.g., which may be similar to the traffic routing and monitoring platform 102) and transmit the unencrypted identity information (in whole or in part) as part of the communication. The local resolver then takes the received unencrypted identity information and, in some examples, may add additional identity information (e.g., for the first client device 105, the local resolver, and / or others) and encrypt all of the identity information. Any requests from the local resolver to other resolvers (which may be similarly configured, for example, as the traffic routing and monitoring platform 102) may then be sent using clear text with the identity encrypted.

[0070] In these examples, once a DNS request is captured, encryption ensures that identity information remains protected (e.g., against changes to identity information, user identification based on identity information, etc.). Furthermore, because the path of a DNS request may not be controlled as it travels upstream, outside of an entity's infrastructure, etc., scenarios may arise in which certain protocols (e.g., DoT communications, DoH communications) are not supported or permitted. For example, security upgrades or downgrades may occur within an enterprise. For example, an enterprise may use encrypted DNS internally, but the same protocol (e.g., encryption) may not be supported upstream once the DNS request passes through an internal resolver. Thus, the way identity information is conveyed may change throughout the path of a DNS request (e.g., by changing the encryption level associated with the domain of the DNS request). Additionally, or alternatively, the protocol itself may change (e.g., from DNS over UDP to DoT, to DoH, and back to UDP). Nevertheless, by including identity information in a field of a DNS request, such information may be conveyed regardless of protocol upgrades / downgrades along the path of the DNS request.

[0071] Additionally, it may be advantageous to utilize standard fields in the DNS request protocol to encrypt and convey the identity information, which further enables embedding of the identity information on the client side (e.g., the first client device 105) for communication to the server side (e.g., the traffic routing and monitoring platform 102), thus allowing the identity to be embedded and transmitted from the originator of the DNS request.

[0072] Additionally or alternatively, the local resolver may be configured to protect any identity information received in a DNS request from leaking the identity information and / or other privacy information before forwarding the DNS request (e.g., in instances where the DNS request is sent publicly). This may be particularly advantageous in instances where a client (e.g., the first client device 105) fails to encrypt the identity information.

[0073] In some examples, the traffic routing and monitoring platform 102 can modify the first identity-embedded DNS query request as it is received. For example, in some examples, a malicious user may send a non-compliant DNS query request (e.g., using non-compliant or disallowed characters). However, in such examples, such non-compliant DNS query requests may not normally be filtered out. Therefore, it may be advantageous to transform or modify such DNS query requests upon receipt. For example, the traffic routing and monitoring platform 102 may extract the domain name and re-encode the domain name into subsequent DNS query requests. This process may enable payload transformation, which, for example, may be exploited by a malicious actor to subvert filtering by the traffic routing and monitoring platform 102.

[0074] To avoid such abuse, the traffic routing and monitoring platform 102 may modify the DNS query request, normalizing (e.g., Punycode, etc.), standardizing, and / or transforming the DNS query request to facilitate CTI matching and enforce intelligence that might otherwise be avoided without such transformation (e.g., before routing the DNS query request upstream). Furthermore, such techniques enable transforming non-compliant DNS query requests into compliant DNS query requests and applying intelligence accordingly. Based on such intelligence, the traffic routing and monitoring platform 102 may identify further actions to be taken with respect to the DNS query request, such as redirecting the request, allowing the request to proceed, etc.

[0075] In step 206, the traffic routing and monitoring platform 102 can identify a first traffic routing rule based on the identity of the first user. For example, the traffic routing and monitoring platform 102 maintains a database of traffic routing rules corresponding to each of a plurality of users and identifies the first traffic routing rule corresponding to the first user (e.g., by indexing the database). In some examples, in identifying the first traffic routing rule, the traffic routing and monitoring platform 102 identifies domain match criteria and corresponding actions to be performed for each of a plurality of domain names (including the domain name sent in the first identity-embedded DNS query request), both of which may be specific to the first user. For example, the first traffic routing rule may be specific to the first user's organization, the first user's subscription level (e.g., which may provide a unique security level and / or be selected or registered by the first user), geographic location, and / or other user characteristics. The first traffic routing rule may also be common across all network users (including the first user). In some examples, the subscription level of the first user indicates whether a unique policy specific to the first user or a generic policy should be applied. In some examples, when specifying domain match criteria for the first traffic routing rule, the traffic routing and monitoring platform 102 may identify a whitelist, blacklist, and / or watchlist specific to the first user. In these examples, each of a plurality of domain names may be included in one of the whitelist, blacklist, and watchlist. In some examples, the first traffic routing rule is associated with a protected network (e.g., an enterprise network or other secure network).

[0076] In some examples, multiple sets of traffic filtering rules may be applied to the first user. For example, if a user identifier (such as a URL prefix) is embedded in the first identity-embedded DNS query request to indicate additional attributes of the first user, different sets of traffic filtering rules may be applied based on the user identifier. For example, the traffic filtering rules may be different when the first user uses a first browser than when the first user uses a second browser. Thus, in identifying the first traffic filtering rule, the traffic routing and monitoring platform 102 may not only identify a set of rules corresponding to the first user, but also identify a set of rules corresponding to the specific identity of the first user conveyed by the identifier in the first identity-embedded DNS query request (e.g., via DoH).

[0077] In these examples, the traffic routing and monitoring platform 102 may identify one or more policies based on one or more identities conveyed in the first identity-embedded DNS query request. For example, as described above, in some examples, multiple identities (e.g., user ID, device ID, browser ID, application ID, operating system ID, ID of other software supporting DNS requests, enterprise ID, etc.) apply to the first identity-embedded DNS query request along the path between the first client device 105 and the traffic routing and monitoring platform 102 (and / or included within the first certificate). In some examples, the traffic routing and monitoring platform 102 may maintain a stored table (or other correlation) of identity / policy pairs (which in some examples may be key / value pairs, a database, and / or other relationships reflecting the correlation between identities and corresponding policies), where identities are represented as keys and corresponding policies are represented as values. Thus, the traffic routing and monitoring platform 102 may perform a lookup of one or more received identities to identify one or more corresponding policies (e.g., a first policy for the first identity and a second policy for the second identity, etc.).

[0078] In some examples, this stored table can be maintained and / or managed by an intelligence policy manager system to dynamically distribute identity / policy pairs for caching by various traffic routing and monitoring platforms. For example, when a first identity-embedded DNS query request is received by the traffic routing and monitoring platform 102, if the DNS request includes an identity and / or certificate for which there is no policy stored in the table / index (e.g., based on key / value pairs and / or other identity / policy pairs that define a correspondence between the identity and the corresponding policy), the traffic routing and monitoring platform 102 can query the intelligence policy manager system to obtain this information. For example, this table / index can be stored and / or maintained at a local traffic routing and monitoring platform (e.g., first traffic routing and monitoring platform 503, second traffic routing and monitoring platform 505, etc.), and can petition an intelligence policy manager system (e.g., intelligence policy manager system 504) to obtain the identity information and corresponding storage policy (e.g., as described below with respect to FIG. 5). For example, the intelligence policy manager system 504 can distribute corresponding policy information to one or more traffic routing and monitoring platforms and may cache the policy information in a corresponding identity / policy pair table.

[0079] This is illustrated, for example, in Figure 5. For example, a client device 502 (which may be similar to, for example, the first client device 105, the second client device 106, and / or the third client device 107) sends a DNS request to a first traffic routing and monitoring platform 503 (which may be similar to, for example, the traffic routing and monitoring platform 102). The first traffic routing and monitoring platform 503 may identify (e.g., via a local lookup) whether the identity included in the DNS request is represented by an identity / policy pair in a policy index (e.g., maintained and / or stored at the first traffic routing and monitoring platform 503). If all identities are included in the policy index, the sequence of events may proceed as described below with respect to Figure 2B. If any identities are not included in the policy index, the first traffic routing and monitoring platform 503 queries the intelligence policy manager system 504 to obtain the corresponding identity / policy pair (e.g., the policy for the corresponding identity). Once received, the first traffic routing and monitoring platform 503 caches this information in a policy index for future use and applies the policy (or, in some examples, performs policy adjustment as described further below). Based on this policy, the first traffic routing and monitoring platform 503 can return a DNS response to the client device 502, as described further below with respect to an exemplary sequence of events.

[0080] Meanwhile, the intelligence policy manager system 504 can identify other traffic routing and monitoring platforms (e.g., second traffic routing and monitoring platform 505) to which policy information should be preemptively sent. For example, based on the IP address of the client device 502, for example, sent to the intelligence policy manager system 504 along with a query from the first traffic routing and monitoring platform 503, the intelligence policy manager system 504 identifies other traffic routing and monitoring platforms (e.g., second traffic routing and monitoring platform 505) within a geographic boundary corresponding to the location of the client device 502.

[0081] For example, query responses may be routed through servers based on the identified location. As a specific example, if a query request is received through a server in a first geographic location (e.g., a U.S.-based server), but the location of the client device 502 indicates that it is in a second geographic location (e.g., a different country, etc.), the server (e.g., a traffic routing and monitoring platform) may be configured to route a response to this query request, or redirect future query requests, through one or more servers based on the identified location (e.g., the second geographic location) of the client device 502 to provide a response that is best suited to the user's location or that is required by policy. For example, a user compliant with the General Data Protection Regulation (GDPR) may have all queries and responses routed through servers based within a geographic boundary (e.g., a country, a continent), regardless of the user's current location, outside the geographic boundary (e.g., a different country, a continent), etc. In some examples, the rerouting and / or redirection of queries and responses is based on the latency of available servers and / or other performance metrics.

[0082] Once an appropriate server (e.g., a traffic routing and monitoring platform) is identified, the intelligence policy manager system 504 can preemptively push the policy information to the second traffic routing and monitoring platform 505 and cache the policy information in a corresponding policy index (e.g., the second traffic routing and monitoring platform 505). As a result, when the client device 502 sends a DNS request to the second traffic routing and monitoring platform 505, the second traffic routing and monitoring platform 505 may already have stored a key-value pair corresponding to the client device's 502 identity and the corresponding policy. This allows the second traffic routing and monitoring platform 505 to provide a DNS response based on the corresponding policy without querying the intelligence policy manager system 504. Furthermore, operating in this manner can conserve network bandwidth and computing resources by configuring policies only on servers where the policies are needed or implemented. At the same time, this method can reduce delays associated with request processing by preemptively continuing to provide policy information to corresponding servers.

[0083] Additionally, or instead of preemptively pushing policy information to various traffic routing and monitoring platforms (e.g., first traffic routing and monitoring platform 503, second traffic routing and monitoring platform 505, etc.) based on a geographic location associated with client device 502 as described above, policy information may be preemptively pushed based on the policy itself. For example, if a GDPR-compliant target user resides in a first geographic region (e.g., a first country), the target user may require that all DNS requests be processed strictly through traffic routing and monitoring platforms located in that first geographic region. In such an example, a path is provided in which DNS query requests are routed through that first geographic region, regardless of the user's geographic location. Similarly, a particular geographic region may be specified through which DNS requests should not be routed. In such an example, a path is provided for DNS query requests that avoid that particular geographic region. Thus, in these examples, the preemptive pushing of policy information may be policy-driven in addition to or instead of being geographically driven.

[0084] In some examples, the intelligence policy manager system 504 can push and pre-populate policy information based on receiving a request (e.g., from one of the traffic routing and monitoring platforms) (which may include, for example, authentication credentials, etc.) In any of these examples, authorized servers (e.g., traffic routing and monitoring platforms identified as candidates for preemptively receiving policy information) are preemptively populated with policy information from the intelligence policy manager system 504 accordingly.

[0085] In some examples, the client device 502 may send a DNS query request to an authorized server (e.g., the first traffic routing and monitoring platform 503), but a policy definition or requirement directs the client device 502 to direct subsequent requests to another server (e.g., the second traffic routing and monitoring platform 503) or one of a group of servers for a particular reason (e.g., GDPR, current processing load, latency, etc.). In these examples, a response (e.g., a reconfiguration response) to the DNS query request from the traffic routing and monitoring platform 503 may indicate that the DNS query request and / or future DNS query requests should be directed to the second traffic routing and monitoring platform 503. In these examples, the intelligence policy manager system 504 may preemptively push policy information to the second traffic routing and monitoring platform 503 (and / or other traffic routing and monitoring platforms) accordingly.

[0086] Additionally or alternatively, the intelligence policy manager system 504 may preemptively push policy information based on receiving a large number of updates (e.g., exceeding a threshold number of updates) to a given traffic routing and monitoring platform 503 when new cyber threat intelligence is received and / or otherwise.

[0087] There are several drivers for preemptively pushing policy information using one or more of the above methods: First, the amount / size of policy information can be substantial, and therefore, preemptively pushing policy information can reduce or eliminate delays associated with waiting for such policy information.

[0088] Second, because policy information may be constantly changing, it may be important to proactively update the policy information in the traffic routing and monitoring platform whenever these changes are detected or received by the intelligence policy manager system 504 (e.g., every 5 minutes, every hour, etc., which may be based on, for example, the TTL of the policy information, DNS records, etc.).

[0089] For example, by preemptively updating policy information and / or DNS records in the traffic routing and monitoring platform, the intelligence policy manager system 504 can perform indicator eviction (e.g., eviction of information already cached in the traffic routing and monitoring platform) by replacing the TTL of the corresponding policy information and / or DNS record (e.g., replacing the current TTL with the smallest possible TTL to speed up the eviction process and / or delete the corresponding DNS record and / or policy information). In some examples, the TTL is measured in time units (e.g., seconds, minutes, hours, etc.), hop counts, and / or other units. In some examples, a TTL detected to exceed a certain threshold may be capped at the threshold (e.g., reduced to a maximum value corresponding to the threshold). This can enable replacement of information / records already cached in the traffic routing and monitoring platform and prevent use of such information / records by downstream clients (e.g., the first client device 105).

[0090] In some examples, the client device 502 may include an agent configured to store in a local cache a direction to evict already accessed records. For example, the agent may be configured to communicate with the traffic routing and monitoring platform and / or intelligence policy manager system 504 to communicate which records have been accessed, and a direction to evict the records may be provided accordingly based on this communication. In other examples, the first client device 105 may not be configured with an agent. In these examples, the traffic routing and monitoring platform and / or intelligence policy manager system 504 may track requested DNS records. The traffic routing and monitoring platform and / or intelligence policy manager system 504 may further track known-good DNS records and allow such records to pass their TTLs. Similarly, the traffic routing and monitoring platform and / or intelligence policy manager system 504 may implement shortened TTLs for records for which cyber threat intelligence is unknown or unreliable (e.g., by transparently overwriting the existing TTLs of these records). In doing so, the traffic routing and monitoring platform and / or intelligence policy manager system 504 may update its cache (or one or more records therein) based on the changed TTL expiration date.

[0091] In some examples, the traffic routing and monitoring platform and / or intelligence policy manager system 504 may generate a threat score and may accordingly adjust the TTL based on the threat score. For example, a higher threat score may result in a shorter TTL and a lower threat score may result in a longer TTL. For example, the threat score may correspond to a percentage, and the TTL may decrease according to the percentage (e.g., a threat score of .6 results in a 60% decrease, etc.). In some examples, the TTL may be dynamically changed over time as additional intelligence is received.

[0092] This provides a technical solution to the problems posed by the use of DNS records in cybersecurity. For example, because DNS records are cached locally, client devices will continue to access bad records (even after they have been identified or flagged) for the full duration of their corresponding TTL. Therefore, reducing the TTL can minimize the impact of bad or untrustworthy records, as they may be removed from local caches upon the expiration of the shortened TTL. Similarly, for known or trusted records, the TTL can be extended.

[0093] Similarly, a decision to shorten the TTL may be used to record information related to visits to a particular website. For example, by shortening the TTL associated with a website, the traffic routing and monitoring platform and / or intelligence policy manager system 504 may cause the client device 502 to send DNS requests at more frequent intervals, e.g., to more closely represent the number of times the website is accessed.

[0094] Additionally, a third impetus for preemptively pushing policy information using one or more of the above methods addresses issues related to pushing policies to an ID-based cache. For example, policies common to multiple identities are preemptively pushed. In some examples, a local ID-based cache is implemented to store policies for a particular user. However, as the number of users (each with a corresponding policy) increases, problems can arise. For example, each user's policy must be pushed to the local cache regardless of whether these policies contain the same (or substantially similar) information, which may involve the transmission and / or local storage of duplicate or overlapping policy information. Thus, commonalities among policies and / or identities that may be deployed to a particular traffic routing and monitoring platform are identified. For example, if a particular policy is common to all identities accessing a particular traffic routing and monitoring platform, this policy is pushed (e.g., by the intelligence policy manager system 504) only once (e.g., not once for each identity), and the group cache is populated accordingly. In these examples, the group cache corresponds to one or more identities with common policies and / or one or more identities associated with a common subset of different policies. By identifying these commonalities and building a group cache accordingly, the amount of policy information pushed to traffic routing and monitoring platforms is significantly reduced, saving network bandwidth and processing resources. For example, policies sent can be evaluated for efficient delivery and duplicate information may not be sent.

[0095] In some examples, it may be advantageous for policies to be cached as close to the user as possible (e.g., at the nearest traffic routing and monitoring platform), so that as policies are pushed down to a given traffic routing and monitoring platform, the intelligence policy manager system 504 can accordingly understand commonalities among identities associated with that traffic routing and monitoring platform and therefore create group cached / common policies as described above. For example, a corporate policy that applies to many employees of a company may include policies that apply to all employees (or most employees), and smaller individual policies (containing the remaining policies for various employees) may be sent accordingly. In doing so, policies may be sent in different ways that minimize the amount of policies, duplicate information, and / or generally applicable information sent.

[0096] Further, in some examples, the group cache may be dynamically adjusted to add and / or remove policies from a common policy associated with the group cache based on the application of the policy to the identity corresponding to the group cache. Returning to step 206 of FIG. 2B , in examples where multiple policies are identified, the traffic routing and monitoring platform 102 may perform a reconciliation process to apply the appropriate policy (e.g., block the traffic, allow the traffic, log the traffic, etc.) to any given packet or request. For example, the traffic routing and monitoring platform 102 may identify whether the policies conflict (e.g., one policy indicates that traffic should be blocked for the requested IP address, while the other policy indicates that traffic should be allowed). In such an example of a complete conflict, the traffic routing and monitoring platform 102 may select a dominant policy to apply (e.g., based on pre-configured settings, user input, etc.) and apply the corresponding policy. For example, the traffic routing and monitoring platform 102 may be configured to apply a corporate policy over an individual user policy in an example of a conflict (e.g., select a second policy over a first policy).

[0097] In other examples, the traffic routing and monitoring platform 102 may identify a partial conflict (e.g., two or more policies agree in some respects and conflict in other respects). In these examples, the traffic routing and monitoring platform 102 may apply the non-conflicting portions of the policies and reconcile any conflicting portions as described above (e.g., identify that the non-conflicting portions of a first policy should be applied in addition to a second policy). For example, in some examples, a policy includes an action indicating an action, such as block or allow. Additionally, in some examples, a policy includes a directive, such as log, monitor, capture one or more packets, alert, redirect, and / or other secondary or additional action. Thus, in some examples, a partial conflict is identified when two policies indicate a common action but the directives conflict. In these examples, the traffic routing and monitoring platform 102 may resolve the conflict by performing a combination of the actions defined in the conflicting actions in addition to performing the common action. Additionally or alternatively, one or more primary directives may be selected and executed in order to resolve the conflict.

[0098] In some instances where a conflict is identified (e.g., a partial conflict or a complete conflict), instead of selecting one of the conflicting policies as the overall dominant policy, the traffic routing and monitoring platform 102 may select one or more dominant rules of multiple different conflicting policies. For example, the traffic routing and monitoring platform 102 may generate and / or otherwise associate a priority score with the rule associated with each conflicting policy and may select a rule from one or more policies by selecting, from a pair of conflicting rules, the rule that has a higher priority score than the remaining rule. For example, if the first rule of a first policy has a higher priority score than the first rule of a second policy, but the second rule of the second policy has a higher priority score than the second rule of the first policy, the traffic routing and monitoring platform 102 may select the first rule of the first policy and the second rule of the second policy.

[0099] As another example, conflicts may be resolved based on specificity. For example, a first policy may block "*.domain.com" while another policy may allow "www.domain.com." Depending on the conflict resolution criteria, traffic to "www.domain.com" may be allowed but traffic to "meet.domain.com" and other traffic may not. Similarly, the reverse may also occur, depending on the priority of each scenario. Additionally or alternatively, conflict resolution may be performed based on block versus allow. For example, a block may take precedence over any allow. In this example, traffic to "www.domain.com" may be blocked by a rule for "*domain.com," but the rule indicates that traffic to "www.domain.com" should be allowed. In some examples, these examples may illustrate the application of rule priority. In some examples, such priority is assigned through human-applied judgment and / or determined by a rule analysis agent.

[0100] In other examples, the traffic routing and monitoring platform 102 may identify that the policies do not conflict (or are consistent) and apply each policy as a whole (e.g., apply both the first and second policies), thereby creating an overall or comprehensive policy, which may be, for example, a selection of an identity-based policy, the sum of multiple identity-based policies, or a partial combination of multiple identity-based policies.

[0101] This policy resolution and / or policy conflict resolution can address privacy concerns related to personal devices. For example, if a user is using a company-issued laptop, it is unlikely that several different policies apply. Rather, the laptop is simply governed by corporate policy. However, when using a personal device (or if personal browsing is allowed on a corporate device), individuals may seek privacy on their devices, and in some instances, do so by circumventing corporate security. By applying an identity-driven solution such as that described herein, multiple profiles, personal devices, multi-use devices, and / or other devices can be supported to provide user privacy while maintaining security.

[0102] In some examples, the traffic routing and monitoring platform 102 may further select this blanket policy based on non-identity-based attributes (e.g., attributes not specifically associated with a given user ID), which may include, for example, GDPR attributes where different blanket policies are selected for the same identity based on the value of the GDPR attribute (e.g., whether a user is located in a first country versus a second country).

[0103] In these examples, the identified / selected policy may correspond to a set of traffic routing rules (e.g., a first traffic routing rule as described in step 207 below). This policy selection is further explained with respect to FIG. 4, described below.

[0104] In step 207, the traffic routing and monitoring platform 102 can determine an action to perform with respect to the first identity-embedded DNS query request based on the first traffic routing rule. For example, the traffic routing and monitoring platform 102 can identify whether to allow, block, and / or monitor traffic directed to the IP address (which may correspond to the target server 108, for example) requested by the first identity-embedded DNS query request based on the first traffic routing rule. For example, the traffic routing and monitoring platform 102 can identify that IP addresses corresponding to blacklisted domains should be blocked, that access to IP addresses corresponding to whitelisted domains should be allowed, and that traffic to and from IP addresses corresponding to watchlisted domains should be monitored / logged. For illustrative purposes, in step 207, the traffic routing and monitoring platform 102 can determine that traffic should be allowed to access the IP address requested by the first identity-embedded DNS query request based on the first traffic routing rule.

[0105] In some examples, in addition to or as an alternative to applying these policies / traffic routing rules to route traffic based on the first identity-embedded DNS query request, the traffic routing and monitoring platform 102 may also segment reports based on privacy settings corresponding to the identity (which may be stored and / or identified using methods similar to those described above with respect to the policies and / or may be included in the policies). For example, the traffic routing and monitoring platform 102 may not collect and / or report a first type of information (e.g., account information, password information, etc.), but may report other information.

[0106] In step 208, based on identifying the domain name of the first identity-embedded DNS query request as a domain name for which traffic should be allowed, the traffic routing and monitoring platform 102 can identify the requested IP address (e.g., the IP address of the target server 108).

[0107] In some examples, upon identifying the requested IP address, the traffic routing and monitoring platform 102 may use DNS caching to improve response time. For example, a DNS server may spend a significant amount of time connecting to other servers to search for the appropriate answer to a query. Once the DNS server has the answer, it can respond to the query. By storing the answer to the query, the DNS server can provide a much faster response to subsequent users requesting the same information. This storage and use of saved DNS responses is sometimes referred to as DNS caching. In particular, most DNS servers are built to support multiple users, all serving identical information from a single global cache.

[0108] With respect to the systems and methods described herein, when a client (e.g., first client device 105) queries the traffic routing and monitoring platform 102, several different responses may be generated by the traffic routing and monitoring platform 102 and / or received by the first client device 105 based on policies created for that particular client. For example, the correct response to a client's DNS query will vary depending on the services and / or policies specific to that client.

[0109] For example, an advertising company may want its employees to be able to access a particular social media website (e.g., Website #1). Therefore, the company's DNS policy may indicate that access to the correct IP address for Website #1 should be allowed. To speed up subsequent queries to Website #1, the traffic routing and monitoring platform 102 may cache the answer to the "allow" response. In contrast, a high school's DNS policy may indicate that Website #1 should be blocked. However, the traffic routing and monitoring platform 102 may see the cached "allow" response and provide the correct IP address for Website #1, in violation of the high school's DNS policy. Similarly, the reverse situation may occur, where both the company and the high school are blocked from accessing Website #1. Thus, while caching can significantly speed up query processing by the traffic routing and monitoring platform 102, it can also be a source of erroneous responses to certain clients.

[0110] To address this deficiency, policies can be applied by the traffic routing and monitoring platform 102, followed by a DNS lookup for each client query. However, this can introduce latency and delays, negatively impacting the user experience. Therefore, per-client caching is proposed herein. This may involve segmenting the traffic routing and monitoring platform 102 cache to limit users of a particular client (e.g., the business or high school mentioned above) to cached responses for that client. This can be achieved by incorporating a client identifier into the caching mechanism, allowing the traffic routing and monitoring platform 102 to quickly provide validated DNS query responses across its entire user base. In these examples, identity-aware caching can be used to provide the correct response associated with the identity and corresponding policy. Thus, referring to the example above, the correct policy is applied for both the advertising company (e.g., allow) and the high school (e.g., block) with respect to access to website #1. Additionally or alternatively, identity-aware caching may be based on other attributes (e.g., location, device, business, user, and / or other attributes) without departing from the scope of the disclosure. For example, cached information (e.g., policies, DNS responses, etc.) may be proactively pushed to a server (e.g., a traffic routing and monitoring platform) to which a user is redirected. More specifically, if a user is accessing a first server (e.g., the traffic routing and monitoring platform 102) in a first location (e.g., country, continent, geographic region, etc.) but is redirected to a second server (e.g., another traffic routing and monitoring platform) based on location, etc., cached policy information may be pushed to this second server accordingly (e.g., the second server preemptively updating its cache based on the first server's cache and / or otherwise).Therefore, identity-aware caching can be leveraged to preemptively push cached information (e.g., policy information, DNS response information), or to remove / overwrite existing cached information. For example, the cache may be preemptively pushed and / or populated, as described above with respect to FIG. 5 and preemptively pushing policies.

[0111] In some examples, if an identified DNS query response includes or is otherwise associated with a CTI, the traffic routing and monitoring platform 102 may not cache the response. For example, caching a response associated with a CTI may result in incorrect results being applied to subsequent queries.

[0112] In some examples, the response may be cached for a particular period of time, which may be determined by the traffic routing and monitoring platform 102 based on intelligence corresponding to the request for a given response.

[0113] In some examples, to generate the first identity-embedded DNS query request, the traffic routing and monitoring platform 102 can send an outbound application programming interface (API) call to a DNS resolver. In some examples, a sidecar API may be used to extract known intelligence about the first user and the requested domain from the first identity-embedded DNS query request and / or to generate an encrypted DNS query response. For example, if information needs to be filtered based on user identity and / or known intelligence, such filtering is performed. For example, the traffic routing and monitoring platform 102 can deploy a sidecar API and integrate a DNS server to query the sidecar API for relevant policies. For example, the DNS server software extracts the domain and / or other information (e.g., identity information) from the query request and runs the domain and / or other information against the API sidecar. The API sidecar can provide information that can be used by the DNS server to modify the query response (e.g., modify the response, do not respond, send domain does not exist, modify the IP address, select one of multiple IP addresses, provide context about the request, redirect the query to another server, and / or action). The DNS server can then interpret this information from the API sidecar, modify the query response accordingly, and provide the response. Use of this sidecar API can, for example, minimize the changes required to the DNS server itself. For example, use of the sidecar API can avoid building policies directly into the DNS server software; however, in some instances, policies are built directly into the DNS server software.

[0114] In some examples, DNS caching may include the use of a penalty box configured to block access to a particular website for a certain amount of time (e.g., a lifetime, etc.). In these examples, the traffic routing and monitoring platform 102 may analyze the DNS query request (e.g., a first identity-embedded DNS query request, etc.) and respond accordingly (e.g., serving the domain and / or blocking the request based on the requested domain and amount of time). In some examples, a local cache (e.g., the first client device 105) may be configured to avoid making further requests to the corresponding domain until a given amount of time has passed.

[0115] In some examples, generating the first identity-embedded DNS query response includes generating multiple domain and / or other records (e.g., domain names, IP forwarding addresses, IPv6 addresses, email addresses, and / or other information). In these examples, the traffic routing and monitoring platform 102 applies threat intelligence to the identified information and filters the information accordingly. For example, if three IP addresses are identified in the response to the DNS query and two correspond to known threats, the two malicious IP addresses are removed from the response and only the remaining IP addresses are returned in the response.

[0116] In some examples, generating the first identity-embedded DNS query response includes validating downstream IP addresses before routing the first identity-embedded DNS query response to corresponding downstream systems. In doing so, the traffic routing and monitoring platform 102 can ensure that these downstream systems are not compromised and / or comply with the overall policy identified in step 206. This is described, for example, with respect to FIGS. 6A through 6D. Referring to FIG. 2C, in step 209, the traffic routing and monitoring platform 102 can forward the first identity-embedded DNS query response (e.g., 123.123.123.123) to the first client device 105. For example, the traffic routing and monitoring platform 102 forwards the IP address identified in step 208 (which may be, for example, the IP address of the target server 108). In some examples, the traffic routing and monitoring platform 102 can forward the first identity-embedded DNS query response to the first client device 105 during the secure session established in step 203.

[0117] In step 210, the first client device 105 may access the IP address received in step 209. For example, the first client device 105 may access data, content, and / or other information from the target server 108.

[0118] In step 211, now referencing the second security certificate issued to the second client device 106, the second client device 106 can send a request to establish a secure session with the second security certificate to the traffic routing and monitoring platform 102. For example, the second client device 106 may send the request to establish a secure session using the second security certificate and a wired or wireless connection with the traffic routing and monitoring platform 102.

[0119] In step 212, the traffic routing and monitoring platform 102 verifies the second security credential sent in step 211. If the traffic routing and monitoring platform 102 verifies the second security credential, the traffic routing and monitoring platform 102 may establish a secure session with the second client device 106 (and may then proceed to step 213). Alternatively, if the traffic routing and monitoring platform 102 cannot verify the second security credential, the traffic routing and monitoring platform 102 may not proceed to step 213 and instead wait until a security credential is received from the second client device 106 and verified.

[0120] In some examples, upon verifying the second security certificate and establishing the secure session, the traffic routing and monitoring platform 102 may perform a Transport Layer Security (TLS) handshake with the second client device 106. In these examples, the traffic routing and monitoring platform 102 and the second client device 106 initiate an encrypted DNS process (which may include verification of the third security certificate in accordance with RFC 7858 and / or RFC 8310), whereby encrypted DNS query requests and encrypted DNS query responses are exchanged between the traffic routing and monitoring platform 102 and the second client device 106. For example, the second client device 106 informs the traffic routing and monitoring platform 102 of its TLS capabilities (which may be included in the second security certificate, for example), and the traffic routing and monitoring platform 102 can respond to confirm the TLS parameters used to secure the TLS channel. For example, the traffic routing and monitoring platform 102 may send a message including a certificate identifying the traffic routing and monitoring platform 102 and a digital signature of the traffic routing and monitoring platform 102, which may be verified by the second client device 106 (e.g., by checking a trusted certificate authority list, public key pinning, and / or other methods). Once this handshake is complete, the traffic routing and monitoring platform 102 may exchange encrypted messages (e.g., DNS query requests, DNS query responses, and / or other information).

[0121] Referring to FIG. 2D , in step 213, the traffic routing and monitoring platform 102 can identify the user of the second client device 106. For example, based on the second security certificate, the traffic routing and monitoring platform 102 identifies the second user. For example, authentication is supported using mutual X509 certificate authentication. In these examples, DNS over TLS can be used to take advantage of traffic encryption using TLS over TCP and / or UDP, which may provide advantages over the HTTP protocol (which may not itself provide encryption). By managing a public / private key infrastructure, the identity of the second user is securely determined during the exchange process between the second client device 106 and the traffic routing and monitoring platform 102.

[0122] For example, the traffic routing and monitoring platform 102 may identify the second user using mutual X509 certificate authentication using DNS over TLS (e.g., encryption over UDP) protocol. In these examples, the enterprise environment has an internal / local resolver (e.g., DNS using a directory service). The second user may be provided with instructions for the local / internal resolver to resolve to the traffic routing and monitoring platform 102. In such examples, DNS over TLS may be used if a higher level of security is desired. The second user may also be provided with a client certificate and instructions for the local resolver to resolve to the traffic routing and monitoring platform 102 using DNS over TLS. In such examples, instructions to block outbound standard DNS and DNS over HTTPS are provided. Once received, the traffic routing and monitoring platform 102 may identify the second user based on the client certificate. Such mutual authentication offers technical advantages over other methods, such as enhanced security.

[0123] Although the identification of the second user is described in step 213 (e.g., before sending the second identity-embedded DNS query request), in some examples it may be performed based on information received in the second identity-embedded DNS query request, as further described in step 214. Thus, the identification of the second user may occur before or after receiving the second identity-embedded DNS query request without departing from the scope of the disclosure.

[0124] In step 214, once a secure session is established between the second client device 106 and the traffic routing and monitoring platform 102, the second client device 106 sends a second identity-embedded DNS query request (e.g., a fully encrypted DNS request, a partially encrypted DNS request, an unencrypted DNS request, a request embedded in the DNS protocol itself if user identity is present in the certificate, and / or embedded otherwise) to the traffic routing and monitoring platform 102. For example, the second client device 106 sends the domain name of the target server 108 and requests the IP address of the target server 108. For example, the second client device 106 may establish a TLS session over which the second identity-embedded DNS query request can be made securely. For example, the TLS session may be over TCP, UDP, and / or others. Additionally or alternatively, the second client device 106 may establish an HTTP session over which the DNS query request can be made. For example, the HTTP session may be unencrypted over TCP, UDP, etc., or may be encrypted by a TLS session. In some examples, the second client device 106 (e.g., a network interface of the second client device 106) may be pre-configured to direct DNS queries to the traffic routing and monitoring platform 102. For example, a second security certificate may be installed on the second client device 106 prior to sending the second identity-embedded DNS query request. In some examples, when sending the second identity-embedded DNS query request, the second client device 106 may be accessing the Internet from outside a protected network. In some examples, if the second identity-embedded DNS query request is encrypted, the traffic routing and monitoring platform 102 may use the second security certificate to decrypt the second identity-embedded DNS query request.For example, different security certificates may be installed for different browsers on the same device, and different security policies may be applied depending on the certificates presented. In these examples, if the second security certificate has not already been received by the traffic routing and monitoring platform 102, the traffic routing and monitoring platform 102 may prompt the second client device 106 to provide the second security certificate.

[0125] In some examples, the actions taken in step 214 may be similar to those described above in step 205 with respect to the first client device 105. For example, in some examples, a user ID (e.g., based on attributes such as profile, application, operating system, device, network, cluster, wireless access point (WAP) IP, and / or other identifiers) may be received along with the second identity-embedded DNS query request (e.g., via DoH), which may be used to distinguish different profiles / IDs of the second user. In some examples, one or more identities may be embedded in the second identity-embedded DNS query request using techniques similar to those described in step 205 with respect to the first identity-embedded DNS query request, and as further illustrated below with respect to FIG. 4.

[0126] In step 215, the traffic routing and monitoring platform 102 can identify a second traffic routing rule based on the identity of the second user. For example, the traffic routing and monitoring platform 102 may maintain a database of traffic routing rules corresponding to each of a plurality of users and identify the second traffic routing rule corresponding to the second user (e.g., by indexing the database). In some examples, in identifying the second traffic routing rule, the traffic routing and monitoring platform 102 identifies domain match criteria and corresponding actions to be performed for each of a plurality of domain names (including the domain name sent in the second identity-embedded DNS query request), both of which may be specific to the second user. For example, the second traffic routing rule may be specific to the second user's organization, the second user's subscription level (e.g., which may provide a unique security level and / or be selected or registered by the second user), geographic location, and / or other user characteristics. In other examples, the second traffic routing rule may be common among all network users (including the second user). In some examples, when specifying the domain match criteria for the second traffic routing rule, the traffic routing and monitoring platform 102 can identify a whitelist, blacklist, and / or watchlist specific to the second user. In these examples, each of the multiple domain names can be included in one of the whitelist, blacklist, and watchlist. In some examples, the second traffic routing rule is associated with a protected network (e.g., an enterprise network or other secure network).

[0127] In some examples, the second traffic routing rule may be selected based on a particular user identity for the second user (e.g., a rule corresponding to the second user's use of the first browser rather than the second browser, etc.). In some examples, this is similar to the policy / first traffic routing rule selection described with respect to step 206 and as further described with respect to FIG. 4. In some examples, the policy may be distributed, cached, and / or controlled by an intelligence policy manager system, as described with respect to step 206 and FIG. 5.

[0128] At step 216, the traffic routing and monitoring platform 102 can identify an action to perform with respect to the second identity-embedded DNS query request based on the second traffic routing rule. For example, the traffic routing and monitoring platform 102 can identify whether to allow, block, and / or monitor traffic directed to the IP address requested by the second identity-embedded DNS query request (which may correspond to the target server 108, for example) based on the second traffic routing rule. For example, the traffic routing and monitoring platform 102 can identify that IP addresses corresponding to blacklisted domains should be blocked, that access to IP addresses corresponding to whitelisted domains should be allowed, and that traffic to and from IP addresses corresponding to watchlisted domains should be monitored / logged. For illustrative purposes, at step 216, the traffic routing and monitoring platform 102 can identify that traffic directed to the IP address requested by the second identity-embedded DNS query request should be blocked (e.g., because a domain name included in the second identity-embedded DNS query request corresponds to a potential security threat for which traffic should be blocked) based on the second traffic routing rule.

[0129] At step 217, the traffic routing and monitoring platform 102 may send a second identity-embedded DNS query response to the second client device 106. In some examples, generating the second identity-embedded DNS query response may include DNS caching, as described above with respect to the first identity-embedded DNS query response at step 208. However, rather than sending the requested IP address via the second identity-embedded DNS query response, based on identifying that the domain name of the second identity-embedded DNS query request corresponds to a potential security threat whose traffic should be blocked, the traffic routing and monitoring platform 102 may send a second identity-embedded DNS query response indicating that the requesting IP address has been blocked and / or that it has blocked the second client device 106 from accessing the requested IP address. For example, the traffic routing and monitoring platform 102 may send a notification that the requested IP address has been blocked, the IP address of a block notification page, and / or other information indicating that the requested IP address has been blocked. In some examples, the traffic routing and monitoring platform 102 may send the second identity-embedded DNS query response to the second client device 106 over a wired or wireless data connection.

[0130] At step 218, the second client device 106 may display (e.g., decode for display) the second identity-embedded DNS query response. For example, the second client device 106 may display a graphical user interface indicating that the requested IP address has been blocked. In some examples, the second client device 106 may receive user feedback indicating that the requested IP address has been flagged as a false positive (e.g., improperly blocked). In these cases, the second client device 106 may send this user feedback to the traffic routing and monitoring platform 102. The traffic routing and monitoring platform 102 may wait until such false positive feedback is received from more than a threshold number of users for the requested IP address. Once such false positive feedback is received from more than a threshold number of users, the traffic routing and monitoring platform 102 may update the second traffic routing rule to indicate that traffic directed to the requested IP address should instead be allowed (thus, future DNS requests for the requested IP address may follow a process similar to that described above with respect to the first identity-embedded DNS query request). In doing so, the traffic routing and monitoring platform 102 may dynamically modify, update, and / or otherwise refine the second traffic routing rule based on the feedback (thereby, for example, continuously improving the performance and effectiveness of the second traffic routing rule).

[0131] In step 219, now referencing the third security certificate issued to the third client device 107, the third client device 107 can send a request to establish a secure session with the third security certificate to the traffic routing and monitoring platform 102. For example, the third client device 107 may send a request to establish a secure session using the third security certificate and a wired or wireless connection with the traffic routing and monitoring platform 102.

[0132] In step 220, the traffic routing and monitoring platform 102 verifies the third security credential sent in step 219. In examples where the traffic routing and monitoring platform 102 verifies the third security credential, the traffic routing and monitoring platform 102 may establish a secure session with the third client device 107 (and may then proceed to step 221). Alternatively, if the traffic routing and monitoring platform 102 cannot verify the third security credential, the traffic routing and monitoring platform 102 may not proceed to step 221 and instead wait until a security credential is received from the third client device 107 and verified.

[0133] In some examples, upon verifying the third security certificate and establishing the secure session, the traffic routing and monitoring platform 102 may perform a Transport Layer Security (TLS) handshake with the third client device 107. In these examples, the traffic routing and monitoring platform 102 and the third client device 107 initiate an encrypted DNS process (which may include verification of the third security certificate in accordance with RFC 7858 and / or RFC 8310), whereby encrypted DNS query requests and encrypted DNS query responses are exchanged between the traffic routing and monitoring platform 102 and the third client device 107. For example, the third client device 107 may inform the traffic routing and monitoring platform 102 of its TLS capabilities (which may be included in the third security certificate, for example), and the traffic routing and monitoring platform 102 may respond to confirm TLS parameters that may be used to secure the TLS channel. For example, the traffic routing and monitoring platform 102 may send a message including a certificate identifying the traffic routing and monitoring platform 102 and a digital signature of the traffic routing and monitoring platform 102, which may be verified by the third client device 107 (e.g., by checking a trusted certificate authority list, public key pinning, and / or other methods). Once this handshake is complete, the traffic routing and monitoring platform 102 may exchange encrypted messages (e.g., DNS query requests, DNS query responses, and / or other information).

[0134] Referring to FIG. 2F , in step 221, the traffic routing and monitoring platform 102 can identify the user of the third client device 107. For example, based on a third security certificate, the traffic routing and monitoring platform 102 identifies the third user. For example, authentication is supported using mutual X509 certificate authentication. In such an example, DNS over TLS can be used to enable traffic encryption over UDP rather than the HTTP protocol. By managing a public / private key infrastructure, the identity of the third user is securely determined during the exchange process between the third client device 107 and the traffic routing and monitoring platform 102.

[0135] For example, the traffic routing and monitoring platform 102 may identify the third user using mutual X509 certificate authentication using DNS over TLS (e.g., encryption over UDP) protocol. In these examples, the enterprise environment includes an internal / local resolver (e.g., DNS with a directory service, such as Microsoft Active Directory (AD)). The third user may be provided with instructions for the local / internal resolver to resolve to the traffic routing and monitoring platform 102. In such examples, DNS over TLS may be used if a higher level of security is desired. The third user may be provided with a client certificate and instructions for the local resolver to resolve to the traffic routing and monitoring platform 102 using DNS over TLS. In such examples, instructions to block outbound standard DNS and DNS over HTTPS are provided. Once received, the traffic routing and monitoring platform 102 may identify the third user based on the client certificate. Such mutual authentication offers technical advantages over other methods, such as enhanced security.

[0136] Although the identification of the third user is described in step 221 (e.g., before sending the first identity-embedded DNS query request), in some examples it may be performed based on information received in the third identity-embedded DNS query request, as further described in step 222. Thus, the identification of the third user may occur before or after receiving the third identity-embedded DNS query request without departing from the scope of the disclosure.

[0137] In step 222, once a secure session is established between the third client device 107 and the traffic routing and monitoring platform 102, the third client device 107 sends a third identity-embedded DNS query request (e.g., a fully encrypted DNS request, a partially encrypted DNS request, an unencrypted DNS request, or a request that is embedded and / or configured in the DNS protocol itself if the user ID is present in the certificate) to the traffic routing and monitoring platform 102. For example, the third client device 107 sends the domain name of the target server 108 and requests the IP address of the target server 108. For example, the third client device 107 may establish a TLS session over which the third identity-embedded DNS query request can be made securely. For example, the TLS session may be over TCP, UDP, and / or others. Additionally or alternatively, the third client device 107 may establish an HTTP session over which the DNS query request can be made. For example, the HTTP session may be unencrypted over TCP, UDP, etc., or may be encrypted by a TLS session. In some examples, the third client device 107 (e.g., a network interface of the third client device 107) may be pre-configured to direct DNS queries to the traffic routing and monitoring platform 102. For example, a third security certificate may be installed on the third client device 107 prior to sending the third identity-embedded DNS query request. In some examples, when sending the third identity-embedded DNS query request, the third client device 107 may be accessing the Internet from outside the protected network corresponding to the traffic routing and monitoring platform 102 and / or the proxy server 103. In some examples, the traffic routing and monitoring platform 102 may use the third security certificate to decrypt the third identity-embedded DNS query request.In these examples, if the third security credential has not yet been received by the traffic routing and monitoring platform 102, the traffic routing and monitoring platform 102 may prompt the third client device 107 to provide the third security credential.

[0138] In some examples, the actions described in step 222 may be similar to those described above with respect to the first client device 105 in step 205 and / or the second client device 106 in step 214. For example, in some examples, a user ID is received along with a third identity-embedded DNS query request (e.g., via DoH), which can be used to distinguish different profiles / identities for the third user (as further illustrated and described below with respect to FIG. 4).

[0139] In step 223, the traffic routing and monitoring platform 102 can identify a third traffic routing rule based on the identity of the third user. For example, the traffic routing and monitoring platform 102 may maintain a database of traffic routing rules corresponding to each of a plurality of users and identify the third traffic routing rule corresponding to the third user (e.g., by indexing the database). In some examples, in identifying the third traffic routing rule, the traffic routing and monitoring platform 102 identifies domain match criteria and corresponding actions to be performed for each of a plurality of domain names (including the domain names sent in the third identity-embedded DNS query response), both of which may be specific to the third user. For example, the third traffic routing rule may be specific to the third user's organization, the third user's subscription level (e.g., which may provide a unique security level and / or be selected or registered by the third user), geographic location, and / or other user characteristics. In other examples, the third traffic routing rule may be common among all network users (including the third user). In some examples, when specifying the domain match criteria for the third traffic routing rule, the traffic routing and monitoring platform 102 can identify a whitelist, blacklist, and / or watchlist specific to the third user. In these examples, each of the multiple domain names can be included in one of the whitelist, blacklist, and watchlist. In some examples, the third traffic routing rule is associated with a protected network (e.g., an enterprise network or other secure network).

[0140] In some examples, the third traffic routing rules may be selected based on a particular user identity for the third user (e.g., a rule corresponding to use of the first browser by the third user but not the second browser, etc.). In some examples, these third traffic routing rules are selected using methods similar to those described above with respect to step 206 and / or step 215, and / or in connection with the first and / or second traffic routing rules, and / or as further described with respect to FIG. 4. In some examples, the policies may be distributed, cached, and / or controlled by an intelligence policy manager system, as described with respect to step 206 and / or 215 and FIG. 5.

[0141] In step 224, the traffic routing and monitoring platform 102 may identify an action to perform with respect to the third identity-embedded DNS query request based on the third traffic routing rule. For example, the traffic routing and monitoring platform 102 may identify whether to allow, block, and / or monitor traffic directed to the IP address (which may correspond to the target server 108, for example) requested by the third identity-embedded DNS query request based on the third traffic routing rule. For example, the traffic routing and monitoring platform 102 may identify that IP addresses corresponding to blacklisted domains should be blocked, that access to IP addresses corresponding to whitelisted domains should be allowed, and that traffic to and from IP addresses corresponding to watchlisted domains should be monitored / logged. In some examples, when identifying an action to perform with respect to the third identity-embedded DNS query request, the traffic routing and monitoring platform 102 may identify a disposition (e.g., allow or block) and then a corresponding directive (e.g., perform inspection, monitor, log, alert, perform packet capture, perform payload inspection, and / or other action). For example, these directives may be implemented in addition to an "allow" or "block" action. For illustrative purposes, in step 224, the traffic routing and monitoring platform 102 may determine, based on the third traffic routing rule, that traffic directed to the IP address requested by the third identity-embedded DNS query request should be logged.For example, based on the third traffic routing rule, the traffic routing and monitoring platform 102 can identify that the domain name submitted in the third identity-embedded DNS query request corresponds to a potential security threat and is listed on a watchlist (and therefore traffic to and from the corresponding IP address should be logged).

[0142] 2G , in step 225, the traffic routing and monitoring platform 102 may identify the IP address requested by the third identity-embedded DNS query request (e.g., by performing actions similar to those described in step 208). In some examples, generating the third identity-embedded DNS query response may include DNS caching as described above with respect to the first identity-embedded DNS query response in step 208. However, rather than simply forwarding this IP address to the third client device 107, based on identifying that the domain name in the third identity-embedded DNS query request corresponds to a potential security threat whose traffic should be logged, the traffic routing and monitoring platform 102 may send a third identity-embedded DNS query response that includes the IP address of the proxy server 103 (e.g., 111.111.111.111). In some examples, the traffic routing and monitoring platform 102 may also include routing instructions (e.g., to direct traffic through the proxy server 103) in the third identity-embedded DNS query response. In some examples, the agent is used to include this routing instruction and the IP address of the proxy server 103 without excluding the IP address from the third identity-embedded DNS query response for the requested domain name.

[0143] In some examples, the traffic routing and monitoring platform 102 may send a third identity-embedded DNS query response that includes both the requested IP address and the proxy IP address. For example, the traffic routing and monitoring platform 102 can send a third identity-embedded DNS query response that includes the requested IP address embedded within the proxy IP address. In some examples, the third identity-embedded DNS query response includes a DNS record, associating a domain name with the proxy IP address, and a lifetime (e.g., the period of time the third identity-embedded DNS query response may exist before expiry). In some examples, the traffic routing and monitoring platform 102 may send the third identity-embedded DNS query response to the third client device 107 while a secure session with the third client device 107 is established.

[0144] In step 226, the third client device 107 may access the target server 108 through the proxy server 103. For example, the third client device 107 may send traffic to the proxy server 103 using the proxy IP address (e.g., referred to herein as outgoing network traffic). In these examples, the third client device 107 may indicate the proxy IP address as the destination IP address and include data directed to the domain name included in the third identity-embedded DNS query request. In some examples, the third client device 107 may also send a third security certificate to the proxy server 103. For example, the proxy server 103 may, in some examples, prompt the third client device 107 to provide a third security certificate to the proxy server 103, and the third client device 107 may send the third certificate in response (thereby, for example, allowing the proxy server 103 to identify the third user and / or the third client device 107). In doing so, the proxy server 103 is configured to distinguish between requests from different users on the same device (e.g., in contrast to IP address-based methods, which may not be able to distinguish between different users on the same device).

[0145] If the third identity-embedded DNS query response included a time to live, the third client device 107 may, in some examples, determine the DNS record's expiration date, including the expiration date of the DNS record for the proxy IP address. In these examples, rather than contacting the proxy server 103, the third client device 107 may return to step 222 (e.g., to request an updated DNS response). In some examples, the third traffic routing rule may have been updated during the DNS record's live period. For example, the third traffic routing rule may have been updated to indicate that traffic from the requested IP address should be blocked or traffic to the requested IP address should be allowed. In these examples, actions similar to those described above with respect to the first and second identity-embedded DNS query responses (e.g., with respect to allowing or blocking traffic, respectively) are performed by the traffic routing and monitoring platform 102 and / or the proxy server 103. In some examples, any intelligence corresponding to the third user and / or the domain name in the third identity-embedded DNS query request (e.g., as identified by the traffic routing and monitoring platform 102) may be sent to the proxy server 103 along with the traffic.

[0146] In step 227, the proxy server 103 may optionally identify the identity of the user of the third client device 107. For example, based on the third security credential, the proxy server 103 may identify the third user (e.g., using techniques similar to those described above in step 221). Additionally or alternatively, the proxy server 103 may receive information indicating the identity of the third user (e.g., from the traffic routing and monitoring platform 102 identified in step 221).

[0147] Once the proxy server 103 determines the identity of the third user, the proxy server 103 can identify a traffic monitoring rule based on the identity of the third user. In some examples, these may be the same as the third traffic monitoring rule identified in step 223. In other examples, these may be different traffic monitoring rules than those identified in step 223. For example, the proxy server 103 may maintain a database of traffic routing rules corresponding to each of multiple users and identify a traffic monitoring rule corresponding to the third user (e.g., by indexing the database). In some examples, the traffic monitoring rule indicates traffic associated with a potential security threat that should be logged / monitored, metadata to be collected for the traffic associated with the potential security threat, a sampling rate, a sampling frequency, and / or other information.

[0148] After identifying the traffic monitoring rule, the proxy server 103 can identify an action to perform with respect to traffic received from the third client device 107 based on the traffic monitoring rule. For example, the proxy server 103 may identify a traffic logging action / policy for the third user. In doing so, the proxy server 103 may apply an additional layer of policy customization based on user ID (e.g., in addition to the third traffic routing rule determined in step 223).

[0149] In step 228, the proxy server 103 may log / monitor information about the outbound traffic (e.g., traffic sent from the third client device 107 to the proxy server 103). In some examples, the terms logging and monitoring are used interchangeably throughout the specification to refer to proxying traffic, collecting metadata associated with the traffic, performing packet capture, performing deep packet inspection, performing payload inspection, and / or performing other actions. For example, the proxy server 103 may log the information in a stored data log. In some examples, the proxy server 103 may log the information based on traffic monitoring rules (e.g., specified metadata, specified rate / frequency, and / or other), which may be specific to the third user, for example, as described above. For example, the proxy server 103 may log one or more of the sender domain, recipient domain, time information, date information, and / or other information. In some examples, the proxy server 103 may perform logging in real time.

[0150] 2H, in step 229, the proxy server 103 may determine a destination IP address (e.g., the IP address of the target server 108). For example, the proxy server 103 may identify the destination IP address based on the proxy IP address (which, in some examples, may include the destination IP address embedded within the proxy IP address). In some examples, the proxy server 103 may resolve the destination IP address after receiving the outbound traffic. After determining the destination IP address, the proxy server 103 may forward the outbound traffic to the target server 108 (e.g., via a wired or wireless data connection).

[0151] In step 230, the target server 108 may send inbound traffic (eg, via a wired or wireless data connection) to the proxy server 103 (eg, in response to the outbound traffic sent in step 229).

[0152] In step 231, the proxy server 103 may log inbound traffic information (e.g., in the same stored data log). In doing so, the proxy server 103 may log information of traffic passing through the proxy server 103 in both directions. In some examples, the proxy server 103 may log information based on traffic monitoring rules, which may be specific to the third user, for example, as described above. For example, the proxy server 103 may log one or more of a sender domain, a recipient domain, time information, date information, and / or other information. In some examples, the proxy server 103 may log inbound traffic information in real time.

[0153] In some examples, the proxy server 103 may update traffic monitoring rules based on the logged information. For example, the proxy server 103 may increase, decrease, or maintain the frequency at which traffic information is logged. For example, if malicious activity is identified (e.g., after detecting a predetermined amount of traffic for a predetermined period of time, and / or otherwise), the proxy server 103 may modify the traffic monitoring rules for logged traffic information with an increased frequency. Alternatively, if malicious activity is not identified (e.g., after detecting a predetermined amount of traffic for a predetermined period of time, and / or otherwise), the proxy server 103 may modify the traffic monitoring rules to reduce the frequency at which traffic information is logged.

[0154] In step 232, the proxy server 103 can route the inbound traffic to the third client device 107 (eg, via a wired or wireless data connection).

[0155] In step 233, the proxy server 103 can transmit the stored data log to the traffic routing and monitoring platform 102 (e.g., via a wired or wireless data connection). While step 233 is shown after routing of inbound and outbound traffic, this is for illustrative purposes only. For example, the data log may, in some examples, be shared between the proxy server 103 and the traffic routing and monitoring platform 102 in real time as traffic is recorded and / or continuously at predetermined intervals. For example, in some examples, the data log can be made available in real time to enable immediate action based on the data log. For example, the data log can be provided to the traffic routing and monitoring platform 102, which can then update third traffic routing rules and / or other intelligence based on the data log. This allows traffic routing rules to be continuously and dynamically updated per user (regardless of whether the user has multiple devices and / or whether multiple users use the same device).

[0156] At step 234, the traffic routing and monitoring platform 102 may identify a third traffic routing rule based on the stored data log. For example, the traffic routing and monitoring platform 102 may update the action to be taken for the third user at the IP address corresponding to the target server 108. For example, if malicious activity is identified (e.g., after detecting a predetermined amount of traffic for a predetermined time period, and / or otherwise), the traffic routing and monitoring platform 102 may modify the third traffic routing rule to block traffic directed to the target server 108. Alternatively, if malicious activity is not identified (e.g., after detecting a predetermined amount of traffic for a predetermined time period, and / or otherwise), the traffic routing and monitoring platform 102 may modify the third traffic routing rule to allow traffic directed to the target server 108 without further monitoring. In doing so, the traffic routing and monitoring platform 102 may dynamically modify, update, and / or otherwise refine the third traffic routing rule based on the logged activity (thereby, for example, continuously improving the performance and effectiveness of the third traffic routing rule). Examples of such modifications and the processing of various records that may be returned and / or requested by the DNS system are shown in the following table. [Table 1] [Table 2]

[0157] While the first identity-embedded DNS query request, the second identity-embedded DNS query request, and the third identity-embedded DNS query request are described as including a domain name corresponding to the IP address of the target server 108, this is for illustrative purposes only, and the DNS queries may request different IP addresses without departing from the scope of this disclosure. Additionally, while a single proxy server 103 is shown, any number of proxy servers may be implemented without departing from the scope of this disclosure. For example, in some examples, different users (or groups of users) are directed to different proxy servers.

[0158] While steps 225 through 234 describe the use of proxy server 103 to perform traffic monitoring and / or logging, in some examples, steps 225 through 234, described below, illustrate the use of gateway server 115 (rather than proxy server 103) to perform traffic monitoring and logging. In some examples, these techniques, described below, may address current deficiencies in the use of proxy servers. For example, when gray zone traffic (e.g., traffic logged and monitored by proxy server 103) is sent to proxy server 103, the DNS response must be modified to include the proxy server's IP address (e.g., rather than the requested IP address). However, in such an example, the connection between the requested IP address and its corresponding DNS record may disappear (e.g., if the requested IP address is replaced with the proxy IP address). Thus, in some examples, a redirect to proxy server 103 may be successful for HTTP requests, but its use for other protocols (e.g., File Transfer Protocol (FTP)) may be limited. For example, requests implemented across such other protocols may not include the original intent associated with the request (e.g., the intent to access the target server 108), etc. Therefore, to support logging / monitoring of traffic for these other protocols, the proxy server 103 may be replaced with the use of a gateway server 115 (as described herein).

[0159] 2G , at step 225, the traffic routing and monitoring platform 102 may identify the IP address requested by the third identity-embedded DNS query request (e.g., by performing actions similar to those described in step 208). In some examples, generating the third identity-embedded DNS query response may include DNS caching, as described above with respect to the first identity-embedded DNS query response in step 208. However, rather than simply forwarding this IP address to the third client device 107, based on identifying that the domain name in the third identity-embedded DNS query request corresponds to a potential security threat whose traffic should be logged, the traffic routing and monitoring platform 102 may send a third identity-embedded DNS query response including the requested IP address (e.g., 123.123.123.123) along with routing instructions. This may, for example, cause the traffic routing and monitoring platform 102 to route traffic to an IP address (e.g., of the target server 108) through the gateway server 115 (e.g., by including the IP address of the gateway server 115 in the routing instructions). In some examples, the remaining traffic (that does not correspond to potential security threats, such as that corresponding to domain names, IP addresses, etc.) may be routed directly to the requested IP address.

[0160] In some examples, the third client device 107 may be pre-configured with an agent, e.g., configured to interpret routing instructions and direct traffic to the target server 108 via the gateway server 115. For example, the agent may encapsulate a connection between the third client device 107 and the target server 108, but route the traffic to the gateway server 115 rather than to the target server 108 (e.g., tunnel the traffic across the gateway server 115). This may effectively leverage the traffic routing and monitoring platform 102 to create an on-demand router, thereby enabling the redirection and / or pivoting of IP protocol communications for any type of corresponding protocol to a designated tunneling gateway.

[0161] This may allow the traffic routing and monitoring platform 102 to monitor / log traffic without replacing the IP address of the requested domain name and therefore without changing the destination IP address, but rather the traffic routing and monitoring platform 102 may change how traffic is routed to the destination IP address (e.g., in contrast to the method described in step 225, where the requested IP address is replaced with the IP address of the proxy server 103).

[0162] As an added benefit over the use of a proxy server 103, this gateway approach can more effectively convey identity. For example, if a proxy IP address is returned to the third client device 107, it may be difficult to ascertain the identity of the corresponding user when connecting to the proxy server 103 over a particular protocol. However, by providing the requested IP address, along with routing instructions for the gateway server 115, the user identity can be effectively conveyed regardless of protocol, port, etc. For example, an agent may recognize the user identity and therefore configure a gateway tunnel based on the known identity and route traffic through the tunnel accordingly (which may convey both the intended destination of the target server 108 and the user identity, for example).

[0163] As an additional benefit of using the proxy server 103, the gateway approach may be more effective in conveying identity context received from the third client device 107. For example, if traffic is routed to the proxy server 103, the proxy server 103 may terminate the connection with the third client device 107 upon receiving the traffic and establish a new connection with the target server 108 to route the traffic accordingly. In some examples, termination of the connection (with the third client device 107) by the proxy server 103 may present challenges in conveying identity and / or other information. For example, the third client device 107 may be provided with the IP address of the proxy server 103 and use this IP address to connect to the proxy server 103 accordingly. Once the traffic is received at the proxy server 103, the proxy server 103 may terminate the connection with the third client device 107 and then make a new connection to the target server 108 through which the traffic passes. Thus, the proxy server 103 may introduce a terminal endpoint into the initial connection with the third client device 107. This can make it difficult to associate the original DNS request (e.g., the third identity-embedded DNS query request) with the user identity. For example, if the third identity-embedded DNS query response indicating the proxy IP address is cached (e.g., on a local recursive server), other users can contact the proxy IP address without an existing DNS record. This can result in information being lost and correlation being difficult. In contrast, the use of the gateway server 115 allows the initially established connection with the third client device 107 to be maintained, and instead, the connection may be modified and / or encapsulated.In these examples, the agent may bind a user identity to the encapsulation, thus providing identity context for all corresponding traffic (which may include, for example, identity information indicating why the encapsulation tunnel is being established, time information, IP address information, etc.) without modifying the headers or aspects of the corresponding payload. Thus, by implementing gateway server 115, identities and communications can be bound together without terminating this correlation at proxy server 103.

[0164] Additionally, existing client devices may not be configured to route only a portion of their traffic (e.g., traffic to known bad IP addresses) through a proxy server, with the remaining traffic being sent directly to the corresponding target server. Rather, such traffic is routed entirely through the proxy server or not at all. Thus, by implementing the techniques described herein, the gateway server 115 receives a subset of requested and / or policy-defined traffic, which can then be applied at a higher level of granularity for logging / monitoring.

[0165] Furthermore, this provides advantages over traditional IP-based routing, which can selectively route traffic to various IP addresses through different tunnels. For example, the described systems and methods can be significantly scalable. For example, devices used to implement such traditional IP-based routing have limited processing resources and / or capabilities, which hinder the scalability described herein. As a specific example, rather than sending the third client device 107 a large number of IP addresses for which traffic should be logged (some of which may never be accessed by the third client device 107, for example), DNS can be utilized to identify the IP address to which the third client device 107 actually connects, and routing instructions can be dynamically inserted into a DNS query response (e.g., a third identity-embedded DNS query response) to reroute traffic through the gateway server 115 for a specific period of time (e.g., 24 hours). In some examples, these techniques may implement one or more aspects of the techniques described in U.S. Patent No. 10,715,493, filed July 3, 2019, entitled "METHODS AND SYSTEMS FOR EFFICIENT CYBER PROTECTIONS OF MOBILE DEVICES," and / or U.S. Patent No. 11,582,191, filed February 10, 2022, entitled "CYBER PROTECTIONS OF REMOTE NETWORKS VIA SELECTIVE POLICY ENFORCEMENT AT A CENTRAL NETWORK," the disclosures of which are incorporated herein by reference in their entireties.

[0166] In some examples, if the third client device 107 is pre-configured with an agent, instead of routing the traffic through the proxy server 103 (as described above with respect to steps 225 through 234) or the gateway server 115 (as described herein with respect to steps 235 through 242), the traffic routing and monitoring platform 102 can send the identified action (e.g., block or allow) and / or directive (e.g., perform inspection, monitor, log, alert, perform packet capture, perform payload inspection, and / or other action), which may be identified using techniques similar to those described with respect to the first, second, and / or third identity-embedded DNS query request, to the third client device 107 (e.g., as part of a third identity-embedded DNS query response) for local storage. In some examples, along with the identified action / directive, the traffic routing and monitoring platform 102 may provide the requested IP address. In these examples, the third client device 107 may perform, implement, and / or enforce the actions and / or directives itself with respect to traffic between the third client device 107 and the target server 108 (e.g., rather than having the traffic routing and monitoring platform 102, the proxy server 103, the gateway server 115, etc., perform these actions). In some examples, the third client device 107 may store these actions and / or directives (e.g., update a locally cached rule set) and, in some examples, automatically enforce them against future requests (associated with the same ID) for the requested IP address.In some examples, these techniques may implement one or more aspects of the techniques described in U.S. Pat. No. 11,012,417, filed April 30, 2019, entitled "METHODS AND SYSTEMS FOR EFFICIENT PACKET FILTERING," and / or U.S. Pat. No. 11,012,414, filed November 22, 2019, entitled "METHODS AND SYSTEMS FOR PREVENTION OF ATTACKS ASSOCIATED WITH THE DOMAIN NAME SYSTEM," the disclosures of which are incorporated herein by reference in their entireties. In some examples, these operations and / or directives may be stored using efficient data structures that allow them to be implemented by the third client device 107 itself. In some examples, these techniques may implement one or more aspects of the techniques described in U.S. Patent No. 10,715,493, filed July 3, 2019, entitled "METHODS AND SYSTEMS FOR EFFICIENT CYBER PROTECTIONS OF MOBILE DEVICES," the disclosure of which is incorporated herein by reference in its entirety. In some examples, this may include routing the identity-embedded DNS query request by the third client device 107 through a virtual private network (VPN). In some examples, these techniques may implement one or more aspects of the techniques described in U.S. Patent No. 11,582,191, filed February 10, 2022, entitled "CYBER PROTECTIONS OF REMOTE NETWORKS VIA SELECTIVE POLICY ENFORCEMENT AT A CENTRAL NETWORK," the disclosure of which is incorporated herein by reference in its entirety.By providing actions and / or directives associated with the third client device 107 corresponding to the requested IP address, the traffic routing and monitoring platform 102 may optimize policy storage at the third client device 107 by performing ad hoc rule distribution (e.g., by providing only policy information (e.g., actions and / or directives) associated with a given IP address for a given identity). In some examples, when policy information is updated (e.g., at the traffic routing and monitoring platform 102), locally stored policy information (e.g., at the third client device 107) is updated accordingly.

[0167] Returning to the gateway embodiment described with respect to steps 235 through 243, the traffic routing and monitoring platform 102 may send a third identity-embedded DNS query response that includes both the requested IP address and the proxy IP address. For example, the traffic routing and monitoring platform 102 sends the third identity-embedded DNS query response that includes the requested IP address embedded within the proxy IP address. In some examples, the third identity-embedded DNS query response includes a DNS record, associating a domain name with the proxy IP address, and a lifetime (e.g., the period of time the third identity-embedded DNS query response may exist before expiry). In some examples, the traffic routing and monitoring platform 102 may send the third identity-embedded DNS query response to the third client device 107 while a secure session with the third client device 107 is established.

[0168] In step 236, the third client device 107 may access the target server 108 through the gateway server 115. For example, the third client device 107 may send traffic to the gateway server 115 based on the routing instructions (e.g., referred to herein as outgoing network traffic). In these examples, the third client device 107 may indicate the requested IP address as the destination IP address and include data directed to the domain name included in the third identity-embedded DNS query request. In some examples, the third client device 107 may include identity information as part of the identity-embedded DNS query request, which allows the gateway server 115 to distinguish between requests from different users on the same device (e.g., in contrast to IP address-based methods, which may not be able to distinguish between different users on the same device).

[0169] If the third identity-embedded DNS query response included a time-to-live, the third client device 107 may, in some examples, determine the DNS record's expiration date, including the target server's 108 DNS record's expiration date. In these examples, rather than accessing the target server 108 via the gateway server 115, the third client device 107 may return to step 222 (e.g., to request an updated DNS response). In some examples, the third traffic routing rule may have been updated during the DNS record's live period. For example, the third traffic routing rule may have been updated to indicate that traffic from the requested IP address should be blocked or traffic to the requested IP address should be allowed. In these examples, actions similar to those described above with respect to the first and second identity-embedded DNS query responses (e.g., with respect to allowing or blocking traffic, respectively) may be performed by the traffic routing and monitoring platform 102 and / or the proxy server 103. In some examples, any intelligence corresponding to the third user and / or the domain name in the third identity-embedded DNS query request (e.g., as identified by the traffic routing and monitoring platform 102) may be sent along with the traffic to the gateway server 115.

[0170] Referring to FIG. 2J, in step 237, the gateway server 115 may log / monitor information of outbound traffic (e.g., traffic sent from the third client device 107 to the gateway server 115). As noted above, in some examples, the terms logging and monitoring are used interchangeably throughout the specification to refer to proxying traffic, collecting metadata associated with the traffic, performing packet capture, performing deep packet inspection, performing payload inspection, and / or performing other actions. For example, the gateway server 115 may log information in a stored data log. In some examples, the gateway server 115 may log information based on traffic monitoring rules (e.g., specified metadata, specified rate / frequency, and / or other), which may be specific to the third user, as described above. For example, the gateway server 115 may log one or more of a sender domain, a recipient domain, time information, date information, and / or other information. In some examples, the gateway server 115 may perform logging in real time.

[0171] In step 238, the gateway server 115 may determine the destination IP address (e.g., the IP address of the target server 108). For example, the proxy server 103 may identify the destination IP address based on the third identity-embedded DNS query request (which may include, for example, the destination IP address). After determining the destination IP address, the gateway server 115 may forward the outbound traffic to the target server 108 (e.g., via a wired or wireless data connection).

[0172] In step 239, the target server 108 may send inbound traffic to the gateway server 115 (eg, via a wired or wireless data connection) (eg, in response to the outbound traffic sent in step 238).

[0173] In step 240, the gateway server 115 may log inbound traffic information (e.g., in the same stored data log). In doing so, the gateway server 115 may log information of traffic passing through the gateway server 115 in both directions. In some examples, the gateway server 115 may log information based on traffic monitoring rules, which may be specific to the third user, for example, as described above. For example, the gateway server 115 may log one or more of a sender domain, a recipient domain, time information, date information, and / or other information. In some examples, the gateway server 115 may log inbound traffic information in real time.

[0174] In some examples, the gateway server 115 may increase, decrease, or maintain the frequency at which traffic information is logged. For example, if malicious activity is identified (e.g., after detecting a predetermined amount of traffic for a predetermined period of time, and / or otherwise), the gateway server 115 may log traffic at an increased frequency. Alternatively, if malicious activity is not identified (e.g., after detecting a predetermined amount of traffic for a predetermined period of time, and / or otherwise), the proxy server 103 may change, decrease, or decrease the frequency at which traffic information is logged.

[0175] Referring to FIG. 2K, in step 241, the gateway server 115 may route the inbound traffic to the third client device 107 (eg, via a wired or wireless data connection).

[0176] In step 242, the gateway server 115 may transmit the stored data log to the traffic routing and monitoring platform 102 (e.g., via a wired or wireless data connection). While step 242 is shown after routing of inbound and outbound traffic, this is for illustrative purposes only. For example, the data log may, in some examples, be shared between the gateway server 115 and the traffic routing and monitoring platform 102 in real time as traffic is recorded and / or continuously at predetermined intervals. For example, in some examples, the data log may be made available in real time to enable immediate action based on the data log. For example, the data log may be provided to the traffic routing and monitoring platform 102, which may enable the traffic routing and monitoring platform 102 to update third traffic routing rules and / or other intelligence based on the data log. This allows traffic routing rules to be updated continuously and dynamically on a per-user basis (regardless of whether a user has multiple devices and / or whether multiple users use the same device).

[0177] In step 243, the traffic routing and monitoring platform 102 may identify a third traffic routing rule based on the stored data log. For example, the traffic routing and monitoring platform 102 may update the action to be taken for the third user at the IP address corresponding to the target server 108. For example, if malicious activity is identified (e.g., after detecting a predetermined amount of traffic for a predetermined time period, and / or otherwise), the traffic routing and monitoring platform 102 may modify the third traffic routing rule to block traffic directed to the target server 108. Alternatively, if malicious activity is not identified (e.g., after detecting a predetermined amount of traffic for a predetermined time period, and / or otherwise), the traffic routing and monitoring platform 102 may modify the third traffic routing rule to allow traffic directed to the target server 108 without further monitoring. In doing so, the traffic routing and monitoring platform 102 may dynamically modify, update, and / or otherwise refine the third traffic routing rule based on the logged activity (thereby, for example, continuously improving the performance and effectiveness of the third traffic routing rule).

[0178] While the first identity-embedded DNS query request, the second identity-embedded DNS query request, and the third identity-embedded DNS query request are described as including a domain name corresponding to the IP address of the target server 108, this is for illustrative purposes only; the DNS queries may request different IP addresses without departing from the scope of this disclosure. Furthermore, while a single gateway server 115 is shown, any number of gateway servers may be implemented without departing from the scope of this disclosure. For example, in some examples, different users (or groups of users) are directed to different gateway servers. Furthermore, while the methods for allowing, blocking, and logging traffic are shown in a sequential order, this is for illustrative purposes only; requests may be allowed, blocked, and logged simultaneously and / or in any other order without departing from the scope of this disclosure.

[0179] 3 illustrates an exemplary method for traffic routing and monitoring in accordance with one or more exemplary embodiments. Referring to FIG. 3 , at step 305, a computing platform having at least one processor, a communications interface, and a memory can issue a security credential to a client device. For example, the computing platform may issue a certificate that may identify the client device and / or a user of the client device. In some examples, the security credential can be used to establish a secure session and / or a secure DNS channel between the computing platform and the security credential.

[0180] In step 310, the computing platform may receive a security certificate and a request to establish a secure session from the client device. In some examples, the request indicates an intent to establish a secure DNS channel between the computing platform and the client device.

[0181] In step 315, the computing platform may verify the security certificate. For example, the computing platform performs a handshake with the client device, where the computing platform verifies the security certificate and the client device authenticates the computing platform's information (e.g., a certificate, a signature, and / or other authentication mechanism). If the security certificate is not verified, the computing platform may return to step 310. If the security certificate is verified, the computing platform may proceed to step 320.

[0182] The computing platform may establish a secure session with the client device at step 320. For example, the computing platform may establish a secure DNS channel between the client device and the computing platform.

[0183] The computing platform may receive an encrypted DNS query request from a client device at step 325. For example, the computing platform may receive a request for an IP address corresponding to a particular domain name, which may be provided in the encrypted DNS query request.

[0184] At step 330, the computing platform may identify a user of the client device based on the security credentials. At step 335, the computing platform may identify a traffic routing rule based on the user ID. For example, the computing platform may index a database based on the user ID to identify a corresponding traffic routing rule that indicates whether to block, allow, or log traffic directed to a particular IP address.

[0185] In step 340, the computing platform may provide an encrypted DNS query response to the client device based on the traffic routing rule. For example, if the traffic routing rule corresponding to the requested IP address and the user indicates that the traffic should be allowed, the computing platform may provide the requested IP address as an encrypted DNS query response. If the traffic routing rule corresponding to the requested IP address and the user indicates that the traffic should be blocked, the computing platform may indicate that the requested IP address is inaccessible as an encrypted DNS query response. If the traffic routing rule corresponding to the requested IP address and the user indicates that the traffic should be logged, the computing platform may provide an IP address of a proxy server, and the proxy server is configured to monitor traffic between the user device and the target server corresponding to the requested IP address.

[0186] FIG. 4 illustrates an example of traffic routing and monitoring in accordance with one or more exemplary embodiments. More specifically, FIG. 4 illustrates how and where identities can be embedded or assigned to DNS requests along the path between a client application and a traffic routing and monitoring platform. As shown in FIG. 4, a client device 401 (which may be similar to, for example, first client device 105, second client device 106, third client device 107, and / or other client devices, as described above) may communicate to a traffic routing and monitoring platform 407 (which may be similar to, for example, traffic routing and monitoring platform 102, as described above). In communicating the DNS request, the client device 401 may embed one or more identities (representatives of a user, application, profile, operating system, etc.) in the request. In some examples, these DNS requests may pass through (e.g., unchanged) and / or may be modified by one or more intermediaries (e.g., local DNS resolver 406, etc.) along the way. In these examples, the intermediary may similarly embed an identity (e.g., a representation of an entity associated with a given intermediary device) into the DNS request. When the DNS request reaches its final destination at the traffic routing and monitoring platform 407, the traffic routing and monitoring platform 407 may identify the policies associated with each identity (e.g., using stored key / value pairs and / or other identity / policy pairs representative of the identities and policies) and generate an overall / comprehensive policy accordingly (which may include, for example, resolving conflicts between the identified policies).

[0187] As a first example, client device 401 may send a first DNS query 408a from a personal profile 402a of a first browser 402. In this example, client device 401 may embed an identity (e.g., a first identity) corresponding to client device 401, personal profile 402a, and first browser 402 as a URL prefix in first DNS query 408a using DoH. In this example, first DNS query 408a may be received directly by traffic routing and monitoring platform 407. Traffic routing and monitoring platform 407 may identify an identity / policy pair corresponding to the identity associated with the URL prefix, select a policy (e.g., a first policy), and apply the first policy accordingly.

[0188] As a second example, client device 401 can send second DNS query 408b from work profile 402b of first browser 402. In this example, client device 401 can embed an identity, (e.g., a second identity), corresponding to client device 401, first browser 402, and work profile 402b as a URL prefix in second DNS query 408b using DoH. For example, a user can be represented by different identities when making requests to their personal profile 402a and work profile 402b. In this example, second DNS query 408b is routed to traffic routing and monitoring platform 407 via local DNS resolver 406. Thus, local DNS resolver 406 can embed a third identity (corresponding to local DNS resolver 406) in second DNS query 408b′ as a URL prefix update. Thus, the traffic routing and monitoring platform 407 can receive both the second and third identities, identify the corresponding identity / policy pairs, and select corresponding policies (e.g., the second policy and the third policy) accordingly (for each of the second and third identities).

[0189] Once multiple policies have been identified by the traffic routing and monitoring platform 407, an overall or comprehensive policy may be identified. In examples where the second and third policies do not conflict, the traffic routing and monitoring platform 407 may generate an overall policy that is the sum of both the second and third policies, thereby, for example, allowing both policies to be applied in their entirety. In examples where the second and third policies directly conflict, the traffic routing and monitoring platform 407 may select a dominant policy as the overall policy (e.g., selecting either the second policy or the third policy). In some examples, the traffic routing and monitoring platform 407 may select one or more dominant rules (e.g., rather than selecting the entire second policy or the entire third policy). In these examples, the traffic routing and monitoring platform 407 may select one or more dominant rules from the second policy and / or the third policy (e.g., a rule from the second policy and a rule from the third policy, etc.). For example, the traffic routing and monitoring platform 407 may generate and / or otherwise associate a priority score with the rule associated with each policy and may select a rule from one or more policies (e.g., the second policy and / or the third policy) by selecting, from a pair of conflicting rules, the rule that has a higher priority score than the remaining rule. In examples where the second and third policies are partially in conflict, the traffic routing and monitoring platform 407 may resolve the second and third policies to generate an overall policy that includes attributes of one policy and any remaining non-conflicting attributes of the other policy based on specified criteria (e.g., dominance, ranking, etc.).

[0190] In some examples, in addition to or as an alternative to combining and / or adjusting the policies themselves, the traffic routing and monitoring platform 407 may identify attributes corresponding to each identity and combine, add, remove, and / or adjust other attributes of each identity. For example, each identity may include a collection of attributes. The traffic routing and monitoring platform 407 may identify some or all of the attributes corresponding to any received identity (e.g., user, profile, application operating system, device, local network, customer, WAN IP, geographic context, and / or other information) and resolve and / or combine the attributes accordingly to generate an overall identity. The traffic routing and monitoring platform 407 may then identify an appropriate associated policy corresponding to this overall identity. Once the overall policy is identified, it is applied by the traffic routing and monitoring platform 407.

[0191] As a third example, client device 401 can send third DNS query 408c from personal profile 403a of second browser 403. In this example, client device 401 may not be configured with a traffic routing and monitoring service or application corresponding to traffic routing and monitoring platform 407, and therefore an identity cannot be embedded in third DNS query 408c. In this example, third DNS query 408c′ can be routed by operating system 405 to local DNS resolver 406, which can then forward it to traffic routing and monitoring platform 407. In this example, operating system 405 can process third identity-embedded DNS query request 408, attach a fourth identity (corresponding to operating system 405) to third DNS query 408c′ (e.g., as part of a client certificate associated with the operating system as part of DoT), and forward the third identity-embedded DNS query request to local resolver 406. Similarly, the local DNS resolver 406 may embed a third identity (corresponding to the local DNS resolver 406 described above) into a third DNS query 408c'' and embed the third identity within the DoT TLS tunnel as part of the DNS request. In these examples, the local DNS resolver 406 may terminate the existing TLS session and establish a new TLS session. Thus, the traffic routing and monitoring platform 407 may receive both the third and fourth identities, identify the corresponding identity / policy pairs, and select the corresponding policies (e.g., the third policy and the fourth policy) accordingly (for each of the third and fourth identities).These policies are similarly reconciled by the traffic routing and monitoring platform 407 to identify an overall or blanket policy, as described above, which is then applied by the traffic routing and monitoring platform 407.

[0192] As a fourth example, the client device 401 can send a fourth DNS query 408d from the working profile 403b of the second browser 403. In this example, the fourth DNS query 408d is similarly routed to the traffic routing and monitoring platform 407 via the operating system 405 and the local DNS resolver 406. However, this example differs as described above with respect to the third DNS query 408c; the client device 401 can be configured with a traffic routing and monitoring agent 405a and can therefore embed an identity in the fourth DNS query 408d′ (e.g., a fifth identity representing the client device 401, the second browser, and the working profile 403b). For example, the traffic routing and monitoring agent 405a may add a corresponding identity (e.g., a seventh identity representing the traffic routing and monitoring agent 405a) and then pass the fourth DNS query 408d′ to the operating system 405, adding the corresponding identity (e.g., the fifth identity). Alternatively, the operating system 405 may receive the fourth DNS query 408d, embed its corresponding identity (e.g., the fifth identity), and then route the fourth DNS query 408d′ to the traffic routing and monitoring agent 405a, which then adds the corresponding identity (e.g., the seventh identity). In some examples, rather than embedding the seventh identity with the fifth identity, the traffic monitoring and routing agent 405a can replace the fifth identity with the seventh identity, e.g., replace or add to the fifth identity. Thus, the traffic routing and monitoring platform 407 can receive the fourth identity, identify the corresponding identity / policy pair, and select / apply the corresponding policy.In this example, if only one policy is selected, it does not need to be coordinated with other policies as described in the example above.

[0193] As a fifth example, client device 401 can send fifth DNS query 408e from work profile 404a of application 404. In this example, client device 401 can embed an identity, (e.g., a sixth identity), corresponding to client device 401, work profile 404a, and application 404 as a URL prefix in fifth DNS query 408e using DoH. In this example, fifth DNS query 408e is similarly routed via operating system 405 and local DNS resolver 406 to traffic routing and monitoring platform 407. Then, as fifth DNS query 408e is routed through operating system 405 and local DNS resolver 406, the fourth identity (corresponding to operating system 405) and the third identity (corresponding to local DNS resolver 406) can be embedded in the fifth DNS query (e.g., fifth DNS queries 408e′ and 408e″, respectively) (e.g., by modifying a URL prefix to hold multiple identities or by embedding additional identities within the DNS request). Thus, traffic routing and monitoring platform 407 can receive the sixth identity, the fourth identity, and the fifth identity, identify corresponding identity / policy pairs, and select / apply the corresponding policies. These policies are similarly reconciled by traffic routing and monitoring platform 407 to identify an overall or blanket policy, as described above, and the overall policy is then applied by traffic routing and monitoring platform 407.

[0194] Thus, as illustrated and described in these examples, different policies / traffic routing rules apply in various different scenarios even though each DNS request is sent by the same user from the same client device 401. Similarly, by enabling the sending of DNS requests using identity-based unencrypted or encrypted DNS requests, DoT / DoH, etc., multiple types of identity information can be attached or embedded in DNS requests, thereby, for example, enabling more granular policy decisions (e.g., based on each particular identity).

[0195] 6A through 6D illustrate an exemplary sequence of events for improved traffic routing and monitoring in accordance with one or more exemplary embodiments. Referring to FIG. 6A, in step 601, a client device 620 (e.g., which may be similar to the first client device 105, the second client device 106, and / or the third client device 107) sends a DNS request to a traffic routing and monitoring platform 630 (e.g., which may be similar to the traffic routing and monitoring platform 102). In some examples, the DNS request may include one or more domain names, and a corresponding DNS response (described further below) includes one or more IP addresses.

[0196] In step 602, the traffic routing and monitoring platform 630 may check the domain and / or other information included in the DNS request (e.g., against known threats, overall policies, etc.). For example, the traffic routing and monitoring platform 630 checks a local cache for any associated information (which may include queries and / or responses) with the requested domain(s). In step 603, the traffic routing and monitoring platform 630 may check the IP address(es) of the global DNS resolver 640 against known threats, overall policies, etc. If the traffic routing and monitoring platform 630 detects a threat and / or policy violation, it may not proceed to step 604. Rather, the traffic routing and monitoring platform 630 may block the request and return a DNS response indicating that the DNS request was blocked. Otherwise, if no threat or policy violation is identified in the domain or at the global DNS resolver 640, the traffic routing and monitoring platform 630 may proceed to step 604 and forward the DNS request to the global DNS resolver 640.

[0197] 6B , in step 605, the global DNS resolver 640 may check the IP address of the root server 650 against known threats, overall policies, etc. If a threat and / or policy violation is detected, the global DNS resolver 640 may not proceed to step 606. Rather, the global DNS resolver 640 blocks the request and returns a DNS response indicating that the DNS request was blocked (e.g., to the traffic routing and monitoring platform 630, which may forward the DNS response to the client device 620, for example). Otherwise, if no threat or policy violation is detected, the global DNS resolver 640 may proceed to step 606 and forward the DNS request to the root server 650.

[0198] In step 607, the root server 650 can send the IP address of the top-level domain (TLD) server 660 to the global DNS resolver 640. In step 608, the global DNS resolver 640 may check the TLD server IP against known threats, overall policies, etc. If a threat or policy violation is detected, the global DNS resolver may not proceed to step 609. Rather, the root server 650 blocks the request and returns a DNS response indicating that the DNS request was blocked (e.g., to the traffic routing and monitoring platform 630, which may forward the DNS response to the client device 620, for example). If no threat or policy violation is detected, the global DNS resolver 640 can proceed to step 609 and forward the DNS request to the authoritative server 670 (as illustrated in FIG. 6C ).

[0199] 6C , in step 610, the TLD server 660 can send the IP address of the authoritative server 670 to the global DNS resolver 640. In step 611, the global DNS resolver 640 may check the authoritative server IP and / or domain against known threats, overall policies, etc. If a threat or policy violation is detected, the global DNS resolver 640 may not proceed to step 612. Rather, the TLD server 660 blocks the request and returns a DNS response indicating that the DNS request was blocked (e.g., to the traffic routing and monitoring platform 630, which may forward the DNS response to the client device 620, for example). Otherwise, if no threat or policy violation is detected, the global DNS resolver 640 can proceed to step 612 and forward the DNS request to the authoritative server 670.

[0200] 6D , in step 613, the authoritative server 670 may send the DNS response to the global DNS resolver 640. In step 614, the global DNS resolver 640 may forward the DNS response to the traffic routing and monitoring platform 630. In step 615, the traffic routing and monitoring platform 630 may check the DNS response (and any included information) against known threats, overall policies, etc. If the DNS response corresponds to a known threat or policy violation, the traffic routing and monitoring platform 630 either does not forward it to the client device 620 or sends a modified response to the client device 620. Otherwise, if the DNS response does not correspond to a known threat or policy violation, the traffic routing and monitoring platform 630 may proceed to step 616 and forward the DNS response to the client device 620.

[0201] In some examples, the traffic routing and monitoring platform 630 can use cyber threat intelligence (CTI), non-compliant character detection (e.g., as described above with respect to step 205), and / or an overall policy to identify whether to forward the entire DNS response or a portion of the DNS response. For example, the DNS response includes multiple IP addresses. In some examples, the traffic routing and monitoring platform 630 can identify, based on the CTI and / or the overall policy, that one IP address in the response should not be forwarded to the client device 620 and remove this portion of the DNS response before forwarding it to the client device 620. Additionally or alternatively, the traffic routing and monitoring platform 630 can perform a threshold comparison of the DNS response. For example, the traffic routing and monitoring platform 630 can identify whether a majority of the IP addresses included in the response are safe and / or compliant with the overall policy and send the DNS response only if this majority threshold is met. In this example, if the traffic routing and monitoring platform 630 identifies the majority of IP addresses as safe, it may still remove any IP addresses determined to be unsafe or violating applied policies prior to routing to the client device 620.

[0202] By operating in this manner, the traffic routing and monitoring platform 630 can protect against attacks from systems that may be controlled by malicious actors and / or that may otherwise be compromised (e.g., via tunneling attacks, malware installation, etc.) Additionally, the traffic routing and monitoring platform 630 can prevent information leakage to operators of the DNS infrastructure that do not adhere to (or may otherwise attempt to circumvent) privacy and / or security procedures.

[0203] In some examples, when sending a DNS response to the client device 620, the traffic routing and monitoring platform 630 may add routing instructions to the DNS response. In some examples, the traffic routing and monitoring platform 630 may add such instructions if the client device 620 is known to be configured to interpret such instructions. In these examples, the instructions may instruct the client device 620 to route traffic to the provided IP address through a proxy server or gateway (e.g., to log the traffic) and / or otherwise. By operating in this manner, the provided IP address itself may not be changed (thus, intelligence and / or investigative capabilities corresponding to the provided IP address may be maintained), but rather additional routing instructions are added on top of the original IP address (e.g., embedding the routing IP address in a txt record and / or other field).

[0204] One or more aspects of the present disclosure may be embodied in computer-usable data or computer-executable instructions (e.g., one or more program modules), executed by one or more computers or other devices to perform the operations described herein. Generally, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by one or more processors of a computer or other data processing device. The computer-executable instructions may be stored as computer-readable instructions on a computer-readable medium, such as a hard disk, optical disk, removable storage medium, solid-state memory, RAM, etc. The functionality of the program modules may be combined or distributed as desired in various embodiments. Furthermore, the functionality may be embodied, in whole or in part, in firmware or hardware equivalents, such as an integrated circuit, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), etc. Particular data structures may be used to more effectively implement one or more aspects of the present disclosure, and such data structures are considered within the scope of computer-executable instructions and computer-usable data described herein.

[0205] Various aspects described herein may be embodied as methods, apparatus, or one or more computer-readable media storing computer-executable instructions. Accordingly, these aspects may take the form of entirely hardware embodiments, entirely software embodiments, entirely firmware embodiments, or embodiments combining software, hardware, and firmware aspects in any combination. Furthermore, various signals representing data or events as described herein may be transferred between a source and a destination in the form of light or electromagnetic waves passing through a signal-conducting medium, such as metal wires, optical fibers, or wireless transmission media (e.g., air or space). Generally, the one or more computer-readable media may be and / or include one or more non-transitory computer-readable media.

[0206] As described herein, various methods and acts may operate across one or more computing servers and one or more networks. Functions may be distributed in any manner or may be located on a single computing device (e.g., server, client computer, etc.). For example, in alternative embodiments, one or more of the computing platforms described above may be combined into a single computing platform, and the various functions of each computing platform may be performed by the single computing platform. In such an arrangement, some or all of the communications described above between the computing platforms may correspond to data accessed, moved, modified, updated, and / or otherwise used by the single computing platform. Additionally, or alternatively, one or more of the computing platforms described above may be implemented in one or more virtual machines provided by one or more physical computing devices. In such a configuration, the various functions of each computing platform may be performed by one or more virtual machines, and some and / or all of the communications described above between the computing platforms may correspond to data accessed, moved, modified, updated, and / or otherwise used by the one or more virtual machines.

[0207] For the avoidance of doubt, and without limiting the scope of the disclosure above or in the drawings, this application further includes subject matter described in the following numbered clauses: Section 1 1. A method for identity-based Domain Name System (DNS) routing for DNS queries with security policies specific to an identified user, the method comprising: establishing a secure DNS session using an encrypted DNS process, the establishing the secure DNS session comprising performing an encrypted session handshake between an identity-based DNS routing platform and a client device, the performing the encrypted session handshake including receiving from the client device an encrypted DNS process security certificate that identifies a user of the client device; and, while the secure DNS session is established, receiving from the client device an encrypted DNS query request comprising a request for an Internet Protocol (IP) address of a domain name, the encrypted DNS query request specifying the domain name, and determining the identity of the user based on the security certificate. determining a user identity (ID) of the user; and determining a security policy specific to the user based on the ID of the user, the security policy comprising one or more domain name filtering rules, each domain name filtering rule comprising a respective domain match criterion and a corresponding action to be taken for a matching domain name; using the one or more domain name filtering rules to determine a first action corresponding to the domain name in response to the encrypted DNS query request based on the domain name in the encrypted DNS query request; and determining an encrypted DNS query response based on the first action corresponding to the domain name, wherein determining the encrypted DNS query response includes performing an upstream request to the IP address of the domain name to identify the IP address of the domain name; and sending the encrypted DNS query response to the client device. Section 2 2. The ID-based DNS routing method of claim 1, wherein the security policy is user-specific based on an organization associated with the user of the client device, and the encrypted DNS query request is received from the client device while the client device is transmitting the encrypted DNS query request from outside the organization's protected network. Section 3 3. The ID-based DNS routing method of any of claims 1 to 2, wherein the corresponding action taken for the matching domain names indicates whether traffic should be blocked, allowed, or logged for each of the matching domain names. Section 4 4. The ID-based DNS routing method of any of claims 1 to 3, wherein determining the first action corresponding to the domain name comprises determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be blocked. Section 5 5. The ID-based DNS routing method of clause 4, wherein the encrypted DNS query response comprises an IP address of a block notification page. Section 6 5. The ID-based DNS routing method of clause 4, wherein the encrypted DNS query response comprises a notification that the requested IP address has been blocked. Section 7 7. The ID-based DNS routing method of any of claims 1 to 6, wherein determining the first action corresponding to the domain name comprises determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be allowed. Section 8 8. The ID-based DNS routing method of clause 7, wherein the encrypted DNS query response comprises an IP address of a server associated with the domain name in the encrypted DNS query request. Section 9 9. The ID-based DNS routing method of any of claims 1 to 8, wherein determining the first action corresponding to the domain name comprises determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be logged by a proxy server. Section 10 10. The ID-based DNS routing method of clause 9, wherein the encrypted DNS query response comprises an IP address of the proxy server. Section 11 11. The ID-based DNS routing method of clause 10, wherein the encrypted DNS query response is configured such that outgoing and incoming traffic to and from the IP address of a server associated with the domain name of the encrypted DNS query request is routed through the proxy server. Section 12 12. The ID-based DNS routing method of claim 11, wherein the proxy server receives outgoing network traffic from the client device, the outgoing network traffic indicating a proxy IP address of the proxy server as a destination IP address and comprising data destined for a server associated with the domain name, and receives inbound network traffic from the server associated with the domain name comprising a response to the outgoing network traffic; logs network traffic based on domain match criteria of the domain name and corresponding actions performed on the domain name, wherein the network traffic comprises one or more of the outgoing network traffic and the inbound network traffic; and sends the inbound network traffic to the client device. Section 13 13. The ID-based DNS routing method of any of clauses 9 to 12, wherein the proxy server prompts the client device to provide the security certificate, and determines one or more network policies based on the security certificate, the one or more network policies indicating traffic associated with a potential security threat for which traffic should be logged and metadata to be collected about the traffic associated with the potential security threat, collects the metadata for the traffic associated with the potential security threat, and transmits the metadata to the ID-based DNS routing platform. Section 14 14. The ID-based DNS routing method of any of claims 1 to 13, wherein a network interface of the client device is pre-configured to send a DNS request to an IP address of the ID-based DNS routing platform, and the security certificate is installed on the client device before receiving the encrypted DNS query request. Section 15 15. The ID-based DNS routing method of clause 14, wherein the client device is pre-configured based on installation of an entity security profile on the client device, and the installation of the entity security profile on the client device causes the client device to send the DNS request to the IP address of the ID-based DNS routing platform. Section 16 16. The ID-based DNS routing method of any of claims 1 to 15, wherein determining the security policy for the user comprises determining to apply one of a user-specific policy, an organization-level policy, or a default policy to the user. Section 17 17. The ID-based DNS routing method of any of claims 1 to 16, wherein the one or more domain name filtering rules comprise a whitelist, a blacklist, and a watchlist, and each of the matching domain names is included in one of the whitelist, the blacklist, or the watchlist. Section 18 18. The ID-based DNS routing method of claim 17, wherein determining the first action to take on the domain name comprises identifying whether the domain name is listed on the whitelist, the blacklist, or the watchlist, wherein the first action is to block traffic to an IP address of the domain name if the domain name is listed on the blacklist, the first action is to log traffic to the IP address of the domain name if the domain name is listed on the watchlist, and the first action is to allow traffic to access the IP address of the domain name if the domain name is listed on the whitelist. Section 19 19. The ID-based DNS routing method of any of claims 1 to 18, wherein the encrypted session handshake comprises a Transport Layer Security (TLS) handshake. Section 20 20. The ID-based DNS routing method of any of claims 1 to 19, wherein determining the identity of the user further comprises determining the identity of the user based on at least a first identity and a second identity. Section 21 21. The ID-based DNS routing method of clause 20, wherein the first ID and the second ID are embedded in the encrypted DNS query request at the client device. Section 22 21. The ID-based DNS routing method of claim 20, wherein the first encrypted DNS query request is routed from the client device to the ID-based DNS routing platform along a DNS path, which may be a path of the first encrypted DNS query request that recurses through different DNS servers to build a response back to the client device. Section 23 23. The ID-based DNS routing method of clause 22, wherein the first ID is embedded in the encrypted DNS query request at the client device and the second ID is embedded in the encrypted DNS query request at an intermediate server along the DNS path. Section 24 21. The ID-based DNS routing method of claim 20, wherein the first ID corresponds to a first domain name filtering rule, the second ID corresponds to a second domain name filtering rule, and the security policy determination comprises resolving a conflict between the first domain name filtering rule and the second domain name filtering rule. Section 25 25. A system comprising one or more computing devices, the system configured to perform the method of any of clauses 1 to 24. Section 26 One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of one or more computing devices of a system, cause the system to perform the method of any of clauses 1 through 24. Section 27 1. A method for identity-based Domain Name System (DNS) routing for DNS queries with a security policy specific to an identified user, the method comprising: establishing a DNS session between an ID-based DNS routing platform and a client device using an unencrypted DNS process; receiving, during the establishment of the DNS session, from the client device an unencrypted DNS query request comprising a request for an Internet Protocol (IP) address of a domain name, the unencrypted DNS query request specifying the domain name; determining an identity (ID) of the user based on identity information embedded in the unencrypted DNS query request; and determining a security policy specific to the user based on the ID of the user, wherein the security policy is applied to the user. a security policy comprising one or more domain name filtering rules, each domain name filtering rule comprising a respective domain match criterion and a corresponding action to be taken for a matching domain name; using the one or more domain name filtering rules to determine, based on the domain name in the unencrypted DNS query request, a first action corresponding to the domain name in response to the unencrypted DNS query request; and determining an unencrypted DNS query response based on the first action corresponding to the domain name, wherein determining the unencrypted DNS query response includes performing an upstream request to the IP address of the domain name to identify the IP address of the domain name; and sending the unencrypted DNS query response to the client device. Section 28 28. The ID-based DNS routing method of clause 27, wherein the identity information is embedded using clear text in a field of the unencrypted DNS query request. Section 29 29. The ID-based DNS routing method of any of clauses 27 to 28, wherein the identity information is not encrypted. Section 30 30. The ID-based DNS routing method of any of clauses 27 to 29, wherein the identity information is encrypted. Section 31 31. The ID-based DNS routing method of any of clauses 27 to 30, wherein the identity information is encrypted by the client device. Section 32 32. The ID-based DNS routing method of any of clauses 27 to 31, wherein the identity information is encrypted by a local resolver, and the unencrypted DNS query request passes through the local resolver before being received in the unencrypted DNS query request. Section 33 33. The ID-based DNS routing method of clause 32, wherein encrypting the identity information by the local resolver comprises adding an identity of the local resolver to the identity information; and encrypting the identity information after adding the identity of the local resolver to the identity information. Section 34 33. The ID-based DNS routing method of clause 32, wherein encrypting the identity information by the local resolver comprises removing a portion of the identity information; and encrypting the identity information after removing the portion of the identity information. Section 35 35. The ID-based DNS routing method of any of clauses 27 to 34, wherein the security policy is user-specific based on an organization associated with the user of the client device, and the unencrypted DNS query request is received from the client device while the client device is transmitting the unencrypted DNS query request from outside the organization's protected network. Section 36 36. The ID-based DNS routing method of any of clauses 27 to 35, wherein the corresponding action taken for the matching domain names indicates whether traffic should be blocked, allowed, or logged for each of the matching domain names. Section 37 37. The ID-based DNS routing method of any of clauses 27 to 36, wherein determining the first action corresponding to the domain name comprises determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be blocked. Section 38 38. The ID-based DNS routing method of clause 37, wherein the unencrypted DNS query response comprises an IP address of a block notification page. Section 39 38. The ID-based DNS routing method of clause 37, wherein the unencrypted DNS query response comprises a notification that the requested IP address has been blocked. Section 40 40. The ID-based DNS routing method of any of clauses 27 to 39, wherein determining the first action corresponding to the domain name comprises determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be allowed. Section 41 41. The ID-based DNS routing method of clause 40, wherein the unencrypted DNS query response comprises an IP address of a server associated with the domain name in the unencrypted DNS query request. Section 42 42. The ID-based DNS routing method of any of clauses 27 to 41, wherein determining the first action corresponding to the domain name comprises determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be logged by a proxy server. Section 43 43. The ID-based DNS routing method of clause 42, wherein the unencrypted DNS query response comprises an IP address of the proxy server. Section 44 44. The ID-based DNS routing method of clause 43, wherein the unencrypted DNS query response is configured such that outgoing and incoming traffic to and from the IP address of a server associated with the domain name of the unencrypted DNS query request is routed through the proxy server. Section 45 45. The ID-based DNS routing method of clause 44, wherein the proxy server receives outgoing network traffic from the client device, the outgoing network traffic indicating a proxy IP address of the proxy server as a destination IP address and comprising data destined for a server associated with the domain name, and receives inbound network traffic from the server associated with the domain name comprising a response to the outgoing network traffic, logs network traffic based on domain match criteria of the domain name and corresponding actions performed on the domain name, wherein the network traffic comprises one or more of the outgoing network traffic and the inbound network traffic, and sends the inbound network traffic to the client device. Section 46 46. ​​The ID-based DNS routing method of any of clauses 42 to 45, wherein the proxy server prompts the client device to provide the identity information, and determines one or more network policies based on the identity information, the one or more network policies indicating traffic associated with potential security threats for which traffic should be logged and metadata to collect about the traffic associated with the potential security threats, collects the metadata for the traffic associated with the potential security threats, and transmits the metadata to the ID-based DNS routing platform. Section 47 47. The ID-based DNS routing method of any of clauses 27 to 46, wherein the network interface of the client device is pre-configured to send DNS requests to an IP address of the ID-based DNS routing platform. Section 48 48. The ID-based DNS routing method of clause 47, wherein the client device is pre-configured based on installation of an entity security profile on the client device, and the installation of the entity security profile on the client device causes the client device to send the DNS request to the IP address of the ID-based DNS routing platform. Section 49 49. The ID-based DNS routing method of any of clauses 27 to 48, wherein determining the security policy for the user comprises determining to apply one of a user-specific policy, an organization-level policy, or a default policy to the user. Section 50 50. The ID-based DNS routing method of any of clauses 27 to 49, wherein the one or more domain name filtering rules comprise a whitelist, a blacklist, and a watchlist, and each of the matching domain names is included in one of the whitelist, the blacklist, or the watchlist. Section 51 51. The ID-based DNS routing method of claim 50, wherein determining the first action to take on the domain name comprises identifying whether the domain name is listed on the whitelist, the blacklist, or the watchlist, and the first action is to block traffic to an IP address of the domain name if the domain name is listed on the blacklist, the first action is to log traffic to the IP address of the domain name if the domain name is listed on the watchlist, and the first action is to allow traffic to access the IP address of the domain name if the domain name is listed on the whitelist. Section 52 A system comprising one or more computing devices, the system configured to perform the method of any of clauses 27 to 51. Section 53 One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of one or more computing devices of a system, cause the system to perform the method of any of clauses 27 through 51. Section 54 1. A method for identity-based Domain Name System (DNS) routing for DNS queries with a security policy specific to an identified user, the method comprising: establishing a DNS session between an ID-based DNS routing platform and a client device using a DNS process; receiving a DNS query request during the establishment of the DNS session, the DNS query request comprising a request for an Internet Protocol (IP) address of a domain name, the DNS query request specifying the domain name and identity information corresponding to the DNS query request, the identity information indicating at least two identities corresponding to the DNS query request; determining an identity (ID) of a user of the client device based on the identity information; and determining a security policy specific to the user based on the ID of the user. the security policy comprises one or more global domain name filtering rules, each domain name filtering rule of the one or more global domain name filtering rules comprising a respective domain match criterion and a corresponding action to be taken for a matching domain name; using the one or more global domain name filtering rules, and based on the domain name in the DNS query request, determining a first action corresponding to the domain name in response to the DNS query request; and determining a DNS query response based on the first action corresponding to the domain name, wherein determining the DNS query response includes performing an upstream request to the IP address of the domain name to identify the IP address of the domain name; and sending the DNS query response to the client device. Section 55 55. The ID-based DNS routing method of clause 54, wherein the DNS process comprises an encrypted DNS process configured to identify the requested IP address based on receiving the request for the IP address for the domain name. Section 56 55. The ID-based DNS routing method of clause 54, wherein the DNS process comprises an unencrypted DNS process configured to identify the requested IP address based on receiving the request for the IP address of the domain name. Section 57 57. The ID-based DNS routing method of any of clauses 54 to 56, wherein the DNS query request is received from the client device, and at least two IDs corresponding to the DNS query request correspond to the client device. Section 58 58. The ID-based DNS routing method of clause 57, wherein the at least two IDs comprise two or more of a user ID, a device ID, a browser ID, an application ID, an operating system ID, or a software ID. Section 59 59. The ID-based DNS routing method of any of clauses 54 to 58, wherein the DNS query request is routed between the ID-based DNS routing platform and the client device through an additional server. Section 60 60. The ID-based DNS routing method of clause 59, wherein a first ID of the at least two IDs is embedded by the client device and a second ID of the at least two IDs is embedded by the additional server. Section 61 60. The ID-based DNS routing method of clause 59, wherein the additional server is configured to remove at least a portion of the identity information received from the client device. Section 62 60. The ID-based DNS routing method of clause 59, wherein the additional server is configured to modify at least a portion of the identity information received from the client device. Section 63 60. The ID-based DNS routing method of claim 59, wherein the additional server is configured to embed the identity information in its entirety. Section 64 60. The ID-based DNS routing method of any of clauses 54 to 59, wherein the at least two IDs are embedded in the DNS query request as URL prefixes. Section 65 60. The ID-based DNS routing method of any of clauses 54 to 59, wherein a first ID of the at least two IDs corresponds to a first domain name filtering rule and a second ID of the at least two IDs corresponds to a second domain name filtering rule. Section 66 66. The ID-based DNS routing method of clause 65, wherein determining the one or more overall domain name filtering rules comprises adding the first domain name filtering rule to the second domain name filtering rule. Section 67 67. The ID-based DNS routing method of clause 66, wherein the first domain name filtering rule conflicts with the second domain name filtering rule. Section 68 68. The ID-based DNS routing method of clause 67, wherein determining the one or more overall domain name filtering rules comprises adjusting the first domain name filtering rule and the second domain name filtering rule, the adjusting being done by: identifying a conflict between a first rule of the first domain name filtering rules and a second rule of the first domain name filtering rules; comparing a priority score of the first rule with a priority score of the second rule; determining, based on the comparison of the priority scores, that the priority score of the first rule exceeds the priority score of the second rule; and selecting the first rule rather than the second rule for inclusion in the one or more overall domain name filtering rules based on the determination that the priority score of the first rule exceeds the priority score of the second rule, wherein the one or more overall domain name filtering rules include the first domain name filtering rule and all remaining domain name filtering rules of the second domain name filtering rules. Section 69 69. The ID-based DNS routing method of any of clauses 54 to 68, wherein determining a DNS query response based on the first action corresponding to the domain name comprises forwarding the DNS query request upstream to one or more servers on a DNS path. Section 70 70. The ID-based DNS routing method of claim 69, further comprising: identifying a threat context for the one or more servers; and modifying the DNS path based on the identified threat context. Section 71 71. The ID-based DNS routing method of clause 70, wherein the DNS query response indicates an IP address of a second ID-based DNS routing platform, and the DNS query response configures the client device to route future DNS query requests to the second ID-based DNS routing platform instead of the ID-based DNS routing platform. Section 72 72. The ID-based DNS routing method of clause 71, wherein configuring the client device to route future DNS query requests to the second ID-based DNS routing platform comprises configuring the client device to route future DNS query requests to the second ID-based DNS routing platform for a predetermined period of time. Section 73 72. The ID-based DNS routing method of clause 71, wherein the ID-based DNS routing platform is located in a first geographic region and the second ID-based DNS routing platform is located in a second geographic region different from the first geographic region. Section 74 74. The ID-based DNS routing method of any of clauses 54 to 73, further comprising: identifying the domain name as being on a watchlist; and replacing a first time to live (TTL) of the requested IP address with a second TTL of the requested IP address, wherein the first TTL is preset for the requested IP address and the second TTL is shorter than the first TTL. Section 75 75. The ID-based DNS routing method of any of clauses 54 to 74, wherein determining the security policy based on the identity of the user comprises identifying the security policy based on a stored correlation between the identity and the security policy. Section 76 76. The ID-based DNS routing method of claim 75, wherein the intelligence policy manager system pre-populates a cache of the ID-based DNS routing platform to include the stored correlation between the ID and the security policy. Section 77 77. The ID-based DNS routing method of clause 76, wherein the pre-population is based on one of a geographic location of the client device or a request to perform the pre-population. Section 78 78. The ID-based DNS routing method of any of clauses 54 to 77, wherein the DNS query response comprises an IP address of a proxy server, and outgoing traffic to and incoming traffic from an IP address of a server associated with a domain name of the DNS query request is configured to be logged by the proxy server, and the first action comprises logging the outgoing traffic and the incoming traffic by the proxy server. Section 79 79. The ID-based DNS routing method of any of clauses 54 to 78, wherein the DNS query response comprises the requested IP address and routing instructions instructing the client device to route traffic to the requested IP address through a gateway server, and the first action comprises logging outgoing and incoming traffic by the gateway server. Section 80 80. The ID-based DNS routing method of any of clauses 54 to 79, wherein the DNS query response comprises the requested IP address and a local rule indicating the first action corresponding to the domain name, the first action comprising one of blocking traffic directed to the requested IP address, allowing traffic directed to the requested IP address, and logging traffic directed to the requested IP address, and the client device is configured to enforce the local rule. Section 81 A system comprising one or more computing devices, the system configured to perform the method of any of clauses 54 to 80. Section 82 One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of one or more computing devices of a system, cause the system to perform the method of any of clauses 54 to 80. Section 83 1. A method for identity-based Domain Name System (DNS) routing for DNS queries with a security policy specific to an identified user, the method comprising: establishing a DNS session between an ID-based DNS routing platform and a client device using a DNS process; receiving a DNS query request during the establishment of the DNS session, the DNS query request comprising a request for an Internet Protocol (IP) address of a domain name, the DNS query request specifying the domain name and identity information corresponding to the DNS query request, the identity information indicating at least two identities corresponding to the DNS query request; determining an identity (ID) of a user of the client device based on the identity information; and determining a security policy specific to the user based on the ID of the user, the security policy being based on one or more global domain name filtering rules. and a first domain name filtering rule, each of the one or more global domain name filtering rules comprising a respective domain match criterion and a corresponding action to be taken for a matching domain name; using the one or more global domain name filtering rules to determine, based on the domain name in the DNS query request, that the domain name matches a first domain name rule indicating that traffic to the matching domain should be logged by a proxy server; and based on the determination that the matching domain should be logged by the proxy server, determine a DNS query response, the DNS query response comprising an IP address of the proxy server, wherein outgoing traffic to and incoming traffic from the IP address of a server associated with the domain name of the DNS query request is configured to be routed through the proxy server; and sending the DNS query response to the client device. Section 84 84. The ID-based DNS routing method of clause 83, wherein the proxy server receives outgoing network traffic from the client device, the outgoing network traffic indicating a proxy IP address of the proxy server as a destination IP address and comprising data destined for a server associated with the domain name, and receives inbound network traffic from the server associated with the domain name comprising a response to the outgoing network traffic, logs the network traffic based on domain match criteria of the domain name and corresponding actions performed on the domain name, wherein the network traffic comprises one or more of the outgoing network traffic and the inbound network traffic, and sends the inbound network traffic to the client device. Section 85 85. A system comprising one or more computing devices, the system configured to perform the method of any of clauses 83-84. Section 86 One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of one or more computing devices of a system, cause the system to perform the method of any of clauses 83-84. Section 87 1. A method for identity-based Domain Name System (DNS) routing for DNS queries with a security policy specific to an identified user, the method comprising: establishing a DNS session between an ID-based DNS routing platform and a client device using a DNS process; receiving, during the DNS session establishment, a DNS query request comprising a request for an Internet Protocol (IP) address of a domain name, the DNS query request specifying the domain name and identity information corresponding to the DNS query request, the identity information indicating at least two identities corresponding to the DNS query request; determining an identity (ID) of a user of the client device based on the identity information; and determining a security policy specific to the user based on the ID of the user, the security policy comprising one or more global domain name filtering rules, the one or more global domain name filtering rules using the one or more global domain name filtering rules to determine, based on the domain name in the DNS query request, that the domain name matches a first domain name rule indicating that traffic to the matching domain should be logged by a gateway server; and determining a DNS query response based on the determination that the traffic to the matching domain should be logged by the gateway server, the DNS query response comprising the requested IP address and routing instructions instructing the client device to route traffic to the requested IP address via the gateway server, wherein determining the DNS query response includes performing a request to the IP address of the domain name upstream to identify the requested IP address; and sending the DNS query response to the client device;A method comprising: Section 88 88. The ID-based DNS routing method of clause 87, wherein the DNS query response is configured such that outgoing and incoming traffic to and from the requested IP address is routed through the gateway server. Section 89 89. The ID-based DNS routing method of any of clauses 87 to 88, wherein the gateway server receives outgoing network traffic from the client device, the outgoing network traffic indicating the requested IP address as a destination IP address and comprising data destined for a server associated with the domain name, and receives inbound network traffic from the server associated with the domain name comprising a response to the outgoing network traffic, and logs the network traffic based on domain match criteria of the domain name and corresponding actions performed on the domain name, wherein the network traffic comprises one or more of the outgoing network traffic and the inbound network traffic, and sends the inbound network traffic to the client device. Section 90 90. A system comprising one or more computing devices, the system configured to perform the method of any of clauses 87 to 89. Section 91 One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of one or more computing devices of a system, cause the system to perform the method of any of clauses 87 to 89. Section 92 1. A method for identity-based Domain Name System (DNS) routing for DNS queries with a security policy specific to an identified user, the method comprising: establishing a DNS session between an ID-based DNS routing platform and a client device using a DNS process; receiving, during the DNS session establishment, a DNS query request comprising a request for an Internet Protocol (IP) address of a domain name, the DNS query request specifying the domain name and identity information corresponding to the DNS query request, the identity information indicating at least two identities corresponding to the DNS query request; determining an identity (ID) of a user of the client device based on the identity information; and determining a security policy specific to the user based on the ID of the user, the security policy comprising one or more global domain name filtering rules, the one or more global domain names being filtered by the ID-based DNS routing platform; 11. The method of claim 10, wherein each domain name filtering rule of a filtering rule comprises a respective domain match criterion and a corresponding action to be taken for a matching domain name; and wherein the method uses the one or more global domain name filtering rules to determine, based on the domain name in the DNS query request, a first action corresponding to the domain name in response to the DNS query request; and determines a DNS query response based on the first action corresponding to the domain name, the DNS query response comprising the requested IP address and a local rule indicating the first action corresponding to the domain name; determining the encrypted DNS query response includes performing an upstream request to the IP address of the domain name to identify the requested IP address; and sending the DNS query response to the client device, wherein the DNS query response configures the client device to enforce the local rule against traffic directed to the requested IP address. Section 93 93. The ID-based DNS routing method of clause 92, wherein the local rules indicate whether the traffic directed to the requested IP address should be blocked, allowed, or logged. Section 94 94. The ID-based DNS routing method of any of clauses 92 to 93, wherein the client device is configured to receive the local rule indicating the first action corresponding to the domain name and store the local rule indicating the first action corresponding to the domain name. Section 95 A system comprising one or more computing devices, the system configured to perform the method of any of clauses 92 to 94. Section 96 One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of one or more computing devices of a system, cause the system to perform the method of any of clauses 92 to 94.

[0208] Aspects of the present disclosure have been described in terms of exemplary embodiments thereof. Numerous other embodiments, modifications, and variations within the scope and spirit of the appended claims will occur to those skilled in the art from a review of this disclosure. For example, one or more of the steps depicted in the exemplary diagrams may be performed out of the order described, and one or more of the depicted steps may be optional, in accordance with aspects of the disclosure.

Claims

1. 1. A method for identity-based Domain Name System (DNS) routing for DNS queries with security policies specific to identified users, the method comprising: Establishing a secure DNS session using an encrypted DNS process, wherein establishing the secure DNS session comprises performing an encrypted session handshake between an ID-based DNS routing platform and a client device, wherein performing the encrypted session handshake includes receiving, from the client device, an encrypted DNS process security credential that identifies a user of the client device; receiving, while the secure DNS session is established, from the client device an encrypted DNS query request comprising a request for an Internet Protocol (IP) address of a domain name, the encrypted DNS query request specifying the domain name; determining an identity (ID) of the user based on the security credentials; determining a security policy specific to the user based on the identity of the user, the security policy comprising one or more domain name filtering rules, each domain name filtering rule comprising a respective domain match criterion and a corresponding action to be taken for a matching domain name; determining, based on the domain name in the encrypted DNS query request, a first action corresponding to the domain name in response to the encrypted DNS query request using the one or more domain name filtering rules; determining an encrypted DNS query response based on the first action corresponding to the domain name, wherein determining the encrypted DNS query response includes performing an upstream request to the IP address of the domain name to identify the IP address of the domain name; sending the encrypted DNS query response to the client device.

2. 2. The ID-based DNS routing method of claim 1, wherein the security policy is user-specific based on an organization associated with the user of the client device, and the encrypted DNS query request is received from the client device while the client device is transmitting the encrypted DNS query request from outside a protected network of the organization.

3. 2. The ID-based DNS routing method of claim 1, wherein the corresponding action taken for the matching domain names indicates whether traffic should be blocked, allowed, or logged for each of the matching domain names.

4. The determination of the first action corresponding to the domain name includes:

2. The ID-based DNS routing method of claim 1, comprising determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be blocked.

5. The ID-based DNS routing method of claim 4 , wherein the encrypted DNS query response comprises an IP address of a block notification page.

6. The ID-based DNS routing method of claim 4 , wherein the encrypted DNS query response comprises a notification that the requested IP address has been blocked.

7. The determination of the first action corresponding to the domain name includes:

2. The ID-based DNS routing method of claim 1, comprising determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be allowed.

8. 8. The ID-based DNS routing method of claim 7, wherein the encrypted DNS query response comprises an IP address of a server associated with the domain name in the encrypted DNS query request.

9. The determination of the first action corresponding to the domain name includes:

2. The ID-based DNS routing method of claim 1, comprising: determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be logged by a proxy server.

10. 10. The ID-based DNS routing method of claim 9, wherein the encrypted DNS query response comprises an IP address of the proxy server.

11. 11. The ID-based DNS routing method of claim 10, wherein the encrypted DNS query response is configured such that outgoing and incoming traffic to and from the IP address of a server associated with the domain name of the encrypted DNS query request is routed through the proxy server.

12. The proxy server receiving outgoing network traffic from the client device, the outgoing network traffic comprising: indicating the proxy IP address of the proxy server as a destination IP address; data addressed to a server associated with the domain name; receiving inbound network traffic from the server associated with the domain name, the inbound network traffic comprising a response to the outgoing network traffic; logging network traffic based on a domain match criterion of the domain name and a corresponding action performed on the domain name, wherein the network traffic comprises one or more of the outgoing network traffic and the inbound network traffic; The ID-based DNS routing method of claim 11 , further comprising sending the inbound network traffic to the client device.

13. The proxy server prompting the client device to provide the security certificate; determining one or more network policies based on the security credentials; the one or more network policies: Traffic associated with potential security threats that should be logged, and metadata collected about traffic associated with the potential security threat; collecting the metadata of the traffic associated with the potential security threat; The ID-based DNS routing method of claim 9 , further comprising transmitting the metadata to the ID-based DNS routing platform.

14. 2. The ID-based DNS routing method of claim 1, wherein a network interface of the client device is pre-configured to send a DNS request to an IP address of the ID-based DNS routing platform, and the security certificate is installed on the client device before receiving the encrypted DNS query request.

15. 15. The ID-based DNS routing method of claim 14, wherein the client device is pre-configured based on installation of an entity security profile on the client device, and the installation of the entity security profile on the client device causes the client device to send the DNS request to the IP address of the ID-based DNS routing platform.

16. 2. The ID-based DNS routing method of claim 1, wherein determining the security policy for the user comprises determining to apply one of a user-specific policy, an organization-level policy, or a default policy to the user.

17. 2. The ID-based DNS routing method of claim 1, wherein the one or more domain name filtering rules comprise a whitelist, a blacklist, and a watchlist, and wherein each of the matching domain names is included in one of the whitelist, the blacklist, or the watchlist.

18. Determining the first action to be performed on the domain name includes: identifying whether the domain name is listed on the whitelist, the blacklist, or the watchlist; the first action is to block traffic to an IP address of the domain name if the domain name is on the blacklist; the first action is to log traffic to the IP address of the domain name if the domain name is on the watchlist; 20. The ID-based DNS routing method of claim 17, wherein the first action is to allow traffic to access the IP address of the domain name if the domain name is listed on the whitelist.

19. The ID-based DNS routing method of claim 1 , wherein the encrypted session handshake comprises a Transport Layer Security (TLS) handshake.

20. The ID-based DNS routing method of claim 1 , wherein determining the identity of the user further comprises determining the identity of the user based on at least a first identity and a second identity.

21. 21. The ID-based DNS routing method of claim 20, wherein the first ID and the second ID are embedded in the encrypted DNS query request at the client device.

22. 21. The ID-based DNS routing method of claim 20, wherein the first encrypted DNS query request is routed from the client device to the ID-based DNS routing platform along a DNS path, wherein the DNS path may be a path of the first encrypted DNS query request that recurses through different DNS servers to build a response back to the client device.

23. 23. The ID-based DNS routing method of claim 22, wherein the first ID is embedded in the encrypted DNS query request at the client device and the second ID is embedded in the encrypted DNS query request at an intermediate server on the DNS path.

24. 21. The ID-based DNS routing method of claim 20, wherein the first ID corresponds to a first domain name filtering rule, the second ID corresponds to a second domain name filtering rule, and the determining of the security policy comprises resolving a conflict between the first domain name filtering rule and the second domain name filtering rule.

25. 25. A system comprising one or more computing devices, the system configured to perform the method of any of claims 1 to 24.

26. One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of one or more computing devices of a system, cause the system to perform the method of any of claims 1 to 24.

27. 1. A method for identity-based Domain Name System (DNS) routing for DNS queries with security policies specific to identified users, the method comprising: Establishing a DNS session between an ID-based DNS routing platform and a client device using an unencrypted DNS process; receiving, while the DNS session is established, from the client device, an unencrypted DNS query request comprising a request for an Internet Protocol (IP) address of a domain name, the unencrypted DNS query request specifying the domain name; determining an identity (ID) of the user based on identity information embedded in the unencrypted DNS query request; determining a security policy specific to the user based on the identity of the user, the security policy comprising one or more domain name filtering rules, each domain name filtering rule comprising a respective domain match criterion and a corresponding action to be taken for a matching domain name; determining, based on the domain name in the unencrypted DNS query request, a first action corresponding to the domain name in response to the unencrypted DNS query request using the one or more domain name filtering rules; determining an unencrypted DNS query response based on the first action corresponding to the domain name, wherein determining the unencrypted DNS query response includes performing an upstream request to the IP address of the domain name to identify the IP address of the domain name; sending the unencrypted DNS query response to the client device.

28. 28. The ID-based DNS routing method of claim 27, wherein the identity information is embedded using clear text in a field of the unencrypted DNS query request.

29. 28. The ID-based DNS routing method of claim 27, wherein the identity information is not encrypted.

30. 28. The ID-based DNS routing method of claim 27, wherein the identity information is encrypted.

31. 28. The ID-based DNS routing method of claim 27, wherein the identity information is encrypted by the client device.

32. 28. The ID-based DNS routing method of claim 27, wherein the identity information is encrypted by a local resolver, and the unencrypted DNS query request passes through the local resolver before being received in the unencrypted DNS query request.

33. The encryption of the identity information by the local resolver comprises: adding the identity of the local resolver to the identity information; 33. The ID-based DNS routing method of claim 32, comprising encrypting the identity information after adding the identity of the local resolver to the identity information.

34. The encryption of the identity information by the local resolver comprises: deleting a portion of the identity information; 33. The ID-based DNS routing method of claim 32, comprising encrypting the identity information after removing the portion of the identity information.

35. the security policy is user-specific based on an organization associated with the user of the client device; 28. The ID-based DNS routing method of claim 27, wherein the unencrypted DNS query request is received from the client device while the client device is sending the unencrypted DNS query request from outside the organization's protected network.

36. 28. The ID-based DNS routing method of claim 27, wherein the corresponding action taken for the matching domain names indicates whether traffic should be blocked, allowed, or logged for each of the matching domain names.

37. The determination of the first action corresponding to the domain name includes:

30. The ID-based DNS routing method of claim 27, comprising determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be blocked.

38. 38. The ID-based DNS routing method of claim 37, wherein the unencrypted DNS query response comprises an IP address of a block notification page.

39. 38. The ID-based DNS routing method of claim 37, wherein the unencrypted DNS query response comprises a notification that the requested IP address has been blocked.

40. The determination of the first action corresponding to the domain name includes:

30. The ID-based DNS routing method of claim 27, comprising determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be allowed.

41. 41. The ID-based DNS routing method of claim 40, wherein the unencrypted DNS query response comprises an IP address of a server associated with the domain name in the unencrypted DNS query request.

42. The determination of the first action corresponding to the domain name includes:

28. The ID-based DNS routing method of claim 27, comprising determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be logged by a proxy server.

43. 43. The ID-based DNS routing method of claim 42, wherein the unencrypted DNS query response comprises an IP address of the proxy server.

44. 44. The ID-based DNS routing method of claim 43, wherein the unencrypted DNS query response is configured such that outgoing and incoming traffic to and from the IP address of a server associated with the domain name of the unencrypted DNS query request is routed through the proxy server.

45. The proxy server receiving outgoing network traffic from the client device, the outgoing network traffic comprising: indicating the proxy IP address of the proxy server as a destination IP address; data addressed to a server associated with the domain name; receiving inbound network traffic from the server associated with the domain name, the inbound network traffic comprising a response to the outgoing network traffic; logging network traffic based on a domain match criterion of the domain name and a corresponding action performed on the domain name, wherein the network traffic comprises one or more of the outgoing network traffic and the inbound network traffic; 45. The ID-based DNS routing method of claim 44, further comprising sending the inbound network traffic to the client device.

46. The proxy server prompting the client device to provide the identity information; determining one or more network policies based on the identity information; the one or more network policies: Traffic associated with potential security threats that should be logged, and and collecting metadata about traffic associated with the potential security threat; collecting the metadata of the traffic associated with the potential security threat; 43. The ID-based DNS routing method of claim 42, further comprising transmitting the metadata to the ID-based DNS routing platform.

47. 28. The ID-based DNS routing method of claim 27, wherein the network interface of the client device is pre-configured to send DNS requests to an IP address of the ID-based DNS routing platform.

48. 48. The ID-based DNS routing method of claim 47, wherein the client device is pre-configured based on installation of an entity security profile on the client device, the installation of the entity security profile on the client device causing the client device to send the DNS request to the IP address of the ID-based DNS routing platform.

49. 30. The ID-based DNS routing method of claim 27, wherein determining the security policy for the user comprises determining to apply one of a user-specific policy, an organization-level policy, or a default policy to the user.

50. 28. The ID-based DNS routing method of claim 27, wherein the one or more domain name filtering rules comprise a whitelist, a blacklist, and a watchlist, and wherein each of the matching domain names is included in one of the whitelist, the blacklist, or the watchlist.

51. Determining the first action to be performed on the domain name includes: identifying whether the domain name is listed on the whitelist, the blacklist, or the watchlist; the first action is to block traffic to an IP address of the domain name if the domain name is on the blacklist; the first action is to log traffic to the IP address of the domain name if the domain name is on the watchlist; 51. The ID-based DNS routing method of claim 50, wherein the first action is to allow traffic to access the IP address of the domain name if the domain name is listed on the whitelist.

52. 52. A system comprising one or more computing devices, the system configured to perform the method of any of claims 27 to 51.

53. One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of one or more computing devices of a system, cause the system to perform the method of any of claims 27 to 51.

54. 1. A method for identity-based Domain Name System (DNS) routing for DNS queries with security policies specific to identified users, the method comprising: Establishing a DNS session between the ID-based DNS routing platform and the client device using a DNS process; receiving, while the DNS session is established, a DNS query request comprising a request for an Internet Protocol (IP) address of a domain name, the DNS query request specifying the domain name and identity information corresponding to the DNS query request, the identity information indicating at least two identities corresponding to the DNS query request; determining an identity (ID) of a user of the client device based on the identity information; determining a security policy specific to the user based on the identity of the user, the security policy comprising one or more global domain name filtering rules, each domain name filtering rule of the one or more global domain name filtering rules comprising a respective domain match criterion and a corresponding action to be taken for a matching domain name; determining, based on the domain name in the DNS query request, a first action corresponding to the domain name in response to the DNS query request using the one or more global domain name filtering rules; determining a DNS query response based on the first action corresponding to the domain name, wherein determining the DNS query response includes performing an upstream request to the IP address of the domain name to identify the IP address of the domain name; sending the DNS query response to the client device.

55. 55. The ID-based DNS routing method of claim 54, wherein the DNS process comprises an encrypted DNS process configured to identify the requested IP address based on receiving the request for the IP address of the domain name.

56. 55. The ID-based DNS routing method of claim 54, wherein the DNS process comprises an unencrypted DNS process configured to identify the requested IP address based on receiving the request for the IP address of the domain name.

57. 55. The ID-based DNS routing method of claim 54, wherein the DNS query request is received from the client device, and at least two IDs corresponding to the DNS query request correspond to the client device.

58. 58. The ID-based DNS routing method of claim 57, wherein the at least two IDs comprise two or more of a user ID, a device ID, a browser ID, an application ID, an operating system ID, or a software ID.

59. 55. The ID-based DNS routing method of claim 54, wherein the DNS query request is routed between the ID-based DNS routing platform and the client device through an additional server.

60. 60. The ID-based DNS routing method of claim 59, wherein a first ID of the at least two IDs is embedded by the client device and a second ID of the at least two IDs is embedded by the additional server.

61. 60. The ID-based DNS routing method of claim 59, wherein the additional server is configured to remove at least a portion of the identity information received from the client device.

62. 60. The ID-based DNS routing method of claim 59, wherein the additional server is configured to modify at least a portion of the identity information received from the client device.

63. 60. The ID-based DNS routing method of claim 59, wherein the additional server is configured to embed the identity information in its entirety.

64. 55. The ID-based DNS routing method of claim 54, wherein the at least two IDs are embedded in the DNS query request as URL prefixes.

65. 55. The ID-based DNS routing method of claim 54, wherein a first ID of the at least two IDs corresponds to a first domain name filtering rule, and a second ID of the at least two IDs corresponds to a second domain name filtering rule.

66. 66. The ID-based DNS routing method of claim 65, wherein determining the one or more overall domain name filtering rules comprises adding the first domain name filtering rule to the second domain name filtering rule.

67. 67. The ID-based DNS routing method of claim 66, wherein the first domain name filtering rule conflicts with the second domain name filtering rule.

68. determining the one or more overall domain name filtering rules comprises an adjustment of the first domain name filtering rule and the second domain name filtering rule, the adjustment comprising: Identifying a conflict between a first rule of the first domain name filtering rules and a second rule of the first domain name filtering rules; comparing a priority score of the first rule with a priority score of the second rule; determining, based on the comparison of the priority scores, that the priority score of the first rule exceeds the priority score of the second rule; selecting the first rule rather than the second rule for inclusion in the one or more global domain name filtering rules based on identifying the precedence score of the first rule being greater than the precedence score of the second rule; 68. The ID-based DNS routing method of claim 67, wherein the one or more overall domain name filtering rules include all remaining domain name filtering rules of the first domain name filtering rule and the second domain name filtering rule.

69. 55. The ID-based DNS routing method of claim 54, wherein determining a DNS query response based on the first action corresponding to the domain name comprises forwarding the DNS query request upstream to one or more servers on a DNS path.

70. identifying a threat context of the one or more servers; 70. The ID-based DNS routing method of claim 69, further comprising: modifying the DNS path based on the identified threat context.

71. 71. The ID-based DNS routing method of claim 70, wherein the DNS query response indicates an IP address of a second ID-based DNS routing platform, and wherein the DNS query response configures the client device to route future DNS query requests to the second ID-based DNS routing platform instead of the ID-based DNS routing platform.

72. Configuring the client device to route the future DNS query requests to the second ID-based DNS routing platform includes:

72. The ID-based DNS routing method of claim 71, comprising configuring the client device to route the future DNS query requests to the second ID-based DNS routing platform for a predetermined period of time.

73. 72. The ID-based DNS routing method of claim 71, wherein the ID-based DNS routing platform is located in a first geographic region and the second ID-based DNS routing platform is located in a second geographic region different from the first geographic region.

74. identifying the domain name as being on a watchlist; replacing a first time to live (TTL) of the requested IP address with a second TTL of the requested IP address; 55. The ID-based DNS routing method of claim 54, wherein the first TTL is preset for the requested IP address, and the second TTL is shorter than the first TTL.

75. 55. The ID-based DNS routing method of claim 54, wherein determining the security policy based on the identity of the user comprises identifying the security policy based on a stored correlation between the identity and the security policy.

76. 76. The ID-based DNS routing method of claim 75, wherein an intelligence policy manager system pre-populates a cache of the ID-based DNS routing platform to include the stored correlation between the ID and the security policy.

77. 77. The ID-based DNS routing method of claim 76, wherein the pre-population is based on one of a geographic location of the client device or a request to perform the pre-population.

78. the DNS query response: The IP address of the proxy server is provided.

55. The ID-based DNS routing method of claim 54, wherein outgoing traffic to and incoming traffic from an IP address of a server associated with a domain name of the DNS query request is configured to be acted upon by the proxy server, and the first action comprises logging the outgoing traffic and the incoming traffic by the proxy server.

79. the DNS query response: the requested IP address; and routing instructions that instruct the client device to route traffic to the requested IP address through a gateway server; 55. The ID-based DNS routing method of claim 54, wherein the first action comprises logging, by the gateway server, outgoing and incoming traffic.

80. the DNS query response: the requested IP address; and a local rule indicating the first action corresponding to the domain name, wherein the first action is Blocking traffic directed to the requested IP address; Allowing traffic directed to the requested IP address; and 55. The ID-based DNS routing method of claim 54, further comprising one of: logging traffic directed to the requested IP address, wherein the client device is configured to enforce the local rule.

81. 81. A system comprising one or more computing devices, the system configured to perform the method of any of claims 54 to 80.

82. One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of one or more computing devices of a system, cause the system to perform the method of any of claims 54 to 80.

83. 1. A method for identity-based Domain Name System (DNS) routing for DNS queries with security policies specific to identified users, the method comprising: Establishing a DNS session between the ID-based DNS routing platform and the client device using a DNS process; receiving, while the DNS session is established, a DNS query request comprising a request for an Internet Protocol (IP) address of a domain name, the DNS query request specifying the domain name and identity information corresponding to the DNS query request, the identity information indicating at least two identities corresponding to the DNS query request; determining an identity (ID) of a user of the client device based on the identity information; determining a security policy specific to the user based on the identity of the user, the security policy comprising one or more global domain name filtering rules, each domain name filtering rule of the one or more global domain name filtering rules comprising a respective domain match criterion and a corresponding action to be taken for a matching domain name; using the one or more global domain name filtering rules, determining, based on the domain name in the DNS query request, that the domain name matches a first domain name rule indicating that traffic to the matching domain should be logged by a proxy server; determining a DNS query response based on the determination that a matching domain should be logged by the proxy server, the DNS query response comprising: an IP address of the proxy server; configured to route outgoing and incoming traffic to and from the IP address of a server associated with the domain name of the DNS query request through the proxy server; sending the DNS query response to the client device.

84. The proxy server receiving outgoing network traffic from the client device, the outgoing network traffic comprising: indicating the proxy IP address of the proxy server as a destination IP address; data addressed to a server associated with the domain name; receiving inbound network traffic from the server associated with the domain name, the inbound network traffic comprising a response to the outgoing network traffic; logging network traffic based on a domain match criterion of the domain name and a corresponding action performed on the domain name, wherein the network traffic comprises one or more of the outgoing network traffic and the inbound network traffic; 84. The ID-based DNS routing method of claim 83, further comprising sending the inbound network traffic to the client device.

85. 85. A system comprising one or more computing devices, said system configured to perform the method of any of claims 83-84.

86. One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of one or more computing devices of a system, cause the system to perform the method of any of claims 83-84.

87. 1. A method for identity-based Domain Name System (DNS) routing for DNS queries with security policies specific to identified users, the method comprising: Establishing a DNS session between the ID-based DNS routing platform and the client device using a DNS process; receiving, while the DNS session is established, a DNS query request comprising a request for an Internet Protocol (IP) address of a domain name, the DNS query request specifying the domain name and identity information corresponding to the DNS query request, the identity information indicating at least two identities corresponding to the DNS query request; determining an identity (ID) of a user of the client device based on the identity information; determining a security policy specific to the user based on the identity of the user, the security policy comprising one or more global domain name filtering rules, each domain name filtering rule of the one or more global domain name filtering rules comprising a respective domain match criterion and a corresponding action to be taken for a matching domain name; using the one or more global domain name filtering rules, and determining, based on the domain name in the DNS query request, that the domain name matches a first domain name rule indicating that traffic to the matching domain should be logged by a gateway server; determining a DNS query response based on the determination that the traffic to the matching domain should be logged by the gateway server, the DNS query response comprising: the requested IP address; and routing instructions instructing the client device to route traffic to the requested IP address through the gateway server, wherein determining the DNS query response includes performing a request for the IP address of the domain name upstream to identify the requested IP address; sending the DNS query response to the client device.

88. 88. The ID-based DNS routing method of claim 87, wherein the DNS query response is configured such that outgoing and incoming traffic to and from the requested IP address is routed through the gateway server.

89. The gateway server receiving outgoing network traffic from the client device, the outgoing network traffic comprising: indicating the requested IP address as a destination IP address; data addressed to a server associated with the domain name; receiving inbound network traffic from the server associated with the domain name, the inbound network traffic comprising a response to the outgoing network traffic; logging network traffic based on a domain match criterion of the domain name and a corresponding action performed on the domain name, wherein the network traffic comprises one or more of the outgoing network traffic and the inbound network traffic; 88. The ID-based DNS routing method of claim 87, further comprising sending the inbound network traffic to the client device.

90. 90. A system comprising one or more computing devices, said system configured to perform the method of any of claims 87 to 89.

91. One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of one or more computing devices of a system, cause the system to perform the method of any of claims 87 to 89.

92. 1. A method for identity-based Domain Name System (DNS) routing for DNS queries with security policies specific to identified users, the method comprising: Establishing a DNS session between the ID-based DNS routing platform and the client device using a DNS process; receiving, while the DNS session is established, a DNS query request comprising a request for an Internet Protocol (IP) address of a domain name, the DNS query request specifying the domain name and identity information corresponding to the DNS query request, the identity information indicating at least two identities corresponding to the DNS query request; determining an identity (ID) of a user of the client device based on the identity information; determining a security policy specific to the user based on the identity of the user, the security policy comprising one or more global domain name filtering rules, each domain name filtering rule of the one or more global domain name filtering rules comprising a respective domain match criterion and a corresponding action to be taken for a matching domain name; determining, based on the domain name in the DNS query request, a first action corresponding to the domain name in response to the DNS query request using the one or more global domain name filtering rules; determining a DNS query response based on the first action corresponding to the domain name, the DNS query response comprising: the requested IP address; and a local rule indicating the first action corresponding to the domain name, wherein determining the encrypted DNS query response includes performing an upstream request to the IP address of the domain name to identify the requested IP address; sending the DNS query response to the client device; The DNS query response configures the client device to enforce the local rules on traffic directed to the requested IP address.

93. 93. The ID-based DNS routing method of claim 92, wherein the local rules indicate whether the traffic directed to the requested IP address should be blocked, allowed, or logged.

94. The client device receiving the local rule indicating the first action corresponding to the domain name; 93. The ID-based DNS routing method of claim 92, further configured to store the local rule indicating the first action corresponding to the domain name.

95. 95. A system comprising one or more computing devices, said system configured to perform the method of any of claims 92 to 94.

96. One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of one or more computing devices of a system, cause the system to perform the method of any of claims 92 to 94.

Images