Geo DNS

Geo DNS is authoritative DNS. It returns a different answer for the same name, depending on where the query appears to come from. RFC 7871 states the practice plainly: “Many Authoritative Nameservers today return different responses based on the perceived topological location of the user. These servers use the IP address of the incoming query to identify that location” (RFC 7871 §1). Vendors brand it differently. Amazon Route 53 calls it geolocation routing, Azure Traffic Manager calls it the Geographic routing method, and Cloudflare Load Balancing calls it Geo steering. But the mechanism is always the same three steps: read one source address, map it to a region, return the record configured for that region.

It is not Anycast. No packet path changes. No address is advertised from many sites. A name server you control makes the decision once, inside an answer. It is not latency steering either. Route 53 treats “geolocation, geoproximity, IP-based, and latency routing” as four separate policies (AWS docs). A region rule says nothing about round-trip time. It is not failover either. Under Azure’s Geographic method, a region maps to exactly one endpoint. “Traffic Manager returns a response whether the endpoint is healthy or not” (Azure docs). The mapping is a database lookup on an IP address. So it is not an enforcement boundary. A proxy or VPN exit in the target region is indistinguishable from a user there.

Here is the trade-off. You get a deterministic, auditable mapping from place to PoP. AWS names the benefit as balancing load “in a way that is easy to predict and manage, so that each user location always goes to the same endpoint” (AWS docs). But you pay for it. Two structural weaknesses remain that no configuration removes: the server usually sees a recursive resolver instead of the user, and every answer is cached for its TTL. So a re-steer is never instant.

How it works

1. The query arrives from a resolver, often after a CNAME hop. A client asks its recursive resolver. The resolver queries the zone’s authoritative name servers. Many providers park a CNAME in front of the steering service. At Akamai, “the name server replies with a CNAME alias that points to Akamai’s GTM servers”. Then the resolver “requests an optimized route from GTM for the user request, based on policy rules” (Akamai TechDocs).
2. The steering server reads the source address of that query. Azure is explicit that this is normally not the user: “Traffic Manager uses the source IP address of the DNS query to determine the region where a user queries from, which is typically the IP address of the local DNS resolver making the query for the user” (Azure docs).
3. The address is turned into a place by a geo database. “Geolocation works by mapping IP addresses to locations” (AWS docs). The database is a third-party asset. It is not part of DNS. AWS documents this: when a resolver forwards a truncated client address, “CloudFront checks the MaxMind database” (AWS re:Post).
4. Granularity is coarse and fixed by the provider. Route 53 lets you “specify geographic locations by continent, by country, or by state in the United States” (AWS docs). Azure offers World, Regional Grouping, Country/Region and State/Province. The last is “supported only for states/provinces in Australia, Canada, and USA” (Azure docs). There is no “this city” and no “this ISP”.
5. Overlapping rules resolve to the most specific. With Route 53, “If you create separate records for overlapping geographic regions—for example, one record for North America and one for Canada—priority goes to the smallest geographic region” (AWS docs). Azure walks the hierarchy upward: the “lookup starts at the lowest granularity level (State/Province where supported, then Country/Region level) and goes up to the highest level, which is World”, so an endpoint mapped to Ireland beats one mapped to Europe (Azure docs).
6. Unmatched queries need an explicit catch-all. Some addresses map nowhere at all. Route 53: “You can create a default record that handles both queries from unmapped IP addresses and queries from locations where you haven’t created geolocation records. If you don’t create a default record, Route 53 returns a ‘no answer’ response for queries from those locations” (AWS docs). Azure: “If a query comes from a geographic region that has no mapping in that profile, Traffic Manager returns a NODATA response” (Azure docs).
7. The answer is then cached, and the choice sticks. “The recursive DNS service caches the DNS responses it receives. The DNS resolver on the client device also caches the result”. The record’s TTL sets how long: “Shorter values result in faster cache expiry and more round-trips to the Traffic Manager name servers. Longer values mean that directing traffic away from a failed endpoint takes longer” (Azure docs).
8. EDNS Client Subnet can replace the resolver’s address with the client’s prefix. ECS is an EDNS0 option. It lets a recursive resolver, if it is willing, “forward details about the origin network from which a query is coming” (RFC 7871 §5). When ECS is present, the geo lookup runs on the client’s network instead: “Route 53 finds the location of the user from the shortened IP address instead of the resolver’s source IP address; this usually gives a more accurate location” (AWS docs). It is shortened on purpose. Resolvers are “strongly encouraged to conceal part of the user’s IP address by truncating IPv4 addresses to 24 bits. 56 bits are recommended for IPv6” (RFC 7871 §11.1). So ECS identifies a network, never a household.

