Policy-based connection provisioning using domain name system (DNS) requests

Abstract

Described herein are techniques for policy-based connection provisioning using domain name system (DNS) requests. These techniques can include receiving policy data associated with one or more headend nodes that manage connections to computing resources. Further, these techniques can include receiving, from a client device, a DNS request to request establishment of a connection between the client device and a first headend node of the one or more headend nodes. The DNS request can include attributes associated with the client device. A provisioning service can determine, based at least in part on evaluating the attributes against the policy data, that the connection should be established between the client device and the first headend node. Further, these techniques can include sending, to the client device, an internet protocol (IP) address associated with the first headend node to facilitate establishment of the connection.

Description

[0001] Cross Reference to Related Applications

[0002] This patent application claims priority to U.S. Utility Patent Application No. 16 / 917,152, filed June 30, 2020, which is incorporated by reference herein in its entirety. TECHNICAL FIELD

[0003] The present disclosure relates generally to policy-based connection provisioning for connecting a device to a headend device using, at least in part, domain name system (DNS) requests. BACKGROUND

[0004] A virtual private network (VPN) extends a private network across a public network, such as the Internet, and enables end users to send and receive data across the public network as though their computing devices were directly connected to the private network. However, in a cloud computing environment, cloud-based resources host multiple private networks for different clients, and VPNs and similar technologies typically require establishing a large number of connections to cloud tunnel endpoints. Traditionally, when a VPN client attempts to connect to a tunnel headend, the VPN client only needs to know a basic DNS name, e.g., “vpn.company.com.” However, since the VPN headend belongs to a cloud service provider, this simple lookup is no longer sufficient. Therefore, deciding where to establish connectivity for a client requires evaluating additional criteria, and the selection of a specific tunnel endpoint should be transparent to the end user, but subject to policies defined by the client administrator and constraints of the cloud service. BRIEF DESCRIPTION OF DRAWINGS

[0005] A detailed description is given in the following reference to the accompanying drawings. In the drawings, the left-most digit(s) of reference numbers typically denote the first occurrence of the reference number in a figure. The use of identical reference numbers in different figures typically indicates similar or identical items. The systems depicted in the figures are not to scale and the components can be drawn in disproportionate to each other.

[0006] Figure 1 A system architecture diagram illustrating an example environment for policy-based connection provisioning using DNS requests.

[0007] Figure 2A AND 2B A dataflow diagram illustrating an example process for policy-based connection provisioning using DNS requests.

[0008] Figure 3 A block diagram illustrating example details of a provisioning service that can be used to provide policy-based connections using DNS requests.

[0009] Figure 4A flow diagram illustrating an example method of providing policy-based connectivity using DNS requests is shown.

[0010] Figure 5 A flow diagram illustrating another example method of providing policy-based connectivity using DNS requests is shown.

[0011] Figure 6 FIG. 1 is a computer architecture diagram illustrating an illustrative computer hardware architecture for a network device that can be used to implement aspects of the various technologies presented herein. DETAILED DESCRIPTION

[0012] SUMMARY

[0013] The present disclosure describes techniques of providing policy-based connectivity to computing resources using domain name system (DNS) requests. For example, some techniques described by the present disclosure can include receiving first policy data associated with a first headend device that manages one or more first connections to a first computing resource, and receiving second policy data associated with a second headend device that manages one or more second connections to a second computing resource. Further, a domain name system (DNS) request can be received from a client device, the DNS request indicating a desire to establish a communication connection with at least one of the first headend device and the second headend device. The DNS request can include attributes associated with the client device, such as a location of the client device, a device type of the client device, an identifier associated with the client, and the like. The attributes can then be evaluated against at least one of the first policy data and the second policy data, and based at least in part on the evaluation, a provisioning service can determine to establish the communication connection with the first headend device. Accordingly, the provisioning service can send an internet protocol (IP) address associated with the first headend device to the client device to facilitate establishment of the communication connection.

[0014] As another example, techniques described by the present disclosure can also include receiving, at a policy service, policy data associated with one or more headend nodes. The one or more headend nodes can include at least a first headend node that manages a first connection to a first computing resource. Additionally, a policy query can be received from a domain name service (DNS) service. The policy query can include at least a DNS request and attributes associated with a client node that generated the DNS request. Based at least in part on the policy data and based at least in part on the attributes, the policy service can determine to establish a second connection between the client node and the first headend node to provide the client node with access to the first computing resource. Accordingly, the policy service can subsequently send an internet protocol (IP) address corresponding to the first headend node to at least one of the DNS service and the client node to facilitate establishment of the second connection.

[0015] Further, the techniques described herein can be performed as a method and / or by a system having a non-transitory computer-readable medium storing computer-executable instructions, wherein the computer-executable instructions, when executed by one or more processors, perform the techniques described above.

[0016] Example Embodiments

[0017] As described above, when a VPN client attempts to connect to a tunnel head, the VPN client only needs to know a basic DNS name, e.g., “vpn.company.com.” However, this simple lookup is not sufficient in a cloud-based VPN because the VPN head belongs to a cloud service provider. Thus, deciding where to establish connectivity for the VPN client requires evaluating additional criteria, and the selection of a particular tunnel endpoint should be transparent to the end user, but subject to policies defined by the client administrator and constraints of the cloud service. Accordingly, the following improvements in technical aspects are described herein that provide for policy-based connection provisioning using DNS requests.

[0018] When deciding where to establish connectivity for a VPN, the cloud service needs to consider various factors, e.g., location of the VPN client, VPN client version, VPN client device identifier, VPN client identifier, etc. As described herein, when a DNS lookup is made through a cloud service provider DNS server, the DNS server consults a backend policy service. This policy service evaluates the DNS request by considering its knowledge of the client (e.g., location, client identifier, tenant, etc.) and evaluates these attributes against one or more head policies. The policy service is aware of the available tunnel heads and their characteristics and capabilities, including the capacity of the data center that is serving the tunnel endpoint. Using this type of information, a policy-driven selection of a tunnel head for the VPN client to connect to can be made. For example, if the tunnel head to which the VPN client can traditionally connect is at or near full capacity, then the VPN client connection can be redirected to a different tunnel head. This in turn allows for more efficient tunnel heads and provides a healthier or more suitable connection to the VPN client, which can reduce latency or otherwise improve performance. Further, the amount of resources used by each tunnel head can be reduced, which also reduces the likelihood of spillover to other cloud services.

[0019] By way of example and not limitation, methods in accordance with the technology described herein can include receiving first policy data associated with a first headend device that manages one or more first connections to first computing resources. In examples, the first headend device can include a virtual private network (VPN) headend node, and the one or more first connections can include one or more VPN tunnels between the VPN headend node and the first computing resources. The methods can also include receiving second policy data associated with a second headend device that manages one or more second connections to second computing resources. The second headend device can include another virtual private network (VPN) headend node, and the one or more second connections can include one or more other VPN tunnels. In some examples, the first policy data and the second policy data can be received at a provisioning service. In some examples, the provisioning service can include a DNS service, a policy service, or a combination thereof. For example, the provisioning service can include or at least include a DNS service that authenticates users attempting to establish VPN connections in at least some cases.

