A Few Issues with Installing BIND on CentOS 5.3

Published May 18th, 2009

It was time for us to upgrade our development center’s gateway server and we needed to redo our caching DNS server setup that permits local LAN users to enjoy a local DNS server with a split mindset — to support local non-routable domains for internal development teams and cached DNS service for external resources.

Our last BIND install was long time ago and it was willingly forgotten. So before I started with BIND I decided to give a little thought on BIND replacement. My BIND installation started with a Google search for ‘BIND replacement’ and djbdns surfaced. I am big fan of DJB’s (Daniel J. Bernstein) work on cryptography and generally admire his approaches to solving real problems and a very big fan of qmail. But I hardly recommend his wares for scenarios where inexperienced (1-5 years) engineering staff is in charge of network services.  Therefore, even though I loved how djbdns works and the security it provides, I had to stick with the latest version of BIND for this installation. In case you want to ponder some more on the merits of BIND vs djbdns, check out the following document:

BIND versus DJBDNS: A Comparison of Performance,
Ease of Configuration, and Security

If you read the above article, you will notice that BIND only wins against djbdns when it comes to ease of installation: 6 steps for BIND vs 17 steps for djbdns. If djbdns could be had using yum, it would have a bigger install base. Too many steps in installing and configuring makes lazy people (like me) want to stick with what they already have or know.

Although I was quite accustomed to setting up BIND, I found myself into two interesting problems that I like to write here so that next time one of my staff can avoid them without pulling his hair out or wasting hours and hours.

LAN clients can connect to BIND but nothing more happens

I created a view in /etc/named.conf file to allow internal LAN clients connected to localnets to be able to use the DNS server and also see a special internal zone. However, the clients were able to connect fine but they would not resolve anything and timeout.

After an hour+ investigation, I gave up and returned home and later reviewed the problem and discovered that our IPTABLE settings were the cause of the problem. I had only enabled domain port (53) to be open for LAN clients but did not allow the UDP port!  So after adding the following two lines in /etc/sysconfig/iptables and restarting the iptables service, we were in business!

-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport domain -j ACCEPT
-A RH-Firewall-1-INPUT -m state –state NEW -m udp -p udp –dport domain -j ACCEPT

The internal view looked like below:

options {
listen-on port 53 { 127.0.0.1; 192.168.8.254; };
directory       "/var/named";
allow-query     { any; localhost; localnets; };
};

view internal {
match-clients      { localnets; };
recursion yes;
include "/etc/named.rfc1912.zones";
zone "evoknow.net" { type master; file "evoknow.net"; };
};

Weird Problem with CentOS 5.3 Resolver

One of the strangest thing that I have noticed on CentOS 5.3 is that even if I do not provide any nameservers in /etc/resolv.conf and have a caching DNS server running on the same machine or its default route, it is able to resolve names!  I do not understand how that works.  Normally, if you have an name server entry in /etc/resolv.conf, it uses it and if you don’t name service fails unless you are trying to resolve hosts defined in /etc/hosts. So I am bit puzzled by the fact that on this new CentOS 5.3 installation, it works without any valid entries in /etc/resolv.conf.  I did not bother with this much as it works either way for me now.  I will investigate this later or perhaps you can find out more.

Cheers.

Category: DNS | Tags: