What is GeoDNS and how does location-based routing work?

GeoDNS is a technique where an authoritative DNS server gives different answers to the same query depending on where the request appears to come from. A visitor in London who looks up www.example.com might get the IP address of a server in Frankfurt, while a visitor in Sydney gets the address of a server in Singapore. The DNS server works out the location by looking up the source IP address of the query (or the client subnet passed along by the resolver) in a geolocation database, then picks the record set you've configured for that country, continent or region.

It's one of the simplest ways to send users to a nearby server, keep data in a particular jurisdiction, or show regional versions of a service, and it doesn't need any changes on the client side. In this article you'll learn how GeoDNS decides where someone is, what it's good and bad at, how it differs from anycast and latency-based routing, and how to set it up with BIND, PowerDNS, Amazon Route 53 and Terraform.

How GeoDNS Works

In normal DNS, every client asking for www.example.com gets the same answer. A GeoDNS-enabled authoritative server adds one extra step before it replies: it decides which version of the answer to send.

The Lookup Flow

1. The user's device asks its recursive resolver for www.example.com. This is usually their ISP's resolver, a company resolver, or a public resolver such as 8.8.8.8.
2. The resolver walks the DNS hierarchy and eventually sends the query to your authoritative nameservers.
3. Your authoritative server looks at the source of the query. By default that's the resolver's IP address. If the resolver includes an EDNS Client Subnet (ECS) option, the server can use a truncated version of the end user's IP address instead.
4. It looks that address up in a geolocation database, such as MaxMind GeoIP2 or a provider's own data, to get a country, continent, or sometimes a region or city.
5. It matches the location against your rules and returns the records configured for that location, or a default set if nothing matches.
6. The resolver caches the answer for the record's TTL and hands it back to the user.

The key point is that the authoritative server never sees the user directly. It sees the resolver, and that has big consequences for accuracy.

Location Is Based on the Resolver, Not the User

If a user in Paris uses their ISP's resolver in Paris, GeoDNS works well. If they use a corporate VPN that sends all DNS through a resolver in New York, your server thinks they're in New York. The same applies to users of public resolvers whose nearest node is in another country.

ECS was designed to help with this. A resolver that supports it sends a shortened form of the client's address, typically the first 24 bits of an IPv4 address, so the authoritative server can make a better guess. Not all resolvers send ECS, though. Cloudflare's 1.1.1.1, for example, deliberately doesn't send it for privacy reasons, while Google Public DNS does send it to authoritative servers that support it.

What GeoDNS Is Used For

Location-based answers solve several practical problems:

• Lower latency: Sending users to the closest data centre or region cuts round-trip time for every request after the DNS lookup.
• Regional content: Point www at a UK storefront for UK visitors and a US storefront for US visitors, each with the right currency and language.
• Data residency: Keep EU users on EU infrastructure so their requests are handled within the EU, which can help with regulatory requirements.
• Licensing and compliance: Media services sometimes have to serve different catalogues by country.
• Spreading load across regions: Distribute traffic so one region isn't overwhelmed while another sits idle.
• Gradual regional rollouts: Launch a new backend in one country first by changing just that country's answer.

GeoDNS is a coarse tool, though. It decides once per DNS lookup, and the result is cached. It can't react to a single slow request, and it shouldn't be treated as a security control, because anyone can change their apparent location with a VPN.

Geolocation Granularity

Most GeoDNS systems let you write rules at several levels. The more specific rule wins when there's a match.

Level	Example	Typical use
Continent	Europe, Asia, North America	Coarse regional routing to a few data centres
Country	GB, DE, US, JP	Regional storefronts, compliance, licensing
Subdivision	US state, Canadian province	Finer routing in large countries
Custom region or subnet	A list of CIDR ranges	Routing specific networks or offices
Default	Everything else	A catch-all so no user gets an empty answer

Always configure a default answer. If a resolver's IP address isn't in the geolocation database, or it maps to a country you haven't listed, a GeoDNS setup without a default can return no records at all, which looks like an outage to that user.

GeoDNS vs Other Traffic Routing Methods

GeoDNS is often confused with related techniques. They solve similar problems in different ways.

