How to check a subnet's history before you buy or lease it

Reputation attaches to addresses, not to owners

Blocklists key on an address. Fraud scores key on an address, or on the /24 around it. Mail reputation keys on the sending address and the domain behind it. Geolocation and datacenter classification key on the block. None of them key on the RIR record, which is the one thing a transfer actually changes.

So the failure mode is specific. The space is properly yours. The RDAP entry carries your organisation. It is announced from your AS, the ROA validates, every check a network engineer would run comes back correct, and a payment processor still declines every session that arrives from it. You bought the addresses. You also inherited a reputation you cannot see from your own equipment, because the systems holding it are not yours.

Some of that inheritance decays. Public blocklists expire entries, often within weeks. Some of it does not decay on any schedule you can plan around: a deny list inside a large retailer, a fraud model trained on eighteen months of traffic, a "proxy" classification at a commercial intelligence vendor that nobody revisits because nothing prompts them to. Budget in months rather than days, and accept that you will never get a full list of who is still holding it against you.

"Clean" is three different claims

Three claims travel under the same word, and they are worth very different amounts.

The claim you will usually be offered is the first, and it is the weakest, for a reason that is easy to miss: in almost every tool, a negative result and an absence of results look identical. Query an address nobody has ever looked at and the feeds return nothing. Nothing renders as green.

So the question for a seller is not "is it clean". It is "what has been checked, when, by whom, and how far back does the record go". A screenshot of one blocklist query run this morning answers none of that.

The checks, in order

Cheapest and most disqualifying first. All of this is public: RDAP at the five RIRs, the RIRs' own transfer statistics, a route collector or looking glass, an RPKI validator, and whatever address intelligence you already pay for.

1. Registration and transfer history. Who holds it now, who held it before, and when the record last changed. RIPE NCC, ARIN and APNIC publish transfer statistics, and the registry object itself carries registration, allocation and last-changed dates. What you want out of this: how many times the block has moved, how recently, and whether the party selling it to you appears in the chain at all. A block that has changed hands three times in two years is not necessarily dirty, but it is a block that several people in a row decided to get rid of.
2. Allocation date and RIR. A /24 carved out of a 1994 legacy allocation and a /24 issued to a two-year-old LIR are different objects with different failure modes. Old space more often carries stale registry data, an unreachable abuse contact and a history of squatter announcements. New space more often sits inside a range some vendor has already classified wholesale, on the strength of its neighbours.
3. Origin history. Which autonomous systems have announced this prefix, and between which dates. This is the most informative single view of an IPv4 block, because it is the only one that shows use rather than paperwork. Count the distinct origins, note how long each one held it, and look hard at the gaps.
4. Whether it was announced at all. A range with no announcement history carried no traffic, so it earned no reputation, good or bad. That is not automatically the prize it sounds like, for reasons below.
5. RPKI. Is there a ROA, which origin does it authorise, and what is the max length. Presence tells you someone with authority over the block was organised enough to sign a statement about it, and that hijacking the space is harder. Absence tells you nothing: large and entirely reputable networks still have unsigned space.
6. Sampled addresses inside the block, and how far back the readings go. This is where reputation actually lives. Do independent feeds return VPN, proxy, Tor, datacenter, abuser or blocklist verdicts for addresses inside the range, at what risk score, and, the part that decides the purchase, on which dates. A reading taken today tells you about today.

That last check is the one this site exists to answer. Every reading is kept with the date it was taken, so a range that came back quiet in March and flagged in July shows both, rather than only whichever happens to be true this morning.

What each signal does and does not prove

Origin churn is not evidence by itself. Legitimate transfers change the origin AS. So do upstream changes, acquisitions, and an operator moving space between autonomous systems it owns. What deserves attention is churn with a shape: short holds, several unrelated origins inside a narrow window, announcements that start and stop, or an origin with no other business announcing space in that part of the world.

Absence of RPKI proves nothing. Presence proves something narrow and real, which is that a signed authorisation exists and can be checked. Treating an unsigned block as suspicious would condemn a large share of the routed internet.

A single flagged address means very little. One address out of the 65,536 in a /16 coming back as a proxy is noise. Six of nineteen sampled addresses in a /24 scoring 100 out of 100 is a finding, because hitting flags repeatedly across addresses picked at random says something about density, not about one host. Density is the thing you are buying.

Feed disagreement is information, not an error. When one source says VPN and another explicitly says not VPN, the honest reading is "contested". A tool that collapses that into a single yes has hidden the most interesting part of the answer.

Flagged is not the same as malicious

Look up 185.220.101.0/24. It is one of the most heavily flagged /24s on the public internet. The RIPE record says plainly what the space is for, it is announced by a network that exists to run Tor exit nodes, and sampled addresses inside it come back with Tor and proxy verdicts and risk scores at the top of the scale, from more than one independent feed.

None of that is wrongdoing. The operator is long-running, transparent, and doing exactly what its records say it does. But that range would be a catastrophic purchase for anyone who needs their traffic accepted by ordinary consumer services, and no amount of clean paperwork would repair it. The lesson runs in both directions: a heavily flagged range can be entirely legitimate, and an entirely legitimate range can be commercially unusable. Reputation data answers "will this be accepted", not "was the last holder a criminal". Only the first of those is your problem.

Run the contrast yourself on a /24 out of a corporate allocation that one AS has announced for a decade. Same tools, same feeds, and the report comes back mostly empty: one origin, a long unbroken hold, sampled addresses with nothing on them. Quiet is what good looks like, and quiet makes for a boring report, which is why nobody advertises it.

Dormant space cuts both ways

A range that has never been announced has never carried traffic, so it has no reputation to inherit. If you intend to send mail or serve consumer traffic, that is the single most valuable property a block can have, and it is reasonable to pay more for it.

It is also worth being precise about why the space is quiet. Never announced is one thing. Announced for years and silent since is another, and the reason matters, because an operator that wound down cleanly and a block that was pulled after an abuse complaint produce exactly the same silence in a routing table. Dormant space also attracts hijackers, precisely because nobody is watching it, so a block can carry announcements its holder never authorised. That is the kind of history a registry record will never show you, and the kind an origin timeline will.

The check is the same either way: read the origin history and ask whether the silence has an explanation you can name. Never announced, allocated recently, one holder throughout, is a complete story. Announced by three unrelated autonomous systems across 2019 and nothing since is a story with a missing chapter, and the chapter is the reason you are being offered it.

What history cannot tell you

It cannot tell you what the range will look like in six months. That depends on what you run on it and who you sell to, and it is the part you control.

It cannot see private reputation. The lists that matter most to a signup form or a checkout are the ones nobody publishes. History narrows the risk. It does not remove it.

It is incomplete by construction, and honest tooling says so. Route collectors see what their peers see, not what happened everywhere. Sampling covers the addresses somebody has actually checked, not the block: when a report says nineteen addresses in a /24 were sampled, the other 237 are unknown, and unknown is the correct word for them rather than clean.

Registry records are self-reported. Net names, remarks and abuse contacts are typed in by the holder. They are good evidence about intent and about sloppiness. They are not proof.

And a clean history is not a warranty. It is a reason to believe the range has not already been spent. What happens next is your operating practice, which is the part the history will be recording from now on.

Before you sign

• Get the exact prefixes in writing, not "a /22 in RIPE space". You cannot check a description.
• Ask what has been sampled and when. "Not currently listed" does not answer that question.
• Read the origin history yourself instead of accepting a summary of it.
• Sample addresses across the whole range, not the first ten. The first ten are the ones the seller checked.
• Agree in advance what happens if the space turns out to be listed after the transfer completes, because afterwards it is your problem by default.