Chapter 5. BIND (Berkeley Internet Name Domain)

This chapter describes HOWTO install BIND 9.3.x on a variety of OS Platforms as well as BIND's command line arguments. Finally - BIND runs as the daemon named on *nix systems and named.exe under Windows.

Note: The following notes also apply to BIND 9.4.x with the single exception that since BIND 9.3.2 NT 4.0 is no longer supported while Windows XP and Server 2003 have been added to BIND's supported platforms.

• FreeBSD Install (4.x, 5.x and 6.x)

• Linux Install (Fedora Core 2)

• Windows Install (Win2K and NT 4.0)

• BIND Command Line Arguments

FreeBSD 4.x and 5.1 ships with BIND version 8.x as the default or base installation. FreeBSD 5.3 - the first of the stable 5.x series - ships with BIND 9.3.0 and some annoying traits. FreeBSD 6.2 ships with BIND 9.4.1 as the base installation.

FreeBSD differentiates between a base DNS install and a normal DNS install. There are some serious choices to be made when installing from the ports system. We assume the theory behind this is to enable experimentation with the new software but with the ability to return to the original DNS software by changing configuration options in the rc.conf file if things get a bit wobbly.

You can either install BIND 9 as well as the default BIND 8 or 9 installation or you can replace the base version. The base version is installed in /usr/sbin (and the tools in /usr/bin) whereas a normal (non-base) ports installation is made to /usr/local/sbin (and the tools to /usr/local/bin). Finally the base version assumes the named.conf file in /etc/namedb/named.conf whereas a non-base install assumes /usr/local/etc/named.conf.

Notes:

1. On our very dirty FreeBSD 4.x test system - we have done a lot of very naughty things to this poor system none of them deliberately! - we failed to get Bind9 to install initially. The DNS make kept failing with undefined's during compilations in exotic modules caused by incompletely generated header files - created by the gen program which is in turn built during the install! We eventually tracked the problem to an install of /usr/local/lib/libnsl which was causing the installation to assume a linux base and hence the gen program failed to generate the headers correctly. We deleted the library (it's not normally installed in FreeBSD) re-ran and all was well again. The Bind9 build process is really rather horrible we have concluded. Maybe its all essential but complex man, complex. Still it forced us to find out more about autoconf and configure and automake and make and gmake... We had to take a couple of days off work to recover.

BIND 9 non-base install

Assuming you have updated the ports-dns collection proceed as normal:

cd /usr/ports/dns/bind9
make install clean

The above sequence installs BIND9 in /usr/local/sbin and the tools in /usr/local/bin and assumes the named.conf file is in /usr/local/etc.

If you want to run BIND9 at startup you must edit /etc/rc.conf as follows:

# add following line if not present
named_enable="YES"
# the line below must replace the line named_program="/usr/sbin/named' if present 
# otherwise add it
named_program="/usr/local/sbin/named"

Either copy your named.conf file from /etc/namedb to /usr/local/etc before you restart Bind or create a new version of the file in this directory.

To use the BIND9 tools you must precede the command with the BIND9 tool directory path e.g.

 
# this will run the installed Bind9 version
/usr/local/bin/dig example.com any
# but this command
dig example.com
# this will run the base dig version
# 4.x and 5.1 = Bind 8, 5.3 = Bind 9.3.0
dig example.com

BIND 9 replace base install

This assumes you either want to run the latest version of BIND as the base system - replacing the exiting BIND - or a new install with Bind 9 as the base system. Assuming you have updated the ports-dns collection proceed as follows:

cd /usr/ports/dns/bind9
make PORT_REPLACES_BASE_BIND9=yes install clean

Note: BIND 9.3.1+ installation has changed the above value to WITH_PORT_REPLACES_BASE_BIND9=yes. Other than to screw everyone up it's not clear why this has been done - perhaps a desire to be consistent with other options which mostly start with WITH_ - if you get the drift.

The above sequence installs BIND9 in /usr/sbin and the tools in /usr/bin.

If you want to run BIND9 at startup you may need to edit /etc/rc.conf as follows:

# add following line if not present
named_enable="YES"
# add the line following line if not present
named_program="/usr/sbin/named"

No special action is required to run BIND9 tools:

 
# this will run the Bind9 dig version
dig example.com

FreeBSD 5.3/6.2 Issues

By default FreeBSD 5.3 installs Bind 9 (9.3.0) as the default (or base) version and 6.2 installs 9.4.1 as the base version but with the following wrinkles:

