Sung to the old traditional sailor's tune:
Way hay, an' up she rises; way hay an' up she rises;
Way hay, an' up she rises; ear-lye in the morning.
What could you do with your own root server? What could you do with your own root server?
What could you do with your own root server? Ear-lye in the morning?
Since I can't sing a note I'd better stop now.
But the question lingers: What could you do with your own root server? And I mean by this, suppose you had one of the [A-M].root-servers.org addresses?
What could you do? - Probably a lot more than you think.
You could make a lot of people angry; you could make a smaller number people very angry; and you could really hose a number of selected targets.
Please read this note with a bit of humor - it is not intended to be a deep study, perfect in all details. Rather, it is merely the result of a bit of conjecture (while enduring a flu and fever) about what might be possible. So if some of this has the nature of coming from an overheated brain, let me assure you, it really is.
This note is entirely hypothetical. But it is neither completely fanciful nor impossible. Some of the thoughts below are conjectural - but that is not to say that they aren't real. Many, but not all, of these thoughts would, if implemented, be very obvious to the cognoscenti. Some of these thoughts might simply be impractical. But I am certain that many are feasible given adequate ill-will and incentive, particularly if the ill-doer isn't looking for total coverage but is willing to do only partial data mining or cause partial, or short-lived, disruption.
I have not even begun to think of how this list is affected, or prevented, by full or partial deployment of DNSSEC. Remember, I am not writing about the harm that could be caused by some random machine that claims to be a root server. Rather, I'm writing about what could come about through the purposeful manipulation of a machine (or cluster of anycast machines) that is part and parcel of the legacy system of DSN root servers. In fact, because the concerns I raise here come from "the inside", they may be aggravated rather than diminished by the presence of DNSSEC.
The domain name system is organized much like a feudal hierarchy - root servers are the kings; TLD servers are the Dukes; third level servers, the ones that you and I run, or have run on our behalf, are the knights at the bottom. At each layer of DNS, as in feudal systems, the superior node has authority over its inferior nodes. In particular, any node of DNS has the ability to withdraw or modify the delegations of authority to its inferiors, and by virtue of the way DNS works, the superior node is also in a position to partially supersede the work of the its inferiors or even replace them. From this arcane beginning comes enormous power, for good or ill, in the domain name system.
Today we are protected against malevolent DNS not by institutions but by people. Today all that protects us is the good will of the people who have their hands on the buttons of the top (root) and intermediary (TLD) DNS servers. Those groups who, through historical chance, run one of the 13 root servers, are, for the time being, honorable and public-minded.
But times change, people change. And sometimes people, or organizations are coerced to depart from past behavior. One of the great failures of internet governance under the hand of the US Department of Commerce and it's unacknowledged offspring, ICANN, is that the root servers are answerable only to themselves.
A root server could be a very useful tool for information warfare were it to be operated by an institution that has a greater obligation to protect its country than to protect the internet. Three such institutions are worth noting: the United States Department of Defense (g.root-servers.net), the United States National Aeronautics and Space Administration (e.root-servers.net), or the United States Army Research Lab (h.root-servers.net). The United States has recently indicated that it considers the internet to be a weapon, so it would be surprising indeed if the US did not have a rather more complete study of the issues I raise here.
Moreover we have seen, particularly in the United States, that governments are not beyond secret collaboration and secret coercion of private actors. Since the recent revelations about AT&T's and the US Government with regard to the latter's domestic and warrant-less surveillance efforts, one must wonder whether ICANN (l.root-servers.net) is any more immune from USG pressures than AT&T?
No nation is invulnerable to the effects of a rogue root, or large TLD (e.g. .com), server.
Just as nations outside the US are rightfully concerned about the dangers of US hegemony over DNS, the US itself might consider how its own national security might be affected by ill or malicious behavior of root servers outside of its national borders.
Getting down to brass tacks - what exactly could one do if one happened to have a root server? (And remember, anything that a root server can do to the internet in total, a TLD server can do to its own sub-hierarchy.)
Before answering that I'd like to mention some aspects of root servers:
First is that each root servers only see a small portion of all DNS queries. Root queries are spread among 13 servers (or more accurately, 13 groups of servers) - thus there is about a 7.7% chance that any given query will land on any given root server. In addition the DNS contains a lot of intermediate caching of previous results. In my own measurements a continuously-running intermediate resolver typically makes only a few hundred root queries per month. However, when a root server does see a query it usually sees the entire domain name that is being resolved.
It is this fact of the entire requested name that is important. The fact that queries are spread among different root servers and that many queries are handled by caches in intermediate resolvers only means that any data mining, manipulation, or attack must rely on probabilities and statistics. However, as will be mentioned later on, by "going recursive" and manipulating the TTL fields of responses, a root server can arrange for a greater portion of a target's queries to hit the roots. In addition, by becoming even more devious, a root server could, with the help of some cooperative name servers, capture an entire sub-tree of the DNS, for example, example.com, and usurp virtually all of the queries for a given sub-tree of the DNS. This latter aspect, while not very subtle and highly visible, does make root servers fairly powerful weapons of internet warfare.
Second is that during the startup phase of an intermediate DNS resolver there is an opportunity to misdirect that intermediate resolver to use a different suite of root servers. When an intermediate resolver uses its "hints" to discover a suite of root servers it will usually accept the answer from the first "hint" server that is willing to provide a purportedly authoritative list of purported root servers. This means that if you own a root server and you catch an intermediate resolver looking for the root (something not all that hard to recognize), with a little cooperation from other machines you control, you can mislead a victim resolver into believing that a bogus list of machines that you provide is a full and complete set of honest root servers.
Third is that DNS works in this way: In the absence of cached information, a user computer, or a resolver acting on its behalf, sends a query containing the full target domain name to a root server. Root servers are usually configured to answer only the TLD delegation portion of the query. In other words, root servers are usually configured to answer only that part of the query that pertains to items in the root zone itself. The phrase for this in DNS terminology is that the root servers are configured to be "non-recursive". Thus the root servers leave the job of walking through the hierarchy of DNS servers to the user's computer or a resolver acting on behalf of the user's computer. This is the usual mode of operation, but it is not mandatory - root servers could be configured to work through a full or partial sequence of pieces ("labels") of a DNS query. Most user computers or resolvers acting on their behalf would be happy to have the root servers give fully recursed answers. However, because of Verisign's Sitefinder, some DNS software has been modified to be suspicious of root or TLD servers that give out what seems to be too much information beyond that which was actually asked for.
We should not underestimate the degree of control that this kind of DNS manipulation makes possible. Through the mechanism of giving fully or partially recursed replies a root server could mislead user computers. In fact, with some careful staging of DNS responses in coordination with some cooperative servers and proxies, actual data traffic - web, VOIP, file transfers, etc. - could be redirected through proxies that examine, and perhaps even modify, the traffic.
So given these restrictions, which amount to a small peephole through which one can view and affect DNS queries and a somewhat thin reed of control, what kinds of things are possible?
Traffic Analysis/Data Mining
Want to know what's hot and what's not on the internet? Simply look at the number of DNS queries - hot websites (or hot VOIP phones) will be the subject of more queries than the those that are passé.
Root servers (and of course, TLD servers) are in a marvelous position to watch DNS queries and do relatively simple statistical data reduction to know, in a very short period of time, who is interested in what. The hardest part of the task would be to come up with a quantitative expression to compensate for the effects of DNS caching.
In the cyber-warfare context, I'm sure that the worthies over at national spook agencies would find it revealing to know what domain names "the enemy" is uttering.
Is there any wonder why Verisign is so hot to have a data mining provision in in the proposed ICANN-Versign agreement over .com? Imagine how much more interesting information one could obtain if he/she happened to have the ability to data-mine queries seen by a DNS root server? (By-the-way, Verisign runs two root servers [a.root-servers.net and j.root-servers.net]. I wonder whether the originator of SiteFinder might be predisposed to do some commercially lucrative data mining at the root level?)
Most people will immediately say - but the root servers don't seem very many queries. That's true. That's what statistics is all about, drawing broad conclusions from samples. But there's more - a server, be it a root or TLD server, can drive more traffic to itself by giving out small time-to-live (TTL) values. This will cause the caches in intermediary and end-user resolvers to time out more frequently and thus, more often, visit one of the root servers.
There's been a lot of talk recently about how telco providers want to impose differential grades of internet service. Rather than saying that they will make X go slow, they usually say that they will make Y go faster. But no matter the spin, it's still differential service.
DNS roots could easily give differential grades of service. Say, for example, that a root server operator is compelled by a government to give slow replies to queries coming from an disfavored region, or even to shut off service altogether during a period. As has been discussed in the IETF, any slowness in DNS is amplified many-fold by the time it reaches users and the applications they use: even small increases in DNS response time can accumulate, making the web web and other internet services sluggish.
I wonder whether the US considered this option during the cyber-warfare exercises it concluded this week?
Beyond differential service, a root server could give differential answers in an attempt to sew discord - it could send correct answers to friendlies and wrong answers to unfriendlies. These answers could occur as a result of the root server "going recursive" and handing back a completely wrong answer, or the answer could be more subtly altered, such as giving partially or fully incorrect delegation information, or exceedingly short TTLS (and thus inducing query thrashing) or exceeding long TTLs (and thus making it difficult for the domain name owner to propagate changes in its DNS records.)
(A very nasty thing to do would be for A or AAAA records in answers to contain loopback, broadcast, or multicast addresses. I used to do this to spammers via my least-preferred MX record.)
Or it could be even more subtle - a root server might cause DNS replies to be fragmented, or might set strange IP options, or might set the DNS "Truncation" bit, thus pushing intermediary resolvers to engage in far less efficient (TCP based) modes for making DNS queries. And if resolvers are pushed to use TCP rather than UDP for DNS queries, the root server might be slow about its TCP handshakes and slow to tear-down connections. Yes this would burn up protocol resources on the root, but it would also burn up resources on the victim resolver, which is likely to be unprepared to cope.
As I mentioned above, if a malevolent root server can catch an intermediate resolver during its boot-up sequence when it is roaming through its "hints" file trying to learn the servers that form a root, then that malevolent root could mislead that resolver into accepting an entirely divergent set of root servers. Suppose, for example, that we wanted to mislead much of the countries of Olliestan and Fredonia. The malevolent root server could then watch for queries of a form that suggest that a resolver is searching its hints and, in response, feed back a suite of records that define an entirely distinct set of root servers. As I've said before, this would be fairly obvious to those who are looking deeply into DNS, but if the faux-root provided reasonable answers for most things then many users would never notice. Suppose, for example, that the idea was to attack the VOIP/ENUM system of the target countries - the A records used by web and email might be left alone, but interference with the delegations for the enum tree, or "going recursive" and giving misleading answers for NAPTR and SRV records, could wreak havoc on voice calls.
A more subtle approach is to give wrong answers to specific queries. Foe example, if I knew that a particular query was the result of of a SIP INVITE leading to a VOIP phone call, the malevolent root could go recursive and give back an A record pointing to a proxy for the purpose of monitoring the phone call. Again, this could be difficult to arrange - it's hard to know the purpose of any particular DNS query for an A or AAAA record - but if some ancillary information were available to help distinguish the gold from the dross than a government might find this a useful surveillance technique.
Much of what I've just written may be hooey - but if I'm only half right, or even a quarter right, or even 10% right, then there is reason to be concerned that root (and TLD) servers be operated without manipulation.
And any country ought to be wondering whether root servers operated by governments of other countries are being manipulated in the interests of "national security".
Would any government unquestioningly accept the disclaimer of another government that the latter is not meddling with DNS root servers within it borders?
It seems to me that there is little that can be done to dispel suspicions of such activity, especially given the increasing dissonance between what governments (especially my own national government) say and what they do. Such concerns could easily drive the creation of national systems of roots - at least that would give each country some immunity, but certainly not total immunity, from threats arising from manipulation of foreign root servers.Posted by karl at February 13, 2006 8:05 PM