Home / Blogs

So You Think You’re Safe from DNS Cache Poisoning?

Everyone is probably well aware of the Kashpureff-style DNS cache- poisoning exploit (I’ll call this “classic cache poisoning”). For reference, see the original US-CERT advisory prompted by this exploit.

Vendors patched their code to appropriately scrub (validate) responses so that caches could not be poisoned. For the next 7-8 years, we didn’t hear much about cache poisoning. However, there was still a vulnerability lurking in the code, directly related to cache poisoning.

An Additional (not new) Poisoning Problem

On March 26, 2005, a thread on the NANOG mailing list started that was titled “DNS cache poisoning attacks - are they real?”. Operators began to notice more systems being poisoned again, and discussion ensued as to how this could be happening.

On April 7, 2005, the SANS ISC (not to be confused with Internet Systems Consortium) posted an update detailing how Microsoft Windows DNS servers were still being poisoned, even though the “Secure cache against pollution” option was set. The SANS ISC found that Windows DNS servers using BIND4 and BIND8 servers as forwarders were being poisoned. But how could this be?

Dan Kaminsky of Doxpara Research presented details of a large scale research project he started on the DNS. The initial results of this research were posted in an article on News.com.

I think a slight clarification of the News.com article is necessary, with respect to this paragraph:

“The vulnerable servers run the popular Berkeley Internet Name Domain software in an insecure way and should be upgraded, Kaminsky said. The systems run BIND 4 or BIND 8 and are configured to use forwarders for DNS requests—something the distributor of the software specifically warns against.”

In reality, the vulnerable systems are using BIND4 or BIND8 DNS servers *as* forwarders. So what is forwarding, anyway?

What is a Forwarder?

A forwarder is a recursive/caching name server used by downstream systems that have no root.cache file, or that can not access the global DNS for policy reasons. The downstream systems then “forward” all DNS requests to the forwarder for resolution. On a cache miss only, the forwarder will recursively find the answer, scrub any poisoned responses, insert the clean response into the cache, and pass the answer back to the requesting system. However, the answer that is passed back to the requesting system is NOT scrubbed. If that response was poisoned, the downstream system receives poisoned data. Since it has no root.cache file to perform anti-poisoning logic… ouch!

This gives an attacker a chance to poison any system using BIND4 or BIND8 as a forwarder on *any* cache miss on the forwarder. Given the number of systems Dan Kaminsky found that are using a BIND8 system as a forwarder, and the number of possible domains to poison, you can see the potential scale of this problem. Of course, once the forwarder has clean data in the cache, any answers sent to downstream systems from the cache is clean.

Who is Most at Risk?

Anyone using large scale “forwarding” configuration for their name servers is at risk. Imagine tens of thousands of cable model or DSL customers using an ISP DNS servers as a forwarder. Even more dangerous is “forward chaining” where three or more DNS servers are configured to forward queries upstream. Forwarding in and of itself is really not dangerous, but operators should consider the use of forwarding dangerous simply because the systems using a forwarder have no way to validate the responses they get from it.

Why Don’t Organizations Update DNS Software?

Lack of money, lack of expertise, confusion, politics? Yes! Enterprise IT staff or ISP engineering staff are all plagued by one or more of these issues that may prevent or hinder them from upgrading DNS software. If you use the “canonical” BIND source and don’t have resources to deal with upgrading/configuring BIND, consider:

  1. Joining the BIND Forum
  2. Obtaining BIND Support

However, this certainly isn’t a problem limited to DNS software. And the problem is much bigger than the canonical BIND software. Since many firewall and/or appliance vendors start with BIND code as the base for their own DNS implementation, then add their own features and functions, there may be tens of thousands more systems on the Internet with a bug like this just waiting to be triggered. Many times a specific vendor support contract will prevent an organization from upgrading software, saying in effect they will “void” the support contract.

What’s the Future of DNS Management?

I don’t believe this is so much an issue of “managing” DNS. This is a never ending battle of managing software development, and a never ending battle of bad guys exploiting vulnerabilities and good guys racing to find them and fix them first.

