DNS forgery

In theory, cryptography can eliminate all of the DNS attacks described on this web page. In practice, DNSSEC has received millions of dollars in U.S. government grants and after fifteen years still has not stopped any attacks. My efforts in this area are now focused on DNSCurve, a completely different way to use cryptography to protect DNS.

November 2002 comments

If you're running a DNS server, an attacker with access to your network can easily forge responses from that DNS server to other people. He can steal your incoming mail, for example, and replace your web pages.

An attacker from anywhere on the Internet, without access to the client network and without access to the server network, can also forge responses, although not so easily. In particular, he has to guess the query time, the DNS ID (16 bits), and the DNS query port (15-16 bits). The dnscache program uses a cryptographic generator for the ID and query port to make them extremely difficult to predict. However,

• an attacker who makes a few billion random guesses is likely to succeed at least once;
• tens of millions of guesses are adequate with a colliding attack;
• against BIND, a hundred thousand guesses are adequate, because BIND keeps using the same port for every query; and
• against old versions of BIND, a thousand guesses are adequate with a colliding attack.

Larger cookies in the DNS protocol could make blind attacks practically impossible. (Caches could achieve a similar effect without protocol changes by repeating queries a bunch of times with different ports and IDs, at the expense of speed and reliability.) However, attackers with access to the network would still be able to forge DNS responses.

February 2009 comments

Many DNS software authors issued "emergency" UDP-port-randomization patches in July 2008. Some of these patches, and some subsequent patches, also attempted to stop colliding attacks, by combining "duplicate-query suppression" with various other mechanisms. Kevin Day issued a patch of this type for dnscache in February 2009.

Day also issued a security alert ("CVE-2008-4392") stating that dnscache, without duplicate-query suppression, allowed a colliding attack using tens of millions of packets. Day failed to mention that exactly the same information has been available on this web page since November 2002. As far as I know, my July 2001 posting on the topic was the first publication of colliding attacks on DNS.

I haven't reviewed the patches that attempt to stop colliding attacks against dnscache, BIND, etc. Even if these patches work properly, they are at best a speed bump for blind attackers. Saying "An attacker has to send billions of packets on average" is like saying "An attacker has to download a movie"; yes, it takes a little time, but it's not a serious obstacle.

There is a much simpler way that clients can stop blind attackers without requiring any changes from servers: namely, query repetition, another mechanism that has been discussed on this web page since November 2002. Unfortunately, even with query repetition, attackers who control nearby computers can trivially forge DNS responses.

Attackers are estimated to control more than 10% of the computers on the Internet. If a computer on your network has been compromised by an attacker anywhere in the world then the attacker can trivially steal your mail by forging DNS packets. Client-side patches can stop blind attacks, but attacks from nearby computers are not blind. These patches are an extremely poor substitute for proper cryptographic protection.