1. Bind9 defaults to run in a chroot jail or a sandbox (which nows seems the "in" term for a jail) in which all BIND9 files are maintained under /var/named - including named.conf, log files and pid files (hard links are provided so you can continue to find the files where you thought they would be). To disable the sandbox add to /etc/rc.conf the following line(s):

   named_chrootdir=""	               # disables jail/sandbox 
   named_pidfile="/var/run/named/pid" # Must set this in named.conf as well
   named_chroot_autoupdate="NO"       # Automatically install/update chrooted
                                      # components of named. See /etc/rc.d/named.
   named_symlink_enable="NO"	         # Symlink the chrooted pid file
   

   The default value of these parameters in /etc/defaults/rc.conf are:

   named_enable="YES"                 # Run named, the DNS server (or NO).
   named_program="/usr/sbin/named"	   # path to named, if you want a different one.
   named_flags="-u bind"              # Flags for named
   named_pidfile="/var/run/named/pid" # Must set this in named.conf as well
   named_chrootdir="/var/named"       # Chroot directory (or "" not to auto-chroot it)
   named_chroot_autoupdate="YES"      # Automatically install/update chrooted
                                      # components of named. See /etc/rc.d/named.
   named_symlink_enable="YES"         # Symlink the chrooted pid file
   

   As always you should not update the /etc/defaults/rc.conf file but rather edit /etc/rc.conf which will replace entries already defined in /etc/defaults/rc.conf.

2. The system does not ship with localhost or localhost.ca (localhost.rev in our terminology) files instead there is a script /etc/namedb/named.sh which will help you define these files.

This section describes the installation of BIND 9.3.0 on a clean Fedora Core 2 system. This was the first Linux system we had used used since Redhat 7.x series and we found it significantly more windows like (this may be good or bad depending on your predilictions for these things). It was also the first time we had ever had a X11 graphical installation work without fooling around with XF86Config config files (or the /etc/X11/xorg.conf as it is now). How much of this is a function of time and better probing routines and how much the change to Xorg we have no real idea. Never-the-less if you want a graphical system it surely was real fun (read difficult) to configure X-Windows in the old days and it appears at least one of the objections to Linux vs Windows has been removed if you are into GUIs. The configuration had the following highlights:

1. We used the graphical configuration option (anaconda)
2. Automatic Partitioning was selected
3. A server install was selected
4. We selected a GNOME based desktop - we had read somewhere that RH had elected to go with GNOME (rather than KDE) - and we were curious to see what stage the GUI stuff had reached. We would not normally install a GUI for a server configuration.
5. Since we were going to install BIND 9.3.0 we did not select to install DNS from the installation menu. In fact, as we shall see, it partially installed BIND-9.2.8-13.
6. We selected very few install options other that the development tools and graphical internet utilities - this later to allow us to get a hold of the various RPMs and tarballs. We would use the browser for FTPing the rpms and the former for use with the various tarballs.

Installation was very uneventful and we were up in < 30 minutes. Note: We were using a VIA M10000 motherboard (we love these systems) based server and had failed to install FC3 on this system so we retreated fairly quickly to FC2. We note in passing that Fedora is pushing releases out a pretty quick rate these days. We also noted that FC2 does not support the latest SE Linux options - well it does but they are disabled 'cos they don't work. You need at least FC3 for this functionality or even FC4 which is on the horizon.

BIND 9 Install

We used mozilla (the FC2 default installed browser) to obtain, from rpmfind.net, Fedora Core Development rpms for:

1. bind-9.3.0-2.i386.rpm
2. bind-utils-9.3.0-2.i386.rpm
3. bind-libs-9.3.0-2.i386.rpm
4. bind-devel-9.3.0-2.i386.rpm

The above were all downloaded to /tmp. Before we installed we ran the following from a terminal window:

rpm -q bind
# which returned
bind-9.2.8-13

In retrospect this was surprising (since we had not requested any DNS software during the FC2 installation procedure - FC2 install was kind enough to do it anyway) and perhaps we should have removed this version before installing since we ended up with -in our view - an incomplete installation. We may have had a complete install if we had done this - maybe not. We issued the following command to upgrade the installation:

rpm -Uvh /tmp/bind*

every thing appeared to work - there were no error messages. So far so good.

BIND 9 Configure

So we had a bright shiny FC2 GNOME destktop with BIND 9.3.0 installed in front of us and now to get BIND up and running. We were as conversant as normal with the details of any system that was new to us - we read nothing but figured we could wing it and hit google if we got into trouble. We rounded up the normal suspects looking for the default named.conf and default zone files in the normal Linux locations being /etc/named.conf and /var/named for the zone files - typically named.ca for the root servers - and localhost.zone and named.local (one day someone may explain the the idea behind the naming scheme here - we suspect drunken revelry ourselves). We discovered only a file called named.custom in /etc which was a vestigial named.conf file. We poked around a bit more and then found a GUI BIND configuration tool under System Settings-> Server Settings-> DNS from the main menu (which is very windows like). After 5 minutes and a look at the help file for system-config-bind we abandoned the GUI method. Why it could not provide a set of default configurations to include caching server configuration (or at the very least default local host files) is beyond us. What is the point in having a GUI utility that forces you to know just as much as if you manually configure - and the help files don't even hyperlink the BIND documentation - beats us. This GUI for the sake of GUI which - IOHO - misses the point about the power of a GUI.

