What Is Registry-State Export for Internet Number Resources?

Registry-state export is the concept of creating an authenticated, portable and auditable copy of the essential registry information associated with an Internet number resource. For an IPv4 block, IPv6 prefix or Autonomous System Number, that export could include information such as:

• the Internet number resource;
• recognized holder information;
• relevant contact objects;
• registration status;
• transfer history;
• delegation information;
• reverse DNS information;
• RPKI-related metadata;
• dispute or conflict status;
• material change history; and
• audit records needed to understand the current verified state.

The purpose is not simply to create a backup file. A useful registry-state export should make it possible to answer a more important question:

If the system currently maintaining a resource record becomes unavailable, disputed or unable to provide essential services, can the legitimate registry state still be independently understood and reconstructed?

That makes registry-state export a question of continuity, auditability and portability, not merely data download. It is also important to distinguish the concept from existing protocols such as RDAP. RDAP provides structured access to Internet registration information, but a complete registry-state export would potentially contain additional continuity information, historical context, authorization relationships and audit data needed to reconstruct a resource’s verified state. In other words: RDAP helps you query registry data. Registry-state export would help preserve the state needed for continuity.

Why Does Registry-State Export Matter?

Internet number resources can remain operational for many years. During that time:

• companies can change names;
• organizations can merge;
• resources can be transferred;
• addresses can be leased or delegated;
• providers can change;
• routing can move between ASNs;
• technical contacts can change;
• RPKI information can change;
• reverse DNS can move; and
• disputes can arise.

The resource itself may remain embedded in a running network throughout those changes. That means the useful state of an Internet number resource is more than a single row in a database. It can be the result of years of verified changes. If that history becomes inaccessible, network operators may still know that an IPv4 block is running, but reconstructing why the current registry state is legitimate can become much harder. A registry-state export is intended to reduce that dependency. The principle is straightforward: Critical registry information should remain durable even when the organization, platform or infrastructure currently maintaining it changes.

Registry Function Is Different From Registry Institution

This distinction is central to understanding registry-state export. The Internet requires certain number-resource functions. Networks need:

• globally unique identifiers;
• accurate registration information;
• reliable contact information;
• transfer records;
• reverse DNS continuity;
• routing-security information;
• auditable changes; and
• mechanisms for resolving conflicting claims.

Those functions matter. But the function and the institution currently performing the function are not necessarily the same thing. A database platform can change. An organization can restructure. Software can be replaced. Operational responsibilities can move. A registry environment can experience technical, financial, legal or organizational disruption. None of those events should automatically make the historical state of Internet number resources impossible to reconstruct. This is why The Registry Continuity Fallacy distinguishes continuity of the ledger from permanence of the organization operating it. Registry-state export follows the same principle:

Protect the registry function by making the state recoverable.

That is different from assuming one institution must remain unchanged forever.

What Should a Registry-State Export Contain?

A useful export should contain enough information to reconstruct the resource’s relevant verified state. The exact technical format would need specification, but the information can be divided into several categories.

1. Internet Number Resource Information

The export should clearly identify the resource. For example:

• IPv4 prefix;
• IPv6 prefix;
• Autonomous System Number;
• relevant parent or allocation relationship;
• resource status; and
• applicable registration identifiers.

Without a precise resource identity, the rest of the export has little value. For example:

IPv4: 192.0.2.0/24

or:

ASN: AS64500

The resource should be machine-readable and unambiguous.

2. Recognized Holder Information

The export should record the organization associated with the recognized registry state. Relevant information may include:

• organization name;
• registry identifier;
• organization ID;
• relevant legal or organizational reference;
• effective date; and
• status of the registration.

This does not mean a registry record should be treated as a universal legal title document. It means that a continuity system needs to know:

Who did the registry recognize at the last verified state?

That provides a baseline from which later changes can be examined.

3. Contact Objects

Internet number-resource records often contain several types of contacts. These may include:

