Identity-based application of domain filtering rules using domain name system (DNS) platform

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, which may include receiving security credentials identifying a user of the client device for the encrypted DNS process. The computing platform may receive an encrypted DNS query request including a request for an IP address specifying a domain name. The computing platform may determine an identity of the user based on the security credentials. The computing platform may determine, based on the identity of the user, a security policy indicating a domain matching criterion and a corresponding action to take on the matched domain name. The computing platform may determine a first action corresponding to the domain name and may send an encrypted DNS query response based on the first action.

Description

[0001] Cross - Reference to Related Applications

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

[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 cases, DNS policies and / or other threat intelligence can be enforced on a protected network (e.g., an enterprise network) that can be accessed, for example, from a specific location (e.g., an enterprise's office). However, in some cases, an individual can access the enterprise network from a remote location and it may not be possible to enforce such DNS policies. As remote access becomes more prevalent, it may be important to improve the threat intelligence deployed at such remote devices.

[0004] In some cases, encrypted DNS (e.g., as 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, DNS based on Transport Layer Security (TLS) can be used to secure the communication. TLS-based DNS can include embedding DNS messages into 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 these cases, the client device can notify its TLS capabilities to the DNS server, and the DNS server can respond to confirm the TLS parameters that can be used to secure the TLS channel. For example, the DNS server can send a certificate identifying the DNS server and a message including a digital signature of the DNS server, which can be verified by the client device (e.g., by checking a list of trusted authorities, public key pinning, and / or other methods). Once the handshake is complete, the client device and the DNS server can exchange encrypted messages (e.g., DNS query requests, DNS query responses, and / or other information). In these cases, a public DNS server can be shared among multiple client devices, and a common or other public DNS policy can be applied among these devices. As encrypted DNS is increasingly adopted, it may be important to improve or otherwise refine the application of DNS policies. Summary of the Invention

[0005] Aspects of the present disclosure provide effective, efficient, scalable, and convenient technical solutions that address and overcome technical problems associated with traffic routing and monitoring. According to one or more embodiments of the present disclosure, an identity-based DNS routing platform (the identity-based DNS routing platform being configured to apply security policies specific to the identified user to DNS queries and including at least one processor, a communication interface, and a memory storing computer-readable instructions) can use an encrypted DNS process to establish a secure DNS session, which can include performing an encrypted session handshake between the identity-based DNS routing platform and a client device, and wherein performing the encrypted session handshake can include receiving, from the client device, a security certificate identifying the user of the client device for the encrypted DNS process. The computing platform can receive, when establishing the secure DNS session and from the client device, an encrypted DNS query request including a request for an Internet Protocol (IP) address of a domain name, wherein the encrypted DNS query request specifies the domain name. The computing platform can determine the identity of the user based on the security certificate. The computing platform can determine a security policy specific to the user based on the identity of the user, wherein the security policy includes one or more domain name filtering rules, and each domain name filtering rule includes a corresponding domain matching criterion and a corresponding action to be taken for a matching domain name. The computing platform can use the one or more domain name filtering rules and determine a first action corresponding to the domain name based on the domain name in the encrypted DNS query request in response to the encrypted DNS query request. The computing platform can determine an encrypted DNS query response based on the first action corresponding to the domain name, wherein determining the encrypted DNS query response can further include performing an upstream request for 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 cases, the security policy is user-specific based on the organization associated with the user of the client device and can receive the encrypted DNS query request from the client device when the client device sends the encrypted DNS query request from outside the protected network of the organization. In one or more cases, the corresponding actions to be taken for the matching domain names can indicate whether traffic should be blocked, allowed, or logged for the respective domain names among the matching domain names.

[0007] In one or more cases, determining the first action corresponding to the domain name can 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 cases, the encrypted DNS query response can be the IP address of a block notification page.

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

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

[0010] In one or more cases, the encrypted DNS query response can be the IP address of the proxy server. In one or more cases, the encrypted DNS query response can be configured to conduct outgoing and incoming traffic to and from the IP address of a server associated with the domain name of the encrypted DNS query request via the proxy server.

[0011] In one or more cases, the proxy server can: 1) receive outgoing network traffic from the client device, where the outgoing network traffic: a) indicates the proxy IP address of the proxy server as the destination IP address, and b) includes data directed to a server associated with the domain name; 2) receive inbound network traffic including a response to the outgoing network traffic from the server associated with the domain name; 3) record network traffic including one or more of the following based on the domain matching criteria of the domain name and the corresponding action to be performed for the domain name: the outgoing network traffic and the inbound network traffic; and 4) send the inbound network traffic to the client device.

[0012] In one or more cases, the proxy server can: 1) prompt the client device to provide the security certificate; 2) determine one or more network policies based on the security certificate, where the one or more network policies indicate: a) traffic associated with a potential security threat for which traffic should be recorded, and b) metadata to be collected for traffic associated with the potential security threat; 3) collect metadata for traffic associated with the potential security threat; and 4) send the metadata to the identity-based DNS routing platform.

[0013] In one or more cases, the network interface of the client device is preconfigured to direct DNS requests to the IP address of the identity-based DNS routing platform, and the security certificate can be installed at the client device before receiving the encrypted DNS query request. In one or more cases, the client device can be preconfigured based on the installation of an enterprise security profile on the client device, and the installation of the enterprise security profile on the client device can cause the client device to direct these DNS requests to the IP address of the identity-based DNS routing platform. In one or more cases, determining the security policy for the user can include determining to apply one of the following to the user: a user-specific policy, an organization-level policy, or a default policy. In one or more cases, the one or more domain name filtering rules can include 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.

[0014] In one or more cases, determining the first action to be performed on the domain name can include identifying whether the domain name is listed on the whitelist, the blacklist, or the watchlist, where: 1) when the domain name is listed on the blacklist, the first action is to block traffic to the IP address of the domain name; 2) when the domain name is listed on the watchlist, the first action is to record traffic to the IP address of the domain name; and 3) when the domain name is listed on the whitelist, the first action is to allow traffic to the IP address of the domain name. In one or more cases, the encrypted session handshake can be a Transport Layer Security (TLS) handshake.

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

[0016] In one or more cases, the first encrypted DNS query request can be routed along a DNS path from the client device to the identity-based DNS routing platform, where the DNS path can be the path that the first encrypted DNS query request takes as it recurses through different DNS servers to formulate a response back to the client device. In one or more cases, the first identity can be embedded in the encrypted DNS query request at the client device, and the second identity can be embedded in the encrypted DNS query request at an intermediate server along the DNS path. In one or more cases, the first identity can correspond to a first domain name filtering rule and the second identity can correspond to a second domain name filtering rule, where determining the security policy can include resolving conflicts between the first domain name filtering rules and the second domain name filtering rules.

[0017] These features, as well as many others, are discussed in more detail below. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The present disclosure is illustrated by way of example and is not limited to the accompanying drawings, in which like reference numerals indicate like elements and in which:

[0019] Figures 1A to 1C An illustrative computing environment configured to provide improved traffic routing and monitoring in accordance with one or more example embodiments is depicted;

[0020] Figures 2A to 2K An illustrative sequence of events for improved traffic routing and monitoring in accordance with one or more example embodiments is depicted;

[0021] Figure 3 An illustrative method for improved traffic routing and monitoring in accordance with one or more example embodiments is depicted;

[0022] Figure 4 and Figure 5 An illustrative diagram for illustrating improved traffic routing and monitoring in accordance with one or more example embodiments is depicted; and

[0023] Figures 6A to 6D An illustrative sequence of events for improved traffic routing and monitoring in accordance with one or more example embodiments is depicted. DETAILED DESCRIPTION

[0024] In the following description of various illustrative embodiments, reference is made to the accompanying drawings which form a part hereof, and in which are 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 modifications may be made without departing from the scope of the present disclosure.

[0025] Note that various connections between components are discussed in the following description. Note that these connections are general and can be direct or indirect, wired or wireless unless otherwise specified, and the specification is not intended to be limiting in this regard.

[0026] As a brief introduction to the concepts further described herein, one or more aspects of the present disclosure relate to identity-based traffic routing and monitoring. For example, an individual may work from home or otherwise remotely from a physical location of an enterprise of which they may be an employee. In these cases, the individual may not have local access to the enterprise network but may operate on a home or other remote network. For example, an individual may work remotely and use a virtual private network (VPN) that can tunnel traffic through one or more corporate security devices. Multiple illustrative examples are highlighted below. In a first example, an employee may work from home and connect to the corporate network via their home router. In a second example, an employee may work from home and connect to the corporate network via a mobile / cellular network. In a third example, an employee may work at the employer's premises but may connect to the corporate network via public Wi-Fi or a mobile / cellular network. In a fourth example, an employee may work at a location outside the employer's premises (e.g., a coffee shop or other location) and may connect to the corporate network via public / commercial Wi-Fi or a mobile / cellular network. In a fifth example, an employee may work at the employer's premises and may connect directly to a private corporate network via Wi-Fi or a wired connection. In a sixth example, an employee may connect to the Internet in one of the scenarios described in the first through fourth examples and may use a VPN connection to the corporate network such that traffic (including DNS requests) can be routed partially or fully through the corporate network gateway. In a seventh example, an employee may connect to the Internet as described in one of the scenarios in the first through fourth examples but may not be able to connect to the corporate VPN. In an eighth example, an employee may connect from the same location using multiple devices (e.g., a phone, laptop, desktop computer, and / or other devices), but one or more of the devices may connect to the corporate network by different methods described in the first through fifth examples. 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 (such as personal profiles, work profiles, and / or other profiles) such that one VM or profile may connect in a different manner than another virtual machine or profile (e.g., a work profile that connects to the corporate VPN and a personal profile that connects directly to the Internet without a VPN).

[0027] As will be further described in more detail below with respect to the illustrative event sequence, in any or all of these cases, all traffic from the individual's devices can be routed through a corporate network gateway, which can be configured as a packet filtering device. For example, the gateway can have packet filtering rules and / or other network rules customized for the enterprise, which can be applied to the traffic.

[0028] However, in some cases, an individual may use one or more computing devices (e.g., mobile devices, etc.), virtual devices, profiles, applications (e.g., browsers, etc.), and / or systems / applications that may not always be connected to the enterprise network when performing work-related tasks to perform multiple work-related tasks and functions. Thus, traffic from the mobile device may not travel through the existing enterprise security devices (including packet filtering devices). Accordingly, in these cases, packet filtering and / or other network rules may not be applied to the traffic from the mobile device, potentially exposing the device and the enterprise to malicious attacks propagated through Internet traffic. Similarly, since deploying the packet filtering function is a process that requires hardware performance beyond what is available in a typical mobile device, and since packet filtering rules can be routinely and / or otherwise dynamically updated, simply deploying the packet filtering function to the mobile device for local operation may be ineffective.

[0029] Accordingly, a solution to this technical problem is described herein. A user can be directed to an identity-based DNS routing platform, which can identify the user and apply user-specific routing rules to the traffic to and from the user's mobile device. For example, a client device can establish a secure DNS channel with the identity-based DNS routing platform and can send encrypted DNS query requests and responses through the secure DNS channel. In some cases, when establishing the secure DNS channel, the client device can provide an encrypted DNS certificate to the identity-based DNS routing platform, which can be customized on a per-fine (or other individual) basis to identify the originating device or user within the protected enterprise environment and can be used by the identity-based DNS routing platform to identify the corresponding user. Once the identity is determined, the identity-based DNS routing platform can identify the routing rules specific to that user (which can be defined, for example, by the enterprise or otherwise) and provide an encrypted DNS query response based on these routing rules, which can, for example, indicate the requested IP address, indicate that the requested IP address is blocked, indicate the proxy IP address (e.g., of a proxy server that can monitor the traffic between the client device and the target server), and / or other information.

[0030] This document further describes using unencrypted DNS query requests to embed identity information (e.g., as compared to the encrypted DNS method described above). In some cases, the identity information may not be encrypted within the unencrypted DNS query. For example, the identity information can be embedded in the unencrypted DNS query request using plaintext. In some cases, the identity information itself can be encrypted within the unencrypted DNS query.

[0031] In some cases, multiple identities can be embedded in the DNS query request. For example, multiple systems can add, replace, remove, and / or otherwise modify identities along the path of the DNS query request. In some cases, these multiple identities can be included in a daisy chain of DNS query requests. In some cases, each identity can have a corresponding policy, and thus, the addition of multiple different identities can result in one or more policies that conflict with each other. In these cases, the policies can be coordinated and / or otherwise conflict can be eliminated to produce an overall policy for the application.

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

[0033] In some cases, the DNS response can be modified to enable traffic to be routed through a proxy or gateway for further monitoring / recording. Additionally or alternatively, the DNS response can be modified to include local rules to be implemented (e.g., blocking, allowing, monitoring / recording, and / or other actions implemented on the client side). In some cases, the DNS response can be modified to include a shortened time-to-live (TTL) for a given domain (e.g., because the domain is on a watchlist, the domain has little or no knowledge of network threat intelligence, etc.), which may, for example, cause the domain to be evicted from the cache within a shortened period of time.

[0034] By operating in this manner, the DNS infrastructure can be utilized to perform actions and / or implement solutions that it was not originally designed for. For example, the DNS infrastructure can substantially involve and / or otherwise be used to implement distributed delegation of authoritative records. Additionally, the authoritative server can be configured such that the owner of a given domain can control what information exists for such a domain. However, the DNS infrastructure was not originally designed to have information for bad domains evicted from the cache within a shortened time period (e.g., five seconds, etc.), as described herein. Similarly, the DNS infrastructure was not designed to implement the delivery of intelligence directives, as further described herein. These two functions, as well as other functions described herein, can result in improved threat detection and prevention. Accordingly, the systems and methods described herein can utilize the DNS infrastructure to perform actions that it was not originally designed for, thus providing technical advantages and solutions. These and other features are described in further detail below.

[0035] Figures 1A to 1C Depicts an illustrative computing environment that provides improved traffic routing and monitoring in accordance with one or more example embodiments. Referring Figure 1A , computing environment 100 can include one or more computer systems. For example, computing environment 100 can 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.

[0036] As further described below, the traffic routing and monitoring platform 102 can be a computer system that includes one or more computing devices (e.g., servers, blade servers, etc.) and / or other computer components (e.g., processors, memories, communication interfaces) that can be used for traffic routing, traffic monitoring, DNS response, and / or other functions as further described below. In these cases, the traffic routing and monitoring platform 102 can be configured to identify users based on security certificates and apply personalized rules to traffic received from such users (these personalized rules can, for example, include allowing, blocking, and / or monitoring traffic). For example, the traffic routing and monitoring platform can be configured for identity-based DNS routing.

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

[0038] The proxy server 103 can be and / or otherwise include one or more computing devices (e.g., servers, blade servers, and / or other devices) and / or other computer components (e.g., processors, memories, communication interfaces), which can act as intermediaries between client devices (e.g., the first client device 105, the second client device 106, the third client device 107, and / or other client devices) and the target server 108. For example, the proxy server 103 can be configured to receive traffic directed to the target server 108 and accordingly record both the outbound traffic and the inbound traffic to the target server 108. The proxy server 103 can be further configured to share these traffic logs with the traffic routing and monitoring platform 102.

[0039] The first client device 105 can be and / or otherwise include one or more devices such as laptops, desktops, mobile devices, tablets, smartphones, and / or other personal computing devices. For example, the first client device 105 can be a computing device configured to provide (e.g., to the traffic routing and monitoring platform 102) an encrypted DNS query request and accordingly receive an encrypted DNS query response. In addition, the first client device 105 can be configured to access these IP addresses once the IP addresses are received as an encrypted DNS query response. In some cases, the first client device 105 can be configured to establish a secure session with the traffic routing and monitoring platform 102 (e.g., during which DNS queries can be sent). In these cases, the first client device 105 can provide a security certificate, which can be verified and used to establish the secure session. In some cases, the first client device 105 can be configured to generate or otherwise receive a security certificate, which can identify the user of the first client device 105 (e.g., the first user) in some cases. In some cases, the first client device 105 can be configured to display one or more graphical user interfaces (e.g., the requested data interface, the blocked traffic interface, and / or other interfaces).

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

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

[0042] The target server 108 may be and / or otherwise include one or more computing devices (e.g., servers, blade servers, and / or other devices) and / or other computer components (e.g., processors, memories, communication interfaces), and these computing devices and / or computer components may be configured to provide data in response to client requests. In some cases, 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 via the proxy server 103. In some cases, the target server 108 corresponds to a specific domain name (e.g., "domain.com") and has a corresponding IP address (e.g., 123.123.123.123).

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

[0044] The computing environment 100 may further include one or more networks, and these one or more networks 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 the network 101 (which may interconnect, 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, and / or the gateway server 115).

[0045] In one or more arrangements, 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 can be any type of computing device capable of sending and / or receiving requests and processing the requests accordingly. For example, in some cases, 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, gateway server 115, and / or other systems included in the computing environment 100 can be and / or include server computers, desktop computers, laptop computers, tablet computers, smartphones, and / or other devices, and these other devices can include one or more processors, memories, communication interfaces, storage devices, and / or other components. As described above and as will be explained in more detail below, in some cases, 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 can be dedicated computing devices configured to perform specific functions.

[0046] Reference Figure 1B , the traffic routing and monitoring platform 102 can include one or more processors 111, a memory 112, and a communication interface 113. A data bus can interconnect the processor 111, the memory 112, and the communication interface 113. The communication interface 113 can 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 can 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 can store and / or otherwise maintain information that can be used by such program modules and / or the processor 111. In some cases, one or more program modules and / or databases can be stored and / or maintained in different memory units of the traffic routing and monitoring platform 102 and / or by different computing devices that can form and / or otherwise constitute the traffic routing and monitoring platform 102. For example, the memory 112 can have, host, store, and / or include a traffic routing and monitoring module 112a and / or a traffic routing and monitoring database 112b.

[0047] The traffic routing and monitoring module 112a may have instructions to direct and / or cause the traffic routing and monitoring platform 102 to generate user - specific rules / policies based on user identity and apply them to DNS queries and / or other traffic, and in some cases may operate in this way by identifying the user based on a security certificate. The traffic routing and monitoring database 112b may store the correlations between user identities, 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 discussed in more detail below.

[0048] Reference Figure 1C , as Figure 1A a supplement or alternative to the configuration illustrated in Figure 1C , the configuration depicted in Figure 1A may be implemented. For example, as a supplement or alternative to multiple client devices having requests to access a common target server / domain (e.g., target server 108) illustrated in

[0049] a single client device (e.g., client device 105) may attempt to access multiple target servers / domains (e.g., target servers 109 to 111 that may correspond to a first domain, a second domain, and a third domain, respectively). For example, the first, second, and third target servers 109, 110, and 114 may be similar to the target server 108, as described above, but may correspond to different domains. In these cases, the first client device 105 may communicate with the traffic routing and monitoring platform 102 (e.g., via an encrypted DNS session), and the traffic routing and monitoring platform may identify domain - name filtering rules specific to the user of the first client device 105 for each of the first domain, the second domain, and the third domain.

[0050] 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 the traffic between the first client device 105 and the second target server 110 should be blocked, and may accordingly block the access (e.g., by sending an encrypted DNS query response indicating that the second target server 110 is inaccessible instead of sending the IP address of the second target server). In these cases, the first client device 105 may be unable to access the second target server 110. This may be similar to the actions performed at steps 211 to 218, as further described below.

[0051] 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 the traffic between the first client device 105 and the third target server 114 should be logged, and may accordingly log the traffic (e.g., by sending an encrypted DNS query response including the IP address of the proxy server 103, which may be appended or otherwise attached to the IP address of the third target server 114 in some cases). In these cases, the traffic between the first client device 105 and the third target server 114 may be transmitted through the proxy server 103, which may accordingly monitor and log the traffic. This may be similar to the actions performed at steps 219 to 234, as further described below.

[0052] Figures 2A to 2I Depicts an illustrative sequence of events for traffic routing and monitoring in accordance with one or more example embodiments. Refer to Figure 2A, at step 201, the traffic routing and monitoring platform 102 may issue security certificates (e.g., the first security certificate, the second security certificate, and / or the third security certificate respectively) to the first client device 105, the second client device 106, the third client device 107, and / or other client devices. 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 security certificates by themselves and / or via interaction with another computing device. In some cases, these security certificates may include the identity, network, organization, geographical location, and / or other information of the users of the corresponding client devices. For example, the security certificates may be customized on a fine-grained (or individual) basis to identify the client devices. In some cases, the security certificates may be used to establish a secure DNS channel between the client devices and the traffic routing and monitoring platform 102. For example, the Domain Name System Security Extensions (DNSSEC) may use the security certificates to sign DNS data so that the DNS data can be tamper-proof. Similarly, the security certificates may be used to establish an encrypted TLS or a similar encrypted tunnel through which DNS communication can be carried out between the client devices and the traffic routing and monitoring platform 102.

[0053] In some cases, the traffic routing and monitoring platform 102 may issue security certificates at the encryption protocol level (such as TLS or the "S" part of DNS based on HTTPS (Hypertext Transfer Protocol Secure)). In these cases, user / device identity certificates natively supported by TLS authentication may be issued. In some cases, HTTPS-based DNS certificates may not recommend using such certificates to determine client identity but only to authorize secure communication tunnels. Accordingly, in these cases, the certificates may not be deployed on a per-user / device basis. In contrast, the certificates as described herein may be deployed on a per-user / device basis for use in client identification. For example, it may be important to be able to distinguish between users and devices because the same user may connect from multiple devices (including virtual devices, profiles, applications, and / or other devices) and may need to apply different DNS filtering policies depending on the device. Additionally, some devices may be more trustworthy than others, such as a company-issued laptop may be more trustworthy than a user's personal phone. Moreover, in some cases, one device may be used by multiple users. Accordingly, the certificates may be used to specifically identify the user (e.g., such as a user identity certificate), the device (device identity certificate), or both the user and the device (e.g., a certificate issued to the user on a specific device).

