RPKI checker for domains

Enter a domain. SetEnforce finds the IP addresses of its nameservers and mail servers, looks up the prefix and AS number behind each one, and checks whether a valid ROA covers it.

The bare domain, without http:// or a path.

Free scans today Loading...

Anonymous results are kept for 1 hour. Single-standard check

The scan runs all 14 standards, not only this one. 5 free scans a day, no account needed.

How the RPKI check works

Existing RPKI lookup tools ask for a prefix and an AS number. This one starts from the domain, which is what you have when you are checking your own setup.

  1. Find the infrastructure

    The scan reads the domain's NS records, its MX records, and the NS records of each MX host. Those three groups are what a sender has to reach to deliver mail to you.

  2. Resolve the addresses

    Every one of those hosts is resolved to its IPv4 addresses.

  3. Look up prefix and AS

    For each address the scan finds the prefix that contains it and the AS number it belongs to.

  4. Ask an RPKI validator

    Each AS and prefix pair is sent to an RPKI validator, which answers valid, invalid or not found according to the published ROAs (RFC 6811).

  5. Roll up per group

    A group of servers is Valid when every prefix is valid, Partially valid when only some are, and Not valid when none are. The report shows the host, its addresses, the prefix, the AS and the state in a table.

What this check does not do

  • It does not look at the IP address of your website unless that server also hosts your DNS or mail.
  • It does not validate IPv6 addresses. They are listed, not graded.
  • It does not test whether your upstream providers drop invalid routes (route origin validation). It tells you whether your announcements would survive that filtering.
  • It does not show you the ROA itself. To read or edit a ROA, use your registry's portal.

Reading the result

These are the validity states a prefix can come back with, and what the report does with each.

RPKI validity states and their meaning
State What it means In the report
Valid A ROA authorises this AS to announce this prefix at this length. Pass, once every prefix in the group is valid.
Invalid A ROA covers the prefix, but not for this origin AS, or the announcement is more specific than the max length. Counts against the group. Some prefixes valid and some not gives Partial; none valid gives Fail.
Not found No ROA covers the prefix. The route is unprotected, not wrong. Counts against the group in the same way. A prefix with no ROA is a missing control, not an exempt one.
Unknown The validator could not be reached, so nothing is known. Inconclusive. Never reported as a pass or a failure.

What a failing result looks like

This is the finding for the authoritative nameservers, in the words the report uses. The two mail groups use the same text for their own servers.

Medium Nameserver prefixes are covered by a valid ROA bgp.rpki.nameserver_roa

FailNo valid ROA covers the prefixes announcing the authoritative nameservers (not-valid).

Impact

Without a valid ROA covering these prefixes, another network can announce them and other operators have no signal to reject the announcement. Traffic to the authoritative nameservers can be drawn to an attacker without touching the domain, the registrar or any certificate.

Remediation

Create a Route Origin Authorization for every prefix that announces the authoritative nameservers, in your RIR portal (RIPE NCC, ARIN, APNIC, LACNIC or AFRINIC):
  prefix: 203.0.113.0/24   origin AS: AS64496   max length: 24
Set max length equal to the prefix length you actually announce. A looser max length lets an attacker announce a more specific prefix that still validates, which defeats the point.
Then ask your transit providers to enable route origin validation so invalid announcements are dropped rather than merely flagged.

The prefix table with each host, address, AS and state is part of every report, including the anonymous one. The findings list with this impact and remediation text is part of the signed-in report.

How to fix a failing result

The fix is a registry change, not a server change. Who makes it depends on who holds the address space.

  1. Find who holds the prefix

    The report table shows the prefix and AS for each host. If the addresses belong to a hosting provider or a DNS provider, the provider holds the space and creates the ROA. Ask them whether they publish ROAs for it.

  2. Create the ROA

    If you hold the space yourself, sign in to your registry portal (RIPE NCC, ARIN, APNIC, LACNIC or AFRINIC) and create one ROA per prefix you announce, naming the origin AS.

  3. Keep the max length tight

    Set max length to the length you really announce. A looser value lets an attacker announce a more specific prefix that still validates.

  4. Cover every origin

    If two networks announce the same prefix, for example an anycast setup or a DDoS protection service, each origin AS needs its own ROA. Otherwise one of them shows up as invalid.

  5. Scan again

    New ROAs take a while to reach validators. If a re-scan shortly after still reports a failure, wait and run it again before looking for another cause.

Frequently asked questions

Does the checker test my website's IP address?
No. It tests the hosts that answer DNS and mail for the domain: its nameservers, its MX hosts and the nameservers of those MX hosts. A web server on a different network is not part of this check.
What is a ROA?
A Route Origin Authorization is a signed statement, published through your regional internet registry, that says which AS may announce a prefix and how specific the announcement may be (the max length). Networks that perform route origin validation use it to drop announcements that do not match.
What is the difference between invalid and not found?
Not found means no ROA covers the prefix, so a validating network has nothing to judge the route by. Invalid means a ROA covers the prefix but the announcement does not match it: wrong origin AS, or more specific than the max length. Validating networks may drop invalid routes. The report counts both against the group of servers, and the finding has the same severity either way.
Does it check IPv6 addresses?
Not for ROA validity. IPv6 addresses are listed next to each host, but only IPv4 addresses are sent for validation today.
What if the domain has no mail servers?
The two mail-related checks report Not applicable and are left out of the score. The nameserver check still applies.
What happens if the RPKI validator cannot be reached?
The result is Unknown, never Fail. An unreachable validator says nothing about your prefixes, so the report does not pretend it does.
Is a valid ROA enough to stop a hijack?
No. A ROA only helps where networks drop invalid routes. The scan does not test whether your transit providers do that; it tells you whether your announcements are valid in the first place, which is what makes the filtering possible.
Do I need an account?
No. Anonymous visitors get 5 scans a day, and results are kept for 1 hour. The findings list with the full remediation text is part of the signed-in report.

Scan a domain

Keep reading

Other checkers

On this site

  • Compliance benchmarkAnonymous, aggregate adoption rates for each standard across scanned domains.
  • FAQScan limits, result retention, passive and active scans.
  • Full domain scanAll 14 standards and 110+ checks in one report.

Knowledge base