What Is an ASN and Why It Helps Identify Website Hosting

Every hosting checker eventually shows you something like AS13335 — CLOUDFLARENET next to a provider name. It looks like trivia. It is in fact the strongest single piece of evidence in hosting detection, and also the one most often misread. This guide covers what an Autonomous System Number is, how to look one up yourself, what our checker does with it, and the four situations where the ASN will confidently point you at the wrong company.

What an Autonomous System actually is

The internet is not one network. It is tens of thousands of independent networks that agree to exchange traffic. RIPE NCC defines an Autonomous System as "a group of IP networks run by one or more network operators with a single, clearly defined routing policy". Each of those networks gets a unique Autonomous System Number so it can announce its address space to everyone else over BGP.

The numbering is straightforward. The original 16-bit space runs from 0 to 65535. RFC 6793 extended it to 32 bits, so the top of the range is now 4294967295. Two blocks are reserved for private use and will never show up in a public lookup: 64512–65534 and 4200000000–4294967294, per RFC 6996. IANA allocates blocks of ASNs to the five Regional Internet Registries — AFRINIC, APNIC, ARIN, LACNIC and RIPE NCC — which then assign individual numbers to network operators.

Not everyone gets one. RIPE's policy, for instance, expects an applicant to be multi-homed and to run a routing policy distinct from its upstreams. That bar is exactly what makes ASNs useful for hosting detection: an organisation holding its own ASN is operating real network infrastructure, not renting one server in someone else's rack.

ASN, IP address and hosting provider are three different things

The chain from a domain to a company has more links than most people assume:

1. The domain's A/AAAA record resolves to an IP address.
2. That address sits inside a BGP prefix — a block like 104.16.128.0/20 that somebody announces to the global routing table.
3. The network announcing that prefix has an ASN.
4. The ASN is registered to an organisation in one of the five RIR databases.

Each hop can lose information. The IP may belong to a CDN rather than the origin; the prefix may be announced by an upstream carrier; the registered organisation may be a parent company whose brand never appears on an invoice. The honest description of an ASN lookup is therefore: it tells you which network routes this address, which is usually — but not always — the hosting provider.

How to look up an ASN by hand

Three commands cover almost every case. Start with DNS:

$ dig +short A hetzner.com
213.133.116.44

Then map the IP to an ASN. The fastest public route is Team Cymru's IP-to-ASN whois interface, which returns the prefix and registry in one line:

$ whois -h whois.cymru.com " -v 213.133.116.44"
AS     | IP             | BGP Prefix      | CC | Registry | Allocated  | AS Name
24940  | 213.133.116.44 | 213.133.96.0/19 | DE | ripencc  | 2002-05-23 | HETZNER-AS - Hetzner Online GmbH, DE

Read that left to right: AS24940, announcing the /19 that contains the address, registered in the RIPE region, allocated in 2002, held by Hetzner Online GmbH. That is a clean result — the ASN owner is the hosting company.

For the registry's own view, use RDAP, the JSON successor to whois. It is what modern tooling should call; ICANN removed the contractual WHOIS obligation for gTLD registries and registrars on 28 January 2025, and the RIRs have run RDAP as their featured service for years. A query for the IP returns the allocated range:

$ curl -s https://rdap.org/ip/104.16.133.229
{
  "handle": "NET-104-16-0-0-1",
  "startAddress": "104.16.0.0",
  "endAddress": "104.31.255.255",
  "name": "CLOUDFLARENET",
  "type": "DIRECT ALLOCATION"
}

And a query for the ASN itself returns the autnum object:

$ curl -s https://rdap.arin.net/registry/autnum/13335
{ "handle": "AS13335", "startAutnum": 13335, "endAutnum": 13335, "name": "CLOUDFLARENET" }

Three fields carry the meaning: the ASN, the BGP prefix (how big a block the answer covers), and the organisation name. Everything else is metadata.

What the numbers look like in practice

A few real lookups, run while writing this article:

That last row is the whole problem in miniature. AS16509 is announced for both customer compute and CDN edge nodes, so "AS16509" tells you the traffic terminates inside Amazon's network — but not whether you reached a customer's EC2 instance or a CloudFront point of presence in front of a server somewhere else entirely.

What hostingchecker.org does with the ASN

Our check runs the same chain automatically and then adds one step. A WhoisProbe queries RDAP first and falls back to TCP whois on port 43 when a registry does not answer over HTTP; results are cached for 24 hours because registry data changes slowly and the registries are a shared resource. The ASN owner string that comes back is then normalised into a provider name and a stable slug, so HETZNER-AS - Hetzner Online GmbH, DE and Hetzner Online AG land on the same provider profile rather than creating two.

That normalisation is what makes the aggregate pages work: every check is stored, so the same ASN mapping powers the per-provider pages, the per-country hosting breakdowns and the monthly insights reports. The report keeps the CDN verdict in a separate field from the hosting verdict, precisely because one ASN can represent either.

Where ASN evidence breaks down

Four failure modes, in rough order of how often they bite:

CDN-owned ranges. If a site is proxied through Cloudflare, Fastly or CloudFront, every IP you can resolve belongs to the CDN. The ASN is real and correct; it just describes the edge, not the origin. This is the single biggest source of wrong answers in hosting detection — see why a hosting checker can be wrong about CDNs and reverse proxies and the signal-by-signal breakdown in CDN detection for Cloudflare, CloudFront, Fastly and Akamai.

Shared infrastructure. A single prefix inside one ASN can carry tens of thousands of websites on shared hosting. The ASN identifies the company running the hardware, which is correct but low-resolution: it says nothing about which plan, which server, or which of the neighbours on that IP is compromised.

Resellers and white-label hosting. A brand that sells you hosting may not own any network at all. It buys capacity inside a larger provider's ASN, so the lookup returns the wholesale operator — a data centre or cloud company — and the brand on your invoice is invisible to BGP. There is no public signal that recovers the reseller; only the site's own HTTP headers, control-panel fingerprints or nameservers might hint at it.

Upstream and parent-company naming. Some prefixes are announced by a transit provider or by a parent group rather than the operating brand, and RIR records lag reorganisations and acquisitions. An allocation dated 2002 may still carry a company name that was retired years ago.

The practical rule: an ASN is a strong claim about the network, and a weaker claim about the business. Corroborate it with reverse DNS, HTTP headers and nameserver delegation before you treat it as final — the full method is in our guide to working out who hosts a website.

Checklist: reading an ASN result properly

• Resolve the A/AAAA record and note the IP you actually got — anycast and geo-DNS can hand different answers to different resolvers.
• Map the IP to an ASN and record the BGP prefix, not just the number. A /24 is a much more specific claim than a /13.
• Check whether the ASN belongs to a known CDN before concluding anything about hosting.
• Compare the ASN owner with reverse DNS (dig -x) and the Server header. Agreement raises confidence; disagreement usually means a proxy is in the path.
• Look at the nameservers. A host that also runs the DNS is a stronger match than an ASN alone.
• If the ASN belongs to a large cloud or data-centre operator, stop at "hosted in X's network" rather than naming a retail brand.

Summary

An ASN is the identifier of a routing domain, assigned by an RIR to an operator that runs its own network. Looking one up is three commands — dig, an IP-to-ASN query and an RDAP call — and the answer is reliable about which network answers for an address. It becomes unreliable the moment a CDN, a reseller or a shared platform sits between that network and the website you asked about. As more sites move behind proxies, the gap between "whose ASN is this" and "who hosts this" keeps widening, which is why the ASN should be one input to a verdict rather than the verdict itself.

Run a domain through our checker and it resolves the IP, maps the ASN, separates the CDN layer from the hosting layer, and shows you the evidence behind each conclusion. Check your site's IP and ASN.