That is the whole mechanism: one lookup on one address, one record per region, cached until the TTL expires. Everything below follows from that.

Why it matters for a CDN

A CDN only pays off if each user lands on a near edge server. For most of the industry, DNS makes that choice, not routing. AWS documents it as CloudFront’s default behaviour: “CloudFront routes traffic based on the distribution’s price class, associated geolocation databases, and EDNS0-Client-Subnet support” (AWS re:Post). Four jobs fall out of that single lever.

• Placement. Point a continent, country or state at the PoP that serves it. The latency of first byte improves for everyone behind that mapping. This works without touching BGP, addresses, or the client.
• Capacity you can predict. The rule is the region, not a measurement. So “each user location always goes to the same endpoint” (AWS docs). Per-PoP load then follows from population, not from other people’s routing.
• Policy and compliance. The same lever serves language, licensing and residency: “You can also use geolocation routing to limit content to only the locations where you have distribution rights” (AWS docs). Azure sells its Geographic method for “data sovereignty mandates, localization of content and user experience, and measuring traffic from different regions” (Azure docs). Treat these as routing policy, not as controls that cannot be evaded.
• Provider selection. In a multi-CDN build, the region record is where one provider is chosen over another. That works because the endpoint on the far side need not be the DNS operator’s own infrastructure. Azure’s Geographic method directs users “to specific endpoints (Azure, External, or Nested)” (Azure docs).

What CDNs do

• AWS. Route 53 exposes it as the geolocation routing policy over continent, country and US state, with a default record for unmapped addresses (AWS docs). CloudFront applies the same idea internally for edge selection. It combines price class, geolocation databases and ECS support (AWS re:Post). ECS is honoured across policies: “To improve the accuracy of geolocation, geoproximity, IP-based, and latency routing, Amazon Route 53 supports the edns-client-subnet extension of EDNS0” (AWS docs).
• Akamai. GTM has a dedicated property mode for this: “Map by geographic location. GTM returns a CNAME based on the location (country, or country and state) of the requester”. You configure it by defining a geographic map (Akamai TechDocs). Geographic maps are still first-class objects in the current GTM API (GTM API reference). In its other property modes GTM hands back addresses instead, “the list of IP addresses for servers at an optimal data center location” (Akamai TechDocs). So “Geo DNS at Akamai” may mean a CNAME or an address set, depending on the property.
• Azure. Traffic Manager’s Geographic method assigns each endpoint a set of regions. “Traffic Manager routes any requests from those regions only to that endpoint”. A profile runs “only one traffic routing method at a time”. Methods are combined by nesting profiles (Azure docs). It reads ECS when offered: “In addition to the source IP address of the DNS query (usually the DNS resolver’s IP address), Traffic Manager also considers the client subnet address if it’s included in the DNS query” (Azure FAQ).
• Cloudflare. Geo steering exists, but it is a Load Balancing feature. It does not use a geo-IP lookup on the query source: “Geo steering directs traffic to pools tied to specific countries, regions, or — for Enterprise customers only — data centers”. And “the region of a client is determined by the region of the Cloudflare data center that answers the client’s DNS query”. First anycast decides proximity. Then a per-region pool applies (Cloudflare docs). On the resolver side Cloudflare is the opposite of a Geo DNS ally: “1.1.1.1 is a privacy-focused resolver and does not include client IP information in its queries to authoritative servers. It does not send the EDNS Client Subnet (ECS) header” (Cloudflare docs).

Watch out for