[0054] In some cases, as a supplement to or an alternative to issuing certificates, the traffic routing and monitoring platform 102 can issue one or more user identifiers that can be embedded in a Uniform Resource Locator (URL). For example, the traffic routing and monitoring platform 102 can use HTTPS-based DNS (DoH) to associate the identifier with a query. In some cases, these user identifiers can be specific to a combination of attributes corresponding to a user (e.g., user, profile, application operating system, device type, network type, IP address, geographical context, etc.). By doing so, multiple different identities can be assigned to a single user, which can be used to trigger different policies for a single user. For example, a single user can have two separate identifiers - one for each of the two browsers being used, and different policies can be applied during the use of each browser.

[0055] At step 202, once the first security certificate has been issued to the first client device 105, the first client device 105 can send the first security certificate and a request to establish a secure session with the traffic routing and monitoring platform 102. For example, the first client device 105 can send the first security certificate and a request to establish a secure session with the traffic routing and monitoring platform 102 using a wired or wireless connection.

[0056] At step 203, the traffic routing and monitoring platform 102 can verify the first security certificate sent at step 202. In the case where the traffic routing and monitoring platform 102 verifies the first security certificate, the traffic routing and monitoring platform 102 can establish a secure session with the first client device 105 (and then can proceed to step 204). Otherwise, if the traffic routing and monitoring platform 102 is unable to verify the first security certificate, the traffic routing and monitoring platform 102 may not be able to proceed to step 204, but can wait until a security certificate is received from and verified by the first client device 105.

[0057] In some cases, when verifying the first security certificate and establishing a secure session, the traffic routing and monitoring platform 102 may perform an encrypted session handshake with the first client device 105 (e.g., such as a Transport Layer Security (TLS) or other handshake). In these cases, the traffic routing and monitoring platform 102 and the first client device 105 may initiate an encrypted DNS process (the encrypted DNS process may include verifying the first security certificate in accordance with RFC 7858 and / or RFC 8310), during which 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 may notify the traffic routing and monitoring platform 102 of its TLS capabilities (these TLS capabilities may be included in the first security certificate, for example), and the traffic routing and monitoring platform 102 may respond to confirm the TLS parameters that can be used to secure the TLS channel. For example, the traffic routing and monitoring platform 102 may send a certificate identifying the traffic routing and monitoring platform 102 and a message including the digital signature of the traffic routing and monitoring platform 102, which can be verified by the first client device 105 (e.g., by checking the trusted authority list, public key pinning, and / or other methods). Once the encrypted session handshake is complete, the traffic routing and monitoring platform 102 may exchange encrypted messages (e.g., DNS query requests, DNS query replies, and / or other information).

[0058] At step 204, the traffic routing and monitoring platform 102 may identify the user of the first client device 105. For example, based on the first security certificate, the traffic routing and monitoring platform 102 may identify the first user. For example, mutual X509 certificate authentication may be used to support authentication. In these cases, TLS-based DNS may be used to encrypt traffic over the User Datagram Protocol (UDP) rather than the HTTP protocol. By managing the public key / private key infrastructure, the identity of the first user can be securely determined during the exchange process between the first client device 105 and the traffic routing and monitoring platform 102.

[0059] For example, the traffic routing and monitoring platform 102 can identify the first user using mutual X509 certificate authentication using a TLS-based DNS (e.g., UDP-based encryption) protocol. In these cases, the enterprise environment can have an internal / on-premises resolver (e.g., DNS with AD). Instructions can be provided to the first user for the local / internal resolver to resolve to the traffic routing and monitoring platform 102. In these cases, when a higher security level is desired, a TLS-based DNS can be used. A client certificate can be provided to the user along with instructions for the local resolver to resolve to the traffic routing and monitoring platform 102 using a TLS-based DNS. In these cases, instructions can be provided to block outbound standard DNS and HTTPS-based DNS. Once received, the traffic routing and monitoring platform 102 can identify the first user based on the client certificate. This mutual authentication can provide technical advantages over other methods, such as increased security.

[0060] Although the identification of the first user is described at step 204 (e.g., before sending a DNS query request embedding the first identity), in some cases, the identification can be performed based on information received in a DNS query request embedding the first identity as further described below at step 205. Accordingly, the identification of the first user can occur before or after receiving a DNS query request embedding the first identity without departing from the scope of the present disclosure.

[0061] Reference Figure 2B, at step 205, once a secure session has been established between the first client device 105 and the traffic routing and monitoring platform 102, the first client device 105 can send a first embedded DNS request (e.g., a fully encrypted DNS request, a partially encrypted DNS request, an unencrypted DNS request, etc., where the user identity exists in a certificate, is embedded in the DNS protocol itself, and / or is embedded in other ways) to the traffic routing and monitoring platform 102. For example, the first client device 105 can send the domain name of the target server 108 (e.g., domain.com) and can request the IP address of the target server 108. For example, the first client device 105 can establish a TLS session through which an embedded DNS query request with the first identity can be securely issued. For example, the TLS session can be via the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or other means. Additionally or alternatively, the first client device 105 can establish a Hypertext Transfer Protocol (HTTP) session through which a DNS query request can be issued. For example, the HTTP session can be unencrypted via TCP, UDP, etc., or encrypted via a TLS session. In some cases, the first client device 105 (e.g., the network interface of the first client device 105) can be pre-configured to direct DNS queries to the traffic routing and monitoring platform 102. For example, the first security certificate can be installed at the first client device 105 before sending an embedded DNS query request with the first identity. In some cases, when sending an embedded DNS query request with the first identity, the first client device 105 can access the Internet from outside the protected network corresponding to the traffic routing and monitoring platform 102 and / or the proxy server 103.

[0062] In some cases where the embedded DNS query request with the first identity is encrypted, the traffic routing and monitoring platform 102 can use the first security certificate to decrypt the embedded DNS query request with the first identity. In these cases, if the traffic routing and monitoring platform 102 has not received the first security certificate, the traffic routing and monitoring platform 102 can prompt the first client device 105 to provide the first security certificate.

[0063] In some cases, as a supplement or alternative to identifying the first user based on a certificate as described above at step 205, the traffic routing and monitoring platform 102 may identify and / or further confirm the identity of the first user based on information (such as the IP of the first user) embedded in the DNS query request itself that embeds the first identity (e.g., using HTTPS-based DNS). In these cases, 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 the DNS settings within the Dynamic Host Configuration Protocol (DHCP) router settings by manually setting the traffic routing and monitoring platform 102 as the DNS (e.g., UDP-based DNS). In these cases, when sending a DNS query request that embeds the first identity, the traffic routing and monitoring platform 102 may identify the first user based on the IP of the first user as embedded in the DNS query request that embeds the first identity.

[0064] This approach can have various technical advantages. For example, it can be the simplest form of authentication because the traffic routing and monitoring platform 102 may only need to identify the source IP of the DNS query request that embeds the first identity. Additionally, multiple different load balancers all support the transparent passing of UDP packets, enabling the client IP to be preserved for DNS load balancer services. For example, DNS requests (such as DNS query requests that embed the first identity) may be received at a single DNS load balancer IP address, and the DNS load balancer may extract user identity, device identity, location information, and / or other information. In these cases, the DNS load balancer may further pass this information to DNS servers at the back end (e.g., based on the information being passed to a general server or to a specific server such as the traffic routing and monitoring platform 102), and these DNS servers may be configured to handle specific customers, clients, etc. By doing so, address privacy and regulatory issues (general data protection regulatory issues, or other issues where services and / or data associated with the service should always be directed to, processed by, and / or stored on certain DNS server infrastructures) can be addressed.

[0065] In some cases, the DNS load balancer service may have been modified to scrape IP addresses from UDP packets and, in doing so, can configure the traffic routing and monitoring platform 102 to provide technical improvements over traditional DNS systems. More specifically, since many users may map to, for example, a single enterprise network IP address and / or since IP addresses may change rapidly (e.g., due to a mobile device switching between cell towers, etc.), the client connection source IP address may not be an ideal method for user identification. Accordingly, the methods described herein can identify users, devices, locations, and / or other information and pass that information as part of a DNS request (e.g., a DNS query request embedding a first identity) and / or a tunnel that has issued a DNS request from a client device (e.g., the first client device 105) to the traffic routing and monitoring platform 102. The DNS load balancer service can support forwarding the client IP through multiple different methods such as proxy protocols, which can preserve the original UDP message headers and may not affect caching on the DNS load balancer service (e.g., as described in the DoH RFC 8484 and RFC 6570 standards for Uniform Resource Locator (URI) templates).

[0066] Additionally or alternatively, the traffic routing and monitoring platform 102 can use a URI template to identify the first user. For example, a URI template can be used to support authentication for HTTPS-based DNS. Each client can be assigned a unique URI template that can contain an access key. In some cases, the access key can be encrypted, unencrypted, or partially encrypted. The encrypted access key can contain information sufficient to identify the user to the traffic routing and monitoring platform 102 such that routing to the correct (s) DNS server(s) occurs and appropriate Cyber Threat Intelligence (CTI) is applied based on the needs of the first client. In these cases, the traffic routing and monitoring platform 102 can pass the access key (or a subset of the access key) to the corresponding (s) DNS server(s) such that the (s) DNS server(s) can apply appropriate CTI for that user. As a supplement or alternative to identifying the first user using a unique URI template containing an access key at least associated with the first user, the traffic routing and monitoring platform 102 can use one or more of the following to identify the first user: an access key that is embedded in a standard DNS request (e.g., in the EDNS field or otherwise embedded); a certificate that is assigned to the first client and / or other user devices; an IP address that may (but not necessarily) be uniquely associated with the first user and / or other users; and / or an access key that is embedded in a wrapper protocol that transports a DNS query request embedding a first identity.

[0067] In some cases, the first user may have manually configured the first client device 105 to point to the traffic routing and monitoring platform 102. To this end, the first user can use an HTTPS-based DNS (DoH) URI template that includes a user-specific access key embedded in the path to modify their browser settings. In these cases, the first user can perform an initial authentication to obtain the access key described above. When 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.

[0068] In the case where the first user is an enterprise user, the enterprise environment may have an internal / on-premises resolver (e.g., a DNS with a directory service (e.g., such as Microsoft Active Directory)). In these cases, instructions for the on-premises resolver to point to the traffic routing and monitoring platform 102 can be provided to the first user. In some cases, these instructions can 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 the installation of an enterprise security profile on the first client device 105), and / or others, and can, for example, cause the first client device 105 to direct DNS requests to the IP address of the traffic routing and monitoring platform 102. For example, configuration data or an application can be provided to the first user that can provide the function of authenticating the first user to the traffic routing and monitoring platform 102 in order to enable the download of a certificate including instructions from the traffic routing and monitoring platform 102. Once downloaded, the first client device 105 can then use a browser and / or other application to automatically present the certificate when prompted to present the certificate. In some cases, different certificates can be provided for use with different browsers. For example, different policies can be applied to the same user (e.g., work and personal profiles, etc.) and / or different users on the same device (e.g., parents and children, etc.). In some cases, the certificate can similarly include password protection, prompting the first user to provide a corresponding password and / or other access key when presenting the certificate.

[0069] Similar to the home / individual use case described above, the DoH URI template can be 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 cases where DoH is implemented, the traffic routing and monitoring platform 102 can be instructed to block outbound standard DNS and / or DoT queues.

[0070] In the case of user identification based on information in a DNS query request embedding a first identity, user and / or device identity information can be embedded in the DNS query request embedding the first identity at the DNS query level (including the DNS protocol and DNS over HTTPS before being encrypted to DNS over HTTPS) and / or at the encryption protocol level (wherein the DNS protocol or DNS over HTTP is encapsulated before being encrypted to DNS over HTTPS). At the DNS protocol level, the RFC 6891 DNS Extension Mechanism (EDNS(0)) can be used to attach a custom payload (i.e., user / device identity information) to the DNS query itself, which can allow for transparent exploitation, up / down the OSI layers from lower protocol levels to higher protocol levels, up / down the DNS server hierarchy, up / down the hierarchy of the traffic routing and monitoring platform 102, and / or others, and / or others. For example, a plain / unconfigured client can query a local resolver via an unencrypted DNS protocol, and the local resolver can embed the client's identity in the EDNS of its query, wrap the identity in TLS, and forward the identity information as part of the DNS query via DoT. For example, a client certificate can be issued to a device (e.g., the first client device 105), where the certificate persists on the device regardless of who the user is using / authenticating on the device. The user identity can be embedded in an access key combined with a URL template, which can be the same across multiple devices the user is using. Then, the combination of the user identity from the URL template and the device identity from the certificate can enable the unique identification of the user on a specific device, which in turn can enable the enforcement of a first policy on the first device (e.g., a mobile device-oriented CTI policy on a mobile phone), a second policy on the second device (e.g., an operating system-specific CTI policy for a computing device), etc. In these cases, a remote resolver (e.g., the traffic routing and monitoring platform 102) can extract the identity information from the EDNS and apply appropriate filtering policies (described further below). Additionally or alternatively, a configured DNS over HTTPS client (e.g., the first client device 105) can use a client certificate to convey its device identity to the traffic routing and monitoring platform 102 and at the same time use a URL template with embedded user identity information to convey its identity to the traffic routing and monitoring platform 102. This can allow the traffic routing and monitoring platform 102 to apply different policies to the same user logging in from different devices (e.g., mobile devices, desktop devices, multiple users at a shared workstation, etc.), and / or can apply different policies to authenticated devices without an authenticated user (e.g., not logged in), authenticated devices with an authenticated user, and unauthenticated devices with an authenticated user.This flexibility can allow for supporting different client capabilities, such as older clients that can only support the native DNS protocol and new clients that support, for example, DoT but not DoH. When doing so, such clients can transfer identity information into the queries that travel to the traffic routing and monitoring platform 102 across the Internet in the most secure and private manner possible.

[0071] In some cases, the first client device 105 can use DoH to send the user identifier described above at step 201 along with a DNS query request embedding the first identity, which in some cases can indicate multiple attributes of the user identity (e.g., profile, application, operating system, device, network, cluster, wide area network (WAN) IP, and / or other identifiers). In some cases, these attributes of the user identity sent from the first client device 105 can correspond to a profile (e.g., the first identity). For example, the user identifier can be included in a URL (e.g., HTTP header, etc.) corresponding to the DNS query request embedding the first identity. For example, the user identifier can be a URL prefix that can be assigned to the user when the user registers with the traffic routing and monitoring platform 102. In some cases, the user identifier can be a fixed value that can be assigned to the user and stored, for example. In some cases, an application stored at the first client device 105 (e.g., an application that the user has previously authenticated) can be used to dynamically adjust the user identifier. In some cases, the user identifier can be generated / assigned simultaneously or at a later time with a first security certificate. In some cases, the user identifier can be sent together with the first security certificate described above at steps 201 to 203 (which can, for example, enable additional identity information to be sent when compared to the transmission of the first security certificate itself). In some cases, one or more user identifiers can be sent as a supplement or alternative to the first security certificate.

[0072] In some cases, the DNS query request embedding the first identity can be routed to the traffic routing and monitoring platform 102 via one or more other devices (such as a local DNS resolver, etc.). In these cases, a second identity (e.g., an identity corresponding to the intermediate device) can be attached to the DNS query request embedding the first identity. For example, the intermediate device can be associated with an enterprise, and thus, the identity of the enterprise can be attached to the DNS query request embedding the first identity. Accordingly, one or more identities can be attached to the DNS query request embedding the first identity along the path between the first client device 105 and the traffic routing and monitoring platform 102.

[0073] As a specific example, the first identity can indicate a specific user identity and the browser on which the user is operating, and the second identity can identify a company entity. Although the first identity and the second identity are described, in some cases, a single identity or any other number of identities can be included in the DNS query request that embeds the first identity without departing from the present disclosure. Additional examples of these user identities are described below with respect to Figure 4 Additional examples of these user identities are described below with respect to

[0074] In some cases, if the first client device 105 is not configured for DoT or DoH communication, the first client device 105 can embed these identities into the DNS query request that embeds the first identity using plaintext. For example, the first client device 105 can be customized and / or otherwise configured to perform such embedding. In some cases, the plaintext identity information can be embedded in an unencrypted DNS request (e.g., in a field of the DNS request protocol, etc.). Alternatively, the identity information can be encrypted (fully or partially) and then embedded into an unencrypted DNS request. For example, the identity information can be run through an encryption protocol before being embedded within the DNS request. In some cases, the first client device 105 can communicate with a local resolver (which can be, for example, similar to the traffic routing and monitoring platform 102) and can convey the unencrypted (fully or partially) identity information as part of the communication. The local resolver can then, in some cases, obtain the received unencrypted identity information, add additional identity information (e.g., regarding the first client device 105, the local resolver, and / or others), and encrypt all of the identity information. Then, any requests from the local resolver to other resolvers (which can be, for example, configured to be similar to the traffic routing and monitoring platform 102) can be sent using the plaintext with the encrypted identities.

[0075] In these cases, if a DNS request is captured, the identity information can remain protected due to encryption (e.g., in case of modification of the identity information, user identification based on the identity information, etc.). Additionally, since the path of DNS requests may be uncontrolled as they travel upstream outside the enterprise infrastructure, etc., there may be scenarios where certain protocols (e.g., DoT communication, DoH communication, etc.) may not be supported or otherwise permitted. For example, a security upgrade or downgrade may occur within the enterprise. For example, an enterprise may use encrypted DNS internally, but once the DNS request passes through the internal resolver, the same protocol (e.g., encryption, etc.) may not be supported upstream. Thus, the method for conveying identity information can be changed by the path of the DNS request (e.g., changing the encryption level associated with the domain of the DNS request, etc.). Additionally or alternatively, the protocol itself can be changed (e.g., changing from UDP-based DNS to DoT, changing to DoH and back to UDP, etc.). However, by including the identity information in the fields of the DNS request, such information can be conveyed regardless of the protocol upgrade / downgrade along the path of the DNS request.

[0076] Furthermore, it may be advantageous to use the standard fields of the DNS request protocol to convey the identity information in an encrypted manner. This can further permit the embedding of the identity information on the client side (e.g., by the first client device 105) for communication with the server side (e.g., with the traffic routing and monitoring platform 102), thus allowing the identity to be embedded and transmitted from the originator of the DNS request.

[0077] Additionally or alternatively, the local resolver can be configured to strip or otherwise remove any identity information received in the DNS request before forwarding the DNS request (e.g., in cases where the DNS request will be sent to the public), to protect the identity information and / or other privacy information from being disclosed. This can be particularly advantageous in cases where the client (e.g., the first client device 105) fails to encrypt the identity information.

[0078] In some cases, the traffic routing and monitoring platform 102 may modify a DNS query request when the DNS query request embedding the first identity is received. For example, in some cases, a malicious user may submit a non-compliant DNS query request (e.g., using non-compliant or otherwise disallowed characters). However, in these cases, such non-compliant DNS query requests may generally not be filtered out. Accordingly, it may be advantageous to transform or otherwise 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 a subsequent DNS query request. This process can achieve payload transformation, which malicious actors may exploit, for example, to defeat the filtering of the traffic routing and monitoring platform 102.

[0079] To avoid such exploitation, the traffic routing and monitoring platform 102 may modify the DNS query request to normalize (e.g., Punycode, etc.), standardize, and / or otherwise transform the DNS query request to facilitate CTI matching in order to enforce intelligence that may otherwise be circumvented without such transformation (e.g., before routing the DNS query request upstream, etc.). Further, such techniques can enable non-compliant DNS query requests to be transformed into compliant DNS query requests to correspondingly apply the intelligence. Based on such intelligence, the traffic routing and monitoring platform 102 can identify further actions to take regarding the DNS query request, such as redirecting the request, allowing the request to continue, etc.

[0080] At step 206, the traffic routing and monitoring platform 102 may identify a first traffic routing rule based on the identity of the first 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 may identify (e.g., by indexing the database) the first traffic routing rule corresponding to the first user. In some cases, when identifying the first traffic routing rule, the traffic routing and monitoring platform 102 may identify domain matching criteria and corresponding actions to be performed for each of a plurality of domain names (including the domain name sent in the DNS query request embedding the first identity), both the domain matching criteria and the corresponding actions may be specific to the first user. For example, the first traffic routing rule may be specific to the organization of the first user, the subscription level of the first user (which may provide, for example, a unique security level and / or be selected or otherwise registered by the first user), the geographical location, and / or other user characteristics. In other cases, the first traffic routing rule may be common among all network users (including the first user). In some cases, the subscription level of the first user may indicate whether a unique policy specific to the first user should be applied, or conversely, whether a general policy should be applied. In some cases, when identifying the domain matching criteria of the first traffic routing rule, the traffic routing and monitoring platform 102 may identify a whitelist, a blacklist, and / or a monitoring list specific to the first user. In these cases, each of the plurality of domain names may be on one of the whitelist, the blacklist, and the monitoring list. In some cases, the first traffic routing rule may be associated with a protected network (e.g., an enterprise or other secure network).

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

