Anycast routing — the technology behind Cloudflare's DNS, Google's 8.8.8.8, and most major CDNs — means that when you query 1.1.1.1, you're not necessarily connecting to the same physical server as someone on the other side of the world querying the same IP address, and understanding this explains both why these services are fast and why DNS propagation sometimes behaves unexpectedly
The previous articles on this site covered NS lookup basics, DNS propagation, DNS provider comparison, glue records and delegation, single-provider redundancy risks, and NS record hijacking security. This article addresses DNS anycast and infrastructure scale — how modern DNS providers route queries globally, what anycast means for latency and reliability, and what this reveals about why DNS changes propagate differently at different locations.
What anycast routing means for DNS
Unicast routing (the default for most internet traffic) sends each packet to exactly one destination — the specific server at a specific IP address. If you connect to 203.0.113.42, you reach that particular machine.
Anycast routing announces the same IP prefix from multiple locations simultaneously via BGP. When your packet is sent to an anycast IP, BGP routing selects the "nearest" announcement (by BGP path metrics, not necessarily geographic distance) and routes your packet there.
Cloudflare's 1.1.1.1 anycast example:
- Cloudflare announces
1.0.0.0/24(which includes 1.1.1.1) from all ~200+ of their data centres simultaneously - A user in London reaches a London Cloudflare server
- A user in Sydney reaches a Sydney Cloudflare server
- Both appear to connect to
1.1.1.1but reach physically different machines
Why anycast is ideal for DNS:
- DNS queries are stateless (each query is independent)
- Proximity reduces latency (closer server = faster response)
- Automatic failover (if a data centre goes offline, BGP re-routes to the next-nearest)
- No load balancer needed (BGP distributes load across PoPs naturally)
How this explains propagation variability
DNS propagation is often described as "up to 48 hours" — but the actual propagation experience varies dramatically by location, and anycast explains why:
Scenario: you change your nameservers. The old NS records had TTL of 86400 (24 hours). The new NS records are published immediately.
What happens:
- A resolver in Frankfurt that cached your old NS records 23 hours ago: will refresh within the next hour
- A resolver in São Paulo that cached the records 2 hours ago: has 22 more hours of cache
- A resolver in Tokyo using Cloudflare's anycast DNS: the Tokyo PoP has its own cache, separate from the Frankfurt PoP — Tokyo may have cached more recently or less recently
- A resolver that didn't cache your NS records at all: sees the new records immediately
The geographic variation in propagation: with anycast, different physical servers at the same logical IP address have independent caches. Cloudflare's 1.1.1.1 resolvers in 200+ cities maintain independent cache state — a change you made may have propagated to Frankfurt's cache but not yet to São Paulo's or Tokyo's 1.1.1.1 nodes.
This is why checking propagation from multiple locations gives different results — you're potentially querying different physical servers, each with its own cache state.
Root nameservers and the DNS hierarchy
The DNS root zone is the top of the hierarchy. When a resolver doesn't have a record cached and can't find it from a known nameserver, it queries one of the 13 root nameserver addresses (A through M):
a.root-servers.net 198.41.0.4
b.root-servers.net 199.9.14.201
c.root-servers.net 192.33.4.12
...
m.root-servers.net 202.12.27.33
These 13 addresses are all anycast — each is served by hundreds of nodes worldwide. The "13 root servers" are logical entities, with the actual physical infrastructure comprising over 1,500 nodes worldwide.
Why only 13 addresses? The original DNS protocol limited the root zone response to 512 bytes (fitting in a single UDP packet). 13 was the maximum number of nameserver records that fit. Modern DNS uses EDNS0 (Extension Mechanisms for DNS) which allows larger responses, but the 13 logical root server addresses remain for compatibility.
Authoritative vs recursive resolvers: different caching behaviour
Two resolver types with completely different caching implications:
Recursive resolvers (what your ISP or 8.8.8.8 provides): they query authoritatives on your behalf, cache results, and serve from cache. Cache TTL is determined by the authoritative server's response. You query a recursive resolver every time you look up a domain.
Authoritative nameservers (what Cloudflare DNS, Route 53, etc. provide when you host DNS there): they hold the ground truth for your zone. They don't cache — they answer with the actual current records. When you change an A record at Cloudflare, the authoritative server immediately returns the new value.
The propagation chain:
- You change a record at your authoritative nameserver → immediate effect at the authoritative
- Recursive resolvers' caches expire according to TTL → they query the authoritative for fresh data
- Your local stub resolver (OS DNS cache) refreshes from the recursive resolver
"Propagation" time = time for all recursive resolver caches worldwide to expire — not time for the authoritative to update. The authoritative is always current immediately.
TTL strategy: when to use low vs high values
TTL (Time to Live) is set per DNS record at your authoritative nameserver and controls cache duration:
High TTL (86400+ seconds): fewer queries to your authoritative (lower cost and load), better performance for end users (more likely to be cached). Appropriate for stable records that rarely change.
Low TTL (300 seconds / 5 minutes): faster propagation when records change, at the cost of more queries. Required before planned changes (lower TTL 24 hours before migrating A records or MX records).
The TTL change timing strategy:
- 48 hours before planned change: lower TTL to 300 seconds
- Make the planned change
- After confirming the new records work: raise TTL back to 86400
The double TTL rule: you must wait for existing caches to expire before lowering the TTL takes effect. If your TTL is 86400 and you lower it to 300, caches that refreshed 1 hour ago will continue using the old TTL for another 23 hours. Plan the TTL change at least 24-48 hours in advance.
How to use the NS Lookup on sadiqbd.com
- Propagation checking: look up your domain's NS records from the tool (which queries from a specific vantage point) and compare against what you expect — differences indicate propagation is still in progress at that location
- Authoritative vs recursive comparison: to verify a change has propagated to the authoritative, query directly against the authoritative nameserver (using dig's
@ns1.yourprovider.com yourdomain.com NS) rather than through a recursive resolver - TTL audit: the NS lookup shows the TTL on current NS records — verify the TTL before any planned nameserver change; if it's high (86400), lower it in advance
Frequently Asked Questions
If I use the same DNS provider everywhere, is my DNS genuinely redundant? For individual server failures, yes. For provider-wide outages, no. A DNS provider using anycast automatically fails over between their own nodes if one goes down. But a provider-wide outage (as happened to Dyn in 2016, which took down large portions of the US internet including Twitter, Reddit, and Spotify) affects all their anycast nodes simultaneously. True DNS redundancy requires nameservers at two different providers, each with their own infrastructure. Most DNS providers support secondary DNS or zone transfer so your records can be served from two independent providers — worth implementing for any business-critical domain where DNS availability is mission-critical.
Is the NS Lookup free? Yes — completely free, no sign-up required.
Try the NS Lookup free at sadiqbd.com — look up authoritative nameservers for any domain instantly.
