What is Anycast DNS and how does it improve performance?

Sajjad
DNS
10 Oct, 2026

Anycast DNS is a way of running DNS servers where the same IP address is announced from many locations around the world at once, and the internet's routing system delivers each query to whichever location is nearest in network terms. Instead of every resolver in the world sending queries to one server in one data centre, a resolver in London reaches a server in London and a resolver in Singapore reaches one in Singapore, all using the same address. That cuts response times, spreads load and attack traffic across many sites, and keeps DNS working when a single location fails, because traffic simply flows to the next-nearest one.

Anycast is the reason the DNS root, top-level domains, public resolvers such as 1.1.1.1 and 8.8.8.8, and almost every serious managed DNS provider can answer quickly from anywhere. In this article you'll learn how anycast differs from ordinary unicast routing, how BGP makes it work, the specific ways it improves performance and resilience, where it falls short, and how to see anycast in action with dig. You'll also see what it takes to run anycast yourself.

Unicast Versus Anycast

Most IP addresses are unicast: one address belongs to one machine, or one cluster, in one place. Every packet sent to that address travels to that single location, however far away the sender is.

With anycast, one address is configured on many servers in many locations. Each location tells the internet "I can reach this address". Routers pick the best path according to their routing tables, and the packet ends up at one of those servers, normally the closest one from the sender's network point of view.

	Unicast DNS	Anycast DNS
Locations per IP address	One	Many
Where a query goes	Always the same server	The nearest announcing location
Latency for distant users	High	Low, if a nearby location exists
Effect of a site outage	That IP is unreachable	Traffic moves to another site
DDoS impact	Concentrated on one site	Spread across all sites
Operational complexity	Low	Higher: needs BGP, an ASN and IP space

There's also GeoDNS, which is sometimes confused with anycast. GeoDNS gives different answers depending on where the query comes from, while anycast gives the same answer but routes the packets to different servers. Many providers use both: anycast for their nameservers, and GeoDNS for the records they serve.

How Anycast Works With BGP

The internet is made up of tens of thousands of independent networks, each called an autonomous system (AS) and identified by an AS number. They exchange information about which IP address blocks they can reach using the Border Gateway Protocol (BGP).

An anycast DNS operator does the following:

Gets an IP prefix and an AS number: For example, the IPv4 block 203.0.113.0/24 and an IPv6 block from 2001:db8::/32.
Deploys DNS servers in many locations: Each site runs identical DNS software serving identical zone data, with the anycast address configured on a loopback interface.
Announces the same prefix from every site: Each site's routers advertise 203.0.113.0/24 to the local transit providers and internet exchange peers.
Lets BGP choose: Every network on the internet now sees several paths to the prefix and picks one, typically the one with the shortest AS path and the best local preference.
Serves queries locally: A resolver sending a query to 203.0.113.53 reaches whichever site its network's routing prefers, and gets the answer from there.

"Nearest" Means Network Distance

BGP doesn't know about geography. It picks routes based on AS path length, the network's own policies and commercial relationships. Usually that correlates well with physical distance, but not always. A resolver in Paris might be routed to Frankfurt rather than a server in Paris if its ISP doesn't peer with the provider in Paris. Large anycast operators put a lot of effort into peering widely at internet exchanges so that routing matches geography as closely as possible.

What Happens When a Site Fails

Each anycast site runs health checks on its own DNS service. If the service stops answering, the site withdraws its BGP announcement. Within seconds to a few minutes, routers across the internet remove that path and send traffic to the next-best site. Resolvers keep using the same IP address and usually never notice.

How Anycast Improves DNS Performance

Lower Latency

The biggest win is shorter round trips. A unicast nameserver in a single region might take 150 to 250 ms to reach from the other side of the world. An anycast network with a location on every continent can often answer most resolvers within 10 to 30 ms. Because a DNS lookup sits at the very start of every connection, that saving matters for the first visit to a site and for every uncached lookup after that.

Load Distribution

