What Is GeoDNS, and How Does Location-Based Routing Work?

If your users are spread across continents, sending all of them to one data center means some of them always get a slow experience. You might also need to keep European users' traffic on European servers for data protection reasons, or show different storefronts to different countries. All of these come down to the same requirement: give different people different answers when they look up the same hostname. GeoDNS does exactly that. This article explains how GeoDNS works, how an authoritative server figures out where a query came from, the role of EDNS Client Subnet, how to configure location-based routing in AWS Route 53 and BIND, and the pitfalls that catch people out. For how GeoDNS fits alongside round-robin and weighted routing, see how DNS can be used for load balancing. This article goes deeper on the location mechanism itself.

What Is GeoDNS?

GeoDNS (also called geolocation routing or geo-steering) is a feature of an authoritative DNS server that returns different records for the same name depending on the estimated geographic location of the query's source. A user in Germany who looks up www.example.com might receive 203.0.113.10, the address of a Frankfurt server, while a user in Brazil receives 198.51.100.20, the address of a São Paulo server.

The key point is that GeoDNS changes the answer. That makes it fundamentally different from anycast DNS, which changes which server answers but returns the same records everywhere. The two are often used together: an anycast network delivers queries quickly to a nearby name server, and GeoDNS logic on that server picks a region-appropriate answer.

How GeoDNS Works Under the Hood

Step 1: The Authoritative Server Sees the Resolver, Not the User

When a user's browser looks up a name, the query goes to their recursive resolver, which then asks the authoritative server. The authoritative server never sees the user's device directly. The source IP address of the query it receives belongs to the recursive resolver.

For many users, that is fine. An ISP's resolver is usually in the same country or region as its customers, so the resolver's location is a reasonable proxy for the user's location. But public resolvers complicate this. If a user in Kenya uses a public resolver whose nearest instance happens to be in another country, a GeoDNS server that only looks at the source IP will route them as if they were in that other country.

Step 2: EDNS Client Subnet Narrows It Down

To fix this, EDNS Client Subnet (ECS), defined in RFC 7871, lets a recursive resolver include a truncated version of the client's IP address in its query to the authoritative server. Typically it sends only the first 24 bits of an IPv4 address, or the first 56 bits of an IPv6 address, so the authoritative server learns the user's network but not their exact address. ECS is carried in the OPT record introduced by EDNS.

The authoritative server uses that subnet for its location lookup and returns an answer along with a scope prefix length, which tells the resolver how broadly the answer applies. The resolver then caches that answer only for clients within that scope.

ECS support varies by resolver:

Resolver	Sends ECS to authoritative servers
Most ISP resolvers	Often not needed, since the resolver is near its users
Google Public DNS (8.8.8.8)	Yes, to authoritative servers that support it
Cloudflare (1.1.1.1)	No, for privacy reasons
Quad9 (9.9.9.9)	No. Quad9 offers a separate ECS-enabled service at 9.9.9.11
Corporate resolvers	Depends on configuration

Because Cloudflare's network is so densely anycast, its resolver instance is usually close to the user anyway, which reduces the impact of not sending ECS.

Step 3: The Location Database

The authoritative server maps the IP or subnet to a location using a GeoIP database, a dataset that associates IP ranges with countries, regions, and sometimes cities. Common sources are commercial databases such as MaxMind GeoIP2 and regional internet registry allocation data. Country-level accuracy is high for most fixed-line networks. City-level accuracy is much lower, and mobile, satellite, and VPN traffic can be wrong entirely.

Step 4: Rule Matching and the Default Answer

Finally, the server matches the location against your rules, typically checking from most specific to least specific: subdivision, then country, then continent, then a default record for everything else. If a location matches nothing and there is no default, many providers return an empty answer, which looks to users like the site does not exist. Always define a default.

GeoDNS vs Latency-Based Routing

GeoDNS and latency-based routing are related but not the same.

Approach	Decides by	Best for
GeoDNS	The query's estimated geographic location	Compliance, localized content, contractual regional routing
Latency-based routing	Measured network latency between the user's network and each region	Pure performance
Geoproximity	Distance to each endpoint, with an adjustable bias	Gradually shifting traffic between regions

If your only goal is speed, latency-based routing is usually more accurate, because geography and network distance do not always agree. If you need guarantees such as "users in the EU always go to EU servers," you need geolocation rules.

Configuring GeoDNS in AWS Route 53

Route 53 supports geolocation routing by continent, country, and for some countries by subdivision, such as US states. Each location gets its own record set with a unique SetIdentifier. Save the following as geo.json:

{
  "Comment": "Geolocation routing for www.example.com",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "SetIdentifier": "germany",
        "GeoLocation": { "CountryCode": "DE" },
        "TTL": 60,
        "ResourceRecords": [{ "Value": "203.0.113.10" }]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "SetIdentifier": "europe",
        "GeoLocation": { "ContinentCode": "EU" },
        "TTL": 60,
        "ResourceRecords": [{ "Value": "203.0.113.20" }]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "SetIdentifier": "default",
        "GeoLocation": { "CountryCode": "*" },
        "TTL": 60,
        "ResourceRecords": [{ "Value": "198.51.100.20" }]
      }
    }
  ]
}

Apply it with the AWS CLI:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789EXAMPLE \
  --change-batch file://geo.json

This creates three records for the same name. Users in Germany get 203.0.113.10, the rest of Europe gets 203.0.113.20, and everyone else gets the default 198.51.100.20. Route 53 always uses the most specific match, so Germany overrides the Europe rule. "CountryCode": "*" is Route 53's syntax for the default location. Route 53 uses ECS data when the resolver provides it. For general Route 53 record management, see how to manage DNS records in AWS Route 53.

