Summary

  • On 21 March 2018, after appointing an ad hoc chair and distinguishing a director’s possible conflict from the CEO’s disclosed conflict and recusal, AFRINIC’s Board ratified a policy that said the registry must remove a lame nameserver attribute after detection and reasonable contact attempts.
  • Ratification under a private policy process was not implementation and did not confer sovereign authority. The operational method still had to determine how lameness would be measured, how contacts would be notified, how long correction would remain possible and what evidence would justify changing parent-side reverse-DNS data.
  • The strongest case for the policy is ordinary technical hygiene: stale delegations degrade a shared coordination ledger. That case becomes weaker, not stronger, if measurement is opaque or removal is treated as punishment rather than narrowly bounded maintenance.
  • The proper safeguard is a durable implementation receipt, backed by multi-vantage testing, an ambiguity hold, staged notice, a meaningful cure period, public procedure and an automatic firewall separating reverse-DNS maintenance from corporate, membership, financial, electoral and legal disputes.

L3 — A vote, a recusal and a mandatory removal rule

The decisive scene began with an institutional absence. When AFRINIC’s Board continued its meeting on 21 March 2018, its chair and vice-chair were not present. Both had sent emails giving notice that they were stepping down, while legal advice about the binding effect of those notices had not yet arrived. The remaining directors appointed an ad hoc chair so that the meeting could proceed. That is the immediate setting in which the Board came to the proposal on lame delegations in AFRINIC reverse DNS.

The setting matters because it shows how much can be placed into motion by an apparently compact act of corporate governance: the personnel arrangement was temporary, the resolution was short, but the operational obligation accepted by the vote could eventually alter live delegation data.

The minutes also record two different conflict questions, and accuracy requires that they remain different. One director raised a possible conflict because two of the proposal’s authors were AFRINIC staff and he himself was a director. The Board discussed that concern and concluded that the recorded circumstances did not create a director conflict in this case. The CEO then disclosed a conflict arising from his combined position as CEO and staff member on one side and director on the other. He recused himself from the ratification vote. These facts demonstrate disclosure, discussion, a recorded conclusion and a recusal.

They do not demonstrate improper influence, capture, collusion, bad faith or a tainted outcome. Reading more into them would turn procedural evidence into an allegation the evidence cannot bear.

After that handling, the Board adopted Resolution 201803.395. The resolution recorded that the proposal had passed through AFRINIC’s Policy Development Process and had been referred by the working-group chairs. The Board ratified it with the CEO recused. This was the article 3.4.4 function of a private membership-based, non-profit technical registry operating within a Mauritian corporate framework. It was an act within AFRINIC’s own policy and corporate machinery. It was not legislation, an exercise of popular sovereignty or a delegation of public-law jurisdiction. The distinction is not semantic.

It determines what the word “must” could legitimately authorise and what it could never authorise.

The ratified text supplied a mandatory result. Once a nameserver was determined to be lame for an authoritative parent-side reverse-DNS delegation, and after reasonable attempts had been made to contact the responsible party, AFRINIC must remove that nameserver attribute from the relevant domain object. The policy also required an identifying remark after detection. If every nameserver associated with the domain object was lame and all nameserver records were consequently removed, the domain object itself had to be removed. Records of lame delegations were to be archived for a reasonable time.

Thus the consequence was not merely an advisory email or a voluntary tidying request. It was a registry-side change to data that helps determine the parent delegation for reverse lookup.

That mandatory core must be stated without exaggerating its reach. Removing one lame nameserver attribute was not the same action as removing an entire reverse-domain object. The latter followed only when all nameservers had been removed because all were lame. Neither action transferred or confiscated address holdings. Neither revoked allocation title, suppressed routing announcements, governed forward DNS, judged the content of a network nor imposed a public-law penalty. The policy concerned the accuracy and function of a particular parent-side reverse-DNS delegation.

Confusing that narrow surface with control over addresses or routing would inflate the act technically as well as institutionally.

The reason the proposal sought policy authority is equally bounded. At the November 2017 public policy meeting, the recorded rationale was that AFRINIC staff could not properly alter member-created WHOIS data without explicit policy authority. Ratification answered an internal authorisation problem: when may staff maintaining the registry change data supplied by a member? It did not answer a sovereign jurisdiction problem because AFRINIC had no sovereign jurisdiction to confer. A private coordination body can define disciplined authority for its employees over the records it maintains.

