Summary

  • UIXP lists two directly connected AFRINIC DNS networks: AFDSP/NS2 under AS37177 and DotARPA under AS37181. AFRINIC’s own deployment guide assigns them different IPv4 and IPv6 anycast prefixes and different DNS roles.
  • A directory row, an RDAP allocation and a PeeringDB interface record establish identifiers and a connection surface. They do not establish a live route advertisement, route-server participation, the answering instance for a query, latency, uptime or resilience.
  • The operational chain is divided again between the host, which supplies infrastructure, power and connectivity, and AFRINIC, which maintains software and configuration, coordinates BGP and monitors service health.
  • A credible Uganda-node receipt would be per service, not per map marker: ASN and advertised prefixes, peering mode, activation and health state, served namespaces, observation time, and distributed query results that identify the answering instance.

Two neighbours in the directory

The most revealing detail on UIXP’s network page is not a traffic number. It is a pair of rows. “AFRINIC - DNS - AFDSP” appears with ASN 37177, an open peering policy and 2025 in the member-since field. “AFRINIC - DNS - DotARPA” appears separately with ASN 37181, the same stated policy and the same year. UIXP says the networks on this page are directly connected to its peering LAN. It also tells the reader to consult the looking glass to learn whether a network uses the route servers and which prefixes it announces.

That qualification is the hinge of the story. The directory proves something useful: two AFRINIC-controlled network identities have exchange-facing interfaces at UIXP. It does not collapse those identities into one logical service, and it does not describe current routing. An exchange member may peer through route servers, through bilateral sessions, through both, or—at a particular instant—through neither in a way that exposes the expected routes. The row is an address-book entry for a control surface, not a packet trace.

The public PeeringDB API supplies a second directory view. In the captured records, both ASNs are associated with UIXP’s exchange identifier, ix_id 422. AS37177 is listed with UIXP peering-LAN addresses ending in .5 on IPv4 and ::5 on IPv6; AS37181 is listed separately with addresses ending in .6 and ::6. Those numbers are not the service anycast prefixes. They are the interfaces through which the two networks can exchange routes at the IXP. This distinction matters. Confusing a peering address with an announced service address can make a network look observable when only its hand-off point is known.

The two rows therefore describe a shared location in the interconnection graph but separate routing actors. A drawing could put both inside one Kampala marker. An operational ledger should not.

AS37177 carries the NS2 chain

AFRINIC’s deployment guide assigns NS2 to AS37177. It pairs that ASN with IPv4 prefix 196.216.168.0/24 and IPv6 prefix 2001:43f8:120::/48. AFRINIC’s programme page describes NS2 as an anycast service supporting African country-code top-level-domain infrastructure and related regional DNS needs.

The service role narrows the authority claim. AFRINIC’s DNS-support description calls AfDSP a secondary, or slave, DNS service. Zone data is transferred from a primary server. AFRINIC says it does not manage the content of the zone. That makes the service operationally important without turning it into the policy authority for every name it answers. The operator can provide an additional authoritative copy and a routing surface; the zone manager remains responsible for the source content and for decisions about the zone.

This boundary also separates the present article from a count of hosted ccTLDs. A zone inventory asks which delegations or address joins reveal use of the NS2 prefixes. The UIXP question is different: is the AS37177 service present, advertised and answering through the Uganda exchange, and from which vantage points? The first inquiry is about the membership of a service set. The second is about the state and locality of one service instance. A map can imply both while proving neither by itself.

RDAP confirms that AS37177 and the published NS2 address blocks are registered under AFRINIC’s organisation record. That is useful identity evidence. It is not live routing evidence. Registration does not show that 196.216.168.0/24 or 2001:43f8:120::/48 was visible at UIXP when these pages were captured, which neighbours accepted the announcements, or which physical or virtual instance a resolver reached.

AS37181 carries a different reverse-DNS chain

