The DNS Bug: Why You Should Care

It's not every day that the New York Times writes articles about the Domain Name System, but then again this DNS bug is anything but normal.

It's been over five weeks now since Dan Kaminsky first announced the major flaw that he found in the DNS protocol. Although most of the details of the bug have been public for a few weeks now, it wasn't until last week at the Black Hat and Defcon conferences in Las Vegas that Kaminsky explained the depth of the issue. As I listened to him describe the ways this bug can be exploited my heart dropped down into my stomach and I felt a little sick. My friend was only half joking when he whispered to me "I'm thinking about transferring to accounting."

Yes, the bug is that bad. Everyone should be paying attention to this one. Fortunately, most of the big sites out there have been patched, for now. But the current patch only buys us some time, it doesn't actually fix the real problem.

In case you are just joining the party, the bug that Dan found can be used by an attacker to poison DNS records. In other words, he can redirect your email, instant messages, website visits, or any other traffic that relies on DNS. Which, of course, means all traffic. Yes, that sounds scary, but it seems that most people don't fully appreciate the degree to which this can be exploited. Dan's presentation made it crystal clear.

What This Means For You

Let's start with a quote from George Kurtz, a VP at McAfee:

If you control the DNS servers, you control the Internet.

This exploit effectively grants control of the DNS servers to anyone clever enough to execute the attack. When you control DNS you also control email. And when you control email you also control, well, everything.

Email is Broken

Assume for a moment that I've used this DNS exploit to take control of your email account. The most obvious effect is that I can now read your mail. Also, I can read your mail and continue forwarding it to you, so that you never realize there is a problem. I can add attachments to your messages, or infect existing attachments from people you trust with viruses or malware. When your best friend sends a link to you about that funny video on YouTube, well, I can rewrite that link to go anywhere I want.

Of course, we all know that nobody out there uses the Internet mail system to do harm, right? Just imagine, instead of getting normal annoying spam like you've been seeing for years now, you also now have to worry about legitimate messages from your friends being the carriers of trouble.

So how else can I use email to my advantage? Kaminsky pointed out that almost every website out there relies on your email address to verify your identity. Using the whois database I can find out who the administrative contact is for, say, and claim that email address. Then I just browse to the website of the registrar for, click on the "forgot my password" link, and have the password for that account reset. Since I'm getting the email for that account, I'll also get the link they send me that says "please click here to verify your new password." At that point I effectively own and can do whatever I want, including changing the contact email address, or transferring it to a different registrar.

Think about that the next time you see a "Forgot my password" link on a website.

SSL is Broken

Dan Kaminsky said that many people were pointing to SSL as a safety measure. He told them they should be more cafeful. After all, how does one go about registering a SSL certificate? Anyone is allowed to buy a certificate, but they must show some authoritity over the domain. This authoritity is checked by the certificate authorities (CA) by using DNS, typically in one of three ways:

  • The CA looks up the domain via whois
  • The CA sends an email to an address they have on record
  • The CA checks for a specially named file on the website's server

As Dan pointed out in his talk, all three of these methods rely on DNS, which we have poisoned. Just because that site you are visiting uses SSL doesn't mean it's the site you think it is. :)

The Web is Broken

Ok, so enough about email. Why else should you care? (as if that weren't enough already) Well, how many sites do you think you visit that have the following code embedded in them?

  <script type="text/javascript"

  <script type="text/javascript"

  <script src="" 
  <script type="text/javascript">
    _uacct = "UA-XXXXXXX-1";

If I were to inject poisoned records into your DNS for,, or then I can execute javascript from any website you visit that uses Google Analytics or Google Adsense. The same holds true for, (YUI), or any other site that serves commonly included scripts (src="?").

Desktop Apps are Broken

Kaminsky also pointed out that we have now entered an era where the Internet has expanded to the desktop. Many applications are useless without an Internet connection, such as AIM/ICQ/Jabber/etc, iTunes, Skype and most popular games. By poisoning the DNS entry for I can intercept AIM messages for anyone who is using that DNS server. The same holds for any other Desktop application that connects to the Internet.

Perhaps most worriesome are mechanisms for applying automatic updates. Yes, this includes attacks on popular Linux package management systems such as apt-get and yum. But it goes beyond that, and into systems that automatically update such as iTunes, Mac OS X, Open Office, Winzip, Winamp, and others. Imagine what an attacker could accomplish if he could poison and in Comcast's DNS servers. Mac OS X, as well as iTunes, periodically checks for software updates in the background, and pops up a notification if there are upgrades to be applied. An attacker could push down any software update and the innocent user would never know the difference.

Everything Else is Broken, Too

Of course, these are just some of the reasons an attacker may want to poison DNS. Kaminsky covers many more in his presentation, including CDN population, writing SSL cookies, and discovering internal addresses for databases, backup servers, and authentication services. He specifically states that it is indeed possible to poison the top level domains, including com, net, and org. That's right, an attacker can intercept all DNS requests for .com. This means that he not only gets to respond to your questions, but also find out what questions you are asking. Those "private" DNS records are no longer private (they never were, really).

The initial patch that the vendors released on July 8th has been deployed in most places by now, but again, it is only a temporary solution. It just makes it harder for an attacker to poison DNS - it doesn't make it impossible. In fact, a Russian researcher named Evgeniy Polyakov has already demonstrated that it is possible to poison the latest patched BIND DNS server with two standard desktop PCs and a gigabit ethernet connection. Instead of 10 seconds it took him 10 hours, and required a lot of traffic.

We are still in trouble, but this is the best we have for now.


Cory Wright


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

The internet isn't a safe

Johanna's picture

The internet isn't a safe place anymore. One can get worms and trojans from all sort of sites. I use Hughes Net as my internet provider and the guys that installed the cables were nice enough to install a firewall for me.


wisser's picture

There is a solution. It is around for almost a decade but politics are stalling it. DNSSec (RFC 4033, 4034, 4035) does prevent this kind of attack. And DNSSec is working. The Swedish TLD is offering DNSSec and the major Swedish ISPs are using DNSSec in their resolvers. Of course there are problems but cache poisoning isn't one of them.

Solution is easy: DJBDNS

erth64net's picture

Yawn...this is old news... I, as well as my customers and end-users, have nothing to worry about. We use DJBDNS, which was hardened against this age-old attack nearly a decade ago; the DJBDNS DNS engine continues to be invulnerable to the inherent flaws of BIND's design (and its derivatives).

djbdns is indeed a great

Cory Wright's picture

djbdns is indeed a great piece of software. See my article about it in this months issue of Linux Journal. :)

However, djbdns is not completely invulnerable to this attack. Evgeniy Polyakov has shown that even source port randomization can be defeated with enough traffic. Also, if your dnscache instances are behind a NAT device that normalizes the ports of outbound queries then you may not be protected.

A note about NAT device

Anonymous's picture

Particularly about NAT device normalizing the port, if you use OpenBSD (what else, right?) based NAT firewall, the source port will be randomly chosen and thus, it doesn't normalize the port. Now, you may ask "How random is OpenBSD randomly chosen those ports?". I don't know the answer on top of my head but you can research on it. I wouldn't worry too much about it since their random generation mechanism is used in other parts of the (well-audited) OS.

See this note in pf documentation at,
"Source port: replaced with a randomly chosen, unused port on the gateway (for example, 53136)"

By the way, I've been using djbdns for over 2 years now and I love it. Read DJB comments that he posted at . Those made me switch to djbdns. While you are at it, check out his qmail: one of the most secure one. I'll add that I have more confidence in qmail than even Postfix just because it uses multiple processes that run under different users who don't trust each other's input (and validate it). And qmail works with ucspi-tcp. Familiar with tcp wrappers? Check out ucspi-tcp, you'll love it.

And since it was released

Anonymous's picture

And since it was released into the public domain in Dec. of 2007 I can't figure out why it isn't being used as the standard everywhere now.


Anonymous's picture

If you forget about the NAT issue and use DJBDNS (it is solid no argument there) the DNS servers you use upstream may be poisoned. If the upstream is poisoned and you could cache the poisoned entry. You have protected yourself against a direct attack. If you do not have control of the upstream servers you can still suffer indirectly. That is what makes me nervous.

A default installation of

Cory Wright's picture

A default installation of djbdns does not forward queries to upstream caches. The dnscache program resolves everything by itself, starting from the root servers and working its way down. It can be configured to forward queries, but by default it does not.