[0020] As used herein, the term "policy data" (such as the first policy data and the second policy data described in the preceding paragraph) can include data that indicates a policy according to which a headend node operates (e.g., a set of rules that the headend node must follow). For example, the policy data can indicate that a headend node policy only allows connections with client nodes located in a particular location (e.g., the United States, the western United States, the Pacific Northwest region of the United States, etc.). Additionally or alternatively, the policy data associated with a particular policy of a headend node can indicate a particular type of the headend node, a size of the headend node, headend node capabilities, etc. Additionally or alternatively, the policy data can further indicate a capacity limit (e.g., a maximum capacity) of a data center that the headend node is serving.

[0021] In various examples, the methods can include receiving, at a provisioning service from a client device, a domain name system (DNS) lookup request for requesting establishment of a communication connection with at least one of the first headend device and the second headend device in order to enable access to the one or more computing resources. The DNS request can include a base DNS name (e.g., "vpn.company.com") and an attribute associated with the client device. The attribute can include one or more of an identifier associated with the client (e.g., a client ID), a version associated with the client, an identifier associated with the client device (e.g., a device ID), a location of the client, a tenant associated with the client, etc. The attribute can be included in the DNS request or can be determined by the provisioning service for the client device after receiving the DNS request from the client device.

[0022] The method can also include evaluating the attribute with respect to at least one of the first policy data and the second policy data. For example, if the attribute includes a location associated with the client device, the location can be evaluated with respect to a location constraint indicated in the first policy data or the second policy data to determine whether a geographic location of the client device is within a threshold distance from the first headend device or the second headend device. In this way, based at least in part on the evaluation, the provisioning service can determine to establish the communication connection with the first headend device and send an Internet Protocol (IP) address associated with the first headend device to the client device to facilitate establishing the communication connection. In some examples, one or more IP addresses associated with different headend devices can be sent to the client device. For example, more than one headend device can be capable of servicing the client device to provide the connection. In this case, more than one IP address can be sent to the client device and the client device can determine which headend device to select based at least in part on additional parameters such as location constraints, speed, size, etc.

[0023] In some examples, telemetry data can be received from the headend devices (e.g., the first headend device and the second headend device). The telemetry data can indicate a current capacity of various computing resources associated with the respective headend devices, a current usage of the respective headend itself, etc. In this way, the method can include determining that a capacity of the first computing resource meets or exceeds a threshold capacity (e.g., the first computing resource still has capacity to service the client device) and determining to establish the communication connection with the first headend device can also be based at least in part on the capacity of the first computing resource. Further, in some examples, the threshold capacity can be determined based at least in part on an attribute associated with the client device (e.g., how much capacity is needed to service the client device and / or an amount of resources the client device is requesting).

[0024] The method can also include receiving attributes associated with the headend devices from the headend devices. In some examples, the attributes can indicate that the respective headend devices include a firewall, a geographic location of the headend device, or other static settings associated with the headend device. Further, in at least some examples, determining that a connection should be established between the client device and the headend device can also be based at least in part on the attributes of the headend devices.

[0025] In at least one example, the method can include authenticating that the client device is allowed to establish the communication connection based at least in part on the DNS request. For example, the DNS request can include data indicating that the client device is authorized to establish the communication connection. The data can include a unique identifier associated with the client device, a user of the client device, etc.

[0026] In some examples, evaluating the attribute for at least one of the first policy data and the second policy data can include sending a policy query to a tunnel policy service. For example, the provisioning service described above can include a DNS service and a tunnel policy service. The DNS service can send the policy query to the tunnel policy service. The policy query can include at least the DNS request and the attribute associated with the client device. In this way, the tunnel policy service can evaluate the attribute for a policy and, in at least some examples, other data (e.g., telemetry data and / or other headend attributes). Thus, after the tunnel policy service evaluates the request, the tunnel policy service can send the IP address associated with the first headend device to the DNS service. The DNS service can then forward the IP address to the client device to facilitate establishment of the connection.

[0027] Certain embodiments and examples of the present disclosure will be described below with reference to drawings illustrating various aspects of the disclosure. The various aspects can, however, be implemented in many different forms and should not be construed as limited to the embodiments set forth herein. The present disclosure includes all variations of the examples described herein. Like numbers refer to like elements throughout.

[0028] Figure 1 A system architecture diagram illustrating an example environment 100 for policy-based connection provisioning using DNS requests is shown. The example environment 100 includes various nodes and / or devices, such as headend nodes 102, computing resources 104, client nodes 106, user devices 108, and provisioning services 110, that are capable of communicating with one another.

[0029] The headend nodes 102 can include one or more headend nodes, such as headend nodes 102A, 102B, and 102N (where N represents any number greater than or equal to 1). As shown, the headend nodes 102 can manage one or more connections with respective computing resources 104. For example, headend node 102A manages a connection with computing resource 104A, headend node 102B manages a connection with computing resource 104B, and headend node 102N manages a connection with computing resource 104N. Although the connections between the headend nodes 102 and the computing resources 104 are shown as a single connection for ease of illustration, it is contemplated that each connection can include one or more connections. The headend nodes 102 can include any type of device having routing capabilities, such as a switch, router, gateway, or other network device. Further, the headend nodes 102 can provide connections to the computing resources 104 and / or client devices in accordance with a predefined policy. For example, the policy can indicate that a particular client node is not allowed to connect to a particular computing resource, can indicate that a client node located in a first geographic location is only allowed to connect to a computing resource located in the same first geographic location, and / or the like.

[0030] The computing resources 104 can provide services for the client nodes 106. Generally, the computing resources 104 can provide basic resources, such as compute (CPU), memory (RAM), storage (disk), and networking (bandwidth). In addition, in some examples, the computing resources 104 can provide, host, or otherwise support one or more application services for the client nodes 106 to connect to and use, e.g., a VPN session. The client nodes 106 can include any type of device configured to communicate over the network 112 using various communication protocols, such as IPSec, OpenVPN, SSL, TLS, DTLS, SSTP, IP Ev2, and / or any other protocol. For example, the client nodes 106 can include personal user devices (e.g., desktop computers, laptop computers, phones, tablets, wearable devices, entertainment devices such as televisions, etc.), network devices (e.g., servers, routers, switches, access points, etc.), and / or any other type of computing device.

[0031] In some cases, the computing resources 104 can be stored in various data centers located in different physical locations. For example, the computing resources 104A can be stored in a first data center located in a first geographic location, while the computing resources 104B can be stored in a second data center located in a second geographic location. A data center can be a physical facility or building located in a geographic region designated for the storage of networked devices. A data center can include various networked devices, redundant or backup components or infrastructure for power supply, data communications connections, environmental controls, and various security devices. In some examples, a data center can include one or more virtual data centers, which are pools or collections of cloud infrastructure resources designed specifically for enterprise needs and / or cloud-based service provider needs.

