For years, cryptographer Daniel J. Bernstein has touted his djbdns as so secure he promised a $1,000 bounty to anyone who can poke holes in the domain name resolution software. Now it could be time to pay up, as researchers said they've uncovered several vulnerabilities in the package that could lead end users to fraudulent …
If Dan would have bothered to read:
He would notice that forgery issues to *NOT* qualify for the security bounty. FAIL!
OK, so here's a stupid question -- if DNS caches can be poisoned so easily, why do we continue to use UDP connections for them? Wouldn't TCP connections, due to their stateful nature, prevent these issues (unless it was a man-in-the-middle attack, where the attacker would know the exact response to send)?
@ Stupid question
''if DNS caches can be poisoned so easily, why do we continue to use UDP connections for them?''
Because UDP is so much faster, the DNS look up is done with one packet out and one packet back. To do that with TCP would require 3 packet setup, question, answer, 3 packet close.
UDP vs. TCP
>> why do we continue to use UDP connections for
I would venture simply because you don't want to suffer the useless TCP connection setup overhead. DNS is just a directory lookup service and apparently suffers from lots of stupid optimization tricks that were relevant when a "DNS server" had to be 30-kg machine in the basement. Still, one wants to avoid the situation where hundreds or thousands of clients per seconds set up and tearing down TCP connections. So the correct way to do is to pack your queries and answers into the 64K offered by connectionless/fire-and-forget UDP. If a query or answer gets lost on the wy, you can simply query again. Perfect. UDP packets may even pass through a congested network where TCP won't even be able to work at all. This is also why SNMP for example uses UDP for short queries and notifications.
If the bounty is a measly grand I'm thinking Bernstein didn't have that much confidence in his software in the first place.
It's faster but not as safe - but it probably won't be you gets pranged.
"Because UDP is so much faster, the DNS look up is done with one packet out and one packet back. To do that with TCP would require 3 packet setup, question, answer, 3 packet close."
That used to be a far more valid argument, when people were on slow networks and slow machines. but I'm not convinced that it still does. A (very) unscientific test gives me (averaged over 20 repetitions of the same query) timings of:-
There are a number of advantages to using TCP, I don't think the speed issue is a sufficient disadvantage now.
Not really scalable when you have DNS servers serving multiple thousand queries of dns servers per second. The speed isn't the issue it's the overhead of setting up and maintaining those thousands of TCP sessions if you are running an auth server that is going to cause you headaches.
Brett (Wondering why Paris hasn't commented on this thread)
Fat TCP is fat!
>> I don't think the speed issue is a sufficient disadvantage now.
Think about what the kernel has to do whenever a TCP connection is opened: managed the initial packet exchange (possibly waiting for a long time in case of SYN w/o ACKs), set up queue buffers, set up the TCP state machines (whatever these are), finally hand the client socket to your application, which then has to proceed to do something special, hopefully not create two specialized threads to work with that socket.
In case you don't need all that stuff and it is sufficient to regard the network as just a work queue with incoming 64K contextless packets, use UDP. The kernel will just have to copy the packet into userspace and you app can handle them as fast as they come in.
Loadbalancers on high-traffic websites. They are there for a reason.
He writes a piece of public domain software, doesn't charge for the software, doesn't offer commercial support directly, etc. He makes *NOTHING* off of the software, yet he's offering $1000 of his own personal money, and that isn't enough for you? How many other FOSS projects do you know of that offer a similar award? Go away, troll.
Copied from http://cr.yp.to/djbdns/forgery.html
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.
(more at link)
Seriously. It would be much cheaper to simply hire Roland the HTG to enforce this.
Second bug not just a forgery issue
"He would notice that forgery issues to *NOT* qualify for the security bounty. FAIL!"
Right, and for this reason, I don't think DJB will award the $1000 to Kevin Day. However, the bug that I pointed out is an actual exploitable bug in how djbdns builds DNS response packets, which I believe is covered by DJB's security guarantee. You can read my BugTraq posting for more details (linked within the article).
Here's another piece of software that is doing that ;)
- HALF A BILLION TERRORISTS: WhatsApp encrypts ALL its worldwide jabber
- HUMAN DNA 'will be FOUND ON MOON' – rocking boffin Brian Cox
- Bang! You're dead. Who gets your email, iTunes and Facebook?
- YOU are the threat: True confessions of real-life sysadmins
- Blackpool hotel 'fines' couple £100 for crap TripAdvisor review