A look at DNS (part 1)

By: L33tdawg

Back in the days when the Internet was nothing more than a
glorified project by the Department of Defense known as Arpanet,
there were few enough hosts that they could all be listed in text
files stored on each inter-connected hosts - I'm talking about none
other than the /etc/hosts file - back then the file served its
purpose, containing a list of the names of all the computers on the
network and associated those human readable names with their machine
readable IP addresses. So when a person typed in any computer name,
that system's matching IP address could be instantaneously looked up
in /etc/hosts. Well that kind of system would be totally unmanageable
in today's world, what with the huge number of hosts and domains on
the Internet, where its estimated that each day, more than 50,000 new
domain names are registered. The Domain Name Service (DNS for short)
is essentially a huge conga line of servers (called name servers)
snaking through the Internet. FOr any computer connected to the Net,
a given DNS server can provide you with that computer's host name and
IP address information or the server knows how to find other name
servers that will have that information. So DNS does a tremendous
amount to simplify domain name management on a global scale.

More recently though, DNS has become relevant to make more users
as they gain access to high speed network connections via cable or
DSL. If you're thinking about building an internal LAN to take
advantage of that fast network connection then you've just become and
instant system administrator (sort of) and you'll need to work with
DNS. Having a working understanding of DNS is crucial - luckily
though, its pretty straightforward and the learning curve isn't steep
at all. Creating the files used by DNS, starting one or more DNS
servers, and configuring how, when and if your systems use DNS is
easy, especially under Linux. In this article, I'm going to give all
of you a general overview of a DNS system, how its implemented on
Linux, and how to configure it. Lets get to it then.

DNS allows computers on a network to access other computers using
human-readable names. In a nutshell, DNS servers translate the names
we all know on the Internet into the IP address that machines
actually use to communicate. All of the hosts on your network can
query one or more local DNS server for local host name and IP address
information. Requests for host name and IP address information
outside the administrative domain of your DNS servers are
automatically passed up the DNS food chain until some DNS server can
provide the requested information. Each domain on the Internet must
have at least two name servers, for redundancy sake. It's best if
these servers are placed on different networks so the domain can
still be found even if one network is down due to hardware or
software failure. These tow servers are referred to as the primary
and secondary name servers. A domain can have more than two servers
if desired - the more the merrier really. These servers are called
authoritative servers for the domain, meaning they are the source
(authority) for "name" information on those networks. A
non-authoritative DNS server is one that has cached the information
for a domain. So if you ask your ISPs name server for the address for
freelinuxmail.com, it can give you a non-authoritative response. But
if you want to be sure you have the most up to date host information
for the domain, you would need to go to the authoritative server. At
the top of this food chain are a bunch of servers that are called
Internet "root" name servers (as in the "root" of
the whole system).

The root name servers will send a requests for name information to
a primary name server first, since a primary name server should
contain the master name table for that domain. Primaries are
configured as domain master servers. Any secondary servers may be
configured as slave servers. The slaves automatically check for
updates on the master server, so that administrators only need to
maintain one host database. So how does DNS work its black magic? Say
you want to check out Hack In The Box. Well, you fire up your web
browser, and enter the address http://www.hackinthebox.org. In a
typical configuration, your computer fists check the local /etc/hosts
file to see if that server name is listed. If not, then it tries to
find out the proper address by using DNS. Your computer now looks at
your network's local DNS server list (typically provided by your ISP)
and sends its request to the first server on that list. That name
server checks its local database to see if it has the IP information
for www.hackinthebox.org cached. If it doesn't, it then passes the
request up the DNS chain to one of the root name servers on the
Internet. That server knows the authoritative DNS servers for every
domain on the Net, and passes the request off to the primary DNS for
the hackinthebox.org domain (ns.tele-matrix.com). That server DOES
have the IP address (203.106.21.47) and returns that information to
your computer. At last, your browser can send its request directly to
hackinthebox.org use its IP address. The name server software used on
the vast majority of name servers on the Internet is Berkeley
Internet Name Domain (BIND). This is the software that comes
preinstalled with most Linux distributions. It includes the name
server (named), a library for those who wish to add DNS capabilities
to software they develop and DNS client tools such as nslookup and
nsupdate.

