(This post originally appeared on Dyn.com, a company proud to lend some expertise and insight into Speed Awareness Month.)
My latest performance annoyance with DNS is the proliferation of long CNAME chains employed by various service providers around the Internet to topologically geolocate end-users and end-user networks. The concern is that many people don’t understand or appreciate the number of DNS queries that need to be performed due to these long CNAME chains, in many cases each with their own authoritative DNS infrastructures, of which many are not global anycast offerings like DynECT Managed DNS.
We’ve come across many sites where the main zone itself (say “example.com”) is using a robust anycast DNS network, only to CNAME critical web assets (such as www.example.com) off to less robust Unicast networks simply for enhanced performance through the use of Global Server Load Balancing (GSLB).
To back up this claim, we decided to study three popular banking websites, each known to use CNAME chains for the purpose of geolocation. For the sake of comparison, we setup a corresponding DNS hostname which mimicked the exaction geographic behavior of the original website FQDN and ran end to end page load measurements of the six FQDNs. Performance test data was taken from a variety of US locations using Catchpoint Systems monitoring.
The Test Specimens
Our first specimen was U.S. based Chase Bank, a popular US bank found at the URL http://www.chase.com. DNS service for the domain chase.com is handled by four unicast nameservers operated by Chase themselves, all of which are located on the East Coast. Additionally, lookups for www.chase.com are CNAME’ed off to wwwchase.gslb.bankone.com. The subdomain gslb.bankone.com is serviced by seven unicast GSLB DNS devices distributed around the US.
The second specimen, BNY Mellon, located at http://www.bnymellon.com, has DNS for the main domain itself handled by three unicast nameservers operated by Mellon Bank, in or around the Pittsburgh, PA, area. The website www.bnymellon.com is CNAME’ed off to www-bnymellon.extlb.bnymellon.com, handled by two unicast GSLB devices.
The third specimen is Capital One, located at http://www.capitalone.com, proved to be an interesting example of chaining DNS CNAME and additional redirection through HTTP. Two unicast nameservers operated by Capital One themselves handle DNS for capitalone.com. Additionally, www.capitalone.com is CNAME’ed off to www.wpex.capitalone.com which has its DNS handled by a pair of GSLB DNS devices. We also found an additional layer of HTTP redirection offered when the remote User-Agent is unknown.
In each of these cases, additional DNS queries above the usual three (root, TLD, domain authoritative DNS) are being made to support these GSLB devices. In many cases, more than four or five DNS queries are needed to resolve the host name in question – nearly doubling the latency of the DNS cycle needed to start loading the web page in question!
Remember for each of these sites, we set up “mirrored” DNS hostnames on our own DNS, utilizing the Traffic Management features offered by DynECT Managed DNS 5.0. We matched the characteristics of GSLB mapping, response RR sets and TTLs to emulate each site’s behavior as though it was hosted on DynECT Managed DNS.
The Test Results
The results of the test were impressive. There was a significant decrease of DNS response time down to 35 milliseconds or less thanks to a reduction of DNS queries due to Dyn’s unique capability to mix both standard DNS queries (A, AAAA, CNAME) intermingled with advanced DNS responses (GSLB). This eliminated the need to perform an additional lookup to resolve the CNAME from the main domain down to the GSLB devices, saving a DNS lookup. Additionally, the benefit of having all of these resolutions occur on a global anycast network also contributes to overall latency reduction.
As we know, certain DNS query sequences are a blocking operation in web browsers and in DNS resolvers since you cannot resolve a CNAME until you know what it actually points to. This delays the browser from connecting to the HTTP server itself, so we’re talking about massive potential impact to time to first byte and total page load time. Take a look below. Not only did we have a profound impact upon the DNS response time, but an overall decrease of up to 22.66% in the end-to-end page load time.
This is proof in the pudding for the need for optimized, globally anycast, managed DNS and traffic management services!
|Website||DNS Response Time (ms)||DynECT Optimized DNS Response Time (ms)||Total End-to-End Time (ms)||DynECT Optimized Total End-to-End Time (ms)||E2E Page Load Speedup|
* Capital One forces an additional lookup for their mobile site.
Website performance optimization teams work hard and spend gobs of money to decrease page load times by even single digit milliseconds. In this demonstration, we’re slashing page load times by double digit percentages just by making simple DNS optimizations – reducing the number of queries needed to perform geolocation and the migration to an anycast network. These are simple wins available to all website operators, and features available in our release of DynECT Managed DNS 5.0.
Tom (@tomdyninc) is one of the founders of Dyn, and over the years worked hard to earn the title of CTO. He is a technologist who is passionate about performance and optimization of DNS and Email Delivery services, and happens to have a particular knowledge of how the Internet backbone works at scale. He has a B.S. in Electrical and Computer Engineering from Worcester Polytechnic Institute (WPI).