Summary

  • LACNIC’s last changed value records when information in a particular RDAP object was last changed; it does not, by itself, date a transfer, BGP cutover, traffic migration or commercial handover.
  • One live response for 200.7.85.1 shows a network record last changed in 2024 and two embedded entities last changed in 2026. The three clocks are not contradictory: they apply to different objects.

Analysis

On 26 August 2026, a query for 200.7.85.1 at LACNIC’s RDAP service did not return a single-address biography. It returned the enclosing network object, 200.7.84.0/23, covering 512 IPv4 addresses from 200.7.84.0 through 200.7.85.255. The record described the block as assigned and carried two top-level events: registration on 25 January 2008 and last change on 17 September 2024.

The same JSON response also embedded a registrant entity and a contact entity. The registrant handle, UY-LACN-LACNIC, was last changed on 7 August 2026. The handle AIL, serving administrative, technical and abuse roles in that response, was last changed on 20 January 2026. A hasty timeline would line up those dates and call them successive changes to “the network”. The data says something narrower and more useful. The 2024 timestamp belongs to the IP network object. The two 2026 timestamps belong to entity objects with their own registration information.

That object boundary is part of the RDAP standard. RFC 9083 defines the events structure as representing events that occurred on an instance of an object class. It registers last changed as an action noting when the information in that object instance was last changed. It also defines separate actions for registration, reregistration, transfer, expiration, deletion and reinstantiation. Those verbs are not stylistic variations. They encode different claims.

LACNIC’s own Whois guidance uses the same discipline. For an Internet resource, changed is the date on which the resource information was last modified. For a contact, changed is the date on which that contact information was last modified. LACNIC presents RDAP as a standardized HTTP and JSON route to Whois registration information. The service makes records easier to parse; it does not broaden what a record can prove.

This matters because a timestamp feels conclusive. In acquisition diligence, incident response or a dispute over an address block, “last changed” may be copied into a chronology as though it marked the day control moved. But the field does not reveal which attribute changed. The live network response does not name an actor for its top-level events. It does not say that the registrant changed, that a sale closed, that a contract took effect or that equipment moved. It says the information in that network object was last changed at the stated time.

The distinction is even sharper for routing. BGP, specified in RFC 4271, distributes reachability information between autonomous systems through routing updates and route-selection machinery. A router does not wait for an RDAP event before advertising a prefix, and an RDAP timestamp does not report whether an upstream accepted, filtered or withdrew a route. A network could change its contact information without changing a single route. It could also move traffic, change an origin AS or cut customers over without producing a corresponding last changed event at the moment an investigator expects.

The correct use of the field is therefore affirmative, not dismissive. It gives a reliable lower-level proposition: by that timestamp, information in this identified object instance had been changed. It helps investigators choose windows for archive retrieval, compare successive snapshots and ask who had authenticated access to the resource-management system. It can corroborate a broader account. It should not be promoted into the broader account on its own.

A disciplined timeline keeps at least four lanes separate. The registry lane contains RDAP or Whois objects and their event dates. The corporate lane contains signed agreements, board approvals, closing documents and legal notices. The routing lane contains BGP collector history, origin changes, path changes and withdrawals. The service lane contains customer cutovers, DNS changes, monitoring and traffic observations. Events across those lanes may cluster around a genuine handover, but alignment must be demonstrated rather than assumed.

The absence of an event also has limits. RFC 9083 includes a transfer action, but the live LACNIC response examined here reports registration and last change, not transfer. That does not prove no commercial or operational handover ever occurred. It proves only that this response does not report one as a transfer event. Silence in one evidence system is not evidence that every other system was silent.

For readers, the practical test is simple: name the object before naming the event. “The IP network object was last changed” is faithful. “The network changed hands” is a different claim requiring different evidence. RDAP’s precision survives only when the analyst preserves that grammar.

Sources