beehivelogo codonslogo

A Survey of DNS Security: Most Vulnerable and Valuable Assets

It is well-known that nameservers in the Domain Name System are vulnerable to a wide range of attacks. We recently performed a large scale survey to answer some basic questions about the legacy DNS:

We present the results from this survey below in the hope of identifying problem spots in the Internet and thus improving the security of our common cyberinfrastructure. This study is based entirely on public data - all information available on these pages is also available to others with less-than-honorable intentions.

Survey Methodology

We collected 593160 unique webserver names from the Yahoo! and DMOZ.org web directories. Since the names were extracted from web directories instead of being generated automatically, they have been filtered through a preliminary level of human scrutiny. Though it is clear that the level of scrutiny is not extremely high (i.e. there are some spam hostnames in the survey), we believe that these names are representative of the sites people actually care about.

We then queried the legacy DNS for these names and recorded the chain of nameservers that are involved in their resolution. We thus obtained a snapshot of the dependencies in the DNS system. A total of 166771 nameservers were discovered in this process. The survey was performed on July 22, 2004.

The name delegation data enabled us to answer some basic questions about DNS security.

Most Vulnerable Assets

First, we examine the vulnerable assets in DNS. The vulnerability of a DNS name, say www.cnn.com, is tied to the number of servers whose compromise could potentially misdirect clients seeking to contact that server. These servers form the trusted computing base for that name during name resolution.

The architecture of the legacy DNS greatly helps the attackers. It creates many non-obvious dependencies between names and nameservers, and can enable unexpected nodes to exert great control over remote domains. For example, the resolution of the host www.whitehouse.gov is directly dependent on all the servers that serve the whitehouse.gov domain. There are just seven of these, one of which is a.gov.zoneedit.com. But how does a client figure out the IP address of a.gov.zoneedit.com? For that, it will have to find out the name servers for .com, one of which is a.gtld-servers.net. To figure out the IP address of a.gtld-servers.net, it needs to contact a2.nstld.com. And so on, until the search bottoms out at a root server. In all, the name www.whitehouse.gov is dependent on 40 different nameservers. A compromise in any one of these servers can be used to redirect clients under the right circumstances. The root problem here is that legacy DNS requires a transitive trust relationship, from a name to all its nameservers, and from those nameservers' names to all their nameservers, and so on. These dependencies create a dependency graph (technically it should be a directed acyclic graph culminating in the root servers, but cycles can arise in practice - legacy DNS requires manual administration, and humans make mistakes. See Mockapetris 88 and Pappas 04 for the extent of cyclic delegations). We first examined the size of these graphs, to get a handle on the extent of the trust relationships.

Here are the results of our survey:

The linked pages rank web servers by the number of nameservers on which they depend. A higher number corresponds to a larger trusted computing base, and thus to a greater set of dependencies, a bigger attack profile, and greater vulnerability. Surely, it is not the case that all of the nameservers are involved in every name resolution involving that web server; caching, network availability, load-balancing decisions and the preferential order in each delegation set together determine the precise set of contacts for each query. However, under the right set of circumstances, say the severence of the wrong set of cables or a targeted link saturation attack, any one of these nodes can end up being queried and thus control the ultimate mapping for that name.

The numbers shown above exclude the DNS root servers, because they are sometimes treated specially at the network level through BGP anycast to a local root replica. To get a true count in most places in North America, one should add 13 to the numbers shown above. If anycasting is used for root queries in your part of the Internet, you should add the appropriate number for the root replicas in use.

The numbers also exclude any domain whose nameservers were down or timed out at the time we performed our survey. They strictly underestimate the level of dependence between names and nameservers. Here are the highlights from the raw data.

Most Valuable Assets

Next, we examine the valuable assets in DNS. The value of a DNS nameserver is tied to the role it plays in name resolution.

We model the value of a nameserver as being proportional to the number of hostnames whose resolution that nameserver controls. It is these high profile servers whose compromise would put the largest portions of the DNS namespace in jeopardy. Attackers are likely to focus their energies on such high-leverae servers - the effort to break into a vulnerable nameserver is constant, and breaking into a nameserver that controls a large number of names provides a higher payoff ("0wnage points").

Here are the results of our survey:

