RPKI origin validation for resolvers!


Download cmdns-cli and run cmdns-cli -checks trans_rpkiv4.

Hints; Use trans_rpkiv6 for IPv6 check and -res <IP>:<port> to use a different resolver then the system default.

RIPE NCC RPKI web test

As RIPE79 was approaching I started to reach out to a few that might shed some light at how this test is done. Luckily some were present at RIPE79 and even more so, some had time to talk :)

Getting in to the nitty gritty I quickly realized that this wasn’t at all easy to set up yourself (disclaimer: I’m _not_ a routing person).


These beacons are placed on different networks that each have their own Route Origin Authorization (ROA) so that you can sign one correctly (A) and then have another one with an invalid signature (B).

If you can reach A but not B then you’re most likely dropping the invalid ROA, if you can reach both then you’re probably not and if you can’t reach A at all then there is probably some network problem.

NOTE; There are also Caveats (at bottom), so please read them.

Job to the rescue!

This got a bit panic-y, -”do I need to buy a /24 v4?” -”learn all things BPG” -”can I even get this to my development server hosted at Netnod” -”gaaaah…”

As email discussions was brewing in the background, I suddenly got an email from Job Snijders (NTT) with an offer to use the same networks as the web test and a bunch of addresses to use :)

-”Yay! Awesome!” and the hacking begun!


This proxy now runs on the various beacons, takes the incoming DNS queries and sends them over a back channel, letting all the checks and logic of Check My DNS run. Then the DNS responses are relayed back over the channel, to the proxy and sent back to where they came from.

Once the proxy was done it was really easy to deploy, as Check My DNS is written in Go I just compiled the proxy on my laptop, scp’ed the binary and ran it :)

RPKI resolver checks


With the new cmdns-cli option -checks you can specify a comma separated list of checks you want to run.

The check trans_rpkiv4 will check if RPKI origin validation is enabled for the resolvers that queries it on the IPv4 beacons. If you wish to test IPv6 beacons then use trans_rpkiv6 (or trans_rpkiv4,trans_rpkiv6for both).

The checks will per default use your system’s configured resolver but with cmdns-cli you can direct the queries somewhere else by using -res <IP>:<port>.

There is also the new option -list-checks which will get a list of available checks to run from Check My DNS.

But where’s the UI?

And I haven’t really decided yet if this should be added to Check My DNS’s UI or if this should be something stand-alone (love the smiling face in the web test), because it’s not just a simple DNS feature check.

To be continued…

Data available for researchers!

About Check My DNS


While this test will work reliably in most use cases, there are a few caveats to consider when interpreting the results of this test.

1) Any resolver that is hosted in a network that points a default route to NTT / AS 2914, or is downstream of a network pointing default to NTT, will be able to reach the RPKI invalid beacons at NTT.

This means that even if the resolver operator applies RPKI based BGP Origin Validation (RPKI OV) on all their peering routers and rejects invalid route announcements (which is good!) the test will indicate that no RPKI OV is happening: _a false negative_.

2) If the resolver is hosted in a network that is using another intermediate network to reach NTT, and the “in between” network is doing RPKI OV, the test may result in a false sense of security as the resolver network isn’t doing RPKI OV but the intermediate network is! Depending on the circumstances this is less optimal or fine.




Domain Name System Operations Analysis and Research Center

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store