We manually built a simple caching server named.conf (no we didn't use vi - we used gEdit). We FTP'd the missing root.server(called named.ca in RH Lunix distributions - also available here as named.root) and master.localhost (called localhost.zone in RH Lunix distributions) and localhost.rev (called named.local in RH Lunix distributions) from another system - if you can't do this you will have to manually create them. We always log to /var/log/named/named.txt (habit really) so we had to create and fix the permissions for this directory using:

cd /var/log
mkdir named
chown named:named named

We then fired up BIND using:

/etc/rc.d/init.d/named start

And it failed with a segmentation fault!

syslog (/var/log/messages) showed the following message:

/usr/lib/libisc.so.9: symbol __snprint_chk, version GLIBC_2.3.4
not defined in file libc.so.6 with link time reference failed

We checked the version of GLIBC:

rpm -q glibc
glibc-2.3.3-27

Surprising that rpm forgot the dependency on glibc!! We downloaded the following Fedora Core Development rpms - all demanded by various dependencies:

1. glibc-2.3.4-3
2. glibc-common-2.3.4-3
3. glibc-devel-2.3.4-3
4. glibc-headers-2.3.4-3
5. nscd-2.3.4-3
6. selinux-1.20.1-2

The easiest way we know to solve all those terrible dependency with rpms is to create a new folder (in this case /tmp/glibc) - download or move all the rpms into it and then:

rpm -Uvh /tmp/glibc/*
glibc-2.3.3-27

We fired up bind again:

/etc/rc.d/init.d/named start

and confirmed it was running:

ps ax |grep named
1846   ?    S    0:00 /usr/sbin/named -u named

Finally we verified that all was working using a dig:

dig @192.168.2.2 example.com any
# where @192.168.2.2 is the new server address
# forces use of new server irrespective of 
# resolv.conf configuration

Which returned a good result and confirmed that all was working. We wanted this server to use our new DNS so we edited /etc/resolve.conf to include this servers IP as the first namesever record.

We also want bind to load at start-up time so we need to ensure the named script in invoked - the named script was installed as usual as /etc/rc.d/init.d/named by either the initial install or the upgrade - who knows). To do this we linked the named start/stop script for each of the run-level directories that we might use:

ln /etc/rc.d/init.d/named /etc/rc.d/rc5.d/S68named # gui interface
ln /etc/rc.d/init.d/named /etc/rc.d/rc5.d/K68named # gui interface
ln /etc/rc.d/init.d/named /etc/rc.d/rc3.d/S68named # tty interface
ln /etc/rc.d/init.d/named /etc/rc.d/rc3.d/K68named # tty interface

The 68 in the S and K values is pretty arbitrary.

Finally we rebooted the system, checked syslog for any errors and verified that BIND was indeed running, again with the command:

ps aux |grep named
1846   ?    S    0:00 /usr/sbin/named -u named

In our follow-up research we discovered we had two other choices for installation as well as the standard rpms:

1. caching-nameserver rpm which seems to be a package installed after BIND has been installed.
2. bind-chroot rpms

We could find no further documentation that describes use, specification of installation instructions for either of these packages. We're sure it must exist.

This section describes the various command line options for BIND. You can get these using man named but reproduced here for consistency.

Arg	Param	Notes
-c	/path/to/config-file	Absolute path to the config file (named.conf). This allows you to both change the location and the name of this file. Default depends of OS (Linux = /etc/named.conf, BSD = either /etc/namedb/named.conf or /etc/local/etc/named.conf, Windows = c:\winnt\system32\dns\etc\named.conf.
-d	de-bug level
-f	-	run in foreground (don't run as daemon) - normally only for de-bug purposes.
-g	-	run in foreground (don't run as daemon) and log to stderr (console) - normally only for de-bug purposes.
-n	#cpus	Create #cpus worker threads to take advantage of multiple CPUs. If not specified, named will try to determine the number of CPUs present and create one thread per CPU. If it is unable to determine the number of CPUs, a single worker thread will be created.
-p	port-no	Listen on defined port number. Default is 53. Normally only used for debugging purposes since queries are received on port 53.
-t	directory	The path to the a directory to be used when named is run in a sandbox (a chroot jail). This is conventionally set to /var/named/chroot in most systems which offer this service as a standard configuration or option (BSD and FC2 do) but can be set to anything you want. Must be used in conjunction with the -u argument below to provide any meaningful security.
-u	user	Cause bind to suid() (change user name) after creating sockets on port 53 (which is in the privileged range of < 1024). If not present runs as user root. Generally used only with chroot options (-t above) but most start-up scripts now use -u named argument even if not chrooted which means that log files files will have to have appropriate permissions set.
-v	-	Displays the bind version number to stdout (console) and exit.

There are two further arguments (-s and -x) which should only be used by developers and have been omitted.