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.

Routing Priority

Edge DNS uses a 3-level hierarchy to find the best match for each user:

1 Zone (US-WEST)

→

2 Country (US)

→

3 Region (NA)

→

4 Default

A user in Los Angeles will first check for US-WEST, then US, then NA, before falling back to the default record.

Regions (Continents)

Use these region codes for continent-level routing:

Code	Region	Coverage
`NA`	North America	US, Canada, Mexico, Caribbean, Central America
`SA`	South America	Brazil, Argentina, Chile, Colombia, etc.
`EU`	Europe	UK, Germany, France, Italy, Spain, etc.
`AS`	Asia	Japan, Korea, Singapore, Thailand, Vietnam, etc.
`OC`	Oceania	Australia, New Zealand, Pacific Islands
`AF`	Africa	South Africa, Nigeria, Kenya, Egypt, etc.
`ME`	Middle East	UAE, Saudi Arabia, Israel, Turkey, etc.

Sub-Country Zones

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

🇺🇸 United States

US-WESTCA, OR, WA, NV, AZ, etc.

US-EASTNY, NJ, FL, GA, VA, etc.

US-CENTRALTX, IL, MN, MO, etc.

US-MIDWESTOH, MI, IN, KY, etc.

🇨🇦 Canada

CA-WESTBC, AB, SK, MB

CA-EASTON, QC, NB, NS

🇦🇺 Australia

AU-EASTNSW, VIC, QLD, ACT

AU-WESTWA, SA, NT

🇬🇧 United Kingdom

GB-ENGLANDEngland

GB-SCOTLANDScotland

GB-WALESWales

GB-NINorthern Ireland

🇨🇳 China

CN-NORTHBeijing, Tianjin, etc.

CN-EASTShanghai, Jiangsu, etc.

CN-SOUTHGuangdong, Hong Kong

CN-WESTSichuan, Chongqing, etc.

🇮🇳 India

IN-NORTHDelhi, Punjab, UP

IN-SOUTHKarnataka, Tamil Nadu

IN-WESTMaharashtra, Gujarat

IN-EASTWest Bengal, Bihar

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:

• User in Los Angeles → US-WEST → 64.34.80.42
• User in New York → US-EAST → 64.34.80.43
• User in Dallas → US (no zone match) → 64.34.80.41
• User in Toronto → NA (no CA entry) → 64.34.80.40
• User in Sydney → AU-EAST → 103.3.3.4
• User in Perth → AU (no AU-WEST) → 103.3.3.3
• User in Paris → EU → 185.2.2.2
• User in São Paulo → Default → 185.1.1.1

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.