Setting up a Bind 9 DNS Name Server

Bind (Berkeley Internet Domain software) is the most commonly used name server. It's necessary to patch bind to prevent your users from being redirected to Verisign's advertising site when they make a typing mistake. See also linuxsetup59.html for details about setting up DNS in small subnets.

Step 1: Apply anti-Verisign patch and build the software. 

   tar -xzvf bind-9.2.2.tar.gz
   cd bind-9.2.2
   patch -p1 < ../patch.9.2.2-P1
   configure
   make
   make install

Step 2: Create Zone files.

  1. Obtain named.root by anonymous ftp from ftp.rs.internic.net
  2. Rename named.root to db.cache
  3. Create zonefiles according to Chapter 4 in DNS and BIND (O'Reilly Press). Note that the filenames for the db files specified in /etc/named.conf must correspond to the filenames of the zonefiles. The zonefiles must be customized for each server. You should have at least two servers. As an example, here are the zone files we use on our server:
    Do not use these files without modification. These files must be modified to match your hostnames.
    1. Create db.127.0.0 (for the localhost)
    2. Create db.mittlenkampf (For forward name resolution)
    3. Create db.11.111.111 (For reverse name resolution)
    4. Create db.22.222.222 if you have a second subnet.
    5. Add the line 
      $TTL 21600
      above the SOA line in each zonefile to specify the time-to-live. This is the 'TTL directive' which is necessary for bind version 9. It is needed even if the TTL is specified in the SOA.
  4. Make sure the forward and reverse files correspond with each other, or you will have weird DNS problems.
  5. Check to make sure the hostmaster alias specified in your SOA is a real person who is listed in the /etc/aliases file.
  6. Make a backup copy of the db files, in case named trashes them (which it will do if you are not authoritative for the domain).

Step 3: Configure Bind.

You should always set up at least two name servers, and designate one as the master.
Do not use these files without modification. These files must be modified to match your hostnames.

  1. Create /etc/named.conf for the master server. Note that the path for the db files ( var/named/ ) is specified in the named.conf file. The format for version 9 is different from that shown in the book. In this example, the access control list (acl) is disabled.
  2. Change the pid-file location to /var/named/named.pid. This is necessary because named is not being run as root and can't access /var/run.
  3. Create named.conf for the slave server(s).
  4. Create user 'named' and group 'named'. In /etc/passwd: 
     named:x:44:44:Nameserver Daemon:/var/named:/bin/nologin
    In /etc/group : 
     named:x:44:named
  5. Create a /var/named/ directory, owned by named.named and put the db files there. They should also be owned by named.named. Make sure /var/named/ has the following permissions: 
          drwxr-xr-x   2 named    root         4096 Apr  1 14:42 named
  6. Set the options in named.conf as needed for security. 
    options {
        directory "/var/named";
        pid-file "/var/named/named.pid";
        allow-query { "any"; };
        allow-transfer { 63.127.146.192/26;  65.198.102.64/26;};
        allow-recursion { 63.127.146.192/26;  65.198.102.64/26;};
};
    The "allow-transfer" option prevents third parties from performing zone transfers and thereby gaining information about your network.

    The "allow-recursion" option prevents third parties from leeching your bandwidth by using your server instead of their own server to do their DNS. With this line, only the specified networks are allowed to perform recursive queries, i.e. queries about names for which the server is not authoritative. Answering recursive queries also makes your server vulnerable to cache poisoning.

    You should also disallow dynamic updates. The main effect of dynamic updates is to mess up your zone files. See www.cert.org/archive/pdf/dns.pdf for more suggestions on securing your DNS server. 
    zone "brclbangers.org" {
        type master;
        file "db.brclbangers";
        allow-update { none; };   
        allow-transfer { 63.127.146.192/26;  65.198.102.64/26; };
        allow-query { "any"; };
        notify yes; 
};

    Alternatively, use an access control list: 
    acl "living-dead" { 63.127.146.192/26;  65.198.102.64/26; };
options {
      ...
        allow-recursion { living-dead; };                               
};
    The above combination will allow only the living-dead (and clients therein) to perform recursive queries.

Step 4: Change the System Startup Scripts.

  1. Modify /etc/rc.d/named to reflect the correct path for named. Also remove the '-g' option, which is not supported in ver. 9, if it's present. Make sure the named script is still executable and owned by root. 
     -rwxr-----  1 root root 906 Apr 1 14:34 named
  2. Modify /etc/rc.config and change START_BIND to "yes" (This only applies to SuSE Linux).
  3. Monitor for errors using the command tail -f /var/log/messages and try starting named by typing "/etc/rc.d/named start". The logfile should say something like this (this is a log from a slave server): 
         named: starting BIND 9.1.1 -u named
     named: using 1 CPU
     named: loading configuration from '/etc/named.conf'
     named: the default for the 'auth-nxdomain' option is now 'no'
     named: no IPv6 interfaces found
     named: listening on IPv4 interface lo, 127.0.0.1#53
     named: listening on IPv4 interface eth0, 11.111.111.195#53
     named: running
     named: refresh_callback: zone 222.222.22.in-addr.arpa/IN: \
        non-authoritative answer from 111.1.1.111#53
    This is different from the logs produced by the old bind: 
          named: starting.  named 8.2.3-T5B ... 8-8.2.3/bin/named
      named: hint zone "" (IN) loaded (serial 0)
      named: master zone "mittlenkampf.org" (IN) loaded (serial 1)
      named: master zone "0.0.127.in-addr.arpa" (IN) loaded (serial 1)
      named: slave zone "111.111.11.in-addr.arpa" (IN) loaded (serial 1)
      named: slave zone "222.222.22.in-addr.arpa" (IN) loaded (serial 1)
      named: listening on [127.0.0.1].53 (lo)
      named: listening on [11.111.111.195].53 (eth0)
      named: Forwarding source address is [0.0.0.0].1783
      named: group = named
      named: user = named
      named: Ready to answer queries.
    Make sure the correct bind is running. With bind 9, if any error is found, bind will not start up.

Step 5: Check its operation for a few days before announcing the new service.

  1. Check with nslookup to make sure the server can answer forward, reverse, and external queries.
  2. Shut down named by typing /etc/rc.d/named stop. It should say: 
     named: shutting down
 named: no longer listening on 127.0.0.1#53
 named: no longer listening on 11.111.111.195#53
 named: exiting
  3. Check the db files against their backups using diff. If there were no errors, the files should be only slightly changed. Named may change the files depending on the settings in named.conf. It is a good idea to re-check the files each time you restart named whenver a change occurs in your registration status.
  4. Go to the website of the company from which you purchased your domain name and register your DNS server with them.
  5. Next, contact the ISP that issued you the network address space and get them to register your name servers. Each domain must be registered with its parent. This is the often most difficult step, because many ISPs have trouble setting up DNS properly. Both of these steps are necessary for correct forward and reverse lookups.
  6. Change /etc/dhcpd.conf for your Windows and Mac users and tell your Unix users to change their /etc/resolv.conf to point to the new name server. Users who are getting their IPs using DHCP should be told to leave their entries for DNS servers blank. The nameserver should have itself listed in its /etc/resolv.conf file.
  7. Run the servers for a couple of days as slaves to make sure everything works perfectly before making them authoritative.
  8. Then, go to the Website of your domain name registrar and change the authoritative server to point to your primary server, and make your ISP's name server the secondary name server. Once you are certain your nameserver is working properly, all your users are using it, and the changes have propagated throughout the Net, then go to the Website again and substitute your secondary for the ISP's server. Finally, after a couple more days, contact your ISP and let them know that your server is now the authoritative one, and that they can remove their zone files. Don't add or delete any DNS entries from the time you start running a server until the ISP's server is actually dropped by INTERNIC (do a 'whois' lookup).
  9. Sign up for the bind-users mailing list, so you are informed if the named.root file from INTERNIC is changed.
  10. If you are running an OS that meddles with your resolv.conf file (such as SuSE Linux), edit /etc/rc.config to prevent it from being changed.

Problems

  1. Bind v.8 seems to die at random times. Solution: switch to v.9.
  2. Host hostname works but ping hostname gives hostname not found message. Solution: add 
      nameserver 111.111.111.11
    to /etc/resolv.conf on the nameserver, where 111.111.111.11 is the hostname of the server running bind. This is necessary even though the book says not to do this.

Maintenance

  1. If you change the zonefiles, be sure to increment the serial number so your slave servers will obtain the updated information.
  2. You should have bind running on at least two computers. If your nameserver goes down for a long enough time, it may take several hours after you restore them before people can reach you. If you are in a location where the electricity is frequently off for long periods, it may be better to let the ISP handle your DNS.
  3. Make certain to update both the forward and reverse zonefiles whenever you change anything.
  4. Don't make more than one master server or you will have to keep them synchronized.

Testing for lame delegation

  1. Check to make sure your delegation is not lame by running dnswalk. Having a lame delegation doesn't seem to hurt anything, but preventing your network from showing up in other administrators' logs as "lame" is reason enough to fix the problem.
  2. Find out what your nameserver is presenting to the public with the command 
     dig @ mynameserver.myisp.com mx mydomain.org
    In this example, only the MX records are checked.

Back