1.

INTRODUCTION

Nothing has changed the world as much as the Internet. And an important
aspect of this technology is the DNS (Domain Name Server). DNS is one of the
Internet’s fundamental building blocks. It is a distributed host information
database that’s responsible for translating named into addresses, routing mail to
its proper destination, and many other services. To be specific, DNS converts
machine names to IP address that all machines have on net. It translates (or
maps) names to IP address and IP addresses to names, and also some other
things. A mapping is simply an association between two things, in this case a
machine name like www.recjai.com, and the machine’s IP number (or address)
210.212.99.163. DNS also contains mapping the other way form the IP number
to machine name. This is called reverse mapping.

Before understanding DNS it is important to know a little about the history of

Internet and history of Domain Name System.

1.1 History of Internet

In the late 1960s, the U.S. department of Defense’s Advanced Research

Projects Agency, ARPA (latter DARPA), begun funding an experiment wide
area computer network that connected important organization in the U.S.,
called the ARPAnet .The original goal of the ARPAnet was to allow
government contractor to share expensive or scarce computing resources. From
the beginning, however, users of ARPAnet also used the network for
collaboration ranged from sharing files and software and exchanging electronic

1
mail-now commonplace-to joint development and research using shared remote
computers.

The network grew from a handful to a network of tens of thousands of hosts.

The original ARPAnet became the backbone of a confederation of local and
original networks based on TCP/IP, called the internet.

Today, the Internet connects millions of host around the world. In fact, a
significant proportion of the non-PC computers in the world are connected to
the Internet. Some of the new commercial backbone can carry a volume of 622
megabits per second, over ten thousand times the bandwidth of original
ARPAnet. Tens of millions peoples use the network for communication and
collaboration daily.

1.2 History of Domain Name System

Through the 1970s, the ARPAnet was a small, friendly community of a few
hundred hosts. A single file, HOSTS.TXT, contained all the information we
needed to know about those host: it held a name –to-address mapping for every
host connect to the ARPAnet. The familiar UNIX host table, /etc/hosts, was
compiled from HOST.TXT (mostly by deleting fields that UNIX didn’t use).

HOSTS.TXT was maintained by SRI’s Network Information Center (dibbed

“the NIC”) and distributed from a single host, SRI-NIC.” ARPAnet
administrators typically emailed their changes to the NIC, and periodically
ftped to SRI-NIC and grabbed the current HOSTS.TXT. Their changes were
compiled into anew HOSTS.TXT once or twice a week. As the ARPAnet

2
grew, however, this scheme became unworkable. The size of HOSTS.TXT
grew in proportion to the growth in the number of ARPAnet hosts, Moreover,
the traffic generated by the update process increased even faster: every
additional host meant no only another line in HOSTS.TXT, but potentially
another host updating from SRI-NIC.

And when the ARPAnet moved to the TCP/IP protocols, the population of the
network exploded. Now there was host of problems with HOSTS.TXT, but
potentially another host updating from SRI-NIC.

And when the ARPAnet moved to the TCP/IP protocols, the population of the
network exploded. Now there was a host of problems with HOSTS.TXT:

Traffic and load

The toll on SRI-NIC, in terms of the network traffic and processor load
involved in distributing the file, was becoming unbearable.

Name collisions
No toll hosts in HOSTS.TXT could have the same name. However,
while the NIC could assign addresses in a way that guaranteed
uniqueness, it had no authority over host named. There was nothing to
prevent someone from adding a host with a conflicting name and
breaking the whole scheme. Someone adding a host with the same name
as a major mail hub, for example, could disrupt mail service to much of
the ARPAnet.

Name collisions
Maintaining consistency of the file across an expanding network
became harder and harder. By the time a new HOSTS.TXT could reach

3
 the farthest shores of the enlarged ARPAnet, hoists across the network
had changed addresses, or a new host had sprung up that users wanted
to reach.

The essential problem was that that HOSTS.TXT mechanism didn’t scale well.
Ironically HOSTS.TXT. Their goal was to create a system that solved the
problems inherently a unified host table system. The new system should allow
local administration of data, yet make the data globally available. The
decentralization of administration would eliminate the single-host bottleneck
and relieve the traffic problem. And local management would make the task of
keeping data up-to-date much easier. It should use a hierarchical name space to
name hosts. This would ensure the uniqueness of names.

Paul Mockaperris, then of USC’s Information Sciences Institute, was

responsible for designing the architecture of the new system. In 1984, he
released RFCs 882 and 883, which describe the Domain Name System. These
RFCs were superseded by RFCs 1034 and 1035, the current specification of the
Domain Name System. RFCs 1034 and 1035 have now been augmented by
many other RFCs, which describe potential DNS security problems,
implementation problems, administrative gotchas, mechanisms for dynamically
updating name servers and for securing domain data, and more.

