Anycast measurement lab

Lab notes

Sixteen measurement notes from August and September 2026. Every note carries the RIPE Atlas measurement IDs, so anyone can check the numbers. Among them: two drains of one site, 52 hours apart, where 85 and 88 % of the probes came back within 82 seconds and the same ten entries never did; how the TLDs, Germany and Europe delegate their DNS; and what one anycast site costs or saves per continent.

Bill Woodcock, Packet Clearing House, on Mastodon about one of the notes: “It's a great use of RIPE Atlas, since all the measurements are auditable and all the results can be independently verified.” Quoted with permission.

• Public resolvers can leave from almost anywhere. Their queries come from a few places. — An egress map of a public resolver shows where the resolver can ask from. It does not show where it asks from. We measured both on our own lab and they are far apart.
• Which nameserver do resolvers pick, and how fast do they move — 78 zones, delegated to one unicast server and to 34 anycast nodes at the same time. For 24 hours we counted where the resolvers sent their queries, and in a separate test how long they take to follow a change.
• Drains three and four: this time with real traffic — Withdrawn in one second, nothing left on the drained node, and 159 of 165 source prefixes back home with their first query.
• Atlas tells you where a network goes. It does not tell you how much traffic arrives. — We checked one against the other on our own lab: the catchment that RIPE Atlas probes report for each node, next to the resolver traffic the same nodes actually answered.
• Two drains, two days apart: 85 and 88 % of the probes came back, and the same ten never did — two maintenance windows on our own anycast lab, 52 hours apart: the return curve is flat after 82 seconds, and the probes that stayed away are the same ones both times.
• How German sectors delegate: cities, universities, banks and the .de top 1,000 — four lists, 1,276 zones, plain DNS queries: one operator behind 72 % of the universities, 3.8 % of the bank zones signed, ten operators behind 58 % of the .de top 1,000.
• Who changed their ccTLD nameservers this year: 78 of 309, ten operator swaps, read from the root zone — 947 copies of the root zone, one year, all 309 ccTLDs: who appeared, who disappeared, and why the IANA date is not the change.
• Who checks the anycast vendors of Europe's ccTLDs? Nobody. So we did. — 27 ccTLDs measured from RIPE Atlas probes inside each country: the registry's own servers and the commercial anycast operators within about 10 ms, the registry-to-registry secondaries 18 to 41 ms away.
• How Europe delegates: 853 zones, 76 % outsourced, and DNSSEC depends on the registry — seven lists, plain DNS queries: who runs the nameservers in each country, how concentrated it is, and why the Dutch list is signed and the other six are not.
• Prepending one anycast site: the first prepend does the work, the third does nothing — Miami, three prepends, one withdraw, one control, the same 1,000 probes at every step: one prepend moved 40 of 49 probes, the third moved none.
• What the delegation costs: 139 German zones, 146 ms in one country, 21 ms on anycast — the same zones measured from 1,000 probes weighted by population: what one country costs in Asia and South America, per group and per provider.
• Who answers for apple.com: half Apple, half Packet Clearing House — 30 sites against 124, from 1,000 probes: where each half wins, and what a resolver gets.
• How the TLDs delegate: 1,438 zones, two operators on half of them, 87 without DNSSEC — every top-level domain in the root, read with plain DNS queries.
• How Germany delegates: 139 zones, 76 % outsourced, 60 % in one country — DAX-40, federal government, states, broadcasters, banks: who runs their nameservers, and how few are signed.
• 1 to 33 anycast sites at one cloud provider: a staircase, not a curve — one prefix, six stages, the same 1,000 probes at every step. The site that made a continent slower, and the one nobody sees.
• AS218833: from ASN assignment to two-site anycast in one afternoon — timeline and field notes of the lab going live.

All notes: anycast.org/notes · RSS

Tools

whoserves

A small Python tool that measures catchments from the user's side, for any zone, with public RIPE Atlas measurements. It will plan the measurements, weight the probes by population, and report which site serves which region, what moves during maintenance, and which operator takes over when one fails. Status: placeholder 0.0.2 on PyPI, no measurement code yet. I write it by hand. Apache-2.0. Code: github.com/anycast-lab/whoserves · PyPI

