Introduction
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:
host.linux.com
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
./configure
make
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.
. 6D IN NS G.ROOT-SERVERS.NET.
. 6D IN NS J.ROOT-SERVERS.NET.
. 6D IN NS K.ROOT-SERVERS.NET.
. 6D IN NS L.ROOT-SERVERS.NET.
. 6D IN NS M.ROOT-SERVERS.NET.
. 6D IN NS A.ROOT-SERVERS.NET.
. 6D IN NS H.ROOT-SERVERS.NET.
. 6D IN NS B.ROOT-SERVERS.NET.
. 6D IN NS C.ROOT-SERVERS.NET.
. 6D IN NS D.ROOT-SERVERS.NET.
. 6D IN NS E.ROOT-SERVERS.NET.
. 6D IN NS I.ROOT-SERVERS.NET.
. 6D IN NS F.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4
J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10
K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129
L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12
M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33
A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4
H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53
B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107
C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12
D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90
E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10
I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17
F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241
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 { 192.168.1.30; 192.168.1.40; };
}
Where 192.168.1.30 and 192.168.1.40 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. (
1
3H
1H
1W
1D )
domain.lan. IN NS ns.domain.lan.
domain.lan. IN MX 10 mail.domain.lan.
localhost.domain.lan. IN A 127.0.0.1
ns.domain.lan. IN A 192.168.1.1
www.domain.lan. IN A 192.168.1.2
ftp.domain.lan. IN A 192.168.1.3
mail.domain.lan. IN A 192.168.1.4
josh.workstation.domain.lan. IN A 192.168.1.10
julie.workstation.domain.lan. IN A 192.168.1.11
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 127.0.0.1, our local IP pointing back
to our computer, 127.0.0.1 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. (
1
3H
1H
1W
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 192.168.1.1
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. (
1
3H
1H
1W
1D )
@ IN NS ns.domain.lan.
1 IN PTR localhost.
This file only maps one IP address (127.0.0.1) to localhost. This is the only entry you need for this file and is only needed by applications that use 127.0.0.1 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
nameserver 192.168.1.1
nameserver 192.168.1.30
nameserver 192.168.1.40
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:
Server:
ns.domain.lan Address: 192.168.1.1
Name: www.domain.lan
Address: 192.168.1.2
This output tells us that the server ns.domain.lan is
handling our request, and this server has an IP address of 192.168.1.1.
The second part of the output tells us the result of the lookup;
www.domain.lan has an IP address of 192.168.1.2. 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.
Conclusion
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 192.168.1.1 to login to the computer at
192.168.1.1 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.