Method	How it decides	Strengths	Weaknesses
GeoDNS	Geographic location of the resolver or client subnet	Simple, predictable, good for compliance and regional content	Location isn't the same as network distance; depends on resolver location
Latency-based routing	Measured network latency from resolver networks to each region	Picks the genuinely fastest region more often	Less predictable; not suitable for compliance rules
Anycast	The same IP announced from many locations; BGP routes users to the nearest one	No DNS tricks, works per packet, fast failover	Needs your own IP space and BGP, or a provider that offers it
Weighted DNS	Fixed percentages per record	Good for canary releases and splitting load	Ignores location entirely

Many large services combine these. A CDN might use anycast for its edge network and GeoDNS or latency routing to choose between origin regions behind it. Amazon Route 53 offers geolocation, geoproximity and latency-based routing as separate policies, and you can nest them with alias records to build more complex trees.

Geography Isn't the Same as Network Distance

A user in one country might be closer, in network terms, to a data centre in a neighbouring country because of how their ISP peers. Geographic rules ignore that. If your goal is purely performance, latency-based routing or anycast is often a better fit. If your goal is "EU users must reach EU servers", geography is exactly what you want.

Setting Up GeoDNS

How you configure GeoDNS depends on whether you run your own nameservers or use a managed DNS provider.

BIND with GeoIP2 Views

BIND 9 can match clients by location using MaxMind's GeoIP2 databases inside ACLs. You combine those ACLs with views, where each view serves a different copy of the zone.

First, point BIND at the database directory in named.conf.options:

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

Then define ACLs and views in named.conf.local:

acl "europe" {
    geoip continent EU;
};

acl "asia" {
    geoip continent AS;
};

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

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

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

Views are evaluated in order, so the catch-all default view must come last. Each zone file holds the records for that region. For example, the European file might contain:

$TTL 300
@       IN  SOA ns1.example.com. hostmaster.example.com. (
            2026102101 ; serial
            3600       ; refresh
            900        ; retry
            1209600    ; expire
            300 )      ; negative caching TTL
@       IN  NS   ns1.example.com.
@       IN  NS   ns2.example.com.
ns1     IN  A    192.0.2.53
ns2     IN  A    198.51.100.53
www     IN  A    203.0.113.10

The Asian and default files are identical apart from the www address and the serial. Check the config before reloading:

sudo named-checkconf
sudo named-checkzone example.com /etc/bind/zones/db.example.com.eu
sudo rndc reload

The downside of views is that you maintain several near-identical zone files. Keep them generated from a single template, or the regional copies will drift apart over time.

You'll also need to keep the GeoIP2 database updated. MaxMind publishes updates regularly, and their geoipupdate tool can fetch new copies on a schedule once you've set up a free account.

PowerDNS with LUA Records

PowerDNS Authoritative Server supports LUA records, which compute the answer at query time. Once you've enabled them (enable-lua-records=yes) and configured the GeoIP backend's database, a single record can choose an address based on the client's location:

www.example.com.  300  IN  LUA  A "ifurlup('https://www.example.com/health', {{'203.0.113.10'}, {'198.51.100.10'}}, {selector='pickclosest'})"
geo.example.com.  300  IN  LUA  A "pickclosest({'203.0.113.10', '198.51.100.10'})"

pickclosest returns the address that's geographically closest to the client, based on the GeoIP data for each candidate. This avoids maintaining separate zone files, at the cost of a more specialised setup.

Amazon Route 53 Geolocation Routing

Managed providers expose GeoDNS as a routing policy. In Route 53, you create several records with the same name and type, each with a set identifier and a location. Here's an AWS CLI change batch that creates a European record, a North American record, and a default:

{
  "Comment": "Geolocation records for www.example.com",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "SetIdentifier": "europe",
        "GeoLocation": { "ContinentCode": "EU" },
        "TTL": 300,
        "ResourceRecords": [{ "Value": "203.0.113.10" }]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "SetIdentifier": "north-america",
        "GeoLocation": { "ContinentCode": "NA" },
        "TTL": 300,
        "ResourceRecords": [{ "Value": "198.51.100.10" }]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "SetIdentifier": "default",
        "GeoLocation": { "CountryCode": "*" },
        "TTL": 300,
        "ResourceRecords": [{ "Value": "192.0.2.10" }]
      }
    }
  ]
}