[0032] The client nodes 106 can access the head-end nodes 102 and the computing resources 104 through one or more networks 112, such as the Internet. The networks 112 can include one or more networks implemented by any viable communication technology (e.g., wired and / or wireless modes and / or technologies). The networks 112 can include any combination, arrangement, and / or aggregation of personal area networks (PANs), local area networks (LANs), campus area networks (CANs), metropolitan area networks (MANs), extranets, intranets, the Internet, short-range wireless communication networks (e.g., ZigBee, Bluetooth, etc.), wide area networks (WANs) - centralized and / or distributed - and / or any of them.

[0033] The headend nodes 102 and computing resources 104 can be accessed by the client nodes 106 over one or more networks 112, such as the Internet. The networks 112 can include one or more networks implemented by any workable communication technology, such as wired and / or wireless modes and / or technologies. The networks 112 can include any combination of personal area networks (PANs), local area networks (LANs), campus area networks (CANs), metropolitan area networks (MANs), extranets, intranets, the Internet, short-range wireless communication networks (e.g., ZigBee, Bluetooth, etc.), wide area networks (WANs), whether centralized and / or distributed, and / or any combination, permutation, and / or aggregation thereof.

[0034] The provisioning service 110 can authenticate or otherwise evaluate DNS requests received from the client nodes 106. As an example Figure 1 As shown, the provisioning service 110 can include a DNS service 114 and a policy service 116. In this way, if the client nodes 106 wish to establish a VPN connection with one of the computing resources 104, the provisioning service 110 can use the DNS service 114 and / or the policy service 116 to evaluate the DNS request to determine which computing resource (e.g., computing resource 104A, 104B, or 104N) is the "best match" for the client node 106 to connect to. Moreover, although shown as separate entities in Figure 1 It is contemplated, however, that the provisioning service 110 can perform the various functions of both the DNS service 114 and the policy service 116.

[0035] As an example Figure 1 Several example steps, numbered "1" through "7", are also shown to illustrate an example process for provisioning policy-based connections using DNS. At "1", the process begins with receiving one or more headend policies 118 from the user devices 108. The user devices 108 can represent system administrators and / or client administrators responsible for defining policies for each of the headend nodes 102. The headend policies 118 can be installed on each of the headend nodes 102, and each of the headend nodes 102 can include different policies. The headend policies 118 can then be stored by the policy service 116. Additionally or alternatively, the headend policies 118 can be stored by the DNS service 114 or the provisioning service 110. Generally, the headend policies 118 can include a set of rules or algorithms that are evaluated against parameters of a connection request received from the user devices 108 to determine what headend node 102 the user devices 108 are to connect to.

[0036] At "2", the headend node 102 can send headend node data 120, e.g., telemetry data, headend attributes, etc., to the provisioning service 110. The headend node data 120 can be received at the provisioning service 110 and / or the policy service 116 as conditions change for each headend node 102. For example, as the capacity of a headend node or computing resource decreases and / or increases, headend node data 120 can be sent to the provisioning service 110 to indicate the current capacity. In some examples, the headend node data 120 can be sent according to a predefined schedule (e.g., every second, every minute, every ten minutes, etc.). In this way, the provisioning service 110 can dynamically determine the accurate state of each headend node 102. The headend node data 120 can include telemetry data (e.g., usage, capacity, etc.) associated with each headend node 102 or computing resource 104. The telemetry data can include dynamic data that changes over time based on various factors (e.g., demand and usage). Additionally or alternatively, the headend node data 120 can include attributes (e.g., location of headend, type of headend node, size of headend node, etc.) associated with each headend node 102. In some examples, the attributes associated with each headend node 102 can include static data that does not change frequently over time.

[0037] At "3", the client node 106 can send a DNS request 122 to the provisioning service 110 over the network 112. The DNS request 122 can include a DNS lookup request or a request to establish a VPN connection with one of the computing resources 104 through a headend node 102. In some examples, the DNS request can include a DNS name as well as other client node information, e.g., a client identifier, a device identifier, a location of the client node, a client version, etc. The DNS request 122 can in turn be received by the provisioning service 110 and / or the DNS service 114.

[0038] At "4", the DNS request 122 is evaluated against at least one of the headend policies 118 and / or the headend node data 120 to identify which headend node and computing resource the client node 106 should connect to. In some examples, evaluating the DNS request 122 can include sending the DNS request 122 and the client node information from the DNS service 114 to the policy service 116. In this way, the policy service 116 can evaluate the DNS request and the client node information considering the various headend policies 118 stored by the policy service 116 as well as the headend node data 120. Further, once the policy service 116 completes the evaluation of the DNS request 122, the policy service 116 can send a headend IP address to the DNS service 114, which in turn can forward the IP address to the client node 106 to facilitate establishing a connection.

[0039] By way of example and not limitation, an example policy for a head-end node can require that a client node be located in the same geographic region as the head-end node and that the client version be a particular version. As such, evaluating the DNS request can include determining that the client node is located in the same geographic region as the head-end node and further determining that the client version is the particular version. In this way, if the DNS request indicates that the above policy conditions are satisfied, at least one of the policy service 116 and the provisioning service 110 can determine that the head-end node is allowed to connect to the client node to provide the client node with access to computing resources.

[0040] At "5", at least one of the provisioning service 110 and / or the DNS service 114 can send the head-end IP address 124 to the client node 106 over the network 112 to facilitate establishing a connection. The head-end IP address 124 can be sent only after the provisioning service 110 identifies an acceptable head-end node to serve the client node. The head-end IP address 124 can correspond to one or more head-end nodes. For example, in the example scenario 100, the head-end IP address 124 can correspond to the head-end node 102A. Figure 1

[0041] Finally, at "6", after receiving the head-end IP address 124, a connection is established between the client node 106 and the head-end node 102A to facilitate the flow of traffic 126 between the client node 106 and the computing resource 104A. In some examples, the connection can include a VPN connection and the traffic 126 can be encrypted as it is sent between the client node 106 and the computing resource 104A.

[0042] Figure 2A and 2B Data flow diagrams illustrating example processes 200 and 202 for policy-based connection provisioning using DNS requests are shown. Referring to Figure 2A , the process 200 begins at "1" where the user device 108 sends policy data 204 to the policy service 116. The policy data 204 can include one or more policies for individual ones of one or more head-end nodes (e.g., the head-end node 102A). The policy data 204 can be stored by the policy service 116 after being received.

