Anycast DNS vs Unicast DNS — Which Is Better for Your Domain?

What You Will Learn

• How unicast and anycast DNS routing work at the network level
• The performance, resilience, and security trade-offs between the two approaches
• When unicast is good enough and when anycast becomes essential
• How DNScale uses anycast across its global edge network

What Is Unicast DNS?

Unicast is the traditional routing model of the Internet. Every IP address maps to exactly one server in one physical location. When a recursive resolver sends a DNS query to a unicast nameserver, that packet always travels to the same machine, regardless of where the resolver sits on the network.

For decades this was how all authoritative DNS worked. You would run two or three nameservers in a data centre, publish their addresses as NS records at the registrar, and every DNS query for your zone would arrive at one of those specific servers.

Unicast in Practice

dig example.com @ns1.provider.com
 
; ns1.provider.com has a single IP: 203.0.113.10
; Every query from every resolver on the planet
; travels to that one server at that one location.

If ns1.provider.com is in Frankfurt and a resolver in Tokyo queries it, the packet crosses half the planet, accumulating 150-250 ms of round-trip latency before the answer even begins its journey back.

How Unicast Failover Works

With unicast, resilience depends on having multiple nameservers with different IPs. If one goes down, resolvers try the next NS record in the set. But this failover is slow: the resolver must wait for a timeout (typically 2-5 seconds), try another server, and resolvers that already cached the dead server's IP keep retrying it until the TTL expires.

What Is Anycast DNS?

Anycast takes a fundamentally different approach. The same IP address is announced from multiple physical locations simultaneously. When a resolver sends a query to an anycast IP, the Internet's routing fabric delivers that packet to whichever location is topologically closest.

From the resolver's perspective, nothing changes — it queries a single IP address and gets an answer. But behind the scenes, that query was handled by whichever point of presence (POP) offered the shortest network path.

If unicast is like calling a specific phone number that rings one phone on one desk, anycast is like calling a toll-free number that connects you to the nearest call centre automatically.

How BGP Makes Anycast Work

Anycast relies on BGP (Border Gateway Protocol), the routing protocol that glues the Internet's autonomous systems together. Here is the sequence:

1. Prefix announcement — Each POP announces the same IP prefix (for example, a /24 block) to its upstream transit providers via BGP.
2. Route propagation — Those announcements propagate through the global routing table. Every router on the Internet learns that this prefix is reachable through multiple paths.
3. Best-path selection — When a packet is destined for an address in that prefix, each router along the way selects the route with the shortest AS-path — the fewest autonomous-system hops.
4. Delivery — The packet arrives at whichever POP won the routing decision from that particular point on the Internet.

Because DNS queries are stateless UDP exchanges — a question goes out, an answer comes back — they are a perfect fit for anycast. There is no long-lived connection that must stick to a single server.

Anycast in Practice

dig example.com @ns1.dnscale.eu
 
; ns1.dnscale.eu resolves to an anycast IP: 185.x.x.1
; A resolver in Paris reaches the Amsterdam or Paris POP.
; A resolver in Chicago reaches the ORD POP.
; Same IP, different physical server answering.

You can observe this yourself by running the same dig query from servers in different regions. The answer will be identical, but the response time will differ because each query was answered by a different POP:

# From a server in Amsterdam
dig example.com @185.x.x.1 +stats | grep "Query time"
;; Query time: 2 msec
 
# From a server in New York
dig example.com @185.x.x.1 +stats | grep "Query time"
;; Query time: 5 msec
 
# From a server in Singapore
dig example.com @185.x.x.1 +stats | grep "Query time"
;; Query time: 8 msec

All three queries hit the same IP, but each was routed to the nearest POP by BGP.

Head-to-Head Comparison

The following table summarises the key differences between unicast and anycast DNS across the dimensions that matter most to domain operators.

Performance: Why Latency Matters for DNS

Every website load, API call, and email delivery starts with a DNS lookup. If that lookup takes 200 ms instead of 5 ms, the delay cascades into everything that follows. For sites with dozens of third-party resources, each requiring its own DNS resolution, slow lookups compound into noticeable page load increases.

Unicast Latency Profile

With unicast nameservers in a single region, users near that region enjoy fast lookups while everyone else pays a distance penalty. A European-hosted unicast nameserver might return:

• 5-10 ms for resolvers in Western Europe
• 80-120 ms for resolvers on the US East Coast
• 150-250 ms for resolvers in Asia Pacific

Those numbers represent the round-trip time for a single DNS query. For a domain with short TTLs, resolvers make these trips frequently.

Anycast Latency Profile

Anycast eliminates the distance penalty by placing answering servers near the resolvers. With POPs in Europe, North America, and Asia Pacific, the same domain might return:

