ASN / Prefix Lookup

An ASN lookup answers a more useful question than “where is this IP?” — it tells you which network operates the address and which block that address belongs to. Instead of reasoning about one IP, you get the prefix and the operator behind it: an ISP, a data centre, a cloud region, a CDN, or a VPN provider.

An autonomous system is a network under a single routing policy. Each one is assigned a number by a regional registry — RIPE NCC, ARIN, APNIC, LACNIC or AFRINIC — and uses BGP to announce the prefixes it holds to its neighbours. Those announcements are what make an address reachable at all; without one, the address exists on paper and nowhere else. A lookup here returns the origin AS (the network that injected that prefix into the global routing table) together with the exact prefix being announced, which is usually a larger block than people expect from a single address.

Read the prefix, not just the IP. If 203.0.113.45 comes back as part of 203.0.113.0/24 announced by AS64500, then every address from .0 to .255 belongs to the same operator and will behave the same way for policy purposes. Big operators announce dozens of prefixes across more than one ASN, and the split is often historical — an acquisition, a separate business unit, a regional network. For the large clouds, the providers publish machine-readable prefix lists of their own, and those are a better source than any lookup if you are writing firewall rules against AWS, Azure or GCP.

The relationships between autonomous systems explain a lot of odd behaviour. Transit is a paid arrangement: a smaller network pays a larger one to carry its traffic to everywhere else. Peering is settlement-free, two networks exchanging enough traffic with each other that cross-connecting at an internet exchange is cheaper than paying transit for it. When a site is fast from one ISP and slow from another, or latency jumps overnight with no change on your side, the cause is frequently a shift in which of those paths is preferred — not anything on the server.

On the security side this is one of the highest-signal, lowest-effort checks available. Traffic arriving from an ASN that belongs to a VPS or hosting provider is a very different proposition from the same volume spread across residential broadband networks: real customers rarely sign up from a data centre. Investigating a spike, sorting scrapers from users, or explaining why one region sees different behaviour all get easier when you group by ASN rather than by address. It is also the quickest way to check whether an IP in your logs is your own CDN, your monitoring vendor, or something unexpected.

Using ASN for allowlisting is convenient and blunt. Cloudflare, some WAFs and a handful of CDNs let you write a rule against an ASN directly. Most firewalls and load balancers do not, so you end up expanding the ASN into its prefixes and maintaining that list yourself. Prefixes move: an operator can deaggregate a /16 into /24s overnight, sell a block, or shift a customer to a different upstream. Anything meant to outlive a debugging session needs a scheduled refresh and a way to notice when the list changes.

Be clear about what the answer does not mean. ASN tells you who routes an address, not where a person is and not who the end customer is. A residential subscriber, a corporate VPN concentrator and a compromised home router can all sit inside the same ASN with the same registered country. Routing itself is not authoritative either: BGP hijacks and route leaks mean the origin AS in the table isn’t always the legitimate holder of a prefix, which is precisely the problem RPKI route origin validation exists to solve — and that is a separate check from this one.

The lookup runs server-side against public routing and registry data. The address you type isn’t stored, and the tool never sends traffic to the address itself — nothing is probed, scanned or connected to, so looking up an IP is invisible to whoever operates it.