GeoDNS: Location-Based DNS Routing
4 min read
## The Geographic Routing Problem
When you serve a global audience from a single server, users on the other side of the planet experience high latency. The solution is geographic distribution — multiple server instances, each close to a subset of users. The challenge is directing each user to their nearest instance without requiring them to visit different URLs.
GeoDNS solves this transparently at the DNS layer. The Authoritative DNS Server server inspects the source IP of the DNS query, maps it to a geographic location using a GeoIP database, and returns an IP Address corresponding to the closest server. The user visits `www.example.com` and receives the IP of a server in Frankfurt; a user in Singapore visits the same URL and receives the Singapore server's IP. The application is identical; only the DNS answer differs.
## How GeoIP Resolution Works
GeoDNS requires a mapping from IP ranges to geographic regions. Providers maintain proprietary databases — MaxMind GeoIP2, IPinfo, or their own — that assign each IPv4/IPv6 prefix to a country, region, city, and sometimes a latitude/longitude centroid.
The resolution pipeline:
1. Recursive DNS Resolver queries the authoritative GeoDNS server
2. Authoritative server reads the source IP of the incoming query
3. Looks up that IP in the GeoIP database → "Netherlands, Europe"
4. Matches against routing rules → return EU endpoint IP
5. Sends the answer with appropriate TTL (Time To Live)
The catch: the source IP the authoritative server sees is the recursive resolver's IP, not the end user's IP. A user in Amsterdam using Google's `8.8.8.8` resolver (whose query might arrive from a Google PoP in Frankfurt) will be correctly routed. But a user in remote Siberia whose ISP uses a resolver located in Moscow will be routed as if they are in Moscow.
## EDNS Client Subnet (ECS)
EDNS Client Subnet (RFC 7871) addresses the resolver IP problem. With ECS, the recursive resolver includes a truncated version of the client's IP address in the DNS query — enough for geographic mapping but not full identification (typically the first /24 of the IPv4 address, /56 of IPv6).
When the authoritative GeoDNS server receives an ECS-enabled query, it uses the client subnet rather than the resolver IP for geolocation. Google's `8.8.8.8`, Cloudflare's `1.1.1.1`, and most major ISP resolvers support ECS.
```bash
# Test ECS with dig
dig +subnet=203.0.113.0/24 www.example.com @ns1.provider.com
# Check if a resolver sends ECS
dig CHAOS TXT whoami.ds.afilias-analog.info
```
DNS-over-HTTPS (DoH) resolvers have varying ECS support. Cloudflare's DoH resolver strips ECS by default for privacy; Google's DoH forwards it. This matters for GeoDNS accuracy — DoH users behind a privacy-preserving resolver may experience suboptimal routing.
## Implementing GeoDNS
### Using a Managed Provider
Most enterprise Managed DNS providers support GeoDNS natively:
**AWS Route 53 Geolocation Routing**: Match on continent, country, or US state. Define catch-all rules for unmatched regions.
```
Rule: Country = DE, FR, NL → 203.0.113.10 (eu-west-1)
Rule: Country = JP, KR, SG → 203.0.113.20 (ap-northeast-1)
Default: → 203.0.113.1 (us-east-1)
```
**Cloudflare Load Balancing with Geo Steering**: Map Cloudflare regions (WEUR, EEUR, APAC, etc.) to origin server pools.
**NS1 Filter Chain**: Build composable routing rules — GeoIP filter → weighted filter → health-check filter — applied sequentially.
### Self-Hosted GeoDNS with PowerDNS
```python
# PowerDNS with GeoIP module (pdns.conf)
# geoip-database=/usr/share/GeoIP/GeoLite2-City.mmdb
# geoip-zones-dir=/etc/pdns/geoip-zones/
# /etc/pdns/geoip-zones/example.com.yaml
domains:
- domain: example.com
ttl: 60
records:
www.example.com:
- for:
continent: eu
answer: "203.0.113.10"
- for:
continent: as
answer: "203.0.113.20"
- default: "203.0.113.1"
```
PowerDNS's GeoIP backend supports MaxMind GeoIP2 databases and can route by continent, country, region, city, or AS number.
## GeoDNS for Multi-CDN Traffic Management
Large platforms use GeoDNS to distribute traffic across multiple CDN (Content Delivery Network) providers, balancing cost, performance, and risk. A typical multi-CDN setup:
- 60% of traffic → Cloudflare (global coverage)
- 30% → Fastly (specific regions where Fastly outperforms)
- 10% → AWS CloudFront (fallback)
GeoDNS maps regions to preferred CDN CNAME targets. Combined with health-check-based failover, if one CDN degrades (as measured by synthetic monitoring), traffic automatically shifts to the next-preferred provider.
## Limitations and Trade-offs
**GeoIP accuracy**: GeoIP databases are imperfect. VPN users, satellite internet (Starlink users appear in US regardless of physical location), and mobile users roaming internationally may be misrouted. Plan for graceful degradation — your application must work from any regional endpoint, not just the "optimal" one.
**TTL (Time To Live) and routing agility**: Because GeoDNS depends on DNS caching, routing changes take effect slowly. If a regional server fails and you update GeoDNS to exclude its IP, users who cached the old record will continue attempting to reach the failed server for up to TTL seconds. Short TTLs (30–60 seconds) are essential for routing that requires rapid change.
**Complexity**: GeoDNS adds a layer of state to your DNS configuration. It must be synchronized with your infrastructure — when you add a new region, update GeoDNS; when you decommission one, remove it immediately. Stale GeoDNS entries pointing to decommissioned servers are a common cause of regional outages.
See Anycast DNS: How Global DNS Networks Work for the BGP-layer alternative to GeoDNS, and DNS Failover and Load Balancing for health-check-based failover configurations.
DNS Record Helper