Before we start, you will need a linux box with ISC-BIND installed. For this tutorial I will be using CentOS 4.4 with the following packages installed.

• bind-9.2.4-24.EL4
• bind-chroot-9.2.4-24.EL4
• bind-libs-9.2.4-24.EL4
• bind-utils-9.2.4-24.EL4
• caching-nameserver-7.3-3

If you are using CentOS or any other linux that uses YUM (Yellowdog Updater Modified) package management you can install the packages by using the following command:

yum install bind bind-chroot bind-libs bind-utils caching-nameserver

If your bind/named is installed without the bind-chroot package, you will find it in /etc/named.conf, otherwise you will find it in /var/named/chroot/etc/named.conf. For the rest of this article I will only refer to this file as named.conf, so make sure you remember the correct location of the file.

I will not be going into great detail of what can be done in the named.conf file so if you want to do anything advanced with it I suggest getting a book that covers isc-bind and reading the manual page for named.conf by typing ‘man named.conf’ at your shell prompt. Now, with that said, open up your named.conf in your favorite editor and find the line that says

directory "/var/named";

this is the location that named will look for the files we will create later for your domain(s), so change this if you want them to be stored in a different location, but the default should be fine for mostly everyone. I should also note that this path does not need to be inside the chroot/ folder if you are running bind in a chroot environment because these files are read before the chroot takes place.

Now… one thing that I normally do, which is not done by default in named.conf, is masquerade the version response that named will return to clients. This is so people can not determine what version of the software we are running. You can do this by adding something like the following directly below the ‘directory’ line mentioned above.

version "You have got to be kidding...";

You can test that this is working correctly by using the following command at a shell prompt (after your bind server has been rehashed/restarted)

dig @your.dns.server.address.com txt chaos version.bind

For now, you can save and close the named.conf file until later. After saving your changes, reload your named server config using the following command

rndc reload

Creating The ZONE File

The purpose of the zone file is to tell dns servers what the IP address of a host is. This is for hostname->ip conversion only. The DNS server will “not” be able to convert the ip->hostname without having a matching ARPA record (which will be discussed in the next section).

Before we get started, make sure you know the following information

• what is the domain name you want to create. (eg. funky.lan)
• who is the dns administrator. (eg. snoo@gmail.com)
• what is the host name you want for this dns server. (eg. ns.funky.lan)
• what is the address of the mail server for this domain (not required but nice).
• what host names do you want/need.

Next you will create the zone file for the domain, you will need to create this inside of the folder you set with the directory option earlier. Usually what I do is create a folder with the domain name that I am creating inside of that folder, for example:

mkdir /var/named/funky.lan/

Then create a new file inside of that folder named zone, which will hold the zone information. The following is an example zone file

$ORIGIN funky.lan.
$TTL 86400
@             IN SOA ns.funky.lan.  snoo.gmail.com. (
                                                   1          ; serial #
                                                   3H         ; refresh time
                                                   15M        ; retry time
                                                   1W         ; zone expiry time
                                                   1D )       ; minimum

                                          ; DNS Servers for this domain
                                          IN NS      ns.funky.lan.

                                          ; Mail servers for this domain
                                          IN MX 10   mail.funky.lan.

                                          ; ip address of just funky.lan
                                          IN A       192.168.1.1

localhost         IN A      127.0.0.1

ns                IN A      192.168.1.1
mail              IN A      192.168.1.2
www               IN A      192.168.1.3
ftp               IN CNAME  www

Okay… a breakdown of the important information above, first the following

