Akamai’s web application accelerator product has been a tremendous benefit for our global operations.  Using their tools, we have observed a 400% performance boost between the United States and Asia versus accessing our site over “public” internet.  The benefits come from three areas:

1. Caching static elements (javascript, css, images, etc) at Akamai edge servers around the world
2. Enhanced delivery speeds through Akamai’s proprietary internal protocols, which are able to avoid the TCP/IP slow start
3. Routing around internet bottlenecks

However, I frequently find myself talking to customers who are saying that many of their global offices are experiencing performance problems.  When I look into it, I frequently discover that many of the benefits of Akamai’s web application accelerator are being negated by the IT infrastructures of large, global corporations.

More specifically, it is being negated by the way that many large corporations handle DNS resolution.

To understand why, you first need to understand a little bit about how Akamai works.

How Akamai Works

Akamai maintains “edge servers” all over the world.  When a site connected to Akamai’s web application accelerator, the DNS entry is set up as a CNAME over to Akamai, rather than an A record.  When an end user tries to resolve the website, Akamai’s nameservers identifies an edge server near the end user, and they start talking to that edge, thinking it is the site.

Static elements may be served straight out of the edge server’s cache (if it has been requested by another user recently), and missing elements or non-cachable pages are routed through the Akamai network to another edge server near the host.  That edge server makes the actual requests to the host site and passes them back through the network to the original edge server, and from there they are returned to the end-user.

Since the edge servers are internally communicating using Akamai’s proprietary protocols and routing around bottlenecks, traffic can flow much faster than over the public internet.

The Role of DNS

The key to this entire process working properly is DNS.  Akamai is identifying which edge server to send the end user based on what DNS server made the request.  They assume that the end user is located nearby this DNS server, so as long as they accelerate traffic to that region, it should have only a short journey over the public internet.

However, in a corporate environment, there are generally multiple DNS servers involved.  Most offices will have some sort of internal DNS server.  When a machine wants to connect to a site, they will make a “recursive” name lookup request to their internal DNS server.  Since the internal DNS server cannot provide translations for external sites, it will simply forward the request its own external DNS server and then return the answer to the client.  The client is generally unaware that multiple DNS servers will involved in handling the request.

This still works fine, assuming that the external DNS server was close to the client, just like the internal DNS server was.

Global Corporate DNS Resolution

Unfortunately, global corporations are complex places with their own complex IT infrastructures.  They have large numbers of internal sites and resources, and they need their DNS servers to ensure that all internal users are able to access them.  Many times, rather than forwarding DNS requests to a nearby external DNS server, remote corporate offices will forward DNS requests to another internal DNS server back at the company’s headquarters, somewhere else in the world.

And here is where the problems come in. When trying to access external sites, the centralized DNS server needs to pass them off to its nearby external DNS server.  If the site is on Akamai, then it is the external DNS server near the central coprorate server who makes the request to Akamai.  Akamai now concludes that the user is in a completely different part of the world.

In the example in the diagram above, Akamai sees that the DNS request came from a DNS server in Europe, so it returns the ip address of a European edge server and routes the traffic there.  It has no way of knowing that the end user was actually in Asia.  Now, the end user starts communicating over public internet to the Akamai edge server in Europe.  At this point, most of the benefits for the Akamai network are lost.  The client is still travelling huge distances over congested networks using slow start TCP/IP to reach the edge server.

Fixing the Problem

There is no way to fix the Akamai configuration to correct the problem.  Changes need to be made at each remote office in the global corporation to change how they resolve DNS.  The need to modify their servers to pass external DNS entries and only forward on requests for internal sites to the central server (conditional forwarding).  Or, at the very least, pass off DNS requests for the Akamai site in question to the local site.

And this is where the real change is.  It involves educating IT professionals all over the world about how Akamai works and convincing them that they need to make a change on their end to fix the problem.  This requires overcoming language barriers and time differences, and being very persuasive.

Welcome to performance tuning in a globalized world.