Registry Records vs BGP Routing: Why They Can Show Different Information

Registry Records vs BGP Routing: The Short Answer

Registry records and BGP routing can show different information because they describe different layers of the Internet.

A registry record can show which organization is associated with an IP address range.

BGP shows which Autonomous System is actually announcing a route to that prefix.

RPKI can show which ASN has been authorized to originate it.

IRR records can describe registered routing information.

These systems are related, but they are not interchangeable.

For example:

Registry:
203.0.113.0/24 → Example Enterprise Ltd.

BGP:
203.0.113.0/24 → AS64500

RPKI:
203.0.113.0/24 → AS64500 authorized

This may be completely normal.

Example Enterprise Ltd. may administer the address space while its network, provider or infrastructure partner originates the route through AS64500.

The key principle is:

Registry state, routing state and authorization state answer different questions.

A mismatch between them does not automatically mean something is wrong.

But an unexplained mismatch should be investigated.

What Is an IP Registry Record?

An IP registry record contains registration information about Internet number resources such as:

• IPv4 addresses;

• IPv6 addresses;

• Autonomous System Numbers.

Regional Internet Registries maintain registration systems that help coordinate these resources.

Today, registration information can commonly be accessed through RDAP.

RDAP can provide information such as:

• registered address range;

• registry identifier;

• network name;

• organization-related entities;

• status;

• contacts;

• registration events;

• parent resources.

The IETF defines RDAP response structures in RFC 9083.

NRS explains these fields in detail in How to Read an RDAP Record for an IP Address.

The important point is that RDAP describes registration information.

It does not directly show what the global routing system is doing at this moment.

What Is BGP Routing?

BGP, or Border Gateway Protocol, is used by Autonomous Systems to exchange Internet reachability information.

The IETF describes BGP in RFC 4271 as an inter-Autonomous System routing protocol.

A simplified route might look like:

203.0.113.0/24
AS3356 AS1299 AS64500

This shows an observed AS path.

The originating ASN in this simplified example is:

AS64500

BGP therefore helps answer:

Which ASN is currently observed originating this prefix?

That is an operational question.

It is different from asking:

Which organization appears in the registry record?

NRS explains how to verify this layer in How to Check Who Is Announcing an IP Prefix in BGP.

Registry Records and BGP Answer Different Questions

The simplest way to understand the difference is:

These systems often align.

But they do not need to contain identical names or identifiers.

For example:

RDAP:
Example Enterprise Ltd.

BGP:
AS64500 — Example Transit Network

This may be legitimate if the enterprise uses the transit provider to announce its prefix.

Why Can the Registered Organization Differ From the BGP Origin?

There are many legitimate reasons.

Upstream Provider Routing

An enterprise may hold or administer the IP addresses but use its upstream provider’s ASN for routing.

For example:

Registered organization:
Example Enterprise Ltd.

Origin ASN:
AS64500 — Example ISP

The ISP is providing routing.

The enterprise remains associated with the address resource.

These facts do not contradict each other.

Managed Hosting

A company may host infrastructure with another operator.

The hosting provider may originate the customer’s address space under an agreed arrangement.

This can result in:

Registry:
Customer A

BGP:
Hosting Provider B

Again, the difference can be legitimate.

DDoS Mitigation

During a DDoS attack, a mitigation provider may temporarily announce a customer’s prefix.

The normal state might be:

203.0.113.0/24 → AS64500

During mitigation:

203.0.113.0/24 → AS64550

The registry record may never change.

The routing state changes temporarily because the operational path has changed.

This is a good example of why registry data should not be treated as a live-routing database.

Network Migration

A provider or ASN migration can also create temporary differences.

Suppose an organization is moving from:

AS64500

to:

AS64501

During the migration, routing may temporarily involve both ASNs.

Registry information may remain unchanged because the organization associated with the IP resource has not changed.

Only the routing architecture has changed.

Anycast

Anycast architectures may originate the same prefix from multiple locations.

Depending on the design, the same or different ASNs may be involved.

The registry record still describes the resource relationship.

BGP describes how reachability is being presented to the Internet.

These are different layers of the architecture.

Corporate Mergers and Acquisitions

A company can change ownership while its network continues routing exactly as before.

For example:

Before acquisition:
203.0.113.0/24 → AS64500

After acquisition:
203.0.113.0/24 → AS64500

Corporate ownership has changed.

BGP has not.

Alternatively, the registry may be updated before the network is migrated.

NRS explores this in What Happens to IP Addresses During a Merger or Acquisition?.

This illustrates an important principle:

Corporate change, registry change and routing change do not necessarily happen at the same time.

