Registry-State Export: How to Make Internet Number Records Recoverable

When a registry is available, an Internet number resource can feel like a simple lookup. You query an IP prefix or an autonomous system number and receive a record. That record is useful, but it is only one view of a larger state: who the registry recognized, what changed, which services were delegated, which routing authorizations existed, and what evidence supports the current answer.

The harder question appears when the registry is unavailable, disputed, compromised, or being replaced. Can the legitimate state of the resource still be understood and verified by someone who does not have the original database and internal procedures?

The continuity question: if the current registry system stops answering tomorrow, what information would a legitimate holder or successor need to reconstruct the last verified state without inventing a new one?

Start by separating three different states

Many registry discussions become confusing because three different questions are treated as one:

• Registry state: what an authority currently records about the resource, the recognized holder, contacts, events, delegation and status.
• Operational state: how the resource is being used in practice, including reverse DNS, provider relationships and service continuity.
• Routing state: which autonomous system is originating a route and whether the relevant routing authorization is valid.

These states can agree, but they do not have to change at the same time. A prefix can move between providers while its recognized holder remains the same. A registry record can be correct while a route is misconfigured. A routing authorization can be valid while a contact object is obsolete. A useful export must preserve the relationships between these states and show which statement each piece of evidence supports.

What RDAP gives you, and what it does not

RDAP is the standard lookup layer for registration data. Its JSON model describes objects such as IP networks, autonomous system numbers, entities, events and links. That makes a live record easier to query and interpret across registries. The structure is defined by RFC 9083.

RDAP answers a present lookup question: what does the serving registry return for this object now? It may include the current record and event information, but a live response is not automatically an independent continuity package. It does not by itself guarantee that a holder has a portable, authenticated sequence of prior states, a complete transition record, or the material needed for an orderly successor process.

That difference matters. A live directory is a window into a system. A registry-state export is a way to preserve enough verified state to reason about continuity when the window, the system, or the institutional relationship changes.

What RPKI proves, and what it does not

RPKI answers a routing question. A Route Origin Authorization identifies an autonomous system that the address-space holder has authorized to originate routes for one or more prefixes. The profile and validation rules are described in RFC 9582.

This is valuable evidence, but it is not a complete answer to every registry question. A valid ROA does not by itself prove the full legal or administrative history of a resource, identify every operational contact, establish reverse-DNS continuity, or resolve a dispute about which registry state should be recognized. RPKI authorization is one layer in a continuity record, not a replacement for the record.

A working definition of registry-state export

Registry-state export is a proposed continuity package that makes the essential verified state of an IPv4, IPv6 or ASN resource portable, understandable and testable. It should allow an independent reader to answer four questions:

1. What resource and recognized holder are we talking about?
2. What was the last verified state and when did it become effective?
3. What material changes happened after that state?
4. What evidence and authority support a legitimate transition or successor process?

This is more specific than a database dump and more useful than a screenshot. The export should contain the state a successor needs, while leaving out unrelated customer data, private business strategy and internal implementation details that do not establish the resource.

The minimum useful export

A practical export can be organized into a small set of connected records. Each record should carry a stable identifier, an effective time, its source, and enough information to detect an unexplained change.

• Resource identity: the IPv4 prefix, IPv6 prefix or ASN, its parent or allocation relationship where relevant, and its registry identifiers.
• Recognized holder: the organization or entity recognized at the verified state, the registry identifier, effective date and status of that recognition.
• Contacts: administrative, technical, abuse and security contacts that a successor or relying party actually needs.
• Material history: transfers, name or organization changes, delegations, status changes, disputes and the evidence or authorization associated with each event.
• Operational relationships: relevant provider, delegated-user, reverse-DNS and service relationships, with effective periods and termination state.
• Routing and security references: the relevant origin ASN, ROA or RPKI object references, publication state and the time at which that state was observed.
• Conflict state: whether a dispute, hold or conflicting claim exists, what resource it affects, and the last state that was not disputed.
• Audit trail: who changed what, when, under which authority, from which value to which value, and with what verification result.
• Integrity information: version numbers, timestamps, object hashes, signatures and an export manifest so a recipient can verify the source and detect modification.

