DNS Can Do More Than Return an Address
Basic DNS behaviour is "give a name, get an address". Managed DNS services — NS1, UltraDNS and similar — turn that answer into a programmable decision point: the same name can return different addresses depending on where the query came from, measured latency to each endpoint, and current health.
That's genuinely useful for cross-border architecture: Asian users to Asian nodes, European to European, with nothing needed at the application layer. But the whole mechanism rests on an assumption that frequently doesn't hold — the third row below is where it breaks.
| Method | What it decides on | Limitation |
|---|---|---|
| Round robin | Returns each address in turn | Ignores location and health entirely |
| Weighted distribution | A preconfigured traffic ratio | Controllable split, still ignores location |
| Geographic (GeoDNS) | Location of the recursive resolver asking | Not the user's location — unless ECS is present |
| Latency-based | Measured latency to each endpoint | Measured from the resolver, not the user |
| Health-check failover | Whether an endpoint passes health checks | Switching is bounded by TTL, not immediate |
First, what each steering method actually decides on.
Three Situations That Misjudge
All three are common, and all share one property: the user and the resolver aren't in the same place.
- The user switched to a public resolver Public resolvers like 8.8.8.8 and 1.1.1.1 run on anycast, distributed globally. A user in Taiwan querying 8.8.8.8 may actually be answered from Singapore or Hong Kong, and that's the location your authoritative server sees. One line changed in their network settings defeats your geographic routing, entirely outside your control.
- Corporate resolvers centralised at headquarters Many organisations funnel DNS queries through internal resolvers at head office. So staff in the Tokyo branch generate queries originating from Taipei, and GeoDNS sends all of them to the Taipei node. Nothing looks wrong in the logs, because from the authoritative server's view those genuinely were queries from Taipei.
- Carrier and mobile network resolver placement Operator resolvers aren't necessarily deployed in the region their users occupy, which shows most in cross-border scenarios. China's three carriers each structure their resolvers differently, which is one reason the same site performs inconsistently between Telecom and Mobile users.
What ECS Fixes, and What It Doesn't
EDNS Client Subnet (ECS, specified in RFC 7871) exists for exactly this problem: the recursive resolver forwards a fragment of the user's IP subnet alongside the query, letting the authoritative server decide on the user rather than the resolver. NS1's documentation says as much — its geographic filters work best when resolvers support ECS.
It has three limits. First, not every resolver sends it — privacy concerns mean some deliberately don't, and you can't compel them. Second, it carries a subnet rather than a full address, so precision is bounded. Third, it increases caching load on the authoritative side, since one name now needs different answers per subnet.
Where geographic accuracy genuinely matters, anycast is structurally better than GeoDNS. Anycast routing happens at the network layer along the actual BGP path, reflecting where the user really is without a resolver in between. It's why CDNs generally don't rely on GeoDNS for node selection.
Health-Check Failover Is Slower Than It Looks
Managed DNS health checks detect a failed endpoint and start returning a backup address. But that switch only takes effect once the answer users already hold expires — the record's TTL. At a 300-second TTL, users can keep reaching the failed endpoint for up to five minutes.
So DNS-level failover suits outages lasting minutes or more, not second-scale high availability. For that, a load balancer or anycast network does the work instead. This follows directly from TTL behaviour, the same mechanism that governs any DNS change.
Three Levels of Assessment
When evaluating GeoDNS, work through these in order:
1. Which resolvers do your users use?
This decides how accurate GeoDNS will be for you. Consumers use public DNS heavily; corporate users often go through internal resolvers — both reduce accuracy. If users concentrate in a few regions and mostly use local carrier resolvers, accuracy is considerably higher.
2. How serious is reaching the wrong node?
If the consequence is somewhat higher latency, probabilistic accuracy is acceptable. If it involves data residency or regulatory separation — certain data not leaving a jurisdiction — GeoDNS cannot be relied on. That needs an explicit decision in the application, not a mechanism that never sees the user.
3. Are you after optimisation or failover?
The two want opposite TTLs. Optimisation prefers longer TTLs to reduce queries; failover prefers short ones to switch faster. Doing both means compromising, or handing failover to a lower layer.
Three Things to Confirm Before Configuring
These decide whether it can meet your expectations at all:
- That your provider supports ECS and it's enabled Supporting and enabling are separate; some services require switching it on explicitly. Without it, every query is judged on resolver location.
- That TTL matches your switching requirement Decide what switching delay is acceptable, then work back to a TTL. Discovering later that it's too long doesn't help — answers already handed out don't expire because you changed a setting.
- That you can verify actual behaviour Query from different regions and different resolvers and see which address comes back. Testing only from your own network always yields the same answer, which proves nothing about whether geographic routing works.
In Summary
GeoDNS's fundamental limit is that the authoritative server cannot see users, only resolvers. ECS mitigates this without eliminating it, because whether ECS is sent is the resolver's decision, not yours. As best-effort optimisation it's reasonable; as precise traffic control it will leave you unable to explain the failures.
If what you need is reliable proximity rather than a probabilistic guess, anycast fits structurally better — the routing decision happens at the network layer, along the user's real path rather than the resolver's location. Our CDN works this way, and can be deployed without connecting mainland China nodes.