[0082] In these cases, the traffic routing and monitoring platform 102 may identify one or more policies based on one or more identities conveyed in the DNS query request embedding the first identity. For example, as mentioned above, in some cases, multiple identities (e.g., user identity, device identity, browser identity, application identity, operating system identity, identity of other software supporting the DNS request, company identity, etc.) may be applied to the DNS query request embedding the first identity (and / or included in the first certificate) along the path between the first client device 105 and the traffic routing and monitoring platform 102. In some cases, the traffic routing and monitoring platform 102 may maintain a stored table (or other correlation) of identity / policy pairs (which may be key / value pairs, databases, and / or other relationships reflecting the correlation between identities and corresponding policies in some cases), where the identity is represented as the key and the corresponding policy is represented as the value. Accordingly, 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.).

[0083] In some cases, the stored table may be maintained and / or otherwise managed by an intelligent policy manager system, which may dynamically distribute identity / policy pairs for caching by various traffic routing and monitoring platforms. For example, when the traffic routing and monitoring platform 102 receives a DNS query request embedding the first identity, if the DNS request includes an identity and / or certificate for which there is no stored policy in the table / index (e.g., based on key / value pairs and / or other identity / policy pairs defining the correspondence between identities and corresponding policies), the traffic routing and monitoring platform 102 may query the intelligent policy manager system to obtain the information. For example, the table / index may be stored and / or otherwise maintained at the local traffic routing and monitoring platform (e.g., the first traffic routing and monitoring platform 503, the second traffic routing and monitoring platform 505, etc.), and may request the intelligent policy manager system (e.g., the intelligent policy manager system 504) to obtain the identity information to be stored and the corresponding policies (e.g., as further described below Figure 5 . For example, the intelligent policy manager system 504 may distribute the corresponding policy information to one or more traffic routing and monitoring platforms, which may cache the policy information in the corresponding identity / policy pair table.

[0084] This is for example in Figure 5is illustrated. For example, a client device 502 (which can be, for example, similar to the first client device 105, the second client device 106, and / or the third client device 107) can send a DNS request to a first traffic routing and monitoring platform 503 (which can be, for example, similar to the traffic routing and monitoring platform 102). The first traffic routing and monitoring platform 503 can identify (e.g., via a local search) whether an identity included in the DNS request is represented in an identity / policy pair in a policy index (which can be maintained and / or otherwise stored at the first traffic routing and monitoring platform 503, for example). If all identities are included in the policy index, the event sequence can continue as described below with respect to Figure 2B If any identity is not included in the policy index, the first traffic routing and monitoring platform 503 can query the intelligent 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 can cache the information in the policy index for future use and apply the policy (or perform policy coordination in some cases, as further described below). Based on the policy, the first traffic routing and monitoring platform 503 can return a DNS response to the client device 502, as further described below with respect to the illustrative event sequence.

[0085] Meanwhile, the intelligent policy manager system 504 can identify other traffic routing and monitoring platforms (e.g., a second traffic routing and monitoring platform 505) to which the policy information should be pre-sent. For example, based on the IP address of the client device 502 (which may have been sent to the intelligent policy manager system 504 together with the query from the first traffic routing and monitoring platform 503, for example), the intelligent policy manager system 504 can identify other traffic routing and monitoring platforms (e.g., a second traffic routing and monitoring platform 505) within the geographical boundary corresponding to the location of the client device 502.

[0086] For example, the server can route query responses based on the identified location. As a specific example, if a query request is received via a server in a first geographical location (e.g., a US-based server), but the location of the client device 502 indicates that they are in a second geographical location (e.g., a different country, etc.), the server (e.g., the traffic routing and monitoring platform) can be configured to route the response to the query request based on the identified location of the client device 502 (e.g., the second geographical location) via one or more servers or redirect the query request itself (including future queries) to provide a response that is most appropriate or required by the policy for the user's location. For example, a user compliant with the General Data Protection Regulation (GDPR) can route all queries and responses via a server located within a geographical boundary (e.g., a country, a continent, etc.), regardless of the user's current location, which may be outside the geographical boundary (e.g., a different country, a continent, etc.). In some cases, the rerouting and / or redirecting of queries and responses can be based on the latency of available servers and / or other performance metrics.

[0087] Once the appropriate server (e.g., the traffic routing and monitoring platform) is identified, the intelligent policy manager system 504 can pre-push policy information to the second traffic routing and monitoring platform 505, which can cache the policy information in a corresponding policy index (e.g., at the second traffic routing and monitoring platform 505). Thus, 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 the stored key-value pairs corresponding to the identity of the client device 502 and the corresponding policy. This can enable the second traffic routing and monitoring platform 505 to provide a DNS response based on the corresponding policy without querying the intelligent policy manager system 504. Additionally, by operating in this way, network bandwidth and computing resources can be saved by populating only the servers that will need / implement the policy with the policy. At the same time, this method can reduce the latency associated with request processing by continuously pre-providing policy information to the corresponding servers.

[0088] As a supplement or alternative to pre-pushing policy information based on the geographical location associated with the client device 502 as described above to various traffic routing and monitoring platforms (e.g., the first traffic routing and monitoring platform 503, the second traffic routing and monitoring platform 505, etc.), policy information can be pre-pushed based on the policy itself. For example, covered users in a first geographical region (e.g., a first country, etc.) who comply with GDPR can request that all their DNS requests be processed strictly through the traffic routing and monitoring platform located in that first geographical region. In these cases, regardless of where the user is geographically located, a path that will be routed through that first geographical region can be provided for DNS query requests. Similarly, a specific geographical region through which DNS requests should not be routed can be specified. In these cases, a path that avoids that specific geographical region can be provided for DNS query requests. Accordingly, in these cases, as a supplement or alternative to being geographically driven, the pre-pushing of policy information can be policy-driven.

[0089] In some cases, the intelligent policy manager system 504 can push policy information based on a request (e.g., from one of the traffic routing and monitoring platforms) to receive pre-populated policy information (which can include, for example, authentication credentials, etc.). In any of these cases, an authorized server (e.g., a traffic routing and monitoring platform identified as a candidate for pre-receiving policy information) can be pre-populated accordingly with policy information from the intelligent policy management system 504.

[0090] In some cases, the client device 502 can send a DNS query request to an authorized server (e.g., the first traffic routing and monitoring platform 503). However, due to policy definitions or requirements, for certain reasons (e.g., GDPR, current processing load, latency, etc.), the client device 502 should be instructed to direct subsequent requests to another server (e.g., the second traffic routing and monitoring platform 503, etc.) or one of the servers in a server group. In these cases, the response to the DNS query request from the traffic routing and monitoring platform 503 (e.g., a reconfiguration response) can 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 cases, the intelligent policy manager system 504 can accordingly pre-push policy information to the second traffic routing and monitoring platform 503 (and / or other traffic routing and monitoring platforms).

[0091] Additionally or alternatively, when new network threat intelligence and / or others are received, the intelligent policy manager system 504 can pre-push policy information based on receiving multiple updates (e.g., more than a threshold number of updates, etc.) for a given traffic routing and monitoring platform 503.

[0092] There can be multiple drivers for pre-pushing policy information using one or more of the methods described above. First, the quantity / size of the policy information may be large, and thus, pre-pushing the policy information can reduce or otherwise eliminate the latency associated with waiting for such policy information.

[0093] Second, since the policy information may change continuously, it may be important to proactively update the policy information at the traffic routing and monitoring platform continuously when such changes are detected or otherwise received by the intelligent policy manager system 504 (e.g., every five minutes, every hour, etc., which can be based on, for example, the TTL of the policy information, DNS records, etc.).

[0094] For example, by pre-updating the policy information and / or DNS records at the traffic routing and monitoring platform, the intelligent policy manager system 504 can perform indicator eviction (e.g., evict information that has been cached at the traffic routing and monitoring platform) by replacing the TTL and / or DNS records of the corresponding policy information (e.g., replacing the current TTL with the smallest possible TTL to accelerate the eviction process, and / or otherwise removing the corresponding DNS records and / or policy information). In some cases, the TTL can be measured in time units (e.g., seconds, minutes, hours, etc.), hop counts, and / or others. In some cases, any TTL detected as exceeding a specific threshold can be limited to that threshold (e.g., reduced to the maximum value corresponding to that threshold, etc.). This can enable the replacement of information / records that have been cached at the traffic routing and monitoring platform to prevent downstream clients (e.g., the first client device 105) from using such information / records.

[0095] In some cases, the client device 502 may include a proxy configured to receive instructions to evict accessed records stored in a local cache. For example, the proxy may be configured to communicate with a traffic routing and monitoring platform and / or an intelligent policy manager system 504 to convey which records have been accessed and may accordingly be provided with instructions for evicting records based on that communication. In other cases, the first client device 105 may not be configured with a proxy. In these cases, the traffic routing and monitoring platform and / or the intelligent policy manager system 504 may track the DNS records requested. The traffic routing and monitoring platform and / or the intelligent policy manager system 504 may further track known good DNS records and may allow such records to have a pass-through TTL. Similarly, the traffic routing and monitoring platform and / or the intelligent policy manager system 504 may enforce a shortened TTL for records that are unknown or otherwise untrusted for network threat intelligence (e.g., by transparently overriding the existing TTL of these records). In doing so, the traffic routing and monitoring platform and / or the intelligent policy manager system 504 may cause the cache (or one or more records therein) to be updated based on the expiration of the modified TTL.

[0096] In some cases, the traffic routing and monitoring platform and / or the intelligent policy manager system 504 may generate a threat score and may accordingly adjust the TTL based on the threat score. For example, the TTL may be shortened for a higher threat score and lengthened for a lower threat score. For example, the threat score may correspond to a percentage and the TTL may be reduced according to that percentage (e.g., reduced by 60% if the threat score is 0.6, etc.). In some cases, the TTL may be modified dynamically over time upon receipt of additional intelligence.

[0097] This can provide a technical solution to the problems posed regarding the use of DNS records in network security. For example, since DNS records are locally cached, the client device may continue to access a bad record for the entire duration of the corresponding TTL (even after the bad record has been identified or otherwise flagged). Accordingly, by reducing the TTL, the impact of bad or otherwise untrusted records can be minimized as the record may be evicted from the local cache when the shortened TTL expires. Similarly, for known or otherwise trusted records, the TTL may be lengthened.

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

[0099] Furthermore, a third driver for pre-pushing policy information using one or more of the methods described above addresses issues associated with pushing policies to an identity-based cache. For example, policies that are common to more than one identity can be pre-pushed. In some cases, locally identity-based caches can be implemented, which can store policies for a given user. However, challenges can arise as the number of users (each with corresponding policies) increases. For example, the policies for each user must be pushed out to the local cache, regardless of whether the policies contain the same (or substantially similar) information, which can involve the transmission and / or local storage of duplicate and / or otherwise overlapping policy information. Accordingly, commonalities between policies and / or identities that can be deployed to a particular traffic routing and monitoring platform can be identified. For example, if a particular policy is common to all identities accessing a particular traffic routing and monitoring platform, the policy can be pushed once (e.g., by the intelligent policy manager system 504) (e.g., rather than once per identity), and the group cache can be populated with the policy accordingly. In these cases, the group cache can correspond to one or more identities with a common policy and / or one or more identities associated with a common subset of different policies. By identifying these commonalities and constructing group caches accordingly, the amount of policy information to be pushed to the traffic routing and monitoring platform can be significantly reduced, which can, for example, save network bandwidth and processing resources. For example, issued policies can be evaluated for efficient delivery, where duplicate information may not be issued.

[0100] In some cases, since it may be advantageous to cache policies as close as possible to the user (e.g., at the location closest to the traffic routing and monitoring platform, etc.), when policies are pushed down to a given traffic routing and monitoring platform, the intelligent policy manager system 504 can accordingly understand the commonalities between the identities associated with that traffic routing and monitoring platform and can thus create group caches / common policies as described above. For example, a company policy that applies to multiple employees of an enterprise can be sent down, which includes policies that apply to all (or a large percentage of) employees, and smaller individual policies (including the remaining policies for each individual employee) can be sent down accordingly. When doing so, the policies can be sent in a differential manner that minimizes the amount of policies, duplicate information, and / or information that is generally applicable to be sent.

[0101] In addition, in some cases, the group cache can be dynamically adjusted to add and / or remove policies from the common policy associated with the group cache based on applying the policies to the identities corresponding to the group cache. Returning to Figure 2BIn step 206, in the case of identifying multiple policies, the traffic routing and monitoring platform 102 can perform a coordination process to apply appropriate policies (e.g., block traffic, allow traffic, record traffic, etc.) to any given packet or request. For example, the traffic routing and monitoring platform 102 can identify whether the policies conflict (e.g., whether one policy indicates that traffic should be blocked for the requested IP address and another policy indicates that traffic should be allowed). In such a complete conflict situation, the traffic routing and monitoring platform 102 can select a dominant policy to apply (e.g., based on pre-configured settings, user input, etc.), and can apply the corresponding policy. For example, the traffic routing and monitoring platform 102 can be configured to apply corporate policies rather than individual user policies in case of conflict (e.g., select the second policy instead of the first policy).

[0102] In other cases, the traffic routing and monitoring platform 102 can identify partial conflicts (e.g., two or more policies are consistent in some aspects and conflict in other aspects). In these cases, the traffic routing and monitoring platform 102 can apply the non-conflicting parts of the policies, and can coordinate any conflicting parts as described above (e.g., identify that the second policy plus a non-conflicting part of the first policy should be applied). For example, in some cases, a policy can include a disposition indicating an action such as block or allow. Additionally, in some cases, a policy can include instructions such as record, monitor, capture one or more packets, alert, redirect, and / or other secondary or additional actions. Accordingly, in some cases, a partial conflict can be identified, where two policies indicate a common disposition but the instructions conflict. In these cases, the traffic routing and monitoring platform 102 can resolve the conflict by performing a combination of the actions defined in the conflicting dispositions in addition to performing the common disposition. Additionally or alternatively, one or more dominant instructions can be selected and executed to resolve the conflict.

[0103] In some cases where identifying a conflict (e.g., partial conflict or complete conflict) is an alternative to simply selecting one of the conflicting policies as the dominant policy, the traffic routing and monitoring platform 102 can select one or more dominant rules for multiple different conflicting policies. For example, the traffic routing and monitoring platform 102 can generate a priority score and / or otherwise associate a priority score with the rules associated with each conflicting policy, and can select the rule from one or more policies by choosing the rule (from a pair of conflicting rules) that has a higher priority score than the remaining rule. For example, if the first rule of the first policy has a higher priority score than the first rule of the second policy, but the second rule of the second policy has a higher priority score than the second rule of the first policy, then the traffic routing and monitoring platform 102 can select the first rule of the first policy and the second rule of the second policy.

[0104] As another example, conflicts can be resolved based on special circumstances. For example, a first policy might indicate blocking “*.domain.com”, and another policy might indicate allowing “www.domain.com”. Depending on the conflict resolution criteria, traffic to “www.domain.com” might be allowed, but traffic to, for example, “meet.domain.com” might not be allowed. Similarly, the reverse situation might occur. For example, it can depend on the priority of each scenario. Additionally or alternatively, conflict resolution can be performed based on blocking versus allowing. For example, blocking can take precedence over any allowing. In this example, traffic to “www.domain.com” can be blocked by a rule for “*domain.com”, even though the rule indicates that traffic to “www.domain.com” should be allowed. In some cases, these examples can illustrate the application of rule priorities. In some cases, such priorities can be assigned by human-imposed judgment and / or determined by a rule analysis agent.

[0105] In other cases, the traffic routing and monitoring platform 102 can identify that the policies do not conflict (or are consistent), and can apply each policy in its entirety (e.g., apply both the first policy and the second policy). This can result in an overall or composite policy that can be, for example, a selected identity-based policy, the sum of multiple identity-based policies, or a partial combination of multiple identity-based policies.

[0106] By resolving and / or otherwise eliminating conflicts in policies in this way, privacy issues associated with personal devices can be addressed. For example, if a user has a company-issued tablet, it is less likely that multiple different policies can apply. Instead, the tablet can be governed solely by the company's policy. However, when using a personal device (or if personal browsing is permitted on a company device), the individual can still seek privacy on their device and, in some cases, can circumvent company security to do so. By applying identity-driven solutions as described herein, multiple profiles, personal devices, multi-purpose devices, and / or other devices can be supported to provide user privacy while maintaining security.

[0107] In some cases, the traffic routing and monitoring platform 102 can further select the composite policy based on non-identity-based attributes (e.g., attributes not specifically bound to a given user identity). The non-identity-based attributes can include, for example, GDPR attributes, where different overall policies can be selected based on the value of the GDPR attributes for the same identity (e.g., where the user is located in a first country and a second country, etc.).

[0108] In these cases, the identified / selected strategy may correspond to a set of traffic routing rules (e.g., the first traffic routing rule described below at step 207). Further regarding Figure 4 the illustration of this strategy selection is described below.

[0109] At step 207, the traffic routing and monitoring platform 102 may identify an action to be performed on a DNS query request embedding a first identity based on the first traffic routing rule. For example, the traffic routing and monitoring platform 102 may, based on the first traffic routing rule, identify whether to allow, block, and / or monitor traffic directed to the IP address requested by the DNS query request embedding the first identity (which IP address may, for example, correspond to the target server 108). For example, the traffic routing and monitoring platform 102 may identify that the IP address corresponding to a blacklisted domain should be blocked, access rights should be granted to the IP address corresponding to a whitelisted domain, and traffic to and from the IP address corresponding to a monitored list domain should be monitored / recorded. For illustrative purposes, at step 207, the traffic routing and monitoring platform 102 may, based on the first traffic routing rule, identify that traffic to the IP address requested by the DNS query request embedding the first identity should be allowed.

[0110] In some cases, as a supplement or alternative to applying these strategies / traffic routing rules to route traffic based on a DNS query request embedding a first identity, the traffic routing and monitoring platform 102 may also segment reports based on privacy preferences corresponding to the identity (which privacy preferences may, for example, be stored and / or otherwise identified using a method similar to the method described above regarding the strategy and / or may otherwise be included in the strategy). 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.

[0111] At step 208, based on identifying that the domain name of the DNS query request embedding the first identity is a domain name for which traffic is to be allowed, the traffic routing and monitoring platform 102 may identify the requested IP address (e.g., the IP address of the target server 108).

[0112] In some cases, when identifying the requested IP address, the traffic routing and monitoring platform 102 can use DNS caching to improve response time. For example, a DNS server may take a significant amount of time to contact other servers and search for an appropriate response to a query. Once the DNS server has a response, it can then respond to the query. By storing the response to a query, the DNS server can provide a more rapid response to any subsequent user requesting the same information. This storage and use of the stored DNS responses can be referred to as DNS caching. It is worth noting that most DNS servers can be built to support multiple users and provide all the same information to these users from a single global cache.

[0113] Regarding the systems and methods described herein, when a client (such as the first client device 105) queries the traffic routing and monitoring platform 102, multiple different responses can be generated by the traffic routing and monitoring platform 102 and / or received by the first client device 105 based on policies tailored to that specific client. For example, the correct response to a DNS query for a client can depend on services and / or policies specific to that client.

[0114] For example, a marketing company may want employees to access a specific social media website (e.g., Website #1). Accordingly, the DNS policy for that company can indicate that the correct IP address for the company to access Website #1 should be allowed. To speed up subsequent queries for Website #1, the traffic routing and monitoring platform 102 can cache the response to the "allowed" response. In contrast, the DNS policy for a high school can indicate that Website #1 should be blocked. However, the traffic routing and monitoring platform 102 may see the cached "allowed" response and potentially provide the correct IP address for Website #1 in violation of the high school's DNS policy. Similarly, the opposite situation can occur where both the company and the high school may be blocked from accessing Website #1. Thus, while caching can greatly improve the query processing speed of the traffic routing and monitoring platform 102, it can also be a source of incorrect responses for a specific client.

[0115] To address this shortcoming, the policy can be applied by the traffic routing and monitoring platform 102 and then a DNS lookup can be performed for each client query. However, this can introduce latency and / or delay that may negatively impact the user experience. Accordingly, a per-client cache is proposed herein. This can involve segmenting the cache of the traffic routing and monitoring platform 102 to restrict users of a particular client (e.g., a company or high school as described above) to the cached responses for that client. This can be achieved by incorporating a client identifier into the caching mechanism and can allow the traffic routing and monitoring platform 102 to quickly provide verified DNS query responses across the entire user base. In these cases, identity-aware caching can be used to provide the correct responses related to the identity and its corresponding policy. In doing so, referring to the example described above, regarding access to Website #1, the correct policy will be applied to the advertising company (e.g., allow) and the high school (e.g., block). Additionally or alternatively, identity-aware caching can be based on other attributes (e.g., location, device, company, user, and / or other attributes) without departing from the scope of the present disclosure. For example, the cached information (e.g., policy, DNS response, etc.) can be pre-pushed to the server (e.g., traffic routing and monitoring platform) to which the user is being redirected. More specifically, if a user accesses a first server (e.g., traffic routing and monitoring platform 102) in a first location (country, continent, geographical region, etc.) but is redirected to a second server (e.g., another traffic routing and monitoring platform) based on location, etc., then the cached policy information can be pushed accordingly to that second server (this can, for example, cause the second server to pre-update its cache based on the cache of the first server and / or others). Accordingly, identity-aware caching can be used to pre-push the cached information (e.g., policy information, DNS response information, etc.) and evict / overwrite the existing cached information. For example, as described above regarding Figure 5 and pre-push of the policy, the cache can be pre-pushed and / or populated.

[0116] In some cases, if the identified DNS query response includes CTI or is otherwise associated with CTI, the traffic routing and monitoring platform 102 may not cache the response. For example, a cached response associated with CTI may result in applying incorrect results for subsequent queries.

[0117] In some cases, the response can be cached for a specific period of time. In these cases, the period can be determined by the traffic routing and monitoring platform 102 based on the intelligence corresponding to the request for a given response.

[0118] In some cases, to generate a DNS query request embedding a first identity, the traffic routing and monitoring platform 102 may transmit an outbound application programming interface (API) call to a DNS resolver. In some examples, using a sidecar API, intelligence known to a first user and a requested domain may be extracted from and / or otherwise used to generate an encrypted DNS query response from the DNS query request embedding the first identity. For example, such filtering may be performed if any information should be filtered based on user identity and / or known intelligence. For example, the traffic routing and monitoring platform 102 may deploy the sidecar API, and the DNS server may be integrated to query the sidecar API for relevant policies. For example, the DNS server software may extract the domain and / or other information (such as identity information, etc.) from the query request and may submit the domain and / or other information to the API sidecar for processing. The API sidecar may then provide any information that can be used to change the query response at the DNS server (such as changing the response, not responding, sending domain does not exist, changing the IP address, selecting one of multiple IP addresses, providing the context of the request, redirecting the query to a different server, and / or actions). The DNS server may then interpret this information from the API sidecar, modify the query response accordingly, and provide the response. Using the sidecar API can, for example, minimize the changes required in the DNS server itself. For example, by using the sidecar API, it is possible to avoid directly incorporating policies into the DNS server software. However, in some cases, policies may be directly incorporated into the DNS server software.

[0119] In some cases, DNS caching may involve using a penalty box configured to block access to a specific website for a given amount of time (such as time to live, etc.). In these cases, the traffic routing and monitoring platform 102 may analyze the DNS query request (such as a DNS query request embedding a first identity) and respond accordingly (such as providing the domain and / or blocking the request based on the requested domain and amount of time). In some cases, a local cache (such as at the first client device 105, etc.) may be configured to avoid issuing further requests for the corresponding domain until a given amount of time has expired.

[0120] In some cases, generating a DNS query response embedding a first identity can involve generating multiple domains and / or other records (e.g., domain names, IP forwarding addresses, IPv6 addresses, email addresses, and / or other information). In these cases, the traffic routing and monitoring platform 102 can apply threat intelligence to the identified information and filter the information accordingly. For example, if three IP addresses are identified in response to a DNS query and two of the addresses correspond to known threats, the two malicious IP addresses can be removed from the response and only the remaining IP address can be returned in the response.

[0121] In some cases, generating a DNS query response embedding a first identity can involve verifying a downstream IP address before routing the DNS query response embedding the first identity to a corresponding downstream system. In doing so, the traffic routing and monitoring platform 102 can ensure that these downstream systems are not compromised and / or otherwise comply with the overall policy identified at step 206. This is described, for example, with respect to Figures 6A to 6D which is described. Referring to Figure 2C , at step 209, the traffic routing and monitoring platform 102 can forward the DNS query response embedding the first identity (e.g., 123.123.123.123) to the first client device 105. For example, the traffic routing and monitoring platform 102 can forward the IP address identified at step 208 (which can be, for example, the IP address of the target server 108). In some cases, the traffic routing and monitoring platform 102 can forward the DNS query response embedding the first identity to the first client device 105 during the secure session established at step 203.

[0122] At step 210, the first client device 105 can access the IP address received at step 209. For example, the first client device 105 can access data, content, and / or other information from the target server 108.

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

[0124] At step 212, the traffic routing and monitoring platform 102 may verify the second security certificate sent at step 211. In the case where the traffic routing and monitoring platform 102 verifies the second security certificate, 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). Otherwise, if the traffic routing and monitoring platform 102 is unable to verify the second security certificate, the traffic routing and monitoring platform 102 may not be able to proceed to step 213, but may wait until a security certificate is received from and verified by the second client device 106.

[0125] In some cases, when verifying the second security certificate and establishing a 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 cases, the traffic routing and monitoring platform 102 and the second client device 106 may initiate an encrypted DNS process (the encrypted DNS process may include verifying a third security certificate in accordance with RFC 7858 and / or RFC 8310), during which encrypted DNS query requests and encrypted DNS query responses may be exchanged between the traffic routing and monitoring platform 102 and the second client device 106. For example, the second client device 106 may notify 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 may respond to confirm the TLS parameters that can be used to secure the TLS channel. For example, the traffic routing and monitoring platform 102 may send a certificate identifying the traffic routing and monitoring platform 102 and a message including the digital signature of the traffic routing and monitoring platform 102, which can be verified by the second client device 106 (e.g., by checking a list of trusted authorities, public key pinning, and / or other methods). Once the handshake is complete, the traffic routing and monitoring platform 102 may exchange encrypted messages (e.g., DNS query requests, DNS query replies, and / or other information).

[0126] Reference Figure 2D , at step 213, the traffic routing and monitoring platform 102 may identify the user of the second client device 106. For example, based on the second security certificate, the traffic routing and monitoring platform 102 may identify the second user. For example, mutual X509 certificate authentication may be used to support authentication. In these cases, TLS-based DNS may be used to encrypt traffic using TLS over TCP and / or UDP, which may provide advantages over the HTTP protocol (which may not provide encryption itself). By managing the public key / private key infrastructure, the identity of the second user can be securely determined during the exchange process between the second client device 106 and the traffic routing and monitoring platform 102.

[0127] For example, the traffic routing and monitoring platform 102 can use a TLS-based DNS (e.g., UDP-based encryption) protocol with mutual X509 certificate authentication to identify the second user. In these cases, the enterprise environment can have an internal / local resolver (e.g., DNS with a directory service). Instructions for the local / internal resolver to resolve to the traffic routing and monitoring platform 102 can be provided to the second user. In these cases, when a high level of security is desired, TLS-based DNS can be used. A client certificate as well as instructions for the local resolver to resolve to the traffic routing and monitoring platform 102 using TLS-based DNS can be provided to the second user. In these cases, instructions to block outbound standard DNS and HTTPS-based DNS can be provided. Once received, the traffic routing and monitoring platform 102 can identify the second user based on the client certificate. This mutual authentication can provide technical advantages over other methods, such as increased security.

[0128] Although the identification of the second user is described at step 213 (e.g., before sending a DNS query request embedding the second identity), in some cases, the identification can be performed based on information received in the DNS query request embedding the second identity further described below at step 214. Accordingly, the identification of the second user can occur before or after receiving the DNS query request embedding the second identity without departing from the scope of the present disclosure.

[0129] At step 214, once a secure session has been established between the second client device 106 and the traffic routing and monitoring platform 102, the second client device 106 can send a DNS query request (fully encrypted DNS request, partially encrypted DNS request, unencrypted DNS request, etc.) embedding the second identity to the traffic routing and monitoring platform 102, where the user identity exists in a certificate, is embedded in the DNS protocol itself, and / or is embedded in other ways. For example, the second client device 106 can send the domain name of the target server 108 and can request the IP address of the target server 108. For example, the second client device 106 can establish a TLS session through which a DNS query request embedding the second identity can be securely issued. For example, the TLS session can be via TCP, UDP, and / or other means. Additionally or alternatively, the second client device 106 can establish an HTTP session through which a DNS query request can be issued. For example, the HTTP session can be unencrypted via TCP, UDP, etc., or encrypted via a TLS session. In some cases, the second client device 106 (e.g., the network interface of the second client device 106) can be preconfigured to direct DNS queries to the traffic routing and monitoring platform 102. For example, the second security certificate can be installed at the second client device 106 before sending a DNS query request embedding the second identity. In some cases, when sending a DNS query request embedding the second identity, the second client device 106 can access the Internet from outside the protected network. In some cases where the DNS query request embedding the second identity is encrypted, the traffic routing and monitoring platform 102 can use the second security certificate to decrypt the DNS query request embedding the second identity. For example, different security certificates can be installed at the same device for different browsers, and different security policies can be applied depending on which certificate is presented. In these cases, if the traffic routing and monitoring platform 102 has not received the second security certificate, the traffic routing and monitoring platform 102 can prompt the second client device 106 to provide the second security certificate.

[0130] In some cases, the actions performed at step 214 can be similar to the actions described above at step 205 regarding the first client device 105. For example, in some cases, a user identity (e.g., based on attributes such as a profile, application, operating system, device, network, cluster, wireless access point (WAP) IP, and / or other identifiers) can be received (e.g., via DoH) along with a DNS query request embedding the second identity, which can be used to distinguish different profiles / identities of the second user. In some cases, the same as described at step 205 regarding the DNS query request embedding the first identity and as described below regarding Figure 4Further illustrated techniques similar to the techniques embed one or more identities into a DNS query request that embeds a second identity.

[0131] At 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 can maintain a database of traffic routing rules corresponding to each of a plurality of users, and can identify (e.g., by indexing the database) the second traffic routing rule corresponding to the second user. In some cases, when identifying the second traffic routing rule, the traffic routing and monitoring platform 102 can identify the domain matching criteria and corresponding actions to be performed for each of a plurality of domain names (including the domain name sent in the DNS query request that embeds the second identity), both the domain matching criteria and the corresponding actions can be specific to the second user. For example, the second traffic routing rule can be specific to the organization of the second user, the subscription level of the second user (which can provide, for example, a unique security level and / or be selected or otherwise registered by the second user), geographical location, and / or other user characteristics. In other cases, the second traffic routing rule can be common among all network users (including the second user). In some cases, when identifying the domain matching criteria of the second traffic routing rule, the traffic routing and monitoring platform 102 can identify a whitelist, blacklist, and / or monitoring list specific to the second user. In these cases, each of the plurality of domain names can be on one of the whitelist, blacklist, and monitoring list. In some cases, the second traffic routing rule can be associated with a protected network (e.g., an enterprise or other secure network).

[0132] In some cases, the second traffic routing rule can be selected based on the specific user identity of the second user (e.g., a rule corresponding to the second user using a first browser rather than a second browser, etc.). In some cases, this can be similar to the selection of the policy / first traffic routing rule described with respect to step 206 and as further Figure 4 described. In some cases, the policy can be distributed, cached, and / or otherwise controlled by the intelligent policy manager system, as described with respect to step 206 and Figure 5 described.

[0133] At step 216, the traffic routing and monitoring platform 102 can identify the actions to be performed on the DNS query request embedding the second identity 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 the traffic directed to the IP address requested by the DNS query request embedding the second identity (the IP address can, for example, correspond to the target server 108) based on the second traffic routing rule. For example, the traffic routing and monitoring platform 102 can identify that the IP address corresponding to the blacklisted domain should be blocked, the access permission should be granted to the IP address corresponding to the whitelisted domain, and the traffic to and from the IP address corresponding to the monitored list domain should be monitored / recorded. For illustrative purposes, at step 216, the traffic routing and monitoring platform 102 can identify that the traffic directed to the IP address requested by the DNS query request embedding the second identity should be blocked (for example, because the domain name included in the DNS query request embedding the second identity corresponds to a potential security threat for which the traffic should be blocked).

[0134] At step 217, the traffic routing and monitoring platform 102 can send a DNS query response embedding the second identity to the second client device 106. In some cases, the generation of the DNS query response embedding the second identity can involve DNS caching as described above at step 208 for the DNS query response embedding the first identity. However, instead of sending the IP address requested by the DNS query response embedding the second identity, based on identifying that the domain name of the DNS query request embedding the second identity corresponds to a potential security threat for which the traffic should be blocked, the traffic routing and monitoring platform 102 can send a DNS query response embedding the second identity indicating that the requested IP address has been blocked and / or otherwise preventing the second client device 106 from accessing the requested IP address. For example, the traffic routing and monitoring platform 102 can send a notification that the requested IP address has been blocked, the IP address of the blocked notification page, and / or other information indicating that the requested IP address has been blocked. In some cases, the traffic routing and monitoring platform 102 can send the DNS query response embedding the second identity to the second client device 106 via a wired or wireless data connection.

[0135] At step 218, the second client device 106 may display a DNS query response embedding a second identity (the DNS query response embedding the second identity may be decrypted for display, for example). For example, the second client device 106 may display a graphical user interface indicating that the requested IP address has been blocked. In some cases, the second client device 106 may receive user feedback indicating that the requested IP address has been misjudged (e.g., incorrectly 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 it receives such misjudgment feedback for the requested IP address from more than a threshold number of users. Once it receives such misjudgment feedback 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 alternatively be permitted (and thus, future DNS requests for the requested IP address may follow a procedure similar to the one described above for DNS query requests embedding a first identity). 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 (which may, for example, continuously improve the performance and effectiveness of the second traffic routing rule).

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

[0137] At step 220, the traffic routing and monitoring platform 102 may verify the third security certificate sent at step 219. In the case where the traffic routing and monitoring platform 102 verifies the third security certificate, 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). Otherwise, if the traffic routing and monitoring platform 102 is unable to verify the third security certificate, the traffic routing and monitoring platform 102 may not be able to proceed to step 221, but may wait until it receives and verifies a security certificate from the third client device 107.

[0138] In some cases, when verifying the third security certificate and establishing a 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 cases, the traffic routing and monitoring platform 102 and the third client device 107 may initiate an encrypted DNS process (the encrypted DNS process may include verifying the third security certificate in accordance with RFC 7858 and / or RFC 8310), during which encrypted DNS query requests and encrypted DNS query responses may be exchanged between the traffic routing and monitoring platform 102 and the third client device 107. For example, the third client device 107 may notify the traffic routing and monitoring platform 102 of its TLS capabilities (which may include, for example, in the third security certificate), and the traffic routing and monitoring platform 102 may respond to confirm the TLS parameters that can be used to secure the TLS channel. For example, the traffic routing and monitoring platform 102 may send a certificate identifying the traffic routing and monitoring platform 102 and a message including the digital signature of the traffic routing and monitoring platform 102, which can be verified by the third client device 107 (e.g., by checking a list of trusted authorities, public key pinning, and / or other methods). Once the handshake is complete, the traffic routing and monitoring platform 102 may exchange encrypted messages (e.g., DNS query requests, DNS query replies, and / or other information).

[0139] Reference Figure 2F , at step 221, the traffic routing and monitoring platform 102 may identify the user of the third client device 107. For example, based on the third security certificate, the traffic routing and monitoring platform 102 may identify the third user. For example, mutual X509 certificate authentication may be used to support authentication. In these cases, TLS-based DNS may be used to encrypt traffic over the UDP rather than the HTTP protocol. By managing the public key / private key infrastructure, the identity of the third user can be securely determined during the exchange process between the third client device 107 and the traffic routing and monitoring platform 102.

[0140] For example, the traffic routing and monitoring platform 102 can identify a third user using mutual X509 certificate authentication using a TLS-based DNS (e.g., UDP-based encryption) protocol. In these cases, the enterprise environment can have an internal / local resolver (e.g., a DNS with a directory service such as a directory service like Microsoft Active Directory (AD)). Instructions can be provided to the third user for the local / internal resolver to resolve to the traffic routing and monitoring platform 102. In these cases, when a higher security level is desired, a TLS-based DNS can be used. A client certificate can be provided to the third user along with instructions for the local resolver to resolve to the traffic routing and monitoring platform 102 using the TLS-based DNS. In these cases, instructions can be provided to block outbound standard DNS and HTTPS-based DNS. Once received, the traffic routing and monitoring platform 102 can identify the third user based on the client certificate. This mutual authentication can provide technical advantages over other methods, such as increased security.

[0141] Although the identification of the third user is described at step 221 (e.g., before sending a DNS query request embedding the first identity), in some cases, this identification can be performed based on information received in a DNS query request embedding the third identity, as further described below at step 222. Accordingly, the identification of the third user can occur before or after receiving the DNS query request embedding the third identity without departing from the scope of the present disclosure.

[0142] At step 222, once a secure session has been established between the third client device 107 and the traffic routing and monitoring platform 102, the third client device 107 can send a DNS query request (fully encrypted DNS request, partially encrypted DNS request, unencrypted DNS request, etc.) embedding the third identity to the traffic routing and monitoring platform 102, where the user identity exists in a certificate, is embedded in the DNS protocol itself, and / or is embedded in other ways. For example, the third client device 107 can send the domain name of the target server 108 and can request the IP address of the target server 108. For example, the third client device 107 can establish a TLS session through which a DNS query request embedding the third identity can be securely issued. For example, the TLS session can be via TCP, UDP, and / or other means. Additionally or alternatively, the third client device 107 can establish an HTTP session through which a DNS query request can be issued. For example, the HTTP session can be unencrypted via TCP, UDP, etc., or encrypted via a TLS session. In some cases, the third client device 107 (e.g., the network interface of the third client device 107) can be pre-configured to direct DNS queries to the traffic routing and monitoring platform 102. For example, the third security certificate can be installed at the third client device 107 before sending a DNS query request embedding the third identity. In some cases, when sending a DNS query request embedding the third identity, the third client device 107 can access the Internet from outside the protected network corresponding to the traffic routing and monitoring platform 102 and / or the proxy server 103. In some cases, the traffic routing and monitoring platform 102 can use the third security certificate to decrypt the DNS query request embedding the third identity. In these cases, if the traffic routing and monitoring platform 102 has not received the third security certificate, the traffic routing and monitoring platform 102 can prompt the third client device 107 to provide the third security certificate.

[0143] In some cases, the actions described at step 222 can be similar to the actions described above at step 205 regarding the first client device 105 and / or at step 214 regarding the second client device 106. For example, in some cases, the user identity and a DNS query request embedding the third identity can be received (e.g., via DoH), and the DNS query request embedding the third identity can be used to distinguish different profiles / identities of the third user (as further illustrated and described below). Figure 4 Further illustrated and described).

