How OpenDNS, PowerDNS and MaraDNS remained unaffected by the DNS cache poisoning vulnerability
The short answer is being paranoid about tackling a known vulnerability. It's 2001, and Daniel J. Bernstein (DJB),
"I said "cryptographic randomization.'' The output of random() is not cryptographically secure. In fact, it is quite easily predictable. This is a standard exercise in first-semester cryptography courses. Randomizing the port number makes a huge difference in the cost of a forgery for blind attackers---i.e., most attackers on the Internet. It's funny that the BIND company has gone to so much effort to move from the first line to the second, but now pooh-poohs the third line. Do you think that "RSA'' is a magic word that makes security problems disappear? Without a central key distribution system---a system that doesn't exist now and won't exist for the foreseeable future---DNSSEC doesn't stop forgeries."
The skeleton from the closet makes another appearance in January 2005, according to Marcus H. Sachs, Director, SANS Internet Storm Center, in the face of Ian Green's GIAC Security Essentials Certification (GSEC) submitted paper detailing the same vulnerability :
"Three years ago Ian Green, then studying for his GIAC Security Essentials Certification (GSEC), submitted a paper that details the same DNS spoofing vulnerability, the SANS Institute's Internet Storm Centre notes.In order to spoof a DNS request it's necessary to "guess" both the Query ID and the source port. The query ID is 16 bits long, and the UDP source port also has over 60,000 potential option. But as Green noted back in January 2005, DNS transactions are incremented by one for each subsequent query while the UDP source port remains the same during a session."
Apparently, OpenDNS, PowerDNS and MaraDNS were all aware of the possibility for abuse here, and took action long before the recent vulnerability disclosure and coordinated multi-vendor patching initiated by Dan Kaminsky took place. How did they do it, and what's the current state of the coordinated patching campaign across the Internet?
On July 8th, David Ulevitch at OpenDNS posted a statement that OpenDNS isn't vulnerable :
"I’m very proud to announce that we are one of the only DNS vendor / service providers that was not vulnerable when this issue was first discovered by Dan. During Dan’s testing he confirmed (and we later confirmed) that our DNS implementation is not susceptible to the attack that was discovered. In other words, if you used OpenDNS then you were already protected long before this attack was even discovered.
In fact, for those of you who were listening in on the Microsoft press call this morning, you’ll note that OpenDNS was suggested as the easy and simple solution for anyone who can’t upgrade their DNS infrastructure today. Pointing your DNS servers to forward requests to OpenDNS and firewalling all other DNS traffic off at your server will help mitigate this risk." Bert Hubert, author of PowerDNS, alerted me to the fact that PowerDNS was also not vulnerable when this issue was discovered. That’s not surprising considering Bert is one of the authors of the wonderful DNS forgery resilience Internet Draft that has recently been published. :-) I updated the statement in bold appropriately."
On July 9th, Sam Trenholme at MaraDNS pointed out that the service is too, immune to the new cache poisoning attack :
"MaraDNS is immune to the new cache poisoning attack. MaraDNS has always been immune to this attack. Ditto with Deadwood (indeed, people can use MaraDNS or Deadwood on the loopback interface to protect their machines from this attack). OK, basically, this is an old problem DJB wrote about well over seven years ago. The solution is to randomize both the query ID and the source port; MaraDNS/Deadwood do this (and have been doing this since around the time of their first public releases that could resolve DNS queries) using a cryptographically strong random number generator (MaraDNS uses an AES variant; Deadwood uses the 32-bit version of Radio Gatun)."
And while these DNS services and secure DNS implementations like MaraDNS in this case, weren't susceptible to the DNS
"Look at the figure below, which shows the aggregate volume (in Mbits/hour) over time for the DNS anomalies seen between July 7th and 11th. Clearly, before the CERT announcement and release of the patches, there were no anomalies. But after the announcement on July 8th, NSS saw a 1000x increase in aggregate volume of anomalous DNS traffic. NSS defines a traffic event as an anomaly if the amount or behavior of traffic heading to an ip-address exhibits sudden changes. A further analysis of the sources of these queries shows that they were being originated from open DNS proxies on the Internet and from DNS clients from well-reputed institutions from around the world. The reputation of the anomaly sources leads to the conclusion that these anomalies were not really attacks, but a side-effect of the synchronized patching."
The most recent study on the state of patching vulnerable DNS servers, was released today courtesy of Austria's CERT, stating that :
"The conclusions are rather grim so far – more than two thirds of the Austrian Internet's recursive DNS servers are unpatched while at the same time the upgrade adoption rate seems rather slow. Our findings are matched by the observations of Alexander Klink of Cynops GmbH who analyzed the results of the online vulnerability test on Dan Kaminsky's doxpara site."
The big picture? It seems that it's not just At&T's DNS servers which are susceptible to DNS cache poisoning, but many other like the following according to a request for self-auditing initiated by the Register :
"Skybroadband, Carphone Warehouse Broadband, Opal Telecom, T-Mobile, Videotron Telecom, Roadrunner, Orange, Enventis Telecom, Earthlink, Griffin Internet and Jazztel."
With three publicly available exploits for remote DNS cache poisoning released during the last three days "in the wild", it remains yet to be seen whether or not malicious attackers would take advantage of the window of opportunity, or continue using the "cybercrime as usual" attack tactics.