Anycast DNS and GeoDNS: Speeding Up and Routing Traffic

How Anycast differs from classic Unicast DNS

In a regular (Unicast) setup, every DNS server has a unique IP address, and every resolver in the world talks to that same physical server. Anycast changes the rules: the same IP address is announced over BGP from several points of presence (PoPs) at once. Internet routers pick the nearest node by autonomous-system hop count, so a query from Frankfurt and a query from New York land on physically different servers even though both targeted the same IP.

This lowers resolution latency (RTT) and improves resilience at the same time: if one node goes down or is overloaded by DDoS traffic, BGP simply stops announcing the route through it, and traffic shifts to neighboring points with no zone change and no administrator involved.

How GeoDNS works and how it differs from Anycast

GeoDNS operates at a different layer — not packet routing, but the logic of the DNS server itself. The authoritative server determines the resolver's geographic location (from its IP or from EDNS Client Subnet, RFC 7871) and returns a different IP address for an A or AAAA query depending on the region. Anycast is the same address delivered by the shortest route. GeoDNS is different addresses for different regions, served from one logical server.

The two technologies do not compete, they complement each other: large CDNs and DNS providers announce their DNS servers over Anycast, then layer GeoDNS policies on top to route the user not just to the nearest DNS node, but to the nearest web server or content data center.

When you need Anycast versus when GeoDNS is enough

Anycast makes sense if you run several authoritative servers of your own across different networks and want resilience against a single point failure plus lower resolution latency worldwide. That requires your own ASN and an IP block — see the article on building your own authoritative server on BIND 9 for the underlying infrastructure.

GeoDNS is enough if you run one site with several content mirrors or data centers (for example in Germany, the US, and France) and the goal is to route the visitor to the geographically nearest application server. A DNS provider with GeoIP policies works fine here, or your own PowerDNS server with a GeoIP backend.

How to check whether a DNS provider actually runs Anycast

The most reliable sign of Anycast infrastructure is support for the EDNS NSID option (RFC 5001), which returns the identifier of the specific node that answered the query. Check it with:

dig @ns1.example.com example.com +nsid

If queries from different countries return different NSID values for the same server IP, you are looking at Anycast. A second method is comparing response time (RTT) from different continents through public looking-glass services: with true Anycast, RTT stays consistently low everywhere, not just near one data center.

Setting up GeoDNS policies: a practical example

A typical GeoDNS policy is described as a region-to-address mapping table:

To check which address a resolver from a specific subnet would receive, use EDNS Client Subnet:

dig @8.8.8.8 example.com +subnet=203.0.113.0/24

This query emulates a resolver serving clients from the given subnet and shows which answer the GeoDNS server considers correct for them.

Common mistakes when moving to Anycast or GeoDNS

• Forgetting to raise the low TTL before migration — see the article on DNS failover and switching to backup servers.
• GeoDNS configured only by resolver IP instead of EDNS Client Subnet — users of public DNS like 8.8.8.8 get the data center closest to Google's resolver, not to themselves.
• Anycast nodes announcing different zone versions due to replication drift — catch this by comparing the zone serial number with dig across the different servers.
• No monitoring on BGP announcements, so one node going down stays unnoticed.

Summary: a checklist for choosing a DNS scheme

Before rolling anything out, answer three questions: do you need your own ASN and BGP peering (then Anycast), do you need to route users across several data centers with different content (then GeoDNS), and are you ready to maintain both schemes at once if your infrastructure spans several countries. For most projects with one site running on several mirrors, GeoDNS from a provider with an Anycast network built in is enough — you get both benefits without building your own BGP infrastructure.