Summary

  • AFRINIC’s removal history, captured on 3 September 2026, sums to 27,726 delegation-removal events and 9,036 domain-object-removal events. Neither sum establishes the number of unique objects or organisations involved.
  • The current summary contains three different populations: 1,936 flagged delegation records, 1,358 labelled domain objects and 194 resource holders. Their respective shares are about 1.1%, 2.6% and 10.9%, not interchangeable measures of outage.
  • The first and last observations in the stock series show a decline of about 95.1%. Repair, editing and removal can all change that stock; the aggregate files do not provide a cure rate or a complete account of restored service.

Two columns in AFRINIC’s reverse-DNS removal history tell different stories. Added separately, the dated entries amount to 27,726 lame delegations removed and 9,036 domain objects removed. The first number is not a larger version of the second. A nameserver reference can disappear while the domain object remains. Removing the final reference is a different operation. The file covers 30 May 2021 to 31 August 2026 and contains 996 dated rows; it does not identify the objects behind those totals. These are sums of recorded events, not a census of unique casualties. AFRINIC removal history

That distinction is a useful starting point for judging the cleanup. An inventory can become more accurate without every service represented in it becoming available. Conversely, removing an unusable referral can be valuable even when it does not restore the missing answer. The honest assessment needs room for both results.

A smaller inventory can leave different services behind

Consider a hypothetical reverse zone with two listed nameservers. One no longer answers authoritatively for it; the other still does. Reconfiguring the first server repairs that server’s role. Removing its entry instead stops directing queries towards it. Both actions can reduce the count of failed references. Only one demonstrates that the first server has resumed authoritative service.

Now consider a zone for which no listed server can perform the required function. Removing the final delegation eliminates a misleading route to an answer, but does not conjure an answer into existence. The resulting registry state may be more truthful. For someone who still needs that reverse lookup, however, restoration remains a separate task.

These examples are explanations of possible outcomes, not cases identified in AFRINIC’s aggregate records. They also show why one flagged reference must not be treated as evidence that every server for a zone is unusable. Redundancy changes the consequence of a failure, even if it does not make that failed reference desirable.

AFRINIC’s 2021 implementation explanation describes action at the relevant nameserver attribute, with the domain object removed when no nameserver entries remain. It describes monthly checks of registered nameservers, daily retesting after detection, staged notices and removal on day 30 if the condition persists. Testing is from at least three geographical locations; one authoritative success from any location is enough not to classify the server as lame. These are published operating rules, not evidence that this report audited every subsequent execution. AFRINIC’s implementation explanation

The rule’s caution has an intelligible purpose. An error in classifying a transient condition can make an intervention unnecessary, while endless tolerance of a genuinely dead reference transfers the cost to resolvers and their users. Repeated observation and delayed action try to manage that trade-off. They do not turn the resulting count into a universal availability score.

The label needs its definition

Even the term “lame delegation” is less uniform than it looks. RFC 9499 explains that usage has expanded beyond older definitions to cover several kinds of failure, and recommends more specific terminology. A comparison of two registries’ percentages therefore needs a comparison of their measurement rules first. A shared label is not a shared experiment. RFC 9499, section 7

AFRINIC’s published definition includes silence, an answer for the wrong domain and a response lacking the authoritative bit. A successful test under that definition says something bounded about the server’s response. It does not establish that every observer, query type or application will receive the service it needs. Nor does the breadth of that definition, by itself, establish a standards violation.

There is a strong engineering case for maintaining the references nevertheless. RFC 4697 describes wasted work from repeated queries to unusable servers and distinguishes failure of an entire set from problems affecting only part of it. Its examples are not measurements of AFRINIC traffic and cannot be used to calculate this programme’s savings. They explain why avoiding an unproductive path is a real benefit rather than merely cosmetic tidying. RFC 4697, sections 2.1–2.2

Three denominators, three questions