@             IN SOA ns.funky.lan.  snoo.gmail.com. (

that line means, the records for the domain ‘funky.lan’ can be found on the domain server running at the address ‘ns.funky.lan’, and the domain administrator for this particular domain is ’snoo@gmail.com’, please note that it correct that the @ is specified as a . in the zone record, using an @ will be invalid.

Next is the ‘very important’ serial number line

1          ; serial #

Every single time you change the zone file, you will have to increment this number by 1, so the next time this file is changed, you will change the 1 to a 2, then the following time to a 3, etc. This lets the domain servers know that the records for this domain have changed and they need to update their records as well. If you fail to change this number then any changes to the zone file will go unnoticed.

The next part of the zone file is pretty straight forward.

                ; NS Servers
                IN NS           ns.funky.lan.

                ; Mail Servers
                IN MX 10        mail.funky.lan.

                IN A            192.168.1.1

The NS servers are the domain name servers (dns servers) that are responsible for this domain. This line can appear more than once for the domain, and in fact needs to be there more than once if you have a secondary (slave) dns server for the domain. For example

  IN NS ns.funky.lan.
  IN NS dns2.funky.lan.
  IN NS dns3.funky.lan.

Next we have the Mail Servers (MX), these lines are slightly different because they have a priority number after the MX keyword. This is only important if you have more than one mailserver, but it still needs to be there. The priority number means in which order should the mailservers be tried if the previous one fails to respond. As with the NS records, this can also be used multiple times for backup mailservers. example:

  IN MX 10  mail.funky.lan.
  IN MX 20 mail2.funky.lan.
  IN MX 30 mail3.funky.lan.

This means any email that is sent to user@funky.lan will tried to be sent through the mail servers mail.funky.lan, if this server fails to respond, then mail2.funky.lan will be tried next, then if that fails, mail3.funky.lan will be tried.

The IN A record (the one just below the MX records) means that the domain ‘funky.lan’ by itself will resolve to 192.168.1.1.
And finally the easiest part of the zone file, the A records, these are the host->ip addresses that we want for the domain.

localhost         IN A      127.0.0.1
>>> localhost.funky.lan will have the ip address 127.0.0.1

ns                IN A      192.168.1.1
>>> ns.funky.lan will have the ip address 192.168.1.1

mail              IN A      192.168.1.2
>>> mail.funky.lan will have the ip address 192.168.1.2

www               IN A      192.168.1.3
>>> www.funky.lan will have the ip address 192.168.1.3

ftp               IN CNAME  www
>>> ftp.funky.lan will have the same ip address as www.funky.lan ... which is 192.168.1.3

I hope the above makes sense, it is pretty straight forward. Now save and close that file.

Creating The ARPA File

The purpose of the ARPA records is to tell dns servers what the hostname of an IP address is. These records are for ip->hostname conversions only. The DNS server will “not” be able to convert the hostname->ip without having a matching A record in the zone file (which was discussed in the previous section).

The ARPA file should be found in the same folder as the ZONE file (not really necessary but good practice), and is VERY similar to the ZONE file. The first thing you need to understand is that an ARPA records use the IP address reversed. So read everything backwards, if your lan is 192.168.1.* then the arpa records are written as 1.168.192.in-addr.arpa.

The following is an example ARPA file, please make changes as necessary.

$ORIGIN 1.168.192.in-addr.arpa.
$TTL 86400
@             IN SOA ns.funky.lan.  snoo.gmail.com. (
                                                   1          ; serial #
                                                   3H         ; refresh time
                                                   15M        ; retry time
                                                   1W         ; zone expiry time
                                                   1D )       ; minimum

                                          ; DNS Servers for this domain
                                          IN NS      ns.funky.lan.

                                          ; Mail servers for this domain
                                          IN MX 10   mail.funky.lan.

1                 IN PTR    ns.funky.lan.
2                 IN PTR    mail.funky.lan.
3                 IN PTR    www.funky.lan.

So .. as you can see, it is VERY VERY similar to the ZONE record, except a ZONE record holds ‘A’ records (host->ip), and the ARPA file holds the PTR records (ip->host). Every host that has an ‘IN A’ record in the ZONE file should have an ‘IN PTR’ record in the ARPA file. It is also important to point out that ‘IN CNAME’ records in the zone file “do not” get an ‘IN PTR’ record in the arpa file, because ‘IN CNAME’ is just an alias (another name) for the host specified on the right-hand-side of the record.

As with the zone file, every single time the arpa file is modified, the serial number MUST be incremented by 1.

Adding the domain to named.conf

Now that you have created your first zone and arpa files, you now need to add the records to named.conf so our named (bind) server knows they are there.

Now.. open up your named.conf file and add the following to the end of the file (making changes to reflect your domain)

zone "funky.lan" {
        type master;
        file "funky.lan/zone";
        allow-update { none; };
        allow-transfer { none; };
};

zone "1.168.192.in-addr.arpa" {
        type master;
        file "funky.lan/arpa";
        allow-update { none; };
        allow-transfer { none; };
};

Restarting BIND and Testing Everything

Now that we have done everything, it is time to do a little testing. First, make sure that you restart named. If your Linux distribution has the service command, then use that.

service named restart

If not try the following command

/etc/rc.d/init.d/named restart

If all that fails reboot the box so that named re-starts in the correct manner for your system, or you can try:

killall -9 named
/usr/sbin/named

Now that your named server was restarted, check the hosts that you defied by querying the address of each host/ip.

dig @ns.funky.lan www.funky.lan
dig @ns.funky.lan ftp.funky.lan
dig @ns.funky.lan mail.funky.lan
dig @ns.funky.lan 192.168.1.1
dig @ns.funky.lan 192.168.1.2
dig @ns.funky.lan 192.168.1.3

If any of the above fails, re-check everything.