2. WHAT IS DNS?

The Domain Name System is a database. This allowed local control of the
segment of the overall database, yet data in each segment are available in
across the entire network through a client server scheme. Robustness and
adequate performance are achieved through replication and catching.
4
Programs called name servers constitute the server half of DNS’s client-server
mechanism. Name servers contain information about some segment of the
database and make it available for the client, called resolvers. Resolvers are
often library routines that create queries and send them across a network to a
name server.

The structure of the DNS database shown in Fig2.1 is very similar to the
structure of the UNIX filesystem. The whole database (or filesystem) is
pictured as invert tree, with the root node at top. Each node in the tree has a
text label, which identifies the node relative to its parent. This is roughly
analogous to a “relative pathname” in a filesystem, like bin. One label-the null
label, or is reserved for the root node. In text, the root node is written as a
single dot (“.”). in the UNIX filesystem, the root is written as a slash (“ / ”).

“ ”
co
mc
om

com edu co gov mil

m

Fig 2.1: DNS database

5
 /

system
etc usr
bin etc
etc

bin
etc etc
local

bin
etc etc

Fig 2.2: Unix Filesystem

Each node is also the root of a new subtree of the overall tree. Each of these
subtrees represents a partition of overall database-a “directory” in the UNIX
filesystem, or a domain in the Domain name System. Each domain or directory
can be further divided into additional partitions, called subdomain in DNS, like
a filesystem’s “subdirectories” subdomains, like subdirectories, are drawn as
children of their parent domains.

Every domain has a unique name, like every directory. A domain name
identifies its position in the database, much as a directory’s “absolute

“”
pathname” specifies its place in the filesystem. In DNS, the domain name is the
sequence of labels from the node at the root of the domain to the root of the
whole tree, with “.” separating the labels. In UNIX filesystem, a directory’s
absolute pathname is the list of relative names read from root to leaf (the
opposite direction to DNS, as shown in Fig2.3 and Fig2.4), using a slash to
separate the names.

“”

com
m

hp
co
rp

corp

winnie.corp.hp.com

Fig2.3 Reading named in DNS database

7
 /

usr

local

bin

imake
/usr/local/bin/imake
Fig2.3: Reading named inUNIX filesystem

In DNS, each domain can be administered by a different organization. Each

organization can then break its domain into a number of subdomains and dole
out responsibility for those subdomains to other organizations. For example,
the interNIC runs the edu (educational) domain, but assigns U.C. Berkeley
authority over the berkeley .edu subdomain (Fig2.4). This is sometimes like
remotely mounting a filesystem certain directories in a filesystem may actually

8
be filesystems on other hosts, mounted from a remote host. The administrator
on host winken, for example (Fig2.5), is responsible for the filesystem that
appears on the local host as the directory /usr/nfs/winken.

managed by the
Network Information
Centre