• 2-5 ms for resolvers near any POP
• 10-20 ms for resolvers further from a POP but still on the same continent
• 30-50 ms worst case for resolvers in regions without a nearby POP

The difference is not marginal. For latency-sensitive applications, shaving 100-200 ms off DNS resolution directly improves user experience. For A records and AAAA records that point to your primary services, fast resolution is especially important since those lookups sit on the critical path of every connection.

DDoS Protection: Absorbing Attacks at Scale

DNS is one of the most attacked layers of the Internet. A DDoS attack targeting your nameservers can take your entire online presence offline — not just your website, but email, APIs, and every service that depends on DNS resolution.

Unicast Under Attack

With unicast, all attack traffic converges on a small number of servers. A 10 Gbps flood aimed at a unicast nameserver must be absorbed by that single location's network capacity. If the attack exceeds the server's or data centre's capacity, your DNS goes down and your domain becomes unreachable.

Anycast Under Attack

With anycast, the same 10 Gbps attack is automatically split across every POP announcing the target prefix. If you have seven POPs, each absorbs roughly 1.4 Gbps — a far more manageable volume. Each POP can apply local rate limiting and scrubbing while continuing to serve legitimate queries.

This is not a theoretical benefit. Anycast-based DNS is the industry standard for DDoS resilience precisely because it turns a concentrated attack into a distributed, diluted one. The more POPs in the network, the more effective the dilution.

DNS DDoS attacks affect everything tied to your domain. Unlike a web server attack that takes down one site, a DNS attack renders your domain unresolvable — no website, no email, no API. Anycast is the most effective architectural defence against this class of threat. Learn more in our DNS Attacks and Threats guide.

Failover: Seconds vs Minutes

How quickly your DNS recovers from a server failure directly determines your downtime.

Unicast Failover

When a unicast nameserver goes offline, recovery depends on the DNS layer:

1. A resolver sends a query to the failed server's IP.
2. The query times out after 2-5 seconds.
3. The resolver tries the next NS record (if one exists).
4. If the resolver had cached the failed server as its preferred NS, it continues retrying until the cached entry expires based on the NS record's TTL.
5. Other resolvers that cached answers from the failed server continue serving stale data until the record TTL expires.

Total recovery time: seconds to minutes for the resolver to switch NS records, plus up to the full TTL duration for cached answers to expire across the Internet. With typical TTL values, this can mean 5-60 minutes of degraded resolution.

Anycast Failover

When an anycast POP goes offline, recovery happens at the network layer:

1. The POP withdraws its BGP route for the anycast prefix.
2. Upstream routers converge on the remaining routes within seconds.
3. Traffic that was flowing to the failed POP automatically shifts to the next-closest healthy POP.
4. No DNS changes are needed. No TTL expiry is required. No resolver behaviour changes.

Total recovery time: typically 5-30 seconds for BGP convergence. From the resolver's perspective, the IP address never changed — it just started reaching a different physical server.

This difference is significant. With anycast, a POP failure is a routing event, not a DNS event. Resolvers, clients, and zone delegations remain unchanged.

When Unicast Makes Sense

Unicast is not inherently bad. For certain use cases, it is perfectly adequate:

• Small sites with a regional audience — If your users are concentrated in one city or country and your nameservers are nearby, the latency penalty is negligible.
• Simple infrastructure — Unicast does not require BGP knowledge, AS numbers, or IP prefix allocations. Two servers with static IPs and standard NS delegation work fine.
• Internal or private DNS — Corporate DNS for internal services does not need global distribution. A pair of unicast servers behind a load balancer is standard practice.
• Budget constraints — Running a global anycast network requires significant infrastructure investment. For a personal blog or small business site, the cost is hard to justify when managed unicast DNS is available for a few dollars per month.
• Testing and development — Development environments rarely need production-grade DNS resilience.

If you are running a personal project, a small business website, or a service with a single-region user base, unicast DNS from a reputable provider is a reasonable choice. The key is understanding when you have outgrown it.

When Anycast Becomes Essential

As your requirements grow, anycast stops being a nice-to-have and becomes a necessity:

• Global audience — If your users span multiple continents, unicast creates an inherent latency disadvantage for everyone outside the server's region. Anycast eliminates this by answering from the nearest POP.
• High availability requirements — If DNS downtime means lost revenue, SLA breaches, or user-facing outages, anycast's automatic BGP failover is dramatically faster than unicast's DNS-layer failover.
• DDoS exposure — Any domain that is a potential DDoS target — e-commerce, SaaS platforms, financial services, gaming — benefits from anycast's traffic dilution. A single-location DNS setup is inherently vulnerable to volumetric attacks.
• Multi-provider DNS strategies — When running multi-provider DNS for redundancy, anycast providers offer better baseline performance for each provider in the set.
• Secondary DNS architectures — Anycast ensures your secondary nameservers are reachable with low latency globally, not just from the region where the secondary server is physically located.
• Compliance and data sovereignty — Some regulatory frameworks require DNS queries to be answered within specific jurisdictions. Anycast with regional scoping (like separate EU and Global networks) enables this without sacrificing performance.

