When a Registry Record Changes Without Warning: A Practical Response

First, describe the change precisely

An unexpected registry change can mean several different things: a contact changed, a registration record was edited, an IRR object changed, an RPKI authorisation no longer matches, or a route was announced differently. These events can be related, but they are not interchangeable.

Begin with the exact resource, timestamp, source and observed difference. A precise description prevents a routing problem from being treated as proof that ownership changed, or a record dispute from being treated as proof that every route is unsafe.

Preserve the last known-good state

Capture the registry response, RDAP or WHOIS result, IRR objects, RPKI certificates and ROAs, route observations, relevant contacts, contracts and internal change records. Keep the time and source with each copy. The goal is to make the before-and-after comparison possible while systems continue to change.

Do not overwrite the evidence with a later lookup. The latest record may be the disputed state. A reliable timeline is often the only way to show whether the change began in the registry, in the route, in a provider system or in an internal account.

Check authority and impact separately

Ask who made the change, which function they were authorised to perform and which systems consume the result. Then map the operational impact: routes, filters, security assertions, customer access, mail, monitoring, contracts and external allow-lists.

A registry can maintain a record without receiving a mandate to decide every consequence that follows from it. Note 52 is useful here because it keeps power and liability in the same frame: the institution that can change the record may not be the institution that bears the cost.

Respond without turning urgency into a permanent veto

During an incident, operators need a safe way to stop an unauthorised change from spreading. That does not mean every emergency response should become a permanent power to police future transfers or commercial decisions. Verify the evidence, contain the immediate technical risk and keep the correction path visible.

Note 74 distinguishes a genuine need for evidence from an unlimited pre-approval right. Note 69 adds a warning about relying on calm history: a process can look stable while leaving no usable answer when the decision itself is contested.

Prepare the exit before the record is disputed

A recovery plan should say how a qualified replacement can verify control, preserve uniqueness, update the public record and coordinate routing and security changes. It should identify the people and systems that must recognise the transition. It should also define what evidence remains private and what other networks need to see.

Note 72 gives the design principle: keep accurate common records, but make the administrator replaceable. If the only recovery path is to persuade the incumbent to release the resource, the business has discovered a structural dependency rather than a temporary incident.

The checklist is a rehearsal, not a document

Run the response against a synthetic change. Can the team retrieve the old state? Can it tell a bad record from a bad route? Can it identify the decision maker and the actual scope of authority? Can customers and providers continue while the record is corrected? Can another coordinator be recognised if the original one cannot act?

A registry change becomes manageable when the organisation already knows what must be proved, who must be contacted and which alternatives exist. The urgency is therefore before the change, while the system still has time to build a credible exit.