Summary

  • A frozen copy of AFRINIC’s official public WHOIS dump contained 28,206 mntner objects; 1,345 carried at least one MD5-PW or CRYPT-PW method tag.
  • Of those, 1,285 contained only deprecated tags, while 60 also contained at least one BCRYPT-PW, PGP or X.509 tag.
  • These are stored labels, not 1,345 credentials, members, organisations, accepted updates or proven vulnerabilities.
  • AFRINIC’s live documentation does not provide one unambiguous, operation-specific account of whether residual deprecated methods are inert, migration-only or more broadly accepted.
  • A privacy-safe capability and migration receipt would answer that question without publishing maintainer identities, password hashes, key identifiers or test credentials.

The observation is a label, not a login

At 17:42 UTC on 5 September 2026, a frozen copy of AFRINIC’s official public WHOIS dump contained 28,206 mntner objects and 28,380 auth: lines. In 1,345 of those objects—4.7685 per cent—the method portion of at least one line was MD5-PW or CRYPT-PW. Some 1,285 objects, or 4.5558 per cent of the population, contained a deprecated method and no BCRYPT-PW, PGP or X.509 method. Another 60 combined a deprecated tag with at least one of those non-deprecated tags.

The count is deliberately modest in what it claims. A mntner object is a database object, not a member. One organisation may control several maintainers; one maintainer may protect many objects; a historical label may remain after the service behind it has changed. Nothing in the dump shows whether a password is known, whether a key remains under anyone’s control, whether a credential was presented, or whether an update succeeded. The analysis did not collect maintainer names, contacts, key identifiers or password hashes.

That restraint does not make the result trivial. Authentication policy is represented in the public record through method labels. Operators use the record to understand how objects are protected, and AFRINIC uses a maintainer match to decide whether an update is authorised. If the stored method and the running service have parted company, the public object is no longer a sufficient description of the control surface. It may be a migration marker, a compatibility remnant, an inert label or a live path. Those are materially different states.

The whole distribution helps keep the minority in proportion. The capture contained 26,921 maintainers with at least one BCRYPT-PW, PGP or X.509 method, including 26,861 with only non-deprecated methods. BCRYPT-PW alone accounted for 26,748 objects. PGP or X.509 appeared in 172. The pattern is therefore not a database dominated by old labels. It is a largely migrated population with a residual set large enough to require a precise explanation.

AFRINIC’s pages describe more than one present

AFRINIC’s current data-protection page calls CRYPT-PW and MD5-PW deprecated. It says the two methods may not be used in new objects or future updates, recommends moving to BCRYPT-PW, and adds a qualification: for the time being, existing objects secured with the deprecated methods can still use them for authentication. The current WHOIS utilities page repeats that account.

The same data-protection page explains why the qualification matters. Where a maintainer carries several auth: attributes, matching any one is enough to authorise an update. Its advice is to retain only one strongest practical method. A mixed object is therefore not automatically protected by its strongest-looking line. If an older line remains effective for a consequential operation, the logical OR matters. If the old line is inert, its presence instead misstates the practical choice set.

A live official announcement distributed by AFRINIC on 2 July 2021 uses firmer language. Following an incident involving bulk extraction of WHOIS data, the organisation said it had updated the WHOIS engine so weak authentication mechanisms were no longer supported. The current IRR guide, in a route-object workflow, names BCRYPT-PW and PGP as supported methods. That is consistent with withdrawal, but its scope is too narrow to serve as a complete capability map for every maintainer and every update operation.

These statements need not be read as proof that the system is internally inconsistent. “No longer supported” may describe the creation of new authentication material. “Can still be used” may identify a bounded migration channel. “May not be used in future updates” may refer to changing a maintainer rather than using it to authorise a different protected object. The problem is that the pages do not name those operation boundaries. A reader must supply them.

Nor can page timestamps solve the issue. Server Last-Modified headers show when the currently captured bytes were served as modified, not necessarily when an editor last reviewed each sentence or which deployed release it describes. The record contains documentation state; it is not a runtime test.

The strongest defence is continuity

There is a good operational reason not to erase an old authentication marker casually. A resource holder who can still prove control only through a legacy path may otherwise be locked out of the very object that must be changed. A migration window can preserve continuity while support helps the holder establish a stronger method. Leaving a deprecated tag visible may also make unfinished cleanup measurable instead of burying it in an internal queue.