Each site only handles queries from its own catchment, the part of the internet that routes to it. Load is naturally spread across all sites, so no single location has to be sized for the world's entire query volume.

DDoS Resilience

DNS is a common target for distributed denial of service attacks. With unicast, all attack traffic converges on one location and can overwhelm it. With anycast, attack traffic from a botnet spread around the world is split across many sites by the same routing that splits legitimate traffic. Each site absorbs a fraction of the attack, and if one location is overwhelmed, the others keep serving their own regions. The DNS root has weathered large attacks over the years largely because of anycast.

High Availability

Because a failed site withdraws its route, anycast provides failover at the network level. That's in addition to DNS's own redundancy, where resolvers try another nameserver from your NS records if one doesn't answer. Combining the two gives very high availability.

Simple Configuration for Users

Users and resolvers configure one address, such as 1.1.1.1 or 9.9.9.9, and automatically get a nearby server wherever they are. Nobody has to choose a regional address.

Why Anycast Suits DNS So Well

Anycast is particularly good for DNS because most DNS traffic is a single UDP packet in each direction. There's no long-lived connection that could break if routing changes partway through.

DNS over TCP, DNS over TLS and DNS over HTTPS do use connections. Routing changes that move a client to a different site in the middle of a connection would break it, but in practice BGP routes are stable for long periods, connections are short, and clients simply reconnect if a connection drops. Major anycast resolvers serve encrypted DNS over anycast without problems.

Seeing Anycast in Action

You can't tell from an IP address alone that it's anycast, but many DNS operators let you ask which instance answered.

The CHAOS Class Identity Queries

Many servers answer special queries in the CH (CHAOS) class with a name identifying the instance. For example, to ask a root server which instance you've reached:

dig @k.root-servers.net hostname.bind CH TXT +short

"ns1.gb-lon.k.ripe.net"

The answer shows that this query reached a K-root instance in London. Run the same command from a server in another region and you'll get a different instance name, from the same IP address.

The newer standard name for the same query is id.server:

dig @1.1.1.1 id.server CH TXT +short

"LHR"

Cloudflare's resolver replies with the airport code of the data centre that answered, here London Heathrow.

The NSID Option

The NSID (name server identifier) EDNS option, defined in RFC 5001, asks a server to include its identity in a normal response. dig requests it with +nsid:

dig @a.root-servers.net . SOA +nsid +norecurse

The identifier appears in the OPT pseudo-section of the output:

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 6e 6e 6e 31 2d 6c 6f 6e ("nnn1-lon")

This is handy when you're troubleshooting an inconsistent answer, because you can tell the provider exactly which instance returned it.

Comparing Latency

Measure how quickly a nameserver responds:

dig @1.1.1.1 example.com A +noall +stats | grep 'Query time'

;; Query time: 6 msec

A single-digit response from a service whose headquarters are on another continent is a strong sign you're reaching a local anycast instance. A traceroute to the same address shows the path ending a few hops away, in your own region.

How Many Instances Are There?

The 13 root server identities, a.root-servers.net to m.root-servers.net, are operated by 12 organisations and served by more than 1,900 anycast instances worldwide. The current list and map are published at root-servers.org. This is why the oft-repeated idea that "there are only 13 root servers" is misleading: there are 13 addresses per protocol, each served from many places.

Limitations of Anycast

Routing isn't always optimal: BGP may send a resolver to a distant site because of peering arrangements. Good providers monitor this and adjust.
Uneven catchments: One site can attract far more traffic than expected, for example because a large ISP routes all its users there. Sites must be sized with headroom.
Harder debugging: Different users reach different servers, so a problem at one site affects only some users. Identity queries like hostname.bind and NSID are essential tools.
Consistency across sites: Every site must serve the same zone data. Updates have to reach all sites quickly, or users in different regions see different answers for a while.
Cost and expertise: Running anycast yourself needs your own AS number, a provider-independent IP block, BGP-capable transit at every site and engineers who understand routing.

Running Anycast Yourself