` “”

edu com gov mil

berkley

managed by UC Berkeley

Fig2.4: Remote Management of subdomain

9
 Filesystem on local host

usr system
nfs bin etc
etc
local
bin
nod
blinken etc
etc

berkley

Filesystem on remote host

winken
Fig2.5: Remote Management of filesystems

Domain name are used as indexes into the DNS database. We might think of
data in DNS as “attached” to a domain name. In a filesystem, directories
contain files and subdirectories. Likewise, domain can contain both host and
subdomain. A domain contains those host and subdomain whose domains are
within the domain.

Each host on a network has a domain name, which points to information about
the host (Fig2.6). This information may include IP addresses, information
about mail routing, etc. Hosts may also have one or more domain name aliases,
which are simply pointers from one domain name (the alias) to another (the

10
official or canonical domain name). In the Fig2.6, mailhub.nv…is an alias for
the conical name rincon.ba.ca….

or nv
ca

mailhub
la
ba

rincon
oakland

IP address 192.2.18.44

Fig2.6: An alias in DNS pointing to a canonical name

To solve the problem HOST.TXT had. For example, making domain

hierarchical eliminates the pitfall of name collisions. Each domain has a unique

11
 domain, so organization that runs the domain is free to name hosts and
subdomain. Whatever name they choose for a host or subdomain, it won’t
conflict with other organization’ domain names, since it will end in their
unique domain name. For example, the organization that runs hic.com can
name a host puella (Fig2.7), since it knows that the domain host’s domain
name will end in hic.com, a unique domain name.

“”

com

hoc
haec

hic
puella

puer puella.hoc.com

puella

puella.hic.com

Fig2.7:Solving the name collision problem

12
3. WORKING OF DNS

3.1 Domain Name Space

DNS’s distributed database is indexed by domain names. Each domain name is

essentially just a part in a large invert tree, called the domain name space. The
tree’s hierarchical structure, shown in Fig.3.1, is similar to the structure of the
UNIX filesystem. The tree has a single root at the top. In the UNIX filesystem,
this is called the root directory, represented by a slash (“ / ”). DNS simply calls
it “the root.” Like a filesystem, DNS’s tree can branch any number of ways at
each intersection point, called a node. The depth of the tree is limited to 127
levels (a limit we’re not likely to reach).

“”

org
arpa edu gov

Fig 3.1: The structure of DNS name space

13
Each node in the tree has a text label (without dots) that can be up to 63
characters long. A null (zero-length) label is reserved for the root. The full
domain name of any node in the tree is the sequence of label on the path from
that node to the root. Domain names are always read from the node toward the
root (“up” the tree), and with dots separating the names in the path.

If the root node’s label actually appears in a node’s domain name, the name
looks as thought it ends in a dot, as in “www.oreilly.com.” (It actually ends
with a dot the separator and the root’s null label.). When the root node’s label
appears by itself, it is written as a single dot, “.”, for convenience.
Consequently, some software interprets a trailing dot in a domain name to
indicate the domain name is absolute. An absolute domain name is written
relative to the root, and unambiguously specifies a node’s location in the
hierarchy. An absolute domain name is also referred to as a fully qualified
domain name, often abbreviate FQDN. Names without trailing dots are
sometimes interpret as relative to some domain other than the root, just as
directory names without a leading slash are often interpreted as relative to the
current directory.

DNS requires that sibling nodes-nodes that are children of the same parent-
have different labels. This restriction guarantees that a domain name is
uniquely identifies a single node in the tree. The restriction really is not
limitation, because the labels only need to be unique among the children, not
among all nodes in the tree.

14
 3.2 Domains

A domain is simply a subtree of the domain name space. The domain name of a
domain is same as the domain name of the node at the very top of the domain.
So, far example, the top of the puradue.edu domain is a node named
puradue.edu, as shown in Fig3.2.

“”

com org
edu

purdue.edu node

purdue

purdue.edu domain

Fig 3.2: The purdue.edu domain

Any domain name in the subtree is considered a part of the domain. Because a
domain name can be in many subtrees, a domain name can also be in many

15
domains. For example, the domain name pa.ca.us is part of the ca.us domain
and also part of the us domain, as shown in Fig3.3. So a domain is just a
subtree of the domain name space.

“”

pa.ca.us node mil

net

us
us domain

ny
il

ca

pa mpk
ca.us domain

Fig 3.3: A node in multiple domain.

Domains are groups of hosts. The hosts are there, represented by domain
names. Domain names are just indexes into the DNS database. The “hosts” are
the domain name that point to information about individual hosts. And a
domain contains all the hosts whose domain names are within the domain. The
hosts are related logically, often by geography or organizational affiliation, and
not necessarily by network or address or hardware type. We might have ten

16
different hosts, each of them on a different network and each one perhaps even
in a different country, all in the same domain.

Domain names at the leaves of the tree generally represent individual hosts,
and they may point to network address, hardware information, and mail routing
information. Domain names in the interior of the tree can name a host and can
point to information about domain. Interior domain names are not restricted to
one or the other. They can represent both the domain they correspond to a
particular host on the network. For example, hp.com is both the name of the
Hewlett-Packard Company’s domain and the domain name of a host that runs
HP’s main web server.

The type of information retrieved when we use a domain name depends on the
context in which we use it. Sending mail to someone at hp.com would returm
mail routing information, while telneting to the domain name would look up
the host information (in Fig3.4, for example, hp.com’s IP address).

“”

com

hp.com IP address

hp

sdd
corp gr

Fig.3.4 An interior node with both host and structural data

17
A simple way to deciding whether a domain is subdomain of another domain is
to compare their domain names. A subdomain’s domain name ends with the
domain name of it s parent domain. For example, the domain la.tyrell.com
must be a subdomain of tyrell.com because la.tyrell.com ends with .com ends
with tyrell.com. similarly, it’s a subdomain of com, as is tyrell.com

Besides being referred to in relative terms, as subdomains of other domains,

domains are referred to by level. On mailing lists and in Usenet newsgroups,
these terms simply refer to a domain’s position in the domain name space:

A top-level domain is a child of the root.

A first-level domain is a child of the root (a top-level domain).
A second-level domain is a child of a first-level domain, and so on.

3.3 Top-Level Domains

The original top –level domains divided the Internet domain name space
organization into seven domains:

com
Commercial organizations, such as Hewlett-Packard (hp.com), sun
Microsystems (sun.com), and IBM (ibm.com)

edu

18
 Educational organizations, such as U.C. Berkeley (Berkeley.edu) and
Purdue University (purdue.edu)

gov
Government organizations, such as NASA (nasa.gov) and the National
Science Foundation (nsf.gov)

mil
Military organizations, such as U.S. Army (army.mil) and Navy
(navy.mil)

net
Networking organizations, such as NSFNET (nsf.net)

org
Noncommercial organizations, such as the Electronic Frontier Foundation
(eff.org)

int
International organizations, such as NATO (nato.int)

4. NAME SERVER

In theory at least, a single name server could contain the entire DNS database
and respond to all queries about it. In practice, this server is so overloaded as to
be useless. Furthermore, if it ever went down, the entire Internet would be
crippled.

19
To avoid the problem associated with having only a single source of
information, the DNS name space is divided up into non-overlapping zones.
Each zone contains some part of tree and also contains name servers holding
the authoritative information about the zone. Normally, a zone will have one
primary name server, which get it information from a file on its disk, and one
or more secondary name servers, which get their information from the primary
name server. To improve reliability, some servers for a zone can be located
outside the zone.

When a resolver has a query about a domain name, it passes the query to one of
the local name servers. If the domain being sought falls under the jurisdiction
of the name server, such as ai.cs.yale.edu falling under cs.yale.edu, it returns
the authoritative resource records. An authoritative record is one that comes
from the authority that manages the record, and is thus always correct.
Authoritative records are in contrast to cached records, which may be out of
date.

If, however, the domain is remote and no information about the requested
domain is available locally, the name server send a query message to the top-
level name server for the domain requested. To make this process clearer,
consider the example of Fig4.1. Here, a resolver on flits.cs.vu.nl wants to know
the IP address of the host linda.cs.yale.edu. In step 1 it sends a query to the
local name server, cs.vu.nl. This query contains the domain name sought, the
type (A) and the class (IN).

20
 VU CS edu Yale Yale CS
Originator name server name server name sever name server
1 2 3 4
flitss.vu.nl cs.vu.nl edu-server.net yale.edu cs.yale.edu
8 7 6 5

Fig 4.1: how a resolver looks up a remote name in eight steps

Let us suppose the local name server has never had query for this domain
before and knows nothing about it. It may ask a few other nearby name servers,
but if none of them know, it sends UDP packet to the server for edu given in its
database (Fig 4.1), edu-server.net. It is unlikely that this server knows the
address of Linda.cs.yale.edu, and probably does not know cs.yale.edu either,
but it must know all of its own children, so it forwards the request to the name
server for yale.edu (step 3). In turn, this one forwards the request to cs.yale.edu
(step 4), which must have the authoritative resource record. Since each request
is from a client to a server, the resource record requested works its way back in
step 5 through 8.

Once these records get back to the cs.vu.nl name server, they will be entered
into a cache there, in case they are needed later. However, this information is
not authoritative, since changes made at cs.yale.edu will not be propagated to
all the caches in the world that may know about it. For this reason, cache
entries should not live too long. This is the reason that Time_to_live field is
included in each resource record. It tells remote name servers how long to
cache records. If a certain machine has had the same IP address for years, it
may be safe to cache that information for 1 day. For more volatile information
it might be safer to purge the records after a few seconds or minute.

21
It is worth mentioning that the query method describe here is known as a
recursive query, since each server that does not have the requested
information goes and find it somewhere, then reports back. An alternative form
is also possible. In this form, when a query can not be satisfied locally, the
query fails but the next server along the line to try is returned. This procedure
gives the client to more control over the search process. Some servers do not
implement recursive queries always return the name of next server to try.

It is also worth pointing out that when a DNS client fails to get a response
before its timer goes off, it normally will try another server next time. The
assumption here is that the server is probably down, rather than the request or
reply got lost.

5. RESOLVERS

Resolvers are client that access name servers. Programs running on a host that
need information from the domain name space use the resolver. The resolver
handles:

Querying a name server

Interpreting responses (which may be resource records or an error)
Returning the information to the program that request it

In BIND, the resolver is just a set of library routines that is linked into
programs such as telnet and ftp. It is not even a separate process. It has the
smarts to put together a query, to send it and wait for answer, and to resend the
query if it is not answered, but that is about all. Most of the burden of finding

22
an answer to the query is placed on the name server. The DNS specs call this
kind of a stub resolver.

Other implementations of DNS have had smarter resolvers, which can do more
sophisticated things such as build up a cache of information already retrieved
from name servers. But these are not nearly as common as the stub resolver
implemented in BIND.

23
6. CONCLUSION

24
7. REFERENCES

Bibliography

[1]. P. Albitz & C. Liu, DNS and BIND, Shroff Publishers & Distributors

Pvt. Ltd. Calcutta, Third Edition, Page No. 1-8, 11-16, 18-22, 26

[2]. Andrew S. Tanenbaum, Computer Networking, Prentice-Hall Of India

Pvt. Ltd. New Delhi, Third Edition, Page No. 622-630

Websites

[1]. www.google.com

[2]. www.cis.ohio-state.edu

25