[0144] At step 223, the traffic routing and monitoring platform 102 may 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 may identify (e.g., by indexing the database) the third traffic routing rule corresponding to the third user. In some cases, when identifying the third traffic routing rule, the traffic routing and monitoring platform 102 may identify domain matching criteria and corresponding actions to be performed for each of a plurality of domain names (including the domain names sent in the DNS query response embedding the third identity), both the domain matching criteria and the corresponding actions may be specific to the third user. For example, the third traffic routing rule may be specific to the organization of the third user, the subscription level of the third user (which may provide a unique security level and / or be selected or otherwise registered by the third user), geographical location, and / or other user characteristics. In other cases, the third traffic routing rule may be common among all network users (including the third user). In some cases, when identifying the domain matching criteria of the third traffic routing rule, the traffic routing and monitoring platform 102 may identify a whitelist, blacklist, and / or watchlist specific to the third user. In these cases, each of the plurality of domain names may be included in one of the whitelist, blacklist, and watchlist. In some cases, the third traffic routing rule may be associated with a protected network (e.g., an enterprise or other secure network).

[0145] In some cases, the third traffic routing rule may be selected based on the specific user identity of the third user (e.g., a rule corresponding to the third user using a first browser instead of a second browser, etc.). In some cases, these third traffic routing rules may be selected using a method similar to the methods described above with respect to step 206 and / or 215 as related to the first and / or second traffic routing rules and / or as further described Figure 4 In step 206 and / or 215. In some cases, the policies may be distributed, cached, and / or otherwise controlled by an intelligent policy manager system, as described with respect to step 206 and / or step 215 and Figure 5 as described.

[0146] At step 224, the traffic routing and monitoring platform 102 can identify actions to be performed on DNS query requests embedding a third identity based on the third traffic routing rule. For example, the traffic routing and monitoring platform 102 can, based on the third traffic routing rule, identify whether to allow, block, and / or monitor traffic directed to the IP address requested by the DNS query request embedding the third identity (which IP address can, for example, correspond to the target server 108). For example, the traffic routing and monitoring platform 102 can identify that the IP address corresponding to a domain on the blacklist should be blocked, access rights should be granted to the IP address corresponding to a domain on the whitelist, and traffic to and from the IP address corresponding to a domain on the surveillance list should be monitored / recorded. In some cases, when identifying actions to be performed on DNS query requests embedding a third identity, the traffic routing and monitoring platform 102 can identify a disposition (e.g., allow or block), and can then identify corresponding instructions (e.g., perform an inspection, monitor, record, alert, perform a packet capture, perform a payload inspection, and / or other actions). For example, these instructions can be executed in addition to the "allow" or "block" disposition. For illustrative purposes, at step 224, the traffic routing and monitoring platform 102 can, based on the third traffic routing rule, identify that traffic directed to the IP address requested by the DNS query request embedding the third identity should be recorded. For example, the traffic routing and monitoring platform 102 can, based on the third traffic routing rule, identify that the domain name sent in the DNS query request embedding the third identity corresponds to a potential security threat and is listed on the surveillance list (and thus identify that traffic to and from the corresponding IP address should be recorded).