Compatibility state is not the same thing as silent acceptance. An old method can remain in the database while the update engine refuses it. It can be recognised only for changing the maintainer’s own authentication, not for changing a route, allocation or contact object. A support-mediated recovery process can require additional verification. Each design has a defensible purpose, and the public dump cannot tell which one AFRINIC uses.

There is also a cost to forced migration. Organisations merge, staff leave, mailboxes decay and historical keys disappear. A registry operating across many legal systems and network environments cannot assume that every old object has an active administrator ready for a clean credential rotation. If a technical cleanup severs legitimate control, it can damage accuracy as readily as a weak method can damage security.

This is the case AFRINIC should be allowed to make. It is stronger than an accusation inferred from a label. But a continuity defence becomes auditable only when the institution specifies the boundary: which operation, through which interface, against which deployed release, under what recovery rule, until what end state.

Three very different meanings for 1,345

In the first scenario, every deprecated method is inert. The running service rejects it for all update operations, and the tag survives only as historical or cleanup state. On that reading, 1,345 is not an exposure count. It is an evidence-quality and migration-completion count. The right work is to remove misleading labels safely, help holders who no longer have a usable method, and publish progress without naming them.

In the second scenario, a deprecated method is migration-only. It may be accepted to replace itself, perhaps through a specific channel or after an additional check, while remaining unusable for other protected objects. That is a coherent transitional design. It also requires unusually clear documentation because an ordinary reader will otherwise treat “authentication” as one undivided capability.

In the third scenario, an old method still satisfies broader consequential updates. Then the logical-OR rule gives the residual tag more security importance: adding a stronger method does not remove the older path. The mixed population of 60 matters under this scenario, while the 1,285 deprecated-only objects raise both protection and recoverability questions.

The frozen evidence does not choose among the scenarios. Presenting the third as proven would turn a method census into a vulnerability claim. Presenting the first as proven would let documentation outrun running code in the other direction. The honest finding is that the difference is decision-relevant and presently unreceipted in the public material reviewed.

A capability matrix is smaller than a security report

AFRINIC does not need to publish a penetration test or expose a member object to resolve the ambiguity. It can operate controlled canary maintainers with no production member credentials and report the outcome by method class. The useful unit is not simply “supported”. It is a tuple: stored state, operation, channel, deployed version and result.

At minimum, the matrix should distinguish creation of a new maintainer, modification of a maintainer’s auth: attributes, and modification of another object protected by that maintainer. If web, email, API or other update channels differ, the channel belongs in the row. A rejection class can be published without disclosing the submitted secret or the test object. The deployed WHOIS release anchors the observation to running code rather than a timeless page.

Beside that matrix, an aggregate migration table can report deprecated-only, mixed and non-deprecated-only combinations. The capture in this article provides one reproducible baseline: 1,285, 60 and 26,861 respectively. A later count should carry its own timestamp, dump digest and correction lineage. A change in the total can then be read as movement in stored state, not automatically as a change in runtime exposure.

The final part of the receipt is institutional rather than cryptographic. It should identify the migration owner, the support path for a legitimate holder who cannot rotate unaided, the target state, and any target or review date. A supersession link should retire an earlier capability statement when the engine or policy changes. That prevents an old announcement and a current help page from coexisting as equally current descriptions forever.

What the evidence cannot carry

The official dump is a public operational artifact, but authentication data deserves a narrower analytical surface. The method portion can be aggregated without reproducing sensitive values. Publishing individual maintainers, password-hash material, PGP identifiers, X.509 identifiers or contact trails would add risk without answering the capability question. Trying a credential would cross from observation into an unauthorised security test and is unnecessary.

The count also says nothing about an organisation’s competence or intent. A residual line may reflect a holder who has not migrated, a registry workflow that preserves historical state, an object awaiting support, or an engine that has already disabled the path. No identity-level inference follows from the aggregate.

This is not a general assessment of AFRINIC’s IRR, database accuracy, routing policy or institutional security. It does not establish that any route object is false, any resource record is stale, any maintainer was compromised, or any weak authentication was exploited. Those claims require different evidence objects.

What remains is narrower and operationally useful. A public record names methods that official prose describes in ways that leave their present operation boundary unclear. Running code decides that boundary. A thin, versioned, privacy-safe receipt can make the answer visible without making the system less secure.

Sources

  1. AFRINIC, Data Protection in the WHOIS Database
  2. AFRINIC, WHOIS utilities
  3. AFRINIC announcement list, WHOIS bulk extraction incident update, 2 July 2021
  4. AFRINIC, Internet Routing Registry guide
  5. AFRINIC official public WHOIS database dump