SYSTEMS

BACKGROUND

[0001] Generally described, computing devices utilize a communication network, or a series of communication networks, to exchange data. Companies and organizations operate computer networks that interconnect a number of computing devices to support operations or provide services to third parties. The computing systems can be located in a single geographic location or located in multiple, distinct geographic locations (e.g., interconnected via private or public communication networks). Specifically, data centers or data processing centers, herein generally referred to as "data centers," may include a number of interconnected computing systems to provide computing resources to users of the data center. The data centers may be private data centers operated on behalf of an organization or public data centers operated on behalf, or for the benefit of, the general public.

[0002] Existing routing and addressing technologies can enable multiple data centers to provide similar or identical content to client computing devices. In some instances, each data center providing a set of content may be referred to as a point-of-presence ("POP") for a content delivery system (or other organization) providing the content. Content delivery systems (sometimes referred to as "content delivery networks," or "CDNs") often prefer to connect users to a geographically-nearby POP, as such connections are commonly quicker and more reliable than connections between a user and a geographically-distant POP. Accordingly, a content delivery system can maintain POPs over a wide area (or worldwide). Thereafter, requests for content from the content delivery system can be routed to a nearby POP for fulfillment.

[0003] Each POP may be associated with an address on a computing network, such as an Internet Protocol (IP) address. However, requests for content are generally addressed to a human-readable identifier, such as a universal resource identifier (URI) or domain name. To enable use of human-readable identifiers in accessing content, a client computing device can interact with a Domain Name System (DNS) that operates to resolve a domain name into a corresponding network address (e.g., IP address). Typically, a CDN is associated with one or more domain names, and an operator of CDN will have authority to alter DNS records specifying IP addresses to which those domain names resolve. Thus, the operator of a CDN can utilize DNS records to control how requests to access content of the CDN are routed to POPs.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] FIG. 1 is a block diagram depicting an illustrative logical network including multiple client computing devices and domain name system (DNS) resolvers, as well as a content delivery system including multiple points-of-presence (POPs), multiple DNS servers, and a DNS-to-POP routing mapping service that can determine a mapping between DNS resolvers and POPs for use by the DNS servers;

[0005] FIG. 2A is a block diagram depicting associations between subnets of a computer network (each subnet including one or more client computing devices), DNS resolvers, and POPs of the content delivery system of FIG. 1;

[0006] FIG. 2B is a block diagram depicting associations between subnets of a computer network and volume of communications to individual links associated with a POP of the content delivery system of FIG. 1;

[0007] FIG. 3 is a block diagram depicting illustrative interactions for determining mappings of DNS resolvers to POPs of the content delivery system of FIG. 1 based on a predicted load on individual links of POPs as a result of the mappings;

[0008] FIG. 4 is a flow-diagram of a routine to generate mappings of DNS resolvers to POPs of the content delivery system of FIG. 1, which mappings may be utilized by DNS servers of the content delivery system to respond to resolution requests from DNS resolvers;

[0009] FIG. 5 is a flow-diagram of a routine to determine an association between an individual DNS resolver and a POP of the content delivery system of FIG. 1 based on a predicted load on individual links of the POP as a result of the association; and

[0010] FIG. 6 is a block diagram depicting an illustrative configuration of one embodiment of a DNS-to-POP routing mapping system that may implement the DNS-to-POP routing mapping service of FIG. 1.

DETAILED DESCRIPTION

[0011] Generally described, aspects of the present disclosure relate to managing a load at individual points of presence ("POPs") of a content delivery system, and more particularly, to managing load at individual network communication links of a POP. Broadly described, individual POPs within a content delivery system can service client requests for content duplicated across the POPs. The specific POP used to provide content may be selected based on capacity-independent criteria, such as geographic location or network connectivity speed. However, each POP may also have limited capacity to service user requests. Therefore, the content delivery system may utilize load-balancing techniques to ensure that individual POPs are not overloaded with requests. While POPs generally include a number of different interconnected computing devices (e.g., within a physical data center), load-balancing techniques often consider POPs as an atomic unit. For example, load-balancing techniques may generally take into consideration the total compute capacity of a POP (e.g., a total amount of processing power, memory, etc. available at the POP) or a total network bandwidth available at the POP. Under some conditions, this approach can be effective. For example, a POP may include internal load-balancing that enables near total use of a POP's total compute capacity; thus, load-balancing between POPs based on total compute capacity can be relatively effective. However, it may not be possible at a POP to internally load balance all aspects of network communications. For example, a POP may have a limited number of physical connections, or links, to other networks, and (from the perspective of the POP) have little control over the connection used by incoming requests. Thus, excessive requests flowing to a POP over an individual links can overwhelm resources of the POP, even where aggregate bandwidth usage of the POP is relatively low.

[0012] Specifically, the present disclosure provides for the generation of DNS resolver-to-POP mappings based (at least partly) on an effect of such mappings on link utilizations at individual POPs. The mappings may specify how DNS requests from an individual DNS resolver should be handled by a DNS server of a content delivery system, and particularly, which POP of the content delivery system should be identified by the DNS server in a response to a DNS request. For example, the mappings may specify that DNS requests from resolver A should result in a return of an IP address for POP 1, while DNS requests from resolver B should result in a return of an IP address for POP 2.

[0013] By modifying resolver-to-POP mappings, a content delivery system may alter the load at individual POPs of the content delivery system. As a simplistic example, if all resolvers were mapped to an individual POP, the DNS servers of the content delivery system would respond to all DNS requests with the network address of the individual POP. That individual POP would then experience the total load of all requests to the content delivery system, and likely be overloaded. Meanwhile, other POPs would experience effectively zero load. However, by changing how the DNS servers respond to requests from some DNS resolvers, load associated with those resolvers can be rerouted to other POPs. For example, in a (simplistic) communication network with two resolvers, providing a first resolver with an address of a first POP and a second resolver with an address of a second POP can split load on the content delivery system between the POPs.

[0014] Determining effective resolver-to-POP mappings can be difficult in practice due to a number of complicating factors. One such factor is that DNS resolvers themselves represent little or none of the load actually experienced at a POP. Instead, the DNS resolvers act as proxies for client computing devices, enabling client computing devices to resolve domain names into network addresses. Those client computing devices, in turn, make requests of a POP and cause corresponding load. However, there is generally not a one-to-one correspondence between client computing device requests to a DNS resolver and requests from a DNS resolver to a DNS server within a content delivery system. Instead, DNS resolvers often utilize caching to respond to multiple client computing devices based on a single interaction with a DNS server. Moreover, DNS resolvers can utilize a hierarchical system, such that a DNS server is not aware of the identity of a client computing device ultimately being served by a resolution request. Thus, while a POP may be aware of the load at the POP caused by individual client computing devices, it can be difficult to attribute that load to operation of an individual DNS resolver.