• administrative contacts;
• technical contacts;
• abuse contacts;
• security contacts; and
• other operational contacts.

Current registration-data systems can expose many of these relationships through WHOIS or RDAP. A registry-state export, however, should preserve not only the currently visible contact but enough information to understand the relevant verified relationship at the time of export. This becomes important when staff leave or organizations restructure.

4. Transfer and Change History

Current state is important. History can be equally important. Suppose an IPv4 block changes from Organization A to Organization B. A current registry query might show:

Organization B

But a continuity system should ideally also be able to establish:

• when the change occurred;
• what the previous state was;
• what type of change occurred;
• whether the transition was verified;
• which authorization supported it; and
• when the new state became effective.

A registry-state export does not necessarily need to expose confidential transaction information publicly. But the continuity architecture should preserve enough authenticated history to establish that the state transition occurred legitimately. This turns the registry from a snapshot into an auditable ledger.

5. Operational Delegation Information

The registered holder and the operational user of Internet number resources may be different. For example: Resource holder → lessor → lessee → hosting provider → upstream network A continuity-capable registry may therefore need to record appropriate information about recognized operational delegation. That could include:

• delegated prefix;
• operational user;
• effective period;
• delegated contacts;
• routing relationship;
• authorization status; and
• expiry or termination status.

Not every commercial detail needs to become registry data. The purpose is to preserve information relevant to Internet coordination. This distinction is explored more broadly in The Policy Mirror, where operational delegation is treated as a registrable reality when it materially affects how the resource is being used or coordinated. The important principle is: The record should be capable of describing legitimate operational reality without needing to control the underlying commercial relationship.

6. Reverse DNS Information

Reverse DNS can become operationally important for a running IP resource. A registry-state export could therefore include relevant information about:

• reverse-zone delegation;
• authoritative nameservers;
• delegation status;
• responsible organization; and
• relevant change history.

For IPv4, reverse DNS typically involves the in-addr.arpa hierarchy. For IPv6, it uses ip6.arpa. Reverse DNS can affect:

• email systems;
• security analysis;
• logging;
• troubleshooting;
• reputation systems; and
• network operations.

If registry continuity is required, reverse DNS should not be forgotten. A resource record that survives while its supporting DNS delegation becomes impossible to reconstruct would provide only partial continuity.

7. RPKI-Related Metadata

RPKI is another continuity-sensitive layer. The RPKI system contains resource certificates and signed objects used to support routing-security information such as Route Origin Authorizations. A registry-state export should not be confused with simply copying private cryptographic keys. Private-key handling requires separate security controls. Instead, the export might preserve relevant state such as:

• whether RPKI service is enabled;
• relevant resource-certificate relationships;
• current ROA information;
• authorized origin ASN;
• maximum-length information where applicable;
• publication metadata;
• relevant status information; and
• sufficient references to understand the current security-assertion state.

The goal is not to duplicate the entire RPKI architecture. The goal is to make sure continuity planning knows:

What security assertions were associated with the resource at the verified state?

This matters because a registry transition should not accidentally create unnecessary routing-security problems for a legitimate network.

8. Dispute and Conflict Status

A registry-state export becomes especially valuable when the resource is disputed. Imagine that two parties claim authority over the same resource. Simply exporting:

Holder = Organization A

may not be enough if the current state itself is contested. The export should be capable of representing a conflict state. For example:

• dispute exists;
• date dispute was recorded;
• affected resource;
• last undisputed or verified state;
• current administrative status;
• relevant restriction or hold status;
• adjudication status where applicable; and
• references to the evidence trail.

The purpose is not to decide the dispute automatically. It is to prevent the dispute from disappearing from the data. A good registry should be capable of saying:

This resource is currently subject to a recorded conflict.

rather than silently presenting one side as uncontested reality.

9. The Last Verified State

