Identity Theft Hits the Root Name Servers 商売で routeviews みたいに経路情報の蓄積・解析とかをしてる Renesys による記事。 Identity Theft Hits the Root Name Servers http://www.renesys.com/blog/2008/05/identity_theft_hits_the_root_n_1.shtml l.root-servers.net の I...
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.
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., 188.8.131.52), 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 184.108.40.206. On 24 October 2007, ICANN announced it was changing to the address to 220.127.116.11, 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 (18.104.22.168/24) continued to be announced from ICANN (AS 20144), as they didn’t shut down their old server until May 2nd of this year, as planned. But then, Community DNS (AS 42909) of England started announcing the old space, as well, on December 15th. Bill Manning’s ep.net (AS 4555) did the same on March 18th, and, for good measure, so did Diyixian.com (AS 9584) of Hong Kong on April 1st. 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.
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.”
Whilst I absolutely agree that security at the BGP level needs to be improved, filtering wouldn't apply where the IP block administrator (in this case EP.net) announces its prefix. Therefore, the issue here is why was ICANN using a prefix which wasn't under its control in the first place, not the system by which routes are propagated. Filtering is only as good as the data it's based on.
Interesting... I too had not noticed the change of IP on the L server. But when I did an rndc dumpdb, I found that my cache already had the correct new IP. This despite my root hint file having the old. Does bind automatically update it? It would appear so. But I've updated my hints file anyway. :-)
Bill Manning got it right here. He is also very trustworthy. He used to work for the IANA when it still had good techs. there. The article got it in part wrong, not all DNS lookups go to root servers, and in fact should not if routing and caching is done correctly. Editor's note: The article never stated all DNS lookups go to root servers. Obviously all clients and secondary servers cache.
Mark, Again, DNSSEC validates zone data, not the DNS servers. The issue here is that a root server address was changed with the intent that root service would stop at the old address, but a third party stepped in and continued to provide service. If the root were signed and everybody who seem to be unable to update their root hints had correctly configured their root trust anchor (a bit of a stretch), then the fact that some unknown third party was providing root service at an address formerly used by a root server wouldn't have mattered as much. But that's a different problem.
This problem has been recognized for some time. I have a few colleagues at the Internet Governance Project who have devised a proposal for improving the root zone file security. If you are interested you can get a copy of the paper here.
Re: MacOS X, I've filed a bug report with Apple to get them to update the hints file. I'm sure I'm not the first.
The busy root servers typically handle O(10,000) UDP DNS queries per second steady state (obviously, during a DDoS, this goes up and the root servers are provisioned to try to handle that sort of thing). As far as I am aware, all of the root servers are now clusters of machines, either behind load balancers or via anycast (or both). DNSSEC does not impose that much overhead on authoritative servers for small(ish) zones. It increases the amount of RAM, bandwidth, and disk required, but this isn't that big a deal. Also, DNSSEC is intended to validate zone _data_, not the DNS servers themselves. If the root zone were signed, it wouldn't matter where you get the root zone data from -- you could verify it hasn't been tampered with.
I've heard the oft-repeated story that DNS root servers need to be mighty beefy to handle the load, and are typically as big a server as is reasonable to procure COTS. Assuming this is true, and not just folklore, DNSSEC would incur too much overhead to be usable for all root server queries. However, one could imagine a RFC specifying a way to validate a root server on some small frequency (one query per week, perhaps) with DNSSEC, and then cache the trust. Some result of 'no longer trust this IP address' that's cryptographically verified could be built into an automated root validation system.
mac osx still has not updated as of now, 1825H EDT, its /var/named/named.ca file with the new named.root file from ftp://ftp.internic.net/domain/named.root . however other software development groups just get a new one automatically. well, macoscx does not enable this by default and who knows what one's doing it is easy to fix with someting like curl -o named.root ftp://ftp.internic.net/domain/named.root
Bill's view of the world is somewhat unique. Suffice to say there are some differences of opinion here and there is more to the story than may meet the eye.
@Sena Rebeiro: If I type "foo" into the URL bar (not the search bar), my browser will first do a DNS lookup on "foo" before it will a do a web search for "foo". This behavior is what I was referring to. This is how many people use their browser. While it is true that the root servers only provide data for TLDs, the querylogs can still provide valuable information.
to answer the question, why? to look at the offered load on "de-commissioned" server addresses. There was agreement between the operators of "B", "J", "L", and "M" to collect data on the old addresses for DITL-2008. An overview of the problem space here: http://www.caida.org/workshops/wide/0611/
Actually, the root servers don't get a whole lot of traffic. When I look up, e.g., "www.google.com.", even if I don't have it in cache, I probably "com." in cache, so I don't need to go to the root. IIRC, the TTLs for the TLDs are generally set at something like a week, so they won't be hit that often. For this very reason, it wouldn't be very useful to log queries to the root servers, because you'd be getting such a sparse sampling. (Plus, there are a significant number of clients out there that are so dumb they only ever look at the A server.) Editor's note: http://www.caida.org/research/dns/roottraffic/comparison06_07.xml
Why was ICANN using the EP.NET address space? It was assigned to "L" when I createdd it in 1996. ICANN should have renumbered when they took over "L". They did -not- and have been squatters on the space. They now threaten legal action if I announce my own space. This is a sad state of affairs.
@Bob: query logs on a nameserver most certainly do not provide data on search terms. Search terms and other parts of the URL path are only provided to the Web server, not to the DNS servers (only the host part of the URL is). But even just data on domain names requested by thousands of people could have a lot of value, I imagine.
"Why on earth would anyone want to run a root name server?" Very simple. The query logs of a root name server provide data on search terms (direct type-in the URL bar) and domain typos which can be monetized and potentially may be worth a lot of money.
Identity theft? Problems? Sure this isn't just anycasting? en.wikipedia.org/wiki/DNS_root_zone Editor's note: Very sure. The relevant prefix would have been announced from the same ASN, and not ones that were outside of ICANN control.
"Who knows why ICANN was using Bill Manning's space in the first place". Because he is a thoroughly good and trustworthy chap, who has worked for over a decade to make the Internet (and its DNS) a better place. If he wasn't ICANN would have used some other person or groups address space.