If your audience is global but you’re serving everyone the same content from the same place, you're likely sacrificing performance and resilience. Gcore DNS (which includes a free-forever plan and enterprise-grade option) offers a straightforward way to change that with geo-aware routing, a feature that lets you return different DNS responses based on where users are coming from.
This article breaks down how Gcore's geo-routing works, how to set it up using the GeoDNS preset in dynamic response mode, where it shines, and when you might be better off with a different option. We’ll walk through three hands-on use cases with real config examples, highlight TTL trade-offs, and call out what developers need to know about edge cases like resolver mismatch and caching delays.
What is geo-aware DNS routing?
Gcore DNS lets you return different IP addresses based on the user’s geographic location. This is configured using dynamic response rules with the GeoDNS preset, which lets you match on continent, country, region, ASN, or IP/CIDR. When a user makes a DNS request, Gcore uses the resolver’s location to decide which record to return.
You can control traffic to achieve outcomes like:
- Directing European users to an EU-based CDN endpoint
- Sending users in regions with known service degradation to a fallback instance
Behind the scenes, this is done by setting up metadata pickers and specifying fallback behavior.
For step-by-step guidance, see the official docs: Configure geo-balancing with Dynamic response.
How to configure GeoDNS in Gcore DNS
To use geo-aware routing in Gcore DNS, you'll configure a dynamic response record set with the GeoDNS preset. This lets you return different IPs based on region, country, ASN, or IP/CIDR metadata.
Basic steps
- Go to DNS → Zones in the Gcore Customer Portal. (If you don’t have an account, you can sign up free and use Gcore DNS in just a few clicks.)
- Create or edit a record set (e.g., for
app.example.com
). - Switch to Advanced mode.
- Enable Dynamic response.
- Choose the GeoDNS preset.
- Add responses per region or country.
- Define a fallback record for unmatched queries.
For detailed step-by-step instructions, check out our docs.
Once you’ve set this up, your config should look like the examples shown in the use cases below.
Common use cases
Each use case below includes a real-world scenario and a breakdown of how to configure it in Gcore DNS. These examples assume you're working in the DNS advanced mode zone editor with dynamic response enabled and the GeoDNS preset selected.
The term “DNS setup” refers to the configuration you’d enter for a specific hostname in the Gcore DNS UI under advanced mode.
1. Content localization
Scenario: You're running example.com
and want to serve language-optimized infrastructure for European and Asian users. This use case is often used to reduce TTFB, apply region-specific UX, or comply with local UX norms. If you're also localizing content (e.g., currency, language), make sure your app handles that via subdomains or headers in addition to routing.
Objective:
- EU users →
eu.example.com
- Asia users →
asia.example.com
- All others →
global.example.com
DNS setup:
Host: www.example.com
Type: A
TTL: 120
Dynamic response: Enabled
Preset: GeoDNS
Europe → 185.22.33.44 # EU-based web server
Asia → 103.55.66.77 # Asia-based web server
Fallback → 198.18.0.1 # Global web server
2. Regional CDN failover
Scenario: You’re using two CDN clusters: one in North America, one in Europe. If one cluster is unavailable, you want traffic rerouted regionally without impacting users elsewhere. To make this work reliably, you must enable DNS Healthchecks for each origin so that Gcore DNS can automatically detect outages and filter out unhealthy IPs from responses.
Objective:
- North America →
na.cdn.example.com
- Europe →
eu.cdn.example.com
- Each region has its own fallback
DNS setup:
Host: cdn.example.com
Type: A
TTL: 60
Dynamic response: Enabled
Preset: GeoDNS
North America → 203.0.113.10 # NA CDN IP
Backup (NA region only) → 185.22.33.44 # EU CDN as backup for NA
Health check → Enabled for 203.0.113.10 with HTTP/TCP probe settings
Europe → 185.22.33.44 # EU CDN IP
Backup (EU region only) → 203.0.113.10 # NA CDN as backup for EU
Health check → Enabled for 185.22.33.44
Note: Multi-level fallback by region isn’t supported inside one rule set—you need to separate them to keep routing decisions clean.
3. Traffic steering for compliance
Scenario: You need to keep EU user data inside the EU for GDPR compliance while routing the rest of the world to lower-cost infrastructure elsewhere. This approach is useful for fintech, healthcare, or regulated SaaS workloads where regulatory compliance is a challenge.
Objective:
- EU users → EU-only backend
- All other users → Global backend
DNS setup:
Host: transactions.example.com Type: A TTL: 300 Dynamic response: Enabled Preset: GeoDNS Europe → 185.10.10.10 # EU regional API node Fallback → 198.51.100.42 # Global API node
Edge cases
GeoDNS works well, but it’s worth keeping in mind a few edge cases and limitations when you get set up.
- Resolver location ≠ user location
By default, Gcore uses ECS (EDNS Client Subnet) for precise client subnet geo-balancing. If ECS isn’t present, resolver IP is used, which may skew location (e.g., public resolvers, mobile carriers). ECS usage can be disabled in the ManagedDNS UI if needed. - Caching slows failover
Even if your upstream fails, users may have cached the original IP for minutes. Fallback + TTL tuning are key. - No sub-regional precision
You can route by continent, country, or ASN—but not city. City-level precision isn’t currently supported.
Gcore delivers simple solutions to big problems
Geo-aware routing is one of those features that quietly solves big problems, especially when your app or CDN runs globally. With Gcore DNS, you don’t need complex infrastructure to start optimizing traffic flow.
Geo-aware routing with Gcore DNS is a lightweight way to optimize performance, localize content, or handle regional failover. If you need greater precision, consider pairing GeoDNS with in-app geolocation logic or CDN edge logic. But for many routing use cases, DNS is the simplest and fastest way to go.
Related articles
Subscribe to our newsletter
Get the latest industry trends, exclusive insights, and Gcore updates delivered straight to your inbox.