[0015] An additional factor in determining resolver-to-POP mappings is the potential effect of those mappings on individual communication links within a communications network, such as the Internet. Generally, assigning a resolver to a POP via a resolver-to-POP mapping will direct traffic associated with the resolver (e.g., from client computing devices served by the resolver) to the POP. However, that POP may have many communication links to a communications network, and traffic associated with the resolver may reach the POP over any of those communication links. The specific link used can be controlled, for example, by routing protocols implemented by the communications network. One example of such a protocol is the Border Gateway Protocol (BGP), which enables routing devices on a communications network to exchange information as to the reachability of addresses on the network. While a POP's use of BGP or other protocols may provide the POP some control as to which link traffic with a client device uses, such links are generally selected to minimize communication metrics, such as latency, hop count, bandwidth, packet loss, or path reliability. Using BGP or another protocol to alter communications paths can have substantial detrimental effects, including temporary increases in resource usage to propagate path changes and enduring increases in communication metrics due to properties of the changed path. It is therefore often disadvantageous to alter routing protocols. For this reason, the link over which POP-to-client traffic flows is often substantially fixed.

[0016] Accordingly, a given resolver-to-POP mapping can cause a given amount of traffic not simply at a POP, but at individual communication links of the POP. Each communication link may have a capacity that is independent of other capacity constraints at the POP (e.g., memory and processing power). If a given resolver-to-POP mapping overwhelms the capacity of an individual link, capacity-related errors may occur at the POP, even the overall resource use of the POP is well below total capacity (e.g., when other links of the POP have sufficient bandwidth to service requests). Thus, overloading of an individual communication link at a POP can represent an artificial constraint on the POP's capacity.

[0017] To address this issue, the present disclosure provides for link-aware creation of resolver-to-POP mappings. Specifically, the present disclosure enables a content delivery system to determine an amount of traffic attributable to an individual resolver, to determine which communication link at any given POP would be used to service that traffic, and to assign the resolver to a POP such that the relevant communication link is not overloaded beyond its capacity. This assignment, in the form of a resolver-to-POP mapping, may then be used by DNS servers of the content delivery system to respond to DNS requests from the resolver, thus directing traffic associated with the resolver to the desired POP. In this manner, the overall efficiency of POPs to serve requests can be improved relative to prior implementations.

[0018] While aspects of the present disclosure are discussed with respect to link capacities, other capacities may additionally or alternatively be taken into account when generating resolver-to-POP mappings. For example, embodiments of the present disclosure may determine specific attributes of traffic information attributable to a given resolver, such as an amount of the traffic (e.g., as a percentage of overall traffic or as an absolute amount) that represents communication of a specific type of data. Embodiments of the present disclosure may then generate resolver-to-POP mappings based on a capacity of each POP to serve that specific type of data. As an illustration, each POP may be assigned by an administrator a maximum amount of bits per second of video content to be served by the POP. When determining resolver- to-POP mappings, a service may determine an amount of video content transmitted to client computing devices of a given resolver, and assign the resolver to a POP only when such an assignment would not exceed the total capacity of the POP to serve video content. In some instances, the type of content may be correlated to specific hardware computing resources of a POP, such as processing power. For example, service n bits of video content may be assumed to consume m cycles of processing power. Thus, when determining resolver-to-POP mappings, a service may determine an amount of video content transmitted to client computing devices of a given resolver, determine the number of cycles of processing power expected to be used to serve that video content, and assign the resolver to a POP only when such an assignment would not exceed the total capacity of the POP in terms of processing power. Additional specific capacities may be assigned in similar manners. For example, an administrator of a POP may establish a maximum number of files transmitted by a POP for any number of file types or formats, or may establish a maximum load of various hardware resources (e.g., processing cycles of a central processing unit (CPU) or graphical processing unit (GPU), memory (random access, disk memory, etc.), network bandwidth, etc.), each of which may be correlated based on predetermined mappings to various types of transmissions attributable to a resolver. Thus, any number of different capacities may be used to determine resolver-to-POP mappings in accordance with the present disclosure.

[0019] As will be appreciated by one of skill in the art in light of the description above, the embodiments disclosed herein substantially increase the ability of computing systems, such as content delivery systems, to service requests and provide content to client computing devices. Specifically, embodiments disclosed herein can use link-aware resolver-to-POP mappings to shape traffic to POPs, such that individual communication links at the POPs are not overloaded. This results in a reduction in communication errors experienced at the POP, and removal of artificial restrictions on the POPs' capacities. Thus, the presently disclosed embodiments represent an improvement in the functioning of such computing systems, by enabling more efficient communications to and from content delivery systems or other networked devices. Moreover, the presently disclosed embodiments address technical problems inherent within computing systems; specifically, the limited ability of computing systems to process network-based requests, the limited bandwidth available over individual communication networks, and the inefficiency of rerouting traffic over alternative communication links (e.g., the a detrimental effect on communication metrics resulting from such rerouting). These technical problems are addressed by the various technical solutions described herein, including the generation of link-aware resolver-to-POP mappings in accordance with the embodiments described herein. Thus, the present application represents a substantial improvement on existing network systems and computing systems in general.

[0020] For the purposes of the present disclosure, DNS resolution (e.g., the resolution of a domain name into a network address) will be assumed to be domain-name independent. Thus, it will be assumed that requests for any domain name associated with a content delivery system can be responded to with a network address of any POP of the content delivery system. This assumption holds, for example, where all POPs of a content delivery system operate to provide access to any content associated with the content delivery system. Thus, any POP can function to service requests for any content of the content delivery system. However, it will be appreciated that embodiments described herein could be modified to further account for variation in DNS responses based on a domain name included in a resolution request. For example, variation in DNS responses based on a domain name could be accomplished by generating domain-name specific resolver-to-DNS mappings (e.g., by generating, for each domain name, resolver-to-DNS mappings in accordance with the embodiments below).

[0021] The foregoing aspects and many of the attendant advantages of the present disclosure will become more readily appreciated as the same become better understood by reference to the following, when taken in conjunction with the accompanying drawings.

[0022] FIG. 1 is a block diagram depicting an illustrative logical network 100 including multiple client computing devices 102 and multiple DNS resolvers 104 in communication with a content delivery system 110 via a network 106. While the client computing devices 102 and the DNS resolvers 104 are shown as a group within FIG. 1, the client computing devices 102 and DNS resolvers 104 may be geographically distant, and independently owned or operated. For example, the client computing devices 102 could represent a multitude of users in various global, continental, or regional locations accessing the content delivery system 110. Further, the DNS resolvers 104 could represent a multitude of DNS devices operating globally, continentally or regionally. Accordingly, the groupings of client computing devices 102 and DNS resolvers 104 within FIG. 1 is intended to represent a logical, rather than physical, grouping. Similarly, each of the components of the content delivery system 110 may be located within geographically diverse areas. For example, the DNS servers 112 and POPS 114 within the content delivery system may be globally, continentally, or regionally disparate, in order to provide a wide geographical presence for the content delivery system 110.

