ASNs and IP ownership: who runs the network behind an address

What an autonomous system actually is

An autonomous system is a collection of IP prefixes under a single, clearly defined routing policy. That is the whole definition, and the word policy is doing the work: an AS is the unit in which the internet's routing system expresses who is willing to carry traffic where and on whose behalf.

An AS number, or ASN, is the identifier for one of those. It appears in BGP — the Border Gateway Protocol, which is how networks tell each other which prefixes they can reach — as the origin of a prefix and as a hop in the AS path that describes how the announcement travelled.

Three corrections to the intuitive reading, each of which trips people up:

• An AS is not a company. A large organisation may hold several ASNs for different regions or acquired businesses; a small one may have none at all and simply use addresses from its provider's AS.

• An AS is not a place. The AS path is a sequence of networks, not of countries or cities, and a single AS regularly spans continents.

• Holding an ASN is not the same as holding addresses. They are separate registrations, obtained separately, and an AS can announce prefixes registered to somebody else entirely — which is normal when a provider announces a customer's block on their behalf.

You need your own ASN when you connect to more than one upstream provider and want to control how traffic reaches you. A single-homed network does not need one, because its provider's routing policy is the only one that applies.

How AS numbers are assigned, and the ranges to recognise

IANA allocates blocks of AS numbers to the five Regional Internet Registries, and each RIR assigns individual numbers to organisations in its service region under its own policies. There is no central per-organisation registry: the RIR that assigned the number is the authoritative source for it.

AS numbers were originally 16-bit, giving 0 through 65535. That space ran short, and 32-bit AS numbers extended the range to 4294967295. Both are in use today and a 32-bit number is simply a larger integer — the four-byte notation you may still see written as a pair of numbers separated by a dot has been deprecated in favour of the plain decimal form.

Some ranges are reserved and recognising them saves you a pointless lookup:

• 64512 to 65534, and 4200000000 to 4294967294, are reserved for private use by RFC 6996. They appear inside organisations and in documentation, and should never appear as the origin of a prefix on the public internet.

• 64496 to 64511, and 65536 to 65551, are reserved for documentation by RFC 5398. Examples in guides, including this one, use AS64496 for that reason.

• AS0 is reserved, and has a specific modern use in RPKI: an AS0 route origin authorisation is a statement that a prefix should not be announced by anybody at all.

• AS23456 is the placeholder a legacy 16-bit-only router substitutes when it encounters a 32-bit AS number it cannot represent. Seeing it in a path means an old speaker was involved, not that a network called 23456 was.

What a BGP announcement tells you, and what it does not

When you look up an address in a routing data service, the fundamental facts on offer are: the prefix that covers the address as it is actually announced, the AS that originates that announcement, and the AS paths by which other networks learned it.

That covered prefix is worth attention on its own, because it is frequently not the block the address is registered in. A provider holding a /16 may announce it as a single route or as a set of smaller ones; conversely, an address in a /24 assignment may be covered only by a much larger aggregate announced by the upstream. The routing view and the registration view answer different questions and disagree routinely.

BGP is also a system of assertions rather than facts. An announcement is a claim that a network can reach a prefix. Historically, nothing in the protocol verified that the originator was entitled to announce it, which is why route hijacks — accidental and deliberate — have been a recurring feature of the internet. RPKI, later in this guide, is the mechanism that changes that.

Finally, what you see depends on where you look from. There is no single global routing table. Each network has its own view, and the public route collector projects — RIPE RIS and the University of Oregon's RouteViews are the two long-running ones — publish the views of the many peers that feed them. A prefix visible from one collector and not another is normal and usually means selective announcement rather than an error.

The five RIRs, and how to query them

Address space and AS numbers are administered by five Regional Internet Registries, each covering a service region: AFRINIC for Africa, APNIC for the Asia-Pacific, ARIN for North America, LACNIC for Latin America and the Caribbean, and the RIPE NCC for Europe, the Middle East and Central Asia.

