Summary

  • APNIC's published conditions for a transfer from its account holder to a member of another RIR require the APNIC source to pay the transfer fee. Associated sub-assignments, route objects and domain objects, if present, are deleted from the APNIC Whois Database.
  • The transfer changes the registered holder. It also removes the source registry's public records about customer use, routing assertions and reverse-DNS delegation. Those records need their own inventory and replacement sequence.
  • APNIC's route-object and reverse-DNS guides show why the records matter: route objects identify a prefix's originating AS in Whois, while domain objects carry the nameserver information APNIC uses for reverse delegation.

One sentence in APNIC's Transfer Conditions should be stapled to every outbound IPv4 transfer file. When resources leave an APNIC account holder for a member of another regional Internet registry, APNIC deletes all associated objects from its Whois database. Its examples are sub-assignments, route objects and domain objects. The source pays the transfer fee. At completion, the source loses rights to the resources and the recipient becomes their registered holder. That is a clean change of custody with a less tidy change of operating records.

A buyer may be accustomed to a single question: when will the address block show our name? The deletion rule asks three more. Which customer assignments currently sit under the block? Which route objects describe its announced origin? Which reverse zones point to authoritative name servers? An account can answer the first question and still discover the other three only after its old public record has disappeared. APNIC's process puts those questions on the desk before the transfer closes.

The scope is narrow enough to matter. APNIC's transfer overview lists five scenarios, including transfers between APNIC accounts, with national Internet registries, and between regional registries. The deletion sentence belongs to the outbound inter-RIR case: an APNIC account holder sends resources to a member of another RIR. A domestic APNIC-to-APNIC transaction follows a different operating path. The rule is also distinct from the 30-day recipient acknowledgement in APNIC's intra-region IPv4 transfer guide. This handoff is about what happens to the originating registry's records when the resource leaves its jurisdiction.

Start with the route object. APNIC's guide to creating route objects says that a route or route6 object in its Whois database specifies an interdomain route originating from an autonomous system. To create one, the relevant address-range and AS records must exist, and their mnt-routes authorizations must line up. The object is a published registry assertion about a prefix and origin. Delete the associated object and that APNIC assertion disappears. The receiving holder needs to know where its replacement routing record will live, who can authorize it, and when it becomes visible to networks that use registry data. A transfer contract that merely lists the prefix and price leaves those questions unanswered.

Then the customer assignments. A sub-assignment records that part of a resource is used by another party under the holder's umbrella. APNIC names those objects explicitly in the deletion clause. A buyer taking over a block with downstream users needs an inventory before closing: prefix boundaries, the customer associated with each entry, the contact that must remain reachable and the registry capable of publishing the new record. If an operator cannot reproduce the assignment trail after the old entries disappear, the holder name may be accurate while the public account of actual use is thinner.

That matters for incident response, abuse handling and the routine question of who can be contacted about a specific address.

The domain objects are the more easily missed part. In APNIC's reverse-DNS guide, a domain object carries the nameserver information for an in-addr.arpa or ip6.arpa reverse zone. APNIC uses Whois data to generate its reverse-zone delegations, refreshing the APNIC name servers from the database every two hours before normal DNS caching and refresh take their turn. The holder runs its own authoritative reverse zone and PTR data; APNIC publishes the delegation to those servers. Erasing the source registry's domain object therefore removes an instruction in the delegation chain. The receiving registry's corresponding record, nameserver authority and timing need to be planned as a separate piece of work.

The fee line reveals another handoff asymmetry. For the outbound inter-RIR case, APNIC says its account holder pays the transfer fee. That actor is the source, even if a private contract assigns the economic cost differently between buyer and seller. The registry's invoice recipient and the parties' commercial settlement are separate facts. A closing checklist should name the APNIC account that can pay, the payment evidence and the staff contact who can answer APNIC's final questions. It should name the receiving registry contact with equal precision.

The public APNIC conditions provide the fee direction and object-deletion rule; they do not provide a universal cross-registry closing calendar.

The operational hazard is a false sense of completion. A registrar-facing search may show the new holder. A project team may mark the transaction done. Yet the source's route, assignment and reverse-domain objects are scheduled to vanish from APNIC Whois. Their replacement depends on the receiving side's own system and authority. The right measure of completion is a set of dated records: source object inventory before transfer, APNIC's transfer completion, recipient registration, replacement routing and customer records, reverse-delegation evidence and a check of what outside queries actually return.

Each item has a different owner and a different failure mode.

APNIC's public pages do not state when a receiving RIR creates replacement objects for any particular transfer. A dated receiving-registry record would settle that handoff for a specific prefix.