How To Patch BIND9 Against DNS Cache Poisoning On Debian Etch

Version 1.0
Author: Falko Timme <ft [at] falkotimme [dot] com>
Last edited 07/28/2008

This article explains how you can fix a BIND9 nameserver on a Debian Etch system so that it is not vulnerable anymore to DNS cache poisoning.

This document comes without warranty of any kind! I do not issue any guarantee that this will work for you!

1 Checking If BIND Is Vulnerable

Run the following command against your nameserver to find out if it is vulnerable (replace ns1.example.com with your own nameserver address):

dig +short @ns1.example.com porttest.dns-oarc.net TXT

mh1:~# dig +short @ns1.example.com porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"1.2.3.4 is POOR: 26 queries in 4.4 seconds from 1 ports with std dev 0.00"
mh1:~#

POOR indicates that BIND is vulnerable. In this case you must patch BIND.

If you don't get any answer at all, this means that your DNS server is no recursive resolver which means it doesn't answer queries for domains that it isn't authoritative for. In this case you're not vulnerable to cache poisoning, but still I strongly advise to update BIND!

2 Patching BIND

This is not so much a patch, but an update. Simply run

apt-get install bind9 bind9-host

This will install the updated BIND packages from the Debian repositories.

Afterwards open /etc/bind/named.conf and modify the options section. If you don't need a recursive resolver (i.e., if your nameserver should answer only queries for domains that it is responsible for), add allow-recursion { none; };. That way you turn off caching for other domains. The second line you should add is dnssec-enable yes; - this makes that BIND answers queries on random ports which are harder to guess for hackers (remember the answer to our dig command in chapter 1: [...]26 queries in 4.4 seconds from 1 ports[...] - BIND was answering on only one port...).

Correction: I've just received the following email from Alan Clegg:

Good day!

I just read your writeup at:

http://www.howtoforge.com/how-to-patch-bind-to-avoid-cache-poisoning-debian-etch

and have a couple of comments.

First off, thanks for writing this. We need as many people to fix this
problem as possible.

Secondly, there is a minor error that should be corrected. You state:

"The second line you should add is dnssec-enable yes; - this makes that
BIND answers queries on random ports which are harder to guess for hackers"

Actually, this line enables the server to respond with DNSSEC records
when the "DO" (DNSSEC OK) bit is set in the question being asked.

What you want people to look for is a statement like:

query-source [...] port XX;

Where the XX is a fixed port number on which the queries from this
system are to be sent. This undoes everything that the new versions of
BIND do to randomize the UDP source port.

If you have any questions, please feel free to send e-mail.

Alan Clegg
Internet Systems Consortium (ISC)
Training and Support

vi /etc/bind/named.conf

[...]
options {
        pid-file "/var/run/bind/run/named.pid";
        directory "/etc/bind";
        auth-nxdomain no;
        allow-recursion { none; };
        dnssec-enable yes;
        /*
         * If there is a firewall between you and nameservers you want
         * to talk to, you might need to uncomment the query-source
         * directive below.  Previous versions of BIND always asked
         * questions using port 53, but BIND 8.1 uses an unprivileged
         * port by default.
         */
        // query-source address * port 53;
};
[...]

Restart BIND afterwards:

/etc/init.d/bind9 restart

(If you're using ISPConfig, your changes will be overwritten by ISPConfig. To prevent this, we take the named.conf template file /root/ispconfig/isp/conf/named.conf.master, modify it as shown above, and save the modified template in the /root/ispconfig/isp/conf/customized_templates directory => /root/ispconfig/isp/conf/customized_templates/named.conf.master. Please also modify /etc/bind/named.conf as shown above in addition to that.)

3 Checking BIND Again

Now we run the query from chapter 1 again:

dig +short @ns1.example.com porttest.dns-oarc.net TXT

If all went well, it should now show GOOD instead of POOR, and it should use more than just one port:

mh1:~# dig +short @ns1.example.com porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"1.2.3.4 is GOOD: 26 queries in 4.4 seconds from 26 ports with std dev 20195.32"
mh1:~#

Congratulations, you have just fixed BIND!

You can also run the dig command against your ISP's nameservers to find out if their nameservers are still vulnerable. If they are, you should urge your ISP to update their nameservers!