Who held an IP address on a given date? How IP address history lookups work
A log line, a bounce, a preservation request and a due-diligence file all end up asking the same thing: on this date, who had this address? The honest answer comes in two parts, because the internet keeps two separate ledgers about every address, one about who was responsible for it and one about who was announcing it. Here is where each ledger lives, how far back each reaches, what the dates in them actually mean, and where the trail stops.
Two ledgers, two different answers
The registry ledger is kept by the five regional registries: which organisation a block is registered to, the dates the record was created and last touched, and a log of transfers processed under policy. The routing ledger is kept by nobody in particular and everybody at once: route collectors that have archived what BGP announced, hour by hour, for more than two decades. The two often agree and sometimes do not. A block can be registered to a holding company while a lessee's network announces it; a block can sit registered and unannounced for years; a hijacked prefix appears in the routing ledger with no trace in the registry one. Take 8.8.8.0/24: the routing ledger shows AS15169 announcing it since September 2009, in three visibility windows split by two gaps in the archive itself, while the registry record now says it was registered on 28 December 2023. Both are true, and they answer different questions. So "who held it" splits into "who was responsible" and "who was using it", and a good history lookup shows both, dated, side by side.
The routing ledger: who was announcing it
Routing history is the deeper and more uniform of the two. The University of Oregon's Route Views project has archived routing data since 1997, RIPE NCC's Routing Information Service since 1999, and RIPE NCC describes the raw RIS data as kept forever. RIPEstat's routing-history call will tell you, for a prefix and an origin AS, the periods in which collectors saw that origin announcing it, scoped to a window as narrow as a day. Two caveats belong on every result. It is evidence about who was announcing the space, not a registry statement about who it was registered to. And it is filtered: routes seen by only a few collector peers are dropped by default, so a short, poorly propagated leak or hijack can be missing. Tools also have their own reach; RIPEstat's BGPlay documentation says only data after January 2024 is indexed at the time of writing, so it replays a recent event, not a 2015 one. Our lookup shows the RIS side of this ledger, via RIPEstat, as origin history: one row per network that has ever originated a prefix, with first and last seen dates and visibility windows, and a time machine that steps through the dated moments at which the announcing network changed and names the origin at each. 193.0.0.0/21 shows AS3333 back to October 2000.
The registry ledger: who was responsible for it
The registry ledger is shallower and less even, because it was built to describe the present. A current RDAP record carries a registration date and a last changed date (WHOIS output varies by registry; APNIC's, for one, shows only last-modified), and RDAP defines them plainly: registration is when the object was first registered, last changed is when its information last changed. Neither is a history. For history the registries each offer something different, and as of August 2026 the offerings are these. ARIN's WhoWas produces a report of the public history of one address or AS number, on request, after a one-time access approval, under terms that limit it to research and forbid republishing and high-volume querying; ARIN's bulk product is current data only. The RIPE Database answers a small set of command-line query flags (--list-versions, --show-version and --diff-versions) that walk and compare an object's stored versions; they are not in the web form or the REST API, they never return person or role objects, and they reach back only to the most recent time the object was created or re-created, which in our checks meant 2002 to 2003 for long-standing objects. RIPEstat exposes the same data as historical-whois, RIPE Database only. APNIC runs a public Whowas with data back to 2008, behind an API it marks experimental. AFRINIC's whois server answers the same version flags without documenting them. We found no comparable LACNIC service and would welcome a correction. Alongside the records sit the transfer logs, one JSON file per registry in a shared format, whose earliest entries are 2009 at ARIN, 2010 at APNIC, 2012 at RIPE NCC, 2016 at LACNIC and 2018 at AFRINIC. Merger and acquisition entries start later still at ARIN and RIPE NCC and are absent altogether from the APNIC and LACNIC logs, and only transfers processed under transfer policy are in them, so a block absent from every log has not thereby stayed put.
Why the dates mislead
The dates are the trap. A registration or created date can be the original registration, the day the record was migrated into that registry's database, the day of a transfer, or a placeholder: RIPE NCC uses 1970-01-01 for objects bulk-imported in September 2001 whose creation date is unknown. ARIN gives a block a new network record with a fresh registration date when it moves through a specified transfer inside the region (a merger or acquisition transfer keeps the old handle and date), which is why 8.8.8.0/24 reads 28 December 2023, the day it moved from Level 3 to Google; the /24's own record no longer carries its 1992 date, which survives in the transfer log's source registration date and on the parent 8.0.0.0/8 record. A block moved to another registry can show that registry's import date as its registration: 205.166.177.0/24, the earliest inter-registry entry in the ARIN and APNIC transfer logs, is registered at APNIC from October 2012 while ARIN's log records its first registration in April 1995. And a last changed date moves on any edit, a remark, a contact, a maintainer, so it proves the record was touched, never that the holder changed. One block can carry three honest dates: 193.0.0.0/21 was allocated in 1993, its current record was created in 2003, and the routing archive, which reaches back to 2000, shows AS3333 announcing it from October 2000. Read every date as day-level and ask which event it records before you rest an argument on it.
From a network to a person
Both ledgers stop at an organisation. ARIN's own guidance for law enforcement says WHOIS can help determine which ISP may be connected to an end user, so that legal process is served on the right party; the subscriber behind one address at one timestamp lives in that provider's records, if it kept them, and reaching those takes the provider and appropriate legal process. Cloud addresses add a twist: an AWS Elastic IP normally comes from Amazon's pool (a customer can also bring their own registered range), and once released an Amazon-pool address cannot be recovered if another account has been allocated it, so the same address can pass between unrelated customers with no change in any registry record. What the two ledgers give you is exactly the part that is public: which network was announcing the address, which organisation was responsible for the block, and which registry and provider to ask next. That is a great deal more than nothing, and it is the whole of what a lookup can honestly promise; the person is a different question, answered by different means.
Look up an address, prefix or AS number on the front page for the routing ledger with dates and visibility, the registry's own registration, allocation and last change dates, which registry's published holdings the space appears in and from what date those statistics show it, and every change we have recorded ourselves since the first time somebody looked it up here. What we did not watch we do not back-fill; the report says what it holds.