You do not need to know which one holds a given resource. RDAP bootstraps: IANA publishes ipv4.json, ipv6.json and asn.json, which map address ranges and AS number ranges to the RDAP base URL of the RIR that administers them. Fetch the file, find the entry covering your resource, append /ip/{address} or /autnum/{number}. Most clients, including the RIR lookup pages, do this for you.

Three practical ways in, in rough order of how machine-friendly they are:

• RDAP over HTTPS, returning JSON with defined member names. This is the modern interface and the one to build anything on.

• The RIRs' port-43 WHOIS servers — whois.arin.net, whois.ripe.net, whois.apnic.net, whois.lacnic.net and whois.afrinic.net. Still widely used, still plain text, and still formatted differently by each registry. Note that the RIPE, APNIC and AFRINIC databases use RPSL object types (inetnum, route, aut-num) while ARIN uses its own vocabulary (NetRange, OrgName, NetType).

• RIPEstat, the RIPE NCC's public data service, which answers over HTTPS for resources worldwide rather than only in the RIPE region, and combines registration data with routing data in one place. Its prefix-overview call, for example, returns the covering announced prefix and the originating AS with its holder name for any address you give it.

Every one of these is rate-limited, and the limits are not generous. They are built for investigation, not for bulk enrichment; if you need volume, the RIRs publish bulk data files and delegated-extended statistics for exactly that reason.

# 1. Find the right RIR from IANA's bootstrap, then query it over RDAP
curl -s https://data.iana.org/rdap/ipv4.json | jq -r '.services[][1][0]' | sort -u

curl -s https://rdap.arin.net/registry/ip/203.0.113.10 | jq \
  '{name, handle, startAddress, endAddress, type,
    abuse: [.entities[]? | select(.roles[]? == "abuse") | .handle]}'

# 2. Port 43, where the RIR's plain-text database is easier to skim
whois -h whois.ripe.net 203.0.113.10

# 3. RIPEstat: registration and routing in one answer, for any region
curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=203.0.113.10" \
  | jq '.data | {resource, announced, asns}'

# Note: 203.0.113.0/24 is reserved for documentation (RFC 5737), so these
# return the reservation rather than a live network. Substitute a real address.

Reading an inetnum, a NetRange and an origin AS

The fields differ by registry and the concepts do not. What you are looking for, whatever it is called locally:

• The range itself. inetnum in the RIPE, APNIC and AFRINIC databases; NetRange and CIDR at ARIN; startAddress and endAddress in RDAP. This is the block the registration covers, which may be much smaller than the block announced in BGP.

• The holder. netname and org in RPSL; OrgName and OrgId at ARIN; name and the entity with the registrant role in RDAP. This is who the address space is registered to.

• The status or type. ALLOCATED PA means the block was allocated to a provider to assign from; ASSIGNED PA means it is an assignment out of such a block, typically to a customer; ASSIGNED PI is provider-independent space held directly by the end user. ARIN's equivalents are allocation, assignment and reassignment. This field is the fastest way to tell whether you are looking at an ISP or at one of its customers.

• The contacts, and especially abuse-c or the RDAP entity with the abuse role. This is the address complaints should go to, and RIR policy requires it to be present and to work.

• The origin AS. In RPSL this is a separate route or route6 object, which binds a prefix to an origin AS. In ARIN's database it is expressed through the originating AS field on a network. Either way it is a registration of intent; the authoritative statement about what is actually announced is the routing data.

Specificity matters more than people expect. Querying a single address returns the most specific registration covering it. If a provider has reassigned a /29 to a customer and documented it, you get the customer. If they have not documented it, you get the provider's aggregate and no sign that a customer exists at all. An absent reassignment is not evidence that the provider runs the machine.

One RPSL detail worth knowing: the geofeed attribute, or a remarks line beginning with Geofeed followed by an HTTPS URL, points at a CSV file in which the operator states the geographic location of their sub-ranges themselves. RFC 9632, which obsoleted RFC 9092, defines how to find and use it, and it is the most reliable geolocation signal available for a network that publishes one.

