What Routing Security Services Does ARIN Offer?
ARIN offers four routing security services: Resource Public Key Infrastructure (RPKI), Internet Routing Registry (IRR), DNSSEC, and Reverse DNS. These services help network operators validate route origins, publish routing policy, and secure DNS resolution. They are available to organizations that hold IP addresses or Autonomous System Numbers (ASNs) registered with ARIN, and they work alongside ARIN's registry and Whois data to reduce the risk of route hijacking and related attacks.
RPKI: Validating Route Origins
Resource Public Key Infrastructure (RPKI) is ARIN's framework for cryptographically validating that an Autonomous System is authorized to originate a specific IP address block. It addresses one of the most common routing security problems: a network announcing a prefix it does not legitimately hold.
The mechanism works through signed objects called Route Origin Authorizations (ROAs). A ROA is a signed statement that says, in effect, "this AS is permitted to originate this prefix." Because the statement is cryptographically signed, other networks can verify it without trusting an out-of-band source.
How the pieces fit together
- Certificate Authority: ARIN operates a Resource Public Key Infrastructure (RPKI) certificate authority that issues certificates tied to the IP address and ASN resources it manages.
- ROAs: Resource holders create ROAs to authorize specific ASNs to originate specific prefixes.
- Validation: Networks running RPKI validation (often via a relying party software package) fetch ARIN's repository, validate the ROAs, and produce a validated cache.
- Route Origin Validation (ROV): Routers use the validated cache to mark routes as Valid, Invalid, or NotFound, and can be configured to drop Invalid routes.
For example, if an organization holds 192.0.2.0/24 and wants AS64496 to be the only legitimate origin, it publishes a ROA for that prefix and ASN. A router elsewhere that sees the same prefix announced by a different ASN will classify that announcement as Invalid and can filter it.
What RPKI does and does not do
RPKI validates the origin of a route — the ASN that claims to originate a prefix. It does not validate the full AS path, and it does not by itself prevent every form of hijacking. It is most effective when widely deployed, because its protective value depends on how many networks perform route origin validation.
IRR: Publishing Routing Policy
The Internet Routing Registry (IRR) is a distributed database of routing policy objects. ARIN operates an IRR as part of its registry services. Where RPKI provides cryptographic origin validation, the IRR provides a way to document and publish intended routing policy in a machine-readable form.
Common IRR object types
| Object | Purpose |
|---|---|
| route | Associates a prefix with an origin AS |
| route6 | Same as route, for IPv6 prefixes |
| aut-num | Describes an AS and its peering/policy |
| as-set | Groups ASNs for policy expression |
Networks use IRR data to generate prefix filters. A common workflow is: an operator registers route objects for their prefixes, and their peers or upstreams build inbound filters from those objects so that only authorized announcements are accepted.
IRR and RPKI together
IRR and RPKI are complementary rather than competing. IRR objects express policy intent and can carry more detail than a ROA, while RPKI provides cryptographic proof of authorization. Many operators use both: RPKI for origin validation and IRR for filter generation and policy documentation. Because IRR data is not cryptographically signed in the same way, it relies on registry authentication and good hygiene, which is why some operators treat RPKI as the stronger signal for origin validation.
DNSSEC and Reverse DNS
ARIN provides DNS security extensions (DNSSEC) and reverse DNS services as part of its registry role. These are related to routing security in the sense that they protect the integrity of name resolution and the mapping between IP addresses and names.
- Reverse DNS: ARIN delegates reverse DNS zones for the IP address blocks it manages. Reverse DNS maps an IP address back to a hostname, and it is used in diagnostics, logging, and some security checks.
- DNSSEC: DNSSEC adds cryptographic signatures to DNS records so that resolvers can detect tampering or spoofing. For zones under ARIN's management, DNSSEC helps ensure that reverse DNS answers have not been forged.
These services matter for routing security because DNS is a frequent target for cache poisoning and redirection attacks. If an attacker can forge DNS answers, they can misdirect traffic even when routing itself is intact. DNSSEC and properly managed reverse DNS reduce that exposure.
How These Services Reduce Routing Risk
The services address different layers of the same problem:
- Origin validation (RPKI) — confirms that an AS is authorized to originate a prefix, which counters prefix hijacking.
- Policy publication (IRR) — lets networks build filters from documented intent, which reduces accidental or unauthorized announcements.
- Name and address integrity (DNSSEC, Reverse DNS) — protects the DNS layer that supports diagnostics, logging, and some security decisions.
No single service eliminates routing incidents. Their effectiveness depends on adoption: RPKI requires networks to both publish ROAs and perform validation; IRR requires accurate, maintained objects; DNSSEC requires signing and validation across the chain. The practical benefit comes from combining them and from the broader operator community doing the same.
Getting Started
If your organization holds ARIN resources, the usual first steps are:
- Log in to your ARIN account and review the resources you hold.
- Create ROAs for your prefixes through ARIN's RPKI interface, specifying the authorized origin ASN.
- Register route and route6 objects in the IRR for the prefixes you announce.
- Check whether your reverse DNS zones are delegated and whether DNSSEC is enabled where applicable.
ARIN provides documentation, help videos, and an Operational Test and Evaluation (OT&E) environment for testing registry interactions before making production changes. Because these are registry-level services tied to the resources you hold, the specific options available depend on your account and resource records.