[0023] Network 106 may be any wired network, wireless network or combination thereof. In addition, the network 106 may be a personal area network, local area network, wide area network, cable network, satellite network, cellular telephone network, or combination thereof. In the example environment of FIG. 1, network 106 is a global area network (GAN), such as the Internet. Protocols and components for communicating via the other aforementioned types of communication networks are well known to those skilled in the art of computer communications and thus, need not be described in more detail herein. While each of the client computing devices 102, DNS resolvers 104, and content delivery system 110 are depicted as having a single connection to the network 106, individual components of the client computing devices 102, DNS resolvers 104, and content delivery system 110 may be connected to the network 106 at disparate points. These disparate points are generally referred to herein as "communication links" or simply "links." Illustratively, a communication link may include a single wire connection between a computing device and networking device, such as a single gigabit-speed Ethernet connection. In some instances, a communication link may include multiple connections in serial, parallel, or both. For example, a client computing device's communication link to the network 106 may include a connection between the client computing device and a routing device or modem on a local area network (LAN), such as a home network, as well as a connection between the routing device or modem and an internet service provider (ISP) that forms part of the network 106. The content delivery system may have multiple links to the communication network 106, each of which is formed by one or more physical network connections in serial, parallel, or both. Thus, for the purposes of the present disclosure, a communication link can be generally described as one or more physical connections that enable (or are configured via routing protocols to enable) communication between a first network (or individual device) and a given location on a second network, such as an individual "Internet exchange point" or interface with an ISP or other content delivery system. [0024] Client computing devices 102 may include any number of different computing devices capable of communicating with the content delivery system 102. For example, individual client computing devices may correspond to a laptop or tablet computer, personal computer, wearable computer, server, personal digital assistant (PDA), hybrid PDA/mobile phone, mobile phone, electronic book reader, set-top box, camera, digital media player, and the like. Each client computing device 102 may utilize one or more DNS resolvers 104 to resolve hostnames for devices connected to the network 106 into network addresses, such as IP addresses. Accordingly, each DNS resolver 104 may correspond to a DNS server that serves DNS information to one or more client computing devices 102. For example, each DNS resolver 104 may correspond to a DNS server provided by an ISP of one or more users, a private DNS server, or a public DNS server. The detailed operation of DNS servers is well known within the art, and therefore will not be described in detail herein.

[0025] In order to resolve hostnames corresponding to the content delivery system, each DNS resolver 104 may communicate with a DNS server 112 within the content delivery system 110. DNS servers 112 can be operated on behalf of the content delivery system 110, and configured or otherwise operable to resolve hostnames of the content delivery system 110 into a network address of a corresponding POP 114. Illustratively, each DNS server can 112 be configured, on request from a DNS resolver 104 to resolve a specific hostname, to determine a POP 114 that should serve the DNS resolver 104 (or client computing devices 102 associated with the DNS resolver 104) and to return an IP address of the determined POP 114 to the DNS resolver 104. Thereafter, the DNS resolver 104 can return the IP address of the determined POP 114 to a requesting client computing device 102, which the client computing device 102 may use to contact the content delivery system 110 to retrieve content. In order to determine which POP 114 address into which to resolve a hostname request, each DNS server 112 may utilize a resolver-to-POP mapping generated in accordance with the present disclosure. Specifically, the DNS server 112 may respond to a request from a given resolver 104 by returning a network address of a POP assigned to that resolver within the resolver-to-POP mapping. As discussed above, in some embodiments, such responses may be independent of the particular hostname for which resolution is requested (e.g., when all POPs 114 are configured to provide content from all hostnames associated with the content delivery system 110). [0026] On receiving an address of a POP 114, a client computing device 102 may communicate with the POP 114 to retrieve content from the content delivery service 110. Accordingly, each POP 114 may include one or more data stores configured to store content available from the content delivery system 110. Moreover, each POP 114 may include one or more computing devices configured to receive requests from client computing devices 102 and return requested content. The particular communication path used for communications between a client computing device 102 and a POP 114 may depend on routing protocols used by the POP 114 and the network 106. As noted above, excessive communications to or from a POP 114 over a given path (e.g., over a given communication link at the POP 114) can result in communication errors, even when the POP 114 otherwise has capacity to service the communications. Thus, it is desirable to shape traffic in such a manner that individual communication links of a POP 114 are not overloaded with traffic to client computing devices 102.

[0027] To facilitate such traffic shaping, the content delivery system 110 of FIG. 1 further includes a resolver-to-POP route mapping service 116. In accordance with aspects of the present disclosure, the resolver-to-POP route mapping service 116 may interact with the DNS servers 112 and POPs 114 in order to determine characteristics of traffic associated with individual DNS resolvers 104 (or collections of DNS resolvers 104), and to assign such DNS resolvers 104 to POPs 114 in a manner that is expected not to overload individual communication links of the POPs 114. Further, the resolver-to-POP route mapping service 116 can generate resolver-to-POP mappings that identify these assignments, and return the mappings to the DNS servers 112. Thereafter, the DNS servers 114 can respond to DNS requests from DNS resolvers 104 in accordance with the mappings, thus directing traffic between client computing devices 102 and the POPs 114 in a manner expected not to overload communication links of the POPs 114. Further detail regarding generation of resolver-to-POP mappings is provided below.

[0028] It will be appreciated by those skilled in the art that the content delivery system 110 may have fewer or greater components than are illustrated in FIG. 1. In addition, the content delivery system 110 could include various web services and/or peer-to-peer network configurations. Thus, the depiction of the content delivery system 110 should be taken as illustrative and not limiting to the present disclosure. For example, in some embodiments, components of the content delivery system 110, such as the resolver-to-POP route mapping service 116, may be executed by one more virtual machines implemented in a hosted computing environment. A hosted computing environment may include one or more rapidly provisioned and released computing resources, which computing resources may include computing, networking and/or storage devices. A hosted computing environment may also be referred to as a cloud computing environment.

[0029] Any one or more of the DNS servers 112, the POPs 114 and the resolver-to- POP route mapping service 116 may be embodied in a plurality of components, each executing an instance of the respective DNS servers 112, POPs 114 and resolver-to-POP route mapping service 116. A server or other computing component implementing any one of the DNS servers 112, POPs 114 and resolver-to-POP route mapping service 116 may include a network interface, memory, processing unit, and computer readable medium drive, all of which may communicate which each other may way of a communication bus. The network interface may provide connectivity over the network 106 and/or other networks or computer systems. The processing unit may communicate to and from memory containing program instructions that the processing unit executes in order to operate the respective DNS servers 112, POPs 114 and resolver-to-POP route mapping service 116. The memory may generally include RAM, ROM, other persistent and auxiliary memory, and/or any non-transitory computer-readable media.