Most organisations get anycast DNS by using a managed DNS provider rather than building it. If you do run your own, for example for an internal network spanning several data centres or for a large public service, the core pieces are:

An AS number, obtained from your regional internet registry, such as RIPE NCC or ARIN.
A prefix that will be accepted globally: In practice at least a /24 for IPv4 and a /48 for IPv6, since many networks filter longer prefixes.
A BGP daemon on each DNS server or edge router: BIRD and FRRouting are common choices.
Health checks that withdraw the route when DNS isn't answering.

A minimal BIRD 2 configuration on a DNS server, announcing the anycast prefix to an upstream router, looks like this. The anycast address 203.0.113.53 is configured on the loopback interface and the DNS server listens on it:

router id 198.51.100.10;

protocol device { }

protocol static anycast_v4 {
    ipv4;
    route 203.0.113.0/24 blackhole;
}

protocol bgp upstream_v4 {
    local 198.51.100.10 as 64512;
    neighbor 198.51.100.1 as 64500;
    ipv4 {
        import none;
        export where proto = "anycast_v4";
    };
}

The AS numbers here come from the private and documentation ranges, so substitute your own. A simple health check, run every few seconds by a systemd timer or a supervisor, withdraws the announcement if the local DNS server stops answering and restores it when it recovers:

#!/usr/bin/env bash
# Withdraw the anycast route if local DNS stops answering.
set -u

answer=$(dig @203.0.113.53 example.com SOA +short +time=1 +tries=2 2>/dev/null)

if [ -n "$answer" ]; then
  birdc enable upstream_v4 >/dev/null
else
  birdc disable upstream_v4 >/dev/null
fi

This disables the BGP session entirely, which withdraws the route. In production you'd usually be more careful, for example requiring several failures in a row before withdrawing, so a brief hiccup doesn't cause routes to flap across the internet.

Choosing an Anycast DNS Provider

If you're choosing a managed DNS provider, anycast is now standard among the major ones, so look at the details:

Number and spread of locations, especially near your audience.
Peering and network quality, which determine how well routing matches geography.
Multiple anycast networks: Some providers put different nameservers on separate anycast networks, so a routing problem on one doesn't take out all of them.
Published performance data, such as independent DNS speed monitoring.
DDoS track record and capacity.

For the highest resilience, some organisations use two DNS providers at once, each with its own anycast network, so a provider-wide outage doesn't take their domain offline.

FAQ: Anycast DNS

No. Anycast routes queries for the same IP address to the nearest of many servers, which all give the same answer. GeoDNS gives different answers depending on where the query comes from. They're often used together.

You don't need to build it, but you'll usually get it anyway. Most reputable managed DNS providers, including free tiers, run their nameservers on anycast networks, so choosing one of them gives you the benefits automatically.

Query it from different regions with dig using the CH TXT class for hostname.bind or id.server, or with the +nsid option. If different locations get different instance names for the same IP address, it's anycast.

Yes. Routing changes could in theory move a client to a different site mid-connection, but BGP routes are stable and DNS connections are short, so it works well in practice. Major public resolvers serve DNS over TLS and HTTPS over anycast.

It helps a great deal by spreading attack traffic across many locations, so no single site has to absorb all of it. It's usually combined with filtering, rate limiting and spare capacity at each site.

Many networks filter IPv4 routes longer than a /24 and IPv6 routes longer than a /48, to keep global routing tables manageable. Announcing a smaller block risks it not being accepted widely, so parts of the internet couldn't reach your service.

Conclusion

Anycast DNS announces the same IP address from many locations and lets BGP route each query to the nearest one. That gives resolvers short round trips wherever they are, spreads normal load and attack traffic across many sites, and fails over automatically when a site withdraws its route. It's the foundation that keeps the DNS root, public resolvers and managed DNS providers fast and resilient.

For most websites, the practical step is simple: host your DNS with a provider that runs a well-connected anycast network, ideally with nameservers spread across more than one. Use hostname.bind, id.server and +nsid queries to see which instances you're reaching, and you'll have a clear picture of how anycast is serving your domain.