I recently read an interesting post on LinkedIn Engineering’s blog entitled “TCP over IP Anycast – Pipe dream or Reality?” The authors describe a project to optimize the performance of www.linkedin.com.
The website is served from multiple web server instances located in LinkedIn’s POPs all over the world. Previously LinkedIn used DNS geomapping exclusively to route its users to the best web server instance, but the post describes how they tried using BGP routing instead. In a controlled experiment, they published a single anycast address corresponding to every instance of their website worldwide and let BGP routing direct users to the best one. Performance wasn’t universally improved and worsened in some cases. They ended up using a combination of DNS and BGP routing to direct users to the best place. Rather than use a single anycast IP address for every instance worldwide, they grouped their POPs by geography and assigned an anycast address to all the instances within a region. When a user visits www.linkedin.com, DNS geomapping techniques direct her to the appropriate anycast IP for her region, and then BGP routing chooses the path to the best web server instance in that region. LinkedIn’s before and after performance measurements show the experiment was a success.
This post raises an obvious question: are techniques using DNS to “steer” traffic (such as IP geolocation) sufficient, or do you need to consider using anycast as LinkedIn did? The short answer is that DNS steering works well and is only getting better.
LinkedIn’s situation is special: they run the 14th busiest website in the world according to Alexa. They have the resources and engineering talent to build their own worldwide network of POPs to serve all that traffic. Few companies can do similar, nor do they need to. The benefits of anycasted web content only start to matter in a situation such as LinkedIn’s with a large number of content-serving instances. Most companies have content distributed to far fewer sites and will be much better served by using DNS steering techniques.
Let’s address some of the specific issues that LinkedIn cites regarding using DNS to direct users. First, they point out the lack of visibility to the actual user’s IP address to make steering decisions. Recall that end user devices send DNS queries to a recursive nameserver, usually run by their ISP or on a corporate network. The recursive server queries the authoritative server (in this example the nameserver for linkedin.com) on the user’s behalf, and thus any DNS steering decisions in the authoritative server are made based on the recursive server’s address, not the end user’s address. Usually the recursive server is close to the user, but not always, especially in the case of large public DNS providers, such as Google Public DNS or OpenDNS.
The good news is that the DNS engineering community has known about the issue for a long time and there’s a solution: EDNS Client Subnet, or ECS. This DNS protocol extension allows the recursive server to pass the user’s subnet address to the authoritative server, finally giving the authoritative server visibility to the actual end user address (the subnet is sent rather than the specific IP address for privacy reasons). ECS is winding its way through the IETF standards process and has already seen wide deployment: major DNS providers such as Google and OpenDNS—the ones whose users are most geographically distributed—already support it. So the issue of the authoritative server not knowing the end user’s address to make accurate steering decisions is going away quickly.
The second DNS-related issue LinkedIn mentioned was accuracy of IP geolocation databases. It doesn’t do much good if the authoritative server has visibility to the end user’s actual address but the geographic mapping for that address is incorrect. There are several commercially available IP geolocation databases and they all have their faults, which is why Dyn has built our own to power our products. We start with commercial data but then augment and refine with various patent-pending proprietary techniques. We announced our geolocation enhancements last year and we’ve continued to improve the techniques and the database’s accuracy. We’re confident that no one has better data than we do for mapping DNS-related infrastructure, which is exactly what you need to accurately steer DNS traffic.
Ultimately using DNS to steer users to content gives you the most flexibility. When you rely on anycast and BGP routing, your options for control are limited. You’re relying on the routing policy of other people’s networks and some things are just outside your control. For example, commercial arrangements and disagreements between ISPs can cause traffic to take suboptimal paths. But with DNS, you can use any criteria you want to route traffic. IP geolocation is popular because it performs well, but there are other options. Dyn offers a real user monitoring (RUM) service that measures CDN and website performance from inside the web browser of actual users (hence the name). This data is available in our Internet Intelligence product today and coming soon to our Managed DNS product: shortly you’ll be able to use DNS to direct users to your content based on actual performance measurements made by those users.
So while adding anycast to your website can offer good performance, ultimately DNS steering gives you the most flexibility, and Dyn’s Managed DNS solutions are the best in the industry. And we keep innovating with features like RUM and geographic refinement techniques so good we’re patenting them. Stick with Dyn and we’ll get your traffic delivered—faster, safer and more reliably than ever.
Matt Larson is the CTO for Dyn, the world leader in Internet performance solutions. Matt leads technical innovation at Dyn. In addition, he oversees the engineering, labs and architecture teams and ensures that Dyn remains a leader in engineering excellence. Follow Matt on Twitter at @MatthewHLarson or @Dyn.