A Look at Route Origin Authorizations Deployment at DNS Registries

The DNS is an important component of the Internet and over the last 20 years or so, a great deal of attention has been directed at improving its inherently insecure aspects. This includes the deployment of DNSSEC that enables cryptographic validation of DNS records, and more recently DNS-over-TLS and DNS-over-HTTPS that encrypts DNS transactions between hosts and resolvers.

The DNS though, is also dependent on the global routing system for sending DNS queries from resolvers to servers, and then returning the responses. The integrity of the routing system is extremely important for ensuring DNS transactions are delivered efficiently to the correct destination, yet few DNS registries are implementing RPKI (Routing Public Key Infrastructure) at present.

BGP (Border Gateway Protocol) is the protocol used by the global routing system, yet has no built-in verification of whether IP prefixes announced on the Internet originate from their legitimate resource holders. RPKI is therefore designed to provide cryptographic verification of number resources (IPv4/IPv6 prefixes and AS numbers) using Route Origin Authorizations (ROAs) that are attestations of BGP route announcements that an AS (Autonomous System) is actually authorized to announce the associates prefix(es).

ROAs allow BGP speakers to perform ROVs (Route Origin Validation) where incoming BGP advertisements can be cryptographically validated. As a result, invalid ROAs can be dropped or given a lower priority over valid ROAs, which has been adopted by several major ISPs around the world. This means it’s increasingly important to have valid ROA for announcements, whilst safeguarding networks from possible hijacking and mis-direction of traffic.

Deployment of RPKI at DNS registries

So how much deployment of Route Origin Authorizations (ROA), in terms of signing, is happening across DNS registries? This blog post provides a look at observed deployment among the domain name Top Level Domain registries (collectively the ccTLDs and gTLDs) and Regional Internet Registries (RIRs), as well as some dives into patterns of deployment.

What is measured is whether there is a valid ROA for a route origin (a BGP prefix plus a last hop Autonomous System Number) leading to an address for a nameserver serving a TLD and other zones it manages and the same for nameservers serving the top of the so-called reverse map run by the RIRs. For example, the name servers for “COM.,” “UK.,” “CO.UK.,” as well as “128.in-addr.arpa.” are included.

In the charts, there are counts of “Zones” and “TLDs.” The count of TLDs is 1,780, comprising 1,201 gTLDs, 308 ccTLDs, and 271 reverse map zones. The count of Zones is 4,138, with the bulk of the difference from the count of TLDs being sub-ccTLD zones.

Overall Adoption

Looking over 6,910 route origins for the TLDs and Reverse Map zones, 22% have a valid ROA.  Two thoughts come to mind. First, with a low adoption rate, can we look to identify where it has taken root and where it has not, maybe to give us hints on a future course? Second, the numbers of route origins (6,190) and nameservers (4,323) seem low compared to the count of TLDs and Zones. Why is that?

The first thought suggests breaking down the data into categories. In this blog post a few methods of categorizing the data are explored. The second thought is roughly answered by “there is a lot of sharing happening,” such as many zones using the same set of nameservers, which suggests categorizing the data by service providers.

Adoption by IPv4/IPv6 Address Family

When looking at routing, the usual first step is to categorize by IPv4 or IPv6.

Dividing between IPv4 and IPv6 shows that two address families are very similar, but not equal.  It appears that routing managers treat IPv4 and IPv6 on par, which is encouraging to those who’ve been through an era where IPv6 was treated as something experimental. But a closer look reveals that there are 19 TLDs that do not have IPv6-addresses name servers! This is seen in the count of TLDs above the two pie charts.  (And that is an entirely different blog topic!)

Adoption by TLD “category”

When looking at behaviors of TLD zones, the first categorization is by the kind of zone.

Dividing into the categories of ccTLDs, gTLDs, and the reverse map zones reveals differences in deployment. There are structural differences in the way each of these categories are operated, and it is very evident in these charts.

Distribution of Deployment within a Zone

For any particular zone, the routes leading to its nameservers are managed in very different ways.  Some zone operators run all of their nameservers and have a uniform routing strategy, other zone operators outsource their DNS and therefore routing, still others trade services with other registries.

This chart shows that about 40% of TLDs (in blue) have no ROA deployment and about 40% have full ROA deployment. The remaining 20% have varying levels. What this chart doesn’t reveal is the distribution of TLDs and zones across operators.

Categorizing by DNS Administrator, Sorted by Number of TLDs Managed

The following table is generated by using the responsible name field in the Start of Authority DNS resource record and the name of the Technical Contact organization registered with the IANA Functions. The ordering of the table is from most TLDs managed downward.

Only the top 10, by TLD count, are presented here.  What the table reveals is that there are DNS administrators operating many TLDs and “crossing the lines,” administering both gTLDs and ccTLDs. There is one example (not shown) of an administrator managing gTLDs, ccTLDs, and reverse map zones.

What we are looking for is any sort of patter in the ROA Cover column, and there is nothing apparent. This suggests that the decision to deploy ROAs lies elsewhere, not directly with the DNS administrator.

Categorizing by Autonomous Systems, Sorted by Number of TLDs Served

This table highlights the routing layer supporting the studied zones. In this chart, rows for already listed operators are omitted, as indicated in the first column’s jump counting in the Row column. Only the first ten operators (not first 10 autonomous system, or “AutNum”, numbers) are listed.

There are two interesting points to this table.  First, after the first two operators, the coverage is either 0% or 100%.  Second, there are two operators above that do not operate TLDs (as defined in the study), who are listed because they provide services to those that do.

Three notes should be made, because this table is edited from the raw data.  The 13% for ULTRADNS, US represents just the listed Autonomous System Number, there are about a dozen unlisted AS numbers for ULTRADNS with varying coverages.  The names of the Operator originate from the RIR databases and some judgement was made to decide when dissimilar names were related, if just to collapse the table for publishing. And, finally, for the most part the names are as registered, except for some word-wrapping editing done.

Conclusion

This blog post omits a lot of interesting analysis and data to keep this a reasonable length. The numbers presented are from an ongoing effort to measure and visualize the operations of the Internet.  Work to do that is on ongoing task.