[0043] ​At "2", the process 200 can include receiving headend node data 120 at the policy service 116 from the headend node 102A. The headend node data 120 can be received at the policy service 116 when conditions change for the headend node 102A. For example, as the capacity of the headend node 102A or computing resources decreases and / or increases, headend node data 120 can be sent to the policy service 116 to indicate the current capacity. In some examples, the headend node data 120 can be sent according to a predefined schedule, such as every second, every minute, every ten minutes, etc. In this way, the policy service 116 can dynamically determine the accurate state of the headend node 102A. The headend node data 120 can include at least one of headend node attributes and / or telemetry data associated with the headend node 102A and / or computing resources. The telemetry data can include dynamic data that changes over time based on various factors, such as demand and usage. For example, the telemetry data can indicate the current usage and / or capacity of the headend node 102A and / or computing resources, the number of available connections, etc. The headend node attributes can include the location of the headend node, the type of the headend node, the size of the headend node, etc. In some examples, the attributes associated with the headend node 102A can include static data that does not change frequently over time.

[0044] At "3", the process 200 can include receiving a DNS request 122 at the DNS service 114 from the client node 106. The DNS request 122 can include a DNS lookup request and / or a request to establish a VPN connection with the computing resources through the headend node 102A. In some examples, the DNS request 122 can include a DNS name (e.g., vpn.company.com) and other client node information, such as a client identifier, a device identifier, a location of the client node, a client version, etc. Additionally or alternatively, the DNS request 122 can include one or more credentials associated with the client node 106 in order to authenticate the client node 106.

[0045] At "4", the process 200 can include generating and sending a policy query 206 from the DNS service 114 to the policy service 116. The policy query 206 can include some or all of the information described above in step "5". For example, the policy query 206 can include the DNS request 122, or at least the DNS name included in the DNS request. Additionally or alternatively, the policy query 206 can include other information associated with the client node 106, such as a client identifier, a device identifier, a location of the client node 106, a client version, one or more credentials associated with the client node 106, etc. The policy query 206 can indicate to the policy service 116 that the client node 106 is attempting to connect to the headend node 102A.

[0046] Based at least in part on receiving the policy query 206, at "5", the policy service 116 evaluates the DNS request 122 included in the policy query 206. Evaluating the DNS request can include correlating information associated with the client node 106 with at least one of the policy data 204 and / or the headend node data 120. For example, if the policy of the headend node 102A includes a location constraint, the location of the client node 106 can be correlated with the location of the headend node 102B to determine whether the two are located in the same geographic region or within a threshold distance of each other. As another additional or alternative example, if the policy of the headend node 102A includes a constraint that the client node 106 have a minimum client version, evaluating the DNS request can include determining whether the client version of the client node 106 satisfies the minimum client version. As yet another additional or alternative example, if the policy of the headend node 102A includes a constraint that the headend node 102 or its backend computing resources not exceed a threshold capacity, the policy service 116 can evaluate whether establishing a connection with the client node 106 would cause the headend node 102A or the backend computing resources to exceed the threshold capacity.

[0047] At "6", based at least in part on the evaluation, the process 200 can include identifying the headend node IP address 124 and sending the headend node IP address 124 to the DNS service 114. The policy service 116 can identify the headend node IP address 124 based at least in part on determining that the headend node 102A would best serve the client node 106 and / or that the attributes associated with the client node 106 satisfy the constraints of the headend node 102A policy.

[0048] At "7", the DNS service 114 can receive the headend node IP address 124 from the policy service 116 and forward the headend node IP address 124 to the client node 106 to facilitate establishing a connection at step "8". As shown, a connection can be established between the client node 106 and the headend node 102A. The connection can enable the client node 106 to access one or more backend computing resources through the headend node 102A. As an example, the client node 106 can access a VPN session running on a backend computing resource and the headend node 102A can act as a VPN tunnel head for the VPN session.

[0049] Referring now to Figure 2B The process 202 begins at step "1", during which the user device 108 sends the policy data 204 to the provisioning service 110. The policy data 204 can include one or more policies for individual ones of one or more headend nodes (e.g., the headend node 102A). The policy data 204 can be stored by the provisioning service 110 after being received.

[0050] At "2", the process 202 can include receiving headend node data 120 at the provisioning service 110 from at least the headend node 102A. The headend node data 120 can be received at the provisioning service 110 when conditions change for the headend node 102A. For example, as the capacity of the headend node 102A or computing resources decreases and / or increases, headend node data 120 can be sent to the provisioning service 110 to indicate the current capacity. In some examples, the headend node data 120 can be sent according to a predefined schedule (e.g., every second, every minute, every ten minutes, etc.). In this way, the provisioning service 110 can dynamically determine the accurate state of the headend node 102A. The headend node data 120 can include at least one of headend node attributes and / or telemetry data associated with the headend node 102A and / or backend computing resources. The telemetry data can include dynamic data that changes over time based on various factors (e.g., demand, usage, etc.). For example, the telemetry data can indicate the current usage and / or capacity of the headend node 102A and / or backend computing resources, the number of available connections, etc. The headend node attributes can include the location of the headend node, the type of the headend node, the size of the headend node, etc. In some examples, the attributes associated with the headend node 102A can include static data that does not change frequently over time.

[0051] At "3", the process 202 can include receiving a DNS request 122 at the provisioning service 110 from the client node 106. The DNS request 122 can include a DNS lookup request and / or a request to establish a VPN connection with the backend computing resources through the headend node 102A. In some examples, the DNS request 122 can include a DNS name (e.g., vpn.company.com) and other client node information, such as a client identifier, a device identifier, a location of the client node, a client version, etc. Additionally or alternatively, the DNS request 122 can include one or more credentials associated with the client node 106 in order to authenticate the client node 106.

[0052] Based at least in part on receiving the DNS request 122, at "4", the provisioning service 110 evaluates the DNS request 122 against at least one of the policy data 204 and / or the headend node data 120. Evaluating the DNS request 122 can include correlating information associated with the client node 106 (information received in the DNS request 122) with at least one of the policy data 204 and / or the headend node data 120. For example, if the policy of the headend node 102A includes a location constraint, the location of the client node 106 can be correlated with the location of the headend node 102B to determine whether both are located in the same geographic region or are within a threshold distance of each other. As another additional or alternative example, if the policy of the headend node 102A includes a constraint that the client node 106 has a minimum client version, evaluating the DNS request can include determining whether the client version of the client node 106 satisfies the minimum client version. As yet another additional or alternative example, if the policy of the headend node 102A includes a constraint that the headend node 102 or its backend computing resources do not exceed a threshold capacity, the policy service 116 can evaluate whether establishing a connection with the client node 106 would cause the headend node 102A or the backend computing resources to exceed the threshold capacity.

[0053] At "5", based at least in part on the evaluation, the process 202 can include identifying the headend node IP address 124 and sending the headend node IP address 124 to the client node 106. The provisioning service 110 can identify the headend node IP address 124 based at least in part on determining that the headend node 102A will best serve the client node 106 and / or that the attributes associated with the client node 106 satisfy the constraints of the headend node 102A policy. The provisioning service 110 can send the headend node IP address 124 to the client node 106 to facilitate establishing a connection between the client node 106 and the headend node 102A at step "6". After the connection is established, the client node 106 can access one or more backend computing resources through the headend node 102A. For example, the client node 106 can open a VPN session on one or more backend computing resources, and the headend node 102A can act as a VPN tunnel headend.