This list identifies the surveys that appear on the most number of delegation graphs for the web sites in our survey. Here are the highlights from the raw data:

We hope that the operators of names close to the top of this list exert due diligence. We quantify their level of diligence below.

Known Exploits and Their Impact

As part of our survey, we also collected version information for the nameservers we encountered, where possible. Older versions of nameserver software contain well-documented bugs. We can combine this data with the preceding two studies to determine which names and which nameservers are subject to compromise.

At this time, we are releasing only aggregated data. The link below examines which vulnerabilities are most prevalent.

We next examine which names depend on nameservers with known security flaws. Of the 166771 nameservers, 27141 have known vulnerabilities. These vulnerabilities affect 185802 names. A naive expectation might be that, with ~17% vulnerable nameservers, only 17% of the names would be affected. This is patently not the case; transitive trust relationships "poison" every path that passes through an insecure nameserver. Hence 34% of DNS names can be compromised by launching well-known, scripted attacks.

The page below lists web server names whose DNS delegations may be handled by such an insecure nameserver. If a webserver you administer appears in this list and you do not know where the vulnerable web server is, we can identify the offending servers when you contact us with your credentials.

Interestingly, www.fbi.gov is vulnerable to being hijacked, along with every other name in the fbi.gov domain.

The fbi.gov domain is served by two machines called dns.sprintip.com and dns2.sprintip.com. A client trying to resolve www.fbi.gov will first have to get to sprintip.com to find the FBI nameservers. The sprintip.com domain is in turn served by three machines named reston-ns[123].telemail.net. Of these machines, reston-ns2.telemail.net is running an old nameserver (BIND8.2.2-p5), with nine different known exploits against it (namely, tsig, libbind, negcache, sigrec, DoS_multi, srv, zxfr, infoleak and sigdiv0 exploits). Having compromised reston-ns2 using a standard crack tool available on the web, an attacker can divert a query for dns.sprintip.com to a malicious nameserver, which can then divert the subsequent query for www.fbi.gov to any other address, hijacking the FBI's web site and services.

Discussion

DNS is a complex system where a vulnerability in an obscure nameserver can have far-reaching consequences. It is far too easy for a host to be dependent on a remote nameserver. Even if the name owners are diligent and check the extent of dependencies at name creation, it's quite possible for the trust relationship to change under the covers. Thus DNS fits very well Leslie Lamport's definition of a distributed system, "a distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable."

The main culprit here is the reliance on transitive trust. Security-minded readers will quickly realize that the legacy DNS defines a "speaks-for" graph. A set of nameservers speak for the IP addresses of the names they manage. A different set of nameservers speak for the IP addresses of those nameservers in turn. The graph thus extends until the root servers are reached on all paths or cycles are encountered. All nodes in this name delegation graph can play a role in resolving the desired name - the graph defines the trusted computing base. It is a well-accepted axiom of computer security that a small trusted computing base is highly desirable: it is easier to secure, audit and manage.

Our survey has found that name delegation graphs in DNS commonly grow to be enormous and can include more than 600 nodes. An average name depends on 46 nameservers, while the average in some top-level domains exceeds 300. Since a significant percentage of nameservers contain known security flaws, it is often possible to locate a vulnerable node in the physical delegation graph.

Our study shows that one in three Internet names can be hijacked using publicly-known exploits. This points to a significant common vulnerability: legacy DNS. It is highly unlikely that an attacker can break into a third of the webservers around the globe. Firewalls, hardened kernels, and intrusion detection tools deter direct attacks on web servers. But the legacy DNS enables attackers to hijack one in three sites, thus gaining the ability to masquerade as the original site, obtain access to their clients, potentially collect passwords, and possibly spread misinformation. High-profile domains, including those belonging to the FBI, NSA and US Treasury, are vulnerable because of problems stemming from the way legacy DNS performs delegations.

A better approach is required to achieve name security on the Internet. Deployment of DNSSEC helps, but DNSSEC continues to rely on the same physical delegation chains as legacy DNS during lookups (not for establishing authority, but for service). We believe that the legacy DNS should be complemented with a system that serves cryptographically delegated name-to-address bindings that obviate the entire static nameserver hierarchy.

FAQ
Related Work
CoDoNS Main Page

Computer Science Department
Cornell University