Relatives of DNS

Before diving into an explanation of what makes DNS tick, its
worth pointing out that there are other systems that were designed to
tackle the problem of associating host names with numeric addresses
on a network, and many of them are still in use. In the beginning,
there were /etc/hosts files located on each system, and that was
okay. However, when an internal network grows quickly, the time
required to maintain identical /etc/hosts files on all of your
systems quickly becomes a major pain, so other methods of keeping
track of what's what was invented. Sun Microsystems invented a
network oriented file sharing solution it named Network Information
Service - NIS. NIS eventually grew up and spawned a successor, NIS+,
NIS and NIS+ work by storing central versions of critical files like
/etc/group /etc/shadow, and /etc/passwd on a NIS or NIS+ server.
Those files are then provided to that server's client systems as
requested. The problem with NIS and NIS+ is that they aren't always
suitable or usable because they don't always play well together with
all types of computer systems. Linux DNS files The configuration
information for the named name server is contained in a number of
different files. These files include nsswitch.conf, resolv.conf,
named.conf, named.ca and named.local, as well as the domain specific
files like jaring.my. Let's take a brief look at each one and some
configuration examples.

The Name Server Switch Configuration File

As we mentioned earlier, DNS is only one possible system for
mapping names to network addresses. Other methods include /etc/hosts
files, NIS and NIS+. The file /etc/nsswitch.conf defines the order in
which those methods should be attempted. Here's how an entry of hosts
information in the /etc/nsswitch.conf file looks on my box :

hosts: files dns [NOTFOUND=return] nisplus nis

What precisely does this mean? Well it tells any program wishing to map a
name to a number to
look up the /etc/hosts file first, if the entry is not found there,
then use dns, if that fails as well and a host is not found in either
of these mechanisms, then give up. Any method listed after the
[NOTFOUND=return] will not be used. Thus on my machine, I don't want
any programs to use the nisplus or nis mechanisms as I don't run
those on my machines.

The resolv.conf Configuration File.

Whether or not it is running a name server, if your Linux box uses
other name servers, it needs to know where to find them. This is
where the /etc/resolv.conf file comes in. It contains a listing of
the names servers that the machine should use to look up addresses
(usually provided by your ISP), as well as which domain names to
search for hosts in if the request does not include a domain. A
typical /etc/resolv.conf file looks like this: search jaring.my
nameserver 192.228.128.20 nameserver 192.228.128.18 The lines in this
file are pretty self explanatory. The first lines defines the search
domain (jaring.my) and the net two lines define which name servers
should be used to look up IP addresses.

The named Configuration File

Name serving on Red hat Linux systems is done by a program called
named, which is part of the BIND package for UNIX/Linux systems. The
name daemon (named) uses the configuration file /etc/named.conf to
identify the files that it should use to populate the local name
service database. The file is broken up into zones and options. Thename daemon (named) uses the configuration file /etc/named.conf to
identify the files that it should use to populate the local name
service database. The file is broken up into zones and options. The
options section identifies the directory where the files for the
local DNS servers are found /var/named. The zone section identifies
each area of responsibility that the DNS server knows about and the
files associated with that area. These files are located in the
directory defined by the directory option. The named.ca is the local
cache of the highest-level DNS servers on the Internet - the
so-called root name servers if you will). The file named.local
contains authoritative information for any hosts that you can access
thorough the current host's loopback network interface. It normally
contains just one host entry, localhost.

Well I'm feeling kind of tired and lazy right about now - so I'm
going to break this article up into two parts. Next month, I'll wrap
things up and really get into the configuration of the DNS files and
other little bits for your system.

Till then - have fun.

Peace.

L33tdawg

1.) Interview
with Hacker (the anti-MPAA web defacer - madirish

2.) Dreamcast
Hacking - 101bytz

3.) Setting Up
Your Own Mail Server - madirish

4.) A look at
DNS (part 1) - L33tdawg

5.) PC Be With
You - Joel Garreau