[Skip to content](#content) ![APNIC Home](https://webdist.data.apnic.net/web-framework-theme/9.1.5/images/apnic.svg) [Skip to the article](#article-content) # Who’s running all those tiny RPKI servers? By Ties Dirksen on 15 Jul 2026 [Ties Dirksen](https://blog.apnic.net/author/ties-dirksen/)

APNIC Home

Who’s running all those tiny RPKI servers?

By Ties Dirksen on 15 Jul 2026

Ties Dirksen

Category: Tech matters

Tech matters

Tags: Guest Post, routing, RPKI, security

Share on LinkedIn

Blog home

Conny Schneider

Unsplash

Border Gateway Protocol (BGP) lacks built-in trust, leaving the Internet routing layer exposed to accidental or malicious prefix hijacks. Resource Public Key Infrastructure (RPKI) addresses that problem by letting address space holders cryptographically authorize which Autonomous System (AS) may originate their prefixes, via Route Origin Authorizations (ROAs) published through a chain of trust anchored at the five Regional Internet Registries (RIRs).

While most ROAs are published directly by the RIRs, a long tail of smaller, independently operated publication servers (run by cloud providers, ISPs, hobbyists, educational institutions, and RPKI as a Service (RPKIaaS) companies) also contributes to the global RPKI dataset. In this post, we investigate who operates those small servers and why.

What is RPKI and why should you care?

Every time you open a website, your traffic hops across dozens of routers guided by BGP. BGP is the glue of the Internet: It tells routers where to send packets to reach any IP address on the planet. The trouble is that BGP was designed for an era when networks trusted each other, and misbehaviour was still uncommon. Any network can (accidentally or maliciously) announce that it owns an IP prefix it does not actually control. That is called a routing incident, and it can cause your traffic to be silently redirected to the wrong destination.

RPKI is (one of) the Internet’s answers to that problem. It works by letting the rightful owners of IP address blocks cryptographically sign a ROA; a small record that says: ‘IP prefix X is authorized to be announced by Autonomous System Number (ASN) Y.’ Routers that implement Route Origin Validation (ROV) then use those signed records to check incoming BGP announcements and drop the ones that don’t match.

The entire system rests on a chain of trust anchored at the five Regional Internet Registries (RIRs): ARIN (North America), RIPE NCC (Europe/Middle East/Central Asia), APNIC (Asia Pacific), LACNIC (Latin America) and AFRINIC (Africa). Those bodies issue IP address space to networks and operate the top-level RPKI Certification Authorities (CAs). ROA objects can be published directly from the RIR servers, or from smaller, independent publication servers.

Small RPKI publication servers

Most ROA objects are published by the five RIRs, which are well-resourced, professionally maintained and globally trusted. But alongside those giants sits a long tail of smaller publication servers run by cloud providers, hobbyists, educational institutions, Internet Service Providers (ISPs) and RPKIaaS companies. During the research described in this post, we examined these ‘small’ servers to see what we can learn from them, why they operate and why they exist in the first place.

Defining ‘small’

The first methodological challenge was defining what makes a server ‘small’. We used a straightforward, ROA-count-based definition:

A server is classified as ‘small’ if it announces fewer than 1,300 ROA objects.

That threshold was chosen by inspecting the empirical cumulative distribution function (ECDF) of ROA counts across all known RPKI servers. The distribution is heavily skewed: A handful of large providers (the five RIRs and Amazon Web Services (AWS)) account for most ROAs. The 1,300-ROA cut-off captures the natural break between those large players and the rest.

One notable exclusion: The AWS RPKI Repository Delta Protocol (RRDP) servers. Amazon constructs its RPKI publication infrastructure unusually. Their architecture is distinct enough from the other small servers that it was kept out of scope. Whether that construction offers operational advantages remains an open question for future research.

Why would anyone run their own RPKI server?

The existence of small servers naturally raises the question: Why bother? The RIRs already provide publication services as part of membership. The answer is that there are several legitimate reasons to operate independently; the table below lists a few examples.

The dataset: IP space statistics

Using the Routinator API (version 0.15.1), we fetched all ROA objects from each qualifying publication server as of 23 April 2026. The resulting dataset spans 2,467 unique ROAs covering 3,778 prefixes across 1,163 unique ASes. Table 2 summarizes the key numbers.

Valid: At least one Validated ROA Payload (VRP) covering the announced prefix exists (same or less specific, within max length) with a matching origin AS.

Invalid: A Validated ROA Payload (VRP) covering that prefix space exists, but part of the information in the VRP is incorrect, or the object has expired.

Unknown: No VRP was found, or an incorrect VRP was found and has been dropped.

A few figures stand out. The covered IPv4 space (698,000 addresses, or 0.016% of all IPv4 addresses) and IPv6 space (addresses or %) both look small, but it is far from insignificant. The dataset includes prefixes hosting government services (such as gov.ai, the official domain of the Government of Anguilla) and potentially other services people rely on daily. The failure of such servers would not break the Internet, but it could quietly make parts of it unverifiable for a subset of users.

None of the unknown ROA objects had active BGP announcements. That is good news, since it would indicate that the prefixes in question are vulnerable to BGP-hijacks.

Inside the numbers: The server overview

Table 3 condenses the per-server statistics from the research. Each row represents one publication server, with columns showing prefix counts, validity breakdown, maxLength usage, BGP reachability and Firehol (a company that combines lists of different abuse lists to try and create a comprehensive and complete list of prefixes to block to ensure an acceptable level of safety) blocklist overlap. A few rows are shown below as examples.

Firehol

Table 3 — Condensed overview of analysed RPKI publication servers (top 15 by prefix count). ‘At-Risk’ = maxLength ROAs with no corresponding BGP announcement for the authorized sub-prefixes.

In the remainder of this section, we will point out some servers that exhibit strange behaviours and describe the uncommon behaviours they exhibit.

r.magellan.ipxo.com: The largest and most complex

With 776 prefixes, the Magellan server operated by the company IPXO is the largest in the dataset. All 776 are IPv4, and 100% are BGP-reachable, but 103 are flagged as at-risk due to broad maxLength settings without full BGP coverage of the authorized range.

IPXO

maxLength settings without full BGP

repo.rpki.space: Spam infrastructure

With 8 Firehol level 1 blocklist matches out of only 79 prefixes, repo.rpki.space stands out immediately. Inspection of BGP Tools DNS records for this server reveals a high density of mailing domains, strongly suggesting that spam mailing infrastructure is hosted across the prefixes in question. One potential reason a spam operator would run their own RPKI server — the RIRs have active abuse prevention procedures, and having an independent publication server adds an extra step in the takedown chain; a layer of operational friction for abuse reporters.

ca.nat.moe: 99 unknown objects

This server is a striking outlier: Every single one of its 99 ROA objects has unknown validity status, meaning all 99 failed cryptographic validation. Nevertheless, of the valid objects, 100% are BGP-reachable and 64 use maxLength.

rpki-01.pdxnet.uk: The maxLength puzzle

This server announces almost half of its prefixes with maxLength set to 32 (IPv4) or 128 (IPv6) — the maximum possible prefix length. That means that every IP address within the announced range is formally authorized. In practice, that is not exploitable: BGP does not accept prefixes more specific than /24 for IPv4 or /48 for IPv6, and the underlying prefixes are already at those limits. The reason for this unusual configuration remains unexplained.

Where does the IP space come from?

One of the most interesting structural findings concerns the RIR origin of prefixes announced by small servers. When an organization publishes ROAs on its own server, a natural expectation might be that it has cross-RIR allocations (IP space from multiple registries), which would make a single publication point convenient. The data tells a more nuanced story.

Table 4 — RIR origin presence per publication server (condensed first 18 servers). A checkmark indicates that at least one prefix from that RIR was present in the server’s ROA set.

A sizable proportion of servers announce prefixes from only a single RIR (mainly RIPE). For servers that draw exclusively from RIPE, one of the most compelling reasons for running a custom server (avoiding managing multiple RIR accounts) does not apply.

The maxLength problem

More than half of all ROA objects in the dataset (53.98%) use the maxLength parameter to authorize announcements for prefixes more specific than the one listed in the ROA. RFC 9319 explicitly discourages that practice.

RFC 9319

An ROA for 103.0.0.0/22 with maxLength /24 does not just authorize the /22; it authorizes every /23 and /24 within that block, 103.0.0.0/24 through 103.0.3.0/24, without requiring a separate ROA for each. From a BGP perspective, the most specific matching prefix wins. So, if an attacker who controls the authorized ASN announces 103.0.0.0/24 (in principle), every relying party will mark it valid. The broader ROA has authorized the hijack (if there is no competing BGP announcement that is faster, and the announcement is RPKI valid).

Of the ROAs with a broad maxLength setting, approximately 80% already have the more specific sub-prefixes covered by existing BGP announcements, meaning the actual exposure is limited in most cases.

However, the remaining 19.6% have no BGP announcement covering the authorized sub-prefixes. Those represent potentially at-risk configurations: A sub-prefix hijack using the legitimate origin of the ASN could pass RPKI validation unchallenged (again if there is no competing BGP announcement that is faster, and the announcement is RPKI valid).

The fix is straightforward in principle — create a separate ROA for each prefix you intend to announce and set maxLength equal to the prefix length itself. The downside is that that increases the ROA count significantly — exactly the opposite of the aggregation benefit that maxLength was designed to provide.

BGPsec

BGPsec is a method that verifies whether the announced BGP route has been cryptographically validated by every single AS in its path. That means that BGPsec verifies whether every AS in the announced path agrees that the path is valid. Even though BGPsec has been standardized since 2017, we found that (not only in our dataset) BGPsec is simply not deployed (having only a single AS announcing its routing keys), as also noted by Lisa Bruder in her blog post: BGPsec – Could you run it if you wanted to?.

BGPsec – Could you run it if you wanted to?

A word from one of the operators

We have reached out to one of the bigger operators (Axivora, which operates rpki.cc, krill.accuristechnologies.ca and rpki.folf.systems) to understand why they run their own RRDP notification server, and we got the following response:

Axivora

The short answer is that we originally started running our own RPKI publication infrastructure because we were (and still are) Internet enthusiasts who wanted to understand how the system actually works.

Axivora still leases two dedicated IPv6 PA /40 allocations for educational and research purposes. Within those prefixes, they delegate smaller allocations to individuals who want their own independent address space. They handle the logistics of creating the corresponding ROA and IRR records for them, and they eliminate the need for them to operate their own ASN.

The original reason for running their own publication infrastructure was to get a better understanding of the RPKI ecosystem and to learn how ROAs propagate through the Internet.

Today, all their business prefixes use RIPE’s PaaS services, yet they continue to operate their own publisher server for research, educational and experimental purposes.

And, admittedly, we still think it’s pretty cool.

Conclusion

Taken together, the data suggests that small RPKI publication servers cover a relatively modest corner of the Internet. Even though the prefixes they cover are tiny in aggregate, they include some crucial services such as government domains. While the failure of such servers would not break the entire Internet, it would have ramifications for the verifiability of the Internet and potentially break specific prefixes, making them unreachable.

On the validation side, the picture seems relatively healthy: 92.4% of the ROA objects are valid and, of those objects, 91% carry an active and matching BGP announcement. The only notable metric here is that the unknown rate of 7.6% is relatively high.

A clearer area that raises some concern is the usage of maxLength. More than half of the ROA objects did not adhere to the recommendations of RFC 9319, which is not inherently problematic. However, 19.6% of those did not have BGP announcements that covered all sub-prefixes they permitted. Leaving a relatively limited but relevant risk of sub-prefix hijacks. That risk is, however, not exclusive to those publication servers and could very well exist with larger publication servers as well.

Other protective technologies had similarly not been deployed on the set of servers we studied. BGPsec was not deployed at all.

As for why operators choose to run their own infrastructure, the data broadly suggests cross-RIR simplicity as the dominant reason, but not the only one. Educational purposes proved to be a less common motivation than initially expected.

Ties Dirksen is a second-year Master’s student in Computing Science specializing in Cybersecurity at Radboud University Nijmegen in the Netherlands. In 2026, he interned at SIDN Labs, where he conducted research into small RRDP notification servers, why they exist, and who operates them. SIDN Labs is the research team of SIDN, the administrator of the .nl domain.

This post was originally published at SIDN Labs.

SIDN Labs

The views expressed by the authors of this blog are their own

and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Code of Conduct

Get Updates

Thanks for subscribing! Check your inbox or spam folder to confirm your subscription.

Authors

Adli Wahid

Aftab Siddiqui

Geoff Huston

George Michaelson

Jen Linkova

Jia Rong Low

Job Snijders

Kathleen Moriarty

Premanand Seralathan

Ulrich Speidel

A Khalil Azizi

A S M Rizvi

AbdelRahman Abdou

Abhishek Jain

Abu Sufian

Achie Atienza

Adam Gosling

Adam McFillin

Adam Oest

Adeel Sadiq

Adiel Akplogan

Adisorn Lertsinsrubtavee

Adli Wahid

Adrian Farrel

Adrian Wan

Afifa Abbas

Afsheen Saadat

Aftab Siddiqui

Agustín Formoso

Ahmad Darki

Ajay Kumar

Akimichi Ogawa

Alain Aina

Alan DeKok

Alan Mauldin

Albert Gran Alcoz

Alden Hilton

Alec Muffett

Alejandro Acosta

Alex Band

Alex Boten

Alex Turing

Alex Yen

Alexander Azimov

Alexander Kozlov

Alfred Arouna

Ali Abedi

Ali Norouzi

Amanda H A Watson

Amaury Van Bemten

Amreesh Phokeer

Amrita Choudhury

Anand Buddhdev

Anant Shah

Andra Lutu

Andre Gelderblom

Andrea Sordello

Andreas Dewes

Andreas Reuter

Andree Toonk

Andrei Robachevsky

Andrew Ayer

Andrew Campling

Andrew Cormack

Andrew Cushen

Andrew Ferguson

Andrew Gray

Andrew Sullivan

Andrew Toimoana

Andrijana Todosijević

Andy Mindnich

Andy Newton

Anju Mangal

Anna Maria Mandalari

Annaliza Mulingbayan

Anosh Khan

Anriette Esterhuysen

Anthony Lee

Anton Strydom

Anup Changaroth

Anurag Bhatia

APNIC

Apoorv Shukla

Arash Molavi Kakhki

Arian Niaki

Aris Tzermias

Arjuna Sathiaseelan

Arlin Kokkelmans

Arth Paulite

Arthur Gilly

Artyom Gavrichenkov

Arun Neelicattu

Asad Ali

Asanka Sayakkara

Ashil Oogarah

Ashwin Kumar

Ashwin Rangan

Athina Fragkouli

Audrey Randall

Aurélien Aptel

Austin Hounsel

Austin Ruckstuhl

Avery Pennarun

Ayesha Iftikhar

Aysha Labiba

Ayush Mishra

Azfar Adib

Azhar Khuwaja

Azura Mat Salim

Baojun Liu

Baptiste Jonglez

Barbara Jantzen

Barry Greene

Bart Hogeveen

Basileal Imana

Bastian Kanbach

Batmagnai Erdene

Bayar Batjargal

Beau Gieskens

Ben Cox

Ben Du

Ben Schwartz

Benjz Gerard Sevilla

Benno Overeinder

Berislav Todorovic

Bert Hubert

Bhadrika Magan

Bhumika Sapkota

Bikram Shrestha

Bill Hess

Bill Stearns

Bill Woodcock

Bjørn Teigen

Blake Anderson

Blandine Cousin

Blas Trigueros

Branden Palacio

Brandon Hitzel

Brenda Buwu

Brenden Kuerbis

Brent Carey

Brett Bralley

Brian Carpenter

Brian Nisbet

Brian Trammell

Brianna Boudreau

Bruce Davie

Bruce Spang

Byambajargal Jamsran

Byron Ellacott

Byungjin Jun

Cameron Steel

Carlos Martinez-Cagnazzo

Carsten Strotmann

Caspar Schutijser

Cecilia Testart

Cengiz Alaettinoglu

CF Chui

Champika Wijayatunga

Charith Amarasinghe

Che-Hoo Cheng

Cheeyong Tay

Cherie Lagakali

Chia Ling (Jolin) Chan

Chika Yoshimura

Ching-Heng Ku

Chris Amin

Chris Buckridge

Chris Grundemann

Chris Parker

Chris Ritzo

Chris Siebenmann

Christian Giese

Christian Huitema

Christoph Dietzel

Christopher Hawker

Chuan Jiang

Ciprian Popoviciu

Clarence Filsfils

Claudio Jeker

Clemens Mosig

Colin Perkins

Constance Bommelaer

Constantin Sander

Constanze Dietrich

Cordian Daniluk

Craig Miller

Craig Ng

Craig Rowland

Dale Roberts

Dan Fidler

Dan Groshev

Dan Li

Daniel Dib

Daniel Kopp

Danilo Giordano

Danny Alex Lachos Perez

Danny Pinto

Daryll Swer

Dashzeveg Baatartsogt

Dave Mill

Dave Phelan

David Anderson

David Burkett

David Dawson

David Holder

David Holsgrove

David Huberman

Dean Pemberton

Debashis Pal

Debopam Bhattacherjee

Deepak Vasisht

Denesh Bhabuta

Dennis Baaten

Désirée Miloshevic

Dewangga Alam

Dewole Ajao

Dhruv Dhody

Di Ma

Diego Pino García

Dinesh Bhatia

Diptanshu Singh

Dirk Doesburg

Dirk Trossen

Dmytro Shypovalov

Donatas Abraitis

Donika Mirdita

Doug Madory

Doug Montgomery

Dr Bahaa Al-Musawi

Dr Govind

Drikus Brits

Duane Wessels

Duncan Macintosh

E. Marie Brierley

Ebrima Jaw

Ed Horley

Edward Lewis

Edwin Sandys

Ege Cem Kirci

Eline Stehouwer

Eliot Lear

Elizabeth Krumbach Joseph

Ellisha Heppner

Elly Tawhai

Elvin Prasad

Emile Aben

Emily Gallarde

Emily Stark

Emir Beganović

Eneken Tikk

Enno Rey

Enric Pujol

Eric Lawrence

Eric Loos

Eric Vyncke

Erik Hjelmvik

Erik Rye

Erin Scherer

Eshaan Bansal

Esteban Carisimo

Eugene Bogomazov

Eunju Kang

Eunju Pak

Eyal Estrin

Fabián Bustamante

Fahad Hilal

Fakrul Alam

Farbod Shahinfar

Farha Diba

Fenglu Zhang

Ferenc Fejes

Fernando Gont

Flavia Salutari

Flavio Luciani

Florentin Rochet

Florian Holzbauer

Florian Steurer

Florian Streibelt

Foy Shiver

Francesco Ferreri

Francesco Sassi

Franck Martin

François Michel

Frane Maroevic

Frank Denis

Frank Herberg

Franziska Lichtblau

Fred Christopher

Fred Templin

Fredrik Lindeberg

Gael Hernandez

Ganga R Dhungyel

Gaurab Raj Upadhaya

Gautam Akiwate

Gavin Reid

Gavin Tweedie

Geoff Huston

George Kuo

George Michaelson

George Odagi

George Sadowsky

George Salisbury

Giacomo Giuliari

Gianmarco Pagani

Gina Mahe

Giovane Moura

Gomer Padong

Gonchig Altansukh

Gordon King

Greg Ferro

Greg Hankins

Grégory Mounier

Guangliang Pan

Guillermo Baltra

Guoliang Yang

GZ Kabir

Ha Dao

Haisheng Yu

Hammas Bin Tanveer

Han Zhang

Hanna Kreitem

Hannah Durack

Hanno Böck

Hans Petter Holen

Harish Chowdhary

Haya Schulmann

Helen Hollins

Herbert Wolverson

Hervé Clément

Hideyuki Sasaki

Hinne Hettema

Hiroki Kawabata

Hiroko Kamata

Hiromu Shiozawa

Hisham Ibrahim

Hoàng Nguyên Phong

Holly Bergen

Houlin Zhao

Hyeonmin Lee

Hyojoon Kim

Ignacio Castro

Ihita Gangavarpu

Ike Kunze

Ilker Nadi Bozkurt

Imtiaz Rahman

Indya Bolton

Ioana Livadariu

Italo Cunha

Ivan Ristić

Ivana Tomic

Ivo A. Ivanov

Ivy Yip

Izumi Okutani

Jaber Daneshamooz

Jaclyn Knight

Jacob Davis

Jacob Ginesin

Jahangir Hossain

Jake Bauer

Jake Flint

Jake Holland

James Ah Wai

James Bensley

James Kettle

James Pavur

James Richards

James Shank

Jamie Gillespie

Jan Doskočil

Jan Harm Kuipers

Jan Rüth

Jan Schaumann

Jan Zorz

Jan-Piet Mens

Jane Yen

Jannik Peters

Jari Arkko

Jason Livingood

Jason Reid

Jason Smith

Jasper den Hertog

Jawad Ahmed

Jay Daley

Jay Ford

Jeff Chan

Jeff Fry

Jeff Man

Jeff Osborn

Jen Linkova

Jenine Beekhuyzen

Jens Link

Jeremy Harrison

Jerry Lundström

Jessica Shen

Jessica Wei

Jethro Webston

Jia Rong Low

Jilong Wang

Jim Cowie

Jim Forster

Jim Vella

Jimmy Lim

Jing Qiao

Jinghua Bai

Jinwei Zhao

Joanna Kulesza

João L. Sobrinho

Joao Luis Silva Damas

Joao M. Ceron

Job Snijders

Joel Jaeggli

Johanna Amann

Johannes Krupp

Johannes Weber

Johannes Zirngibl

John Althouse

John Bambenek

John Curran

John Garrity

John Jack

John Jason Brzozowski

Who's running all those tiny RPKI servers?