Save it as geo.json and apply it:

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

The CountryCode value * is Route 53's default location, used for any query that doesn't match a more specific rule or can't be located.

Terraform

If you manage DNS as code, the same setup in Terraform uses geolocation_routing_policy blocks:

resource "aws_route53_record" "www_eu" {
  zone_id        = var.zone_id
  name           = "www.example.com"
  type           = "A"
  ttl            = 300
  records        = ["203.0.113.10"]
  set_identifier = "europe"

  geolocation_routing_policy {
    continent = "EU"
  }
}

resource "aws_route53_record" "www_default" {
  zone_id        = var.zone_id
  name           = "www.example.com"
  type           = "A"
  ttl            = 300
  records        = ["192.0.2.10"]
  set_identifier = "default"

  geolocation_routing_policy {
    country = "*"
  }
}

Other managed providers, including Cloudflare (through its load balancing product), NS1, Azure Traffic Manager and Google Cloud DNS routing policies, offer equivalent features with their own terminology. The concepts of regions, a default answer and health checks carry across.

Testing GeoDNS

Because the answer depends on where the query comes from, testing from your own machine only shows you one region's view.

Use the Client Subnet Option in dig

If your authoritative server or provider honours ECS, you can simulate clients in different places by sending a subnet with the query directly to an authoritative nameserver:

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

Look at the OPT PSEUDOSECTION in the output to see whether the server accepted the subnet:

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; CLIENT-SUBNET: 203.0.113.0/24/24

;; ANSWER SECTION:
www.example.com.    300    IN    A    203.0.113.10

The last number after the slashes is the scope prefix length. A non-zero scope tells you the server used the subnet to pick the answer. A scope of 0 means the answer is the same for everyone. Documentation ranges such as 203.0.113.0/24 won't map to a real country, so for meaningful tests substitute a real public prefix from the region you want to simulate.

Query Resolvers in Different Locations

You can also query public resolvers, or use a global DNS checking tool or a looking-glass service that runs queries from many countries, and compare the answers:

for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
  echo "== $r"
  dig @"$r" www.example.com A +short
done

Remember that each resolver's answer reflects its own location and whether it sends ECS, so differences are expected.

Limitations and Pitfalls

GeoDNS is useful, but it comes with some sharp edges:

1. Resolver location skews results: Users of distant resolvers or VPNs get routed by the resolver's location, not their own.
2. Geolocation data is imperfect: IP-to-location databases are good at country level and much less reliable at city level. Mobile and satellite networks are particularly hard to place.
3. Caching reduces precision: Resolvers cache answers for the TTL. Without ECS, one cached answer is shared by everyone using that resolver.
4. It isn't a failover mechanism on its own: If a region goes down, GeoDNS will keep sending users there unless you attach health checks so unhealthy regions are removed from answers.
5. Debugging is harder: "It works for me" means less when users in other countries see a different answer. Log which rule matched, if your server or provider supports it.
6. DNSSEC works, but plan for it: Each regional answer is a separate record set that must be signed. Managed providers handle this for you; with BIND views, each view's zone must be signed.
7. It isn't access control: Anyone can appear to be in another country. If you must block regions, enforce it at the application or edge, not only in DNS.

Choosing a TTL

Shorter TTLs, such as 60 to 300 seconds, let changes and health-check decisions take effect quickly, at the cost of more queries to your nameservers. Longer TTLs reduce load but make regional answers stickier. For most GeoDNS setups, a TTL of a few minutes is a sensible balance.

---

FAQ: GeoDNS

---

Conclusion

GeoDNS lets your authoritative nameservers answer the same question differently depending on where it comes from. By mapping the resolver's address, or the client subnet it passes along, to a country or continent, it sends users to nearby servers, regional content or compliant infrastructure without anything changing on the user's device.

It works best when you understand its limits: location is approximate, resolvers and caching blur the picture, and it needs health checks to cope with outages. Set a default answer, keep TTLs modest, test from more than one location, and GeoDNS becomes a simple and dependable way to put users closer to your servers.