back to article Caching bugs exposed in second biggest DNS server

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 …

COMMENTS

This topic is closed for new posts.
Dead Vulture

Lazy Reporter

If Dan would have bothered to read:

http://cr.yp.to/djbdns/guarantee.html

He would notice that forgery issues to *NOT* qualify for the security bounty. FAIL!

0
0

Stupid question

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)?

0
0
Silver badge

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

0
0
Silver badge

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.

0
0

Bounty

If the bounty is a measly grand I'm thinking Bernstein didn't have that much confidence in his software in the first place.

0
0

like motorbikes

It's faster but not as safe - but it probably won't be you gets pranged.

Sam

0
0
Anonymous Coward

@alain williams

"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:-

using tcp:

real 0m0.076s

user 0m0.007s

sys 0m0.003s

using udp:-

real 0m0.044s

user 0m0.002s

sys 0m0.008s

There are a number of advantages to using TCP, I don't think the speed issue is a sufficient disadvantage now.

0
0
Boffin

using tcp

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)

0
0
Silver badge
Boffin

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.

0
0
Flame

@Wyrmhole

What?!

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.

0
0
Stop

djb's comments

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)

0
0

BCP 38

Seriously. It would be much cheaper to simply hire Roland the HTG to enforce this.

0
0

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

0
0

@Dustin Marquess

Here's another piece of software that is doing that ;)

http://www.dovecot.org/security.html

0
0
This topic is closed for new posts.

Forums