anycast-agent

A small passive agent for nameservers from the lab period. It reads dnstap metadata and collects Verfploeter replies on the operator's own nodes. Query names and full client addresses never leave the server. It is a prototype, written mostly with a coding assistant, and it has been stopped on all lab nodes since 2026-10-30. The code stays public: github.com/anycast-lab/anycast-agent

What my probes would do

I use the Verfploeter method (de Vries et al., IMC 2017; used in production at B-Root and for .nl): one lab node sends ICMP echo requests with the anycast address as the source; every lab node records which replies arrive there. The node that receives your reply is the node BGP routes you to. That is the whole measurement.

• Packet type: ICMP echo request (IPv4) and ICMPv6 echo request. Nothing else. No TCP, no UDP, no port scans, no application-layer payloads.
• Targets: one address per routed /24 (IPv4) or per /48 (IPv6), taken from public responsive-address lists, minus my exclusion list.
• Rate: at most a few hundred packets per second in total across the whole Internet; one packet per target network per run. A full run takes several hours. 1–2 runs per day, occasionally an extra run after a routing event.
• Size: small packets (under 100 bytes). The payload carries a plain-text identifier with this page's address.
• Identification: source addresses have reverse DNS under anycast.org, the prefixes are registered to the lab ASN with an abuse contact, and this page is linked from the payload.
• No exploitation, no persistence: I never connect to services, never retry a target that does not answer within a run, never follow up on anything I learn about a host.

How to confirm it was me

1. The source address is inside one of the prefixes listed under Status.
2. dig -x <source address> returns a name ending in .anycast.org, for example probe-fra1.anycast.org. (Reverse DNS for the probe addresses is set before the first run; until then no probe traffic exists to check.)
3. The RIPE database (whois <source address>) shows the lab ASN ANYCAST-LAB, organisation Portalix UG, and abuse@anycast.org as abuse contact.
4. The ICMP payload contains the string anycast.org measurement - opt-out: https://anycast.org/#opt-out.

If a packet claims to be from me and fails these checks, it was not me. Please tell me at abuse@anycast.org; spoofed measurement traffic is something I want to know about.

What I store and publish

• Stored per run: target network (/24 or /48), which lab node received the reply, round-trip time, timestamp. That is the entire record. I do not store packet contents, and I do not keep per-host information beyond the one probed address per network.
• Enrichment: origin AS and country per network from public routing data and a commercial geolocation database, used for aggregation only.
• Published: aggregated catchment maps and statistics (per country, per AS, per node). Findings about a specific third-party network are shared with that network's operator first and published only in aggregate or with the operator's consent.
• Retention: raw run data for 12 months, aggregates indefinitely.
• Personal data: measurement records concern network infrastructure, not people. Opt-out requests (e-mail address, prefixes) are kept as long as the exclusion is in force. Privacy policy: anycast.org/privacy.

Why I do this

Anycast is how most of the Internet's DNS is delivered, and operators mostly cannot see where their traffic actually lands. The measurement methods are published, but a small operator, or a registry with an outsourced provider, has no tool to check who really serves their users and what happens when one site fails. The lab exists to build that in the open. The notes show the method on real zones, whoserves will make it a tool anyone can run, and the experiments on the lab's own prefixes are documented so others can learn from them.

References

• W. de Vries, R. de O. Schmidt, W. Hardaker, J. Heidemann, P.-T. de Boer, A. Pras: Broad and Load-Aware Anycast Mapping with Verfploeter, ACM IMC 2017.
• A. S. M. Rizvi, L. Bertholdo, J. Ceron, J. Heidemann: Anycast Agility: Network Playbooks to Fight DDoS, USENIX Security 2022.
• RIPE NCC: RIPE Atlas, atlas.ripe.net.

Use of generative AI

Past use: the measurement pipeline behind the notes, the anycast-agent prototype, and the text of the notes and of this page were drafted with a coding assistant under my direction. The measurements, the Atlas measurement IDs and the numbers are my own and public, so every claim can be checked without trusting the text.

Present use: for whoserves the assistant is read-only. It may run tests and review code and text that I wrote. It does not write code, documentation or text for whoserves. The README of whoserves will say the same.

Contact