Can the Registry Change Without BGP Changing?

Yes.

Suppose an IPv4 block is transferred from one organization to another.

After completion:

Registry:
Company B

But the acquiring company may temporarily continue using the existing routing architecture:

BGP:
203.0.113.0/24 → AS64500

The registry state has changed.

The routing state has not.

That can be intentional during a controlled transition.

The important question is whether the state is:

• documented;

• authorized;

• expected;

• operationally understood.

Can BGP Change Without the Registry Changing?

Yes.

This happens frequently.

Examples include:

• changing transit providers;

• changing origin ASN;

• DDoS mitigation;

• traffic engineering;

• network migration;

• outsourcing routing operations.

The organization registered to the resource may remain exactly the same.

Only the operational routing changes.

Why RDAP Does Not Prove Who Is Routing a Prefix

An RDAP response may contain:

startAddress
endAddress
name
status
entities
events

Those fields describe the registry object.

They do not describe the live BGP announcement.

For example, an RDAP record with:

status: active

does not prove that the prefix is currently visible in global BGP.

Likewise, an organization’s name appearing in RDAP does not prove that its own ASN originates the route.

This is why RDAP should be treated as one layer of resource verification.

NRS’s RDAP guide emphasizes the same distinction: registry state and routing state should be checked separately.

BGP Does Not Prove Registration

The reverse mistake is also common.

Suppose you observe:

203.0.113.0/24 → AS64500

That tells you that AS64500 is observed originating the route.

It does not automatically tell you:

• which organization appears in the registry;

• whether AS64500 is authorized;

• whether the announcement is expected;

• who has contractual rights to the resource;

• whether the route is malicious or legitimate.

BGP describes reachability.

It is not a legal or registration database.

BGP Does Not Prove Authorization

BGP itself does not prove that an ASN has permission to originate a prefix.

That is one of the problems RPKI helps address.

Suppose:

BGP:
203.0.113.0/24 → AS64500

This only shows the observed announcement.

To determine whether this origin is authorized, check RPKI.

Where RPKI Fits In

RPKI provides cryptographically verifiable routing authorization.

A Route Origin Authorization may state:

203.0.113.0/24 → AS64500

RFC 9582 defines the current ROA profile and describes ROAs as digitally signed objects used to verify that an address block holder has authorized an AS to originate routes for specified prefixes.

See RFC 9582.

This creates a third layer:

Registry:
Who is associated with the resource?

RPKI:
Who is authorized to originate it?

BGP:
Who is actually originating it?

That distinction is extremely useful during investigations.

Example: Everything Aligns

Consider:

Registry:
Example Network Ltd.

RPKI:
203.0.113.0/24 → AS64500

BGP:
203.0.113.0/24 → AS64500

This is a straightforward state.

The expected origin matches the authorization and the live route.

But even here, the registry organization name and ASN identity may still be different entities depending on the operating model.

Example: BGP Differs From RPKI

Now consider:

Registry:
Example Network Ltd.

RPKI:
203.0.113.0/24 → AS64500

BGP:
203.0.113.0/24 → AS64501

This deserves investigation.

Possible explanations include:

• ASN migration;

• provider change;

• stale ROA;

• configuration mistake;

• unauthorized origination.

The data itself tells you there is a mismatch.

It does not automatically tell you why.

Example: Registry and BGP Differ, but RPKI Confirms the Route

Consider:

Registry:
Example Enterprise Ltd.

RPKI:
203.0.113.0/24 → AS64550

BGP:
203.0.113.0/24 → AS64550

Suppose AS64550 belongs to the enterprise’s infrastructure provider.

The fact that the company name in RDAP differs from the BGP origin may be completely expected.

The RPKI authorization provides useful evidence that the route is intended.

This is why comparing multiple layers is more informative than comparing names alone.

What Does RPKI Invalid Mean?

If the observed route is not permitted by the applicable ROA, it may be classified as Invalid.

For example:

ROA:
203.0.113.0/24 → AS64500

BGP:
203.0.113.0/24 → AS64501

The route may be Invalid.

But Invalid does not automatically mean malicious.

It could result from:

• stale authorization;

• provider migration;

• incorrect maxLength;

• operational error;

• unauthorized origination.

NRS examines these issues in ROA Coverage vs ROV Adoption in 2026: Why the Routing Security Gap Matters.

Where IRR Fits In

The Internet Routing Registry adds another layer.

An IRR route object might look like:

route: 203.0.113.0/24
origin: AS64500

This represents registered routing information.

Some networks use IRR data to construct routing filters.

However, IRR data may become stale.

For example:

IRR:
AS64500