One of the most useful concepts for registry continuity is the last verified state. Suppose the current registry data becomes disputed or corrupted. The system should ideally be able to reconstruct:

1. the last state considered valid;
2. when that state became effective;
3. what evidence supported it;
4. which changes occurred afterward; and
5. which change introduced the uncertainty.

This makes dispute investigation much more precise. Instead of asking:

“Who controls the resource?”

the investigation can ask:

“What was the last verified state, and what evidence supports the transition away from it?”

That is a much more auditable question. Registry-state export makes this model practical because the relevant historical state is preserved rather than being overwritten without context.

10. Audit Logs

Auditability is one of the most important parts of a meaningful export. An audit log might preserve information such as:

• timestamp;
• action;
• affected object;
• previous value;
• new value;
• authenticated actor;
• authorization reference;
• verification status; and
• transaction or change identifier.

Not every operational detail needs to be public. But critical state transitions should be explainable. An audit trail helps answer:

Who changed this?

When?

From what?

To what?

Under whose authority?

Based on what evidence?

Those questions become particularly important when Internet number resources support production infrastructure or have significant operational value.

Registry-State Export vs RDAP

Registry-state export should not be confused with RDAP. RDAP already provides an important standardized mechanism for accessing registration data. But the objectives are different.

Feature	RDAP	Registry-State Export
Query current registration data	Yes	Yes, potentially
Standardized protocol	Yes	Not currently as a general INR export standard
Machine-readable	Yes	Should be
Resource holder information	Yes, where available	Yes
Contacts	Yes, subject to access rules	Relevant continuity state
Complete transfer history	Not its primary purpose	Potentially
Historical state	Limited / implementation dependent	Should support it
Audit logs	Not core RDAP purpose	Important
Dispute metadata	Depends on implementation	Should support it
RPKI continuity metadata	Separate system	Could reference relevant state
Reverse-DNS continuity state	Separate system	Could include relevant state
Failover / portability purpose	No	Yes
Restore verified registry state	Not its main purpose	Core objective

The distinction is important. RDAP is a registration-data access protocol. Registry-state export is a continuity architecture concept. The two could complement one another. A future registry-state export format could reuse standardized RDAP objects rather than inventing unnecessary new formats for information that RDAP already represents well.

Registry-State Export Is More Than a Backup

A database backup answers:

Can we restore this database?

A registry-state export asks:

Can this resource’s legitimate registry state be reconstructed independently?

Those are different objectives. A traditional backup may:

• depend on proprietary database software;
• contain data for every customer;
• require the original registry infrastructure;
• use undocumented internal relationships;
• contain unnecessary confidential information; or
• be difficult for a resource holder to verify independently.

A resource-level registry-state export should instead be:

• scoped;
• authenticated;
• understandable;
• machine-readable;
• verifiable;
• portable; and
• sufficient for continuity.

That makes it closer to a continuity package for the resource than a conventional server backup.

Why Resource Holders May Need Registry-State Export

A network operator rarely thinks about registry failover when everything is working normally. But critical infrastructure should be designed for abnormal situations as well. Potential continuity events can include:

• database corruption;
• extended technical outage;
• cybersecurity incident;
• organizational restructuring;
• insolvency;
• loss of key personnel;
• disputed registry records;
• service migration; or
• transition to a successor platform.

This does not imply that any particular registry is expected to fail. The same resilience principle applies throughout infrastructure engineering: If a function is important, its recovery path should be designed before failure occurs. Networks maintain backups. Databases use replication. DNS uses multiple authoritative servers. Routing uses redundant paths. Cloud systems use multiple availability zones. Critical registry information deserves the same architectural question:

What is the recovery path?

How Registry-State Export Supports Portability

Portability becomes difficult when all evidence of a resource’s current state exists only inside one provider’s internal system. A successor system would need to reconstruct the resource from incomplete evidence. That can introduce uncertainty about:

