Geographic routing

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.

1. User makes a request. A user in Tokyo visits example.com.
2. DNS query is routed to Edge. The query arrives at the nearest Edge DNS node via anycast.
3. Location is determined. Edge identifies the resolver as being in Japan/Asia.
4. Region-specific response. Edge returns the IP of the Tokyo data centre instead of the default.

Use cases#

• Latency optimisation: route users to the nearest data centre for faster response times. Reduce round-trip latency by serving from local regions.
• Load distribution: spread traffic geographically across multiple data centres. 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. For example, to add a record with geo routing via the 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
  }
}

Routing priority#

Edge DNS uses a three-level hierarchy to find the best match for each user, before falling back to the default:

1. Zone (e.g. US-WEST)
2. Country (e.g. US)
3. Region (e.g. NA)
4. Default

A user in Los Angeles is first matched against US-WEST, then US, then NA, before falling back to the default record.

Regions (continents)#

Use these region codes for continent-level routing:

Sub-country zones#

For large countries, route by sub-region for even lower latency:

Also supported: BR-SOUTH, BR-NORTH (Brazil), RU-WEST, RU-EAST (Russia), DE-NORTH, DE-SOUTH (Germany).

Complete example#

Combine zones, countries and regions for maximum control:

{
  "type": "A",
  "name": "cdn",
  "data": "185.1.1.1",           // Default fallback
  "geo": {
    // Regions (broadest)
    "NA": "64.34.80.40",         // North America default
    "EU": "185.2.2.2",           // Europe
    "AS": "103.1.1.1",           // Asia

    // Countries (more specific)
    "US": "64.34.80.41",         // United States
    "JP": "103.2.2.2",           // Japan
    "AU": "103.3.3.3",           // Australia

    // Zones (most specific)
    "US-WEST": "64.34.80.42",    // US West Coast
    "US-EAST": "64.34.80.43",    // US East Coast
    "AU-EAST": "103.3.3.4"       // Sydney region
  }
}

Resolution examples:

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 that 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), so we can route based on the end user’s location as well as the resolver’s.

When ECS is not available (e.g. with 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 are routed based on the resolver’s location.
• GeoIP accuracy: location data is generally accurate to country level, but city-level precision is not guaranteed.
• VPN users: users connecting via a VPN are routed based on their VPN exit node location, which may differ from their physical location.