DNS Infrastructure & Operations Introductory 8 min read

Anycast and DNS: Why the Same IP Exists Everywhere

An explanation of how IP anycast works, why it is heavily used in DNS infrastructure, and what it means operationally when the same address appears to exist in many places at once.

Updated January 23, 2026

If you run a DNS lookup and inspect where the response came from, you may notice something that feels impossible. The same IP address appears to answer queries from locations all over the world. Sometimes latency is low even though the address is registered to a distant region. Other times traffic shifts without the IP ever changing.

This behavior is not a DNS trick. It is the result of IP anycast, a routing technique that DNS relies on heavily to scale, perform well, and survive failures.

This article explains how anycast works at the network layer, how it depends on internet routing, and why DNS is especially well suited to it.

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. At the same time, DNS infrastructure needs to be fast, resilient, and able to absorb very uneven traffic patterns.

If every DNS server had a unique IP address in a single physical location, you run into problems: latency increases for distant users, local outages take the service offline globally, and traffic concentration makes denial of service attacks easier. Solving these problems inside the DNS protocol would add complexity to every client and server. Instead, DNS relies on the routing layer to do this work.

What anycast actually means

In simple terms, anycast means multiple servers advertise the same IP address from different locations on the internet.

Each of those servers is configured identically at the IP level. They all announce reachability to the same IP prefix, which contains the shared address. The internet’s routing system then decides which instance a given client will reach.

From the client’s point of view, there is only one destination IP. From the network’s point of view, there are many possible paths to that IP.

Did you know?
The DNS root server system was one of the earliest large-scale anycast deployments. Each root server identity is backed by many globally distributed instances that all share the same IP addresses.

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. When this happens, routers select one of the available paths based on routing policy and topology. There is no requirement that a prefix be advertised from a single location.

Anycast deliberately takes advantage of this behavior.

In an anycast deployment, identical DNS servers in multiple locations advertise the same IP prefix into BGP. Each site originates the route independently. From the perspective of the global routing system, there are now multiple valid paths to the same destination address.

Diagram showing how BGP anycast routing works - multiple servers advertise the same IP prefix and routers select the best path based on routing policy
Multiple anycast sites advertise the same IP prefix into BGP, and routers select the best available path for each query.

When a resolver sends a DNS query to an anycast address, the packet is forwarded along the path that the resolver’s upstream routers consider best. That decision is made entirely by BGP and the routing policy of the networks involved.

DNS itself is not aware of this process. The DNS server does not know whether it is one of many instances, and the client does not know which instance will answer.

Standards reference
Operational use of anycast services and their interaction with routing is discussed in RFC 4786.

Path selection is policy driven, not geographic

A common misconception is that anycast always sends traffic to the physically closest server. In reality, BGP selects paths based on policy, peering relationships, and network topology.

Geographic proximity often aligns with these factors, but it is not guaranteed. This is why two users in the same city can sometimes reach different anycast instances, and why routing can change without any DNS configuration updates.

Failover happens through routing changes

When an anycast site goes offline or is taken out of service, it stops advertising the prefix into BGP. Routers withdraw that path and select an alternate one. Subsequent DNS queries are delivered to a different site using the same destination IP.

This failover is handled entirely by the routing system. There is no DNS level health check or redirection involved.

Because BGP convergence is not instantaneous, brief packet loss or delay can occur during these transitions. DNS tolerates this well because queries are stateless and retries are expected behavior.

Anycast versus unicast in practice

With unicast addressing, an IP address exists in one place. Traffic always flows to that specific location, regardless of where the client is.

With anycast addressing, the same IP address exists in many places. Traffic flows to whichever instance the routing system selects at that moment.

Diagram comparing unicast and anycast routing - unicast shows all traffic going to one server location, while anycast shows traffic distributed to the nearest server instance
Unicast routes all traffic to a single location, while anycast distributes traffic to the nearest available instance of the same IP address.

This distinction matters operationally. Anycast trades strict predictability for resilience and performance at scale.

How DNS uses anycast

Most large-scale DNS operators deploy authoritative and recursive servers using anycast.

From an operational perspective, this means:

  • A single IP address represents an entire global fleet
  • Queries automatically spread across regions
  • Failures are handled by routing changes rather than DNS logic

When a recursive resolver sends a query to an anycast authoritative server, it does not know which physical machine will answer. It only knows the destination IP. The network delivers the packet to one instance, and that instance responds from the same address.

Case example
A resolver in Germany sends a query to an authoritative server IP. Under normal conditions, BGP routes the packet to a nearby European site. If that site is withdrawn for maintenance, routing shifts and the same query is answered by another region without changing the destination address.

What anycast does not do

Anycast is often misunderstood as a load balancer or an application level traffic director. It is neither.

Important limitations to understand:

  • Anycast operates at the IP routing layer, not at the DNS protocol layer
  • It does not inspect queries or make per request decisions
  • It does not guarantee session affinity

Each DNS query is routed independently. Two successive queries from the same resolver may reach different instances if routing changes in between.

This is usually acceptable for DNS because queries are stateless and responses are cacheable.

Why DNS is especially suited to anycast

DNS works unusually well with anycast because of several protocol characteristics. Queries are small and independent, UDP is commonly used which reduces connection state, responses are self contained, and caching absorbs repeat traffic. If a query is lost during a routing change, the resolver simply retries. There is no long lived session to disrupt.

These properties allow DNS operators to rely on routing behavior without exposing complexity to clients.

Anycast and the illusion of a single server

Anycast creates the illusion of a single, globally present server. In reality, it is many independent servers cooperating through the routing system.

DNS relies on this illusion. Clients are designed to treat an IP address as a stable identity. Anycast allows that identity to be backed by a distributed system without changing client behavior.

This separation of responsibility is why anycast has become foundational to DNS infrastructure.

Summary

Anycast allows the same IP address to be advertised from many locations at once. BGP selects which instance a client reaches based on routing policy and topology.

DNS relies on anycast because it needs global reach, low latency, and high resilience without adding protocol complexity. DNS queries are stateless and tolerant of retries, making them a natural fit for routing based distribution.

When the same DNS IP appears to exist everywhere, it is not a single server. It is a distributed system made possible by internet routing.