1.1. 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,

    * 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. 

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.

1.2. 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. 

「すぐ近くに敵が潜んでいて、覗き見しているなら、暗号を使うのがベストだ」という結論だ。-- ToshinoriMaeno 2011-06-29 00:30:40