Hoe 1.1.1.1 overal tegelijk kan zijn
Stel je DNS-resolver in op 1.1.1.1 en je praat met een server in Amsterdam. Iemand in São Paulo die hetzelfde adres intypt, praat met een server in São Paulo. Er zit geen DNS-truc of doorverwijzing achter: het is letterlijk hetzelfde IP-adres, op honderden plekken tegelijk. Die techniek heet anycast, en CDN's als Cloudflare zijn erop gebouwd.
Hieronder zie je hoe BGP dat regelt, wat er gebeurt als een locatie uitvalt, en hoe een CDN er een cache bovenop zet. De meetwaarden zijn gemeten op 24 september 2026 vanaf een Nederlandse verbinding.
unicast · één adres, één server in Newark (EWR)
jij (NL) → EWR: 103 ms RTT
Eén adres, één plek
Normaal hoort een IP-adres bij één machine op één plek: unicast. Staat de server in Newark, dan reist elk verzoek uit Tokio, Kaapstad of Utrecht naar New Jersey en weer terug.
Vanaf mijn verbinding kost een ping naar een server in Newark minimaal 103 ms. Dat zit vooral in de kabel onder de oceaan. Licht in glasvezel haalt ongeveer 200 km per milliseconde, harder gaat het niet.
Hetzelfde prefix, overal aangekondigd
Anycast draait het om. Cloudflare (AS13335) kondigt het prefix 1.1.1.0/24 via BGP aan vanaf al zijn locaties tegelijk. BGP controleert niet of een prefix op één plek bestaat, dus voor de rest van het internet woont het gewoon overal.
Volgens Cloudflare zit het netwerk in 348 steden (cloudflare.com/network, geraadpleegd 24 september 2026). De kaart toont een selectie.
Het netwerk kiest
Elke router onderweg ziet meerdere routes naar 1.1.1.0/24 en kiest er één. Zo belandt je verzoek bij één van de PoP's (points of presence).
Vanaf mijn aansluiting antwoordt Amsterdam: curl https://1.1.1.1/cdn-cgi/trace gaf colo=AMS, de ping was minimaal 12 ms. dig CH TXT id.server @1.1.1.1 gaf bij drie pogingen achter elkaar ams19, ams08 en ams17. Binnen de PoP wordt het verkeer dus nog eens over een rij servers verdeeld.
Dichtstbij, in BGP-termen
"Dichtstbijzijnde" klinkt geografisch, maar BGP meet geen kilometers. Een router kiest op beleid (klant boven peer boven transit), daarna op de lengte van het AS-pad, en pas veel later op zoiets als nabijheid. Heeft een provider in Kaapstad geen peering met Cloudflare in Johannesburg, maar wel een transitleverancier die het verkeer in Londen overdraagt, dan gaat dat verkeer naar Londen. Dat voorbeeld op de kaart heb ik verzonnen, maar het gebeurt echt.
Onderzoekers die een root-DNS-server met meer dan honderd locaties een jaar volgden, zagen dat de meeste queries verder reisden dan nodig, veel daarvan meer dan 5000 km (Li e.a., SIGCOMM 2018).
Een locatie valt uit
Gaat de PoP in Amsterdam plat of in onderhoud, dan stuurt die een BGP-withdraw voor 1.1.1.0/24. De routers in de buurt verwijderen die route en vallen terug op de volgende beste die ze al kenden. Mijn verkeer gaat dan bijvoorbeeld naar Frankfurt: minimaal 21 ms in plaats van 12.
Geen DNS-record verandert, geen client merkt iets. Het omschakelen duurt zo lang als BGP nodig heeft om te convergeren: seconden, soms minuten. De keerzijde: toen Cloudflare op 14 juli 2025 door een configuratiefout de 1.1.1.1-prefixen op álle locaties tegelijk introk, was de resolver 62 minuten wereldwijd onbereikbaar. Alleen DNS-over-HTTPS via cloudflare-dns.com bleef grotendeels werken, omdat dat op andere adressen draait.
Een cache aan de rand
Een CDN gebruikt hetzelfde anycast-netwerk voor websites. Je browser praat met de dichtstbijzijnde PoP, de edge. Heeft die het bestand al, dan komt het antwoord direct uit de cache, 12 ms verderop, en ziet de oorspronkelijke server (de origin) het verzoek nooit.
Cloudflare meldt dat in de header cf-cache-status: HIT. De header age vertelt hoeveel seconden het object al in de cache ligt.
Miss, en de upper tier
Heeft de edge het bestand niet (MISS), dan moet het ergens anders vandaan. Als elke PoP zelf naar de origin loopt, krijgt die bij een populair bestand honderden identieke vragen. Daarom zit er een laag tussen: een origin shield, bij Cloudflare Tiered Cache genoemd. Alleen de upper tier mag de origin iets vragen. Bij Smart Tiered Cache is dat één PoP dicht bij de origin.
In het rekenvoorbeeld staat de origin aan de Amerikaanse oostkust. Een volledige miss kost dan zo'n 134 ms: 12 ms naar de edge, ongeveer 90 ms de oceaan over, een paar ms naar de origin en 30 ms rekenwerk. Alleen de eerste 12 ms is gemeten, de rest is een schatting.
TTL en Cache-Control
Hoe lang een cache iets mag bewaren, bepaalt de origin met Cache-Control. Bij public, max-age=300, s-maxage=86400 mag je browser het vijf minuten bewaren en een gedeelde cache, zoals de CDN, een dag. Is die tijd verstreken, dan vraagt de edge het object opnieuw op, of controleert met een conditioneel verzoek of het nog klopt (REVALIDATED).
Wissel hierboven tussen edge-hit, shield-hit en miss. Het verschil zit bijna helemaal in die ene trans-Atlantische rit.
Speel zelf: zet PoP's uit
Klik op een PoP op de kaart, of op de knoppen eronder, om hem uit te zetten. Wie daar zat, schuift door naar de volgende route, en jouw RTT loopt op. De waarden zijn minimale pingtijden vanaf mijn verbinding, naar 1.1.1.1 in Amsterdam en naar servers in Frankfurt, Londen, Parijs, Stockholm en Newark.
Zet ze allemaal uit en je belandt in Newark. Kapot gaat er niets, het wordt alleen trager.
Anycast en TCP
Voor DNS over UDP is anycast ideaal: één vraag, één antwoord, en welke server antwoordt maakt niet uit. TCP heeft staat, en die staat woont op één server. Verandert de route midden in een verbinding, dan komen je pakketjes aan bij een PoP die jouw sessie niet kent, en die antwoordt met een reset. RFC 4786 (Operation of Anycast Services) zegt het zo: de routekeuze moet veel langer stabiel blijven dan een transactie duurt. In de praktijk gaat het meestal goed, omdat routes zelden midden in een verbinding omslaan.
Hetzelfde principe zit onder de DNS-root. Achter de dertien namen van de rootservers draaiden op 24 september 2026 volgens root-servers.org 2045 instances, beheerd door twaalf organisaties. Vanaf mijn verbinding meldt K-root zich als ns3.nl-ams.k.ripe.net, dus ook uit Amsterdam.
Zelf proberen
Welke PoP antwoordt er bij jou?
curl -s https://1.1.1.1/cdn-cgi/trace
Kijk naar colo=. Dat is een IATA-luchthavencode. De uitvoer bevat ook een regel ip= met je eigen publieke adres, dus die plak je niet zomaar ergens.
Welke server binnen die PoP:
dig +short CH TXT id.server @1.1.1.1
dig +short CH TXT hostname.bind @k.root-servers.net
En de cache van een CDN:
curl -sI https://www.cloudflare.com/favicon.ico | grep -iE 'cf-cache-status|age|cache-control|cf-ray'
cf-ray eindigt op de code van de PoP die je bediende, bij mij -AMS.
Tot slot
Wat me blijft verbazen, is hoe weinig er voor nodig is. Geen nieuw protocol, geen slimme loadbalancer erboven: gewoon BGP, met hetzelfde prefix op honderden plekken. Die eenvoud heeft wel een prijs. In juli 2025 was één configuratiefout genoeg om het adres 62 minuten lang overal tegelijk te laten verdwijnen.