Geolocation and DNS Traffic Management

What is GTM

Global Traffic Management, or GTM, is a DNS-based load balancing service that offers application owners a level of flexibility and insight that is unmatched by traditional on-prem solutions. Highly scalable and fault-resilient, GTM offers customers a layer of abstraction between endpoints, so traffic can be easily shifted between targets. The platform is not limited to weighted load distribution, however; GTM can execute intelligent routing decisions based on client location, network conditions, and even origin server availability. These features are possible thanks to Akamai’s unrivaled visibility into the Internet, which fuels the platform’s dynamic, data-based route optimization engine.

This blog post will focus specifically on GTM’s Geo-IP intelligence feature, and how the Akamai platform addresses a known limitation of the DNS protocol concerning end-user geolocation detection.

AWS Builder Community Hub

DNS and Geolocation Limitations

The minimalist nature of the DNS protocol frequently presents challenges for more complex load balancing requirements. One great example: application owners often want to configure DNS traffic management platforms, such as GTM, to dynamically execute handout decisions based on the location of the end user [1]— information that is derived from the client IP address.  However, incoming DNS queries typically only advertise the IP of the requesting recursive resolver and do not disclose the true client IP. While the local recursive resolver is typically proximal to the requesting machine, geolocation detection can be distorted when a distant proxy server is performing a DNS lookup on behalf of an end user. Unlike HTTP, DNS has no ‘X-Forwarded-For’ equivalent, so the true initial client IP will be invisible to the responding nameserver, complicating any geo-routing decisions. For example, in the image below, the nameserver cannot evaluate the IP of the end user (; it only has insight into the recursive resolver address (

Back-End GTM

From an Akamai perspective, this scenario is applicable when an Akamai edge server is performing a DNS lookup against a GTM property to determine which ‘origin’ datacenter is best suited to respond to a client request. This setup is commonly described as ‘back-end’ GTM, which is illustrated by the second circle below[2]:


With IP intelligence, application owners can map regions to specific target endpoints; GTM nameservers will then handout IPs based on these assignments by evaluating the location of the requesting client resolver. However, with back-end GTM, an Akamai server queries the GTM property, so the GTM nameserver will only have insight into the location of this edge node (and not the true end user). Luckily, with a quarter of a million edge servers located across 234 countries, the impressive footprint of the Akamai platform ensures users are intelligently routed to a geographically proximal edge server. As a result, location-based handout decisions remain as accurate as possible when back-end GTM is in place.

But what happens when multiple Akamai servers are introduced? One of the primary features of Akamai CDN is SureRoute — an optimization engine that preemptively probes the internet to discover alternate request paths to improve performance and reliability. When enabled, the Akamai intelligent platform will frequently send a request to an additional Akamai server (called the ‘Parent’ server) before going forward to the origin datacenter[4] :


While this two-tiered model accelerates the delivery of content, adding an additional Akamai hop to the request flow complicates GTM’s visibility into the end user’s true location, as there is no guarantee the second Akamai server will be in the same approximate region as the initial edge node (called the ‘child’ server pictured above)[5]. Consequently, without any accommodations, GTM IP Intelligence will route the request based on the location of the parent server. While performant, this implementation may not meet the application owner’s traffic management requirements–especially if a strict ‘region-to-datacenter’ mapping needs to be honored for each end user.

To address this DNS limitation, Akamai has developed metadata tags to ensure back-end GTM IP intelligence is interoperable with SureRoute. These tags instruct the platform to always execute the origin DNS lookup on the initial child Akamai server, and the result will be passed to the subsequent parent. With this in place, application owners can more accurately assign users to a datacenter based on their approximate location.

Akamai’s Application Load Balancer (ALB)

With Akamai’s expansive, distributed network and the aforementioned metadata tags, back-end GTM geo-assignments remain accurate if the traffic routing decisions are evaluated at a country or continent level. However, if more granular logic is required (such as state or city), Akamai’s Application Load Balancer Cloudlet includes layer seven geolocation targeting. Unlike GTM, ALB has insight into HTTP request criteria, which allows the cloudlet to ascertain the location of the true end user. Consequently, if geo targeting needs to be executed at a state, county, or city level, ALB is a preferable solution. Along with heightened visibility into the end-user’s location, ALB offers additional layer seven traffic management capabilities, such as session affinity and instant failover.


While ALB offers additional layer seven faculties, GTM has unique capabilities as well, including the ability to execute traffic decisions before an HTTP request is made (Front-End GTM). Consequently, depending on the application owner’s requirements, either solution may prove a better fit, and it is even commonplace to use both!  There will be many architectural situations where an organization will have GTM deployed to cover the resiliency for some functions and ALB deployed to cover specific applications. The combination of ALB and GTM provide DevOps, network architects, and system engineers with the flexibility to choose the optimal cloud-based GSLB solution. Some applications architects might need cloudlet ALB functionality to manage in-line experiences that Akamai delivers. At the same time, network architects for that same company might need to shape traffic between multiple cloud deployments and providers. With GTM and ALB, system engineers and application developers have full control.

Find out More about Akamai’s GTM and ALB

Use the “Get in Touch” icon on to chat with someone in Akamai right now to find more information about Akamai’s GTM and ALB services. The following are some additional links to materials.

[1] For example, different data centers may serve unique geo-specific content. Such a use case would require users to be directed to the appropriate target based on their location

[2] Certain recursive DNS providers have implemented an extension (EDNS0) to pass the source IP information of the actual machine requesting the DNS record. However, the aforementioned proxy implementation can still distort DNS geo detection logic since the initial true client IP will not be visible in this scenario

[3] The optimal Akamai edge server is also determined via a DNS lookup initiated by the true client machine (circle #1). A GTM property can also be used in this stage as well (Front-End GTM)

[4] The most optimal path is computed by running ‘races’ against a Sureroute Test Object and then tabulating statistics based on real-time performance measurement of downloads, latency, and loss frequency.

[5] For cacheable content, a similar two-tiered model called Tiered Distribution is leveraged to maximize offload

*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Sam Preston. Read the original post at: