Summary

  • APNIC logged the exact IPv4 range 125.253.132.0–125.253.135.255 moving from GLOBECOMM SYSTEMS INC. to Indonesia Network Information Center/NUSA-ID at 02:32:56 UTC on 19 June 2026, then moving back at 08:03:11 UTC. The second entry came 5 hours, 30 minutes and 15 seconds after the first.
  • The current APNIC RDAP record names GLOBECOMM SYSTEMS INC. as registrant and dates its registration update to 08:03:32 UTC, 21 seconds after the return entry. The public transfer rows carry no common case key explaining the reversal.

The address block left home and came back before lunch, according to the bookkeeper. In APNIC's cumulative transfer file, one RESOURCE_TRANSFER entry sends the range 125.253.132.0–125.253.135.255 from GLOBECOMM SYSTEMS INC. to Indonesia Network Information Center/NUSA-ID at 02:32:56 UTC on 19 June 2026. A second entry returns precisely the same range from NUSA-ID to GLOBECOMM at 08:03:11 UTC. The interval is 5 hours, 30 minutes and 15 seconds. The 1,024 IPv4 addresses have not changed their boundaries by one address. Two registry receipts point in opposite directions.

That geometry matters more than the theatrical clock. A /22 has 1,024 addresses; the start and end in both entries form that exact block. Both entries name APNIC as source and recipient RIR. The organization names reverse exactly, while the first entry marks GLOBECOMM with country code ZZ and NUSA-ID with ID; the return does the converse. There is no intermediate slice, third organization or cross-RIR handoff in those two rows. The issue is the relationship between the two receipts, not a search for a missing third transfer.

APNIC's transfer log publishes transfers as individual rows; its format documentation describes the cumulative files. The scheme is useful: dates, resource bounds, parties and registry names can be checked without asking either organization for its own version of events. But it gives this pair no shared public case number, correction flag or reason code. A reader can establish the sequence, not the causal explanation. A linked APNIC case record explaining the reciprocal entries would change that assessment.

The live APNIC RDAP record for the range supplies a second clock. It gives the same start and end addresses, the name GLOBECOMM-AP, and registration and last-changed events at 08:03:32 UTC on 19 June. The registrant handle ORG-GSA1-AP resolves to GLOBECOMM SYSTEMS INC.. The event time is 21 seconds after the second transfer entry. That is strong evidence about the resulting public registry state. It is not a diary of how routing, customer service or internal account processing unfolded during the preceding five and a half hours.

APNIC's resource transfer guidance explains why names in this ledger matter: transfers move number-resource registrations between legal entities, and APNIC updates its Whois database. The public file here therefore cannot be brushed off as mere visual noise. A holder seeking to verify control of a scarce resource needs a sequence it can defend to counterparties. When two opposite entries occupy one morning, the registry should make clear whether they are two completed transfers, a correction, or something else. The file makes none of those choices public.

This is a small case with a large bookkeeping lesson. The current registration ends where it started. That does not erase the outbound row: it remains in APNIC's dated transfer history. Equally, the outbound row cannot by itself prove that the block was carried on NUSA-ID's network for five hours. Transfer registration and route origination are different surfaces. The public record proves two recorded directions and a final holder, and stops there.

The puzzle is administrative, not paranormal. If a registry can publish two precise timestamps 19,815 seconds apart, it can attach the public relation between them. Otherwise, its beautiful precision becomes a way of hiding the only sentence operators need: what happened to the first receipt when the second was issued?