We saw an interesting blog post from Dyn Research about the Internet in Iran earlier this week. In the second part of that article, the K-root server instances in Iran are investigated. We'd like to add some additional context to their observations. Please also see this earlier RIPE Labs article on K-root in Iran in this context.

The RIPE NCC is the operator of K-root, one of the 13 DNS root servers.

Looking at the Facts

When Dyn says "More leaks of K-root instance in Tehran" it implies that the configuration where Iranian K-root instances are seen beyond Iran is unintentional, and undesired.

This is an interesting assumption, especially since the DNS root server system uses anycast heavily. When using IP anycast, an IP address is used in multiple (geographical) locations at the same time and the Internet routing system determines which physical device this IP address packet goes to, if you try to send packets to that IP address. 

On the Internet, anycast is usually implemented by using Border Gateway Protocol to simultaneously announce the same destination IP address range from many different places on the Internet. This results in packets addressed to destination addresses in this range being routed to the "nearest" point on the net announcing the given destination IP address. In the past, anycast was suited to connectionless protocols (generally built on UDP), rather than connection-oriented protocols such as TCP that keep their own state. Anycast is generally used as a way to provide high availability and load balancing for stateless services such as access to replicated data; for example, DNS service is a distributed service over multiple geographically dispersed servers. (Wikipedia article on Anycast).

In the case of K-root, the anycast is from 50 sites as is publicly documented at www.root-servers.org (see Figure 1).

Figure 1: Screenshot of the information for K-root on www.root-servers.org

As we stated in our earlier response to a Dyn article, the host of a K-root DNS server instance decides on the scope. Earlier we had a single hosting organisation for an instance in Tehran, but currently we have three hosting organisations hosting three instances in three separate networks. For one of them, routing information was not scoped locally, which explains why a Tehran K-root instance can be seen by clients from outside of Iran. Since the Internet is not a collection of nation-state networks, it is to be expected that for anycasted services it can and will happen that clients in a certain country will be directed to server instances that are not in the same country (see more on that below). Scoping of reachability information is determined by the interplay of network operators originating and accepting routing information.

Transparency

It's all fine and dandy that IP anycast and local policy decisions cause DNS packets to go to certain physical instances of servers, but how can I check what DNS root server instance my DNS packets go to, and maybe even take action to change that?

Besides operating K-root, the RIPE NCC is also operating RIPE Atlas. RIPE Atlas is a large Internet measurement platform consisting of over 9,000 individual devices that constantly measure the Internet actively.

One of the measurements all RIPE Atlas devices do is a check of the DNS root-server infrastructure, from which one can see which physical instance of a particular DNS root server a packet ends up at (this uses the hostname.bind convention as described in RFC 4892). Please also see this RIPE Labs article by Stéphane Bortzmeyer for more details.

You can monitor the live status of this on a map of the RIPE Atlas website. This map shows a circle for every RIPE Atlas device. The colour of the circle is determined by the physical location of the K-root DNS server that we see in measurements. Colours indicate geographic regions: Africa (brown), Europe (blue), South America (orange), Asia (red), North America (green), Middle East (yellow) and Oceania (pink). A snapshot of this for K-root can be seen in Figure 2. As you can see already from this snapshot, sources in a particular region mostly get answers from instances in the same region, but this scoping is far from 100% "watertight". K-root instances in Europe (blue) are seen by clients pretty much all over the world, while instances in North America are seen in South America and Myanmar, just to name a few.

Figure 2: K-root DNS instances as seen on 11 January 2017 (colours indicate regions: Africa (brown), Europe (blue), South America (orange), Asia (red), North America (green), Middle East (yellow) and Oceania (pink))

These maps have functionality that allows you to zoom in on a single server location. You can also to see the situation at a specific point in time (with the help of the time travel functionality). We can see where RIPE Atlas sees specific instances of K-root in Tehran on 9 January 2017 (see Figure 3) and 12 January 2017 (see Figure 4). The visibility of the K-root instance in Tehran changed between these two dates because we helped make a routing configuration change for one of the servers in Tehran, at the request of one of the upstream networks.

Figure 3: K-root Tehran instances as seen on 9 January 2017

Figure 4: K-root Tehran instances as seen on 12 January 2017

If DNS and network operators see something in these maps or in the data we provide that they think is out of the ordinary, please contact us (see our AS25152 aut-num object for contact details).

How Many Queries Between Far Away Caching Resolvers and Root Servers?

As we stated in our article on RIPE Labs, caching resolvers will heavily bias the number of queries towards the server that is closest in terms of latency (see this excellent presentation on various caching resolver implementations ). If, for one of the root servers, latency increases for whatever reason, the number of queries it actually receives goes down significantly, because caching resolvers will prefer other more local root servers. So a caching resolver in Bejing that reaches a local F-root instance in 10ms, but has 258ms latency to B-root in California, will almost never do queries towards B-root (see Figure 5). Note that this effect goes on top of the heavy caching that is already done within the DNS, which typically causes DNS lookups to be answered by a caching resolver that only rarely needs to contact a DNS root server.

Figure 5: Example of latencies from a location in Bejing, China towards all DNS root servers

Mechanisms Against Censorship and Privacy Intrusion: DNSSEC and DPRIVE

Since the Snowden revelations, we know that many nation states do Internet mass surveillance. Internet users, and especially the technical communities around the Internet, have become much more privacy focused. One result of this is the IETF DPRIVE working group. Specifically, the recent qname-minimisation work specified in RFC 7816 is a significant effort to minimise the ability for snooping. A few modern DNS caching resolvers already allow for qname-minimisation.

But going back much further, DNSSEC is a significant effort to help detect tampering, and currently has a significant deployed base. In this case, if there had been tampering going on, it should have been detected by clients doing DNSSEC validation.

Long story short: DNSSEC helps to detect tampering, DPRIVE concepts help against snooping, and the RIPE NCC has been supporting, and intends to continue supporting, deployment of these technological improvements.

Final Thoughts

It's not easy to interpret routing behaviour without a detailed view of operational policies. We hope that this post and our tools and data sets provide transparency and clarity to do so.

Note that the RIPE NCC is going to organise a hackathon for DNS-tools soon. So if you are interested to help create better tooling around this, please look out for the announcement of this hackathon.

The RIPE NCC is committed to an open Internet, and as part of that we intend our services to be open and transparent.