--- title: "Geographic Routing" description: "Route DNS queries to different endpoints based on the geographic location of users." url: https://edge.network/docs/dns/geo-routing/ --- # Geographic Routing 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. 1 User makes request User in Tokyo visits example.com 2 DNS query routed to Edge Query arrives at nearest Edge DNS node via anycast 3 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-WEST` CA, OR, WA, NV, AZ, etc. `US-EAST` NY, NJ, FL, GA, VA, etc. `US-CENTRAL` TX, IL, MN, MO, etc. `US-MIDWEST` OH, MI, IN, KY, etc. ### 🇨🇦 Canada `CA-WEST` BC, AB, SK, MB `CA-EAST` ON, QC, NB, NS ### 🇦🇺 Australia `AU-EAST` NSW, VIC, QLD, ACT `AU-WEST` WA, SA, NT ### 🇬🇧 United Kingdom `GB-ENGLAND` England `GB-SCOTLAND` Scotland `GB-WALES` Wales `GB-NI` Northern Ireland ### 🇨🇳 China `CN-NORTH` Beijing, Tianjin, etc. `CN-EAST` Shanghai, Jiangsu, etc. `CN-SOUTH` Guangdong, Hong Kong `CN-WEST` Sichuan, Chongqing, etc. ### 🇮🇳 India `IN-NORTH` Delhi, Punjab, UP `IN-SOUTH` Karnataka, Tamil Nadu `IN-WEST` Maharashtra, Gujarat `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: ``` { "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. ## Related Topics [DNS Records Learn about record types](https://edge.network/docs/dns/records) [Metrics & Analytics Monitor geographic traffic patterns](https://edge.network/docs/dns/metrics) [Back to Docs](https://edge.network/docs) [Need help?](https://edge.network/support)