Identity Theft Hits the Root Name Servers

There have been a number of attacks on the root name servers over the years, and much written on the topic. (A few references are here, here and here.) Even if you don’t know exactly what these servers do, you can’t help but figure they’re important when the US government says it is prepared to launch a military counterattack in response to cyber-attacks on them.

This posting is about an attack on one such root name server. Actually, “attack” isn’t really an appropriate term. It was not really an attack or a hijack or even identity theft. For one thing, these terms imply the existence of both a victim and a villain. In this story, the villains are not obvious and there might not have been any victims. And as we will see, you can’t really steal something you own. All we can say for certain is that many of you, if not most, probably used an unauthorized root name server over the past few months and were blissfully unaware of it. These bogus servers may have acted just like a normal root server, providing the correct answers to your queries without logging your requests. But since these servers are now shut down, we can no longer investigate what they were doing. And we can only guess at the motivations of those who set them up.

Now what?

As most readers of this blog will know, when you access any resource on the Internet by name (e.g., www.cnn.com), your computer must first convert this name into an IP address (e.g., 64.236.29.120), which it then uses to gain access to the resource you’ve requested. The process of converting names to IP addresses relies on a distributed hierarchy of servers, each responsible for only a subset of names, with the root name servers at the top of this heap. The root servers tell you how to reach the top-level domains, like .com, .gov, or .uk, and from there you can work your way down the hierarchy to find what you want. This is why the root name servers are so important. They are the starting point for navigating the Internet.

Your computer routinely requests the IP addresses for the names of the sites you wish to visit from its local name server. The local name server will faithfully and silently traverse the naming hierarchy to find IP addresses for you on demand. To get started, your local name server needs to know the IP addresses of the root name servers, and since this list almost never changes, it is typically buried in some static configuration file. There are 13 root server IP addresses. Each of these is known by a single letter (A through M). The problem is that the IP address of the L root name server (l.root-servers.net) actually did change recently. After which, unauthorized root name servers running from the old IP address for L started popping up around the globe, the very same address that every provider has squirreled away in that configuration file that is rarely, if ever, updated.

The technical details

So now let’s get into the details of what we know about this incident. The L root name server is run by ICANN and until recently, this server had an address of 198.32.64.12. On 24 October 2007, ICANN announced it was changing to the address to 199.7.83.42, effective 1 November 2007. Did you catch that announcement on the evening news? Me neither.

The Register published a story on this change shortly thereafter, noting the problem of servers potentially going to the old address forever, which they assumed would not be there to answer the call. One of the stated reasons for the change was that ICANN did not officially control the old IP address. That distinction belongs to Bill Manning of ep.net, who registered the associated IP block back in 1997. The new IP space was registered directly to ICANN in 2006. Who knows why ICANN was using Bill Manning’s space in the first place and what exactly motivated such a switch, but it’s safe to say that the Internet was a very different place in 1997.

After the announced change, some interesting things started happening. The old address space (198.32.64.0/24) continued to be announced from ICANN (AS 20144), as they didn’t shut down their old server until May 2^nd of this year, as planned. But then, Community DNS (AS 42909) of England started announcing the old space, as well, on December 15^th. Bill Manning’s ep.net (AS 4555) did the same on March 18^th, and, for good measure, so did Diyixian.com (AS 9584) of Hong Kong on April 1^st. So if you inadvertently went looking for the old L root name server during this time, you might have ended up at any one of four very different places! And most of the planet would have done just that. That wouldn’t matter too much, if these sites weren’t themselves running a root name server, but until last week, they were indeed. The following graph shows, over the past six months, the percentage of Renesys peers selecting each of these four competing choices for old L root name servers.

Once we discovered this, we did a very cursory examination of one of the bogus servers and it appeared to be providing the same information as the correct L root server. We checked out the start of authority (SOA) record and some recently updated top-level domains as suggested by our friends at DynDNS. Everything checked out for our limited tests. So at least the bogus name servers might have been providing the correct responses while they were in service, which may be why no one noticed a problem.

Conclusions

But this sure does leave a lot of unanswered questions. Why on earth would anyone want to run a root name server, especially an unauthorized one from a deprecated IP address? The volume of incoming traffic these things get is staggering, and that traffic isn’t free. Why did ICANN make this change in the first place? And what actions were taken to bring all this to an abrupt halt after going on for so long? It’s not like Bill Manning did anything wrong by announcing address space that he owns. He could have even allowed the others to announce it as well. It’s his space after all and he is free to do what he wants with it. And nothing prevents him or anyone else from running a name server from any IP address under their control. But of course, none of these people are stupid. There must have been some reason to mimic a legitimate root name server on an IP address that they knew would continue to be used for a long time. So, what mechanisms are in place today to stop this from happening again?

We already know the answer to this last question: none. Anyone anywhere can announce the address space occupied by any of the root name servers, past or present. If their upstream providers are not filtering announcements, and many of them are not, then some portion of the Internet will select these bad routes, thus directing their root name server queries to the wrong place. This would be similar to the recent YouTube hijack with one very important difference: no one might notice. So the operators of such bogus name servers could operate for a very long time, providing correct answers or incorrect ones as they saw fit. They could log your requests to determine your interests and censor the ones they didn’t like. In general, they could engage in all sorts of mischief, ranging from very targeted (“let’s get this one individual or organization”) to very wide-ranging (“let’s blow away .com today”).

The short-term solution is for providers to both filter routing announcements and implement active monitoring on resources critical to their customers. We discussed these ideas in the wake of the YouTube hijack. In the longer term, the Internet really needs a verifiable way of providing name service, one that makes some guarantee that the answers we are getting are coming from the authorized servers. Cryptographic solutions to this problem have been proposed, just as they have been for BGP route distribution and filtering, but the sheer scale of the global upgrade problem makes it unlikely that we’ll see them deployed in our lifetimes. For now, all we can suggest is to “watch that basket.”

21 Comments