The export does not need to reproduce every internal database table. It needs to preserve the relationships that make the public answer meaningful and the transition auditable.

Why a backup is not enough

A backup is usually designed to restore a system for the same operator. Registry-state export is designed to let another authorized party understand and verify the state when the original system, organization or operating arrangement cannot simply be restored.

• A backup may require proprietary software, undocumented relationships and the original credentials.
• An export should be readable by an independent successor and should identify the evidence behind each material claim.
• A backup may contain far more data than a resource holder is entitled or willing to receive.
• An export should be scoped to the resource, authenticated, machine-readable and portable.

The distinction is not a technical preference. It is the difference between preserving a machine and preserving the ability to recognize a legitimate state.

What happens when continuity is needed

A continuity process should not begin by allowing two systems to claim the same resource. It should begin by freezing the last verified state and making the transition explicit.

1. Identify the trigger: outage, insolvency, compromise, migration, dispute or another defined continuity event.
2. Preserve the last verified state: record the resource, recognized holder, contacts, material history and the evidence supporting that snapshot.
3. Verify the export: check signatures, hashes, timestamps, authorization references and the integrity of the manifest.
4. Separate evidence layers: compare registry state with operational use, reverse DNS, routing observations and RPKI state instead of treating one layer as proof of all others.
5. Record the successor: define how the previous state is superseded, how conflicts are handled and how relying systems discover the recognized successor.
6. Publish the transition: make the new state and its effective time discoverable, while retaining the prior state as an auditable historical record.

The process is designed to preserve continuity without turning an outage into an opportunity for an unverified claimant to rewrite history.

What registry-state export must not do

A continuity export is not a second registry that gives every recipient power to assert ownership. It should not create parallel claims, bypass the applicable resource policy, expose customer traffic or confidential strategy, or silently convert operational use into recognized administrative control.

The export should also state its limits. If a field is unavailable, redacted or disputed, the record should say so. An honest unknown is safer than a complete-looking value with no evidence.

How to test an export before a crisis

A resource holder or operator can test the concept with a simple review:

• Can an independent reader identify the exact IPv4, IPv6 or ASN resource?
• Can the reader identify the last verified recognized holder and the effective date?
• Can the reader reconstruct material transfers, delegations and organization changes?
• Can the reader distinguish registry state from current routing and operational use?
• Can the reader locate the relevant RPKI and reverse-DNS evidence?
• Can the reader see whether a dispute or conflicting claim exists?
• Can the reader verify who produced the export and whether it changed afterward?
• Can a legitimate successor use the record without importing the original private database?

If the answer to these questions is no, the organization may have a live lookup or a backup, but it does not yet have a tested continuity record.

How this fits the IPv4 lifecycle

An IPv4 resource has a lifecycle that includes registry records, transfers, operational delegation, routing and eventual change of use. The export is the connective tissue between those moments. Start with what registry data can show about an IPv4 lifecycle, then distinguish regional movement in inter-RIR transfers from a routing change in BGP rehoming.

The same reasoning applies to the broader governance question: when a system coordinates unique resources, the ability to verify and carry the state should not depend entirely on one unavailable administrative point. That is why registry-state export belongs alongside the practical questions of what happens if an Internet registry fails and what proof of control can actually show.

Conclusion

Registry-state export is a way to make continuity concrete. It does not replace RDAP, RPKI, routing data, reverse DNS or registry policy. It connects the relevant evidence into an authenticated, versioned and portable record that a legitimate reader can understand when the original system cannot simply be trusted or restored.

If the registry disappears, the goal is not to let anyone claim the resource. The goal is to preserve enough verified state that the legitimate answer can still be recognized, tested and carried forward.