|
The following provides an introduction to a study by Venugopalan Ramasubramanian and Emin Gun Sirer, called “Perils of Transitive Trust in the Domain Name System” [PDF]. The paper presents results from a large scale survey of DNS, illustrating how complex and subtle dependencies between names and nameservers lead to a highly insecure naming system. (Note: This post was updated on May 26, 2006)
It is well-known that nameservers in the Domain Name System are vulnerable to a wide range of attacks. However, cross-dependencies between nameservers can significantly amplify the damage caused by attacks.
We recently performed a large scale survey to answer some basic questions about the security threats in 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. 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.
Survey Results
Our survey exposes several new and surprising vulnerabilities in DNS caused by inter-domain dependencies. For example, the domain fbi.gov indirectly depends on a server belonging to telemail.net, which is vulnerable to four well-known exploits. A malicious agent can easily compromise that server, use it to hijack additional domains, and ultimately take control of FBI’s namespace.
The survey finds that the resolution of a domain name depends on a large number of servers (46 on average and more than 100 for 20% of the names), not including the root servers. About thirty percent of domain names can be hijacked by compromising just two servers each, where both servers contain publicly-known security loopholes. Finally, about 125 servers control a disproportionate 10% of the namespace. Surprisingly, 25 of these critical servers are operated by educational institutions, which may not have adequate incentives and resources to enforce integrity.
It may appear that glue information provided along with NS records circumvent these threats. However, for cross-domain delegations the glue information may not be present, and even if present cannot be considered reliable due to cache poisoning attacks. Hence, nameservers may end up chasing the glue and falling prey to transitive trust attacks.
Implications
The main culprit here is the reliance on transitive, name-based delegations, where one domain authorizes a second domain to serve its names, and that to a third domain and so on. Name-based delegation, however, is central to the current architecture of DNS, which entangles management of name space and lookup service for DNS names together.
It is time to rethink of an entirely different naming infrastructure for the Internet, one that will retain the advantages of legacy DNS but rectify its deficiencies. Recent innovations in self-organizing peer-to-peer frameworks provide a promising approach to support DNS lookup service. We have designed a new naming architecture called CoDoNS that provides high performance, reliable, and secure lookup service for DNS names, while retaining the scalable, decentralized namespace of the legacy DNS.
More information about the DNS survey and our new DNS architecture can be found on the website Cooperative Domain Name System.
Sponsored byDNIB.com
Sponsored byCSC
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byRadix
Sponsored byWhoisXML API
Almost a month has gone by, and no comments yet?
I propose possible remedies for the insecurity:
1. Daily nag messages to the maintainers of the vulnerable name servers;
2. Blacklist the insecure name servers after a grace period from CERT notification of a vulnerability;
3. Develop a (secure) auto-update method for the next version of BIND.