Who’s actually running all those tiny RPKI servers?

Why tiny RPKI servers matter

Border Gateway Protocol (BGP) still ships without built‑in trust, which leaves routing exposed to accidental or malicious prefix hijacks. Resource Public Key Infrastructure (RPKI) aims to fix that by letting IP address holders publish Route Origin Authorizations (ROAs) that say: prefix X may be originated by ASN Y, anchored in a trust chain at the five Regional Internet Registries (RIRs).

Most ROAs come straight from ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC. But there is also a long tail of small, independently operated publication servers run by cloud providers, ISPs, hobbyists, educational institutions, and RPKI as a Service (RPKIaaS) vendors. APNIC’s post digs into who operates these small servers, what they publish, and where their configurations get dangerous.

Defining “small” in RPKI

The study classifies a publication server as small if it announces fewer than 1,300 ROAs. That threshold was picked from the empirical cumulative distribution function of ROA counts across all known RPKI servers, which shows a heavily skewed distribution.

A handful of big providers — the five RIRs plus Amazon Web Services (AWS) — dominate ROA volume. The 1,300‑ROA cut‑off isolates everyone else. One exception: AWS RPKI RRDP servers are excluded entirely because their publication architecture is so unusual that the authors treat it as out of scope for now.

Recommended reading

Mira Murati’s lab unveils Inkling, a 975B open model

Why run your own RPKI server?

RIRs already provide publication as part of membership, yet many networks still operate their own infrastructure. According to the post, reasons include:

• RPKIaaS: Managed RPKI with a uniform REST API so customers can automate resource management without juggling multiple RIR portals.
• Cross‑RIR simplicity: A single interface for organizations holding space from multiple RIRs (for example, ARIN and RIPE) instead of separate accounts.
• Research and education: Academic and hobby deployments of Krill (NLnet Labs' CA software) for experimentation and measurement.
• Operational control: Tight control over signing, publication schedules, and infrastructure for networks with strict security or custom routing needs.
• Fun / learning: Personal setups that exist simply to better understand Internet routing.

The dataset: what these servers actually publish

Using the Routinator API (version 0.15.1), the authors fetched all ROAs from each qualifying server on 23 April 2026. The resulting dataset covers:

• 2,467 unique ROAs
• 3,778 prefixes
• 1,163 unique ASes

Key statistics reported:

• IPv4 prefixes with ROA coverage: 1,409, covering ~698,000 individual addresses
• IPv6 prefixes with ROA coverage: 2,369 (address range described as “astronomical”)
• IPv4 fraction of Internet: 0.0162%
• Total ROA objects analysed: 3,778, across 1,163 unique ASes
• Valid ROA objects: 3,444 (91%)
• Invalid ROA objects: 48 (1.2%)
• Unknown: 286 (7.6%), excluded from further analysis
• ROAs using maxLength: 53.98%
• maxLength ROAs with no BGP coverage: 19.6%, flagged as potentially at risk of sub‑prefix hijack

The covered address space is small in absolute terms but not trivial. The dataset includes prefixes that host government services such as gov.ai, the official domain of the Government of Anguilla. Failure of these small servers would not take the Internet down, but it could make parts of it unverifiable for some users.

None of the unknown ROAs had an active BGP announcement, which is encouraging: if they did, the affected prefixes would be wide open to hijacks.

Inside the servers: standouts and oddities

Table 3 in the post condenses per‑server stats: prefix counts, validity, maxLength usage, BGP reachability, and overlap with the Firehol blocklist (Firehol aggregates various abuse lists into a single blocklist).

r.magellan.ipxo.com — the biggest “small” server

With 776 prefixes, all IPv4 and all BGP‑reachable, r.magellan.ipxo.com (operated by IPXO) is the largest server in the dataset. 103 of those prefixes are marked at risk because of broad maxLength settings without full BGP coverage across the authorized range.

repo.rpki.space — spam infrastructure signals

repo.rpki.space has 8 Firehol level 1 matches out of only 79 prefixes, a conspicuously high ratio. BGP Tools DNS data shows a dense cluster of mailing domains, strongly suggesting spam infrastructure.

One plausible motivation highlighted by the authors: RIRs maintain active abuse procedures, and an independent publication server inserts an extra operational step into any takedown, adding friction for abuse reporters.

ca.nat.moe — 99 unknowns

ca.nat.moe is an outlier where all 99 ROAs have unknown validity, meaning they all failed cryptographic validation. The post notes that, of the valid objects, 100% are BGP‑reachable and 64 use maxLength.

rpki-01.pdxnet.uk — maxLength to the limit

rpki-01.pdxnet.uk announces almost half its prefixes with maxLength set to /32 for IPv4 or /128 for IPv6 — the absolute maximum. That formally authorizes every address in the block.

In practice this is not exploitable because BGP refuses prefixes more specific than /24 (IPv4) or /48 (IPv6) and the base prefixes already sit at those limits. The configuration is still highly unusual, and its rationale remains unclear.

Where the IP space comes from

The authors also look at which RIRs the advertised prefixes belong to. A natural assumption is that self‑hosted publication is driven by cross‑RIR allocations, but the data is mixed.

In the condensed view of 18 servers, many publish prefixes from just a single RIR, mainly RIPE. For those RIPE‑only servers, one of the most compelling arguments for a custom server — not having to manage multiple RIR accounts — does not apply.

The maxLength problem

More than half of all ROAs in the dataset (53.98%) use the maxLength parameter to authorize more specific prefixes than the ROA’s base prefix, a practice explicitly discouraged by RFC 9319.

Example from the post: a ROA for 103.0.0.0/22 with maxLength /24 authorizes every /23 and /24 in that block (103.0.0.0/24 through 103.0.3.0/24) without separate ROAs. Because BGP selects the most specific matching prefix, an attacker who controls the authorized ASN could (in principle) announce a sub‑prefix like 103.0.0.0/24 and be seen as valid, if there is no competing announcement that is faster and the announcement is RPKI valid.

The study finds that ~80% of these broad maxLength ROAs already have their sub‑prefixes covered by real BGP announcements, limiting practical exposure. The remaining 19.6% have no BGP coverage for the authorized sub‑prefixes and are flagged as potentially at risk — a legitimate ASN could be abused to originate a valid‑looking sub‑prefix hijack.

The recommended fix is straightforward: create a separate ROA per actually announced prefix, and set maxLength equal to the prefix length. The trade‑off is a larger ROA set, undoing the aggregation savings that maxLength was intended to provide.

BGPsec: standardized, still not used

The post also checks deployment of BGPsec, which verifies that every AS in a BGP path has cryptographically signed off on it. Although BGPsec has been standardized since 2017, the authors find it is effectively unused — not only in this dataset, but generally — with only a single AS announcing its routing keys.

This matches observations reported by Lisa Bruder in her blog post “BGPsec – Could you run it if you wanted to?”

Operator perspective

The researchers contacted one of the larger operators, Axivora (which runs rpki.cc, krill.accuristechnologies.ca and rpki.folf.systems), to understand why they maintain their own RRDP notification server. The post ends by noting that they received a response, and then trails off before publishing what Axivora said.