Originally Published: Monday, 16 April 2001 Author: Josh Boudreau
Published to: featured_articles/Featured Articles Page: 1/1 - [Printable]

Getting Started with Networking for Linux; Part 2: Configuring DNS for your network with BIND.

In the second part of Josh Boudreau's Getting Started with Linux Networking series Josh takes a look at DNS, the Internet's Domain Name System and walks us through configuring our own LANs to use DNS.

   Page 1 of 1  


Welcome to the second installment of the Getting Started with Networking for Linux series. In the first article we saw how to choose and install networking hardware and how to get started with the basics of TCP/IP configuration. If you're new to networking, I suggest you start there; in this article I assume you have the skills needed to get a network up and running.

Today we will see how to configure and setup DNS (Domain Name System) on your network, so you can refer to your computers as hostnames instead of boring IP addresses. If some of you following this series have experimented with the basic network services offered by your default Linux installation, you may have noticed that some services take a long time to respond, or might not work in a proper manner. This may be because many services work better when you have a working DNS server on your network. DNS offers hostname and IP address resolution, which some application require to work correctly.

DNS works by setting up a machine on your network to act as a DNS server. Other computers query the DNS server's database to resolve hostnames into IP addresses, and IP addresses into hostnames. DNS on Linux is usually handled by the BIND DNS server found at http://www.isc.org/products/BIND/. Most Linux distributions come with this package already installed. We will use BIND to setup our DNS server. The information you will gather from this article is applicable to other DNS server software, however, if you wish to experiment with other DNS software, you probably won't have too much trouble following along.

A Bit of Theory

In the old days, when the Arpanet was being developed, hostname lookups were handled by the file /etc/hosts. This file listed all the hosts on a given network and the file was kept synchronized across all hosts on that network. For instance, if a machine needed to know the IP address of a particular host it would query its local /etc/hosts file. As you imagine, as the Arpanet grew, and then the Internet started to take its place, this method of keeping hostnames and IP addresses in sync between all hosts became inefficient.

This arcane system was replaced by the Domain Name System, which we still use today. In the DNS system you have one server on the network that holds the hostname/IP database for all hosts on that network. Computers query this DNS database to do the translations. As you probably know, the Internet is composed of multiple networks connected together and each network is responsible for handling the task of setting up its own DNS server for each domain. With this system, changing the IP addresses on a network requires only changing the information on the network's DNS server, other machines on remote networks are not required to change anything and the next time they query information from the updated DNS server they'll get the new information.

How it Works

DNS is implemented in a hierarchical system. If you look at a domain name you'll notice that it has several parts separated by dots:


com = top level domain
linux = domain name
host = hostname of machine

When a machine requests a DNS lookup on a particular hostname, the request first goes to the root DNS server handling the top level domain. The root server will then redirect the request to the DNS server handling the database for the particular domain requested. When our request reaches that DNS server, we might get our answer right away or we may be redirected to yet another DNS server if the hostname we requested has multiple levels. A hostname with multiple levels is when a network administrator divides his network into subnets and follows a naming convention for the machines on those subnets. This naming convention is not required but is often very usefull for helping users find machines on a network. As an example, a company might have two subnets and each has a DNS server handling the DNS information for a subnet.

The diagram below show how a request for www.linux.com might travel down the DNS tree. First the root server handling .com domains is queried. This server knows which server has the linux.com database. Our request is then sent to the linux.com DNS server which knows the IP address of www.linux.com. Another example would be to request the address of bob.staff.linux.com. In this case the request would follow the same path, but when we reach the DNS server for linux.com, our request would be sent to yet another server that handles hostnames under staff.linux.com which will know the IP address of bob.staff.linux.com. To follow this multiple level hostname naming convention, a second DNS is not really required and one DNS server can handle the task. This scheme of using more than one DNS server is often put into use by large networks where a few administrators are responsible for only a subnet and not the whole network.

