Summary

  • AFPUB-2012-DNS-001-DRAFT-01 proposed refusing a new reverse-DNS delegation unless the corresponding assignment or sub-allocation was appropriately registered in the AFRINIC Database. It also proposed reminders to holders whose existing delegations lacked downstream registrations.
  • The proposal used access to a useful registry service as an incentive for better bookkeeping. That was more consequential than a reminder, because an inaccurate or delayed record could produce a false refusal even when operational use was legitimate and continuing.
  • Section 3.3 substantially limited the immediate risk: existing reverse delegations approved before any ratification were not to be removed, and only later allocations would be affected. Draft 1 therefore did not propose a retrospective purge of existing delegations.
  • AFRINIC-16 recorded questions about effectiveness, enforceability, staff burden and scanning consent, then recorded no consensus. AFRINIC-17 materials still showed Draft 1 as the current text, and the 2012 annual report did not record consensus for it.
  • A defensible design would have treated AFRINIC as a thin private bookkeeper and delegation coordinator: identify the exact record and zone, authenticate notice, accept corrective evidence, give a reasoned decision, preserve the last verified state, offer independent review and provide rapid rollback. It could not convert a database discrepancy into punishment, adjudication or a judgment about entitlement.

A small condition with a large institutional question

The first draft of “No Reverse Unless Assigned” was concise enough to look like a housekeeping measure. Submitted by Tim McGinnis on 10 April 2012, AFPUB-2012-DNS-001-DRAFT-01 proposed an amendment to AFPUB-2005-v4-001. Its basic move was easy to state: AFRINIC would no longer grant reverse delegation for address space it administered unless an assignment or sub-allocation for that space had been appropriately registered in the AFRINIC Database. Better downstream records would become a prerequisite for a new piece of DNS coordination.

That formulation connected two systems that operators might otherwise experience separately. One was the registry ledger: the database objects describing how allocated address space had been assigned or sub-allocated downstream. The other was reverse DNS: the parent-side delegation that allows address holders to publish address-to-name mappings beneath in-addr.arpa. Draft 1 made the accuracy of the first system consequential at the point of requesting service from the second.

The policy problem was not imaginary. Draft 1 described a public network information database as a means of making contact information about public networks available through registered assignments. The AFRINIC-16 meeting report attributes to the author a claim that more than 60 per cent of ISPs had registered assignments, while close to 40 per cent had registered none. It also records his argument that the existing pressure for registration arrived mainly when an organisation next requested address space and had to demonstrate use against an 80 per cent threshold.

If another request was distant, the database could remain incomplete for a long time. Reverse delegation was proposed as a nearer incentive.

But the reported percentages cannot carry more weight than the record gives them. The meeting summary provides no denominator, extraction date, query, sampling method or independent audit. “No assignment registered” is a description of a query result as reported at a meeting; it is not proof that the address space was unused, that a holder had abandoned it, or that anyone had acted unlawfully. It does not establish why a record was absent, whether an update was pending, or whether the data had been searched at the correct granularity. The figures help explain the proposal’s motivation.

They do not validate every factual inference the proposal’s operation might have made about an individual request.

That distinction is the centre of the institutional problem. A private registry can maintain records, authenticate requests and coordinate a reverse delegation. Those tasks require decisions about whether technical prerequisites are satisfied. Yet a registry record is evidence within an administrative system, not a verdict on a holder’s legal rights or conduct. When a missing object is used to deny a requested delegation, the quality of the matching rule and the correction path matter as much as the policy’s stated objective.

What Draft 1 actually proposed

The operative text had three parts, and each should be read on its own terms.

Section 3.1 contained the prospective delegation condition. AFRINIC would not grant reverse delegation for address space it administered unless an assignment or sub-allocation of that space was appropriately registered. The sealed historical record does not define the precise zone granularity implied by “that address space.” That ambiguity matters. The first draft must be judged by the matching rule it actually stated and by the details it left unstated.

Section 3.2 addressed existing reverse-DNS arrangements whose related allocations had no registered assignments or sub-allocations. It proposed contacting the relevant LIRs, with MyAFRINIC and email envisaged as channels. The operational details were left to Secretariat staff. This was a reminder mechanism, not in itself a specified adjudication system. It did not define the exact contents of a notice, the evidence a recipient could supply, a staff response target, an escalation route or a way to challenge a mistaken match.