How DNScale Implements Anycast

DNScale runs a purpose-built anycast DNS network designed for low latency, automatic failover, and regional compliance.

Seven Points of Presence

DNS queries are answered from seven global POPs:

Each POP sits near major Internet Exchange Points (IXPs), keeping DNS answers close to the resolvers that serve end users.

Dual Autonomous Systems

DNScale operates two separate AS numbers to support both global and regional DNS strategies:

• AS44794 — EU network. Anycast prefixes are announced exclusively from European POPs (AMS, FRA, PAR, LON). Zones delegated to these nameservers are answered entirely within European carriers.
• AS62406 — Global network. Prefixes are announced from all seven POPs worldwide.

This dual-AS architecture means customers can choose per-zone whether DNS should be answered from EU-only infrastructure or from the full global footprint, simply by selecting the appropriate nameservers during delegation at the registrar.

The Stack at Each POP

Every POP runs the same stack:

1. BIRD — BGP daemon that announces anycast prefixes to upstream transit providers and withdraws routes if local health checks fail.
2. DNSdist — DNS load balancer that accepts queries on the anycast IPs, performs health checking, caches responses, and balances load across backend nameservers.
3. PowerDNS Authoritative — Serves the actual DNS records from a locally replicated PostgreSQL database.

Zone data is synchronised across all POPs using PostgreSQL logical replication, ensuring every POP returns identical answers. When you update an A record, a CNAME, or any other record type through the dashboard or API, the change propagates to all POPs within seconds.

For a deeper look at how DNScale's routing intelligence works beyond basic anycast, including ingress sensing, policy engine, and route signalling, read the Global DNS Resolution Balancing guide.

Verifying Anycast Behaviour with dig

You can confirm that anycast is working by querying the same nameserver IP from different network locations and comparing response times.

# Query from a European vantage point
dig example.com @ns1.dnscale.eu +stats
;; Query time: 3 msec
;; SERVER: 185.x.x.1#53(185.x.x.1)
 
# Query from a North American vantage point
dig example.com @ns1.dnscale.eu +stats
;; Query time: 4 msec
;; SERVER: 185.x.x.1#53(185.x.x.1)
 
# Query from an Asia Pacific vantage point
dig example.com @ns1.dnscale.eu +stats
;; Query time: 7 msec
;; SERVER: 185.x.x.1#53(185.x.x.1)

Notice that the server IP is identical in all three responses. With unicast, you would see response times of 3 ms from Europe but 150+ ms from Asia Pacific. With anycast, all three are consistently fast because each query was answered by the nearest POP.

You can also use the +nsid option (if supported by the provider) to see which POP actually answered your query:

dig example.com @ns1.dnscale.eu +nsid
;; OPT PSEUDOSECTION:
; NSID: 61 6d 73 ("ams")

Key Takeaways

• Unicast DNS maps each IP to one server. It is simple and affordable but creates latency for distant users and relies on slow DNS-layer failover.
• Anycast DNS maps one IP to many servers across multiple locations. BGP routing delivers each query to the nearest POP, providing low latency, automatic failover, and DDoS dilution.
• Anycast failover happens at the network layer in seconds. Unicast failover depends on resolver timeouts and TTL expiry, which can take minutes.
• For small, single-region sites, unicast is fine. For global audiences, high-availability requirements, or DDoS exposure, anycast is the clear choice.
• DNScale's anycast network spans seven POPs across two autonomous systems, giving customers both global reach and EU-scoped DNS resolution.

Further Reading

• What is an Anycast DNS Network? — How anycast networking and BGP routing work in detail
• Global DNS Resolution Balancing — DNScale's GDRB pipeline for intelligent query steering
• What is DNS? — Fundamentals of the Domain Name System
• DNS Record Types — Overview of all DNS record types
• DNS Server Types — Authoritative vs recursive servers explained
• DNS Attacks and Threats — How DDoS and other attacks target DNS
• Multi-Provider DNS Deployment — Redundancy across multiple DNS providers
• DNS Propagation Explained — Why DNS changes take time and how caching works
• DNS TTL Best Practices — Choosing the right TTL for your records
• What is Secondary DNS? — Primary and secondary nameserver redundancy
• DNS Delegation by Region — Setting up nameserver delegation for DNScale regions