There has been a long history of attacks on the Domain Name System ranging from brute-force denial-of-service attacks to targeted attacks requiring specialized software. In July 2008 a new DNS cache-poisoning attack was unveiled that is considered especially dangerous because it does not require substantial bandwidth or processor resources nor does it require sophisticated techniques.

With cache poisoning an attacker attempts to insert a fake address record for an Internet domain into the DNS. If the server accepts the fake record, the cache is poisoned and subsequent requests for the address of the domain are answered with the address of a server controlled by the attacker. For as long as the fake entry is cached by the server (entries usually have a time to live -- or TTL -- of a couple of hours) subscriber's browsers or e-mail servers will automatically go to the address provided by the compromised DNS server.

This kind of attack is often categorized as a "pharming" attack and it creates several problems. First, users think they are at a familiar site, but they aren't. Unlike with a "phishing" attack where an alert user can spot a suspicious URL, in this case the URL is legitimate. Remember, the browser resolves the address of the domain automatically so there is no intervention of any kind on the part of the users and, since nothing unusual has happened, they have no reason to be suspicious.

Another problem is that hundreds or even thousands of users can be redirected if an attacker successfully inserts a single fake entry into a caching server. The scale of the problem is amplified by the popularity of the domain being requested. Under these circumstances, even a moderately experienced hacker can cause a lot of trouble, obtaining passwords and other valuable or sensitive information.

It is possible to attack e-mail systems in a similar way. Rather than inserting a fake record for a Web server into a DNS caching server, the attacker inserts a fake record for a mail server, thereby redirecting corporate e-mail to a server they control.

So what does an attacker need to do to persuade a caching server to accept a fake entry? When a DNS caching server gets a query from a subscriber for a domain, it looks to see if it has an entry cached. If it does not it asks authoritative DNS servers (run by domain registries or domain owners themselves) and waits for their responses.

Prior to this latest vulnerability, attackers could only exploit this narrow opening: They had to beat legitimate authoritative DNS servers by sending a fake query response, hoping they arrive at the caching server first with the correct query parameter values. These races typically only lasted a fraction of a second, making it difficult for an attacker to succeed.

But the dynamics of the race have been dramatically altered in favor of the attacker with this new vulnerability because a security researcher figured out a way to eliminate the narrow time window. This is accomplished by rapidly firing questions at the caching server that an attacker knows the server will not be able to answer. For instance, an attacker can ask where 1q2w3e.google.com is, knowing a caching server is unlikely to have such an entry. That provokes subsequent questions from the caching server and creates millions of opportunities to send fake answers.