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.

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 {;;};

forward only;

forwarders {;

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 allow { localhost; } keys { rndc-key; };

Comments on why this failed are appreciated.


Anonymous said…
All I can think why it failed would be because you had controls before defining the key. Mine looks the same as your except my controls statement also has a port configure.
Anonymous said…
Mine looks the same also. Perhaps the order is essential.

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.
Anonymous said…
now when u're talking bad about djbdns publicly, then u're just asking for it... ;P

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!
Anonymous said…
If you think using ports is about compiling then you're missing the plot.

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.
Anonymous said…
yes, i know. My point was just that djbdns doesn't really depend on a load of stuff (or others, on it, that requires some trickiness that requires ports. Want a dns server/cache? Sure! no big deal. Just put it in /etc/resolv.conf) - so imo, it is perfectly fine to compile it by hand if you want to. Just know that the source hasnt moved for some time already, and probably wont move ever (djb reserves the last word on that, of course).
mechanix said…
'controls' statement has to be before (not in) 'options'

Popular posts from this blog

Five Reasons I Want China Running Its Own Software

Cybersecurity Domains Mind Map

A Brief History of the Internet in Northern Virginia