---
title: "Geographic routing"
description: "Geographic DNS routing in Edge DNS: per-record geo overrides by continent, country or sub-region, resolution priority, and EDNS Client Subnet support."
url: "https://edge.network/docs/dns/geo-routing"
section: "DNS"
---

# Geographic routing

Direct users to the nearest server or to 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.

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:

```http
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
  }
}
```

> [!NOTE]
> **Fallback behaviour.** The main `data` field is always returned for regions without a specific override.

## 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:

| 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:

| Country | Code | Coverage |
|---|---|---|
| United States | `US-WEST` | CA, OR, WA, NV, AZ, etc. |
| United States | `US-EAST` | NY, NJ, FL, GA, VA, etc. |
| United States | `US-CENTRAL` | TX, IL, MN, MO, etc. |
| United States | `US-MIDWEST` | OH, MI, IN, KY, etc. |
| Canada | `CA-WEST` | BC, AB, SK, MB |
| Canada | `CA-EAST` | ON, QC, NB, NS |
| Australia | `AU-EAST` | NSW, VIC, QLD, ACT |
| Australia | `AU-WEST` | WA, SA, NT |
| United Kingdom | `GB-ENGLAND` | England |
| United Kingdom | `GB-SCOTLAND` | Scotland |
| United Kingdom | `GB-WALES` | Wales |
| United Kingdom | `GB-NI` | Northern Ireland |
| China | `CN-NORTH` | Beijing, Tianjin, etc. |
| China | `CN-EAST` | Shanghai, Jiangsu, etc. |
| China | `CN-SOUTH` | Guangdong, Hong Kong |
| China | `CN-WEST` | Sichuan, Chongqing, etc. |
| India | `IN-NORTH` | Delhi, Punjab, UP |
| India | `IN-SOUTH` | Karnataka, Tamil Nadu |
| India | `IN-WEST` | Maharashtra, Gujarat |
| India | `IN-EAST` | West 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:

```jsonc
{
  "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 location | Match | Answer |
|---|---|---|
| Los Angeles | `US-WEST` | `64.34.80.42` |
| New York | `US-EAST` | `64.34.80.43` |
| Dallas | `US` (no zone match) | `64.34.80.41` |
| Toronto | `NA` (no `CA` entry) | `64.34.80.40` |
| Sydney | `AU-EAST` | `103.3.3.4` |
| Perth | `AU` (no `AU-WEST`) | `103.3.3.3` |
| Paris | `EU` | `185.2.2.2` |
| 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 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.

> [!TIP]
> **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 it is 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. 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.

## Next steps

- [DNS records](/docs/dns/records) — Learn about record types
- [Metrics and analytics](/docs/dns/metrics) — Monitor geographic traffic patterns