• holder identity;
• contacts;
• historical transfers;
• authorization;
• operational delegation;
• RPKI state;
• reverse DNS;
• disputes; and
• previous verified changes.

A standardized, authenticated registry-state export could reduce this problem. Conceptually, portability could work as: Current registry ↓ Authenticated registry-state export ↓ Independent verification ↓ Qualified successor registry or continuity system ↓ Preserved resource identity and service continuity The objective is not uncontrolled duplication. There should still be one recognized active state for uniqueness purposes. Portability should preserve uniqueness—not undermine it.

Export Does Not Mean Two Registries Can Claim the Same Resource

This is an important limitation. Registry-state portability should not create duplicate active registrations. The Internet still needs uniqueness. A failover model needs rules for:

• which registry state is authoritative;
• when a continuity trigger occurs;
• how the previous registry is superseded;
• how conflicting states are detected;
• how the transition is recorded; and
• how relying systems discover the recognized successor.

A copied file alone does not solve these questions. The architecture needs a state-transition mechanism. The purpose of export is to provide the evidence and data necessary for that mechanism. It should not create competing registries for the same resource.

What Would an Authenticated Export Look Like?

A useful registry-state export should not be an editable spreadsheet with no way to verify its origin. A future technical design could potentially use:

• structured JSON;
• standardized RDAP-compatible objects;
• cryptographic signatures;
• timestamps;
• object hashes;
• version numbers;
• immutable change identifiers; and
• verifiable export manifests.

For example, an export might conceptually contain:

Field	Example Purpose
Resource	Identify IPv4, IPv6 or ASN
Registry	Identify source registry
Export version	Identify format version
Export timestamp	Establish time
Holder object	Record recognized holder
Contacts	Preserve relevant contacts
Registration status	Preserve resource state
Transfer history	Explain prior transitions
Delegations	Record operational relationships
Reverse DNS	Preserve relevant delegation state
RPKI metadata	Describe security-related state
Dispute status	Preserve conflict information
Audit events	Explain material changes
State hash	Detect modification
Digital signature	Authenticate the exporter

The precise specification would require technical design and community review. But the design goal should be clear:

A recipient should be able to verify where the export came from and determine whether it has been altered.

How Often Should Registry State Be Exported?

There is no universal interval today because registry-state export is not a standardized operational system. A future implementation could consider exports:

• periodically;
• after major resource changes;
• after transfers;
• after organization changes;
• after significant delegation changes;
• after RPKI changes;
• when a dispute begins;
• before a registry migration; and
• when defined continuity-risk events occur.

The right frequency depends on how quickly the state changes. A resource that has remained static for ten years has different requirements from a portfolio with frequent transfers and delegations. The goal should be to keep the export recent enough that it can serve as meaningful continuity evidence.

Who Should Be Able to Receive an Export?

Not every registry field should necessarily be public. Privacy, security and confidentiality still matter. A registry-state architecture could distinguish between:

Public registry data

Information already intended for public coordination.

Resource-holder continuity data

Additional information available to an authenticated resource holder.

Escrow or successor-registry data

Information stored under controlled conditions for continuity purposes.

Restricted evidence

Sensitive records available only under defined authorization, dispute or legal procedures. This layered approach can support continuity without turning every internal record into public data. The objective is portability of necessary state, not indiscriminate publication.

Registry-State Export and Independent Escrow

Export becomes stronger when combined with independent escrow. If the only copy of a continuity export is stored on the same infrastructure as the registry database, both can fail together. A continuity architecture could therefore preserve authenticated versions with an independent escrow service or equivalent mechanism. That system could maintain:

• periodic versions;
• cryptographic integrity;
• timestamps;
• retention history;
• access controls; and
• defined release conditions.

This creates separation between: operating the registry and: preserving the evidence required to restore registry function. The separation is valuable because continuity should not depend entirely on the same failure domain.

Registry-State Export and RPKI Continuity

