IP Address Ownership Lookup: Registration, Routing and Reputation, Delivered

Ownership is three different questions stacked on top of each other, and any lookup that claims to answer all three from one field is quietly answering only one.

The registration layer is the legal answer. In the RIPE Database (WHOIS & Routing Registry) - quality score 9 in Datadory's catalog - it lives across roughly twenty-one RPSL object classes: an inetnum object holds the range, an organisation object names the holder, and an abuse-c contact identifies who receives complaints about that space. The same database doubles as an Internet Routing Registry, so intended routing policy arrives as aut-num, route and route6 objects beside the ownership facts.

The routing layer is the operational answer: whoever announces the prefix on the internet today. The RouteViews BGP Archive & API, also scored 9, holds full IPv4 views above 900k prefixes per peer on its best-connected collectors, and those live announcements diverge from registration often enough that the gap is the core evidence in every hijack investigation.

The same address can sit registered to one organisation, announced by an unrelated network and listed inside DROP simultaneously - three true answers issued by three different authorities. Treat any lookup that returns only one of the layers as incomplete.

A fourth layer sits upstream of all three for anything hostname-shaped: the Public Suffix List's ~10,058 active suffix rules decide where a name's registrable part ends, which determines whose registration record should be read in the first place.

Six catalog records cover the question, and they overlap far less than they first appear: two answer registration, one answers announcement, one answers live usage, one answers reputation and one packages history - which is why most ownership products combine at least two rather than choosing one.

• RIPEstat Data API - the widest single integration in the slice: 60+ named data calls aggregating 35+ underlying datasets for any IP address, prefix, ASN or country code, spanning WHOIS, geolocation, routing history, announced prefixes, ASN neighbours, reverse DNS and RPKI status. Coverage reaches all five Regional Internet Registries, so one record resolves addresses well beyond its home region.
• RIPE Database (WHOIS & Routing Registry) - the authoritative ledger for Europe, the Middle East and parts of Central Asia, 75 member countries deep, with created and last-modified timestamps reaching back to the early 1990s and millions of live objects across ~21 RPSL classes.
• RouteViews BGP Archive & API - terabytes of archived routing material across roughly twenty collectors, legacy vintages reaching back to the late 1990s, plus current-state lookups carrying AS paths, communities and validation states.
• Spamhaus DROP Lists (Don't Route Or Peer) - ~1,700 hijacked IPv4 netblocks, ~40 IPv6 prefixes and ~438 ASNs drawn from all five registries, every entry keyed per CIDR prefix or per ASN with its SBL record identifier attached.
• WhoisXML API – Domain & IP Intelligence - 28.7B+ historic WHOIS records, 116B+ DNS records and 10.6M+ netblocks spanning 99.5% of in-use IPv4/IPv6 space across 7,596+ TLDs.
• Shodan – Search Engine for Internet-Connected Devices - billions of indexed service banners across hundreds of millions of hosts, covering every routable IPv4 address plus reachable IPv6, geolocated to city and postal code.

Quality scores across these six run 8 to 9 against a master catalog averaging 7.81 over 1,744 datasets - this slice punches above the catalog mean because the underlying authorities maintain the data professionally and document it honestly.

One address in, three reconciled layers out. A resolution keyed on 193.0.6.0/24 reads like this once the records land in one table:

resource          : 193.0.6.0/24
registered_range  : 193.0.0.0 - 193.0.7.255   (inetnum, RIPE region)
netname           : RIPE-NCC
org_handle        : ORG-RIEN1-RIPE            (holder join key)
abuse_c           : abuse@ripe.net
announced         : true | origin_asn=3333 | holder=RIPE-NCC-AS
rpki_state        : valid
reputation        : not listed (~1,700 netblocks rostered globally)
snapshot_time     : 2026-08-21T08:00:00Z

Read what the rows establish. The org_handle is the join key that turns "a range" into "an accountable organisation" - one equality instead of a name-matching exercise. The announced origin sits beside the registered holder precisely so the disagreement becomes visible rather than discoverable. And the snapshot timestamp converts a static answer into a timeline entry, which is what lets a fraud score or an allow-list explain why it said yes last Tuesday.

Three clocks, and they measure different things.

Registry time runs deepest on the registration side: the RIPE Database carries created and last-modified timestamps reaching back to the early 1990s, with per-object version history available for change-tracking work, so a range changing hands is observable rather than inferred. WhoisXML API's historic archive extends the same idea globally at a vendor-reported 28.7B+ WHOIS records.

Routing time is measured in snapshots and streams: legacy RouteViews collectors reach back to the late 1990s - over a quarter century of continuous routing history - while newer collectors extend the record from February 2024 onward, and current-state lookups cover the present.

Reputation time is deliberately short and rolling: listings track operators who abandon flagged ranges for fresh leases, and each DROP entry keeps its SBL identifier so past listings stay traceable after a range cleans up. Live usage evidence runs on a similar clock - Shodan's index covers the whole routable address space with retained banner history per host, so ports opening and software changing assemble into timelines without anyone running their own scans.

A longitudinal study needs all three clocks aligned on one key. That alignment is exactly what the normalized feed provides.

Three limits define the edge of the method, and none of them goes away with a bigger budget.

First, region: the authoritative registry answers only inside its own service region. A global product needs the aggregated views across all five Regional Internet Registries, or a commercial netblock layer, for addresses outside Europe, the Middle East and Central Asia.

Second, meaning: registration is not usage. The registered holder may lease the space, announce it from a different network, or have nothing running on it at all - which is why the routing and exposure layers exist, and why a single-layer lookup misleads politely but consistently.

Third, precision: IP geolocation resolves to city and postal code at best, and shared infrastructure means one address can serve many parties. Ownership data supports attribution decisions; it does not substitute for them. Products that treat the three layers as independent witnesses - and record where they disagree - end up with defensible outputs instead of confident ones.

• Security and abuse operations turn an offending address into an accountable party through abuse-c and tech-c handles, screen signups against freshly allocated blocks - where fraud density runs highest - and check candidate ranges against the ~1,700-netblock hijack roster before allowing new traffic.
• Fraud and risk platforms score incoming IPs on the gap between registered holder and announced origin, plus hosting-versus-residential classification drawn from netblock and geolocation fields covering 99.5% of in-use space.
• Network engineers and peering teams resolve any prefix to its holder before negotiating a session, and read published import/export policy objects to know what a peer will actually accept.
• Competitive intelligence teams count holdings per organisation to size hosting and carrier footprints, and watch new ASN registrations as market-entry signals.
• Developers and builders wire the resolution into products: enrichment that appends network owner and geography to IP-bearing records, alerting that notices when a customer prefix stops being announced. The developers and builders playbook walks the workflow.
• Researchers and journalists build topology studies and citation-grade investigations on a quarter century of AS paths under one schema.

API, files, or your warehouse. Daily, weekly, or hourly.

Name the resources - an ASN list, a country, a prefix family - and we send real rows in the same schema the production feed uses. Get a sample cut to your address space before anything else; the ongoing arrangement follows once the rows validate.

This page covers one lookup workflow inside the ten-record Internet Services & Infrastructure pool - eight primary datasets plus two cross-industry entries. The internet services infrastructure data guide maps all of them with field dictionaries, coverage windows and quality scores, and shows where IP ownership sits beside domain parsing, routing archives and attack-surface crawls.

From here, go row-level in four directions: the RIPEstat Data API record for the five-registry aggregator, the RIPE Database (WHOIS & Routing Registry) page for authoritative registry objects, the WhoisXML API – Domain & IP Intelligence page for historical depth, and the internet services infrastructure data hub for the full industry view on one screen.