Summary

  • AFRINIC’s NS2 measurement configuration lists 17 locations. Six have complete before-and-after RIPE Atlas pairs, while eleven have neither measurement ID and are classified by the interface as pending.
  • All twelve linked DNS measurements are public, stopped one-offs. They can support bounded deployment comparisons, but calling their last results “real-time” collapses historical experiment evidence into current-health evidence.

The latest result is not the present tense

The consequential word on AFRINIC’s NS2 measurement dashboard is not anycast. It is real-time. The page calls itself “Real-time Anycast Node Monitoring”, offers an average round-trip time, before-versus-after comparisons, probe views and a “Last updated” field. These are the visual cues of an operating instrument. A reader can reasonably assume that a fresh visit describes the current network.

The implementation says something narrower. AFRINIC’s published node configuration contains 17 locations. Its dashboard application declares a location configured only when both a beforeMeasurementId and an afterMeasurementId are present. Six pass that test. Eleven have both fields blank. The interface labels the latter “Pending Configuration” and says that no measurement data are available.

For a configured location, the application requests RIPE Atlas’s /measurements/{id}/latest/ endpoint for each member of the pair. That endpoint name can be misread. “Latest” means the most recent result stored for the identified measurement. It does not mean that the measurement is ongoing, periodic or recent. A stopped one-off still has a latest result. Reloading it today retrieves history more quickly; it does not create a new observation today.

This is not a semantic complaint. It changes what decisions the page can safely support. A before-and-after experiment may show that latency changed around a deployment. A live monitor is asked whether the service is observable now, from which viewpoints, through which node and with what freshness. Those are related products, but they have different clocks, denominators and failure modes.

Three inventories occupy the same public story

AFRINIC’s DNS Anycast Programme page presents two service families. It identifies AS37181 with CIP, the reverse-DNS service associated with AS112 practice, and AS37177 with NS2 support for African country-code domains. It also links to a public node map and describes infrastructure hosting, redundancy and operational support as programme requirements.

The node distribution map uses two downloadable inventories. The frozen CIP host file contains 20 host rows, and the NS2 host file contains another 20. These rows identify hosts and locations. They are a deployment inventory.

The map’s public assembly script confirms that those two inventories feed the display.

The measurement dashboard is different. Its heading is “NS2 DNS Measurement”, and its configuration lists 17 location labels, not 40 host rows. Six labels have an experiment pair: KIXP in Nairobi, HIXP in Harare, LSKIX in Lusaka, DoualaIX in Douala, IXPN in Lagos and MIXP in Rose Hill. Eleven are pending: JINX, s02.iso, CINX, s01.pkl, s02.pkl, DINX, NMBINX, DarIX, UIXP, RINEX and TUNIX.

Nothing justifies subtracting 17 from 40 and calling 23 hosts unmeasured. A map row and a measurement location are not the same unit; several hosts may share a site, and the measurement interface is scoped to NS2 rather than CIP. The defensible comparison is internal to each surface. The map says what it lists. The dashboard says which of its 17 locations have both experiment IDs. A sound public account keeps those denominators visible instead of blending them into one impression of coverage.

Twelve records, all with the same lifecycle state

The six pairs point to twelve public RIPE Atlas DNS measurements:

Location Configured “before” Configured “after” Scheduled probes shown by Atlas
KIXP 154055021 154055966 16 / 16
HIXP 142775401 142775907 3 / 3
LSKIX 142730550 142730838 6 / 6
DoualaIX 155156750 155156902 2 / 2
IXPN 143072543 147523251 12 / 10
MIXP 142741062 142740732 8 / 8

Every record returns is_oneoff: true. Every status is Stopped. Their observation windows run from 8 December 2025 to 16 February 2026. Most lasted roughly five minutes. RIPE Atlas’s measurement API reference explicitly distinguishes one-off measurements and defines “Stopped” as a lifecycle state. This is not an interpretation imposed from outside the data; it is the vocabulary of the measurement provider.

The records are still valuable. The KIXP pair, for example, names a before and an after test against the same target address and ASN. A bounded comparison can ask whether the same probe cohort saw a different round-trip distribution around a deployment. That is a legitimate experiment. The error begins when the result is allowed to escape its time window and stand in for current service health seven months later.

