← Back

EDNS Client Subnet doesn't do what you think it does

What ECS is sold as, what it actually is, and what to do instead.

Every DNS provider with geo-routing has a slide that says "ECS-aware". The implication is that thanks to EDNS Client Subnet (RFC 7871), the authoritative server sees where your end user actually is, not where their recursive resolver happens to live, and can return the geographically-optimal answer.

That's true about 30% of the time. The other 70% it's a useful fiction. If you're picking a DNS provider partly on this feature, it's worth understanding why.

What ECS does on paper

Without ECS, an authoritative DNS server only knows the IP of the recursive resolver that asked. For most of the internet, that's a Google (8.8.8.8) or Cloudflare (1.1.1.1) IP, or your ISP's resolver, and none of those tell you anything useful about where the actual end user is sitting.

ECS lets the resolver attach a fragment of the client's IP, typically the first 24 bits of an IPv4, to the upstream query. The authoritative sees "this end user is somewhere in 203.0.113.0/24" and can give a geo-aware answer.

What goes wrong in production

Four things, in roughly decreasing order of how much they break geo-routing in practice:

1. Cloudflare 1.1.1.1 does not send ECS

Cloudflare's public resolver is one of the two or three most-used resolvers on the planet. By default, it does not forward ECS upstream, citing user privacy. Cloudflare argues that 1.1.1.1's anycast deployment is dense enough that the resolver IP is already close to the user, so geo-routing without ECS still works "well enough".

That's plausible for some workloads. It's not how a geo-routing engineer expects this to behave. If your largest customer cohort is on a 1.1.1.1-using mobile carrier or default-Mac home network, your "ECS-aware geo" decisions are quietly falling back to "wherever Cloudflare's resolver POP happens to be".

2. Google 8.8.8.8 sends ECS but with redacted bits

Google does send ECS by default, but only with a /24 (IPv4) or /56 (IPv6) prefix. That's enough for continent-level accuracy. For country-level it's mostly fine. For city-level or "is this end user inside our corporate VPN range" it's not enough.

Worse, Google's policy on which queries get ECS is opaque. Some auth servers see it, some don't, for reasons that aren't documented.

3. The resolver-chain hop matters

Many corporate networks run their own internal recursive resolver that forwards to 8.8.8.8 or 1.1.1.1. That internal resolver almost never adds ECS. So even if the upstream resolver would honor ECS, the corporate one stripped it before forwarding.

Some ISPs do the same, they run a local resolver that forwards to a public one and don't bother with ECS. From the authoritative's point of view, the query looks like it came from the ISP's resolver IP. Geo-routing falls back to that.

4. The /24 fallacy

Even when ECS arrives intact at the authoritative, the /24 prefix it carries is just the first 24 bits of the client's IPv4. There's no guarantee that range is in one geographic location. Mobile carriers, in particular, route huge ranges through a single national anchor, so a /24 that "contains the client" can span the entire country.

ECS gives you "the user is somewhere in this /24". It does not give you "the user is at this geolocation". The IP-to-geo step still happens on the authoritative server, using the same GeoIP databases that already have country-level accuracy but city-level uncertainty.

What this means in practice

Geo-DNS works. ECS is a useful (sometimes) supplement to it. But the right framing is:

Continent-level accuracy is reliable. EU users get the EU endpoint, NA users get the NA one, Asia users get the Asia one. Both with and without ECS, the resolver's POP gives you that.
Country-level accuracy is mostly reliable. A user in Germany on 1.1.1.1 might get the Frankfurt POP or the Amsterdam one. Both are close enough for almost every workload.
City- or carrier-level accuracy via DNS is not. If you need that, put a CDN or an anycast load balancer in front and let the network layer route, not DNS.

How aigw handles it

aigw GEO records resolve the client to a continent code from either the ECS-supplied subnet (when present) or the source IP of the query. We don't pretend ECS is always there. The GEO record envelope has a per-continent map plus a default fallback, if we can't determine the continent (genuinely-unknown IP, no ECS, missing GeoIP entry), we serve the default.

For workloads that need finer routing, a GEO record (per-continent, not dependent on a precise client IP) covers most "send users to the nearest region" cases honestly. For true client-latency routing, the only approaches that actually measure the client, rather than the resolver, are anycast with BGP, or RUM beacons. We're candid about that: aigw does geo + health-checked pools, not RTT-based steering.