Configuring BIND

Most distributions of Linux come with BIND already installed, but if your system doesn't already have it you can probably find a precompiled version that's packaged for your Linux distribution. If you can't find a precompiled package you can always download the source code and compile it yourself. Follow the example below to extract the source, and build it.

tar zxvf bind-x-x-x.tar.gz
cd bind-x-x-x
make install

When running the ./configure command there are other options you can choose to customize the compilation. You can list these options with ./configure --help. For example you might want to change the default installtion directory /usr/local/ to /home/user with ./configure --prefix=/home/user. All those options are covered in the BIND documentation distributed with the source code, but most of the time the default options are fine for most people and I wouldn't worry too much about them exept maybe the --prefix to decide the installation directory. Once the configuration script has finished, running make will build the source. The make install command requires root access since it needs to write to install the files.

Configuration Files

When you have BIND installed, there are a few configuration files we should edit before starting the server. The first file we will look at is the BIND configuration file, which is by default installed in /etc/named.conf. This file is used to set various options including the list of which domains our DNS server will serve. Since we're about to edit the configuration files, you should know which domain you're going to use for your network.

Note: An important thing to understand at this point is that the domain you choose will not be used on the Internet. This article aims at setting up BIND for a private network, and therefore our BIND configuration will not serve DNS requests to or from the Internet. Domain names on the Internet must be registered with the registrar selling domain names for a particular top level domain. Since in future articles we will learn how to get your network connected to the Internet, I advise you not to choose a real domain. In our example configuration we'll use a domain name ending with .lan which is non-existent on the Internet. I suggest you do the same, or pick another top level domain that doesn't already exist. If your domain is going to be used publicly on the Internet you will need to register a real domain name and have the registrar forward requests to your DNS server, but we won't cover that kind of setup in this article.

So let's have a look at /etc/named.conf. If this file doesn't exist yet you should create it. To start off, I'll list what you should have in there, and then I'll explain the syntax.