[0030] With reference to FIG. 2 A, an example of possible logical associations between client computing devices 102, DNS resolvers 104, and POPs 114 will be described. In FIG. 2, client computing devices 102 are represented as subnets 202, each representing one or more client computing devices 102. Each subnet 202 may correspond to a subnetwork including network addresses for one or more client computing devices 102. For example, where devices 102 utilize IP version 4 (IPv4) addresses, a subnet may represent all possible network addresses utilizing a common prefix (e.g., the prefix "10.0.1" within the network addresses "10.0.1.1" through "10.0.1.254"). These prefix are commonly referred to using Classless Inter- Domain Routing, or "CIDR," notation, which specifies the length of a prefix using "slash notation." Illustratively, a '724" network may represent a block of 256 possible addresses under the IPv4 addressing scheme. The six of each subnet 202 may be vary in different embodiments, as larger subnets 202 may reduce the data processing required to generate resolver-to-POP mappings, while smaller subnets 202 may increase the granularity with which traffic can be shaped. In the illustrative examples provided herein, the subnets 202 are assumed to represent a /24 block of IPv4 addresses.

[0031] As shown in FIG. 2A, each subnet 202 is associated with a DNS resolver 104A. This association indicates that a client computing device 102 within a given subnet 202 is expected to communicate (as necessary) with a given DNS resolver 104 in order to resolve hostnames associated with the content delivery system 110. For example, client computing devices 102 corresponding to subnets 202 A and 202B are expected to communicate with DNS resolver 104A when resolving hostnames of the content delivery system 110. Client computing devices 102 corresponding to subnet 202C are expected to communicate with DNS resolver 104B, computing devices 102 corresponding to subnet 202N are expected to communicate with DNS resolver 104N, etc. Similarly, FIG. 2 A further depicts associations between DNS resolvers 104A and POPs 114 of the content delivery system. These associations indicate for example that, when a DNS request is received from a DNS resolver 104A to resolve a host name of the content delivery system 110, a DNS server 112 (not shown in FIG. 2 A) of the content delivery system 110 will return a network address of POP 114 A. Similarly, when a DNS request is received from a DNS resolver 104N to resolve a host name of the content delivery system 110, the DNS server 112 will return a network address of POP 114N. From the associations of FIG. 2A, it can then be seen that traffic associated with subnets 202A, 202B, and 202C is expected to occur at POP 114A, while traffic associated with subnet 202N is expected to occur at POP 114N. (While a limited number of subnets 202, DNS servers 104, and POPs 114 are shown in FIG. 2A for illustrative purposes, various embodiments may include any number of subnets 202, DNS servers 104, and POPs 114.)

[0032] One of skill in the art will appreciate that the associations of FIG. 2A are logical in nature, and are unlikely to represent actual network communications between subnets 202, DNS resolvers 104, and POPs 114. For example, devices 102 subnets 202A may not directly communicate with resolvers 104, but may instead utilize one or more intermediary DNS resolvers (according to the hierarchical nature of DNS infrastructure). Moreover, devices 102 may not generally use DNS resolvers 104 as an intermediary to communicate with a POP 114. Rather, devices 102 may utilize resolvers 104 to resolve a hostname or domain name to an address of a POP 114, and thereafter direct communications to that address of the POP 114. Further, DNS resolvers 104 A may not generally communicate with a POP 114 A, but may instead communicate with DNS servers 112 (not shown in FIG. 2A) to resolve hostnames associated with a content delivery system 110. Thus, the associations of FIG. 2A are not necessarily intended to depict actual network communications. Rather, these associations are intended to depict how traffic at a POP 114 can be conceptualized as a result of association between subnets 202, DNS resolvers 104, and POPs 114.

[0033] In some instances, the associations of FIG. 2A may not be readily apparent to a content delivery system 110. For example, POPs 114 may not generally be notified of communications between DNS resolvers 104 A and client computing devices 102 within subnets 202. Moreover, communications that are received from a DNS resolver 104 may not indicate the subnet 202 from which the communications originated. Thus, in some embodiments, the content delivery system 112 may be configured to determine associations between subnets 202 and DNS resolvers 104.

[0034] One set of mechanisms for determining associations between subnets 202 and DNS resolvers 104 is described within U.S. Patent Application No. 14/565,042, entitled "Capacity Independent Demand Assessment" and filed December 9, 2014 (the "'042 Application"), which is hereby incorporated by reference in its entirety. As described at FIG. 2 of the '042 Application, one mechanism for determining associations between subnets 202 and DNS resolvers 104 is that POPs 114 of a content delivery system 110 may transmit "web beacons" to specific client computing devices 102, which web beacons cause the client computing devices 102 to resolve a specific hostname associated with the content delivery system 110. DNS servers 112 of the content delivery system 110 may then monitor for requests to resolve the specific hostname, and associate the client computing devices 102 (or a subnet 202 including the client computing devices 102) with the DNS resolver 104 from which the request was received. Such web beacons may be included, for example, within an HTML page previously transmitted to the client computing devices 102. A client computing device 102 can attempt to resolve a hostname associated with the web beacon, as derived from the URL of the web beacon within the HTML page. Such a hostname may be unique or semi-unique to the web beacon, and therefore allow the content delivery system 110 to track interactions of the client computing device 102 related to the web beacon. Illustratively, the web beacon may be associated with the URL "beaconl .cdn.tld/myBeacon.gif." The hostname of the URL (e.g., "beaconl .cdn.tld") can be selected such that DNS requests for the web beacon are likely to be associated with a specific client computing device 102, rather than other client computing devices 102. Thus, when a request to resolve a URL of a particular web beacon is received at a DNS server 112, the DNS resolver 104 from which the request was received can be associated with the client computing device 102 to which the web beacon was sent.

[0035] Another set of mechanisms determining associations between subnets 202 and DNS resolvers 104 is described within U.S. Patent Application No. 15/389,276, entitled "Network Addresses with Encoded DNS-Level Information" and filed December 22, 2016 (the "'276 Application"), which is hereby incorporated by reference in its entirety. As noted in the '276 Application (e.g., at ]j 0019 _another mechanism for determining associations between subnets 202 and DNS resolvers 104 is that DNS servers 112 of a content delivery system 110 may in some instances encode request information, such as an identifier of a DNS resolver 104, into network addresses provided in response to a DNS request. Thus, subsequent communications to those network addresses can be determined to have occurred as a result of those DNS requests, and an association can be created between client computing devices 102 transmitting the subsequent communications and the DNS resolver 104 that transmitted the DNS request. For example, some formats of IP address (such as the IP version 6, or "IPv6") may provide more bits than are necessary to route a request to a particular device. For example, in the 128 bit IPv6 format, a first 48 bits may be used to route a request to the content delivery system 110, while a final 80 bits may be used to encode other information. Thus, a DNS server 112 can utilize non-routing bits of an IP address (e.g., a last 80 bits) to encode DNS-level information, known to a DNS server 112 at the time that resolution of a domain name into an IP address is requested. In one embodiment, this DNS-level information includes an identifier of a DNS resolver 104 from which a request to resolve the domain name is received. The identifier may include, for example, a lower-bit network address, such as an IPv4 network address of the DNS resolver 104, which can be encoded in its entirety into a high-bit network address, such as an IPv6 address. The IP address encoded with DNS-level information can then be returned to a DNS resolver 104, which in turn provides the address to a client computing device 102. The client computing device 102 may then utilize the encoded IP address to request access to the content delivery system 110, which request may be routed based on routing bits of the encoded IP address. On receiving a request to the encoded IP address, the content delivery system 110 may associate a client computing device 102 which transmitted the request to a DNS resolver 104 whose identifying information is encoded within the IP address to which the request was transmitted. Embodiments of the present disclosure may utilize additional or alternative mechanisms for associating subnets 202 (or devices 102 themselves) with DNS resolvers 104.