[0147] Reference Figure 2G, at step 225, the traffic routing and monitoring platform 102 can identify the IP address requested by the DNS query request embedding the third identity (e.g., by performing actions similar to those described at step 208). In some cases, the generation of the DNS query response embedding the third identity may involve DNS caching as described above at step 208 for the DNS query response embedding the first identity. However, instead of simply forwarding the IP address to the third client device 107, based on identifying that the domain name of the DNS query request embedding the third identity corresponds to a potential security threat for which traffic should be recorded, the traffic routing and monitoring platform 102 can send a DNS query response embedding the third identity that includes the IP address of the proxy server 103 (e.g., 111.111.111.111). In some cases, the traffic routing and monitoring platform 102 can also include routing instructions (e.g., for traffic to be directed through the proxy server 103) within the DNS query response embedding the third identity. In some cases, the proxy can be used to include the routing instructions and the IP address of the proxy server 103 without eliminating the IP address for the requested domain name from the DNS query response embedding the third identity.

[0148] In some cases, the traffic routing and monitoring platform 102 can send a DNS query response embedding the third identity that includes both the requested IP address and the proxy IP address. For example, the traffic routing and monitoring platform 102 can send a DNS query response embedding the third identity that includes the requested IP address embedded within the proxy IP address. In some cases, the DNS query response embedding the third identity can include a DNS record associating the domain name with the proxy IP address and a time to live (e.g., the period of time the DNS query response embedding the third identity can exist before expiration). In some cases, the traffic routing and monitoring platform 102 can send the DNS query response embedding the third identity to the third client device 107 when establishing a secure session with the third client device 107.

[0149] At step 226, the third client device 107 may access the target server 108 via the proxy server 103. For example, the third client device 107 may send traffic (e.g., referred to herein as outbound network traffic) to the proxy server 103 using a proxy IP address. In these cases, the third client device 107 may indicate the proxy IP address as the destination IP address and may include data directed to the domain name included in the DNS query request embedding the third identity. In some cases, the third client device 107 may also send a third security certificate to the proxy server 103. For example, in some cases the proxy server 103 may prompt the third client device 107 to provide the third security certificate to the proxy server 103, and the third client device 107 may send the third certificate accordingly (which may, for example, enable the proxy server 103 to identify the third user and / or the third client device 107). In doing so, the proxy server 103 may be configured to distinguish requests from different users on the same device (e.g., compared to an IP address-based method which may not be able to distinguish different users on the same device).

[0150] In cases where the DNS query response embedding the third identity includes a time to live, the third client device 107 may, in some cases, determine the expiration of the DNS record, which includes the expiration of the DNS record of the proxy IP address. In these cases, instead of accessing the proxy server 103, the third client device 107 may return to step 222 (e.g., to request an updated DNS response). In some cases, the third traffic routing rule may have been updated during the lifetime of the DNS record. For example, the third traffic routing rule may have been updated to indicate that traffic should be blocked or allowed to reach the requested IP address. In these cases, actions similar to those described above with respect to the DNS query response embedding the first identity and the DNS query response embedding the second identity (e.g., regarding allowing or blocking traffic) may be performed by the traffic routing and monitoring platform 102 and / or the proxy server 103. In some cases, any intelligence corresponding to the third user and / or the domain name included in the DNS query request embedding the third identity (e.g., as identified by the traffic routing and monitoring platform 102) may be sent to the proxy server 103 along with the traffic.

[0151] At 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 certificate, the proxy server 103 may identify the third user (e.g., using techniques similar to those described above at step 221). Additionally or alternatively, the proxy server 103 may receive information indicating the identity of the third user (e.g., received from the traffic routing and monitoring platform 102 once identified at step 221).

[0152] Once the identity of the third user is determined by the proxy server 103, the proxy server 103 may identify traffic monitoring rules based on the identity of the third user. In some cases, these traffic monitoring rules may be the same as the third traffic monitoring rules identified at step 223. In other cases, these traffic monitoring rules may be different traffic monitoring rules from those identified at step 223. For example, the proxy server 103 may maintain a database of traffic routing rules corresponding to each of a plurality of users and may identify (e.g., by indexing the database) the traffic monitoring rules corresponding to the third user. In some cases, the traffic monitoring rules may indicate traffic associated with a potential security threat for which traffic should be logged / monitored, metadata to be collected for traffic associated with the potential security threat, sampling rate, sampling frequency, and / or other information.

[0153] After identifying the traffic monitoring rules, the proxy server 103 may identify actions to be performed regarding the traffic received from the third client device 107 based on these traffic monitoring rules. For example, the proxy server 103 may identify traffic recording actions / policies for the third user. In doing so, the proxy server 103 may apply an additional layer of policy customization based on user identity (e.g., in addition to the third traffic routing rules determined at step 223).

[0154] At step 228, the proxy server 103 may record / monitor information on outbound traffic (e.g., traffic sent from the third client device 107 to the proxy server 103). In some cases, the terms record and monitor may be used interchangeably throughout this specification and may 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 record the information in a stored data log. In some cases, the proxy server 103 may record information based on traffic monitoring rules (e.g., specifying metadata, at a specified rate / frequency, and / or others), which may be specific to the third user as described above, for example. For example, the proxy server 103 may record one or more of the following: sender domain, recipient domain, time information, date information, and / or other information. In some cases, the proxy server 103 may perform real-time recording.

[0155] Reference Figure 2H , at step 229, the proxy server 103 may identify 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 proxy IP address, which may include the destination IP address embedded within the proxy IP address in some cases. In some cases, the proxy server 103 may resolve the destination IP address after receiving the outbound traffic. After identifying 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).

[0156] At step 230, the target server 108 may send inbound traffic (e.g., in response to the outbound traffic sent at step 229) to the proxy server 103 (e.g., via a wired or wireless data connection).

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

[0158] In some cases, the proxy server 103 can update the traffic monitoring rules based on the recorded information. For example, the proxy server 103 can increase, decrease, or maintain the frequency of recording traffic information. For example, if malicious activity is identified (e.g., within a predetermined time period, after detecting a predetermined amount of traffic, and / or otherwise), the proxy server 103 can modify the traffic monitoring rules to record traffic information at an increased frequency. Alternatively, if no malicious activity is identified (e.g., within a predetermined time period, after detecting a predetermined amount of traffic, and / or otherwise), the proxy server 103 can modify the traffic monitoring rules to decrease the frequency of recording traffic information.

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

[0160] At step 233, the proxy server 103 can send the stored data log to the traffic routing and monitoring platform 102 (e.g., via a wired or wireless data connection). Although step 233 is shown after routing the inbound and outbound traffic, this is for illustrative purposes only. For example, the data log can be shared continuously between the proxy server 103 and the traffic routing and monitoring platform 102 in real time and / or at predetermined intervals when recording traffic in some cases. For example, in some cases, the data log can be made available in real time to enable immediate actions based on the data log. For example, the data log can be provided to the traffic routing and monitoring platform 102 so that the traffic routing and monitoring platform 102 can update the third traffic routing rule and / or other intelligence based on the data log. In doing so, the traffic routing rules can be updated continuously and dynamically on a per-user basis (regardless of whether a user has multiple devices and / or multiple users use the same device).

[0161] At step 234, the traffic routing and monitoring platform 102 may update the third traffic routing rule based on the stored data logs. For example, the traffic routing and monitoring platform 102 may update the actions to be performed for a third user at the IP address corresponding to the target server 108. For example, if malicious activity is identified (e.g., within a predetermined time period, after detecting a predetermined amount of traffic, and / or others), the traffic routing and monitoring platform 102 may modify the third traffic routing rule so that the traffic directed to the target server 108 is blocked. Alternatively, if no malicious activity is identified (e.g., within a predetermined time period, after detecting a predetermined amount of traffic, and / or others), the traffic routing and monitoring platform 102 may modify the third traffic routing rule so that the traffic directed to the target server 108 is allowed 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 recorded activities (which may, for example, continuously improve the performance and effectiveness of the third traffic routing rule). An example of such modification and processing of different records that the DNS system may return and / or request is shown in the table below.

[0162]

[0163]

[0164]

[0165] Although the DNS query requests embedding the first identity, the DNS query requests embedding the second identity, and the DNS query requests embedding the third identity are described as including domain names corresponding to the IP address of the target server 108, this is for illustrative purposes only, and the DNS query may request different IP addresses without departing from the scope of the present disclosure. Additionally, although a single proxy server 103 is shown, any number of proxy servers may be implemented without departing from the scope of the present disclosure. For example, in some cases, different users (or groups of users) may be directed to different proxy servers.

[0166] Although steps 225 to 234 describe using proxy server 103 to perform traffic monitoring and / or recording, in some cases, steps 225 to 234 can be replaced by steps 235 to 242, which are described below and illustrate using gateway server 115 (instead of proxy server 103) to perform traffic monitoring and recording. In some cases, the techniques described below can address current deficiencies when using a proxy server. For example, in the case where grey zone traffic (e.g., traffic to be recorded, monitored, etc. by proxy server 103) is to be directed to proxy server 103, the DNS response must be modified to include the IP address of the proxy server (e.g., instead of the requested IP address). However, in these cases, any connection between the requested IP address and its corresponding DNS record may be lost (e.g., due to replacing the requested IP address with the proxy IP address). Accordingly, in some cases, redirection to proxy server 103 may be successful for HTTP requests, but may be limited when used for other protocols (e.g., File Transfer Protocol (FTP), etc.). For example, requests implemented across such other protocols may not include the original intent associated with the request (e.g., the intent to access target server 108), etc. Accordingly, to support traffic recording / monitoring for traffic of these other protocols, proxy server 103 can be replaced by using gateway server 115 (as described herein).

[0167] At step 235, traffic routing and monitoring platform 102 can identify the IP address requested by a DNS query request embedding a third identity (e.g., by performing actions similar to those described at steps 208 and / or 225). In some cases, the generation of a DNS query response embedding a third identity can involve DNS caching as described above at step 208 regarding DNS query responses embedding a first identity. However, instead of simply forwarding the IP address to third client device 107, based on identifying that the domain name of the DNS query request embedding a third identity corresponds to a potential security threat for which traffic should be recorded, traffic routing and monitoring platform 102 can send a DNS query response embedding a third identity including the requested IP address (e.g., 123.123.123.123) and a routing instruction that can, for example, cause traffic routing and monitoring flat 102 to route traffic via gateway server 115 to the IP address (e.g., of target server 108) (e.g., by including the IP address of gateway server 115 in the routing instruction). In some cases, any remaining traffic (e.g., corresponding to domain names, IP addresses, etc.) not corresponding to a potential security threat can be directly routed to the requested IP address.

[0168] In some cases, the third client device 107 may be pre-configured with a proxy that can be configured, for example, to interpret routing instructions and direct traffic to the target server 108 via the gateway server 115. For example, the proxy may encapsulate the connection between the third client device 107 and the target server 108 but route the traffic to the gateway server 115 instead of the target server 108 (e.g., tunnel the traffic across the gateway server 115). This can effectively utilize the traffic routing and monitoring platform 102 to create an on-demand router that can enable IP protocol communications of any type of corresponding protocol to be redirected and / or steered to a specified tunnel gateway.

[0169] By doing so, the traffic routing and monitoring platform 102 can achieve monitoring / recording of traffic without replacing the IP address for the requested domain name and thus changing the destination IP address. Instead, the traffic routing and monitoring platform 102 can modify the way the traffic is routed to the destination IP address (e.g., compared to the method described at step 225, where the requested IP address is replaced with the IP address of the proxy server 103).

[0170] As an additional advantage over using the proxy server 103, this gateway method can convey identity more effectively. For example, if the proxy IP address is returned to the third client device 107, it may be difficult to authenticate the corresponding user's identity when the user connects to the proxy server 103 via certain protocols. However, by providing the requested IP address along with the routing instructions for the gateway server 115, the user identity can be effectively conveyed regardless of the protocol, port, etc. For example, since the proxy may know the user identity, the proxy can configure the gateway tunnel based on the known identity and can route the traffic through the tunnel accordingly (the tunnel can convey, for example, both the expected destination of the target server 108 and the user identity).

[0171] As yet another additional advantage of using proxy server 103, the gateway approach may be more effective in conveying the identity context received from the third client device 107. For example, in the case where traffic is routed to the proxy server 103, once the traffic is received, the proxy server 103 can terminate the connection with the third client device 107 and can accordingly establish a new connection with the target server 108 to route the traffic. In some cases, the proxy server 103 terminating the connection (with the third client device 107) may pose challenges in conveying the identity and / or other information. For example, the IP address of the proxy server 103 may be provided to the third client device 107, and the third client device may accordingly use that IP address to connect to the proxy server 103. Once the traffic is received at the proxy server 103, the proxy server 103 can terminate the connection with the third client device 107 and then form a new connection outwards to the target server 108 through which the traffic is passed. Accordingly, the proxy server 103 can introduce a termination endpoint to the initial connection with the third client device 107. This may make it difficult to bind the original DNS request (e.g., a DNS query request embedding a third identity) to the user identity. For example, if a DNS query response embedding a third identity indicating the proxy IP address is cached (e.g., on a local resolver, etc.), other users may access the proxy IP address without an existing DNS record. This may lead to information loss and correlation difficulties. In contrast, using the gateway server 115 can allow the initially established connection with the third client device 107 to be maintained and, alternatively, the connection can be modified and / or otherwise encapsulated. In these cases, the proxy can bind the user identity to the encapsulation and thus provide an identity context for all corresponding traffic (the identity context can include, for example, identity information, time information, IP address information, etc. that can indicate why the encapsulation tunnel was established) without changing any headers or aspects of the corresponding payload. Accordingly, by implementing the gateway server 115, the identity and the communication can be bound together without terminating such correlation at the proxy server 103.

[0172] As yet another additional advantage, existing client devices may not be configured such that only a portion of their traffic (e.g., traffic to known bad IP addresses, etc.) is routed via a proxy server, where the remaining traffic is sent directly to the corresponding target server. Instead, such traffic may be routed either all or not at all through the proxy server. Accordingly, by implementing the techniques described herein, the gateway server 115 can be applied at a higher level of granularity to receive and subsequently record / monitor a subset of the traffic that the gateway server is policy required and / or otherwise defined for.

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

[0174] In some cases where a proxy is preconfigured on the third client device 107, as an alternative to routing traffic through the proxy server 103 (as described above with respect to steps 225 to 234) or the gateway server 115 (as described here with respect to steps 235 to 242), the traffic routing and monitoring platform 102 can send the identified disposition (e.g., block or allow) and / or instructions (e.g., perform inspection, monitoring, logging, alerting, perform packet capture, perform payload inspection, and / or other actions), which may have been identified using techniques similar to those described with respect to DNS query requests embedding the first identity, DNS query requests embedding the second identity, and / or DNS query requests embedding the third identity, to the third client device 107 (e.g., as part of a DNS query response embedding the third identity) for local storage. In some cases, along with the identified disposition / instructions, the traffic routing and monitoring platform 102 can provide the requested IP address. In these cases, the third client device 107 can execute, enforce, and / or otherwise implement the disposition and / or instructions themselves for traffic between the third client device 107 and the target server 108 (e.g., rather than performing these actions at the traffic routing and monitoring platform 102, proxy server 103, gateway server 115, etc.). In some cases, the third client device 107 can store these dispositions and / or instructions (e.g., update the locally cached rule set), and in some cases can automatically enforce these dispositions and / or instructions for future requests to the requested IP address (associated with the same identity). In some cases, these techniques can implement one or more aspects of the techniques described in U.S. Patent No. 11,012,417, filed April 30, 2019, and titled "METHODS AND SYSTEMS FOR EFFICIENT PACKET FILTERING" and / or U.S. Patent No. 11,012,414, filed November 22, 2019, and titled "METHODS AND SYSTEMS FOR PREVENTION OF ATTACKS ASSOCIATED WITH THE DOMAIN NAME SYSTEM", the disclosures of which are incorporated herein by reference in their entirety. In some cases, these dispositions and / or instructions can be stored using an efficient data structure that enables these dispositions and / or instructions to be implemented by the third client device 107 itself.In some cases, these techniques can implement one or more aspects of the techniques described in U.S. Patent No. 10,715,493, filed on July 3, 2019, and titled "METHODS AND SYSTEMS FOR EFFICIENT CYBERPROTECTIONS OF MOBILE DEVICES", the disclosure of which is incorporated herein by reference in its entirety. In some cases, this can include routing DNS query requests with embedded identities by the third client device 107 via a virtual private network (VPN). In some cases, these techniques can implement one or more aspects of the techniques described in U.S. Patent No. 11,582,191, filed on February 10, 2022, and titled "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 the third client device 107 with relevant dispositions and / or instructions corresponding to the requested IP address, the traffic routing and monitoring platform 102 can optimize the policy storage at the third client device 107 by performing ad hoc rule delivery (e.g., providing relevant policy information (e.g., dispositions and / or instructions) for a given IP address only for a given identity). In some cases where the policy information is updated (e.g., at the traffic routing and monitoring platform 102), the locally stored policy information (e.g., at the third client device 107) can be updated accordingly.

[0175] Returning to the gateway embodiment described with respect to steps 235 through 243, the traffic routing and monitoring platform 102 can send a DNS query response with an embedded third identity that includes both the requested IP address and the proxy IP address. For example, the traffic routing and monitoring platform 102 can send a DNS query response with an embedded third identity that includes the requested IP address embedded within the proxy IP address. In some cases, the DNS query response with an embedded third identity can include a DNS record associating the domain name with the proxy IP address and a time to live (e.g., the period of time that the DNS query response with an embedded third identity can exist before expiration). In some cases, the traffic routing and monitoring platform 102 can send the DNS query response with an embedded third identity to the third client device 107 when establishing a secure session with the third client device 107.

[0176] At step 236, the third client device 107 may access the target server 108 via the gateway server 115. For example, the third client device 107 may send traffic (e.g., referred to herein as outgoing network traffic) to the gateway server 115 based on a routing instruction. In these cases, the third client device 107 may indicate the requested IP address as the destination IP address and may include data directed to the domain name included in the DNS query request that embeds the third identity. In some cases, the third client device 107 may include identity information as part of the DNS query request that embeds the identity, which may enable the gateway server 115 to distinguish requests from different users on the same device (e.g., compared to an IP address-based method that may not be able to distinguish different users on the same device).

[0177] In cases where the DNS query response that embeds the third identity includes a time to live, the third client device 107 may, in some cases, determine the expiration of the DNS record, which includes the expiration of the DNS record of the target server 108. In these cases, instead of 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 cases, the third traffic routing rule may have been updated during the lifetime of the DNS record. For example, the third traffic routing rule may have been updated to indicate that traffic should be blocked or allowed to reach the requested IP address. In these cases, actions similar to those described above with respect to the DNS query responses that embed the first identity and the second identity (e.g., regarding allowing or blocking traffic) may be performed by the traffic routing and monitoring platform 102 and / or the proxy server 103. In some cases, any intelligence corresponding to the third user and / or the domain name included in the DNS query request that embeds the third identity (e.g., as identified by the traffic routing and monitoring platform 102) may be sent to the gateway server 115 along with the traffic.

[0178] Reference Figure 2J, at step 237, the gateway server 115 may record / monitor information on outbound traffic (e.g., traffic sent from the third client device 107 to the gateway server 115). As described above, in some cases, the terms record and monitor may be used interchangeably throughout this specification and may 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 record the information in the stored data log. In some cases, the gateway server 115 may record information based on traffic monitoring rules (e.g., specifying metadata, at a specified rate / frequency, and / or otherwise), which may be specific to the third user as described above, for example. For example, the gateway server 115 may record one or more of the following: sender domain, recipient domain, time information, date information, and / or other information. In some cases, the gateway server 115 may perform real-time recording.

[0179] At step 238, the gateway server 115 may identify 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 a DNS query request embedding the third identity (which may include the destination IP address, for example). After identifying 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).

[0180] At step 239, the target server 108 may send inbound traffic (e.g., in response to the outbound traffic sent at step 238) to the gateway server 115 (e.g., via a wired or wireless data connection).

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

[0182] In some cases, the gateway server 115 may increase, decrease, or maintain the frequency of recording traffic information. For example, if malicious activity is identified (e.g., within a predetermined time period, after detecting a predetermined amount of traffic, and / or otherwise), traffic is recorded at an increased frequency. Alternatively, if no malicious activity is identified (e.g., within a predetermined time period, after detecting a predetermined amount of traffic, and / or otherwise), the proxy server 103 may modify and decrease the frequency of recording traffic information.

[0183] Reference Figure 2K , at step 241, the gateway server 115 may route the inbound traffic to the third client device 107 (e.g., via a wired or wireless data connection).

[0184] At step 242, the gateway server 115 may send the stored data log to the traffic routing and monitoring platform 102 (e.g., via a wired or wireless data connection). Although step 242 is shown after routing the inbound and outbound traffic, this is for illustrative purposes only. For example, the data log may be shared continuously between the gateway server 115 and the traffic routing and monitoring platform 102 in real time and / or at predetermined intervals when recording traffic in some cases. For example, in some cases, the data log may be made available in real time to enable immediate actions based on the data log. For example, the data log may be provided to the traffic routing and monitoring platform 102 so that the traffic routing and monitoring platform 102 can update the third traffic routing rule and / or other intelligence based on the data log. In doing so, the traffic routing rule may be updated continuously and dynamically on a per-user basis (regardless of whether the user has multiple devices and / or multiple users use the same device).

[0185] At step 243, the traffic routing and monitoring platform 102 may update the 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 performed for the third user at the IP address corresponding to the target server 108. For example, if malicious activity is identified (e.g., within a predetermined time period, after detecting a predetermined amount of traffic, and / or otherwise), the traffic routing and monitoring platform 102 may modify the third traffic routing rule to block the traffic directed to the target server 108. Alternatively, if no malicious activity is identified (e.g., within a predetermined time period, after detecting a predetermined amount of traffic, and / or otherwise), the traffic routing and monitoring platform 102 may modify the third traffic routing rule to allow the 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 recorded activities (which may, for example, continuously improve the performance and effectiveness of the third traffic routing rule).

