DNS caching poisioning

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 vulnerable…by running the commands below replacing ns1.youdomain.co.tz with their organization’s TLD or ccTLD.

dig +short @ns1.youdomain.co.tz porttest.dns-oarc.net 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. <!–[endif]–>

Reload or Restart BIND.

/etc/init.d/named reload <!–[endif]–>

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

dig +short @ns1.youdomain.co.tz porttest.dns-oarc.net 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.


Upgrading an older version of FC with FC9 Updated bind …
Submitted by pererik (Contact Author) (Forums) on Wed, 2008-07-30 10:31.

If you have a server with an nonsupported FC release, i.e. FC7, you can upgrade from SRPMS from FC9 like described below

1) Download the SOURCE rpms (in this case ftp.uio.no):
cd /tmp
wget ftp://ftp.uio.no/linux/Fedora/updates/9/SRPMS/bind-9.5.0-33.P1.fc9.src.rpm
rpm -ivh bind-9.5.0-33.P1.fc9.src.rpm

2) Build the RPMS:
cd /usr/src/redhat/SPECS
First try:
rpmbuild -bb bind.spec
You may have to install missing rpms with yum like:
yum update postgresql-devel mysql-devel unixODBC-devel
Try again:
rpmbuild -bb bind.spec
If OK, proceed to 3), else repeat.

3) Check out the binary RPMS produced:

cd /usr/src/redhat/RPMS/i386
ls -l total 10416
-rw-r–r– 1 root root 1706252 2008-07-30 09:11 bind-9.5.0-33.P1.fc7.i386.rpm
-rw-r–r– 1 root root   58218 2008-07-30 09:11 bind-chroot-9.5.0-33.P1.fc7.i386.rpm
-rw-r–r– 1 root root 4130721 2008-07-30 09:11 bind-debuginfo-9.5.0-33.P1.fc7.i386.rpm
-rw-r–r– 1 root root 3277876 2008-07-30 09:11 bind-devel-9.5.0-33.P1.fc7.i386.rpm
-rw-r–r– 1 root root  978048 2008-07-30 09:11 bind-libs-9.5.0-33.P1.fc7.i386.rpm
-rw-r–r– 1 root root  274739 2008-07-30 09:11 bind-sdb-9.5.0-33.P1.fc7.i386.rpm
-rw-r–r– 1 root root  195075 2008-07-30 09:11 bind-utils-9.5.0-33.P1.fc7.i386.rpm

4) Backup your bind config files.

5) Which bind rpms are installed on my machine?
rpm -qa | grep “^bind”

6) Upgrade only the RPMs what you have installed on your machine:

rpm -Uvh bind-9.5.0-33.P1.fc7.i386.rpm bind-chroot-9.5.0-33.P1.fc7.i386.rpm bind-libs-9.5.0-33.P1.fc7.i386.rpm bind-utils-9.5.0-33.P1.fc7.i386.rpm

7) Check the log and verify that everything is OK.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s