RPKI Explained: Authorizing Your Routes

The chain of trust

RPKI follows the same path as address allocation. IANA hands blocks to the five Regional Internet Registries, the RIRs hand them to their members, and each step is backed by a certificate that lists the resources it covers.

A certificate can only cover resources its parent holds, so nobody can sign a ROA for addresses that were never allocated to them. Signed objects are published in public repositories, which validators download over RRDP, defined in RFC 8182, or rsync. Common open-source validators include Routinator, rpki-client and FORT.

Most organizations use hosted RPKI: the RIR runs the certificate authority and you create ROAs in its member portal. Delegated RPKI, where you run your own certificate authority with software such as Krill and publish your own repository, suits large networks with many prefixes or automation needs, but it adds a service that must stay online.

What goes in a ROA

Each prefix and origin pair you announce needs a matching authorization. If two networks legitimately originate the same block, for example your own AS day to day and a DDoS mitigation provider during an attack, publish one ROA for each AS. A typical small network might publish:

Keep the maximum length equal to the prefix length you actually announce. A ROA for a /22 with a maximum length of 24 also authorizes every /23 and /24 inside it, including ones you never send. An attacker can announce one of those more-specifics with your AS forged as the origin, and it will validate. RFC 9319 recommends avoiding a wider maximum length unless every more-specific it covers is really announced.

Creating ROAs step by step

1. Inventory what is announced. List every prefix and origin AS as the internet sees it, not as your documentation says. A route collector or looking glass shows the real announcements, including old ones nobody remembers.
2. Find out who holds each block. Addresses registered to you at an RIR are yours to sign. Addresses borrowed from a transit or hosting provider are signed by that provider.
3. Create the ROAs in the RIR portal. Most portals suggest ROAs from the announcements they observe, which is a useful starting point. Check each suggestion against your inventory before accepting it.
4. Confirm the result. Every current announcement should validate as Valid. Any that shows Invalid is a route that enforcing networks will drop.
5. Add alerting. Monitor your prefixes for unexpected origins, unexpected more-specifics, and announcements of your own that turn Invalid.

You can check a prefix and origin against the global RPKI data with RIPEstat, or with your own validator. Replace the documentation prefix and AS below with your own; reserved examples like these have no ROA and come back as NotFound.

$ curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64510&prefix=198.51.100.0/24" \
    | jq '.data | {status, validating_roas}'

$ routinator validate --asn AS64510 --prefix 198.51.100.0/24
Valid

Changing routing without becoming invalid

Most RPKI outages are self-inflicted: a network starts announcing a prefix from a new AS, or splits it into more-specifics, and the existing ROA marks the new announcement Invalid. The safe order is always authorization first:

1. Add a ROA for the new prefix length or origin AS, keeping the old ROA.
2. Wait until public validators show the new ROA. An hour is a comfortable margin.
3. Change the BGP announcement and confirm it validates.
4. Remove the old ROA once the old announcement is withdrawn everywhere.

The same applies in reverse. When you stop using a provider, withdraw the announcement before deleting the ROA that authorized it, or the provider's last announcements go Invalid while traffic is still flowing.

Address space you hold but do not announce can still be hijacked. An AS0 ROA, defined in RFC 6483, authorizes origin AS 0, which never appears in BGP, so every announcement of that block is Invalid. Remove it before you start using the space.

What RPKI does not cover yet

A ROA authorizes the origin of a route, the last AS in the path. It says nothing about the networks in between, so a route leak, or a hijack that forges a path ending in your AS, can still validate. Two newer pieces address the path:

• ASPA, Autonomous System Provider Authorization, lets each network sign a list of its upstream providers. Validators can then spot paths that could only exist through a leak or a forged hop. It is still being standardized at the IETF, though some RIR portals and validators already support creating and checking ASPA objects.
• BGPsec, defined in RFC 8205, signs every hop of the path. It requires support on every router along the way and has seen very little deployment.

Until those are widespread, origin validation combined with strict filtering of what customers may announce remains the main defense. RPKI also only helps when networks act on it. Many large transit providers and content networks now drop Invalid routes, but not all do, so a hijack can still spread through networks that do not.

Why this matters for DNS

Authoritative name servers and public resolvers are high-value targets. Hijacking the prefix of a name server lets an attacker answer queries for every zone it serves. Publish ROAs for any prefix that holds your own name servers, and check that your DNS providers do the same for theirs. Pair that with DNSSEC, which keeps forged answers from being accepted even if the routing defense fails, and with name servers spread across networks, as described in Multi-DNS Provider Strategy.

How DNS Panopticon helps

Website Recon looks up each address a domain resolves to and shows the organization that holds the address block, from RDAP, and the AS that announces it, from BGP routing data. The holder of an address block is the one who signs its ROAs, so that tells you who is responsible for protecting a site or name server, and an unfamiliar origin AS is the first sign of a route worth checking. Domain Visualizer resolves a domain's name servers and DNSSEC status live, so you can confirm the second layer of protection is in place.

DNS Panopticon does not read RPKI repositories directly. Use RIPEstat or a validator, as shown above, to check the validation state of a specific prefix and origin.