[0186] Although the DNS query requests embedding the first identity, the DNS query requests embedding the second identity, and the DNS query requests embedding the third identity are described as including domain names 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 the present disclosure. Additionally, although a single gateway server 115 is shown, any number of gateway servers may be implemented without departing from the scope of the present disclosure. For example, in some cases, different users (or groups of users) may be directed to different gateway servers. Further, although the methods for allowing, blocking, and logging traffic are shown in sequence, this is for illustrative purposes only, and requests may be allowed, blocked, and logged simultaneously and / or in any other order without departing from the scope of the present disclosure.

[0187] Figure 3 An illustrative method for traffic routing and monitoring in accordance with one or more example embodiments is depicted. Referring Figure 3 , at step 305, a computing platform having at least one processor, a communication interface, and a memory may issue a security certificate to a client device. For example, the computing platform may issue a certificate that can identify the client device and / or the user of the client device. In some cases, the security certificate may be used to establish a secure session and / or a secure DNS channel between the computing platform and the security certificate.

[0188] At step 310, the computing platform may receive the security certificate and a request to establish a secure session from the client device. In some cases, the request may indicate an intention to establish a secure DNS channel between the computing platform and the client device.

[0189] At step 315, the computing platform may verify the security certificate. For example, the computing platform may perform a handshake with the client device, where the computing platform verifies the security certificate and the client device authenticates information of the computing platform (e.g., certificate, signature, and / or other authentication mechanisms). If the security certificate fails verification, the computing platform may return to step 310. If the security certificate passes verification, the computing platform may proceed to step 320.

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

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

[0192] At step 330, the computing platform can identify the user of the client device based on the security certificate. At step 335, the computing platform can identify the traffic routing rules based on the user identity. For example, the computing platform can index a database based on the user identity to identify the corresponding traffic routing rules, which can indicate whether the traffic directed to a specific IP address should be blocked, allowed, or logged.

[0193] At step 340, the computing platform can provide the encrypted DNS query response to the client device based on the traffic routing rules. 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 can provide the requested IP address as the 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 can provide an indication that the requested IP address is inaccessible as the 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 can provide the IP address of a proxy server that can be configured to monitor the traffic between the user device and the target server corresponding to the requested IP address.

[0194] Figure 4 Illustrative examples of traffic routing and monitoring according to one or more example embodiments are depicted. More specifically, Figure 4 illustrates how and where the identity can be embedded or assigned to the DNS request along the path between the client application and the traffic routing and monitoring platform. As Figure 4As shown in, client device 401 (which can be, for example, similar to the first client device 105, second client device 106, third client device 107, and / or other client devices as described above) can communicate with a traffic routing and monitoring platform 407 (which can be, for example, similar to the traffic routing and monitoring platform 102 as described above). When transmitting a DNS request, client device 401 can embed one or more identities (representing a user, application, profile, operating system, etc.) into the request. In some cases, these DNS requests can be relayed (e.g., unchanged) and / or otherwise modified by one or more intermediaries (such as, for example, local DNS resolver 406) along their path. In these cases, the intermediaries can similarly embed identities (representing entities associated with a given intermediate device, etc.) into the DNS request. Once the DNS request reaches its final destination at traffic routing and monitoring platform 407, traffic routing and monitoring platform 407 can identify the policies associated with each identity (e.g., using stored key / value pairs and / or other identity / policy pairs representing the identities and policies), and can generate an overall / comprehensive policy accordingly (which can, for example, involve resolving conflicts between the identified policies).

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

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

[0197] Since the traffic routing and monitoring platform 407 now identifies multiple policies, an overall or comprehensive policy may be identified. In the case where the second policy and the third policy do not conflict, the traffic routing and monitoring platform 407 may generate an overall policy that is the sum of both the second policy and the third policy, which may, for example, allow both policies to be applied overall. In the case where the second policy and the third policy directly conflict, the traffic routing and monitoring platform 407 may select the dominant policy as the overall policy (e.g., select the second policy or the third policy). In some cases, the traffic routing and monitoring platform 407 may select one or more dominant rules (e.g., instead of selecting the second policy or the third policy overall). In these cases, 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., rules from the second policy and rules from the third policy, etc.). For example, the traffic routing and monitoring platform 407 may generate a priority score and / or otherwise associate a priority score with the rules associated with each policy, and may select rules from one or more policies (e.g., the second policy and / or the third policy) by selecting the rule (which has a higher priority score than the remaining rules) from a pair of conflicting rules. In the case where the second policy and the third policy partially conflict, the traffic routing and monitoring platform 407 may resolve the second policy and the third policy in order to generate an overall policy that includes the attributes of one policy and the other remaining non-conflicting attributes of the other policy based on specified criteria (e.g., dominance, ranking, etc.).

[0198] In some cases, as a supplement to and / or in lieu of combining and / or otherwise coordinating the policies themselves, the traffic routing and monitoring platform 407 can identify attributes corresponding to each identity and can combine, add, delete, and / or coordinate other attributes of each identity. For example, each identity can include a set of attributes. The traffic routing and monitoring platform 407 can 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 can parse and / or combine the attributes accordingly to produce an overall identity. The traffic routing and monitoring platform 407 can then identify the appropriate associated policy corresponding to that overall identity. Once the overall policy is identified, the traffic routing and monitoring platform 407 can apply the overall policy.

[0199] As a third example, the client device 401 can send a third DNS query 408c from the personal profile 403a of the second browser 403. In this example, the client device 401 may not be configured with a traffic routing and monitoring service or application corresponding to the traffic routing and monitoring platform 407 and, thus, no identity can be embedded in the third DNS query 408c. In this example, the third DNS query 408c' can be routed by the operating system 405 to the local DNS resolver 406, which can then forward the third DNS query to the traffic routing and monitoring platform 407. In this example, the operating system 405 can process the DNS query request 408 embedding the third identity and embed a fourth identity (corresponding to the operating system 405) in the third DNS query 408c' (e.g., as part of a client certificate associated with the operating system, which is part of DoT), and can forward the DNS query request embedding the third identity to the local resolver 406. Similarly, the local DNS resolver 406 can embed a third identity (corresponding to the local DNS resolver 406 as described above) in the third DNS query 408c" and embed the third identity within the TLS tunnel of DoT as part of the DNS request. In these examples, the local DNS resolver 406 can terminate the existing TLS session and establish a new TLS session. Accordingly, the traffic routing and monitoring platform 407 can receive both the third identity and the fourth identity, 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 identity and the fourth identity). These policies can be similarly coordinated by the traffic routing and monitoring platform 407 to identify an overall or comprehensive policy, as described above, and then the traffic routing and monitoring platform 407 can apply the overall policy.

[0200] As a fourth example, the client device 401 can send a fourth DNS query 408d from the work profile 403b of the second browser 403. In this example, the fourth DNS query 408d can similarly be routed via the operating system 405 and the local DNS resolver 406 to the traffic routing and monitoring platform 407. However, in this example, unlike what was 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 thus, an identity (e.g., a fifth identity representing the client device 401, the second browser, and the work profile 403b) can be embedded in the fourth DNS query 408d'. For example, the traffic routing and monitoring agent 405a can add a corresponding identity (e.g., a seventh identity representing the traffic routing and monitoring agent 405a), and then can pass the fourth DNS query 408d' to the operating system 405, which can add its corresponding identity (e.g., the fifth identity). Alternatively, the operating system 405 can receive the fourth DNS query 408d, embed its corresponding identity (e.g., the fifth identity) and then can route the fourth DNS query 408d' to the traffic routing and monitoring agent 405a, which can subsequently add its corresponding identity (e.g., the seventh identity). In some cases, instead of embedding the seventh identity together with the fifth identity, the traffic monitoring and routing agent 405a can replace the fifth identity with the seventh identity, which can, for example, supersede or be added to the fifth identity. Accordingly, 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, that policy does not need to be coordinated with other policies as described in the above examples.