The DotARPA row leads elsewhere. AFRINIC’s guide assigns this service to AS37181, IPv4 prefix 196.216.169.0/24 and IPv6 prefix 2001:43f8:110::/48. Its programme page associates the network with the reverse-DNS infrastructure described by RFC 5855, particularly the dedicated service for IN-ADDR.ARPA. The two IPv4 prefixes differ by one in the third octet, and the IPv6 blocks differ by one component. Their visual similarity is an invitation to clerical error, not evidence that they are one service.

RFC 5855 helps explain why the split is substantive. It introduced dedicated nameserver identities for the IPv4 and IPv6 reverse trees so that reverse-DNS service would not share every dependency with unrelated DNS functions. The point is controlled separation. A failure or maintenance event affecting one named service need not become collateral failure for another. AFRINIC’s use of a distinct ASN and prefix family for DotARPA reflects that same legibility at the routing layer.

It would be wrong, however, to promote the DotARPA node into “the reverse DNS for Africa” without qualification. A reverse query follows DNS delegation, caching and referral rules. Whether a particular query reaches a particular anycast instance depends on the namespace being queried, the resolver’s cache state, the routes visible from that resolver and the health of the instance selected by routing. AS37181 is also not a root-server operator merely because the programme sits near AFRINIC’s root-server-copy work. AFRINIC describes that other programme as facilitation for copies operated by root-server organisations.

The roles are adjacent; they are not interchangeable.

RDAP again establishes the registry identity of AS37181 and its two published service prefixes. PeeringDB again records the UIXP interconnection interface. Neither answers the runtime questions. Keeping the chains separate prevents evidence about one service from being borrowed by the other.

Anycast turns “where” into an observation

Anycast allows multiple service instances to use the same service address. Routing selects the instance reached from a given source. That makes a statement such as “the service is in Uganda” incomplete unless the speaker names the layer being described.

At the infrastructure layer, a host may run an appliance or virtual machine in a Ugandan facility. At the interconnection layer, the service ASN may have an interface on UIXP’s peering LAN. At the routing layer, the service prefixes may be announced to selected peers. At the DNS layer, the application may be healthy and authoritative for a defined set of namespaces. At the observation layer, queries from specified vantage points may actually reach that instance. Each layer can be true while the next is false or unknown.

RFC 4786 treats this as an operational property, not a semantic inconvenience. BGP reachability can continue while an application is unhealthy. An operator therefore needs a mechanism that withdraws or suppresses reachability when an instance should not receive traffic. Even when the application is healthy, routing policy may lead a Ugandan source to another anycast site or bring a distant source to Uganda. The network does not promise geographic nearestness; it selects according to the routes available under policy.

RFC 7094 makes the measurement consequence explicit. Anycast behaviour is observed from distributed vantage points. One looking-glass path can establish what that collector sees, not what every resolver sees. One DNS response can establish that an answering instance was reachable from one source at one time, not continuous availability. Repeated measurements with instance identifiers, response metadata and timestamps are needed before words such as “local,” “faster” or “more resilient” become measured claims.

AFRINIC’s public pages describe intended benefits including performance and resilience. Those are plausible architectural goals. This source package does not contain the before-and-after measurements required to attribute either result to the UIXP presence. The responsible conclusion is not that the node delivers no benefit. It is that the public connection records and the operational-outcome records are different objects.

The responsibility boundary is also doubled

AFRINIC’s deployment guide specifies more than addresses. A prospective host needs BGP capability and separate management and peering networks. The published virtual-appliance baseline calls for two virtual CPUs, four gigabytes of memory and ten gigabytes of disk. These requirements describe a deployment interface. They do not reveal whether the UIXP arrangement uses exactly one virtual machine per service, a shared physical host, redundant hosts or some other topology.

The guide divides responsibility. The host supplies infrastructure, power and network connectivity, works to maintain uptime and notifies AFRINIC about outages. AFRINIC maintains the software and configuration, handles security, coordinates BGP, monitors service health and works with the host on troubleshooting. This is not a flaw. Shared service delivery normally requires several operators. It does mean that “AFRINIC node” is too coarse for incident evidence.

