How Anycast DNS Cuts Resolver Latency Without Adding Servers

Every web request starts with a DNS lookup, and that lookup happens before a single byte of your page loads. If your nameservers sit in one data center in Virginia and a user in Lagos is trying to reach you, their DNS query crosses an ocean and back before the browser even knows which server to connect to. That round trip is pure latency, paid on the very first interaction, and no amount of front-end optimisation can recover it because it happens upstream of everything you control in the page.

The intuitive fix is to add nameservers in more regions and tell DNS to hand out the closest one. That is the harder, more brittle way, and it does not actually guarantee a user reaches the near server. The better answer is anycast, where one IP address is answered from dozens of locations at once, and the network itself routes each user to the nearest one. It sounds like it should not work, one address in many places, but it is how the fast DNS providers run, and understanding why is worth the few minutes.

One IP, many locations, the network picks

In normal (unicast) routing, an IP address lives in exactly one place, and packets to it all converge there. Anycast breaks that assumption deliberately. You announce the same IP address from multiple locations, each one running a copy of your nameserver, and you let Border Gateway Protocol (BGP), the protocol that decides how traffic moves between networks on the internet, route each query to the topologically nearest instance.

Here is the mechanism. Every one of your anycast nodes advertises the same IP to its upstream routers via BGP. Those routers, and the routers beyond them, each pick the lowest-cost path to that IP. Because the address is advertised from many points, "the lowest-cost path" resolves to whichever node is closest to the user in network terms. A query from Lagos gets routed to the node nearest Lagos, a query from Frankfurt to the node nearest Frankfurt, all to the same IP address, with no logic in your DNS records and no work on the client's part. The internet's own routing does the geography for you.

The payoff is concrete. DNS resolution that took hundreds of milliseconds across a long unicast path drops to roughly 20 to 30 milliseconds with anycast, because each query is answered by the server fewest network hops away. Multiply that saving across every first-time visitor and every cold cache, and it is a meaningful chunk of perceived load time that you bought without touching your application at all, and perceived load time is exactly what every slow second actually costs you in revenue.

Why this beats a stack of regional nameservers

You could try to solve the same problem with geographically separated unicast nameservers and geo-based routing, handing out the closest one per region. It works, sort of, but it carries real disadvantages that anycast does not.

Geo-routing depends on a database mapping IPs to locations, and those databases are imperfect, so a user behind a VPN or a misclassified IP block gets sent to the wrong region. Anycast does not guess location, it follows the actual network path, which is the thing that actually determines latency. A user might be geographically near a node but network-distant from it, and anycast routes by network distance, which is the metric that matters.

Anycast also gives you resilience as a side effect of the same design. If one node fails or you take it down for maintenance, BGP simply stops seeing its route and reroutes those queries to the next-nearest node automatically. There is no failover logic to write and no DNS change to push. The same mechanism that picks the closest node also routes around a dead one, which is why anycast is the standard for DNS that has to stay up under DDoS and hardware failures alike. That kind of routing-level resilience is also what turns reliability into a competitive moat nobody can copy, and it is the upstream half of exposing an internal app publicly without opening a single port.

Verify it is actually routing close, do not assume

The trap with anycast is that it is invisible when it works and invisible when it does not. You can have an anycast IP that, due to a misconfigured BGP announcement or a bad upstream peering, routes a whole region to a distant node. The DNS still resolves, so nothing looks broken, but your users in that region are paying the latency anycast was supposed to remove. So you verify, from multiple regions, rather than trusting that "we enabled anycast" means it is working.

The basic measurement is query time. dig reports it directly:

dig @203.0.113.1 example.com
;; Query time: 24 msec

Run that from several regions, using either real machines in those regions or a measurement service that queries from many vantage points, and confirm the query time is low everywhere, not just near your home node. A region showing 180 msec when others show 25 is a routing problem worth chasing.

To confirm which physical node actually answered, use NSID (Name Server Identifier). Each node can be configured to report an identifier, and you ask for it explicitly:

dig @203.0.113.1 example.com +nsid

The response carries the responding node's ID, so you can prove that a query from Frankfurt landed on the Frankfurt node and not, say, one in Singapore. This is the difference between assuming anycast works and knowing it does. When a region is slow, NSID tells you whether the problem is the node being far or the routing sending traffic the wrong way, which are two very different fixes.

Where this fits in the bigger latency picture

Anycast DNS shortens the first step of a connection, but it is one step. The honest framing is that it removes a fixed tax you were paying on every lookup, and that tax is largest for users far from your infrastructure. If your audience is global, or growing into new regions, the DNS latency you never measured is probably worse than you think for the users farthest from your servers.

It also pairs with the rest of the edge strategy. Anycast gets the user to your nameserver fast; pushing your CDN cache hit ratio past 95 percent gets them to your content fast; both use the same one-address-many-locations idea applied to different layers. The same geographic thinking carries into routing every user to their nearest region with latency-based DNS and setting DNS TTLs so failover is instant without hammering resolvers. Getting the DNS layer right first is sensible because it gates everything after it, and because it is cheap relative to the gain.

This is the kind of infrastructure decision that is easy to get subtly wrong and easy to never notice you got wrong, which is why it sits squarely in networking work: not just turning anycast on, but verifying with dig and NSID from real vantage points that every region is genuinely routing to a near node. The same care extends to the whole connection path, which is part of broader server administration once you are running infrastructure that serves people in more than one place.

The reason to care about a number measured in tens of milliseconds is that it is paid on the very first thing every user does, before your carefully optimised page gets a chance to load. Shaving DNS from hundreds of milliseconds to tens, for the users farthest from you, is a quiet win that compounds across every visit, and it matters most for distant audiences, which is part of what most software teams get wrong about shipping to African markets. If you suspect your DNS is the slow first step for part of your audience, the measurement to settle it takes minutes, and we are happy to run it with you.