SKNK Field Notes · Reading lookup results

When You Look Up an ASN or Prefix, What Is the Data Actually Saying?

A lookup result can come from a registry, a routing observation, an authorisation record, or a public profile — each answers a different question. This page is a field guide: identify the source, read the result, then decide what to do next.

Reviewed against public documentation: 2 August 2026

Start with the question

Are you checking registration, routing, or authorisation?

Pick the question before the tool. Four sources answer four questions: registry, routing, authorisation, and self-report. Reading a registry record as proof that "the whole Internet can reach it" is the most common mistake we see.

RIPE Database / IRR

Who is this space registered to?

The registry holds an object for this prefix → it is registered, and the holder is on record

What this confirms: At the moment you queried, the registry returned a published route or route6 object with the prefix and origin on it.
What it does not answer: The object can be years old — the route can have been gone for months. It also says nothing about acceptance or visibility from any collector.
What to check next: Cross-check it against BGP observations and their timestamps. For real reachability, test from your own network or upstream.

RIPEstat / RIS

Is anyone announcing it right now?

A public collector sees the route → visible from that vantage point, at that time

What this confirms: The selected collector received a route for the prefix, with the path and origin it observed.
What it does not answer: Collectors cannot see private sessions, filters, or local policy. What one network sees can differ completely from what another sees.
What to check next: Compare several collectors and timestamps. To know whether a user can reach your service, test along the relevant path.

RPKI / ROA

Is the announcer authorised?

RPKI returns Valid → the announcer is authorised

What this confirms: For that validator's data set, the observed route matches an applicable published ROA.
What it does not answer: It does not check the BGP session, end-to-end reachability, DNS, or whether your application is up. Your site can be down and RPKI still says Valid.
What to check next: Read RPKI alongside the BGP and registry data; for applications, use monitoring and real requests.

DNS / PeeringDB

Who does it say it is, publicly?

PeeringDB has a public entry → it published identity and interconnection details

What this confirms: The participant published the information shown — facilities, policy, network details, or a contact path.
What it does not answer: It does not prove both sides agreed to peer, that a session is configured, or that traffic is flowing.
What to check next: Read the stated policy and contact the operator. Once terms are agreed, both sides configure their side of the session.

When you read a lookup result

Three details, every time.

State these three and anyone can judge your conclusion. Use the same order when you check data yourself.

What was checked?

Be specific: an ASN is an ASN, a prefix includes its length. Vague input produces vague answers.

Which source returned it?

The source decides the meaning. Registry, observation, authorisation, and self-report mean four different things. Four sources giving four answers is not a contradiction — it is division of labour.

When was it checked?

Public data changes constantly. A three-month-old observation does not answer a "right now" question. Note the time when you query, and carry it whenever you quote the result.

Public data is evidence, not a verdict.

Whether a route is accepted and a service is healthy also depends on upstream filters, your policy, and your monitoring. For policy, contracts, or service scope, the formal pages are the source of truth.

Data sources

Public data sources this site uses

What each source can and cannot support is covered by the four cards above. They update at different speeds, so read any result together with its query time.