D. J. Bernstein
Internet publication
djbdns

DNS forgery

I've given a few talks on ``The DNS security mess'': 2003.02.11 (slides available). 2003.03.18 (slides available). 2004.04.28 (slides available).

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

An attacker with access to your network can easily forge responses to your computer's DNS requests. He can steal your outgoing mail, for example, and intercept your ``secure'' web transactions.

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,

As of November 2002, CERT is panicking because they didn't realize how trivial this was, even though I spelled it out in a posting in July 2001.

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

I introduced UDP port randomization in the first dnscache release in December 1999. PowerDNS copied the same feature in 2006. As far as I know, between December 1999 and July 2008, all other DNS software on the Internet allowed blind attacks that were likely to succeed using fewer than 100000 packets.

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.