BGP:
AS64501

That could indicate:

• a migration;

• an outdated route object;

• incomplete operational change management.

Again, the difference is not automatically evidence of abuse.

It is a reason to investigate.

Registry, RPKI, IRR and BGP Form a Layered Picture

A useful model is:

Registry / RDAP
        ↓
Resource administration

RPKI
        ↓
Origin authorization

IRR
        ↓
Registered routing information

BGP
        ↓
Observed routing reality

Each layer contributes different evidence.

No single layer answers every question.

What Should Match?

The goal is not necessarily for every system to contain the same organization name.

The goal is for the relationships to make sense.

For example:

Registry organization:
Enterprise A

Expected origin:
Provider B

RPKI:
Provider B authorized

IRR:
Provider B registered

BGP:
Provider B observed

This is internally consistent even though the registry organization and origin network are different.

The important concept is explainable alignment.

What Is an Unexplained Mismatch?

An unexplained mismatch exists when the observed state differs from what the organization expects and no documented reason exists.

For example:

Internal expectation:
AS64500

RPKI:
AS64500

IRR:
AS64500

BGP:
AS64599

This should be investigated quickly.

Possible causes include:

• configuration error;

• provider error;

• route leak;

• unauthorized announcement;

• forgotten migration;

• stale internal records.

A Practical Verification Workflow

When registry and BGP information appear different, use a structured process.

Step 1: Confirm the Prefix

Make sure you are comparing the same CIDR block.

A registered /20 may be announced as multiple /24s.

Do not compare different prefix lengths without understanding the relationship.

Step 2: Check RDAP

Record:

• registered range;

• organization;

• registry;

• status;

• relevant events.

Do not interpret the record beyond what it actually shows.

Step 3: Check Live BGP

Record:

• visible prefix;

• origin ASN;

• AS path;

• more-specific routes;

• multiple origins.

This establishes operational state.

Step 4: Check RPKI

Ask:

Is the observed ASN authorized?

Record:

• Valid;

• Invalid;

• Not Found.

Step 5: Check IRR

Look for:

• route object;

• route6 object;

• origin ASN;

• stale or conflicting entries.

Step 6: Compare Internal Documentation

Internal records should tell you:

• expected origin ASN;

• provider;

• routing architecture;

• recent migrations;

• temporary mitigation arrangements.

Step 7: Investigate Differences

Do not assume the first differing system is wrong.

Determine which state was intended.

More-Specific Prefixes Can Make Comparisons Confusing

Suppose the registry contains:

203.0.112.0/23

BGP may show:

203.0.112.0/24 → AS64500
203.0.113.0/24 → AS64501

That does not necessarily contradict the registry record.

The registry describes a broader address range.

The network is announcing more-specific routes from different ASNs.

Possible reasons include:

• multihoming;

• regional routing;

• customer delegation;

• traffic engineering.

Always compare prefix lengths carefully.

Multiple-Origin Announcements Need Context

A prefix can sometimes appear with more than one origin ASN.

For example:

203.0.113.0/24 → AS64500
203.0.113.0/24 → AS64501

This is often called a Multiple-Origin AS, or MOAS, situation.

It may result from:

• anycast;

• migration;

• DDoS mitigation;

• shared routing architecture.

Or it may indicate an unintended announcement.

Context matters.

Historical Data Can Explain Current Differences

Sometimes the best explanation is found in historical routing data.

Suppose:

January:
203.0.113.0/24 → AS64500

October:
203.0.113.0/24 → AS64501

A historical lookup may reveal that the origin changed on the same date as:

• a provider migration;

• acquisition;

• data-centre move;

• DDoS mitigation event.

This can turn an apparently suspicious difference into an understandable operational change.

Corporate Records Can Explain Registry Differences

Registry information can lag behind internal corporate change if updates have not yet been completed.

Examples include:

• company rename;

• subsidiary restructuring;

• acquisition;

• merger;

• entity consolidation.

That does not mean inaccurate data should be ignored.

It means the organization should determine whether the record needs updating.

Accurate registration supports future:

• account recovery;

• transfers;

• due diligence;

• security response;

• continuity.

Provider-Assigned Addresses Require Extra Care

Not every IP address used by an enterprise is directly registered to that enterprise.

An ISP may provide the addresses.

For example:

RDAP:
ISP B

Customer using the addresses:
Enterprise A

This may be expected.

Likewise:

BGP:
ISP B

may also be expected.

The enterprise should therefore distinguish between:

organization-held resources

and

provider-assigned resources.

This distinction becomes particularly important during provider migration.

Does the Registry Record Prove Legal Ownership?

