Trace an IP to its network, prefix, and route authority.

Which network and source-reported range carry this IP?

Read the reported ASN, operator and source range, with independent origin corroboration where available. These are network facts, not subscriber identity. The current deployment withholds RPKI validity instead of presenting it as verified.

Source availability depends on the current deployment and each returned record. These review dates do not establish when a particular IP was observed. Method axis-scope-2026-09-15 · Score ipjury-score-v3.

This record reports which network and range the permitted sources name for an address. It does not currently validate route authorization. Useful context — and regularly mistaken for what it is not: a statement about the person using the address.

Allocation is not the same as routed reality

Two records describe an address block and answer different questions. A regional internet registry — one of five bodies distributing number resources under IANA — records who was allocated the block and under which allocation type: the paper trail. BGP separately shows which prefix is announced today and which ASN originates it. The paper trail changes when the registry is updated; the routed reality changes when someone changes a router.

The gap is normal, not suspicious. Blocks are leased, sub-allocated, transferred, and re-purposed, and records can update on different schedules. When a registry says an enterprise in one country holds a block while routing shows a hosting provider in another announcing it, the records may describe different scopes; compare their dates and definitions instead of assuming either is automatically correct. IPJury shows the announced prefix alongside the allocation rather than calling one the truth.

RPKI: what the three states actually mean

IPJury does not currently display RPKI validity. The state is withheld rather than unknown: the deployed build sources validation from RIPEstat, whose terms restrict commercial reuse, so the routing axis reports origin ASN, announced prefix and route-origin conflicts instead. The states below are what the field would tell you, and what to check it against elsewhere.

The Resource Public Key Infrastructure lets an address holder publish a signed statement — a Route Origin Authorisation — naming which ASN may originate their prefix and up to what length. Validating routers compare announcements against it and produce one of three states, defined in RFC 6811.

Valid

A published authorisation covers this prefix and permits this origin ASN at this length. The announcement matches what the holder authorised, and says nothing about the traffic it carries.

Invalid

An authorisation exists for the prefix but none permits this origin or length. The state worth attention — and still not proof of an attack: misconfiguration or an outdated authorization is one possible explanation to investigate.

Not found

No authorisation covers the prefix: a holder who has not published one. Neither good nor bad news; reading it as a negative penalises networks for not adopting an optional practice.

Route-origin conflicts

A conflict appears when the same or overlapping prefixes are announced from more than one origin ASN, or when an unexpected more-specific announcement shadows a covering block. Some are legitimate: multi-origin announcements occur in anycast deployments, during provider migrations, and where a customer and its upstream both originate a block. Some are misconfiguration; a few are hijacks. The state prompts a look at operator context rather than standing as a verdict, and belongs to the prefix, not to any address in it.

PTR is a weak clue, by design

Reverse DNS maps an address back to a hostname, and hostnames look informative: names like static, dynamic, pool, or vpn hint at how a range is used. But PTR is set by whoever controls the reverse zone, verified by nobody, and frequently left over from an old configuration — wrong through neglect as easily as intent. IPJury reports it as a naming clue and labels it weak. A forward-confirmed lookup, where the hostname resolves back to the address, is stronger, and still only a claim about DNS.

What routing informs and what it cannot decide

Routing context makes the other axes readable. It distinguishes consumer ISPs from carriers, clouds, CDNs, and transit providers, and explains why an address inherits a network-level prior. What it cannot do is settle those axes: an ASN running hosting infrastructure does not make an address inside it a proxy, and a valid RPKI state is not an absence of abuse history. Routing describes the road; the other axes describe the traffic.

For how routing feeds the role determination, see the network role guide.