What we really need is more large-scale measurement and testing projects for the DNS. DNS is a large, complex, distributed database. We must better understand how it works *when it’s working*, as well as what happens when it breaks, or even ways the DNS might fail that we haven’t thought of yet! The bad guys are continually probing software and systems for weaknesses. We need better intelligence, and we need it yesterday.

How can I help with this, you ask? Support and/or participate in organizations and projects such as the DNS Operations, Analysis, and Research Center (OARC), the Cooperative Association for Internet Data Analysis (CAIDA), or Doxpara Research (Dan Kaminsky’s Infrastructure Validation Project).

The only way we can *avoid* these problems, and reduce the fear, uncertainty, and doubt that circulates is to measure, test, understand, and educate everyone. I have hopefully furthered those goals in this article.

By Brett Watson, Senior Manager, Professional Services at Neustar

Brett’s experience spans large-scale IP networking, optical networking, network/system administration and design, and security architecture including high level security policy and architecture, as well as vulnerability assessments and penetration testing.

Visit Page

Filed Under


The Famous Brett Watson  –  Aug 18, 2005 3:44 PM

Let me see if I have this straight. The BIND4 or BIND8 instance that’s acting as a forwarder cleans the received response for the purposes of populating its local cache, but passes the unscrubbed response back to the original requesting party? I’ll bet someone slapped their forehead over that one.

On a slightly tangential note, given that most such vulnerabilities come from weak implementations, rather than weakness in the protocol itself, are we likely to create more problems than we solve by increasing the complexity of the process in the name of security? I refer here to DNSSec, of course, and I’m not saying that it’s a bad idea, but it does give me pause to question how much real improvement it can offer, given inevitably weak implementations.

Matthew Elvey  –  Aug 25, 2005 11:18 PM

Looking at the DNS software a few ISP servers claim to be running didn’t give me a warm fuzzy feeling.
Is it appropriate to probe and publicize a wall of shame/list of vulnerable servers?  I think so.  The bad guys already know.
I see some large services with nameservers running 8.x.

Brett Watson  –  Aug 25, 2005 11:22 PM

matthew, that would be a good question for dan kaminsky.  he’s running a project (linked to from the article) to ‘map’ the interrelationships of servers running bind8 with forwarders pointing at them.  the news.com article mentions what is probably the tip of the iceburg.  dan is working on a much larger scale analysis.

i think before a ‘wall of shame’ goes up, efforts should probably be made to contact providers and educate/encourage them to *upgrade* and properly configure systems.  that was part of the purpose in writing this article.

Simon Waters  –  Sep 4, 2005 9:20 AM

Matthew, when I did get involved in monitoring and sorting DNS issues, I found you can’t rely on the returned version number to reveal specific weaknesses with the implementation.

Some of the big Unix vendors, commercial DNS implementations based on BIND, and others, will backport fixes from more recent versions of BIND, in an attempt to minimize the disruption to their customer base. Although I’m not sure how wise this is as a long term strategy, and you would hope they would all be based on BIND9 by now.

Whilst the recent poisonings are worrying, other basic weaknesses in deployed DNS configurations remain, not least one well known organisation, that should know better, appeared to have both (only 2?) DNS servers deployed in the New Orleans metropolitan area before the hurricane struck, fortunately it looks like they managed to move the service away “just about in time”.

However I notice my earlier criticisms of the poor state of many European TLD have been at least partially addressed. Human nature, whilst things mostly work, is not to address them till they are clearly broken, and for all it’s flaws the DNS “mostly works”, where as some of us know that it is “broken enough” to need fixing.

The good news is that the poisoning problem is something you can fix for yourself, and you can do it all with Free Software”, so no need to get budgetary approval.

I’m voting “lack of expertise” being the biggest cause.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



IPv4 Markets

Sponsored byIPv4.Global

Domain Names

Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API


Sponsored byVerisign

Brand Protection

Sponsored byCSC


Sponsored byDNIB.com

New TLDs

Sponsored byRadix