Who Owns an IP Address? Registered Holder vs ASN

An IP lookup can show who an address range is registered to and which networks were observed announcing routes to it. A routing announcement tells other networks that traffic can reach the range through the announcing network. Each of these networks has an identifier called an Autonomous System Number (ASN). Those fields may name different organizations, and neither one identifies a specific person, device, home address, or exact physical location.

People often ask who “owns” an IP address, but public records do not settle legal title. IP Lens labels one field Owner; read it as the registered holder, registrant, or organization listed in registration data. The origin ASN answers a separate question: which network was observed introducing the route, rather than passing along another network's announcement?

Which organization or person does each field describe?

Record or party	What it can tell you	What it cannot tell you
Registered holder	Which registrant or organization registration data lists for the prefix.	Legal title, the network routing it now, or the person using one address.
Observed announcing network	Which origin ASN or ASNs the available routing observations associate with the prefix.	A universal current route, the complete AS path, registration, or the end user.
Current end user	Who or what used a connection at the event time, if your authenticated service or access logs establish it.	This identity is not supplied by public registry or BGP data.

What does the registered owner field mean?

The field names the registered holder, registrant, or other organization listed in public registry data for an IP prefix. This administrative record is not proof of legal ownership, current routing, or the person using an individual address. See how IP registries work.

What is the announcing Autonomous System Number?

The Internet is built from many networks called Autonomous Systems. Each one is identified by an ASN. Border Gateway Protocol (BGP) is the set of rules they use to tell other networks which address ranges they can reach. This is how networks exchange routing announcements.

IP Lens finds the smallest address range containing the address (the most-specific matching prefix) in its available routing information. It associates that range with one or more origin ASNs: networks observed introducing the route into BGP, rather than relaying another network's route. A prefix can have more than one observed origin at the same time, a situation called a Multiple-Origin AS (MOAS). This can be intentional or accidental, so the presence of multiple origins is a reason to investigate rather than proof of a routing incident. The displayed origins are observations, not a live universal view or proof of the complete path your traffic followed.

This is different from registration. The registered-holder field comes from an administrative record; the origin ASN comes from a routing observation. Compare the observation time or data revision with the event time when the distinction matters.

An observed announcement does not by itself prove the network is authorized to originate the route. A Route Origin Authorization (ROA) records which ASN may originate routes for an address range and how specific those routes may be. Resource Public Key Infrastructure (RPKI) uses signed records to let validators check that authorization. IP Lens does not currently display RPKI validation, so this is an advanced check to perform with a separate validator.

Result	What it means
Valid	At least one validated ROA payload covers the announced prefix and authorizes both its origin ASN and announced prefix length.
Invalid	At least one validated ROA payload covers the announced prefix, but none authorizes both its origin ASN and announced prefix length. A hijack is one possibility; stale ROAs and configuration mistakes are others.
NotFound	No validated ROA payload covers the announced prefix. This is missing authorization data, not an Invalid result.

RPKI origin validation checks only the prefix, origin ASN, and allowed maximum prefix length. It does not validate the rest of the AS path, prove which organization operated the systems, or show that the traffic was harmless.

Why can the registered holder and origin ASN differ?

It is common for the registered-holder record and the observed origin ASN to point to different organizations.

Example: 1.1.1.1

The address in the Cloudflare public DNS resolver result for 1.1.1.1 is inside 1.1.1.0/24, carved from a larger APNIC Research and Development allocation. Cloudflare documents that APNIC provided 1.1.1.1 for the jointly operated public resolver, and Cloudflare's routing documentation lists AS13335 as the origin for 1.1.1.0/24. Depending on the available registration and routing observations, the linked IP Lens results may show those records or a different covering prefix. Treat the example as a comparison of fields, not a guarantee that every field is present in a current result:

Field	Meaning
Registered holder: APNIC Research and Development	Registration data describes the larger allocation containing the routed /24.
Documented service origin: Cloudflare AS13335	A matching routing observation can associate the prefix with Cloudflare's ASN.
Reverse DNS name: one.one.one.one	A DNS Pointer (PTR) record associated with Cloudflare's resolver service.

Example: Bring Your Own IP

Some organizations keep using address space they hold while letting a cloud provider announce those prefixes from its own network. This lets traffic to the customer's addresses be protected, proxied, accelerated, or routed through the provider's services. The arrangement is commonly called Bring Your Own IP (BYOIP): the customer continues to use the address space, and the provider originates its routes.

Field	Possible value
Registered holder	Customer organization
Announcing ASN	Cloud provider
Explanation	The registry lists the customer, while routing observations associate the prefix with the cloud provider's origin ASN.

Example: Internet provider or leased address space

An Internet Service Provider (ISP) is a company that supplies Internet access. A block may list one organization in registration data but be used by another through assignment, leasing, hosting, or customer delegation. A hosting company may lease space from another holder, or an enterprise may have its prefix originated by a protection or cloud network. A network that merely carries the route as transit appears elsewhere in the AS path; carrying traffic does not make it the origin ASN.

How should I use registration and ASN data?

Read the registered-holder field, observed origin ASN, reverse DNS, IP address tags, and location together. No single field tells the whole story, and registration, routing, DNS, and location all change over time.

For security investigations, keep complete logs — including timestamps, IP addresses, and source port numbers, which help distinguish exchanges of data at a shared address — and combine IP data with other evidence before acting. See Logging best practices for what to record and why.

To report a documented event, use the registry for the address to find the most-specific current RDAP record and its published abuse contact. Do not send a report to the registered holder or announcing ASN merely because its name appears here. Follow the complete IP abuse-reporting workflow for the required UTC timestamp, connection evidence, and contact steps.

How to phrase findings

Better	Risky	Why
Registration data lists this organization, while routing observations show this origin ASN for the prefix.	This ASN owns the address.	Registration data and routing-origin observations can point to different organizations, and neither field alone proves legal ownership.
An external RPKI validator reports Invalid for this prefix, origin ASN, or prefix length; investigate the mismatch.	The route is definitely hijacked.	Invalid is a serious origin-authorization signal, but stale ROAs and operational mistakes are possible, and RPKI does not validate the full path.