Section 3.3 supplied an important limit. AFRINIC would not remove reverse delegation for LIR allocations approved before ratification; only later allocations would be affected. In other words, Draft 1 did not make its new condition a mandate to strip existing pre-ratification delegations. That prospective boundary sharply reduced the immediate blast radius. It preserved working configurations and avoided turning the state of a historical database record into an automatic trigger for removing an established delegation.

The three provisions created an asymmetry. A holder with an existing qualifying delegation would receive reminders but retain the delegation. A holder seeking a new delegation for later address space could be refused if the database did not show the expected downstream object. The policy therefore placed the hardest evidentiary question at the new-request stage: what, exactly, had to be present in the database, and what happened if the registry’s view of the record did not match operational reality?

Calling the proposal “No Reverse Unless Assigned” can obscure that limited historical design. The title sounds absolute. The first draft was not. It paired a condition on new delegation with outreach concerning old records and an express promise not to remove the established delegations described in section 3.3. A later draft followed, but its design belongs to a separate analysis. Draft 1 neither acquired consensus nor became an implemented rule in the captured 2012 record.

Reverse DNS is operational, but it is not routing

The technical mechanism needs only a narrow explanation. IPv4 reverse DNS uses delegated zones beneath IN-ADDR.ARPA and PTR records to associate an address with a name. AFRINIC can sit on the parent side of that delegation chain for address space within its registry-service scope. A holder cannot simply substitute its own parent-side change if the necessary delegation must be configured higher in the hierarchy. That makes the registry’s coordination service an operational dependency.

It does not make PTR a routing protocol. Packets can continue to route without a reverse mapping, and the AFRINIC-16 report records a participant making substantially that point. Missing reverse DNS should therefore not be described as automatically disconnecting a network or causing a universal outage. The risk is narrower: systems and counterparties may use the presence or consistency of reverse and forward names as one signal in access, service or operational decisions. RFC 1912 describes common problems associated with missing or mismatched records and recommends consistent PTR and A records for hosts.

That guidance establishes a plausible reliance surface, not a claim that every application requires reverse DNS.

This is precisely why the proposed refusal deserved more process than a routine database validation error. Its impact could vary. For one operator, delay might be inconvenient but manageable. For another, the inability to publish expected reverse mappings could affect interactions with systems that examine them. The historical record identifies no actual denial, outage or customer loss caused by Draft 1, and none should be invented. Still, uncertainty about magnitude does not erase the dependency.

It strengthens the case for a reversible decision path that can correct an error before a temporary administrative mismatch becomes a prolonged service problem.

The proposal’s strongest practical case followed from this dependency. AFRINIC had to configure the delegation on its side. Requiring the requester to register the relevant downstream assignment before that configuration could align the public responsibility record with the name service being requested. It could also create an incentive at a moment when the holder valued quick action, rather than waiting until the next address request. That is a coherent case for a narrowly defined prerequisite.

It is not a case for punishment. AFRINIC is a private bookkeeper, registry-service operator and technical coordinator. It is not a state, regulator, police force, prosecutor, court, confiscator or sovereign. The fact that operators depend on a service does not enlarge the provider into a public authority. The fact that an official document calls a mechanism “enforcement” does not create sovereign power. At most, the registry can decline to perform a requested technical change until objective prerequisites for that change are verified, subject to fair and effective error correction.

That boundary changes the language and the design. The relevant question is not whether a holder deserves to lose a service for having an imperfect record. It is whether the registry has the evidence it needs to configure the requested delegation accurately and safely. If the evidence is missing, the proper response is a precise validation result and an expedited cure path. Moral judgment, presumptions of abandonment and claims about loss of entitlement have no place in that transaction.

The false-negative problem

Draft 1’s weakness was not that it cared about registration accuracy. It was that it did not describe a reliable way to distinguish a truly missing downstream registration from a record that merely appeared missing to the decision system.

Several states could produce the same outward signal. An operator might have submitted an authenticated update that had not yet completed processing. A database entry might exist at a granularity or under a relationship that the matching routine did not expect. Operational use might have changed faster than the public record. A staff member or automated check might associate the request with the wrong range or zone. An account or contact transition might delay the requester’s ability to present the expected object. None of these possibilities proves that a false negative occurred in 2012.

They are the foreseeable categories a delegation policy needed to handle before treating “not found” as a sufficient decision.