It cannot transform internal consensus into police, prosecutorial, punitive, confiscatory or judicial power merely by adopting mandatory wording.

The policy text and its sample implementation guideline also occupied different levels. The removal result, the remark, the all-nameservers consequence and the archive obligation were part of the policy. The sample guideline was expressly not policy. It could illustrate a workable path, but it did not bind the operational choices in the same way.

This left critical questions for implementation: what response counted as lame; from where and how often testing should occur; how transient network conditions should be treated; which contacts should be reached; what constituted a reasonable contact attempt; how long an operator should have to cure; and what evidence should survive after removal. Ratification settled that action must eventually follow a properly established condition. It did not, by itself, establish the entire proof mechanism for reaching that action.

AFRINIC’s announcement of 28 March made another distinction necessary. It identified 21 March as the ratification date, cited article 3.4.4 and said the organisation would begin the necessary steps and process for “immediate implementation”, with the community to be informed when implementation was completed. In ordinary speech, “immediate implementation” might sound like a switch had already been thrown. The later chronology shows why it cannot be read that way.

Starting implementation steps is not the same as completing the operational system, and announcing a ratification is not the same as announcing the adoption date contemplated by the policy process.

The consolidated policy manual preserved that separation. Ratification under section 3.4.4 was followed by adoption and implementation under section 3.4.5. An adoption date had to be announced to the community, and implementation should normally occur within six months after Last Call unless a waiver applied. Implementation procedures were also to be documented and publicly available. Those provisions place method within accountability. They recognise that the legitimacy of an operational rule does not rest only on whether the correct body approved its objective.

It also rests on whether the body that applies the rule can show how a case crossed the threshold from observation to intervention.

By 28 September 2018, detection was operating, but deletion had not started. The implementation review reported 19,613 lame records affecting 530 members. That scale sharpened the Board’s operational responsibility. A test that is imperfect at one record may become consequential when applied to thousands, while a refusal to act on reliably stale data at the same scale would leave a substantial accuracy problem untreated. The number therefore supports neither panic nor complacency. It identifies the need for a procedure that can distinguish persistent failure from a transient condition and do so repeatedly, consistently and at manageable cost.

The October implementation announcement supplied more of the procedure. AFRINIC described a monthly scan, repeated checks over a 30-day period, notices sent to administrative, technical and zone contacts, and automatic removal after the cure period. On 29 November, AFRINIC still described implementation as partial. It said it was taking care to ensure that findings did not include false positives; information about identified lame nameservers was being relayed to contacts, and AFRINIC had not yet taken action on those records. That caution is relevant evidence about implementation risk.

It is not evidence that an actual false positive occurred, that an operator suffered an outage or that anyone used the rule abusively.

The much more detailed sequence came later. AFRINIC stated that full implementation occurred on 29 April 2021. Under that account, nameservers were tested daily from three locations. Notices went out on days 3, 10, 17 and 24; a remark was added on day 11; and removal followed on day 30 if the lame condition persisted. This later sequence reveals what responsible operation could look like: geographical separation, persistence over time, repeated warning, an intermediate visible mark and delayed action. But it must be used as an audit of the duty created by ratification, not rewritten backwards into the vote.

The 21 March resolution did not itself fix three vantage points, those four notice days, the day-11 remark or the day-30 removal.

The chronology therefore has four distinct institutional moments. The Board ratified on 21 March. AFRINIC announced that ratification and the start of implementation steps on 28 March. Detection and procedural design developed through the later months of 2018, with deletion initially withheld while false-positive risk was considered. A detailed system was described as fully implemented in April 2021. Keeping these moments separate avoids both generous and hostile myths. Ratification was not an empty gesture, because it accepted a mandatory operational end.

Nor was it instantaneous execution, because the proof, notice and cure machinery remained to be built and refined.

What crossed the Board table in March 2018, then, was less a licence to delete than a duty to justify deletion. The mandatory verb created responsibility all the way down the operational chain. If AFRINIC was required to remove a nameserver attribute once defined conditions were met, it was equally required to know, demonstrate and preserve why those conditions were met. The shorter the formal act, the greater the importance of the implementation record that follows it. A corporate resolution can authorise staff in a sentence; safe maintenance requires measurement, notification, time, restraint and evidence sustained over weeks.