From Debian Clusters

This is the second page of a five part tutorial on setting up Name Service: DNS and BIND. The full tutorial includes

• Name Service: DNS and BIND
• Installing and Configuring BIND
• Creating Forward DNS Records
• Creating Reverse DNS Records
• Testing and Troubleshooting BIND

Installing Bind 9

The first step in setting up the DNS server is to

apt-get install bind9

Then go ahead and run ps aux | grep named to make sure that the service started successfully (named is the name of the Bind daemon). If not, check /var/log/syslog for errors.

/etc/bind/named.conf.options

This is the file that specifies how the DNS server works. Even though you should be running this on the internal network, behind a firewall, there are a couple of "good practice" habits to add to this file. Within the options brackets of this file, below any existing entries, add the following:

   version none;
   allow-query { address1; address2; etcetera; };
   allow-transfer { none; };

• version-none tells the server not to respond with the Bind version when queried (such as when being queried by dig). The version can also be specified in quotes. Since there are version-specific Bind exploits, it's just a generally good idea not to give out the version for free.
• allow-query specifies which machines are allowed to use this nameserver for lookups. Again, this probably won't be an issue because the server should be behind a firewall and not advertising on the general Internet, but it's still a good practice. Add your machines instead of "address1; address2; address3"; I'm specifying mine with 192.168.1.0/24. (On the other hand, if you were running this nameserver for a domain name on the internet, you'd want to allow queries from anyone trying to get to your site, so you wouldn't want this option!)
• allow-transfer specifies the machines that are allowed to download all of the zone information (all of DNS information, basically, about which IP addresses go to which domain names, and vice versa - more about zones in the next section). If you're running any slave nameservers, you'll want to add their information here, because they need to be able to download all the information. Without this option, any old server would be able to download all of the information, which is a security risk.

Here's what mine looks like, after I took out all the developer comments (be sure to make a backup if you do this!). The first three lines in options were already automatically added.

options {
        directory "/var/cache/bind";

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };

        # Added - KW
        version none;
        allow-query { 192.168.1.0/24; };
        allow-transfer { none; };
};

There are a few important points about syntax here - and Bind is very particular about syntax! It will fail if you have any syntax errors. (tail /var/log/syslog if refuses to start for pointers to which lines on which files are the problem.) Semicolons are used to end a statement or option. This means everything from options within brackets (notice mine has a semicolon after 192.168.1.0/24) to ending brackets. Bind is pretty good about printing readable errors about missing semicolons:

eyrie:/etc/bind# /etc/init.d/bind9 restart
Stopping domain name service...: bind.
Starting domain name service...: bind failed!
eyrie:/etc/bind# tail /var/log/syslog
Jun 29 00:38:42 eyrie named[2870]: starting BIND 9.4.1 -u bind
Jun 29 00:38:42 eyrie named[2870]: found 1 CPU, using 1 worker thread
Jun 29 00:38:42 eyrie named[2870]: loading configuration from '/etc/bind/named.conf'
Jun 29 00:38:42 eyrie named[2870]: /etc/bind/named.conf.options:9: missing ';' before '}'
Jun 29 00:38:42 eyrie named[2870]: loading configuration: failure
Jun 29 00:38:42 eyrie named[2870]: exiting (due to fatal error)

As shown above, to test your changes to the file, restart bind with

/etc/init.d/bind9 restart

/etc/bind/named.conf.local

This is where you declare your "zones". On the Internet, zones usually refer to groups or single domains or subdomains. (For instance, debianclusters.com might be a zone, including subdomain1.debianclusters.com and subdomain2.debianclusters.com). That being said, unless you're running multiple networks (through multiple switches), you'll probably only have two - one for forward DNS and one for reverse DNS.

There's more about that in the next section. For now, know that you'll need two files (for each domain/IP address).

First, you'll need one for the internal domain name. I've been using raptor.loc in my examples. This is the name of the zone. When creating the file for that zone, the convention for file naming is to typically put db.<name> (so I'm naming mine db.raptor.loc), but technically the name doesn't matter except for readability.

The second file is for the IP addresses for reverse lookup. Because of the way reverse lookup is conducted, the way this domain is declared is by taking the IP address, reversing the order of the sections, and then appending .in-addr.arpa. For example, the zone name for my 192.168.1/24 becomes 1.168.192.in-addr.arpa. I'll call that file db.1.168.192.

My /etc/bind/named.conf.local is below. There's also an example of a named.conf.local file for a cluster that's running three IP ranges on different switches.

zone "raptor.loc" {
        type master;
        file "/etc/bind/db.raptor.loc";
};

zone "1.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.1.168.192";
};

The next step is to begin creating these files. Continue on to Forward DNS - Name to IP Address (db.yourdomain)!