[0054] Figure 3 A block diagram 300 is shown illustrating example components of a provisioning service 110 that can be used to provide policy-based connections using DNS requests. As shown, the provisioning service 110 can include one or more physical and / or logical components.

[0055] The provisioning service 110 can include one or more hardware processors 302 (processors) configured to execute one or more stored instructions. The processors 302 can include one or more cores. Further, the provisioning service 110 can include one or more network interfaces 304 configured to provide communication between the provisioning service 110 and other devices (e.g., client nodes / devices 106, user devices 108, headend nodes 102, computing resources 104, etc.). The network interfaces 304 can include devices configured to couple to a network(s) 112, such as a personal area network (PAN), a wired and / or wireless local area network (LAN), a wired and / or wireless wide area network (WAN), etc. For example, the network interfaces 304 can include devices compatible with Ethernet, Wi-Fi™, etc.

[0056] The provisioning service 110 can also include a computer-readable medium 306 that stores various executable components (e.g., software-based components, firmware-based components, etc.). For example, the computer-readable medium 306 can store a DNS service component 308 and a policy service component 310 that are used to establish policy-based connections to computing resources using DNS requests. The DNS service component 308 and the policy service component 310 can store various data and information within one or more data stores 312 accessible to these components.

[0057] The DNS service component 308 can include one or more physical and / or logical components that perform various functions, such as an authentication component 314, a policy query component 316, and a client attribute component 318. The authentication component 314 can authenticate client nodes that are attempting to establish connections to headend nodes and / or backend computing resources. In some examples, the authentication component 314 can receive DNS requests from client nodes / devices and access one or more DNS addresses 320 stored in the data store(s) 312 in order to authenticate the client nodes / devices.

[0058] The policy query component 316 can generate and send a policy query on behalf of the DNS service component 308 to a policy service. The policy query can be generated and sent after receiving a DNS request from a client node. The policy query can include a DNS address associated with the client node attempting to connect as well as other information about the client node (e.g., location, client version, device ID, client ID, etc.).

[0059] The client properties component 318 can determine client properties associated with a client node attempting to connect. For example, the client properties component 318 can parse and / or analyze any received DNS requests from a client node to determine a location of the client node, a client version number, a client device ID, etc. Additionally or alternatively, the client properties component 318 can send a request to a client node for client node information in response to receiving a DNS request from the client node.

[0060] The policy service component 310 can include one or more physical and / or logical components that perform various functions, such as an evaluation component 322, a policy component 324, an identification component 326, and a geo-location component 328. The policy service component 310 can use some or all of these components to determine a head-end node that is best suited to service a requesting connection from a client node.

[0061] The evaluation component 322 can evaluate incoming policy queries from the DNS service 308. The evaluation component 322 can evaluate client node properties and DNS requests in the policy queries against at least one of the head-end node policies 332 and the head-end node data 334, including the telemetry data 336 and the head-end node properties data 338. The evaluation component 322 can access the data store 312 to retrieve this data. For example, in response to receiving a policy query from the DNS service 308, the evaluation component can retrieve various head-end node policies 322 and head-end node data 334 in order to evaluate which head-end node would best serve a client node. The evaluation component 322 can receive data from other components of the policy service component 310, such as the policy component 324, the identification component 326, and the geo-location component 328, in order to conduct the evaluation.

[0062] The policy component 324 can retrieve head-end node policies 332 from the data store 312 in order to evaluate incoming policy queries. For example, the policy component 324 can provide head-end node policies 332 to the evaluation component 322 in order for the evaluation component to evaluate an incoming policy query.

[0063] The identification component 326 can identify a head-end node IP address 330 corresponding to a selected head-end node. For example, the evaluation component 322 can indicate a selected head-end node that would best serve a client node, and the identification component 326 can identify an IP address corresponding to that head-end node. In this way, the head-end node IP address can be forwarded to the client node to facilitate establishing a connection.

[0064] The geo-location component 328 can determine a geo-location associated with a client node based at least in part on analyzing geo-location data that can be included in a policy query. Additionally or alternatively, the geo-location component 328 can determine geo-locations associated with various head-end nodes. Additionally or alternatively, the geo-location component 328 can determine a distance between a client node and various head-end nodes that can be providing services to the client node.

[0065] The DNS addresses 320 can include a list of all DNS addresses known to the provisioning service 110. Additionally, the DNS addresses 320 can include DNS addresses that are blocked by the provisioning service 110 or otherwise should not be allowed to connect.

[0066] The head-end node IP addresses 330 can include a list of all IP addresses corresponding to various head-end nodes that can serve a client node. The head-end node policies 332 can include a respective policy for each of the various head-end nodes. As an example and not by way of limitation, a head-end policy can indicate that a tunnel head-end includes a location constraint (e.g., can only connect to client nodes in a particular geographic region), a load constraint (e.g., how many client nodes a head-end node can connect to at a time), and a minimum client version, among others.

[0067] The head-end node data 334 can include both telemetry data 336 and head-end node attribute data 338. The telemetry data 336 can be received at the provisioning service 110 as conditions change for each head-end node. For example, as the capacity of a head-end node or computing resource decreases and / or increases, telemetry data 336 can be sent to the provisioning service 110 to indicate the current capacity of the head-end node and / or computing resource. In some examples, the telemetry data 336 can be received according to a predefined schedule (e.g., every second, every minute, every ten minutes, etc.). In this way, the provisioning service 110 can dynamically determine the accurate state of the head-end node and / or computing resource. The telemetry data 336 can include dynamic data that changes over time based on various factors (e.g., demand, usage, etc.). For example, the telemetry data can indicate the current usage and / or capacity of a head-end node and / or backend computing resource, the number of available connections, etc. The head-end node attribute data 338 can include the location of a head-end node, the type of head-end node, the size of a head-end node, the presence of a firewall at or behind a head-end node, etc. In some examples, the head-end node attribute data 338 can include static data that does not change frequently over time.

[0068] Figure 4 and 5 Flowcharts illustrating example methods 400 and 500 are shown, which illustrate at least partially by the provisioning service 110, the DNS service 114, the policy service 116, the head-end nodes 102, and / orFigures 1-3 other devices / nodes shown to perform aspects of the functionality described herein. In this regard, various aspects are described in terms of this example Figure 4 and Figure 5 The logical operations described herein are implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and / or (2) as interconnected machine logic circuits or circuit modules within the computing system.