[0201] As a fifth example, the client device 401 may send a fifth DNS query 408e of the work profile 404a from the application 404. In this example, the client device 401 may embed, as a URL prefix, an identity (e.g., a sixth identity) corresponding to the client device 401, the work profile 404a, and the application 404 into the fifth DNS query 408e via DoH. In this example, the fifth DNS query 408e may be similarly routed via the operating system 405 and the local DNS resolver 406 to the traffic routing and monitoring platform 407. Then, when routing the fifth DNS query 408e via the operating system 405 and the local DNS resolver 406, the operating system and the local DNS resolver may embed a fourth identity (corresponding to the operating system 405) and a third identity (corresponding to the local DNS resolver 406) into the fifth DNS query (e.g., the fifth DNS queries 408e' and 408e", respectively) (e.g., by modifying the URL prefix to hold multiple identities or embedding additional identities inside the DNS request). Accordingly, the traffic routing and monitoring platform 407 may receive the sixth identity, the fourth identity, and the fifth identity, identify the corresponding identity / policy pairs, and select / apply the corresponding policies. These policies may be similarly coordinated by the traffic routing and monitoring platform 407 to identify an overall or comprehensive policy, as described above, and then the traffic routing and monitoring platform 407 may apply the overall policy.

[0202] Accordingly, as illustrated and described for these examples, different policies / traffic routing rules may be applied in a variety of different scenarios, although each DNS request is sent by the same user from the same client device 401. Similarly, by using identity-based unencrypted or encrypted DNS requests, DoT / DoH, etc. to implement the transmission of DNS requests, multiple types of identity information may be appended or otherwise embedded into the DNS request, which may, for example, enable more fine-grained policy determination (e.g., based on each specific identity).

[0203] Figures 6A to 6D Depicts an illustrative sequence of events for improved traffic routing and monitoring in accordance with one or more example embodiments. Referring to Figure 6A , at step 601, a client device 620 (which may, for example, be similar to the first client device 105, the second client device 106, and / or the third client device 107) may send a DNS request to a traffic routing and monitoring platform 630 (which may, for example, be similar to the traffic routing and monitoring platform 102). In some cases, the DNS request may include one or more domain names, and the corresponding DNS response (described further below) may include one or more IP addresses.

[0204] At step 602, the traffic routing and monitoring platform 630 may examine additional information (e.g., against known threats, overall policies, etc.) contained in the (multiple) domain and / or DNS requests. For example, the traffic routing and monitoring platform 630 may examine the local cache of any information (which may include queries and / or responses) associated with the (multiple) requested domains. At step 603, the traffic routing and monitoring platform 630 may examine the (multiple) IP addresses 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. Instead, 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 at the domain or global DNS resolver 640, the traffic routing and monitoring platform 630 may proceed to step 604 to forward the DNS request to the global DNS resolver 640.

[0205] Reference Figure 6B , at step 605, the global DNS resolver 640 may examine 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. Instead, the global DNS resolver 640 may block the request and (e.g., to the traffic routing and monitoring platform 630, which may in turn forward the DNS response to the client device 620) return a DNS response indicating that the DNS request was blocked. Otherwise, if no threat or policy violation is detected, the global DNS resolver 640 may proceed to step 606 to forward the DNS request to the root server 650.

[0206] At step 607, the root server 650 may send the IP address of the top-level domain (TLD) server 660 to the global DNS resolver 640. At step 608, the global DNS resolver 640 may examine 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. Instead, the root server 650 may block the request and (e.g., to the traffic routing and monitoring platform 630, which may in turn forward the DNS response to the client device 620) return a DNS response indicating that the DNS request was blocked. If no threat or policy violation is detected, the global DNS resolver 640 may proceed to step 609 (as Figure 6C illustrated) to forward the DNS request to the authoritative server 670.

[0207] Reference Figure 6C, at step 610, the TLD server 660 may send the IP address of the authoritative server 670 to the global DNS resolver 640. At step 611, the global DNS resolver 640 may check the (multiple) 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. Instead, the TLD server 660 may block the request and (e.g., to the traffic routing and monitoring platform 630, which may forward the DNS response to the client device 620, for example) return a DNS response indicating that the DNS request has been blocked. Otherwise, if no threat or policy violation is detected, the global DNS resolver 640 may proceed to step 612 to forward the DNS request to the authoritative server 670.

[0208] Reference Figure 6D , at step 613, the authoritative server 670 may send a DNS response to the global DNS resolver 640. At step 614, the global DNS resolver 640 may forward the DNS response to the traffic routing and monitoring platform 630. At step 615, the traffic routing and monitoring platform 630 may check the DNS response (and all 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 may not forward the DNS response to the client device 620 or may send 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 to forward the DNS response to the client device 620.

[0209] In some cases, the traffic routing and monitoring platform 630 can use network threat intelligence (CTI), non-compliant character detection (e.g., as described above with respect to step 205), and / or overall policies to identify whether an entire DNS response should be forwarded or a portion of the DNS response should be forwarded. For example, a DNS response can include more than one IP address. In some cases, the traffic routing and monitoring platform 630 can, based on CTI and / or overall policies, identify that one of the IP addresses in the response should not be forwarded to the client device 620 and can remove that portion of the DNS response before continuing to forward it to the client device 620. Additionally or alternatively, the traffic routing and monitoring platform 630 can perform a threshold comparison on the DNS response. For example, the traffic routing and monitoring platform 630 can identify whether the majority of the IP addresses included in the response are secure and / or compliant with the overall policy and can send the DNS response only if that majority threshold is met. In this example, if the traffic routing and monitoring platform 630 identifies that the majority of the IP addresses are secure, it can still remove any IP addresses that are determined to be insecure or otherwise violate the applied policy before routing them to the client device 620.

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

[0211] In some cases, when sending a DNS response to the client device 620, the traffic routing and monitoring platform 630 can add routing instructions to the DNS response. In some cases, the traffic routing and monitoring platform 630 can add such instructions if it is known that the client device 620 is configured to interpret such instructions. In these cases, the instructions can direct the client device 620 to route traffic via a proxy server or gateway to the provided IP address (e.g., log the traffic) and / or otherwise. By operating in this manner, the provided IP address itself may not be modified (and thus any corresponding intelligence and / or the ability to investigate the provided IP address can be maintained), instead, additional routing instructions can be added on top of the original IP address (e.g., by embedding the routing IP address in a txt record and / or other fields).

[0212] One or more aspects of the present disclosure may be embodied in computer-usable data or computer-executable instructions, such as being embedded in one or more program modules executed by one or more computers or other devices to perform the operations described herein. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types when executed by one or more processors in 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. Generally, the functions of the program modules may be combined or distributed as desired in various embodiments. Additionally, the functionality may be embodied entirely or partially in firmware or hardware equivalents such as integrated circuits, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs). Specific data structures may be used to more effectively implement one or more aspects of the present disclosure, and such data structures are contemplated within the scope of the computer-executable instructions and computer-usable data described herein.

[0213] The various aspects described herein may be embodied as a method, apparatus, or as one or more computer-readable media storing computer-executable instructions. Accordingly, these aspects may take the form of an entirely hardware embodiment, an entirely software embodiment, an entirely firmware embodiment, or an embodiment combining software, hardware, and firmware aspects in any combination. Additionally, the various signals representing data or events described herein may be transmitted between a source and a destination in the form of light waves or electromagnetic waves traveling through a signal-conducting medium, which signal-conducting mediums are such as metal wires, optical fibers, or wireless transmission mediums (e.g., air or space). Generally, one or more computer-readable media may be and / or include one or more non-transitory computer-readable media.

[0214] As described herein, various methods and actions can operate on one or more computing servers and one or more networks. The functionality can be distributed in any manner or can be located in a single computing device (e.g., a server, a client computer, etc.). For example, in alternative embodiments, one or more of the computing platforms discussed above can be combined into a single computing platform, and the various functions of each computing platform can be performed by the single computing platform. In such an arrangement, any and / or all of the communications discussed above between the computing platforms can correspond to accessing, moving, modifying, updating, and / or otherwise using data by the single computing platform. Additionally or alternatively, one or more of the computing platforms discussed above can be implemented in one or more virtual machines provided by one or more physical computing devices. In such an arrangement, the various functions of each computing platform can be performed by one or more virtual machines, and any and / or all of the communications discussed above between the computing platforms can correspond to accessing, moving, modifying, updating, and / or otherwise using data by one or more virtual machines.

[0215] To avoid doubt and without limiting the breadth of the disclosure above or in the figures, the present application also includes the subject matter described in the following numbered clauses:

[0216] 1. A method for identity-based DNS routing by applying a security policy specific to an identified user to Domain Name System (DNS) queries, the method comprising: establishing a secure DNS session using an encrypted DNS process, wherein establishing the secure DNS session includes performing an encrypted session handshake between an identity-based DNS routing platform and a client device, and wherein performing the encrypted session handshake includes receiving, from the client device, a security certificate identifying the user of the client device for the encrypted DNS process; receiving, when establishing the secure DNS session and from the client device, an encrypted DNS query request including a request for an Internet Protocol (IP) address of a domain name, wherein the encrypted DNS query request specifies the domain name; determining the identity of the user based on the security certificate; determining the user-specific security policy based on the identity of the user, wherein the security policy includes one or more domain name filtering rules, and each domain name filtering rule includes a corresponding domain matching criterion and a corresponding action to be taken for a matching domain name; determining, in response to the encrypted DNS query request, a first action corresponding to the domain name using the one or more domain name filtering rules and based on the domain name in the encrypted DNS query request; 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 for 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.

[0217] 2. The method for identity-based DNS routing according to clause 1, wherein the security policy is user-specific based on the organization associated with the user of the client device, and wherein the encrypted DNS query request is received from the client device when the client device sends the encrypted DNS query request from outside the protected network of the organization.

[0218] 3. The method for identity-based DNS routing according to any one of clauses 1 to 2, wherein the corresponding action to be taken for the matching domain name indicates whether traffic for the corresponding domain name in the matching domain names should be blocked, allowed, or logged.

[0219] 4. The method for identity-based DNS routing according to any one of clauses 1 to 3, wherein determining the first action corresponding to the domain name includes: determining that the domain name matches a first domain name rule indicating that traffic to a matching domain should be blocked.

[0220] 5. The method for identity-based DNS routing as described in clause 4, wherein the encrypted DNS query response includes the IP address of the blocked notification page.

[0221] 6. The method for identity-based DNS routing as described in clause 4, wherein the encrypted DNS query response includes a notification that the requested IP address has been blocked.

[0222] 7. The method for identity-based DNS routing as described in any one of clauses 1 to 6, wherein determining the first action corresponding to the domain name includes: determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be allowed.

[0223] 8. The method for identity-based DNS routing as described in clause 7, wherein the encrypted DNS query response includes the IP address of the server associated with the domain name in the encrypted DNS query request.

[0224] 9. The method for identity-based DNS routing as described in any one of clauses 1 to 8, wherein determining the first action corresponding to the domain name includes: determining that the domain name matches a first domain name rule indicating that the proxy server should record traffic to the matching domain.

[0225] 10. The method for identity-based DNS routing as described in clause 9, wherein the encrypted DNS query response includes the IP address of the proxy server.

[0226] 11. The method for identity-based DNS routing as described in clause 10, wherein the encrypted DNS query response is configured to conduct outgoing and incoming traffic to and from the IP address of the server associated with the domain name in the encrypted DNS query request via the proxy server.

[0227] 12. The method for identity-based DNS routing as described in clause 11, wherein the proxy server: receives outgoing network traffic from the client device, wherein the outgoing network traffic: indicates the proxy IP address of the proxy server as the destination IP address and includes data directed to the server associated with the domain name; receives inbound network traffic including a response to the outgoing network traffic from the server associated with the domain name, records network traffic including one or more of the following based on the domain matching criteria of the domain name and the corresponding action to be performed for the domain name: the outgoing network traffic and the inbound network traffic; and sends the inbound network traffic to the client device.

[0228] 13. A method for identity-based DNS routing as described in any one of clauses 9 to 12, wherein the proxy server: prompts the client device to provide the security certificate; determines one or more network policies based on the security certificate, wherein the one or more network policies indicate: traffic associated with potential security threats for which traffic should be logged, and metadata to be collected for the traffic associated with the potential security threats; collects the metadata for the traffic associated with the potential security threats; and sends the metadata to the identity-based DNS routing platform.

[0229] 14. A method for identity-based DNS routing as described in any one of clauses 1 to 13, wherein the network interface of the client device is pre-configured to direct DNS requests to the IP address of the identity-based DNS routing platform, and wherein the security certificate is installed at the client device before receiving the encrypted DNS query request.

[0230] 15. A method for identity-based DNS routing as described in clause 14, wherein the client device is pre-configured based on the installation of an enterprise security profile on the client device, and wherein the installation of the enterprise security profile on the client device causes the client device to direct the DNS request to the IP address of the identity-based DNS routing platform.

[0231] 16. A method for identity-based DNS routing as described in any one of clauses 1 to 15, wherein determining the security policy for the user includes determining to apply one of the following to the user: a user-specific policy, an organization-level policy, or a default policy.

[0232] 17. A method for identity-based DNS routing as described in any one of clauses 1 to 16, wherein the one or more domain name filtering rules include a whitelist, a blacklist, and a watchlist, and wherein each of the matching domain names is included on one of the whitelist, the blacklist, or the watchlist.

[0233] 18. A method for identity-based DNS routing as described in clause 17, wherein 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, wherein: the first action is to block traffic to the IP address of the domain name when the domain name is listed on the blacklist; the first action is to log traffic to the IP address of the domain name when the domain name is listed on the watchlist; and the first action is to allow access to the IP address of the domain name when the domain name is listed on the whitelist.

[0234] 19. A method for identity-based DNS routing as described in any one of clauses 1 to 18, wherein the encrypted session handshake includes a Transport Layer Security (TLS) handshake.

[0235] 20. A method for identity-based DNS routing as described in any one of clauses 1 to 19, wherein determining the identity of the user further includes determining the identity of the user based on at least a first identity and a second identity.

[0236] 21. A method for identity-based DNS routing as described in clause 20, wherein the first identity and the second identity are embedded in the encrypted DNS query request at the client device.

[0237] 22. A method for identity-based DNS routing as described in clause 20, wherein the first encrypted DNS query request is routed from the client device along a DNS path to the identity-based DNS routing platform.

[0238] 23. A method for identity-based DNS routing as described in clause 22, wherein the first identity is embedded in the encrypted DNS query request at the client device, and wherein the second identity is embedded in the encrypted DNS query request at an intermediate server along the DNS path.

[0239] 24. A method for identity-based DNS routing as described in clause 20, wherein the first identity corresponds to a first domain name filtering rule and the second identity corresponds to a second domain name filtering rule, and wherein determining the security policy includes resolving conflicts between the first domain name filtering rule and the second domain name filtering rule.

[0240] 25. A system including one or more computing devices, wherein the system is configured to perform the method as described in any one of clauses 1 to 24.

[0241] 26. One or more non-transitory computer-readable media, including stored instructions that, when executed by one or more processors of one or more computing devices of the system, cause the system to perform the method as described in any one of clauses 1 to 24.

[0242] 27. A method for identity - based DNS routing by applying a security policy specific to an identified user to Domain Name System (DNS) queries, the method comprising: using an unencrypted DNS process to establish a DNS session between an identity - based DNS routing platform and a client device; upon establishing the DNS session and receiving from the client device an unencrypted DNS query request including a request for an Internet Protocol (IP) address of a domain name, wherein the unencrypted DNS query request specifies the domain name; determining the identity of the user based on identity information embedded in the unencrypted DNS query request; determining the security policy specific to the user based on the identity of the user, wherein the security policy includes one or more domain - filtering rules, and each domain - filtering rule includes a corresponding domain - matching criterion and a corresponding action to be taken on a matching domain name; using the one or more domain - filtering rules and based on the domain name in the unencrypted DNS query request to determine a first action corresponding to the domain name in response to the unencrypted DNS query request; 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 for 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.

[0243] 28. The method for identity - based DNS routing according to clause 27, wherein the identity information is embedded in a field of the unencrypted DNS query request in plain text.

[0244] 29. The method for identity - based DNS routing according to any one of clauses 27 to 28, wherein the identity information is unencrypted.

[0245] 30. The method for identity - based DNS routing according to any one of clauses 27 to 29, wherein the identity information is encrypted.

[0246] 31. The method for identity - based DNS routing according to any one of clauses 27 to 30, wherein the identity information is encrypted by the client device.

[0247] 32. The method for identity - based DNS routing according to any one of clauses 27 to 31, wherein the identity information is encrypted by a local resolver, and wherein the unencrypted DNS query request passes through the local resolver before being received.

[0248] 33. The method for identity-based DNS routing as described in clause 32, wherein encrypting the identity information by the local resolver includes: adding the 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.

[0249] 34. The method for identity-based DNS routing as described in clause 32, wherein encrypting the identity information by the local resolver includes: removing a part of the identity information, and encrypting the identity information after removing the part of the identity information.

[0250] 35. The method for identity-based DNS routing as described in any one of clauses 27 to 34, wherein the security policy is user-specific based on the organization associated with the user of the client device, and wherein the unencrypted DNS query request is received from the client device when the client device sends the unencrypted DNS query request from outside the protected network of the organization.

[0251] 36. The method for identity-based DNS routing as described in any one of clauses 27 to 35, wherein the corresponding action to be taken on the matching domain name indicates whether to block, allow, or record traffic for the corresponding domain name in the matching domain name.

[0252] 37. The method for identity-based DNS routing as described in any one of clauses 27 to 36, wherein determining the first action corresponding to the domain name includes: determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be blocked.

[0253] 38. The method for identity-based DNS routing as described in clause 37, wherein the unencrypted DNS query response includes the IP address of a block notification page.

[0254] 39. The method for identity-based DNS routing as described in clause 37, wherein the unencrypted DNS query response includes a notification that the requested IP address has been blocked.

[0255] 40. The method for identity-based DNS routing as described in any one of clauses 27 to 39, wherein determining the first action corresponding to the domain name includes: determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be allowed.

[0256] 41. The method for identity-based DNS routing as described in clause 40, wherein the unencrypted DNS query response includes the IP address of a server associated with the domain name in the unencrypted DNS query request.

[0257] 42. The method for identity-based DNS routing as described in any one of clauses 27 to 41, wherein determining the first action corresponding to the domain name includes: determining that the domain name matches a first domain name rule indicating that the proxy server should record traffic to a matching domain.

[0258] 43. The method for identity-based DNS routing as described in clause 42, wherein the unencrypted DNS query response includes the IP address of the proxy server.

[0259] 44. The method for identity-based DNS routing as described in clause 43, wherein the unencrypted DNS query response is configured to conduct outgoing and incoming traffic to and from the IP address of the server associated with the domain name of the unencrypted DNS query request via the proxy server.

[0260] 45. The method for identity-based DNS routing as described in clause 44, wherein the proxy server: receives outgoing network traffic from the client device, wherein the outgoing network traffic: indicates the proxy IP address of the proxy server as the destination IP address and includes data directed to the server associated with the domain name; receives inbound network traffic including a response to the outgoing network traffic from the server associated with the domain name, records network traffic including one or more of the following based on the domain matching criteria of the domain name and the corresponding action to be performed for the domain name: the outgoing network traffic and the inbound network traffic; and sends the inbound network traffic to the client device.

[0261] 46. The method for identity-based DNS routing as described in any one of clauses 42 to 45, wherein the proxy server: prompts the client device to provide the identity information; determines one or more network policies based on the identity information, wherein the one or more network policies indicate: traffic associated with a potential security threat for which traffic should be recorded, and metadata to be collected for the traffic associated with the potential security threat; collects the metadata for the traffic associated with the potential security threat; and sends the metadata to the identity-based DNS routing platform.

[0262] 47. The method for identity-based DNS routing as described in any one of clauses 27 to 46, wherein the network interface of the client device is pre-configured to direct DNS requests to the IP address of the identity-based DNS routing platform.

[0263] 48. A method for identity-based DNS routing as described in clause 47, wherein the client device is pre-configured based on the installation of an enterprise security profile on the client device, and wherein the installation of the enterprise security profile on the client device causes the client device to direct the DNS request to the IP address of the identity-based DNS routing platform.

[0264] 49. A method for identity-based DNS routing as described in any one of clauses 27 to 48, wherein determining the security policy for the user includes determining to apply one of the following to the user: a user-specific policy, an organization-level policy, or a default policy.

[0265] 50. A method for identity-based DNS routing as described in any one of clauses 27 to 49, wherein the one or more domain name filtering rules include a whitelist, a blacklist, and a monitoring list, and wherein each of the matching domain names is included on one of the whitelist, the blacklist, or the monitoring list.

[0266] 51. A method for identity-based DNS routing as described in clause 50, wherein 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 monitoring list, wherein: the first action is to block traffic to the IP address of the domain name when the domain name is listed on the blacklist; the first action is to record traffic to the IP address of the domain name when the domain name is listed on the monitoring list; and the first action is to allow traffic to the IP address of the domain name when the domain name is listed on the whitelist.

[0267] 52. A system including one or more computing devices, wherein the system is configured to perform the method as described in any one of clauses 27 to 51.

[0268] 53. One or more non-transitory computer-readable media, including 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 as described in any one of clauses 27 to 51.

[0269] 54. A method for identity-based DNS routing by applying a security policy specific to an identified user to a Domain Name System (DNS) query, the method comprising: establishing a DNS session between an identity-based DNS routing platform and a client device using DNS procedures; receiving, upon establishing the DNS session, a DNS query request including a request for an Internet Protocol (IP) address of a domain name, wherein the DNS query request specifies: the domain name corresponding to the DNS query request and identity information, wherein the identity information indicates at least two identities corresponding to the DNS query request; determining an identity 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, wherein the security policy includes one or more global domain name filtering rules, and each domain name filtering rule of the one or more global domain name filtering rules includes a corresponding domain matching criterion and a corresponding action to be taken on a matching domain name; determining a first action corresponding to the domain name using the one or more global domain name filtering rules and based on the domain name in the DNS query request in response to the DNS query request; 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 for 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.

[0270] 55. The identity-based DNS routing method according to clause 54, wherein the DNS procedure includes an encrypted DNS procedure configured to identify a requested IP address based on receiving the request for the IP address of the domain name.

[0271] 56. The identity-based DNS routing method according to clause 54, wherein the DNS procedure includes an unencrypted DNS procedure configured to identify a requested IP address based on receiving the request for the IP address of the domain name.

[0272] 57. The identity-based DNS routing method according to any one of clauses 54 to 56, wherein the DNS query request is received from the client device, and wherein the at least two identities corresponding to the DNS query request correspond to the client device.

[0273] 58. The identity-based DNS routing method according to clause 57, wherein the at least two identities include two or more of the following: user identity, device identity, browser identity, application identity, operating system identity, or software identity.

[0274] 59. The identity-based DNS routing method as described in any one of clauses 54 to 58, wherein the DNS query request is routed between the identity-based DNS routing platform and the client device through an additional server.

[0275] 60. The identity-based DNS routing method as described in clause 59, wherein the first identity among the at least two identities is embedded by the client device, and the second identity among the at least two identities is embedded by the additional server.

[0276] 61. The identity-based DNS routing method as described in clause 59, wherein the additional server is configured to remove at least a part of the identity information received from the client device.

[0277] 62. The identity-based DNS routing method as described in clause 59, wherein the additional server is configured to modify at least a part of the identity information received from the client device.

[0278] 63. The identity-based DNS routing method as described in clause 59, wherein the additional server is configured to embed the identity information as a whole.

[0279] 64. The identity-based DNS routing method as described in any one of clauses 54 to 59, wherein the at least two identities are embedded in the DNS query request as a URL prefix.

[0280] 65. The identity-based DNS routing method as described in any one of clauses 54 to 59, wherein the first identity among the at least two identities corresponds to a first domain name filtering rule, and the second identity among the at least two identities corresponds to a second domain name filtering rule.

[0281] 66. The identity-based DNS routing method as described in clause 65, wherein determining the one or more overall domain name filtering rules includes adding the first domain name filtering rule to the second domain name filtering rule.

[0282] 67. The identity-based DNS routing method as described in clause 66, wherein the first domain name filtering rule conflicts with the second domain name filtering rule.

[0283] 68. The identity-based DNS routing method as described in clause 67, wherein determining the one or more overall domain name filtering rules includes coordinating the first domain name filtering rule with the second domain name filtering rule by: identifying a conflict between a first rule in the first domain name filtering rule and a second rule in the first domain name filtering rule, comparing the priority score of the first rule with the priority score of the second rule, identifying that the priority score of the first rule exceeds the priority score of the second rule based on the comparison of the priority scores, and selecting the first rule instead of the second rule for inclusion in the one or more overall domain name filtering rules based on identifying 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 all remaining domain name filtering rules in the first domain name filtering rule and the second domain name filtering rule.

[0284] 69. The identity-based DNS routing method as described in any one of clauses 54 to 68, wherein determining the DNS query response based on the first action corresponding to the domain name includes forwarding the DNS query request upstream along the DNS path to one or more servers.

[0285] 70. The identity-based DNS routing method as described in clause 69, further comprising: identifying the threat context of the one or more servers; and modifying the DNS path based on the identified threat context.

[0286] 71. The identity-based DNS routing method as described in clause 70, wherein the DNS query response indicates the IP address of the DNS routing platform based on a second identity, and wherein the DNS query response configures the client device to route future DNS query requests to the DNS routing platform based on the second identity instead of the DNS routing platform based on the identity.

[0287] 72. The identity-based DNS routing method as described in clause 71, wherein configuring the client device to route the future DNS query requests to the DNS routing platform based on the second identity includes configuring the client device to route the future DNS query requests to the DNS routing platform based on the second identity for a predetermined duration.

[0288] 73. The identity-based DNS routing method as described in clause 71, wherein the DNS routing platform based on the identity is located in a first geographical region, and wherein the DNS routing platform based on the second identity is located in a second geographical region different from the first geographical region.

[0289] 74. The identity-based DNS routing method as described in any one of clauses 54 to 73 further includes: identifying that the domain name is on a watch list; and replacing a first time-to-live (TTL) of the requested IP address with a second TTL of the requested IP address, where the first TTL is preset for the requested IP address and where the second TTL is shorter than the first TTL.

[0290] 75. The identity-based DNS routing method as described in any one of clauses 54 to 74, wherein determining the security policy based on the user's identity includes identifying the security policy based on a correlation between the stored identity and the security policy.

[0291] 76. The identity-based DNS routing method as described in clause 75, wherein the intelligent policy manager system pre-populates a cache of the identity-based DNS routing platform to include the correlation between the stored identity and the security policy.

[0292] 77. The identity-based DNS routing method as described in clause 76, wherein the pre-population is based on one of the following: the geographical location of the client device or a request to perform the pre-population.

[0293] 78. The identity-based DNS routing method as described in any one of clauses 54 to 77, wherein the DNS query response: includes the IP address of a proxy server and is configured to cause outgoing and incoming traffic to and from the IP address of the server associated with the domain name of the DNS query request to be conducted by the proxy server, where the first action includes the proxy server recording the outgoing and incoming traffic.

[0294] 79. The identity-based routing method as described in any one of clauses 54 to 78, wherein the DNS query response includes: the requested IP address and a routing instruction to direct the client device to route traffic to the requested IP address via a gateway server, where the first action includes the gateway server recording outgoing and incoming traffic.

[0295] 80. The identity-based routing method as described in any one of clauses 54 to 79, wherein the DNS query response includes: the requested IP address and a local rule indicating the first action corresponding to the domain name, where the first action includes one of the following: blocking traffic directed to the requested IP address, allowing traffic directed to the requested IP address, and recording traffic directed to the requested IP address, and the client device is configured to enforce the local rule.

[0296] 81. A system comprising one or more computing devices, wherein the system is configured to perform the method according to any one of clauses 54 to 80.

[0297] 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 the system, cause the system to perform the method according to any one of clauses 54 to 80.

[0298] 83. A method for identity-based DNS routing by applying a security policy specific to an identified user to a Domain Name System (DNS) query, the method comprising: using a DNS process and establishing a DNS session between an identity-based DNS routing platform and a client device; receiving, when establishing the DNS session, a DNS query request comprising a request for an Internet Protocol (IP) address of a domain name, wherein the DNS query request specifies: the domain name corresponding to the DNS query request and identity information, wherein the identity information indicates at least two identities corresponding to the DNS query request; determining the identity of the user of the client device based on the identity information; determining the security policy specific to the user based on the identity of the user, wherein the security policy comprises one or more global domain name filtering rules, and each domain name filtering rule of the one or more global domain name filtering rules comprises a corresponding domain matching criterion and a corresponding action to be taken on 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 to determine that the domain name matches a first domain name rule indicating that a proxy server should record traffic to the matching domain; determining a DNS query response based on determining that the proxy server should record the matching domain, wherein the DNS query response: comprises the IP address of the proxy server and is configured to cause outgoing and incoming traffic to the IP address of the server associated with the domain name of the DNS query request to be conducted by the proxy server; and sending the DNS query response to the client device.

[0299] 84. The identity-based DNS routing method as described in clause 83, wherein the proxy server: receives outbound network traffic from the client device, where the outbound network traffic: indicates the proxy IP address of the proxy server as the destination IP address and includes data directed to a server associated with the domain name; receives inbound network traffic including a response to the outbound network traffic from the server associated with the domain name, records network traffic including one or more of the following based on the domain matching criteria for the domain name and the corresponding action to be performed for the domain name: the outbound network traffic and the inbound network traffic; and sends the inbound network traffic to the client device.

[0300] 85. A system including one or more computing devices, wherein the system is configured to perform the method as described in any one of clauses 83 to 84.

[0301] 86. One or more non-transitory computer-readable media, including stored instructions that, when executed by one or more processors of one or more computing devices of the system, cause the system to perform the method as described in any one of clauses 83 to 84.

[0302] 87. A method for identity-based DNS routing by applying a security policy specific to an identified user to a Domain Name System (DNS) query, the method comprising: establishing a DNS session between an identity-based DNS routing platform and a client device using DNS procedures; receiving, at the establishment of the DNS session, a DNS query request including a request for an Internet Protocol (IP) address of a domain name, wherein the DNS query request specifies: the domain name corresponding to the DNS query request and identity information, wherein the identity information indicates at least two identities corresponding to the DNS query request; determining the identity of the user of the client device based on the identity information; determining the security policy specific to the user based on the identity of the user, wherein the security policy includes one or more global domain name filtering rules, and each domain name filtering rule in the one or more global domain name filtering rules includes a corresponding domain matching criterion and a corresponding action to be taken on 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 to determine that the domain name matches a first domain name rule indicating that a gateway server should record traffic to the matching domain; determining a DNS query response based on determining that the gateway server should record the traffic to the matching domain, wherein the DNS query response includes: the requested IP address, and a routing instruction to direct the client device to route traffic to the requested IP address via the gateway server, wherein determining the DNS query response includes performing an upstream request for the IP address of the domain name to identify the requested IP address; and sending the DNS query response to the client device.

[0303] 88. The identity-based DNS routing method according to clause 87, wherein the DNS query response is configured to conduct outgoing and incoming traffic to and from the requested IP address via the gateway server.

[0304] 89. The identity-based DNS routing method according to any one of clauses 87 to 88, wherein the gateway server: receives outgoing network traffic from the client device, wherein the outgoing network traffic: indicates the requested IP address as a destination IP address, and includes data directed to a server associated with the domain name; receives inbound network traffic including a response to the outgoing network traffic from the server associated with the domain name, records network traffic including one or more of the following based on the domain matching criterion of the domain name and the corresponding action to be performed on the domain name: the outgoing network traffic and the inbound network traffic; and sends the inbound network traffic to the client device.

[0305] 90. A system including one or more computing devices, wherein the system is configured to perform the method according to any one of clauses 87 to 89.

[0306] 91. One or more non-transitory computer-readable media including stored instructions that, when executed by one or more processors of one or more computing devices of the system, cause the system to perform the method according to any one of clauses 87 to 89.

[0307] 92. A method for identity-based DNS routing by applying a security policy specific to an identified user to a Domain Name System (DNS) query, the method comprising: using a DNS process and establishing a DNS session between an identity-based DNS routing platform and a client device; receiving, when establishing the DNS session, a DNS query request including a request for an Internet Protocol (IP) address of a domain name, wherein the DNS query request specifies: the domain name corresponding to the DNS query request and identity information, wherein the identity information indicates at least two identities corresponding to the DNS query request; determining the identity of the 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, wherein the security policy includes one or more global domain name filtering rules, and each domain name filtering rule in the one or more global domain name filtering rules includes a corresponding domain matching criterion and a corresponding action to be taken on a matching domain name; determining, in response to the DNS query request, a first action corresponding to the domain name by using the one or more global domain name filtering rules and based on the domain name in the DNS query request; determining a DNS query response based on the first action corresponding to the domain name, wherein the DNS query response includes: 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 for 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 for traffic directed to the requested IP address.

[0308] 93. The identity-based DNS routing method according to clause 92, wherein the local rule indicates whether the traffic directed to the requested IP address should be blocked, allowed, or logged.

[0309] 94. The identity-based DNS routing method as described in any one 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.

[0310] 95. A system including one or more computing devices, wherein the system is configured to perform the method as described in any one of clauses 92 to 94.

[0311] 96. One or more non-transitory computer-readable media, including stored instructions that, when executed by one or more processors of one or more computing devices of the system, cause the system to perform the method as described in any one of clauses 92 to 94.

[0312] Aspects of the present disclosure have been described in accordance with illustrative embodiments of the present disclosure. Those of ordinary skill in the art will, from a review of the present disclosure, envision numerous other embodiments, modifications, and variations within the scope and spirit of the appended claims. For example, one or more of the steps depicted in the illustrative drawings may be performed in an order different from the recited order, and one or more of the depicted steps may be optional in accordance with aspects of the present disclosure.

Claims

1. A method for identity - based DNS routing by applying a security policy specific to an identified user to Domain Name System (DNS) queries, the method comprising: Using an encrypted DNS process to establish a secure DNS session, wherein establishing the secure DNS session includes performing an encrypted session handshake between an identity - based DNS routing platform and a client device, and wherein performing the encrypted session handshake includes receiving, from the client device, a security certificate identifying the user of the client device for the encrypted DNS process; Receiving, when establishing the secure DNS session and from the client device, an encrypted DNS query request including a request for an Internet Protocol (IP) address of a domain name, wherein the encrypted DNS query request specifies the domain name; Determining the identity of the user based on the security certificate; Determining the user - specific security policy based on the identity of the user, wherein the security policy includes one or more domain - filtering rules, and each domain - filtering rule includes a corresponding domain - matching criterion and a corresponding action to be taken for a matching domain name; Using the one or more domain - filtering rules and based on the domain name in the encrypted DNS query request to determine a first action corresponding to the domain name in response to the encrypted DNS query request; 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 for 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.

2. The method for identity-based DNS routing according to claim 1, wherein, The security policy is user - specific based on the organization associated with the user of the client device, and wherein the encrypted DNS query request is received from the client device when the client device sends the encrypted DNS query request from outside the protected network of the organization.

3. The method for identity-based DNS routing according to claim 1, wherein, The corresponding action to be taken for the matching domain name indicates whether traffic to the corresponding domain name in the matching domain names should be blocked, allowed, or logged.

4. The method for identity-based DNS routing according to claim 1, wherein, Determining the first action corresponding to the domain name includes: Determining that the domain name matches a first domain rule indicating that traffic to the matching domain should be blocked.

5. The method for identity-based DNS routing according to claim 4, wherein, The encrypted DNS query response includes the IP address of a block - notification page.

6. The method for identity-based DNS routing according to claim 4, wherein, The encrypted DNS query response includes a notification that the requested IP address has been blocked.

7. The method for identity-based DNS routing as claimed in claim 1, wherein, Determining the first action corresponding to the domain name includes: Determining that the domain name matches a first domain rule indicating that traffic to the matching domain should be allowed.

8. The method for identity-based DNS routing as claimed in claim 7, wherein, The encrypted DNS query response includes the IP address of a server associated with the domain name in the encrypted DNS query request.

9. The method for identity-based DNS routing according to claim 1, wherein, Determining the first action corresponding to the domain name includes: Determining that the domain name matches a first domain rule indicating that a proxy server should log traffic to the matching domain.

10. The method for identity-based DNS routing as claimed in claim 9, wherein, The encrypted DNS query response includes the IP address of the proxy server.

11. The method for identity-based DNS routing according to claim 10, wherein, The encrypted DNS query response is configured to conduct outgoing and incoming traffic to and from the IP address of the server associated with the domain name of the encrypted DNS query request via the proxy server.

12. The method for identity-based DNS routing as claimed in claim 11, wherein, The proxy server: Receives outgoing network traffic from the client device, where the outgoing network traffic: Indicates the proxy IP address of the proxy server as the destination IP address, and Includes data directed to the server associated with the domain name; Receives inbound network traffic including a response to the outgoing network traffic from the server associated with the domain name, Records network traffic including one or more of the following: the outgoing network traffic and the inbound network traffic, based on domain matching criteria for the domain name and the corresponding action to be performed for the domain name; and Sends the inbound network traffic to the client device.

13. The method for identity-based DNS routing according to claim 9, wherein, The proxy server: Prompts the client device to provide the security certificate; Determines one or more network policies based on the security certificate, where the one or more network policies indicate: Traffic associated with potential security threats for which traffic should be recorded, and Metadata to be collected for the traffic associated with the potential security threats; Collects the metadata for the traffic associated with the potential security threats; and Sends the metadata to the identity-based DNS routing platform.

14. The method for identity-based DNS routing according to claim 1, wherein, The network interface of the client device is preconfigured to direct DNS requests to the IP address of the identity-based DNS routing platform, and where the security certificate is installed at the client device prior to receiving the encrypted DNS query request.

15. The method for identity-based DNS routing according to claim 14, wherein, The client device is preconfigured based on the installation of an enterprise security profile on the client device, and where the installation of the enterprise security profile on the client device causes the client device to direct the DNS request to the IP address of the identity-based DNS routing platform.

16. The method for identity-based DNS routing according to claim 1, wherein, Determining the security policy for the user includes determining to apply one of the following to the user: a user-specific policy, an organization-level policy, or a default policy.

17. The method for identity-based DNS routing according to claim 1, wherein, The one or more domain name filtering rules include a whitelist, a blacklist, and a watchlist, and where each of the matching domain names is included on one of the whitelist, the blacklist, or the watchlist.

18. The method for identity-based DNS routing as claimed in claim 17, wherein, Determining the first action to be performed for the domain name includes: Identifying whether the domain name is listed on the whitelist, the blacklist, or the watchlist, where: When the domain name is listed on the blacklist, the first action is to block traffic to the IP address of the domain name; When the domain name is listed on the watchlist, the first action is to record traffic to the IP address of the domain name; and When the domain name is listed on the whitelist, the first action is to allow traffic to the IP address of the domain name.

19. The method for identity-based DNS routing according to claim 1, wherein, The encrypted session handshake includes a Transport Layer Security (TLS) handshake.

20. The method for identity-based DNS routing according to claim 1, wherein, Determining the identity of the user further includes determining, based at least on a first identity and a second identity: the identity of the user.

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

22. The method for identity-based DNS routing according to claim 20, wherein, The first encrypted DNS query request is routed from the client device along a DNS path to the identity-based DNS routing platform, and the DNS path can be the path through which the first encrypted DNS query request recurs through different DNS servers to formulate a response returned to the client device.

23. The method for identity-based DNS routing according to claim 22, wherein, The first identity is embedded in the encrypted DNS query request at the client device, and wherein the second identity is embedded in the encrypted DNS query request at an intermediate server along the DNS path.

24. The method for identity-based DNS routing as claimed in claim 20, wherein, The first identity corresponds to a first domain name filtering rule and the second identity corresponds to a second domain name filtering rule, and wherein determining the security policy includes eliminating conflicts between the first domain name filtering rule and the second domain name filtering rule.

25. A system including one or more computing devices, wherein, The system is configured to perform the method according to any one of claims 1 to 24.

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

27. A method for identity-based DNS routing by applying a security policy specific to an identified user to a Domain Name System (DNS) query, the method comprising: Using an unencrypted DNS process to establish a DNS session between an identity-based DNS routing platform and a client device; Receiving, at the time of establishing the DNS session and from the client device, an unencrypted DNS query request including a request for an Internet Protocol (IP) address of a domain name, wherein the unencrypted DNS query request specifies the domain name; Determining the identity 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, wherein the security policy includes one or more domain name filtering rules, and each domain name filtering rule includes a corresponding domain matching criterion and a corresponding action to be taken on a matching domain name; Using the one or more domain name filtering rules and based on the domain name in the unencrypted DNS query request to determine a first action corresponding to the domain name in response to the unencrypted DNS query request; 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 for 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.

28. The method for identity-based DNS routing according to claim 27, wherein, The identity information is embedded in a field of the unencrypted DNS query request using plaintext.

29. The method for identity-based DNS routing according to claim 27, wherein, The identity information is unencrypted.

30. The method for identity-based DNS routing as claimed in claim 27, wherein, The identity information is encrypted.

31. The method for identity-based DNS routing according to claim 27, wherein, The identity information is encrypted by the client device.

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

33. The method for identity-based DNS routing as claimed in claim 32, wherein, Encrypting the identity information by the local resolver includes: Adding the 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.

34. The method for identity-based DNS routing according to claim 32, wherein, Encrypting the identity information by the local resolver includes: Removing a part of the identity information, and Encrypting the identity information after removing the part of the identity information.

35. The method for identity-based DNS routing as claimed in claim 27, wherein, The security policy is user-specific based on the organization associated with the user of the client device, and wherein the unencrypted DNS query request is received from the client device when the client device sends the unencrypted DNS query request from outside the protected network of the organization.

36. The method for identity-based DNS routing as claimed in claim 27, wherein, The corresponding action to be taken on the matching domain name indicates whether traffic should be blocked, allowed, or logged for the corresponding domain name in the matching domain name.

37. The method for identity-based DNS routing as claimed in claim 27, wherein, Determining the first action corresponding to the domain name includes: Determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be blocked.

38. The method for identity-based DNS routing as claimed in claim 37, wherein, The unencrypted DNS query response includes the IP address of the blocked notification page.

39. The method for identity-based DNS routing according to claim 37, wherein, The unencrypted DNS query response includes a notification that the requested IP address has been blocked.

40. The method for identity-based DNS routing according to claim 27, wherein, Determining the first action corresponding to the domain name includes: Determining that the domain name matches a first domain name rule indicating that traffic to the matching domain should be allowed.

41. The method for identity-based DNS routing as claimed in claim 40, wherein, The unencrypted DNS query response includes the IP address of the server associated with the domain name in the unencrypted DNS query request.

42. The method for identity-based DNS routing according to claim 27, wherein, Determining the first action corresponding to the domain name includes: Determining that the domain name matches a first domain name rule indicating that the proxy server should log traffic to the matching domain.

43. The method for identity-based DNS routing according to claim 42, wherein, The unencrypted DNS query response includes the IP address of the proxy server.

44. The method for identity-based DNS routing as claimed in claim 43, wherein, The unencrypted DNS query response is configured to conduct outgoing and incoming traffic to and from the IP address of the server associated with the domain name of the unencrypted DNS query request via the proxy server.

45. The method for identity-based DNS routing as claimed in claim 44, wherein, The proxy server: Receives outgoing network traffic from the client device, wherein the outgoing network traffic: Indicates the proxy IP address of the proxy server as the destination IP address, and Includes data directed to the server associated with the domain name; Receives inbound network traffic including a response to the outgoing network traffic from the server associated with the domain name, Records network traffic including one or more of the following: the outgoing network traffic and the inbound network traffic based on the domain matching criteria of the domain name and the corresponding action to be performed on the domain name; and Sends the inbound network traffic to the client device.

46. The method for identity-based DNS routing as claimed in claim 42, wherein, The proxy server: Prompts the client device to provide the identity information; Determine one or more network policies based on the identity information, wherein the one or more network policies indicate: traffic associated with potential security threats for which traffic should be logged, and metadata to be collected for the traffic associated with the potential security threats; Collect the metadata for the traffic associated with the potential security threats; and Send the metadata to the identity-based DNS routing platform.

47. The method for identity-based DNS routing as claimed in claim 27, wherein, The network interface of the client device is preconfigured to direct DNS requests to the IP address of the identity-based DNS routing platform.

48. The method for identity-based DNS routing as claimed in claim 47, wherein, The client device is preconfigured based on the installation of an enterprise security profile on the client device, and wherein installing the enterprise security profile on the client device causes the client device to direct the DNS request to the IP address of the identity-based DNS routing platform.

49. The method for identity-based DNS routing as claimed in claim 27, wherein, Determining the security policy for the user includes determining to apply one of the following to the user: a user-specific policy, an organization-level policy, or a default policy.

50. The method for identity-based DNS routing as claimed in claim 27, wherein, The one or more domain name filtering rules include a whitelist, a blacklist, and a watchlist, and wherein each of the matching domain names is included on one of the whitelist, the blacklist, or the watchlist.

51. The method for identity-based DNS routing as claimed in claim 50, wherein, 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, wherein: When the domain name is listed on the blacklist, the first action is to block traffic to the IP address of the domain name; When the domain name is listed on the watchlist, the first action is to log traffic to the IP address of the domain name; and When the domain name is listed on the whitelist, the first action is to allow traffic to the IP address of the domain name.

52. A system including one or more computing devices, wherein, The system is configured to perform the method according to any one of claims 27 to 51.

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

54. A method for identity-based DNS routing by applying a security policy specific to an identified user to a Domain Name System (DNS) query, the method comprising: Establish a DNS session between an identity-based DNS routing platform and a client device using DNS procedures; Receive, at the establishment of the DNS session, a DNS query request including a request for an Internet Protocol (IP) address of a domain name, wherein the DNS query request specifies: the domain name corresponding to the DNS query request and identity information, wherein the identity information indicates at least two identities corresponding to the DNS query request; Determine the identity of the user of the client device based on the identity information; Determine the security policy specific to the user based on the identity of the user, wherein the security policy includes one or more global domain name filtering rules, and each domain name filtering rule in the one or more global domain name filtering rules includes a corresponding domain matching criterion and a corresponding action to be taken on the matching domain name; In response to the DNS query request, use the one or more global domain name filtering rules and determine a first action corresponding to the domain name based on the domain name in the DNS query request; Determine the DNS query response based on the first action corresponding to the domain name, wherein determining the DNS query response includes performing an upstream request for the IP address of the domain name to identify the IP address of the domain name; and Send the DNS query response to the client device.

55. The identity-based DNS routing method according to claim 54, wherein, The DNS process includes 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. The identity-based DNS routing method according to claim 54, wherein, The DNS process includes 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. The identity-based DNS routing method according to claim 54, wherein, The DNS query request is received from the client device, and wherein the at least two identities corresponding to the DNS query request correspond to the client device.

58. The identity-based DNS routing method according to claim 57, wherein, The at least two identities include two or more of the following: user identity, device identity, browser identity, application identity, operating system identity, or software identity.

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

60. The identity-based DNS routing method according to claim 59, wherein, The first identity in the at least two identities is embedded by the client device, and the second identity in the at least two identities is embedded by the additional server.

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

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

63. The identity-based DNS routing method according to claim 59, wherein, The additional server is configured to embed the identity information as a whole.

64. The identity-based DNS routing method according to claim 54, wherein, The at least two identities are embedded in the DNS query request as a URL prefix.

65. The identity-based DNS routing method according to claim 54, wherein, The first identity in the at least two identities corresponds to a first domain name filtering rule, and the second identity in the at least two identities corresponds to a second domain name filtering rule.

66. The identity-based DNS routing method according to claim 65, wherein, Determining the one or more global domain name filtering rules includes adding the first domain name filtering rule to the second domain name filtering rule.

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

68. The identity-based DNS routing method according to claim 67, wherein, Determining the one or more global domain name filtering rules includes coordinating the first domain name filtering rule and the second domain name filtering rule by: Identifying a conflict between a first rule in the first domain name filtering rule and a second rule in the first domain name filtering rule, Comparing the priority score of the first rule with the priority score of the second rule, Identifying that the priority score of the first rule exceeds the priority score of the second rule based on the comparison of the priority scores, and selecting the first rule instead of the second rule for inclusion in the one or more overall domain name filtering rules based on identifying 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 all remaining domain name filtering rules among the first domain name filtering rule and the second domain name filtering rule.

69. The identity-based DNS routing method according to claim 54, wherein, Determining that the DNS query response includes forwarding the DNS query request upstream along the DNS path to one or more servers based on the first action corresponding to the domain name.

70. The identity-based DNS routing method according to claim 69, further comprising:[[]]END]] Identifying a threat context of the one or more servers; and Modifying the DNS path based on the identified threat context.

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

