Harden BIND9 Against Cache Poisoning - Page 2

With phishing and pharming attacks on the rise, protecting your DNS servers from cache poisoning is more important than ever.

 By Charlie Schluting
Page 2 of 2   |  Back to Page 1
Print Article

Continued From Page 1

Protecting Yourself
I think we can all agree that upgrading to BIND 9 is a good idea at this point. The remainder of this article shows how to make cache poisoning nearly impossible, and the configuration assumes a BIND 9 installation.

There are two types of DNS lookups: iterative and recursive. Iterative lookups mean that the DNS answer will be "go look here for the answer." Recursive lookups mean that the DNS server queried will find out the answer, and then return it to the person who asked the question. The normal client computer that isn't running a DNS server needs to be able to ask a recursive DNS server, since it won't understand how to "go look elsewhere."

The best method for protecting your site from DNS cache poisoning is to not allow recursive lookups from unknown sources. There will be no chance for malicious people to inject false information if you aren't serving queries on their behalf. This means that your server should not answer authoritatively for zones it doesn't control, unless the query came from an internal computer trying to use the server for all its DNS information. Some people will claim this doesn't help, since the attacker can just spoof an internal IP address; but we have already read about border security and know that our ingress filters will stop that, right?

BIND 9 provides an excellent method for accomplishing this, but unfortunately the default configuration provides no protection.

A quick example in BIND 9.3.x terms shows how to set this up:

  //Put all your "trusted" IPs in here. acl "inside" {  127/8;
10.0.10/24; 192.168.1/24; };

 //zone declarations go here.  view "inside" {  match-clients {
"inside"; };  recursion yes;  };

 //Same zone declarations go here too.  view "outside" {  match-clients
{ any; };  recursion no;  }; 

The important line to note is "recursion no."

BIND 9 will honor the fact that we don't want to do recursive lookups for untrusted clients who match the "outside" view. It is really that simple. There is no more worrying about the mathematical reasoning behind guessing transaction IDs, because it no longer matters when we don't respond to unknown requestors (excluding authoritative responses about our own zones).

ISC's BIND has had many run-ins with security issues, partly because it has been around since the dawn of Internet time. Dr. Bernstein's djbdns is quite secure, and worth considering. He even offers a monetary reward if someone finds a security hole in his software, but guessing a transaction ID after 1 million attempts isn't a "hole." With djbdns, remember, the port numbers used to talk to a client are random too. This simple practice yields a much more secure DNS implementation, with regards to securing transactions and preventing cache poisoning. Look for ISC to follow in djb's footsteps, eventually.

This article was originally published on Apr 8, 2005
Get the Latest Scoop with Networking Update Newsletter