Why GeoDNS is needed when there is one address for all regions
While a service lives on one site, a single entry point looks reasonable: one address, one configuration, one set of rules.
The problem shows up when the audience is distributed — the resolver returns the same address to everyone, and some clients go through long-haul transit because the nearest site is unknown to them.
Response time for such users is noticeably higher, even though everything on your side works normally.
Degradation is measurable: connection establishment takes longer, first responses arrive more slowly, and the share of retries among mobile clients grows.
On long routes, losses at intermediate nodes are higher, and service availability begins to depend on network segments you do not control.
The second effect is fragility. A single address means that a site or channel failure in a single region brings the service down entirely until the record in resolver caches expires.
Switching at that moment is done manually, and a short TTL is not a free solution: it increases the number of queries to the domain's authoritative servers.
GeoDNS closes this at the name resolution level. The client receives the address of the site nearest to it, so traffic routing by region happens before the first request, not after.
Each zone is mapped to its own address pool, and a site failure is handled by changing weights and removing it from the response — without waiting for the cache to expire for everyone.
Next we break down how such a scheme is assembled: which zones to allocate, how to prioritize between sites, and what to do with clients whose resolver does not report its location.
What GeoDNS provides: response, resilience, and channel offload
GeoDNS returns to the client the address of the region from which the request came, rather than the single address of the central site. The request is served by the nearest region: the page and API calls travel along a short route instead of crossing half a continent.
In practice, response time is reduced severalfold, and the gain is visible on every request, not only on the first load.
The second effect is resilience. Responses are served only for live sites: if a region stops responding to checks, its addresses are removed from the response, and traffic goes to the backup circuit.
This eliminates an entire class of failures — a site outage stops being a service outage, and the client keeps working, albeit with slightly higher response time.
The third effect is channel offload. Without regional routing, all users pull data from the center, and the backbone works on intercity transit instead of useful payload.
When the nearest region serves its own clients itself, intercity traffic drops severalfold, freeing bandwidth for peaks and replication.
What we measure before and after: the share of requests that landed in the local circuit, the response distribution by region, the volume of transit between sites, and the switching time during a planned removal of a region from the response. The latter is verified by drills — we turn off a site and see whether the client noticed.
Options for routing traffic by region and their limitations
The choice of scheme comes down to two questions: how accurately traffic needs to be separated by region and what we are willing to pay for that accuracy.
Geographic binding at the record level separates clients into pools without an intermediate link, but an error in the address database sends a request to the wrong place, and intermediate caching nodes hold the old response longer than the change itself lives.
Schemes are therefore compared not by response speed, but by predictability and by how quickly an unsuccessful edit can be rolled back.
| Scheme | When it fits | Limitations |
|---|---|---|
| Records with geographic binding | One or two large regions, pool composition changes rarely | Inaccurate address detection; provider caching nodes hold the old response; each new region is a manual edit |
| Load balancer with regional pools | Several regions, health checks and fast node removal are needed | The central link becomes a point of failure; delay on the first request; harder debugging from the client side |
| Hybrid: binding plus local caching nodes | High share of repeat requests, strict response requirements in each region | More expensive to maintain; rules need consistency between layers; risk of stale data in caches |
The limitations of a scheme matter more than its advantages: almost always the choice comes down to which class of failure is cheaper for you — the wrong region, downtime of the central link, or desynchronization of rules between layers. Next we break down how we test these scenarios before switching live traffic.
How we implement georouting: work stages
Georouting starts not with editing a zone, but with understanding where users actually come from and how resolvers in each region respond to that. Below is the sequence by which we conduct implementation: from infrastructure audit to handing the working scheme over to your team.
- Infrastructure audit and region inventory. We collect current zones, records, delegation, the list of providers and points of presence. We clarify which regions need to be separated and by which attribute — country, operator, continent.
- Measurements on real resolvers. From different points, we capture which name servers return the response and how reliably the request source is determined. This shows where geographic binding works reliably and where an additional attribute is needed.
- Routing scheme design. We fix the matrix "region → address set", priorities, TTL values, and behavior when a node is unavailable. We coordinate the scheme before edits in the production zone so that changes are predictable.
- Node configuration and health checks. We deploy bindings and health checks: when a node fails, traffic goes to the backup rather than remaining on an unresponsive address. We set the target convergence time and monitor it.
- Switching verification. We conduct controlled failures: turn off a node, substitute the region attribute, and observe actual responses and cache behavior across different providers.
- Handover to operations. We hand over configurations, the scheme, the change procedure, and the rollback order. Your team sees what changes and where when adding a region, and can subsequently edit the scheme itself.
Each stage ends with an artifact: a region map, an approved matrix, or a switching report. This makes it clear what the current solution rests on and what to change when entering a new region.
What remains with you: configurations, schemes, and procedures
Development does not end with traffic switching — the customer receives a set of artifacts according to which the system lives and changes without us. Below is the list of what is handed over to the customer's team: files, schemes, and the procedure for working with them. Everything is stored in your repository, not in someone's personal folder.
- Zone and rule configurations: mapping regions to address pools, record TTL in resolver caches, separate sets for the primary and backup circuits. Any change goes through review before application.
- Region and circuit map: which region goes to which circuit, where the backup site lives, how traffic is distributed during partial unavailability. The scheme reflects reality, not the original intent.
- Switching rules: conditions for taking a node out of service, degradation thresholds, delay before changing the response, behavior when one of the communication channels fails. They are formulated so they can be verified on a test bench, not just read.
- Request routing scheme: the path from a user request to the target server, the points where the region decision is made, and the places where the response is cached.
- Change procedure: who approves an edit to the region map, in what order it is rolled out, how rollback to the previous version is performed and within what time. Plus separation of rights for test and production circuits.
- Documentation: description of zones and their owners, on-call contacts, typical scenarios — add a region, put a site into maintenance, investigate a discrepancy in responses.
- Observability: a set of metrics for resolvers and the share of responses sent to the backup circuit, with configured alerts.
Such a kit allows you to change routing on your own without restarting the project, and to understand exactly what happened when traffic behaved off plan.
Case: from a common entry point to regional circuits
Initially, all regions looked at one common record: a single node received both local and transit traffic.
When the site became unavailable, the on-call engineer manually edited the zone and waited for the record TTL to expire at resolvers — this took from half an hour to forty minutes, and all that time users saw an error.
The analysis began with measurements: we captured response time by region, calculated the share of requests going through the distant node, and recorded the manual switching time as a baseline metric.
The hypothesis was confirmed — a noticeable part of the delay came not from the code, but from the route to the single entry point.
Then we separated regional circuits: authoritative zones were moved to Cloudflare, a separate address set was described for each region, health checks and automatic traffic removal were enabled when a site went down.
The record TTL for service names was reduced so that switching fit within minutes rather than tens of minutes.
Metrics after: switching — about a minute and without on-call involvement, response time in remote regions lower by 38%, and the share of transit traffic through someone else's circuit dropped from 46% to 7%.
An entire class of failures was removed from operations — the unavailability of one node no longer means service unavailability for all regions.
Separately, we established a procedure: how a new region is connected, by what thresholds checks deem a site non-working, and how the zone configuration is rolled back. This is the transition from one entry point to a set of independent regional circuits.
What to do if routing is already configured at the provider
The situation where part of the geo rules already reside with an external vendor occurs more often than a "clean" migration: the provider retains top-level domains, some subdomains, and individual regional branches.
We start with an inventory of rules: we export all records, match them against real traffic from logs, and record which regions actually serve geo logic and which remain "for memory" from past experiments. Without this step, any switch turns into moving someone else's configuration along with its errors.
Next we define boundaries and perform partial delegation: zones where routing is critical for the product are taken under our control, while peripheral subdomains are safely left with the vendor — the branch is delegated entirely, and we do not interfere with it.
This makes the area of responsibility explicit: ours — region distribution rules, health checks, and response logs; the provider's — what we deliberately do not touch.
A zero-downtime transition is built on preparation, not speed.
We reduce record TTL in the cache in advance so that resolvers worldwide stop holding old responses, bring up the new configuration in parallel, and compare it with the current one using a sample of requests from different networks.
Only after responses match are delegation records changed, and the previous scheme remains ready for return within several hours.
Separately, we record what remains with the vendor after the transition: an emergency circuit in case our infrastructure fails or perimeter protection. This is not a compromise, but a deliberate reserve — if there is a failure, traffic can be returned to the previous scheme. Next we break down how such a hybrid scheme is maintained without manual edits.
Technical doubts before starting
Before starting, engineering teams ask approximately the same set of questions: how quickly the scheme will start switching traffic, whether we affect active clients, how we verify correctness, and who supports it afterward. Below are direct answers to the five most common ones, without generalities.
How quickly does switching between regions start working?
The speed is determined not by the control panel, but by the record TTL in resolver caches. We reduce it in advance in the required zones, so a route change is picked up within that window, and after stabilization the value is returned back.
What will active clients see at the moment of route change?
Already open sessions are not interrupted — they live on the service side, not in routing. New requests go to the target region, so in the worst case the user will receive a response from the previous site for one more cycle.
Can the scheme be tested before going to production traffic?
Yes, we bring up a test circuit: a separate zone, the same set of rules, and polling from several points. We run scenarios for region failure, health check unavailability, and geo data correction — and only then transfer the configuration.
How can we be sure that routes are served correctly?
We configure periodic polling of resolvers from different regions, comparing responses against a reference. A discrepancy arrives as a notification to the on-call shift channel, so an error is visible earlier than user complaints.
Who supports the scheme after launch?
We hand over the configuration with a description of rules, a checklist of typical changes, and role-based access. After that, the scheme can be maintained on your own or support can remain with us — the update procedure and on-call duty are fixed at the start.
Let's discuss your task: what to send for an estimate
The accuracy of estimating GeoDNS work is determined by the inputs: the scope of work for one zone with two regions and for ten points of presence with automatic node removal from the response differs severalfold.
To come back with an implementation plan and timelines rather than a "from and to" range, it is enough for us to describe the task and send the following data.
- List of domains and subdomains that need regional routing, indicating where zones are currently delegated and who manages the records.
- Region map: which countries or groups of countries are served, whether there are requirements for local presence and data storage on the territory.
- Infrastructure behind the regions: points of presence, address pools, which service receives traffic and how it is currently distributed.
- Region selection criterion: response latency, node availability, or egress cost — what we consider the priority in a conflict.
- Fault tolerance requirements: allowable switching time when a node fails, whether automatic removal of a region from the response is needed.
- Constraints: corporate policies, an external content delivery accelerator, existing records that must not be broken during migration.
Based on these inputs, we describe the scope of work: audit of the current zone, the scheme for splitting into regions and pools, switching rules, and the rollout procedure with testing on a test domain.
In the implementation plan, we record the stages, checkpoints, and the method for rolling back to the previous routing scheme — edits in the zone are made gradually, without service interruption. Describe the task and send the inputs — we will come back with a work estimate and plan.