[0069] The implementation of the various components described herein are a function of the performance demands of the computing system. The logical operations of various embodiments are implemented differently depending on the technology used to implement the operations. Thus, acts described herein are referred to as operations, structural devices, acts, or modules. These operations, structural devices, acts, and modules can be implemented in software, in firmware, in special purpose digital logic, and any combination thereof. It should also be appreciated that more or fewer operations might be performed than shown in the figures and described herein. These operations can also be performed in parallel, or in different order than those described herein. Some or all of these operations can also be performed by components other than those specifically identified. Although the techniques described in this disclosure are with reference to particular components, in other examples, these techniques can be implemented by less components, more components, different components, or any configuration of components. Figure 4 and Figure 5 more or less operations shown and described herein. These operations can also be performed in parallel, or in different order than those described herein. Some or all of these operations can also be performed by components other than those specifically identified. Although the techniques described in this disclosure are with reference to particular components, in other examples, these techniques can be implemented by less components, more components, different components, or any configuration of components.

[0070] Figure 4 A flow diagram illustrating an example method 400 for providing policy-based connectivity using DNS requests is shown. The method 400 begins at operation 402, during which first policy data is received, the first policy data associated with a first headend device that manages one or more first connections to first computing resources. The first policy data can be received at a provisioning service, such as the provisioning service 110, or at a separate policy service. Further, in some examples, the first policy data can be received from a user device. The user device can correspond to a network administrator that defines policies for various headend devices, or the user device can correspond to a client administrator that defines policies for client connections. Additionally or alternatively, the first policy data can be received from the first headend device when the first headend device registers with the policy service and / or the provisioning service.

[0071] At 404, the method 400 includes receiving second policy data, the second policy data associated with a second headend device that manages one or more second connections to second computing resources. The second policy data can be received at a provisioning service, such as the provisioning service 110, or at a separate policy service. Further, in some examples, the second policy data can be received from a user device. Additionally or alternatively, the second policy data can be received from the second headend device when the second headend device registers with the policy service and / or the provisioning service.

[0072] At 406, the method 400 includes receiving a domain name system (DNS) request, the DNS request to request establishment of a communication connection between a client device and at least one of a first headend device and a second headend device, the DNS request including an attribute associated with the client device. In some examples, the DNS request can include a DNS lookup request received at a provisioning service or a DNS service. The attribute associated with the client device can include a location of the client device, a client ID, a device ID, a client version number, etc. The DNS request can include a DNS name, e.g., vpn.company.com.

[0073] At 408, the method 400 includes evaluating the attribute for at least one of first policy data and second policy data. For example, if the first policy data includes a location constraint, the location of the client device can be determined based at least in part on the attribute. If the client device and the first headend device are located in the same geographic region or within a threshold distance of each other, the first headend device can be selected to establish the connection. As another additional or alternative example, if the first policy data of the first headend device or the second policy data of the second headend device includes a constraint that the client device has a minimum client version, evaluating the attribute can include determining whether the client version of the client device satisfies the minimum client version.

[0074] In some examples, additionally or alternatively, the first policy data or the second policy data can be evaluated for attributes associated with the first headend device or the second headend device and / or for telemetry data received from the first headend device or the second headend device. Further, the DNS request and / or the attribute associated with the client device can be evaluated for attributes associated with the first headend device or the second headend device and / or for telemetry data received from the first headend device or the second headend device. In this way, for example, if the first policy data or the second policy data includes a constraint that the first headend device or the second headend device or their backend computing resources do not exceed a threshold capacity, the provisioning service can evaluate whether establishing a connection with the client device will cause the first headend device or the second headend device or their backend computing resources to exceed the threshold capacity.

[0075] At 410, the method 400 includes determining to establish the communication connection with the first headend device. In various examples, determining to establish the communication connection with the first headend device can be based at least in part on the evaluation described above for block 408. For example, after the evaluation, it can be determined that the first headend device is more preferable to establish a connection with the client device. For example, the first headend device can be located within a threshold distance of the client device. As an additional or alternative example, the first headend device and its backend computing resources can have more capacity available to allocate to the client device compared to the second headend device and / or its backend computing resources.

[0076] At 412, the method 400 includes sending an Internet Protocol (IP) address associated with the first headend device to the client device to facilitate establishment of the communication connection. Upon receiving the IP address, the client node can begin establishing the communication connection by sending packets to the IP address corresponding to the first headend device. In at least one example, sending the IP address to the client device can include sending multiple IP addresses to the client device. The multiple IP addresses can correspond to headend devices that are deemed acceptable to establish a connection with the client device. In this manner, the client device can have an opportunity to perform additional constraint filtering to identify a most preferred headend device (e.g., by selecting a headend device with a lowest cost, by selecting a closest headend device, by selecting a fastest operating headend device, etc.).

[0077] Figure 5 A flowchart illustrating another example method 500 for providing policy-based connectivity using DNS requests is shown. At 502, the method 500 begins by receiving, at a policy service, policy data associated with one or more headend nodes including a first headend node that manages a first connection to a first computing resource. The policy service can include a standalone service or can be included as part of a provisioning service that also includes other components (e.g., a DNS service). Further, in some examples, the policy data can be received from a user device. The user device can correspond to a network administrator that defines policies for various headend devices, or the user device can correspond to a client administrator that defines policies for client connections. Additionally or alternatively, the policy data can be received from one or more headend nodes when the headend nodes register with the policy service.

[0078] At 504, the method 500 includes receiving, from a DNS service, a policy query including at least a DNS request and attributes associated with a client node that generated the DNS request. The DNS request can include a base DNS name, e.g., vpn.company.com. Further, the attributes associated with the client node can indicate a location of the client node, a client identifier, a client device identifier, a version of the client node and / or device, etc.

[0079] At 506, the method 500 includes determining, based at least in part on the policy data and based at least in part on the attributes, to establish a second connection between the client node and a first headend node to provide the client node with access to the first computing resource. For example, if the policy data includes a location constraint, the location of the client node can be determined based at least in part on the attributes. If the client node and the first headend node are both located in the same geographic region or within a threshold distance of each other, the first headend node can be selected to establish the connection. As another additional or alternative example, if the policy data includes a constraint that the client device has a minimum client version, evaluating the attributes can include determining whether the client version of the client node satisfies the minimum client version.

[0080] In some examples, additionally or alternatively, the policy data can be evaluated with respect to attributes associated with one or more headend nodes and / or with respect to telemetry data received from one or more headend nodes. Further, the DNS request and / or the attributes associated with the client node can be evaluated with respect to attributes associated with one or more headend nodes and / or with respect to telemetry data received from one or more headend nodes. In this way, for example, if the policy data includes a constraint that one or more headend nodes or their backend computing resources do not exceed a threshold capacity, the policy service can evaluate whether establishing a connection with the client node would cause any of the one or more headend nodes or their backend computing resources to exceed the threshold capacity. In this way, a headend node can be selected in which establishing a connection would not exceed the capacity of the headend node or its backend computing resources.

