Advanced

Geographic Routing

Direct users to the nearest server or region-specific content by routing DNS queries based on the geographic location of the resolver.

How It Works

When a DNS query reaches Edge DNS, we determine the geographic location of the requesting resolver using GeoIP data. Based on your routing rules, we return different IP addresses or hostnames for different regions.

User makes request

User in Tokyo visits example.com

DNS query routed to Edge

Query arrives at nearest Edge DNS node via anycast

Location determined

Edge identifies resolver as being in Japan/Asia

✓

Region-specific response

Returns IP of Tokyo datacenter instead of default

Use Cases

Latency Optimization

Route users to the nearest datacenter for faster response times. Reduce round-trip latency by serving from local regions.

Load Distribution

Spread traffic across multiple datacenters geographically. Prevent overload on any single location.

Regional Content

Serve region-specific versions of your site. Direct EU users to GDPR-compliant servers, for example.

Data Sovereignty

Keep user data within specific geographic boundaries by routing to region-locked infrastructure.

Configuring Geographic Routing

Add geographic overrides to any record by specifying region-specific values:

# Add record with geo routing via API

POST /api/dns/zones/:id/records
{
  "type": "A",
  "name": "@",
  "data": "185.1.1.1",        // Default (fallback)
  "ttl": 300,
  "geo": {
    "NA": "185.2.2.2",        // North America
    "EU": "185.3.3.3",        // Europe
    "AS": "185.4.4.4"         // Asia
  }
}

Fallback Behavior

The main data field is always returned for regions without a specific override.

Supported Regions

Use these region codes in your geo routing configuration:

Code	Region	Coverage
`NA`	North America	United States, Canada, Mexico
`SA`	Latin America	Central & South America, Caribbean
`EU`	Europe	Western, Eastern, Northern Europe
`MEA`	Middle East & Africa	Middle East, North & Sub-Saharan Africa
`AS`	East & Southeast Asia	Japan, Korea, Singapore, Thailand, etc.
`SA_OC`	South Asia & Oceania	India, Australia, New Zealand, Pacific
`CN`	China	Mainland China (special routing)

Country-Level Routing

For more granular control, you can also route by ISO country code:

{
  "type": "A",
  "name": "api",
  "data": "185.1.1.1",
  "geo": {
    "US": "185.2.2.2",        // United States
    "GB": "185.3.3.3",        // United Kingdom
    "DE": "185.3.3.3",        // Germany (same as UK)
    "JP": "185.4.4.4",        // Japan
    "AU": "185.5.5.5"         // Australia
  }
}

Resolution Priority

Country codes take precedence over region codes. If a user is in the US and you have both US and NA defined, the US value is used.

Best Practices

Always set a default

The main data field should always contain a valid value for regions not covered by your geo rules.

Use regions for broad coverage

Start with region codes (NA, EU, AS) rather than individual countries. Add country overrides only when needed.

Monitor with metrics

Use the geographic breakdown in zone metrics to verify traffic is being routed as expected.

Test from multiple locations

Use tools like dig from different regions or online DNS checkers to verify your geo routing works as expected.

EDNS Client Subnet Support

Edge DNS fully supports EDNS Client Subnet (ECS), which allows us to route based on the actual user's location, not just the resolver's location.

User-based routing when ECS is present

Major DNS resolvers including Google (8.8.8.8), Cloudflare (1.1.1.1), and OpenDNS send ECS data. When present, Edge DNS uses the client subnet for geographic decisions, providing accurate routing based on the end user's actual location.

When ECS is not available (e.g., privacy-focused resolvers), we fall back to the resolver's IP address for geographic determination.

Considerations

Privacy-focused resolvers: Some resolvers (like Quad9 with privacy mode) don't send ECS data. Users of these services will be routed based on the resolver's location.
GeoIP accuracy: Location data is generally accurate to the country level, but city-level precision is not guaranteed.
VPN users: Users connecting via VPN will be routed based on their VPN exit node location, which may differ from their physical location.