TL;DR
Check My DNS can now check if RPKI origin validation is enabled for the resolvers that query it (read caveats below).
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
This all started a month or two ago when I was talking to a former colleague and he asked if Check My DNS could do a RPKI test similar to RIPE NCC’s web tester (hot new thing).
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).
Beacons
What you need are beacons, as they are called in the web test, which essentially is some service that you can communicate with (HTTPS for web test, DNS for Check My DNS).
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!
Another “issue” that started to become obvious was that I would need addresses to announce and the smallest you can get that would be accepted is a /24 for v4 and /48 for v6.
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!
cmdns-proxyd
First thing I needed to do was to extend Check My DNS and I managed to hack together a proxy that relayed the DNS from an external point into the logic of the daemon as if it was answered on site.
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
These checks are now available using cmdns-cli, a small Go program that can communicate with Check My DNS.
https://github.com/DNS-OARC/cmdns-cliWith 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?
I only had time to hack this together using cmdns-cli, UI stuff is hard and always takes more time than you think.
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!
As a DNS-OARC member you can get access to all of the raw test data on our analysis servers, if you wish to have access but currently don’t have access to the analysis servers please contact us.
About Check My DNS
Check My DNS is a custom developed DNS nameserver that creates dynamic delegated subdomains to enable clients to query for never-seen-before resource records in order to support a general-purpose framework for testing DNS resolvers.
Caveats
Job Snijders (NTT) comments:
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.
Cheers,
Jerry