RPKI requires special care. The RPKI system has its own certificate hierarchy, keys, publication repositories and signed objects. A registry-state export should therefore not be treated as an informal substitute for RPKI’s cryptographic architecture. Instead, continuity planning needs explicit RPKI succession procedures. Those procedures may need to answer:

• What happens to existing certificates?
• What happens to published ROAs?
• How does a successor preserve or re-establish valid authorization?
• How are revoked or superseded objects handled?
• How is the transition communicated to relying parties?

A registry-continuity architecture should work with existing RPKI mechanisms rather than attempting to replace them. The principle remains: Registry continuity should include security continuity.

Registry-State Export and Reverse DNS Continuity

The same principle applies to reverse DNS. A resource may remain properly registered while its reverse DNS becomes unavailable because delegation information was not preserved during a transition. A complete continuity plan therefore needs to consider:

• reverse-zone delegation;
• nameserver information;
• relevant authorization;
• transition timing; and
• successor operation.

This demonstrates why registry continuity is broader than restoring a WHOIS or RDAP server. The resource has several dependencies. A continuity system should understand them.

What Registry-State Export Should Not Do

A focused registry-state export should not attempt to become a universal database of everything involving an Internet number resource. It does not need to contain:

• customer business plans;
• pricing;
• confidential commercial strategy;
• every network configuration;
• customer traffic;
• application data;
• unrelated compliance data; or
• every contract involving the organization.

That would make the coordination layer unnecessarily thick. The export should instead focus on information genuinely needed to preserve: uniqueness verified control registry accuracy security assertions delegation state auditability dispute visibility and: continuity This is consistent with the thin-coordination model described in Running-Code Primacy. A continuity export should be strong enough to protect the registry function without becoming a repository for unrelated organizational control.

A Practical Registry-State Export Checklist

A continuity-ready export should allow an authorized reviewer to answer:

Resource

• What IPv4, IPv6 or ASN resource is involved?
• Is the resource uniquely identified?

Holder

• Who is the last verified recognized holder?
• When was that state established?

Contacts

• Which contacts are relevant?
• Are they current?

History

• What material state changes occurred?
• Can previous states be reconstructed?

Transfer

• Has the resource been transferred?
• Is the transition history available?

Delegation

• Is there a relevant operational delegation?
• What is its current status?

Routing and security

• What routing-related authorization information matters?
• What relevant RPKI state exists?

Reverse DNS

• What reverse-DNS delegation is associated with the resource?

Disputes

• Is the resource currently disputed?
• What was the last verified state?

Auditability

• Who made material changes?
• When?
• Under what verified authority?

Authenticity

• Is the export digitally authenticated?
• Can modification be detected?

Recovery

• Could the information support a legitimate continuity or successor process?

If the answer to the final question is no, the file may be a data export—but it is not yet a meaningful registry continuity export.

Conclusion

Internet number registries perform a function that matters. They help preserve globally unique identifiers. They maintain resource records. They publish contacts. They support transfer history. They interact with reverse DNS and routing-security systems. They help independent networks understand the number-resource environment they share. Because those functions matter, they should be designed for continuity. Registry-state export is one way to think about that requirement. It asks a simple infrastructure question:

If the current registry system becomes unavailable, do we still have enough authenticated information to understand the legitimate state of the resource?

A serious answer requires more than a current WHOIS record. It requires:

• resource identity;
• recognized holder state;
• contacts;
• material history;
• transfer records;
• delegation information;
• security-related state;
• reverse-DNS information;
• conflict metadata;
• auditability; and
• authenticated evidence.

This does not mean any particular registry is expected to fail. It means important systems should have recovery paths. The Internet already applies this principle to routing, DNS, storage, databases and cloud infrastructure. The number-resource layer can benefit from the same resilience thinking. The registry function should remain recoverable as technologies, platforms and organizations evolve. The ledger should remain understandable. The resource should remain unique. And running networks should be able to preserve continuity as the systems around them change.