How a lookup is answered

Look up an address and you get back where it is, who runs it, and whether anything is hiding behind it. Here is how each answer is reached, and how firmly we are willing to state it.

Longest prefix wins

An address is not in one list. It sits inside a registry allocation, inside a routed prefix, inside a geolocation block, and possibly inside a published cloud range and a proxy listing as well. Each of those blocks is a different size, and the most specific one is the one that describes the address best. Every lookup here resolves each question independently and takes the narrowest block that contains the address. That is the longest match, and it is what the site is named after.

Every signal carries its evidence

A flag that says only yes or no hides the difference between an operator publishing an address as its own exit and a wide block somebody once associated with proxy use. Those are not the same claim, and treating them alike is how commercial tools end up flagging ordinary broadband subscribers.

Every anonymiser signal carries a grade set by two things together: where the listing came from, and how much address space it covers. A narrow listing from the operator itself reads as confirmed. An independent list naming a block reads as listed. A wide block, or an inference from the network an address sits on, reads as inferred and is worded so a reader can see it is an inference. The grade changes the score, the wording, and what the page is willing to state.

Two scores, deliberately kept apart

One number asks whether this address hides where its user is. The other asks whether this address space has been reported. They are different questions with different answers, and averaging them is useless for both. Somebody on a corporate VPN scores high on concealment and nothing on abuse. Hijacked space scores high on abuse whether or not anyone is hiding behind it.

Each score ships with the signals that produced it, so you can see what moved it.

Physical location, and registration, as separate answers

Where address space is used and where its holder is registered are different facts. They agree for 95.1% of the internet and for 38.8% of VPN space. Both are reported, labelled as what they are, and a caveat is attached to the field when they disagree.

A city needs two sources to agree

Location comes from two datasets that are built separately. Where they name the same country, you get the country, the region and the city. Where they disagree, you get the country from the more reliable of the two and no city at all, plus a note saying what the other one said. About a fifth of lookups land in that state, because the addresses people search for most are public resolvers, content networks and cloud endpoints. Those are where the two sources disagree most.

A city belongs to the country it sits in, so publishing one source’s city under the other’s country would be a false answer where a missing one is only a vague one. Coordinates get a further check: the point has to fall inside the country named beside it, because agreeing on a country says nothing about where the pin was put.

Where your lookups go

The answer is already on our own servers. Every dataset behind a lookup is ingested here in advance, so answering you costs no request to anybody else, and the addresses you search for are never brokered to a data vendor.

Two parts of a lookup do leave, and both are named here rather than buried. Reverse DNS sends a query for the address to a resolver, which is the only way a hostname is found at all, and an address we have not seen before is queued for that in the background. enrich=true asks the registry directly when we do not already hold the registered holder. Nothing else about your request goes anywhere.