Summary

  • AFRINIC’s current ccTLD map loads 27 rows and marks every row hosted; a frozen DNS snapshot found an AFRINIC-labelled hostname in 24 delegation sets.
  • The three apparent exceptions—.so, .ng and .ml—each had IPv4 and IPv6 nameserver addresses inside AFRINIC’s published NS2 prefixes, so the total survives an address-level check.
  • A dated hosted-zone receipt should expose the hostname-to-address-to-prefix join, without pretending that DNS data proves a contract, node location, uptime or control of zone content.

Twenty-seven is a reassuringly tidy number. AFRINIC’s DNS programme page says it hosts authoritative DNS for more than 25 African country-code top-level domains. The linked distribution map is more precise: its current CSV contains 27 unique country and ccTLD rows, and the browser code assigns every row the status isHosted: true.

The count is not the problem. The missing object is the proof beneath it.

A reader trying to reproduce the map from public delegations gets to 24 by the obvious route. Names such as ns-bi.afrinic.net, ns-bj.afrinic.net and ns-dz.afrinic.net advertise the institutional connection in the hostname. Three delegations do not: .so, .ng and .ml contain no nameserver name with the string afrinic. Stop at the labels and the map appears to overcount. Continue to the addresses and the three rows reappear.

Three links concealed by perfectly valid names

For .so, the relevant server is d.nic.so. In the frozen 12 September DNS snapshot it resolved to 196.216.168.54 and 2001:43f8:120::54. IANA’s delegation record publishes the same pair.

For .ng, the bridge is ns5.nic.net.ng, at 196.216.168.41 and 2001:43f8:120::41. For .ml, it is d.nic.ml, at 196.216.168.37 and 2001:43f8:120::37. Again, the current IANA delegation pages provide the same addresses.

AFRINIC’s deployment guide supplies the final side of the join. It identifies AS37177 as the NS2 service and publishes 196.216.168.0/24 and 2001:43f8:120::/48 as its IPv4 and IPv6 anycast prefixes. Each of the six addresses above sits inside the corresponding prefix. The same test found at least one nameserver address in each published prefix for all 27 CSV rows.

That is strong support for the public total. It is also a demonstration of why a hostname is a poor proxy for an operator. A ccTLD manager may retain a locally meaningful server name while the address points into a shared secondary service. Renaming every server to display the supplier would be cosmetic and potentially disruptive. The sensible remedy is not a naming rule. It is a visible relationship record.

What the map says and what it leaves implicit

The CSV has only country, ccTLD and flag fields. Its client code turns each row into a hosted country and displays the length of the array as the statistic. There is no row-level observation time, delegated hostname, address, matched service prefix, first-seen date or status history.

This makes the map easy to read and hard to audit. If a ccTLD changes a nameserver, retires the AFRINIC secondary, adds a white-label hostname or shifts one address, the public total may remain correct while the evidence path changes. A reader cannot tell whether a row was confirmed this morning, copied from an earlier inventory or awaiting a delegation update.

None of this establishes that a current row is stale. The frozen check found a technical path for every one of the 27. Nor does the address join prove everything the word “hosted” might suggest. It does not identify a physical node, show which anycast instance answered a particular user, measure latency, prove uptime, reveal an agreement or establish who may alter zone content.

AFRINIC itself draws the last boundary clearly. Its DNS Support Program describes the service as slave or secondary DNS. Zone data is replicated from the operator’s master or primary server; AFRINIC says it does not manage the zone or its content. Infrastructure service and policy authority are not the same thing.

Publish the receipt, not just the total

A useful hosted-zone receipt can remain compact. For each row, it would show the ccTLD, the delegated hostname used for AFRINIC service, the observed IPv4 and IPv6 addresses, the matched service prefix and origin reference, the source and timestamp of the observation, and whether the relationship is active, pending, retired or temporarily unavailable.

It should also preserve first-seen, last-confirmed and status-change dates. That history matters more than decorative certainty. When a hostname changes but the service does not, the record should show continuity. When an address leaves the published prefix, the row should not silently disappear; it should move to a review state with a correction channel.

The receipt need not publish contracts, technical contacts or sensitive node coordinates. It should not convert a DNS observation into a service-level guarantee. Its task is narrower: show the exact public evidence used to include a zone in the total and label the limits of that evidence.

The strongest defence of AFRINIC’s design is simplicity. A public map is not a configuration-management database, and ordinary readers benefit from a clear count rather than a page of DNS machinery. The current number also withstood the frozen address test. But simplicity at the front end does not require invisibility at the evidence layer. A short expandable receipt would let both audiences use the same map.

This matters because shared infrastructure often travels under someone else’s name. The .so, .ng and .ml rows are not anomalies to eliminate. They are the cases that reveal the real architecture: local naming at the delegation layer, common service at the address layer, and a registry claim at the presentation layer. A trustworthy total should keep those layers joined without collapsing them.

Sources