Forwarding Nameserver with BIND 9
I know all of the djbdns fans will attack me, but I set up a forwarding nameserver with the built-in BIND 9.3.1 version packaged with FreeBSD 5.4. I did give djbdns the old college try using the ports tree, but I had trouble getting daemontools and scvscan working in the time I allotted for the project. I was able to get BIND working strictly as a forwarding server using the following steps.
First I created a rndc.key file using rndc-confgen.
I created a /etc/named/rndc.conf file and copied the contents of /etc/namedb/rndc.key into rndc.conf, along with the entries shown below:
I then modified /etc/namedb/named.conf in the following ways.
The first line tells BIND where to listen. The second tells BIND to only forward DNS requests. The third line tells BIND where to forward requests.
So what's the purpose of this setup? I am running BIND on a central system to which various remote sensors connect. All of them will be configured to ask DNS requests of this central system through an IPSec tunnel. None will make DNS requests on the client networks. This reduces the traffic caused by the sensor on the client network.
I had trouble setting up BIND using the configuration I outlined before. Specifically, BIND did not recognize the controls directive:
I have no idea why this happened. Once I removed the controls section, everything worked. This is what I used for controls:
Comments on why this failed are appreciated.
First I created a rndc.key file using rndc-confgen.
janney:/etc/namedb# rndc-confgen -a
wrote key file "/etc/namedb/rndc.key"
I created a /etc/named/rndc.conf file and copied the contents of /etc/namedb/rndc.key into rndc.conf, along with the entries shown below:
options {
default-server localhost;
default-key "rndc-key";
};
server localhost {
key "rndc-key";
};
key "rndc-key" {
algorithm hmac-md5;
secret "OBSCURED";
};
I then modified /etc/namedb/named.conf in the following ways.
listen-on { 127.0.0.1; 192.168.3.7;};
forward only;
forwarders {
192.168.2.1;
};
The first line tells BIND where to listen. The second tells BIND to only forward DNS requests. The third line tells BIND where to forward requests.
So what's the purpose of this setup? I am running BIND on a central system to which various remote sensors connect. All of them will be configured to ask DNS requests of this central system through an IPSec tunnel. None will make DNS requests on the client networks. This reduces the traffic caused by the sensor on the client network.
I had trouble setting up BIND using the configuration I outlined before. Specifically, BIND did not recognize the controls directive:
janney:/etc/namedb# named -g
28-Jun-2005 17:07:57.969 starting BIND 9.3.1 -g
28-Jun-2005 17:07:57.970 found 2 CPUs, using 2 worker threads
28-Jun-2005 17:07:57.986 loading configuration from '/etc/namedb/named.conf'
28-Jun-2005 17:07:57.987 /etc/namedb/named.conf:27: unknown option 'controls'
28-Jun-2005 17:07:57.991 loading configuration: failure
28-Jun-2005 17:07:57.991 exiting (due to fatal error)
I have no idea why this happened. Once I removed the controls section, everything worked. This is what I used for controls:
controls {
inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};
Comments on why this failed are appreciated.
Comments
By the way, I too had problems with djbdns and had to use BIND. It's an internal box on my home network, so I'm not too worried.
nah, just kidding. But to all of the folks that have problems, why not just consider compiling it manually? I know I did. And it worked with my FreeBSD system. I don't believe there's any stuff in there (the ports tree) to warrant having to use the ports system to compile djbdns, or any of its dependencies...
Besides, it's not as if the code is not stable! right? The code's been like not moving for quite a while now (just like qmail-1.03)
So good luck, and have some fun/experimentation with djbdns!
Package management, version control, integrity checking, auditing, compliance to the way the OS builders intended the system to be used etc, all of these things gets accomplished by using the ports - and other package management system - for all your software needs. You gain a lot more than just having a simple compile done.
Want to upgrade package A, ask the package system what depends on A so you know what to rebuild. Really simple example where having a big network with maybe more than one admin installing from source would completely fall flat.