Not by itself.

A registry record can be important evidence concerning registration and resource administration.

But questions of legal or contractual rights may also depend on:

• agreements;

• transfer history;

• corporate records;

• applicable policies;

• applicable law.

It is therefore safer to describe registry data as registration information, rather than universally describing it as a legal title register.

Does BGP Prove Operational Control?

BGP provides strong evidence about current routing behavior.

But even that needs context.

An organization may not directly operate the ASN that originates its prefix.

A provider may do so on its behalf.

Therefore:

Observed routing is evidence of network behavior, not necessarily complete evidence of organizational control.

Why Internal Records Matter

Public datasets can tell you a lot.

They cannot always tell you what the organization intended.

An enterprise should maintain an internal record such as:

This makes inconsistencies visible.

When Should Companies Compare Registry and BGP Data?

Useful triggers include:

• annual Internet number resource audit;

• M&A;

• IPv4 transfer;

• provider migration;

• ASN change;

• RPKI deployment;

• unexplained reachability issue;

• DDoS mitigation;

• corporate restructuring.

Regular verification is better than waiting for an incident.

Why This Matters During IPv4 Transfers

An IPv4 transfer may update the registry relationship.

But routing may need to be changed separately.

A complete transition may involve:

Registry update
+
BGP update
+
RPKI update
+
IRR update
+
DNS update

These processes should be coordinated.

NRS’s analysis of 2026 IPv4 Transfer Market Data highlights how IPv4 increasingly moves between organizations in the post-exhaustion environment.

As resources change administrative context, record accuracy becomes more important.

Why This Matters During M&A

M&A creates the same layered problem.

A buyer may acquire a company today while its routing remains unchanged for months.

The correct approach is not to force every layer to change simultaneously.

It is to ensure that every layer is:

• understood;

• documented;

• accurate;

• recoverable.

Why This Matters for Network Resilience

A network is easier to recover when operators know:

• which resources exist;

• which organization is registered;

• which ASN should originate them;

• which ROAs authorize them;

• which IRR objects support them;

• who controls the relevant accounts.

That supports:

• troubleshooting;

• provider migration;

• security response;

• disaster recovery;

• business continuity.

Registry Accuracy Still Matters

Recognizing that registry records and BGP routing are different does not mean registry information is unimportant.

The opposite is true.

Registry information is valuable because it supports coordination around Internet number resources.

But it is most useful when operators understand what it represents.

A good registry record should accurately describe its administrative layer.

A good routing system should accurately implement the network’s intended operational state.

A resilient organization verifies both.

Running-Network Reality Also Matters

Likewise, live BGP data should not be ignored merely because the registry looks correct.

The Internet forwards packets according to the running network.

That means operational verification matters.

If:

Registry:
Correct

RPKI:
Correct

Internal documentation:
Correct

BGP:
Unexpected

the network may still have an operational problem.

Records are useful because they help explain and secure the network.

They do not replace the network itself.

The Better Model: Independent but Aligned Layers

A resilient resource-management model does not depend on one database answering every question.

Instead:

Accurate Registry
       +
Correct Authorization
       +
Current Routing Data
       +
Useful Internal Documentation
       =
Better Operational Confidence

This allows each system to serve its own function.

It also makes discrepancies easier to detect.

Registry Records vs BGP Routing Checklist

When the two appear different, check:

What Network Operators Should Avoid

Assuming Different Means Wrong

Legitimate third-party routing is common.

Assuming Matching Means Safe

The same ASN can appear everywhere while other routing problems still exist.

Treating RDAP as a Routing Tool

Use BGP data for routing.

Treating BGP as an Ownership Database

It is not.

Ignoring RPKI

Origin authorization provides important additional context.

Ignoring Internal Records

Public data cannot always explain business intent.

Failing to Review After Changes

Provider migrations, transfers and M&A should trigger verification.

Final Takeaway

Registry records and BGP routing can show different information because they describe different parts of the Internet.

Registry / RDAP describes registration information.

BGP describes observed routing.

RPKI describes origin authorization.

IRR provides registered routing-policy information.

The correct question is not:

Which one is the real source of truth?

A better question is:

What does each system describe, and do the relationships between them make operational sense?

A registry record does not route packets.

A BGP announcement does not prove authorization.

A ROA does not describe the entire network.

An IRR object does not guarantee current production state.

Each layer has a distinct function.

For network operators, the goal is explainable alignment:

• accurate registration;

• correct authorization;

• expected BGP routing;

• current routing records;

• documented organizational control.

When those layers remain understandable and aligned, Internet number resources are easier to secure, operate, transfer and recover.