RPKI and the DNS: protection levels going up, but still lots of room for improvement

This is a guest post by Raoul Linssen for sidnlabs.nl. Raoul is a bachelor student at the University of Twente, the Netherlands, and in this blog he summarises the findings of his bachelor research. Raoul’s mentor was SIDN Labs’ Moritz Müller.

The problem

The Border Gateway Protocol (BGP) makes sure that packets sent from one end of the internet can reach their destination at the other end. Also in case a recursive resolver wants to know the IP address of a domain name such as example.nl, BGP makes sure that the resolver's query is directed to the corresponding authoritative name server. Imagine now that the query, instead of being directed to the authoritative name server for example.nl, is directed elsewhere on the internet. In that case, the query may get lost somewhere in the abyss, preventing the resolver from fetching the IP address, or the query may even be answered by a malicious actor who responds by giving the wrong IP address. In the first scenario, clients simply can't reach example.nl, but in the second scenario they might be directed to a malicious website.

The solution

That second scenario is not fanciful. Every day, networks on the internet claim that they are the legitimate destination for addresses that they don’t own, causing traffic to be misdirected. Most of the time, such routing hijacks happen by accident, but sometimes they are intentional. Domain name registrants can partially mitigate the impact of BGP hijacks by deploying the DNS Security Extensions (DNSSEC). Then, a resolver can verify whether it has really received the right IP address for example.nl, and tell applications not to connect to an address if the associated response can’t be verified. However, the use of DNSSEC does not actually prevent the IP space hijack itself. And there is the added problem that DNSSEC signing and validation have not yet been globally adopted. The Resource Public Key Infrastructure (RPKI) is intended to address that situation. With RPKI, the owner of an IP address can publish a verifiable statement, identifying the network from which they will announce their IP address range. Routers, which are responsible for transmitting packets between networks on the internet, can take the statements into account when trying to find the best path to the IP address. If an unauthorised network claims to host an IP address, routers can use the RPKI to detect that the claim is false and ignore the information provided. You can find more details in this excellent documentation.

Measuring RPKI deployment

Authoritative name servers that are reachable at IP addresses protected with RPKI are therefore potentially harder to hijack, which in turn also protects the domain names for which they are authoritative. RPKI has gained some traction in the last few years (see Figure 1), but we were especially interested to know whether the networks in which name servers are located are RPKI-protected.

Figure 1. Adoption of RPKI (green line) 2013-2020 (source: https://rpki-monitor.antd.nist.gov/).

In this article, we focus mainly on name servers that are authoritative for .nl domain names, but also on name servers responsible for other top-level-domains (TLDs), and the root name servers. In total, we analysed the name servers of eleven TLDs in our paper. First, we obtained a list of authoritative name servers from the OpenINTEL project, which gave details of the name servers' IP addresses and the number of domain names for which they were authoritative. We then used the API of the Routing Information Service (RIS), provided by RIPE NCC, to validate whether the networks in which the IP addresses were located had rolled out RPKI. We automated all the steps described and made the program publicly available. In addition to the procedure outlined above, the program features several other functions for analysing RPKI deployment.

.nl is almost halfway

We find that 47% of name servers authoritative for .nl domain names are located in networks that are protected with RPKI. That is slightly better than the average of 45%, and way better than the figure for authoritative name servers of .com domains (23%). In the DNS, domain names can have multiple name servers. Therefore, a domain name like example.nl is only fully protected if all of it name servers are located in networks that have RPKI deployed. For .nl, that is the case for 41% of domain names; 29% have at least one name server that is protected, and 30% are not protected at all.

Other TLDs and the root lag behind

The DNS is a hierarchical naming system, meaning that only protecting your name servers is not sufficient. A resolver also relies on the name servers of the TLD and the root servers when fetching the IP address of a domain like example.nl. The .nl operator (SIDN) has placed two of its three authoritative name servers for .nl in networks that support RPKI. That reflects the general tendency for country-code TLDs to use name servers in protected networks (48% of ccTLD name servers are in such networks). The average is 27% overall. Out of all TLDs, only 190 have fully protected name servers, with .de (Germany) and .ru (Russia) as leading examples. The root servers, the most crucial name servers in the DNS, have even more catching up to do. Only the K-root servers, which are run by RIPE, are fully protected. That is a concern because it enables an attacker to hijack prefixes of the root and thus redirect traffic for all domain names.

Next steps

We can see RPKI deployment is increasing, but there is still room for improvement. However, the fact that many domain names rely on the same authoritative name servers is to our advantage. In our research, we found that by deploying RPKI at only three prefixes we could boost RPKI deployment in .com by 16%, protecting 39% of the name servers. For .nl domain names, the top three unprotected prefixes are responsible for 3.7%. At the end of the research, multiple owners of larger unprotected IP spaces were contacted in an effort to persuade them to implement RPKI. One of them signed their IP space in response to our outreach. SIDN is in touch with its name server provider, asking them to deploy RPKI for the last remaining unprotected .nl name server as well.

The bigger picture

Deploying RPKI on networks is only one part of protecting the DNS from route hijacks. Routers also need to validate announcements with RPKI, and an initial study shows that there is a lot of work to be done in that regard. Also, if only a domain's name servers are protected, it is still possible to hijack the IP addresses of the underlying service. For example, www.example.nl might point to a web server, which is not located in a protected network and consequently vulnerable to BGP hijacking. We therefore recommend the deployment of RPKI in all networks, not only the ones where DNS components are located. Furthermore, RPKI is only one piece of the puzzle when it comes to secure routing policies. Mutually Agreed Norms for Routing Security (MANRS) list additional measures that network operators should take to protect their networks and the networks of others. Finally, DNSSEC still has an important role to play in domain name protection and should still be deployed.

Download the full paper.