Testing Route 53 Geolocation

Route 53 can simulate a query from a specific resolver and client subnet without you needing to be in that location:

aws route53 test-dns-answer \
  --hosted-zone-id Z0123456789EXAMPLE \
  --record-name www.example.com \
  --record-type A \
  --resolver-ip 203.0.113.1 \
  --edns0-client-subnet-ip 203.0.113.0 \
  --edns0-client-subnet-mask 24

The response shows the record data Route 53 would return for that subnet. Replace the example addresses with real IPs from the regions you want to test, since documentation ranges do not geolocate to any country.

Configuring GeoDNS with BIND Views

You can also do location-based answers on your own name server. BIND supports GeoIP2 databases in access control lists, and views let you serve different versions of a zone to different ACLs. This named.conf excerpt assumes MaxMind GeoLite2 or GeoIP2 database files are installed in /usr/share/GeoIP:

options {
    directory "/var/cache/bind";
    geoip-directory "/usr/share/GeoIP";
    recursion no;
};

acl "europe" { geoip continent EU; };
acl "north_america" { geoip country US; geoip country CA; geoip country MX; };

view "europe" {
    match-clients { europe; };
    zone "example.com" {
        type primary;
        file "/etc/bind/zones/db.example.com.eu";
    };
};

view "north_america" {
    match-clients { north_america; };
    zone "example.com" {
        type primary;
        file "/etc/bind/zones/db.example.com.na";
    };
};

view "default" {
    match-clients { any; };
    zone "example.com" {
        type primary;
        file "/etc/bind/zones/db.example.com.default";
    };
};

BIND evaluates views in order and uses the first one whose match-clients ACL matches the query's source address. Each view has its own copy of the zone, so the three zone files can differ in just the records you want to localize:

; db.example.com.eu (excerpt)
www   60  IN  A  203.0.113.20

; db.example.com.na (excerpt)
www   60  IN  A  198.51.100.30

; db.example.com.default (excerpt)
www   60  IN  A  198.51.100.20

Check the configuration with sudo named-checkconf, then reload with sudo rndc reload. The views here match the address the query arrives from, which is normally the recursive resolver, so keep the resolver-location caveats above in mind. Every zone must be defined in every view, and keeping three copies in sync is the main operational cost. Many teams generate the per-view files from a template. The same views mechanism is also used for internal versus external answers, covered in what split-horizon DNS is. For a full BIND setup, see how to run your own DNS server with BIND.

Other authoritative servers offer similar features, including PowerDNS's GeoIP backend and the geo-steering options in most managed DNS and load-balancing products.

Testing GeoDNS from the Command Line

dig can add an ECS option to a query, so you can ask an ECS-aware authoritative server what it would return for a given subnet:

dig @ns1.example-dns.net www.example.com A +subnet=203.0.113.0/24

Query the authoritative server directly, not a public resolver, so that the subnet you specify is what the server sees. In the response's OPT PSEUDOSECTION, a CLIENT-SUBNET line shows the subnet and the scope the server returned. A scope of /0 means the answer does not vary by location.

Real-World Use Cases

1. Performance. Sending users to the nearest region cuts round-trip times for every request after the DNS lookup.
2. Data residency. Keeping EU users on EU infrastructure helps support data protection obligations, though DNS alone is not a compliance guarantee.
3. Localized content. Country-specific storefronts, pricing, or languages served from separate deployments.
4. Licensing and content rights. Directing users to region-appropriate services where content is licensed per country.
5. Gradual regional rollouts. Releasing a new deployment to one country first.
6. Regional failover. Combining geolocation with health checks so a region's users move to the next closest region if theirs fails. See what DNS failover is and how to configure it.

Common Mistakes and Best Practices

1. Always define a default record so unmatched locations still resolve.
2. Do not rely on GeoDNS for security or strict compliance. VPNs, proxies, and misgeolocated IPs mean some users will always land in the "wrong" region. Enforce hard requirements at the application layer too.
3. Keep TTLs moderate. Short TTLs, often 60 to 300 seconds, let routing changes take effect quickly. Remember that DNS caching means each resolver keeps the answer it got for the full TTL.
4. Keep the GeoIP database updated if you run your own server. IP allocations move between countries regularly.
5. Make every regional endpoint serve the full site. Users will occasionally be routed to an unexpected region, and search engine crawlers typically resolve from a handful of locations.
6. Add health checks so a dead region is not still receiving its users.
7. Test from real vantage points, not just from your office.

---

GeoDNS FAQ

Conclusion

GeoDNS gives you a simple but powerful lever: the same hostname can lead to different servers for different parts of the world. It works by estimating each query's location from the resolver's IP, or more accurately from EDNS Client Subnet data, matching it against your rules, and returning the matching record, with a default for everyone else.

Used well, it speeds up global sites, supports data residency and localization, and enables regional rollouts and failover. Used carelessly, it sends some users to the wrong place with no way back. Define a default, keep regional deployments complete, pair location rules with health checks, and test from real networks. Then GeoDNS becomes a dependable part of a global architecture rather than a source of hard-to-reproduce bugs.

Here are some useful references for going deeper on GeoDNS:

1. RFC 7871: Client Subnet in DNS Queries — the specification for EDNS Client Subnet.
2. AWS Documentation: Choosing a routing policy — Route 53 geolocation, geoproximity, and latency-based routing.
3. ISC BIND 9 Documentation: BIND 9 Administrator Reference Manual — covers views, ACLs, and GeoIP2 matching.
4. Cloudflare Learning Center: What is DNS? — background on how resolvers and authoritative servers interact.
5. MaxMind: GeoIP2 and GeoLite2 Developer Documentation — the IP geolocation databases used by many GeoDNS implementations.