The difference between absence of evidence and evidence of absence is especially important in registry administration. A query can accurately report that it did not find a particular object while remaining silent about why. The result may justify asking for a correction or more information. It cannot, without additional proof, establish that the network is unused, the allocation has been abandoned, the holder has acted improperly or the holder has lost a legal entitlement. Those are different propositions, and some belong in an independent competent forum rather than inside a service desk.

A sound prerequisite therefore needed a defined false-negative test. The decision-maker should be able to state which database object was expected, which address range and reverse zone were examined, which authenticated account requested the delegation, which matching rule was applied, and what result was returned. The requester should be able to answer that precise finding with a correction, a reference to an existing object or evidence that a submitted change was still pending. The decision should move when the evidence moves.

Draft 1 did not provide those mechanics. Its section 3.2 mentioned MyAFRINIC and email for reminders, but it left the details to staff and did not create a reasoned-denial format. It set no service target for accepting a cure. It offered no independent route to review a staff-side matching or authentication error. It did not say how quickly an erroneous refusal would be rolled back or how the incident would be recorded. The policy’s high-level simplicity was purchased by moving critical judgment into an unspecified operational layer.

That is not an accusation against the author, Secretariat or participants. The historical record supports a proposal, a rationale and a discussion, not private motives or misconduct. It is an institutional observation: whenever policy turns a database field into a service consequence, omitted process does not disappear. It becomes staff discretion, software behaviour, queue time and operator uncertainty.

Grandfathering was a substantive safeguard

Section 3.3 deserves more credit than a footnote. By preserving reverse delegations approved before ratification, Draft 1 protected the last verified working state for the population it described. It avoided an immediate exercise in searching old records and disabling established delegations on the strength of a database mismatch. That reduced both technical exposure and evidentiary pressure.

The restraint was institutionally appropriate. Existing working infrastructure represents accumulated coordination: authenticated changes have been made, delegations have been relied on, and operational expectations have formed. Altering that state should require more than a generic record-quality concern. Preservation is particularly important while the registry and holder disagree about whether a record is absent, delayed or incorrectly matched.

Grandfathering also kept the proposal closer to the registry’s legitimate service surface. A new request naturally gives the registry a reason to verify what it is being asked to configure. Retrospectively disturbing an existing delegation would be a different act, with a different continuity burden. Section 3.3 recognised that distinction even though the draft did not articulate it as a full theory of authority.

Yet prospective application did not solve the new-request problem. A new allocation can support real operations, and a new reverse delegation can be time-sensitive. Refusal based on an incorrect match can still create cost. The safeguard limited how many working states were exposed; it did not define what happened to a requester caught by a false negative.

The right conclusion is therefore two-sided but not evasive. Draft 1 showed useful restraint by preserving existing delegations. It still needed a stronger decision architecture for later requests. One judgment does not cancel the other.

What the 2012 discussion settled—and what it did not

AFRINIC-16 discussed Draft 1 on 18 May 2012. The official report records the author’s stated concern about incomplete assignment registration and the proposed incentive. It also records questions from participants about whether the measure would work, whether it was enforceable, what burden it would place on staff and whether port scanning would require consent. The meeting recorded no consensus and returned the proposal to the mailing list.

Those interventions are useful because they reveal that implementation was not a neutral afterthought. If identifying inaccurate records involved active checking, staff effort and possibly scanning, the method of detection mattered. Consent mattered. So did the question of whether a DNS consequence would actually improve registration rather than merely add friction at a service request. The discussion did not resolve those issues; it put them on the record.

The no-consensus result should also be handled carefully. It means the captured process did not adopt Draft 1 at that point. AFRINIC-17 policy slides dated 29 November 2012 still identified the first draft and reproduced its sections 3.1 through 3.3. The annual report later listed the proposal among those discussed and said none gained consensus at AFRINIC-17. Publication, presentation and discussion prove an institutional act and a process state. They do not prove the proposal’s correctness, representative legitimacy or lawful public authority.

Nor does no consensus amount to a sovereign rejection on the merits. A private policy-development process can record agreement or disagreement among its participants. It cannot transform participation into jurisdiction over every affected operator, and it cannot turn its outcome into public law. The evidence permits a narrower statement: Draft 1 was proposed, discussed, questioned and not carried through the recorded 2012 meetings as a consensus policy.

That historical result leaves the design question valuable. The draft captured a recurring registry dilemma: operators benefit from accurate public responsibility records, but a registry can cause harm if it uses a dependent service as leverage without an exact evidentiary and correction path. The policy did not have to be implemented to expose that problem.