A user routed to a distant data center pays the round-trip cost on every request.
When DNS hands every user the same data center regardless of where they are, users far from that DC carry a longer network path on every single request. The extra distance shows up as higher round-trip time, slower connection establishment and a degraded experience that no amount of backend tuning at the destination can recover.
Plain country-only routing helps, but it is coarse. A user can be in the right country yet much closer to one of two in-country data centers than the other, and a national-boundary rule cannot tell them apart. Distribution that ignores proximity entirely — round-robin or random across all DCs — actively sends a fraction of users the long way around.
Outsourcing the proximity decision to an external geolocation service introduces its own problems: DNS query context leaves the organization, the decision layer depends on a third party's availability, and data-residency obligations become hard to satisfy. A critical traffic decision should not be contingent on an outside API.
There is also a correctness trap. Proximity to the nearest data center is only useful if that data center is actually healthy. Steering a user to the closest DC while it is failing is worse than sending them slightly farther to a working one.
TR7 Proximity-Based DNS Routing addresses exactly this: it picks the closest healthy data center for each requester using offline proximity data, keeping the path short without leaking query context or ignoring DC health.
Our approach
TR7 implements proximity steering through the closest selector, offline GeoIP data, client-subnet awareness and health-filtered candidate sets.
The closest selector picks the nearest candidate per query
When a DNS record uses the closest balance algorithm, GTM ranks the candidate answers by the proximity of the requester to each data center and returns the nearest one. The decision runs per query, so each requester is answered with the data center that minimizes their network distance.
Offline GeoIP databases keep the lookup on-device
Proximity is resolved from country, city and ASN databases stored locally on the appliance. The decision never sends DNS query context to an external geolocation API — geographic resolution stays inside the organization's infrastructure.
EDNS Client Subnet follows the real user, not the resolver
With EDNS Client Subnet, the proximity decision can be based on the user's actual subnet instead of the forwarding resolver's IP. This avoids steering users on public resolvers to the data center that is closest to the resolver rather than to themselves.
Unhealthy data centers leave the candidate set first
Health-check state filters the record candidates before the proximity decision runs. A failing data center is removed from the set, so the closest answer is always the nearest healthy data center — proximity never overrides availability.
Capabilities
Proximity-Based DNS Routing turns proximity into a per-query DNS decision, scoped to each record and decided locally.
Per-query closest selection shortens the network path
The closest balance algorithm evaluates each candidate record against the requesting network's location and returns the nearest data center. Because shorter geographic distance generally means lower round-trip time, users are kept on the shortest viable path to the application without any per-user configuration. The decision is recomputed for every query rather than fixed at configuration time.
Proximity is resolved from country, city and ASN data together
GTM resolves the requester's location using offline country, city and ASN databases. City-level data lets the platform distinguish between two data centers within the same country, and ASN data refines the decision by the network the requester is connected through. This is finer-grained than national-boundary routing while remaining a deterministic local lookup.
EDNS Client Subnet improves proximity accuracy
When the resolver supplies the client subnet, GTM bases the proximity decision on the user's real network location rather than the resolver's. This matters most for clients using distant public resolvers, where a resolver-only decision could send a user to a data center near the resolver instead of near the user. The closest answer follows where the user actually is.
Health filtering keeps proximity honest
Candidate records are filtered by data-center health before the closest decision is applied. An unhealthy data center is not eligible to be the nearest answer, so the platform never trades availability for proximity. When a near data center recovers, it re-enters the candidate set on the next decision automatically.
Proximity composes with topology rules
The closest selector can act as the selector inside a topology rule set, so an operator can first scope candidates by network, country, city, continent or ASN and then pick the nearest answer among the matches. This lets compliance or carrier constraints and proximity steering operate in the same decision pipeline.
Configured per DNS record, not globally
The balance algorithm is set on each DNS record. The same domain can answer one record by proximity and another by a different strategy, so proximity steering is applied exactly where it adds value and other records keep their own behavior. Operators tune routing record by record.
On-device decision with no external dependency
Both the proximity lookup and the record selection run on the appliance. There is no external geolocation API in the request path, which removes a third-party availability dependency and keeps DNS query context inside the organization. The proximity decision continues to work even when outbound connectivity to external services is unavailable.
Operational depth
Proximity steering is operated alongside the GeoIP database set, the balance-algorithm field, topology selectors, health filtering and live configuration reload.
GeoIP database set
Proximity decisions draw on three offline databases on the appliance: an ASN database, a city-level database and a country-level database. Together they support country, city and ASN-aware proximity. Because the data is local, runtime decisions do not depend on an external service; the database update flow is planned separately from the live decision path.
Balance-algorithm field
Proximity is selected by setting the record's balance algorithm to closest, one of the available DNS-record balance algorithms alongside all, first-N, round-robin, weighted round-robin, random and weighted random. The field is set per record and changes are applied through the configuration pipeline.
Topology selector composition
Inside a topology rule set, closest can be used as the selector applied to the records that match a rule. This lets proximity run after a geographic or network constraint has already narrowed the candidates, combining policy filtering with nearest-answer selection in a single record.
Health-filtered candidates
The candidate set handed to the closest decision reflects current data-center health. Records for unhealthy data centers are dropped before selection, so proximity is computed only over data centers that can actually serve traffic. This filtering is part of the decision pipeline, not a separate manual rule.
Live configuration reload
Changes to record algorithms and candidate sets enter the configuration regeneration pipeline and are applied without restarting the service. New queries receive answers reflecting the current configuration; answers already cached by clients live until their TTL expires, so lower TTLs make proximity and health changes take effect faster.
Proximity versus live network signals
The closest selector decides on geographic proximity, which serves as a proxy for latency rather than a live measurement of it. When a decision must reflect the actual real-time network path or data-center load, multi-source DC selection provides live host, service and client-path signals that complement geographic proximity steering.
When to use it
Steer global users to the nearest region
For services with users spread across regions, the closest selector answers each query with the geographically nearest data center, shortening the network path and reducing round-trip time without per-user rules.
Choose between two data centers in one country
When a country hosts more than one data center, city-level proximity distinguishes which is nearer to the requester — finer than a country-only rule that would treat both as equivalent.
Proximity steering with data residency
Because the geolocation lookup runs on offline on-device databases, organizations with data-residency or query-privacy obligations get proximity-based routing without sending DNS query context to an external geolocation provider.
Proximity inside a topology policy
Scope candidates first by country, ASN or CIDR for compliance or carrier reasons, then let the closest selector pick the nearest answer among the allowed data centers — policy and proximity in one record.
Frequently asked questions
Does TR7 GTM measure live latency from the resolver to each data center?
How is the requester's location determined?
Why use EDNS Client Subnet with proximity routing?
What stops a query being steered to the closest data center while it is down?
Can proximity routing be combined with country or ASN rules?
Is proximity routing applied to the whole zone or per record?
Keep every user on the shortest path to a healthy data center
Proximity-based DNS steering decided on your own appliances — offline GeoIP, client-subnet awareness and health filtering. Let's walk through it on your own topology.