Summary

  • AFRINIC documents the WHOIS source value as the string that identifies the database. It is namespace metadata, not a complete record-level provenance certificate.
  • The -q sources response also reports mirroring capability and available serial ranges. Those fields help identify a service and diagnose replication, but do not identify the original author or present legal owner of an individual record.
  • Maintainer authentication, update history, allocation documents and time-aligned routing observation answer different questions. None can be inferred from source: AFRINIC alone.

A label that resembles a citation

Registry records carry compact fields because they must be queried, mirrored and processed. A reader approaching one record in isolation may interpret source: AFRINIC as a declaration that AFRINIC originated every statement in the object, verified its current truth, or stands behind the record as a chain-of-custody authority. The label does not carry all of those meanings.

AFRINIC’s reference manual explains the -q sources query as a way to list the sources available from the WHOIS server. In the response grammar, the source is “the string that identifies the Database”, with AFRINIC as the example. The same response includes a mirroring indicator and the lowest and most recent serial numbers available. The operational object is therefore a served database namespace and its replication surface.

That is useful information. A client can identify the database it queried. A mirror operator can compare source names and serial windows. An investigator can avoid silently mixing records from different registry namespaces. But none of those operations reconstructs the history of one object.

Namespace attribution is not authorship

A database may serve a record that has passed through several hands. A resource holder, sponsoring organisation, maintainer or registry operator may have supplied or changed different attributes at different times. A mirror may reproduce the current object without preserving every decision that produced it. The source label remains stable while the people, credentials and evidence behind individual changes may differ.

Record provenance therefore needs a more specific ledger. The relevant questions include which update was submitted, which authentication method satisfied the maintainer rule, which object version resulted, what allocation or transfer document supported the change, and whether any registry intervention occurred. source: AFRINIC does not answer those questions merely by appearing at the bottom of the object.

The boundary also protects AFRINIC from overclaiming. Identifying a database need not mean that the registry independently warrants every contact name, route policy or organisational description as a presently verified fact. It means the record is being served in the named database context. Accuracy, authority and legal effect each require their own evidence.

The mirror fields reveal the operational purpose

The shape of the -q sources response is instructive. Alongside the source name, the manual describes whether mirroring is allowed and which serial numbers are available. Those are properties of database distribution. They let operators reason about replication eligibility and about the window of updates a service can supply.

A serial range can support a diagnosis of mirror state, but it is not self-sufficient proof that a specific mirror has consumed every update or is returning the same object version at the same moment. That comparison requires observations from the relevant services. Nor does a recent serial prove that the underlying record is factually correct; a precisely replicated error remains an error.

This gives operators three distinct clocks. The database has an update sequence. A mirror has a replication position and query time. The network has an observation time. Conflating them creates false confidence: a fresh WHOIS response can contain an old claim, and a recently updated route object can describe a policy that is not visible in BGP.

Registration and routing require separate proof

The source label belongs to the registration system. It cannot establish that a prefix is being announced, that an autonomous system originates it, that another network accepts the route, or that traffic follows a particular path. Those claims require route collectors, operator telemetry or other time-aligned observations, interpreted with their own coverage limits.

The same separation applies to ownership. A database record may be relevant evidence in an allocation, assignment or transfer inquiry, but the string naming the database does not itself prove present legal title, beneficial ownership or contractual authority. An investigator should follow the actual registration documents and change controls rather than treating a namespace label as the conclusion.

A practical evidence sequence

For a directory investigation, preserve the query endpoint, time, exact response bytes and source label first. If replication matters, capture the -q sources output and serial range from each service being compared. Then obtain the object history and identify the maintainer and authentication path relevant to the disputed change. Link those records to allocation, assignment or transfer documents where the question requires them.

Only after that should the investigation compare registration claims with operational measurements. Record the collectors, vantage points, timestamps and limitations of the BGP evidence. A mismatch is a finding to explain, not automatic proof that either system is fraudulent or broken.

Sources