• You are steering the resolver, not the user. “Since most queries come from Intermediate Recursive Resolvers, the source address is that of the Recursive Resolver rather than of the query originator” (RFC 7871 §1). Centralised resolver estates make this worse. The RFC says so: “These cases all lead to less than desirable responses from topology-sensitive Authoritative Nameservers” (RFC 7871 §1).
• ECS is opt-in at both ends, and a major resolver declines. RFC 7871 recommends “that the feature be turned off by default in all nameserver software, and that operators only enable it explicitly in those circumstances where it provides a clear benefit for their clients” (RFC 7871 §2). Route 53 “can use edns-client-subnet only when DNS resolvers support it” (AWS docs). Cloudflare’s 1.1.1.1 “does not send the EDNS Client Subnet (ECS) header”. The one documented exception is Akamai’s cross-provider debug domain whoami.ds.akahelp.net, not any production zone (Cloudflare docs). So for that resolver’s users, your geo answer is only ever as good as the resolver’s own position.
• ECS is not free for the resolver. “Enabling support for ECS in an Intermediate Nameserver will significantly increase the size of the cache, reduce the number of results that can be served from cache, and increase the load on the server” (RFC 7871 §7.3.1). This is why the RFC also says it “SHOULD be disabled in all default configurations” (RFC 7871 §11.3). Expect fewer cache hits and more traffic at your authoritative servers once ECS is in play.
• Mixed ECS support inside one zone poisons the result. Google Public DNS is explicit: “All authoritative name servers for an ECS-enabled zone must enable ECS for the zone”. That is because a server that does not participate “quickly becomes the source of most cached data” (Google Public DNS).
• Overlapping ECS scopes make the answer depend on query order. “An Authoritative Nameserver MUST NOT overlap prefixes”. Where it does, “the order of queries will determine which answers get cached” (RFC 7871 §7.2.1).
• The geo database is approximate and incomplete. “Some IP addresses aren’t mapped to a location, so even if you create geolocation records that cover all seven continents, Amazon Route 53 will get some DNS queries from locations that it can’t identify” (AWS docs). AWS’s own troubleshooting note is blunt about the consequence: “You must correctly map the IP addresses in the geolocation database so that requests are routed correctly” (AWS re:Post).
• No catch-all means no answer. A missing default record (Route 53) or missing World region (Azure) turns an unmapped user into a resolution failure. There is no fallback (AWS docs, Azure docs).
• Geographic routing can out-rank health. An Azure region maps to exactly one endpoint. So “Traffic Manager returns a response whether the endpoint is healthy or not”. An endpoint in the Stopped state yields NODATA, with no further lookup up the hierarchy. Microsoft’s answer is to point regions at Nested endpoints “that have child profiles containing at least two endpoints within each” (Azure docs).
• Vendor coupling. Steering modes are not orthogonal: an Azure profile runs one routing method at a time (Azure docs). With Cloudflare, “custom load balancing rules are incompatible with Geo steering”. Data-center-level granularity there is Enterprise-only (Cloudflare docs).
• Caching makes every change late. The recursive service and the client both cache the answer. So a region moved to another PoP takes effect only as TTLs expire. And “directing traffic away from a failed endpoint takes longer” (Azure docs). Geo DNS is a placement tool, not an outage tool.

Best practice

• Configure the catch-all first. A default record in Route 53, a World-mapped endpoint in Azure. Unmapped addresses exist in every zone. Build the fallback before the regions (AWS docs, Azure docs).
• Enable ECS on every authoritative name server for the zone, not just some. One non-participating server becomes the cache source and silently flattens your steering (Google Public DNS).
• Measure whether the resolvers your users actually use send ECS. AWS documents the check. Query a resolver known to support it, and look for a truncated client subnet in the answer. dig +nocl TXT o-o.myaddr.l.google.com @8.8.8.8 +short returns a “/24” or “/32” client subnet when ECS is in use (AWS re:Post). Design the mapping for the resolver mix you observe, not the one you assume.
• Size regions to the granularity you are actually given. Route 53 offers continent, country and US state. Azure offers World, regional grouping, country, and state or province, with state or province supported only in Australia, Canada and the USA. A rule finer than the provider’s taxonomy cannot be expressed (AWS docs, Azure docs).
• Pick the TTL from the re-steer budget, then accept the bill. Shorter TTLs mean “faster cache expiry and more round-trips” to your authoritative servers. Longer TTLs mean slower withdrawal of a region (Azure docs). Azure allows anything from 0 to 2,147,483,647 seconds. The constraint is yours, not the platform’s.
• Do not ask geo to optimise latency. Compose it with something that does. Route 53 keeps latency and geoproximity as distinct policies (AWS docs). Azure’s supported way to combine is structural: “You can combine traffic routing methods by using nested Traffic Manager profiles” (Azure docs). Put geographic routing on the outside for compliance, and performance-style routing inside.
• Keep failover in a layer that fails over. A mapped region answers regardless of endpoint health. So put health-checked pools or nested profiles behind each region. Do not rely on the geo answer to move traffic (Azure docs).
• Never use Geo DNS as a compliance or security control on its own. The decision rests on an IP-to-location database and, at best, a truncated client prefix. Enforce licensing or residency at the application or delivery layer. Treat the DNS answer only as an optimisation (AWS docs, RFC 7871 §11.1).