What an ASN background check reveals before you buy, lease or peer
An autonomous system number comes with a history. Before you take over an ASN, lease one or open a peering session with another network, it pays to know who has held it, what it has announced and how other networks see it. This article sets out what a background check covers, where the data comes from and which findings should make you stop and ask questions.
Registry records: who holds it now and who held it before
Start with the registry. In the RIPE region, the aut-num object in the RIPE Database shows the ASN’s holding organisation, its maintainers, its administrative and technical contacts, and the abuse contact. For ASNs assigned to end users, the sponsoring LIR is shown as well. Check that:
- the organisation matches the counterparty you are dealing with, by legal name and registration details
- the abuse contact is a working, monitored address
- the maintainer is controlled by the holder, not by a former provider or an unrelated third party
- the creation and last-modified dates fit the story you are being told
The current record is only a snapshot. The RIPE Database keeps version history for its objects, so you can see how the aut-num and related organisation objects have changed. Look for several changes of holder in a short period, maintainers or contacts swapped shortly before a sale, and holding organisations that have since been dissolved or renamed. None of this proves wrongdoing, but each change should have an explanation. For ASNs registered in other regions, the relevant RIR’s WHOIS or RDAP service provides equivalent data.
Routing history: what it has announced
Routing data shows how the ASN has actually been used. RIPEstat, archived BGP data from RIPE RIS and RouteViews, and tools such as the Hurricane Electric BGP Toolkit show which prefixes an ASN has originated, which upstreams and peers it has used and when it was active. Warning signs include:
- announcements of prefixes the holder has no apparent right to use, which can indicate hijacking
- short bursts of many unrelated prefixes appearing and disappearing
- announcements of unallocated or reserved address space
- upstreams with a reputation for tolerating abuse
- long dormancy followed by sudden activity, which can mean an unused ASN has been passed to a new operator without the registry record changing
Also check RPKI. Do the prefixes it announces have valid ROAs, and has it originated routes that were RPKI-invalid? An operator that keeps its routing data in order is easier to deal with in every sense.
Reputation, abuse and sanctions
An ASN’s reputation is largely the reputation of the address space it announces, and some operators filter or score traffic by origin ASN. Check:
- whether the ASN appears on the Spamhaus ASN-DROP list, which names ASNs that Spamhaus considers controlled by spammers or cybercriminals, or hijacked
- blacklist and threat-intelligence results for the prefixes it originates now and has originated in the past
- whether it is covered by escalation lists that target entire ASNs because of activity across their space
For EU companies, an ASN deal is also a transaction for sanctions purposes. Screen the holding organisation, its directors and its beneficial owners against the EU consolidated sanctions list, and against other regimes where your business has a connection to them. Look at where the network operates and who its upstreams are; routing through networks in sanctioned jurisdictions raises questions even when the holder itself is not listed.
Extra checks before you peer
Peering is not a transfer, but a careless peer can still cause harm through route leaks or announcements it should not be making. Before you turn up a session:
- review the network’s PeeringDB record for facilities, contacts and peering policy
- expand its IRR as-set and check that the ASNs and prefixes in it make sense for a network of its size
- confirm its announcements are covered by valid ROAs
- set sensible maximum-prefix limits and build filters from IRR and RPKI data rather than accepting everything
If a prospective peer’s as-set contains networks you cannot explain, ask before connecting, not after a leak.
A checklist to work through
The table below summarises the checks, where the data comes from and what should prompt further questions.
| Check | Main sources | Red flag |
|---|---|---|
| Current holder | RIPE Database aut-num and organisation objects | Holder does not match the counterparty |
| Holder history | RIPE Database version history | Several recent changes without explanation |
| Routing history | RIPEstat, RIS, RouteViews, BGP toolkits | Hijacks, bogon announcements, unrelated prefix bursts |
| Reputation | Spamhaus ASN-DROP, blacklists, threat intelligence | Listings on the ASN or its prefixes |
| Sanctions | EU consolidated list, company and ownership registers | Listed holder, owner or director |
| Peering readiness | PeeringDB, IRR, RPKI | Inaccurate as-set, missing or invalid ROAs |
Record what you checked, the date and what you found. If you go ahead, that file shows the diligence behind the decision; if you walk away, it explains why.
How TACS can help
Our ASN background check covers holders, routing history, reputation and sanctions screening, and tells you which findings matter before you commit. If you need an ASN of your own, our ASN page explains registration, lease and transfer options.