Why the registered holder and the operator differ

The single biggest source of wrong conclusions in this area is treating the registered holder as the operator. They differ for entirely ordinary reasons:

• Hosting and cloud. A block registered to a cloud provider carries tens of thousands of unrelated customers. The registration names the provider because the provider holds the addresses; the machine is somebody else's.

• Reassignment that was never documented. Providers are expected to record customer assignments, and many record them only for larger blocks or not at all.

• Transfers and acquisitions. Address blocks change hands, and registration records lag. A netname can remain the name of a company that was absorbed a decade ago.

• Leased address space. Addresses are rented, sometimes through brokers, with the registration staying in the lessor's name for the duration.

• CDNs, proxies and scrubbing services. An address may belong to a network that terminates connections on behalf of a customer whose own infrastructure is somewhere else entirely and deliberately not visible.

So the registration answers who holds this address space, which is a real and useful question. Who is responsible for the traffic from this specific address right now is a different question, and the honest answer usually starts with the abuse contact of the registered holder, because they are the party who can find out.

A practical investigation, in order

When an address needs looking into, this sequence gets you the most for the least effort, and each step narrows what the next one has to explain.

• Reverse DNS first. It is one query and it is frequently the most informative single fact available: PTR records commonly name the hosting provider outright, and a generic pattern of digits and dashes tells you something too — it usually means a dynamically assigned address, which mail receivers treat with suspicion for good reason. Our reverse DNS lookup does this and also checks forward-confirmed reverse DNS, where the hostname resolves back to the same address.

• Then the RIR record, for the covering block, the holder, the status and the abuse contact. Note whether you got a specific assignment or a large aggregate.

• Then the routing view, for the prefix as actually announced and the originating AS. A mismatch between the registered block and the announced prefix is normal; a mismatch between the registered origin and the observed one is worth a second look.

• Then, if the address is a mail server, its reputation. A listing is a lead to investigate rather than a verdict, and the lists differ enormously in weight — some are consulted by a great many mail servers, others list entire network ranges as a pressure tactic against the network operator. Our blacklist check reports what it queried and, just as importantly, names the widely consulted lists it did not query and why.

• Finally, if the question is really about a domain rather than an address, run the full Domain Health Check. Mail rejection, certificate problems and DNS misconfiguration are far more often domain-level faults than network-level ones, and chasing an address when the cause is an SPF record wastes an afternoon.

For mail specifically, one network-level effect is worth naming: reputation travels by neighbourhood. Many blocklists and many receiving systems make judgements about ranges, not single addresses, so a new server on a previously abused block can inherit a problem it had no part in causing. Establishing which block and which AS you are actually in is how you find out whether that is what is happening to you.

Geolocation, and how much of it to believe

The country field in an RIR record is an administrative attribute of the registration. It is frequently the country of the holding organisation's headquarters, and it says nothing about where any particular address in the block is used. Treating it as a location is the most common mistake made with this data.

Commercial geolocation databases are a different thing: they infer location from network measurement, from operator-supplied data, and from behavioural signals. At country level they are usually right. At city level they are often approximately right. At street level they are not evidence of anything, and the consequences of pretending otherwise have been real enough that at least one widely used database's default coordinates for an entire country became a physical address people turned up at.

Three things routinely defeat geolocation entirely: VPNs and proxies, which relocate the visible address by design; mobile networks, which frequently route large regions through a small number of gateways; and CGNAT, where a great many subscribers share one public address.

The one signal worth trusting more than the rest is a geofeed published by the operator themselves, under RFC 9632, because it is a first-party statement rather than an inference. Where a network publishes one, use it in preference to any database.

RPKI and route origin validation