[0036] In the illustrative depiction of FIG. 2A, for simplicity, each subnet 202 is shown as associated with a single DNS resolver 104 A. However, in some embodiments of the present disclosure, a subnet 202 may be associated with multiple DNS resolvers 104. For example, as described in the '042 Application, a given subnet 202 may be associated with two or more different resolvers 104, such that a given percentage of DNS requests from the subnet 202 are predicted to be directed to a first DNS resolver 104, a given percentage are predicted to be directed to a second DNS resolver 104, etc. In these embodiments, the traffic from each subnet 202 may be partitioned according to the percentages assigned to each resolver 104. So, if 20% of DNS requests from subnet 202 A are predicted to be routed to DNS resolver 104 A, 20% of traffic from devices within subnet 202A would be predicted to occur based on communication with the DNS resolver 104 A (and thus could be shaped according to interactions with DNS resolver 104 A).

[0037] Moreover, for simplicity, each DNS resolver 104A is associated with a single POP 114. However, in some embodiments of the present disclosure, a resolver 104 may be associated with multiple POPs 114. For example, resolver-to-POP mappings may indicate a certain percentage of DNS requests from a given resolver 104 should be responded to with an address of POP 114A, another percentage should be responded to with an address of POP 114B, etc. In this manner, traffic associated with a single DNS resolver 104 may be directed to multiple POP 114.

[0038] While description is generally made herein with respect to individual DNS resolvers 104, embodiments of the present disclosure may in some instances group multiple DNS resolvers 104. For example, DNS resolvers 104 within a given subnet (e.g., sharing a /24 or other prefix) may be considered as a "single" DNS resolver 104 (or a resolver "group") for purposes of creating a resolver-to-POP mapping.

[0039] With reference to FIG. 2B, an illustrative block diagram is shown depicting associations between the subnets 202A-N and volume of communications to individual links associated with POPs 114A and 114N. As discussed above with respect to FIG. 2A, it is assumed in the present example that communications related to subnets 202A-C occur at POP 114A, and that communications related to subnet 202 occur at POP 114N. These communications may include, for example, requests from devices 102 of the respective subnets 202 to obtain content from the POPs 114, as well as transmission of such content from the POPs 114 to devices 102 within the subnets 202. Communication from each subnet 202A may be associated with a given volume of traffic, which may be measured according to various metrics. For example, volumes may be measured as "requests per second," or the number of requests from devices 102 within a subnet 202 for content from the POPs 114. In another instance, volumes may be measured as bits per second, or the actual bandwidth used to support communications (e.g., in gigabits per second). Volumes may be measured, for example, by routing devices or content delivery devices within a POP 114.

[0040] As also shown in FIG. 2B, communications with a POP 114 may be transmitted to the POP 114 through a number of communication links. Devices 102 of subnets 202A and 202B, for example, are shown to communicate with POP 114A through link A. l, while devices of subnet 202C is shown to communicate with POP 114A through link A.2, etc. As noted above, each link may represent one or more physical connections (e.g., an individual connection, or multiple connections in serial or parallel) to a network external to the POP 114. Thus, each link is associated with capacity constraints based on those connections. For example, a given link may be able to support communications of a limited bandwidth (e.g., 10 gigabits per second) before becoming congested. As discussed above, the specific link to which communications are routed is generally controlled by routing protocols between the POP 114 and an external network, and is often selected to minimize some aspect of communications, such as latency, hop count, bandwidth, packet loss, or path reliability. It can be disadvantageous, difficult, or impossible to manipulate the individual links through which communications reach a POP 114. If the volume of communications over an individual link exceed the capacity of that link, errors (such as request timeouts) are likely to be observed at client computing devices 102. Thus, for example, if the volume of communications from subnets 202A and B exceed the capacity of link A. l, client computing devices 102 of subnets 202A and B are likely to experience errors, even when the POP 114 otherwise has capacity to service those communications.

[0041] With reference to FIG. 3, illustrative interactions are depicted enabling a content delivery system 110 to determine resolver-to-POP mappings based at least partly on a predicted effect of such mappings on loads at individual links of POPs 114, such that those individual links are expected not to be overloaded. The interactions begin at (1), where DNS servers 112 of the content delivery system 110 determine resolver-to-subnet correlation information. This information may represent information gathered at or generated by the DNS servers 112 and usable by the resolver-to-POP route mapping service 116 to determine associations between re sol vers 104 and subnets 202. For example, in accordance with embodiments of the '042 Application, the resolver-to-subnet correlation information may include identifying information for DNS resolvers 104 that requested resolution of hostnames included in a web beacon. This information may then, at (2), be transmitted to the route mapping service 116 for use in determining associations between resolvers 104 and subnets 202.

[0042] In some instances, the mapping service 116 may determine associations between resolvers 104 and subnets 202 without requiring any information from the DNS servers 112, and thus interactions (1) and (2) may be omitted. For example, in accordance with embodiments of the '276 Application, associations between resolvers 104 and subnets 202 may be determined based on information encoded within addresses of POPs 114, and thus no information need be transmitted from the DNS servers 112 to the route mapping service 116.

[0043] At (3), the POPs 114 similarly determine resolver-to-subnet correlation information. As stated above, this information may represent information usable by the route mapping service 116 to determine associations between resolvers 104 and subnets 202 (though in the instance of interaction (3), the information would be generated at or gathered by POPs 114). For example, in accordance with embodiments of the '042 Application, the resolver-to-subnet correlation information gathered at POPs 114 may include identifying information for client computing devices 102 to which instructions to request a web beacon were transmitted. As another example, in accordance with embodiments of the '276 Application, this information may include identifying information of client computing devices 102 that requested content from encoded network addresses, as well as identifying information of resolvers 104 that has been encoded into those network addresses.

