BIND 9 Vulnerability And Solution - Patch BIND To Avoid Cache Poisoning (Fedora/CentOS)

I am pretty sure most of you guys have hard about the Vulnerability in BIND. Dan Kaminsky earlier this month announced a massive, multi-vendor issue with DNS that could allow attackers to compromise any name server - clients, too.

I thought I would share with you all one of the quickest solutions systems administrators running BIND 9 can use to help solve this vulnerability in case their systems are vulnerable.

After 3 days of testing and playing around with my DNS servers, I discovered something that seemed to solve my problem hence deciding to share with you all.

I am not sure if this really solved the problem, though it has worked for me as the test results are great. But your suggestions and comments are welcome.

My finding as simple as it may look, only applies to those folks running BIND 9 on Centos 4 or 5 and Fedora core systems and above... I tested on all this boxes in my office.

Let’s start…shall we?


Prerequisites And Assumptions

  • Your firewall (iptables NAT/PAT or PIX) must have port 53 open in such a way that it will allow random port selection.
  • You must be running BIND 9 on Centos 4 or 5 or any Fedora core system.
  • Bind must be running in chrooted mode though not a prerequisite but a best practice.
  • In your /etc/named/named.conf OR /etc/named.conf files....One must disable recursive querying and also add an acl to only allow their networks to do recursive requests. With this, the system administrator will have reduced chances of cache poisoning down to their own known networks.
acl "mynetworks" {
view "internal" {
         match-clients { mynetwork; };
         allow-query { mynetwork; };
         allow-recursion { mynetwork; };
         match-recursive-only yes;
view "external" {
         match-clients { any; };
         allow-query { any; };
         allow-recursion { none; };
         match-recursive-only no;


And Now To Fix The BIND Vulnerability

The first step is for one to check if their system is running the commands below replacing with their organization's TLD or ccTLD.

dig +short TXT
" is POOR: 26 queries in 20.0 seconds from 1 ports with std dev 0.00"

POOR-----> definitely indicates that the name-server or system in question is vulnerable and of course the BIND software running is also old and needs to be PATCHED ...



For those who run CentOS OR Fedora systems.....yum can be used to patch the systems. The CentOS 5 developers have already released a patch for BIND software and the current one is: bind-9.3.4-6.0.2.P1.el5_2.  P1 indicates the package is a patched one.

On my systems after patching i got this result..

rpm -q bind

bind-9.3.4-6.0.2.P1.el5_2  ----> if your bind version is not patched..then patch it.

One should do this to get the latest software and patch.

yum update bind bind-chroot -y

One should edit their named.conf file and add the following. Save and reload BIND.

 vi /etc/named.conf 
options {
         directory "/var/named";
         allow-transfer { ;};
         query-source   address * port 53; ##COMMENT or REMOVE THIS LINE.

It will allow random port selection. Only do this if this parameter is enabled under options in your named.conf file.

         dnssec-enable yes;                        ## ADD THIS OPTION TO ENABLE DNS-SEC.

The above line when added to your named.conf file will enable DNS-SEC. Go ahead and set up DNS-SEC but remember DNS-SEC isn't an ultimate solution to this vulnerability.

Reload or Restart BIND.

/etc/init.d/named reload

Then test again to see if you get a better result.

dig +short TXT

Just to confirm...:-)
" is GOOD: 26 queries in 19.6 seconds from 26 ports with std dev 16515.27"

GOOD indicates that the name server in question at appears to be safe, but one must make sure the ports listed aren't following an obvious pattern. i.e the ports with standard deviation..16515.27...But if your test clocks ( 10000.00 std dev ) then your DNS server is safer and your clients or users should not worry.

The same procedure should be carried out on all DNS servers in your organization.

Share this page:

2 Comment(s)