AFRINIC’s homepage displayed 1,936 lame delegations and a 95% decrease badge when the data were captured on 3 September. The latest row in the underlying stock history is dated 2 September. The homepage figure is an entry point, not a full description of the population being measured. AFRINIC statistics portal

The summary file classifies delegation records, domain objects and resource holders separately. Adding the two states within each population produces the following arithmetic. Official summary data

Population labelled in the summary Flagged Total of both states Flagged share
Delegation records 1,936 172,702 About 1.1%
Domain objects 1,358 52,450 About 2.6%
Resource holders 194 1,774 About 10.9%

The record share helps describe the size of the error inventory. The holder share is closer to the distribution of responsibility for dealing with it. Many records can sit with one holder, so a relatively small fraction of records and a much larger fraction of represented holders can coexist without contradiction.

The denominators still impose limits. The 1,774 holders are those represented by the two summary states, not a count that can simply be substituted for all AFRINIC members. The domain totals are labelled aggregates without the grouping query or an identity-level join. They do not establish that all 1,358 flagged domain objects are wholly unresolvable, or reveal how the 1,936 records are distributed among them.

For an operator, that difference matters more than the headline ranking of percentages. A failed reference with working alternatives and the loss of a zone’s last effective delegation call for different priorities. For a manager, 194 represented holders may suggest the scale of coordination work, but it does not reveal the duration, severity or concentration of that work. Neither number names the people or networks most exposed.

The dashboard itself gives readers a better basis for analysis than a single counter: it exposes distinct views and a removal-history table. The task is to preserve those distinctions, not collapse them into one score. AFRINIC’s lame-delegation dashboard

Why the tempting subtraction does not work

The stock history begins with 39,814 on 28 September 2018 and ends with 1,936 on 2 September 2026. The net reduction is 37,878, or about 95.1% of the first observation. That is consistent, after rounding, with the homepage badge. It does not prove the homepage uses this baseline, that the measurement population stayed fixed, or that 95% of a defined cohort was repaired. Stock-history data

Subtracting the 27,726 recorded removal events from that net reduction would not reveal the number of repairs. The windows start in different years, and the records lack the identities needed to follow a cohort. More fundamentally, the stock can receive new failures while older ones leave it. Repaired servers, edited nameserver lists, removal, reappearance and changes in observed coverage can affect the total. Those are possible components of the accounting, not causes established for particular entries.

A stock-flow relationship can be sound while the information needed to populate it is missing. The mistake is not doing subtraction incorrectly. It is giving the remainder a causal name that the data have not earned.

The last observations make the risk tangible. The file reports 2,016 on 30 August, 3,354 on 31 August and 1,936 on 2 September, with no intervening 1 September row. The final drop is 1,418 between recorded observations. It cannot be attributed to the removal file’s last four events, to a single scan or to 1,418 repairs. The files do not provide that join.

There are other gaps in the historical date sequence. A missing published observation is evidence about the available series, not proof that monitoring stopped or DNS service failed. The same restraint applies to the summary’s current zero in its removal category: the separate history plainly contains removals, so a snapshot cell must not be read as an all-time total.

What the public files do establish

For this analysis, the five tables shared by the downloadable CSV archive and the dashboard’s JSON were compared field by field. The summary, 2,719-row stock series, 996-row removal series, country aggregate and holder-type aggregate matched. That reconciliation establishes consistency between two published representations. It does not create the missing object-level relationships or certify the detector’s operation. Official raw-data archive

The distinction is worth preserving because it gives appropriate credit. AFRINIC publishes enough data to inspect several units of measurement and to see that the error inventory is much smaller than at the series’ beginning. Its records also show that removal has occurred. Neither fact needs to be exaggerated into a complete account of customer benefit to be useful.

Cleaning a registry is partly the work of making its promises more accurate. A referral should not continue to advertise a service that cannot fulfil its role merely to avoid recording a removal. But a more accurate statement of absence is not the same product as a recovered answer. The count tells us about the inventory left behind; the service still needs to be assessed on its own terms.