The word “real-time” also obscures how sparse the probe cohorts are. Two scheduled probes may be sufficient for a carefully scoped Douala experiment; they are not automatically a representative view of a continent-scale anycast service. Sixteen probes may improve one comparison without turning it into a continuous coverage system. Probe count, probe identity, geography and path all belong with the result. A dashboard number without that cohort can acquire more authority than the experiment earned.

Two pairs need an alignment note before comparison

The public configuration also exposes two correctable questions. HIXP’s beforeMeasurementId is 142775401, but that measurement’s description ends with “After”. Its configured partner, 142775907, has a generic Zimbabwe description and points to a different target ASN and IP address. A comparison may still have a valid design, but the dashboard should state why those targets form a pair and which label is authoritative.

MIXP is more visibly crossed. The ID placed in the configuration’s “before” field, 142741062, is described by Atlas as “Mauritus - After”. The ID placed in the “after” field, 142740732, is described as “before”. This may be no more than a field-order mistake. It is not evidence that the DNS service failed, that a node was misdeployed or that the underlying measurements are corrupt. It is evidence that the comparison needs an explicit mapping record before a reader treats the chart direction as meaningful.

That restraint matters. Public technical criticism often leaps from a metadata mismatch to a service verdict. The data here do not support that leap. They support a narrower conclusion: the page needs to disclose which label, target and window were accepted for each comparison, and it needs a correction history when those mappings change.

Anycast makes viewpoint part of the result

RFC 4786, the operational BCP for anycast services, explains why this distinction is structural. A client is routed to one of several service nodes, and the observed availability or performance depends on where that client sits in the network. The document recommends monitoring from representative distributed probes and, where possible, recording the identity of the node that answered along with performance and availability statistics.

That advice does not make the RFC a binding dashboard specification, and it does not prove AFRINIC breached a duty. It does provide the right analytical test. A measurement result is not just a latency value. It is a statement about a target, a probe, a route, a responding node if identifiable, and a time. Remove the time and the statement becomes misleading. Remove the node identity and an anycast path may be attributed to the wrong site. Remove the probe cohort and a local improvement may be presented as regional.

The distinction is especially important because AFRINIC’s programmes distribute responsibility. The separate root-server copy programme describes AFRINIC as a facilitator rather than the root-copy operator and places local support with the host. RFC 6304 likewise supplies operational context for AS112 service, not a shortcut for assigning responsibility across every CIP or NS2 node. The NS2 dashboard should therefore say what it observes, not quietly imply ownership of everything on the programme map.

A node observation receipt is smaller than a new platform

AFRINIC does not need to build another dashboard to fix the evidentiary boundary. It needs a compact receipt behind each displayed node and comparison.

First, identify the service class and unit: NS2 or CIP, host or location, NSID if observed, and the public site label. Then state the lifecycle object: deployment inventory, pre-deployment experiment, post-deployment experiment or current-health monitor. Those four labels prevent a historical chart from being promoted by design.

Second, preserve the measurement contract. Record both IDs, their accepted before/after order, target ASN and IP, DNS query name and type, address family, requested and scheduled probe cohort, start and stop time, and whether the task is one-off or periodic. If target or cohort changes across a pair, explain why the comparison remains valid or mark it non-comparable.

Third, give freshness a type. “Last result fetched” is not “last current observation”. A receipt should show the most recent measurement execution, the most recent successful dashboard retrieval and the maximum age allowed for a current-health badge. Once the age is exceeded, the interface should display “historical” or “stale for live health”, not merely keep the last value green.

Finally, record responsibility without publishing sensitive topology. Name the role that owns the measurement definition, the role that can correct a node mapping, and the escalation path for a host or ccTLD operator. A correction should append a new mapping and retain the old one’s hash and validity window. That is enough to make a chart auditable without exposing router configuration or facility detail.

The resulting states are unglamorous and useful: deployed but uninstrumented; experiment configured; experiment complete; continuous monitoring active; current observation stale; mapping under review. A public programme can be healthy while some rows occupy each state. Precision does not manufacture a crisis. It prevents an unfinished measurement surface from being mistaken for one.

Sources used for the measurement finding

The finding is reproducible from AFRINIC’s programme page, deployment map, measurement dashboard, node configuration, application logic, and the two public host inventories for CIP and NS2. The measurement-provider definitions come from RIPE Atlas’s API reference; the operational benchmark is RFC 4786. Each of the twelve Atlas records is linked in the table above. The root-copy and AS112 materials are used only to keep programme roles separate.