The Resource Public Key Infrastructure is the system that lets an address holder make a cryptographically verifiable statement about which AS may originate their prefixes. The statement is a Route Origin Authorisation, a signed object profiled by RFC 9582, which obsoleted RFC 6482 in 2024. A ROA names a prefix, the AS authorised to originate it, and an optional maximum length that bounds how specific an announcement may be.

Relying parties fetch and validate all published ROAs, producing a set of validated ROA payloads, and feed them to routers. RFC 6811 defines the three outcomes for a given announcement:

• Valid: at least one validated payload matches the prefix and origin AS.

• Invalid: a payload covers the prefix but none matches it — the origin AS is wrong, or the announcement is more specific than the maximum length allows.

• NotFound: no payload covers the prefix at all. This is not a failure; it is the state of any prefix whose holder has not published a ROA.

What networks do with those states is local policy, and the broad practice among networks that deploy validation is to drop Invalid and accept the other two. That is why a badly configured ROA is worse than none: publishing a ROA and then announcing something it does not cover makes your own prefix Invalid and can make you unreachable from every network that filters, while never publishing one leaves you exactly where you were.

Two practical cautions if you are creating ROAs. Set maxLength no larger than the longest prefix you actually announce — RFC 9319, a Best Current Practice, explains why a permissive maxLength hands an attacker a ready-made more-specific hijack that validates. And create the ROA before you start announcing, not after, so there is no window in which your own traffic is being dropped.

RPKI origin validation answers one question only: is this AS entitled to originate this prefix. It says nothing about whether the rest of the AS path is genuine, which is a separate and much harder problem.

The honest limits, and what we actually offer

It is worth being plain about how far this gets you, because tools in this space often imply more than the data supports.

• Registration data tells you who holds an address block. It does not tell you who is operating the machine, and on cloud and hosting networks it usually is not the same party.

• Routing data tells you which AS announces a prefix, from the vantage points that feed a given collector. It is not a global truth and it changes minute to minute.

• Abuse contacts are required to exist and are not required to be useful. Some are staffed and responsive; some are a ticketing address nobody reads. Their presence is not a promise.

• Country and organisation fields are administrative. They are not locations and they are not evidence about who a user is.

• None of this identifies a person. It identifies networks and organisations, and attributing activity to an individual from an IP address alone is unsound — shared addresses, CGNAT, proxies and compromised machines all sever the link.

dotvitals has no ASN lookup tool, no IP-owner lookup and no BGP viewer. We are not going to pretend otherwise, and a thin page that proxied a RIR query would not tell you anything the RIR does not already tell you for free. What we do have that genuinely helps with an address-shaped question: the reverse DNS lookup, which resolves the PTR and checks forward-confirmed reverse DNS; the blacklist check, which reports a mail server address against the lists we are licensed to query and says which ones it did not ask; and the full Domain Health Check, when the problem turns out to be the domain rather than the network. For the registration side of a domain, our WHOIS lookup reads the same RDAP protocol described here, applied to names rather than addresses.

What commonly goes wrong

• Reading the RIR country field as the location of a machine. It is an administrative attribute of the registration, and acting on it produces blocks and accusations aimed at the wrong region.

• Sending an abuse report to the upstream provider when the block is reassigned to a customer. Query the specific address, not the aggregate, so the most specific registration is what you act on.

• Treating a registered holder as the operator. On cloud and hosting networks the registration names the provider, and the machine belongs to one of thousands of unrelated customers.

• Assuming the registered route object matches reality. Route objects are registrations of intent and are frequently stale; the routing data is what is actually being announced today.

• Publishing a ROA with a loose maxLength. It validates a more-specific announcement you never intended to make, which is precisely the hijack RPKI exists to prevent.

• Announcing a prefix before the ROA exists, or changing the origin AS without updating it. Your own prefix becomes Invalid and every validating network drops it, which looks exactly like an outage with no local cause.

• Concluding that a single address is a person. Shared addresses, CGNAT, VPNs and compromised machines all break that inference, and the consequences of getting it wrong land on somebody uninvolved.