[0081] At 508, the method 500 includes sending, to a DNS service, an internet protocol (IP) address corresponding to the first headend node to facilitate establishment of the second connection. When the IP address is received, the DNS service can forward the IP address to the client node so that the client node can begin establishing a connection with the first headend node. In various examples, identifying the IP address to send can be based at least in part on determining to establish a connection with the first headend node.

[0082] Figure 6 FIG. 1 is a computer architecture diagram illustrating an illustrative computer hardware architecture for a network device that can be used to implement aspects of the various functional techniques presented herein. Figure 6The illustrated computer architecture shows a conventional server computer, headend node 102, computing resource 104, client node 106, user device 108, workstation, desktop computer, laptop computer, tablet computer, network appliance, e-reader, smartphone, or other computing device, and can be used to execute any of the software components presented herein. In some examples, computer 600 can correspond to a network appliance, and can include a networking device, e.g., a server, switch, router, hub, bridge, gateway, modem, repeater, access point, etc.

[0083] Computer 600 includes a baseboard 602, or "motherboard," which is a printed circuit board to which a multitude of components or devices can be connected by way of a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units ("CPUs") 604 operate in conjunction with a chipset 606. CPUs 604 can include standard

[0084] CPUs 604 perform operations by manipulating and transforming data represented as physical states of transistors in the CPU 604. The CPUs 604 can perform these operations according to instructions stored in memory. The instructions can be in the form of firmware, software, middleware, multi-threaded code, or microcode stored in a memory location.

[0085] Chipset 606 provides an interface between the CPU 604 and the remainder of the components and devices on the baseboard 602. Chipset 606 can provide an interface between the CPU 604 and a RAM 608 used as main memory in the computer 600. Chipset 606 can also provide an interface to the computer-readable storage media, including a read only memory ("ROM") 610 or non-volatile RAM ("NVRAM") for storing basic routines that help to startup the computer 600 and transfer information between the various components and devices. The ROM 610 or NVRAM can also store other software components required for the operation of the computer 600 according to the configurations described herein.

[0086] The computer 600 can operate in a networked environment using logical connections to remote computing devices and computer systems through a network, such as the network 112. The chipset 606 can include functionality for providing network connectivity through a NIC 612, such as a gigabit Ethernet adapter. The NIC 612 is capable of connecting the computer 600 to other computing devices over the network 112. It should be appreciated that multiple NICs 612 can be present in the computer 600, connecting the computer to other types of networks and remote computer systems.

[0087] The computer 600 can be connected to a storage device 618 that provides non-volatile storage for the computer. The storage device 618 can store the operating system 620, the programs 622, and the data, which have been described in greater detail herein. The storage device 618 can be connected to the computer 600 through the storage controller 614 connected to the chipset 606. The storage device 618 can be composed of one or more physical storage units. The storage controller 614 can interface with the physical storage units through a serial attached SCSI (“SAS”) interface, a serial advanced technology attachment (“SATA”) interface, a fiber channel (“FC”) interface, or other type of interface for connecting to physical storage units and transferring data between the computer and the physical storage units.

[0088] The computer 600 can store data on the storage device 618 by transforming the physical state of the physical storage units to reflect the information being stored. The specific transformation of physical state can depend on various factors, in different embodiments of this description. Examples of these factors can include, but are not limited to, the technology used to implement the physical storage units, whether the storage device 618 is characterized as primary or secondary storage, or the like.

[0089] For example, the computer 600 can store information to the storage device 618 by issuing instructions through the storage controller 614 to alter the magnetic characteristics of a particular location within a magnetic disk drive unit, the reflective or refractive characteristics of a particular location within an optical storage unit, or the electrical characteristics of a particular capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this description. The computer 600 can further read information from the storage device 618 by detecting the physical states or characteristics of one or more particular locations within the physical storage units.

[0090] In addition to the mass storage device 618 described above, the computer 600 can have access to other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. It should be appreciated by those skilled in the art that computer-readable storage media is any available media that provides for the non- transitory storage of data and that can be accessed by the computer 600. In some examples, the operations performed by the environment 100 and / or any components included therein can be supported by one or more devices similar to the computer 600. In other words, some or all of the operations performed by the environment 100 and / or any components included therein can be performed by one or more computer devices 600 operating in a cloud-based arrangement.

[0091] By way of example, and not limitation, computer-readable storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media includes, but is not limited to, RAM, ROM, erasable programmable ROM ("EPROM"), electrically-erasable programmable ROM ("EEPROM"), flash memory or other solid-state memory technology, compact disc ROM ("CD-ROM"), digital versatile disc ("DVD"), high definition DVD ("HD-DVD"), BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information in a non-transitory fashion.

[0092] As described above, the storage device 618 can store an operating system 620 used to control the operation of the computer 600. According to one embodiment, the operating system comprises a LINUX operating system. According to another embodiment, the operating system comprises a WINDOWS® SERVER operating system from MICROSOFT Corporation of Redmond, Washington. According to a further embodiment, the operating system can comprise a UNIX operating system or one of its variants. It should be appreciated that other operating systems can also be used. The storage device 618 can store other systems or applications and data used by the computer 600.

[0093] In one embodiment, the storage device 618 or other computer-readable storage media is encoded with computer-executable instructions which, when loaded into the computer 600, transform the computer from a general-purpose computing system into a special-purpose computing system capable of implementing the embodiments described herein. These computer-executable instructions, when executed, transform the computer 600 by specifying how the CPU 604 transitions between states, as described above. According to one embodiment, the computer 600 has access to computer-readable storage media storing computer-executable instructions which, when executed, perform the operations described above with respect to Figures 1-5The various processes described herein. The computer 600 may also include a computer-readable storage medium having instructions stored thereon for performing operations of any other computer implementation described herein.

[0094] Computer 600 may also include one or more input / output controllers 616 for receiving and processing input from multiple input devices (e.g., keyboard, mouse, touchpad, touchscreen, electronic pen, or other types of input devices). Similarly, input / output controllers 616 may provide output to a display (e.g., computer monitor, flat panel display, digital projector, printer, or other types of output device). It should be understood that computer 600 may not include... Figure 6 All components shown, and may include Figure 6 Other components not explicitly shown, or those that can be used with Figure 6 The architecture shown is completely different from the one described above.

[0095] As described herein, computer 600 may include one or more of the following: headend node 102, computing resource 104, client node / device 106, user equipment 108, provisioning service 110, DNS service 114, or policy service 116. Computer 600 may include one or more hardware processors 604 (processors) configured to execute one or more stored instructions. The processors 604 may include one or more cores. Furthermore, computer 600 may include one or more network interfaces configured to provide communication between computer 600 and other devices, such as those described herein. Figures 1-5 The various devices / nodes described herein perform the communications. Network interfaces may include devices configured to couple to personal area networks (PANs), wired and wireless local area networks (LANs), wired and wireless wide area networks (WANs), etc. For example, network interfaces may include devices compatible with Ethernet, Wi-Fi™, etc.

