Run a DNS lookup and inspect where the response came from, and you may notice something that feels impossible. The same IP address answers queries from locations all over the world. Latency is low even though the address is registered to a distant region. Traffic shifts between continents without the IP ever changing.
None of this is a DNS trick. It’s IP anycast, a routing technique that DNS leans on heavily to scale, perform, and survive failures.
The problem DNS needs to solve
DNS is a globally shared system. A recursive resolver in one country must be able to reach authoritative servers that serve users everywhere, and DNS infrastructure has to stay fast and resilient under very uneven traffic.
Give every DNS server a unique IP in a single physical location and the problems stack up: distant users eat latency, a local outage becomes a global one, and concentrated traffic gives a denial-of-service attack a single target. Solving that inside the DNS protocol would burden every client and server. DNS instead hands the problem to the routing layer.
One address, announced from many places
Anycast means multiple servers advertise the same IP address from different locations on the internet.
Each site serves the same address, and its routing infrastructure advertises the same prefix. The internet’s routing system decides which instance any given client reaches. The client sees one destination IP, while the network sees many paths to it.
The role of BGP in anycast
Anycast works only because of how the Border Gateway Protocol (BGP) handles route advertisements.
BGP allows multiple networks to advertise reachability to the same IP prefix. Routers then select among the available paths based on routing policy and topology, and nothing requires a prefix to originate from a single location. Anycast deliberately exploits this.
In an anycast deployment, sites in multiple locations each originate the same route independently. To the global routing system, there are simply multiple valid paths to one destination.
When a resolver sends a query to an anycast address, the packet follows whatever path the resolver’s upstream routers consider best. DNS is never consulted. The server doesn’t know it’s one of many instances, and the client doesn’t know which instance will answer.
Path selection follows BGP policy
Anycast is often described as “traffic goes to the closest server,” but that’s not quite right. BGP selects paths on policy, peering relationships, and topology. Geographic proximity usually falls out of those factors, but nothing guarantees it, which is why two users in the same city can reach different anycast instances and why routing can shift with no DNS change anywhere.
Failover happens through routing changes
When an anycast site’s route goes away, because the site failed outright, was withdrawn for maintenance, or health automation pulled the advertisement, routers drop that path and converge on another. Subsequent queries land at a different site with the same destination IP. The failover involves no DNS record change, though operators often use health monitoring to trigger the withdrawal.
BGP convergence isn’t instantaneous, so brief loss or delay can occur during transitions. DNS shrugs this off. Queries are stateless and clients retry as a matter of course.
Anycast versus unicast in practice
With unicast, an IP address exists in one place and all traffic goes there. With anycast, the same address exists in many places and traffic goes wherever routing currently points.
The trade is strict predictability for resilience and performance at scale.
How DNS uses anycast
Anycast is common in both authoritative and recursive DNS, from root and TLD operators to public resolver services. Operationally it means:
- A single IP address represents an entire global fleet
- Queries spread across regions automatically
- Failures are absorbed by routing changes rather than DNS logic
A resolver querying an anycast authoritative server knows only the destination IP. The network picks the instance, and the instance answers from the shared address.
The limits of anycast
Anycast gets mistaken for a load balancer or an application-level traffic director. It’s neither.
- It operates at the IP routing layer, not the DNS protocol layer
- It never inspects queries or makes per-request decisions
- It offers no session affinity
Every query is routed independently, so two successive queries from the same resolver can land on different instances if routing shifts in between. For DNS this rarely matters, since queries are stateless and answers are cacheable.
Why DNS is especially suited to anycast
The fit is unusually good. DNS queries are small and independent of one another. Most travel over UDP, so there’s no connection state to break. Every response is self-contained. Caching soaks up the repeat traffic. And when a query is lost mid-routing-change, the resolver just retries, with no long-lived session to disrupt.
Few protocols check every one of those boxes, which is why anycast and DNS have grown up together.
Anycast and the illusion of a single server
Anycast creates the illusion of a single, globally present server. In reality it’s many independent servers cooperating through the routing system.
Large-scale DNS depends on that illusion. Clients treat an IP address as a stable identity, and anycast lets that identity be backed by a distributed fleet without changing client behavior at all. That separation of responsibility is why anycast became foundational to large DNS services.
Summary
Anycast lets the same IP address be advertised from many locations, with BGP deciding which instance each client reaches. Large DNS services rely on it because they need global reach, low latency, and resilience without adding protocol complexity, and because stateless, retry-tolerant queries are a natural fit for routing-based distribution.
When the same DNS IP appears to exist everywhere, it isn’t a single server. It’s a distributed system made possible by internet routing.