This disclosure relates in general to content delivery and, more specifically, but not by way of limitation, to domain name service (DNS) resolution.
A content delivery network (CDN) is used by many web sites to deliver content more efficiently. The CDN may host, mirror and/or cache the content as well as deliver it to a requesting party. A web site or origin server is linked to the CDN such that some or all content can be sourced from the CDN rather than the web site. This process of fulfilling a link through a CDN is usually transparent to the user.
Singlecasting of large events can be difficult for CDNs to deliver efficiently. CDNs deliver content objects such as files or streams to tens of thousands of recipients in a short period of time. Serving resources can be overwhelmed by these large events. Where a point of presence (POP) or individual servers saturate, a user can experience inadequate quality of service (QoS). To avoid these bottlenecks, CDNs generally overbuild their serving resources and POPs. Overbuilding is undesirable, as it is inefficient and can result in increased expense and complexity that is not needed during normal operating conditions.
A domain name service (DNS) is used to resolve the IP address or group of IP addresses from where an object or stream should be sourced for delivery to a recipient. Users' local DNS recursors participate in a series of delegations to resolve the actual IP address of the server that will source the data. Through the delegation process, the request for data is routed to the server, which could be one of a number of servers that could source the data.
One or more alternative server addresses can be provided during the DNS resolution process. Any of the alternative servers can be used to provide the data associated with the requested domain. Where a small number of server addresses is provided, and/or where each user DNS recursor is given a DNS solution with the same server listed first, servers can overload and provide poor QoS. One solution to this problem is “round-robin DNS”, where IP addresses given in each DNS resolution are the same, but the order of the IP addresses could be varied for each DNS solution, with the goal of more evenly distributing the content requests across the servers.
Where a larger number of server addresses is desirable, there are limits, typically encountered at user-network firewalls and other security boundaries, on the size of a DNS solution packet, and therefore on the number of IP addresses that can be included in such a solution. A typical limit could be in the range of 16 to 20 IP addresses. There are two method known in the art that are usually deployed to work around this limit and enable utilization of more servers than the limit of the DNS solution packet size. One method is to use a load balancing switch to virtualize the IP addresses. In this method, a small number of logical IP addresses is returned in the DNS solution packet; content requests are intercepted by the load balancing switch; and the switch maps those requests to a greater (often far greater) number of physical IP addresses corresponding to physical servers. The switch is a “load balancing” switch because another of its functions, besides enabling the virtualization of server addresses, is to balance loads across servers, which among other effects, normally makes round-robin DNS unnecessary (because even if all content requests came to a single logical IP address, the switch can distribute the load among the physical IP addresses). Thus, in one example of this scenario, 16 logical IP addresses are returned in each DNS solution; all content requests are directed to one of these 16 logical IP addresses; the load balancing switch translates the 16 logical IP addresses to 60 physical server IP addresses; and the switch balances the loads across the 60 servers.
A second method of solving this DNS solution packet limit problem is to divide the content site into multiple, smaller logical sites, by using hostnames for each portion of the site (a “hostname” is the portion of the URL to the left of the website name, e.g., in the URL img.foo.com, “img” would be the hostname). As an example, if foo.com requires more than the limited number of servers that could be returned in a DNS solution packet, it could be divided into part-A.foo.com, part-B.foo.com, and part-C.foo.com. When DNS resolutions are requested, different server addresses can be provided for each hostname, thereby (in this example), tripling the number of servers that can be used to serve the content. When using this method, round-robin DNS is still useful, because changing the order of the IP addresses presented in the DNS solution for part-A.foo.com can help to more evenly distribute the content requests across the servers. Both of these methods, however, have limitations.
In the appended figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.