[0096] Program 622 may include any type of program or process to perform the techniques described in this disclosure for establishing policy-based connections using DNS requests. Program 622 can enable the various devices and components described herein to perform a variety of operations.

[0097] While the invention has been described with reference to specific examples, it should be understood that the scope of the invention is not limited to these specific examples. Since other modifications and alterations to suit specific operational requirements and environments will be apparent to those skilled in the art, the invention is not to be considered limited to the examples chosen for the purposes of disclosure, and covers all changes and modifications that do not constitute a departure from the true spirit and scope of the invention.

[0098] While the present application describes embodiments with specific structural features and / or method acts, it is to be understood that the claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are merely illustrative of some of the many embodiments falling within the scope of the claims.

Claims

1. A method for policy-based connection provisioning, comprising: receiving first policy data associated with a first headend device that manages one or more first connections to first computing resources; receiving second policy data associated with a second headend device that manages one or more second connections to second computing resources; receiving, from a client device, a domain name system (DNS) request to request establishment of a communication connection with at least one of the first headend device and the second headend device, the DNS request including attributes associated with the client device; evaluating the attributes against at least one of the first policy data and the second policy data; determining, based at least in part on the evaluation, that the communication connection is to be established with the first headend device; and sending, to the client device, an internet protocol (IP) address associated with the first headend device to facilitate establishment of the communication connection. receiving, from the first headend device, first telemetry data indicating a capacity of the first computing resources associated with the first headend device, wherein the evaluation further comprises determining that the capacity of the first computing resources meets or exceeds a threshold capacity.

2. The method of claim 1, further comprising: determining the threshold capacity based at least in part on the attributes associated with the client device.

3. The method of claim 2, further comprising: authenticating, based at least in part on the DNS request, that the client device is permitted to establish the communication connection.

4. The method of any of the preceding claims, further comprising: the attributes associated with the client device include at least one of a client identifier, a user identifier, and a geographic location associated with the client device.

5. The method of any one of claims 1 to 3, wherein, evaluating the attributes against at least one of the first policy data and the second policy data comprises sending a policy query to a tunnel policy service, the policy query including at least the DNS request and the attributes, the method further comprising receiving, from the tunnel policy service, the IP address associated with the first headend device.

6. The method of any one of claims 1 to 3, wherein, 7. A system for policy-based connection provisioning, comprising: one or more processors; and one or more non-transitory computer-readable media storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: receiving first policy data associated with a first headend node that manages a first connection to first computing resources; receiving second policy data associated with a second headend node that manages a second connection to second computing resources; receiving, from a client device, a domain name system (DNS) request to request establishment of a third connection between the client device and at least one of the first headend node and the second headend node, the DNS request including attributes associated with the client device; determining, based at least in part on evaluating the attributes against at least one of the first policy data and the second policy data, that the third connection should be established between the client device and the first headend node; and receiving, from a client device, a domain name system (DNS) request to request establishment of a third connection between the client device and at least one of the first headend node and the second headend node, the DNS request including attributes associated with the client device; ​ ​ sending, to the client device, an Internet Protocol (IP) address associated with the first head-end node to facilitate establishing the third connection.

8. The system of claim 7, the operations further comprising: receiving, from the first head-end node, telemetry data indicative of a capacity of the first computing resource; determining, based at least in part on the telemetry data, that the capacity of the first computing resource is less than a threshold capacity; and wherein determining that the third connection should be established between the client device and the first head-end node is further based at least in part on the capacity of the first computing resource being less than the threshold capacity.

9. The system of claim 7 or 8, the operations further comprising: receiving, from the first head-end node, an attribute associated with the first head-end node, the attribute indicating at least one of: a presence of a firewall on the first head-end node, and a geographic location of the first head-end node; and wherein determining that the third connection should be established between the client device and the first head-end node is further based at least in part on the attribute.

10. The system of claim 7 or 8, the operations further comprising: receiving, from the second head-end node, telemetry data indicative of a capacity of the second computing resource; determining, based at least in part on the telemetry data, that the capacity of the second computing resource meets or exceeds a threshold capacity; and wherein determining that the third connection should be established between the client device and the first head-end node is further based at least in part on the capacity of the second computing resource being greater than the threshold capacity.

11. The system of claim 7 or 8, wherein, the attribute associated with the client device comprises at least one of a client identifier, a user identifier, and a geographic location associated with the client device.

12. The system of claim 7 or 8, wherein, determining that the third connection should be established between the client device and the first head-end node comprises sending a policy query to a tunnel policy service, the policy query comprising at least the DNS request and the attribute, the operations further comprising receiving, from the tunnel policy service, the IP address associated with the first head-end node.

13. The system of claim 7 or 8, wherein, the first policy data and the second policy data comprise at least one of a type associated with the first head-end node and the second head-end node, a size of the first head-end node and second head-end node, and a capability associated with the first head-end node and the second head-end node.

14. The system of claim 7 or 8, wherein, the attribute associated with the client device comprises a geographic location associated with the client device, the operations further comprising: determining that a distance between the first head-end node and the geographic location is within a threshold distance; and wherein determining that the third connection should be established between the client device and the first head-end node is further based at least in part on the distance being within the threshold distance.

15. A method for policy-based connection provisioning, comprising: receiving, at a policy service, policy data associated with one or more headend nodes, the one or more headend nodes including a first headend node that manages a first connection to a first computing resource, the policy data including at least first policy data associated with the first headend node and second policy data associated with a second headend node of the one or more headend nodes; receiving, from a domain name system (DNS) service, a policy query including at least a DNS request and an attribute associated with a client node that generated the DNS request; determining, based at least in part on the policy data and based at least in part on the attribute, to establish a second connection between the client node and the first headend node to provide the client node with access to the first computing resource; and sending, to the DNS service, an internet protocol (IP) address corresponding to the first headend node to facilitate establishment of the second connection.

16. The method of claim 15, wherein, the policy data includes at least one of a type associated with each headend node of the one or more headend nodes, a size associated with each headend node of the one or more headend nodes, and a capability associated with each headend node of the one or more headend nodes.

17. The method of claim 15 or 16, wherein, the attribute associated with the client node includes at least one of a client identifier, a user identifier, and a geographic location associated with the client node.

18. The method of claim 17, wherein, the attribute includes a geographic location associated with the client node, and wherein determining to establish the second connection between the client node and the first headend node is further based at least in part on the geographic location associated with the client node.

19. The method of claim 15 or 16, further comprising: receiving telemetry data indicating a capacity of the first computing resource; determining that the capacity meets or exceeds a threshold capacity; and wherein determining to establish the second connection between the client node and the first headend node is further based at least in part on the capacity meeting or exceeding the threshold capacity.

20. A system for policy-based connection provisioning, comprising: one or more processors; and one or more non-transitory computer-readable media storing instructions that, when executed by the one or more processors, cause the one or more processors to perform the method of any of claims 15-19.

21. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, cause the method of any of claims 1-6 and / or 15-19 to be performed. ​ ​

Images