Suppose an address remains visible in BGP while the DNS process fails. Route evidence points toward the AFRINIC-controlled health and withdrawal logic, but the initial cause could lie in software, virtualisation, host power or connectivity. Suppose the application is healthy but a local network does not learn the route. The question may move to route-server participation, a bilateral session, filtering or the local network’s own policy. Suppose NS2 responds but DotARPA does not. A map marker still looks green, yet half of the paired service statement is unsupported.

The remedy is not to assign all responsibility to the IXP, the host or AFRINIC. It is to preserve the joins: which service, which ASN and prefix, which peering method, which health signal, which answering instance, which observation and which operator owned the failed transition.

A receipt for each service

A useful public receipt can be compact. It should start with an immutable service identity: NS2/AS37177 with its two published service prefixes, or DotARPA/AS37181 with its own pair. It should name the IXP and the peering-LAN interfaces without mistaking those interfaces for the service prefixes. It should then record whether the node is commissioned, whether the expected IPv4 and IPv6 announcements are visible, and whether visibility comes through route servers, bilateral sessions or both.

The application portion should name the namespaces or service class being checked, the health state exported to routing, and the instance identifier returned or inferred by the DNS measurement method. The observation portion should carry vantage point, resolver mode, query name and type, response code, latency and timestamp. A cryptographic hash of the measurement batch would allow a summary page to remain small while preserving a reproducible evidence set.

No single field proves everything. A commissioned status does not prove a current route. A current route does not prove application health. A healthy response does not prove all intended zones are present. A low latency from one probe does not prove regional improvement. The value of the receipt is precisely that it refuses to substitute one layer for another.

For UIXP, publishing or linking such a receipt would make the existing directory qualification actionable. For AFRINIC, it would preserve the separate meanings of NS2 and DotARPA while demonstrating how each deployment performs. For networks deciding whether to peer, it would expose the exact service routes rather than asking them to infer those routes from an institutional name.

The public evidence already supports a meaningful statement: two AFRINIC DNS service identities are listed as directly connected at UIXP, each with a published operational chain. It does not yet support the more attractive sentence that one Uganda node makes all relevant DNS queries local, faster or resilient. That sentence may become true for defined vantage points. It should arrive with two receipts, not one marker.

Sources

  1. AFRINIC DNS Anycast deployment guide: https://dns.afrinic.net/deployment-guide/
  2. AFRINIC DNS programme: https://dns.afrinic.net/
  3. UIXP connected networks: https://www.uixp.co.ug/networks
  4. UIXP services and route servers: https://www.uixp.co.ug/services
  5. AFRINIC DNS support / AfDSP: https://afrinic.net/dns-support.html
  6. AFRINIC root-server-copy programme: https://afrinic.net/root-server-copy.html
  7. RFC 5855, Nameservers for IPv4 and IPv6 Reverse Zones: https://www.rfc-editor.org/rfc/rfc5855.html
  8. RFC 4786, Operation of Anycast Services: https://www.rfc-editor.org/rfc/rfc4786.html
  9. RFC 7094, Architectural Considerations of IP Anycast: https://www.rfc-editor.org/rfc/rfc7094.html
  10. RFC 1034, Domain Names — Concepts and Facilities: https://www.rfc-editor.org/rfc/rfc1034.html
  11. AFRINIC RDAP, AS37177: https://rdap.afrinic.net/rdap/autnum/37177
  12. AFRINIC RDAP, AS37181: https://rdap.afrinic.net/rdap/autnum/37181
  13. AFRINIC RDAP, 196.216.168.0/24: https://rdap.afrinic.net/rdap/ip/196.216.168.0
  14. AFRINIC RDAP, 196.216.169.0/24: https://rdap.afrinic.net/rdap/ip/196.216.169.0
  15. AFRINIC RDAP, 2001:43f8:120::/48: https://rdap.afrinic.net/rdap/ip/2001:43f8:120::
  16. AFRINIC RDAP, 2001:43f8:110::/48: https://rdap.afrinic.net/rdap/ip/2001:43f8:110::
  17. PeeringDB API, AS37177 exchange interfaces: https://www.peeringdb.com/api/netixlan?asn=37177
  18. PeeringDB API, AS37181 exchange interfaces: https://www.peeringdb.com/api/netixlan?asn=37181