options {
directory "/var/named";

zone "domain.lan" in {
type master;
file "zone-domain.lan";

zone "." in {
type hint;
file "root.cache";

zone "0.0.127.in-addr.arpa" in {
type master;
file "rev-127.0.0";

zone "1.168.192.in-addr.arpa" in {
type master;
file "rev-192.168.1";

There are few things to look at here, the option entry has one subentry which is the directory where we will be storing our domain configuration files. The /var/named directory is the most commonly used, but you may point to any directory you wish to store the files. After that there are 4 zone entries. One for our domain "domain.lan" and it says we are the master server for that file, and its configuration file is in "zone-domain.lan". We specified type master because we are the only DNS server responsible for our domain. If we were to have two DNS servers handling the same domain we could specify the second one as type slave. BIND has features for transfering DNS zone files and keeping in sync between master and slave servers, in this example we only have one master server.

The next zone entry is for the root servers responsible for the top level domains. The two last zone entries are for reverse lookups. Reverse lookups are when we lookup which hostname is associated with an IP address. One entry is for our loopback addresses which are 127.0.0.* and the other is for our network's IP addresses, which are 192.168.1.*. If your network doesn't use those addresses change the zone entry to reflect your network's setup. Note that in the zone entry lists the IP range in reverse order, that is 192.168.1.* is 1.168.192. The reverse zone entry for loopback addresses should be left alone because it's the same for every network.

To get more information on the different features you can specify in your named.conf file, typing man 5 named.conf at the shell prompt will give you a nice big list. With that done, we can start putting together our configuration files for our domain, theseare usually called zone files.

Like our named.conf file indicated, we should put them in the /var/named/ directory, if this directory doesn't exist yet, just create it. The directory should be read/writable by the owner and group, so doing chmod 770 /var/named should set the appropriate permisions. The first one we will do is the root.cache file since we aren't really responsible its content. Most BIND distributions come with this file. You should use the one sent with your BIND package, since it will probably be the most recent copy. If you don't have one here's what should be in it.



This file lists the root servers on the Internet. We are not responsible for this list, and if root servers ever change, an updated file will be distributed with the latest BIND distribution. The root server IP addresses will probably not change very often, so I would say you're safe using the example file I listed above. You might be wondering why we need this file if our domain is not going to be served on the Internet? The file is required because our DNS server will forward our computer's requests to a DNS server located on the Internet. Like we saw before, domain names on the Internet are handled by the root servers, and when we will see how to get your network connected to the Internet in future articles, your DNS server will probably get requests for valid domains that your computers will want to connect to.

Your DNS server only handles the database for your domain and it will forward all your requests for others to the Internet. If your network is already connected to the Internet and you want to have your DNS server forward your requests to the Internet, you can add a forwarders { IP_of_ISP's_DNS; }; line to the option entry in /etc/named.conf. By having your server forward the requests, you won't have to include your ISP's nameservers in /etc/resolv.conf. Our option entry would look like the following with your ISP's nameservers as forwarders:

options {
directory "/var/named";
forwarders {;; };

Where and are the namesevers your ISP provided you.

The next file we should create is the zone file for the domain we chose. In our /etc/named.conf we specified zone-domain.lan as the file. You should create the file you specified and use the your domain instead of this example domain. The syntax for the zone file is a bit complicated and you should pay attention to every detail. I'll list the content of the example zone file for domain.lan and explain it

domain.lan. IN SOA ns.domain.lan. root.domain.lan. (
1D )

domain.lan. IN NS ns.domain.lan.
domain.lan. IN MX 10 mail.domain.lan.

localhost.domain.lan. IN A

ns.domain.lan. IN A
www.domain.lan. IN A
ftp.domain.lan. IN A
mail.domain.lan. IN A
josh.workstation.domain.lan. IN A
julie.workstation.domain.lan. IN A

Take a look at the syntax line by line and I'll explain the structure of this zone file. Please note that the hostnames have a trailing dot and this is very important. Leave them out and your zone file won't work properly. The first line gives the DNS server some information about itself:, "ns.domain.lan" is the name of the DNS server, and "root.domain.lan" is the email address of the administrator. Instead of using the "@" sign in the email address it's just a dot, the address above would be translated to root@domain.lan. The numbers after the first line set a few parameter options like the time a DNS request expires and such. I won't explain those in details so just use the ones in the example because they are sufficient for a DNS server on a private network. The next line lets machines know which DNS server handles the zone for domain.lan, "ns.domain.lan" is the DNS server's name. The next line tells us which address handles mail for that domain. If your network doesn't have a mail server just leave this line out. All the lines with "IN A" assign hostnames to addresses.

In the example file we assigned localhost.domain.lan to, our local IP pointing back to our computer, is called the loopback address and it always points to your local computer. After that we assign a few other hostnames to computers on the network that will be assigned these hostnames.You can use any names you want for your computers, those names only serve as an example.

The only files we have left to configure now are the reverse zones for 127.0.0.* and 192.168.1.*. These files are quite similar to the zone-domain.lan file but instead of mapping hostnames to IP addresses, we will map IP addresses to hostnames. Here's a listing of the rev-192.168.1 file in /var/named.

@ IN SOA ns.domain.lan. root.domain.lan. (
1D )

@ IN NS ns.domain.lan.

1 IN PTR ns.domain.lan.
2 IN PTR www.domain.lan.
3 IN PTR ftp.domain.lan.
4 IN PTR mail.domain.lan.
10 IN PTR josh.workstation.domain.lan.
11 IN PTR julie.workstation.domain.lan.

As you can see, the top portion of the file is the same as our zone-domain.lan file. The only difference between the files is in the bottom part. In the zone-domain.lan file we listed "hostname IN A ipaddress", but in this file we put "ipaddress IN PTR hostname". The first row is really an IP address but we leave out the 192.168.1 part since our server already knows this is the file responsible for mapping the IP addresses in this range. We only need to put the host portion of the address. For example the line with a 1 would expand into when read by the server. The last row, as you probably guessed, is the hostname associated with that IP address.

Finally, we need the file for the reverse lookup of the loopback addresses, which is rev-127.0.0 as specified in /etc/named.conf. Here's a listing.

@ IN SOA ns.domain.lan. root.domain.lan. (
1D )

@ IN NS ns.domain.lan.

1 IN PTR localhost.

This file only maps one IP address ( to localhost. This is the only entry you need for this file and is only needed by applications that use to talk to the computer they are running on.

Getting Ready to Start the DNS Server

Before starting BIND, we should change a few settings to tell our computers where to query our DNS server. On Linux this setting is in the /etc/resolv.conf file. This file lets applications know where to fetch DNS information from. You should add your DNS server's IP address in there. If there are already a few listed, just add your DNS to the top of the list so applications will query your server first. An example /etc/resolv.conf would be:

search domain.lan

The search line tells applications which domain should be searched if the domain.lan is omitted from the request. For example, if we do "nslookup www", the request would be translated as www.domain.lan. This is optional and is only used for shorthand when looking up hostnames. The nameserver lines list the IP addresses of the available DNS servers. The /etc/resolv.conf file needs to be setup appropriately for each computer that will be using the DNS server. On Microsoft Windows this setting is changed in the Network Applet inside the control panel.Note that each computer must set which server to fetch DNS data from in the /etc/resolv.conf file, but not all computers need to run the BIND software.

Once everything it configured correctly it's time to start up the DNS server. Most DNS server programs are called '"named" and this is correct for BIND's software distribution. Starting up the server is just a matter of running named. Once named is run it probably won't output anything to your terminal, it will just put itself in the background and serve incoming DNS requests. Logging info will most likely be appended to the /var/named/messages log file. If you wish to see these messages, switch to another terminal and type tail -f /var/log/messages and start named in the other window. If any errors occur additional entries will be appended to the other terminal. To stop viewing logging messages just hit CTRL-C in that terminal. If you get errors while named is starting it's most likely to be a syntax error in your zone files since they are pretty strict. Check every hostname listed and make sure there is a trailing dot after its entry.

If you make any changes to your DNS server's configuration files, you will need to restart named, you may do so by typing killall -HUP named as root. This will make named re-read its configuration files.

Testing your Configuration

To test the configuration of DNS on your network we can use the nslookup utility. Simply type nslookup www.domain.lan and it should return the IP address of that hostname. An example output listing of the nslookup utility should look similar to this:

ns.domain.lan Address:

Name: www.domain.lan

This output tells us that the server ns.domain.lan is handling our request, and this server has an IP address of The second part of the output tells us the result of the lookup; www.domain.lan has an IP address of I suggest testing this on each machine to see if each computer is able to resolve hostnames on your network. To do a reverse DNS lookup just type nslookup ipaddress and it will tell you which hostname that IP address has.


Now that DNS is up and running on your network you can refer to other computers by their hostnames instead of typing in their IP address. DNS resolution works with every network utility, for example instead of typing telnet to login to the computer at you can type telnet hostname and you should be able to reach that computer with no problems.

Adding more hostnames is just a simple task of adding more entries in your domain zone files and restarting BIND. If you wish to add more domain names to your DNS server you just need to add additional zone entries in the /etc/named.conf and create the corresponding zone files in /var/named. After adding more domains just restart named and the new domains should be active across your network.

This article showed you the steps to configure a small and simple DNS server for a private network and this is usually sufficient for most people. Every aspect of the Domain Name System would be too lengthy too cover herebut if you wish to know more I suggest getting a book on the topic. Below are some additional online resources that you may help you to learn some more on how DNS and BIND works.

   Page 1 of 1