[0044] In addition, at (4), the POPs 114 determine associations between individual subnets 202 and individual communication links at the POPs 114. Illustratively, this information may be determined based on routing information available at the POPs 114, such as BGP route announcements. For example, a POP 114 may determine that a particular subnet 202 (e.g., an individual '724" subnetwork) is reachable through a first communication link, and thus associate the subnet 202 with the first communication link. In one embodiment, the POP 114 may determine subnet-to-link associations for all potential subnets (e.g., every /24 network under the IPv4 addressing format that may be potentially served by the content delivery system 110). In another embodiment, the POP 114 may determine subnet-to-link associations for only some subnets, such as the top N subnets served by the content delivery system 110 in terms of communications volume, or subnets representing a threshold percentage of traffic on the content delivery system 110.

[0045] Still further, at (5), the POPs 114 determine volumes of communications associated with each subnet 202, such as the requests per second received from each subnet 202 or the bits per second required to communicate with each subnet 202. These volumes may be determined by observing present or historical communications with each subnet 202. For example, volumes over a relatively short period of time (e.g., a few minutes) may be averaged to represent a current volume for a given subnet 202. In some instances, volumes may represent future projections for communications with a subnet 202. For example, if a current volume of communications with a subnet 202 represents n gigabits per second, and that volume has been increasing at a rate of 5% every ten minutes, the POP 114 may project that, over a subsequent ten minutes, the volume of communications to the subnet would be 1.1 *n gigabytes per second. Various other mechanisms for projecting future demand are known in the art and thus will not be described herein. Generally, the period of the future projection may be set by the content delivery system 110 to encompass a time during which a resolver-to-POP mappings will be used at the content delivery system 110. Thus, if new resolver-to-POP mappings are generated every hour, demand may be forecasted to cover a future hour of time, etc.

[0046] In addition to volume of communication, the POPs 114 also determine latency of communications with the subnets 202. Latencies can be determined, for example, by monitoring current or past communications with devices 102 of the subnets 202. Alternatively, latencies can be determined by instigating communications with the subnet 202 and observing a latency of those communications. For example, a POP 114 may transmit a "ping" request to a device on the subnet 202 to determine a latency of communications with the subnet 202. While the communication metric of latency is provided as an example in the illustrative interactions of FIG. 3, the content delivery system 110 may additionally or alternatively determine other communication metrics, such as hop count, bandwidth, packet loss, or path reliability.

[0047] Thereafter, at (6), the information gathered at the POPs 114 is transmitted to the resolver-to-POP route mapping service 116. At (7), the service 116 uses the information received from the POPs 114 (and potentially information received from the DNS servers 112) to determine resolver-to-subnet mappings. As noted above, such mappings can represent associations or correlations between client computing devices 102 of a subnet 202 and a DNS resolver 104 used by a subnet to resolve hostnames. Illustrative embodiments for determining associations between client computing devices 102 and a DNS resolver 104 are described in more detail in the '276 and '042 Applications, incorporated by reference above, and are thus not repeated herein.

[0048] At (8), the resolver-to-POP route mapping service 116 determines traffic volumes attributable to various resolvers 104. Illustratively, the traffic volumes attributable to a resolver 104 can represent traffic expected to be received from client computing devices 102 associated with that resolver 104. For a given resolver 104, the traffic volume of the resolver 104 may be determined by aggregating traffic volumes of all subnets 202 associated with the resolver 104. In the instance that only a given percentage of traffic of a subnet 202 is associated with the resolver 104, only that percentage of traffic could be included in the aggregate traffic volume of the resolver. Thus, in order to determine resolver traffic volumes, the route mapping service 116 may combine information associating subnets to resolvers with information associating subnets with traffic volumes in order to result in information assigning traffic volumes to resolvers.

[0049] As an illustrative example, returning to the depictions of FIG. 2A and 2B, assume that POP 114A observed a volume of 2 gigabytes per second from subnet 202A and a volume of 3 gigabytes per second from subnet 202B. Both subnet 202 A and 202B are associated with resolver 104 A. Thus, 5 gigabytes of traffic volume can be attributed to resolver 104 A. In the instance that only 50% of traffic from subnet 202A is associated with resolver 104A, a total traffic volume of 4 gigabits per second can be attributed to resolver 104 A (3 gigabits per second from subnet 202B and one half of 2 gigabits per second from subnet 202A). A similar calculation can be completed for each remaining resolver 104 (e.g., B-N). In some embodiments, traffic volumes for a resolver may be aggregated based on types of data transmitted. For example, where the POPs 1 14 provide a record of volumes of different data types provided to client computing devices 102 associated with a resolver 104, the resolver-to- POP route mapping service 116 may determine data type-specific volumes for the resolver 104 by aggregating traffic volumes of a data type served to the client computing devices 102. Data type-specific volumes may be used, for example, in generating resolver-to-POP mappings based on data type-specific capacities.

[0050] At (9), the resolver-to-POP route mapping service 116 further determines latencies to be assigned to various POP 114 and resolver 104 pairs. As will be discussed below, these latencies can be used to rank or sort POPs 114 to be potentially assigned to a resolver 104. For example, a POP 114 with a lowest latency of communications with a resolver 104 may be ranked highest for potential assignment, a POP 114 with a second lowest latency may be ranked second highest, etc. For an individual resolver 104, latencies to each POP 114 may be determined based on latencies between each POP 114 and the subnets 202 associated with the resolver 104. For example, if a given POP 114 has an average latency of 30 milliseconds (ms) to the subnets 202 associated with a resolver 104, the resolver and POP pair may be assigned a 30 ms latency. As noted above, while latency is provided as an example communication metric, the content delivery system 110 may utilize other monitored communication metrics, such as hop count, bandwidth, packet loss, or path reliability in a similar manner.

[0051] Returning to the depictions of FIG. 2 A and 2B for the purposes of example, assume that POP 114A observed an average latency of 10 ms when communicating with subnet 202 A, and an average latency of 20 ms when communicating with subnet 202B. Because both subnets 202 A and B are associated with resolver 104 A, the route mapping service 116 may average the latencies of these subnets 202 to determine a latency to be attributed to the pair of resolver 104 A and POP 114A. Thus, the latency attributed to this pairing would (in this illustrative example) be 15 ms. In some embodiments, other calculations of latency may be utilized. For example, a route mapping service 116 may utilize an actual observed latency for communications between a POP 114 and a resolver 104, may utilize a highest latency of any subnet 202 associated with the resolver 104, etc. In yet other embodiments, other communication metrics may be used, such as hop count, bandwidth, packet loss, or path reliability. [0052] Thereafter, at (10), the route mapping service 1 16 may determine resolver-to- POP mappings based on resolver traffic volumes, resolver latencies, and an effect of a mappings on capacities of the POPs 114, both with respect to an overall capacity of the POP 114 and an expected effect of a mapping on individual communication links of the POPs 114. The resolver- to-POP mappings can then be returned to the DNS servers 112 at (11).

[0053] One illustrative routine 400 that may be utilized by the route mapping service 116 to determine resolver-to-POP mappings is depicted in FIG. 4. The routine 400 begins at block 402, where the route mapping service 116 obtains resolver-to-subnet mapping information (e.g., as determined at interaction (7) of FIG. 3). The routine 400 proceeds to block 404, where volume and latency information is received. This volume and latency information may include, for example, volume and latencies attributable to resolvers 104 (e.g., as determined at interactions (8) and (9) of FIG. 3), as well as volumes and latencies attributable to subnets 104 (e.g., as determined at interaction (5) of FIG. 3).

[0054] Thereafter, the routine 400 proceeds to block 406, where the route mapping service 116 selects a resolver 104 to which to assign a POP 114. As discussed above, assignment of a POP 114 to a resolver 104 can result in DNS requests from the resolver 104 being responded to with a network address of the POP 114. Thus, assignment of a POP 114 to a resolver 104 can result in the direction of traffic associated with the resolver 104 (e.g., traffic of client computing devices 102 serviced by the resolver 104) to the POP 114.

[0055] In one embodiment, the route mapping service 116 selects a resolver 104 by ranking potential resolvers 104, and selecting a highest ranked resolver. Illustratively, the route mapping service 116 may consider resolvers 104 in order of total traffic volume, such that a resolver 104 associated with the highest volume of traffic to the content delivery system 110 is considered first. In other embodiments, the route mapping service 116 may consider resolvers 104 in other orders (e.g., reverse volume load, random, in numerical order of network addresses, etc.).

[0056] The routine 400 then proceeds to block 408, where a POP 114 of the content distribution system 110 is assigned to the resolver 104. In one embodiment, block 408 is a subroutine corresponding to the routine 500 of FIG. 5. In brief, this subroutine may assign to the resolver 104 a POP 114 with the lowest latency to the resolver 104 (or other positive communication metric), but with sufficient capacity to service traffic associated with the resolver 104 both in terms of overall capacity, and capacity of individual links of the POP 114. Further details regarding a potential routine for the assignment of a POP 114 to a resolver 104 are provided below with respect to FIG. 5.

[0057] Thereafter, the routine 400 proceeds to block 410, where the route mapping service 116 determines whether any additional resolvers 104 that have not yet been assigned a POP 114. If so, the routine 400 returns to block 406, where a new resolver 104 is selected, and where, at block 408, a POP 114 is assigned to the selected resolver 104. The routine 400 proceeds in this manner until, at block 410, no resolvers 104 remain that require the assignment of a POP 114.

[0058] At block 412, the routine 400 builds a resolver-to-POP mapping based on the previously determined assignments. Illustratively, the resolver-to-POP mapping may specify, for each resolver 104, one or more POPs 114 to be identified in DNS responses to the resolver 104. At block 414, the resolver-to-POP mappings are transmitted to DNS servers 112 of the content delivery system 112, and the routine 400 ends at block 416.

[0059] Thereafter, the DNS servers 112 may respond to DNS requests from the resolvers 104 based on the resolver-to-POP mapping (e.g., by returning a network address of a POP 114 assigned to a resolver 104 from which a DNS request was received). Thus, traffic of client computing devices 102 associated with a resolver 104 would be expected to flow to a POP 114 assigned to that resolver. Because the resolver-to-POP mapping are selected such that this traffic is expected not to exceed the capacity of individual links of the POPs 114, the overall efficiency of the content delivery system 114 can be improved relative to prior systems.

[0060] With reference to FIG. 5, one illustrative routine 500 for assigning a POP 114 to a resolver 104 will be described. This routine 500 may be implemented, for example, by the route mapping system 116. Illustratively, the routine 500 may be implemented as a subroutine to the routine 400 of FIG. 4 (e.g., at block 408 of the routine 400).

[0061] The routine 500 begins at block 502, where the route mapping system 116 generates a ranking or sorting of potential POPs 114 according to the latency associated with the resolver 104 and POP 114 pair. For example, a POP 114 with the lowest latency to the resolver 104 may be ranked most highly, followed by a second lowest latency POP 114, etc. As noted above, while latency is provided as an example communication metric for the purposes of ranking, POPs 114 may additionally or alternatively be ranked based on other communication metrics, such as hop count, bandwidth, packet loss, or path reliability between the POPs 114 and the relevant resolver 104.

[0062] At block 504, the route mapping system 116 selects a first candidate POP 114 to potentially assign to the resolver 104. The first candidate POP 114 may be selected, for example, as the highest ranked POP 114 from the ranking of block 502.

[0063] At blocks 506-510, the route mapping service 116 determines whether assignment of the selected candidate POP 114 to the resolver 104 would be expected to exceed the capacity of the POP 114.

[0064] Specifically, at block 506, the route mapping service 116 may determine whether a total volume of communications associated with the resolver 104 would be expected to exceed an overall capacity of the POP 114 to service requests. For example, where the POP 114 is rated (e.g., by an administrator of the content delivery system 110) as being capable of servicing 100 gigabits per second of traffic, and prior assignment of the POP 114 to other resolvers 104 is expected to result in 40 gigabits per second of traffic, the route mapping service 116 may determine at block 504 whether a traffic volume of the present resolver 104 exceeds 60 gigabits per second (the remaining capacity of the POP 114 in view of prior assignments, if any).

[0065] In addition, at block 508, the route mapping service 116 determines whether assignment of a resolver 104 to a given POP 114 would exceed capacity of an individual links of the POP 114. Illustratively, the route mapping service 116 may determine what subnets 202 are associated with a resolver 104 being considered (as determined from resolver-to-subnet mappings) and the volume of traffic from those subnets 202 (as determined by observed subnet volumes at the POP). The route mapping service 116 may thereafter, for a given candidate POP 114, determine the one or more communication link of the POP 114 that would be used to service communications from those subnets 202 (as determined from routing information gathered at the POP 114).

[0066] For each communication link, the route mapping service 116 determines whether assignment of the POP 114 to the current resolver 104 would cause traffic expected to flow over the communication link to exceed the links capacity. As an illustrative example, assume that all traffic from subnets 202 associated with a resolver 104 would be expected to flow over a single communication link at a POP 114. Further assume that this communication link has a capacity of 9 gigabits per second (e.g., as determined by an administrator of the content delivery system 110 in view of the total bandwidth available on the communication link). Still further, assume that based on prior assignments to other resolvers 104, that communication link is expected to experience 3 gigabits per second of communications. In this scenario, the traffic of a current resolver 104 would not exceed the capacity of the communication link so long as that traffic was at or under 6 gigabits per second. Similar examples can be provided where a resolver 104 is associated with traffic expected to flow to a POP 104 over multiple communication links. In such an example, the route mapping service 116 would determine whether the traffic expected to flow over each link (e.g., from a particular subnet 202 associated with the resolver 104) exceeded the capacity of that link.

[0067] At block 510, the route mapping service 116 determines whether the candidate POP 114 has sufficient capacity to be assigned to the resolver 104. Illustratively, if the overall capacity of a POP 114 would not be exceeded by such assignment (e.g., as determined in block 506) and if no communication link of the POP 114 would have its capacity exceeded by such assignment (e.g., as determined in block 508), then block 510 evaluates as true, and the routine 500 proceeds to block 512. The candidate POP 114 is then assigned to the resolver 104, and the routine 500 ends at block 514.

[0068] If the capacity of any link of a POP 114 would be exceeded by assignment of the POP 114 to the resolver 104, or if the overall capacity of the POP 114 would be exceeded by such assignment, block 510 evaluates as false, and the routine 500 returns to block 504. The routine 500 then continues until a POP 114 is selected for assignment to the resolver. While not shown in FIG. 5, the routine 500 may exit with an error (e.g., a notification to an administrator) if no candidate POP 114 is found to have sufficient capacity to be assigned to a resolver 104.

[0069] While the illustrative routine 500 is described such that a single POP 114 is assigned to a resolver 104, the routine 500 in some embodiments may be modified such that multiple POPs 114 are assigned to a given resolver 104. For example, where a first POP 114 has sufficient capacity to service half (but not all) of the traffic volume associated with a resolver 104, both the first POP 114 and the second POP 114 may be assigned to the resolver 104 in an effort to split traffic from the resolver between the first and second POPs 114. In one embodiment, a resolver-to-POP mapping may specify a division of traffic between the first-and-second POPs 114 (e.g., 50/50, 25/75, etc.), and the route mapping service 116 may consider only a relevant portion of the traffic from a resolver 104 in the calculations discussed above. A DNS server 112, in responding to DNS requests from the resolver 104, may respond to the requests based on the division of traffic. For example, the DNS server 112 may respond to 50% of requests by providing an address of the first POP 114, and the other 50% of requests by providing an address of the second POP 114.

[0070] As noted above, while aspects of the present disclosure are discussed with respect to an overall POP capacity or link capacities, other capacities may additionally or alternatively be taken into account when generating resolver-to-POP mappings. Thus, the routine 500 may be modified to take into account these other capacities. For example, the routine 500 may be modified to obtain a record of the various types of data transmitted to client computing devices 102 and thus attributable to a resolver 104, and to predict an effect of those volumes of a given type of data on a corresponding capacity of each POP 114 to serve that type of data to ensure that the POP 114 has sufficient capacity to service the traffic attributable to the resolver. As noted above, the capacity of a POP 114 to serve a given type of data may be specified with respect to the data type itself (e.g., a specific capacity to serve video content, audio content, image content, data of a particular file type, etc.), or may be specified with respect to a hardware computing resource of the POP 114 (e.g., by mapping a volume of a specific data type to an expected usage of a hardware computing resource to that volume of the specific data type). Thus, the capacities discussed in FIG. 5 are intended to be illustrative in nature.

[0071] FIG. 6 depicts a general architecture of a resolver-to-POP route mapping system 600 that may implement functionalities of the resolver-to-POP route mapping service 116 described above. The general architecture of the resolver-to-POP route mapping system 600 depicted in FIG. 6 includes an arrangement of computer hardware and software elements that may be used to implement aspects of the present disclosure. The hardware elements may be implemented with physical electronic devices, as discussed in greater detail below. The resolver-to-POP route mapping system 600 may include many more (or fewer) elements than those shown in FIG. 6. It is not necessary, however, that all of these generally conventional elements be shown in order to provide an enabling disclosure. Additionally, the general architecture illustrated in FIG. 6 may be used to implement one or more of the other components illustrated in FIG. 1. [0072] As illustrated, the resolver-to-POP route mapping system 600 includes a processing unit 604, a network interface 606, a computer readable medium drive 607, and an input/output device interface 620, all of which may communicate with one another by way of a communication bus. The network interface 606 may provide connectivity to one or more networks or computing systems, such as the network 106. The processing unit 604 may thus receive information and instructions from other computing systems or services via the network. The processing unit 604may also communicate to and from memory 610 and further provide output information for an optional display (not shown) via the input/output device interface 620. The input/output device interface 620 may also accept input from an optional input device (not shown).

[0073] The memory 610 may contain computer program instructions (grouped as modules in some embodiments) that the processing unit 604 executes in order to implement one or more aspects of the present disclosure. The memory 610 generally includes random access memory (RAM), read only memory (ROM) and/or other persistent, auxiliary or non-transitory computer readable media. The memory 610 may store an operating system 614 that provides computer program instructions for use by the processing unit 604 in the general administration and operation of the resolver-to-POP route mapping system 600. The memory 610 may further include computer program instructions and other information for implementing aspects of the present disclosure. For example, in one embodiment, the memory 610 includes a user interface unit 612 that generates user interfaces (and/or instructions therefor) for display upon a computing device, e.g., via a navigation and/or browsing interface such as a browser or application installed on the computing device. In addition, the memory 610 may include and/or communicate with one or more data repositories (not shown), for example, to access user program codes and/or libraries.

[0074] In addition to and/or in combination with the user interface unit 612, the memory 610 may include mapping software 616 that may be executed by the processing unit 604. In one embodiment, mapping software 616 implements various aspects of the present disclosure, e.g., assigning POP 114 of the content delivery system 110 to DNS resolvers 104 and generating resolver-to-POP mapping information identifying such assignments.

[0075] While the mapping software 616 is shown in FIG. 6 as part of the resolver-to- POP route mapping system 600, in other embodiments, all or a portion of the mapping software 616 may be implemented by other components of the content distribution system 110 and/or another computing device. For example, in certain embodiments of the present disclosure, a POP 114 of the content distribution system 110 may include mapping software 616 or otherwise be configured with executable instructions to operate similarly to the resolver-to- POP route mapping system 600.

[0076] In some embodiments, the resolver-to-POP route mapping system 600 may further include components other than those illustrated in FIG. 6. For example, the memory 610 may further include executable instructions to undertake other operations related to the present disclosure, such as the association of subnets 202 to DNS resolvers 104.

[0077] All of the methods and processes described above may be embodied in, and fully automated via, software code modules executed by one or more general purpose computers or processors. The code modules may be stored in any type of non-transitory computer-readable medium or other computer storage device. Some or all of the methods may alternatively be embodied in specialized computer hardware.

[0078] Conditional language such as, among others, "can," "could," "might" or "may," unless specifically stated otherwise, are otherwise understood within the context as used in general to present that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment.

[0079] Disjunctive language such as the phrase "at least one of X, Y or Z," unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y or Z, or any combination thereof (e.g., X, Y and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y or at least one of Z to each be present.

[0080] Unless otherwise explicitly stated, articles such as 'a' or 'an' should generally be interpreted to include one or more described items. Accordingly, phrases such as "a device configured to" are intended to include one or more recited devices. Such one or more recited devices can also be collectively configured to carry out the stated recitations. For example, "a processor configured to carry out recitations A, B and C" can include a first processor configured to carry out recitation A working in conjunction with a second processor configured to carry out recitations B and C.

[0081] Any routine descriptions, elements or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or elements in the routine. Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted, or executed out of order from that shown or discussed, including substantially synchronously or in reverse order, depending on the functionality involved as would be understood by those skilled in the art.

[0082] It should be emphasized that many variations and modifications may be made to the above-described embodiments, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.