Replies

Grrrr.

This is NOT a DNS flaw.

This is a flaw in BIND, a particular piece of software that does DNS.

While the majority of DNS servers use BIND, it is not the only one.

I stopped using BIND many years ago due to it's poor track record of security and compliance with RFCs.

I switched to DJBDNS and have had zero problems with DNS since then.

This is NOT a DNS flaw.

BIND is not the only flavor of DNS that is affected. Microsoft DNS was also vulnerable, as are others. Kaminsky does not say that it is a problem solely with BIND, but with various implementations of the DNS protocol.

Here's an interview with Dan Kaminsky at Black Hat 2008 where he explains it pretty well.

> Grrrr. This is NOT a DNS flaw. This is a flaw in BIND, a particular piece of software that does DNS...

I know, and agree...

But hey... when a software programmer doesn't do bounds-checking on a stack-allocated buffer, they don't describe the flaw as a "failure to check bounds", they call it a "buffer overflow", even though it wasn't the buffer's fault.

I should have been more specific.

This is a DNS protocol flaw and spans BIND 8/9, MSDNS, Nominum. It doesn't affect DJBDNS, PowerDNS, and MaraDNS.

Now if someone things the following: “Our DNS servers don’t accept queries from the outside world. They must be safe!”
-Can someone ask them to do an nslookup www.doxpara.com, will they return 157.22.245.20?
-If so, don’t be so sure

I security track record remark I found interesting as it brought back a recent “Banging spoon on highchair” incident of Linus’. Did you catch that a few weeks ago where he called *BSD devs “m*asterbating monkeys”? Some much the educated high-brow discussion of “when’s a security flaw a bug/code flaw” and “aren't all code flaws security holes?”, vice-versa, ad nausea

Don't want to get start a whole DBJDNS v. BIND thing, but I'm with you on your ISC comment. You see ISC+not-for-profit mentioned in the same breath far too often. Configuring BIND is *not* for the faint of heart. Boy, can I attest to that.