A vulnerability exists in the mechanism used by DNS, in general, to determine the name server associated with TLD's (top level domains). DNS is built upon levels of trust, and by exploiting single points of failure in this trust system, it becomes possible for an attacker to convince a caching nameserver that allows for recursion through it that the root server for a given TLD is something other than what it actually is. By consecutively performing these cache attacks, it could be possible for an attacker to entirely take over name service for any given domain. The vulnerability is actually not specific to TLD's. The same attack can be used to hijack any domain which has out of zone NS records, if any of the servers that act as the name server for the out of zone domain can be compromised. The simplest explanation was presented in the example provided by it's discoverer, Dan Bernstein, on the Bugtraq mailing list, on January 23, 2000: "Suppose an attacker can make recursive queries...
A vulnerability exists in the mechanism used by DNS, in general, to determine the name server associated with TLD's (top level domains). DNS is built upon levels of trust, and by exploiting single points of failure in this trust system, it becomes possible for an attacker to convince a caching nameserver that allows for recursion through it that the root server for a given TLD is something other than what it actually is. By consecutively performing these cache attacks, it could be possible for an attacker to entirely take over name service for any given domain. The vulnerability is actually not specific to TLD's. The same attack can be used to hijack any domain which has out of zone NS records, if any of the servers that act as the name server for the out of zone domain can be compromised. The simplest explanation was presented in the example provided by it's discoverer, Dan Bernstein, on the Bugtraq mailing list, on January 23, 2000: "Suppose an attacker can make recursive queries through your cache. Let me emphasize that this does not mean that the attacker is one of your beloved users; many programs act as DNS query-tunneling tools. Suppose the attacker is also able, somehow, to take over ns2.netsol.com. This isn't one of the .com servers, but it's a name server for the gtld-servers.net domain. Here's what happens: (1) The attacker asks your cache about z.com. Your cache contacts (say) k.root-servers.net, which provides a referral: com NS j.gtld-servers.net (among others) j.gtld-servers.net A 198.41.0.21 These records are cached. (2) The attacker asks your cache about z.gtld-servers.net. Your cache contacts (say) f.root-servers.net, which provides a referral: gtld-servers.net NS ns2.netsol.com (among others) ns2.netsol.com A 207.159.77.19 These records are cached. (3) The attacker takes over ns2.netsol.com. (4) The attacker asks your cache about zz.gtld-servers.net. Your cache contacts ns2.netsol.com, and the attacker answers: zz.gtld-servers.net CNAME j.gtld-servers.net j.gtld-servers.net A 1.2.3.4 These records are cached, wiping out the obsolete j glue. (5) A legitimate user asks your cache about yahoo.com. Your cache contacts j.gtld-servers.net, and the attacker answers: yahoo.com A 1.2.3.4 The user contacts yahoo.com at that address." The attack offered requires that an attacker be able to compromise the operation of the DNS server running on, in this case, ns2.netsol.com, although this is not the only server that could potentially be used to launch an attack of this style. The author further indicates that there are in excess of 200 servers that could be used to manipulate resolution of all the .COM domains.