GeoDNS
GeoDNS (also called geo-aware DNS or DNS-based traffic steering) is the practice of returning different DNS answers depending on where the query came from. A US visitor to example.com might get a US-east IP, while a European visitor gets a Frankfurt IP: both correct, both legitimate.
How it works
The authoritative nameserver inspects the IP address of the recursive resolver making the query (or, with the EDNS Client Subnet extension, the original client's subnet). It then returns the record best suited to that location based on rules you configure: closest data center, healthiest endpoint, country-specific compliance, etc.
Common providers
Cloudflare Load Balancing, AWS Route 53 traffic policies, NS1, Akamai, and most modern CDNs implement some form of GeoDNS. If you've set up "geo-routing" or "latency-based routing" in any of those, that's GeoDNS.
Worked example: split-horizon for data residency
A SaaS company runs identical app clusters in Frankfurt and Virginia. EU customers must hit the Frankfurt cluster (GDPR data residency); US customers should hit Virginia (lower latency). At the DNS layer, app.example.com is GeoDNS-routed: queries originating from European recursive resolvers (or from clients whose Client Subnet the resolver forwards) get the Frankfurt IP; queries from US resolvers get the Virginia IP. Customers never see the routing logic — they just type the URL.
This works because of the same recursive-resolver topology that normally causes caching headaches: the authoritative server can tell roughly where a resolver lives, and (with ECS) roughly where its client lives.
EDNS Client Subnet (ECS): the catch
Without ECS, the only signal the authoritative server has is the resolver's own IP. If a user in Munich uses Google DNS, the query might be processed by Google's Belgium pop — the authoritative server sees "Belgium," returns the Frankfurt IP, and that's fine. But if the same user is using a niche resolver whose only POP is in Virginia, the authoritative server sees "Virginia" and returns the Virginia IP. The user gets transatlantic latency for no reason.
ECS solves this by forwarding the client's subnet (anonymized to /24 IPv4 or /48 IPv6 usually) along with the query. Cloudflare's 1.1.1.1 does not send ECS by default (a privacy choice); Google's 8.8.8.8 does. This is why some sites perform better on Google DNS than Cloudflare DNS for the same user.
Verify on WhereIsDNS
Run a lookup through WhereIsDNS for an A record on a GeoDNS-routed hostname. The 14 resolvers are deliberately spread across regions (US, EU, Russia, China). If they return different IPs that all belong to your service, GeoDNS is working as intended. If they all return the same IP, either GeoDNS is misconfigured, the resolvers aren't sending Client Subnet, or only one POP is healthy.
GeoDNS results aren't a propagation problem
This is the single biggest source of false alarms on propagation checkers. Split consensus that matches the expected geography is the system working correctly. Don't "fix" it.