72. The identity-based DNS routing method according to claim 71, wherein, Configuring the client device to route the future DNS query requests to the DNS routing platform based on the second identity includes configuring the client device to route the future DNS query requests to the DNS routing platform based on the second identity within a predetermined duration.

73. The identity-based DNS routing method according to claim 71, wherein, The identity-based DNS routing platform is located in a first geographical region, and wherein the DNS routing platform based on the second identity is located in a second geographical region different from the first geographical region.

74. The identity-based DNS routing method according to claim 54, further comprising:[[]]END]] Identifying that the domain name is on a watch list; 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 wherein the second TTL is shorter than the first TTL.

75. The identity-based DNS routing method according to claim 54, wherein, Determining the security policy based on the identity of the user includes identifying the security policy based on a correlation between the stored identity and the security policy.

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

77. The identity-based DNS routing method according to claim 76, wherein, The pre-population is based on one of the following: the geographical location of the client device or a request to perform the pre-population.

78. The identity-based DNS routing method according to claim 54, wherein, The DNS query response: includes an IP address of a proxy server, and is configured to cause outgoing traffic and incoming traffic to and from the IP address of the server associated with the domain name of the DNS query request to be conducted by the proxy server, wherein the first action includes recording the outgoing traffic and the incoming traffic by the proxy server.

79. The identity-based routing method according to claim 54, wherein, The DNS query response includes: the requested IP address, and A routing instruction that guides the client device to route traffic to the requested IP address via a gateway server, wherein the first action includes the gateway server recording outgoing traffic and incoming traffic.

80. The identity-based routing method according to claim 54, wherein, The DNS query response includes: The requested IP address, and A local rule indicating the first action corresponding to the domain name, wherein the first action includes one of the following items: Blocking traffic directed to the requested IP address, Allowing traffic directed to the requested IP address, and Recording traffic directed to the requested IP address, wherein the client device is configured to enforce the local rule.

81. A system including one or more computing devices, wherein, The system is configured to perform the method according to any one of claims 54 to 80.

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

83. A method for identity-based DNS routing by applying a security policy specific to an identified user to a Domain Name System (DNS) query, the method comprising: Using a DNS process and establishing a DNS session between an identity-based DNS routing platform and a client device; Receiving, when establishing the DNS session, a DNS query request including a request for an Internet Protocol (IP) address of a domain name, wherein the DNS query request specifies: the domain name corresponding to the DNS query request and identity information, and the identity information indicates at least two identities corresponding to the DNS query request; Determining the identity of the 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, wherein the security policy includes one or more overall domain name filtering rules, and each domain name filtering rule in the one or more overall domain name filtering rules includes a corresponding domain matching criterion and a corresponding action to be taken for the matching domain name; Using the one or more overall 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 the proxy server should record traffic to the matching domain; Determining a DNS query response based on determining that the proxy server should record the matching domain, wherein the DNS query response: Includes the IP address of the proxy server, and Is configured to conduct outgoing traffic and incoming traffic to and from the IP address of the server associated with the domain name of the DNS query request by the proxy server; and Sending the DNS query response to the client device.

84. The identity-based DNS routing method according to claim 83, wherein, The proxy server: Receives outgoing network traffic from the client device, wherein the outgoing network traffic: Indicates the proxy IP address of the proxy server as the destination IP address, and Includes data directed to the server associated with the domain name. Receive inbound network traffic including a response to the outbound network traffic from the server associated with the domain name. Record network traffic including one or more of the following based on the domain matching criteria for the domain name and the corresponding action to be performed for the domain name: the outbound network traffic and the inbound network traffic; and Send the inbound network traffic to the client device.

85. A system including one or more computing devices, wherein, The system is configured to perform the method according to any one of claims 83 to 84.

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

87. A method for identity-based DNS routing by applying a security policy specific to an identified user to a Domain Name System (DNS) query, the method comprising: Establish a DNS session between an identity-based DNS routing platform and a client device using DNS procedures. Receive a DNS query request including a request for an Internet Protocol (IP) address of a domain name when establishing the DNS session, wherein the DNS query request specifies: the domain name corresponding to the DNS query request and identity information, and the identity information indicates at least two identities corresponding to the DNS query request. Determine the identity of the user of the client device based on the identity information. Determine the security policy specific to the user based on the identity of the user, wherein the security policy includes one or more overall domain name filtering rules, and each domain name filtering rule in the one or more overall domain name filtering rules includes a corresponding domain matching criteria and a corresponding action to be taken for a matching domain name. Use the one or more overall domain name filtering rules and determine that the domain name matches a first domain name rule indicating that the gateway server should record traffic to the matching domain based on the domain name in the DNS query request. Determine a DNS query response based on determining that the gateway server should record the traffic to the matching domain, wherein the DNS query response includes: The requested IP address, and A routing instruction to direct the client device to route traffic to the requested IP address via the gateway server, wherein determining the DNS query response includes performing an upstream request for the IP address of the domain name to identify the requested IP address; and Send the DNS query response to the client device.

88. The identity-based DNS routing method according to claim 87, wherein, The DNS query response is configured to conduct outbound and inbound traffic to and from the requested IP address via the gateway server.

89. The identity-based DNS routing method according to claim 87, wherein, The gateway server: Receives outbound network traffic from the client device, wherein the outbound network traffic: Indicates the requested IP address as the destination IP address, and Includes data directed to the server associated with the domain name; Receives inbound network traffic including a response to the outbound network traffic from the server associated with the domain name. Record network traffic including one or more of the following based on the domain matching criteria for the domain name and the corresponding action to be performed for the domain name: the outbound network traffic and the inbound network traffic; and Send the inbound network traffic to the client device.

90. A system including one or more computing devices, wherein, The system is configured to perform the method according to any one of claims 87 to 89.

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

92. A method for performing identity-based DNS routing by applying a security policy specific to an identified user to a Domain Name System (DNS) query, the method comprising: Using a DNS process and establishing a DNS session between an identity-based DNS routing platform and a client device; Receiving, when establishing the DNS session, a DNS query request including a request for an Internet Protocol (IP) address of a domain name, wherein the DNS query request specifies: the domain name corresponding to the DNS query request and identity information, and the identity information indicates at least two identities corresponding to the DNS query request; Determining the identity of the user of the client device based on the identity information; Determining the security policy specific to the user based on the identity of the user, wherein the security policy includes one or more overall domain name filtering rules, and each domain name filtering rule in the one or more overall domain name filtering rules includes a corresponding domain matching criterion and a corresponding action to be taken for a matching domain name; Using the one or more overall domain name filtering rules and determining a first action corresponding to the domain name based on the domain name in the DNS query request in response to the DNS query request; Determining a DNS query response based on the first action corresponding to the domain name, wherein the DNS query response includes: 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 for 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 for traffic directed to the requested IP address.

93. The identity-based DNS routing method according to claim 92, wherein, The local rule indicates whether the traffic directed to the requested IP address should be blocked, allowed, or recorded.

94. The identity-based DNS routing method according to claim 92, 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.

95. A system including one or more computing devices, wherein, The system is configured to perform the method according to any one of claims 92 to 94.

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

Images