Domain Name System

0 width=100% bgcolor=ccccff> « back to results for ""
Below is a cache of http://www.dns.net/dnsrd/docs/V01820-72dpi.pdf. It's a snapshot of the page taken as our search engine crawled the Web.
The web site itself may have changed. You can check the current page or check for previous versions at the Internet Archive. Yahoo! is not affiliated with the authors of this page or responsible for its content.
Domain Name System DNS
Architecture
Service
Standard
Robust
Efficient
Flexible
Scalable
Extensible
Affordable
Reliable
Predictable
Domain Name System
Proper use reduces intranet administration costs The Internet continues expanding. Its progress seems unstoppable; for years now the rate
of growth has been increasing. To easily continue using a more widely spread Internet,
and to keep a grip on it, DNS is vital. This article explains the benet of DNS for business
networks and the technological and administrative conditions necessary for the optimal
deployment of this technology. The method described here is particularly important for
organizations with many employees spread over multiple locations. 3 of 8
etwork addresses, such as 192.68.44.134, are difcult
for people to remember. The need for associating
names with network addresses has been recognized
almost from the start of the Internet. Initially, a list of the
names and network addresses of all computer systems
was maintained in a central le, known as the hosts le.
System administrators needed the discipline to regularly
pick up the latest version. This method of working was
no longer practical once the Internet starting rapidly
expanding. System administrators needed to pick up an
increasingly large le increasingly often. Also, the whole
Internet was dependent on a single central authority
who made changes. This authority also had no way of
verifying changes.
By about 1983 it was clear that the hosts le had to be
replaced by another mechanism. The successor had to
offer the same functions, but also be distributed, consis-
tent, reliable, and autonomous. These four characteris-
tics are brought together in DNS.
1.
Distributed: the system is hierarchical and allows the
delegation of authorities to multiple administrators.
2.
Consistent: the same answer is given when the same
request is made at different places.
3.
Reliable: redundant data can be held at different
places; changes propagate automatically.
4.
Autonomous: administrators can make changes inde-
pendently of others.
Figure 1: Applications, names and network connections.
N
N
Domain Name System
Proper use reduces intranet administration costs
Advantages for the Intranet
Internet technology is increasingly used on internal
company networks, where it is called an intranet. The
characteristics of DNS bring a number of advantages for
intranets. An intranet often has the same characteristics
as the Internet, such as rapid growth and increasing
geographical dispersal. This means that there is a greater
need for distributed management of names and
network addresses. DNS can adapt itself to the growth
and dispersal because of its distributed and autonomous
characteristics.
A reliable translation of names to network addresses is a
requirement for the reliability of intranet applications
(see gure 1). Because these names are used for applica-
tions, the reliability of an application is dependent as
much on a reliable translation from name to address as
on a reliable network connection (provided by the
routers). If the translation from name to network
address fails, then the application is, in effect, discon-
nected from the network. DNS is very suitable for per-
forming the translation because of its reliability and con-
sistency.
A well-structured naming scheme makes maintaining an
intranet easier. For example, it makes it possible to make
changes to the infrastructure without disrupting the
services. So the network address of a web server or mail
server can be changed without having to inform the
users, because the name will not change. DNS can,
therefore, reduce intranet management costs.
There are various services which can perform name
translation. The most well known, other than DNS, are
Network Information name Service (NIS) and Windows
Internet Naming Service (WINS). The NIS and WINS
services were developed for administrating Local Area
Networks (LANs) and are not sufciently robust for
larger networks. It is therefore better to use DNS tech-
nology for larger networks and for business critical
applications.
SAP
E-mail
WWW
Names
Network connections
DNS technology is better for larger networks and
business critical applications 4 of 8
DNS architecture
Without a clear architecture for name servers, resolvers
and the content, DNS cannot be effectively deployed.
One possible architecture is looked at here. For the name
server architecture a distinction is made between the
backbone name servers and the LAN servers. A back-
bone name server has information about the whole
intranet. Within the backbone a division is made into
master name servers and regional name servers. The mas-
ter backbone name server passes data on to the regional
name servers. The LAN name server only has informa-
tion about the LAN. LAN name servers ask the regional
backbone servers for DNS content that is not known
locally. To increase reliability the backbone name servers
can be geographically dispersed (gure 4).
Resolvers rst approach the name server on the LAN. In
case of problems they can fallback to the backbone
servers. This arrangement minimizes usage of band-
width on the Wide Area Network (WAN), because the
LAN name server holds information in cache. With this
set-up the resolver gets a response as quickly as possi-
ble. Furthermore, this gives extra robustness in two
ways. Translating local names is still possible if the con-
nection to the WAN is down, and translation of all
names is still possible if the local name server is down,
provided that the resolvers can fallback to using the
backbone name servers.
Figure 2: Name servers and resolvers
DNS building blocks
What does DNS consist of? DNS is built from three com-
ponents: servers, resolvers, and the content. Servers and
resolvers form the DNS infrastructure. The content con-
sists of what are called domains. A DNS server is called a name server, and its job is to
store names or to get them from other name servers.
Responses that the name server gets from other
servers are temporarily stored in cache to eliminate
unnecessary network trafc. Resolvers are the DNS clients whose job it is to
query the name server (gure 2). A resolver can gen-
erally directly query up to three name servers. The DNS content can full a number of functions.
The best known are the translation of names to net-
work addresses and mail routing. DNS can indicate
where e-mail must be delivered. Mail routing can be
made more robust by including alternative routes in
the DNS. Since DNS is distributed, it is also neces-
sary to store where a domain can be found. This is
done with the help of DNS meta-information.
The content is held in a tree structure (gure 3), in which
the highest level in the hierarchy is called the root. This
hierarchical tree structure has different functions. Firstly,
the name gives a rough indication of the type and loca-
tion of the organization. Names that end with .nl, for
example, are related to the Netherlands. Secondly, it is
possible to automatically navigate through the DNS
tree; the DNS meta-information is used for this. Thirdly,
the structure allows responsibility for a branch to be
delegated to multiple parties. Within the branch com, for
example, responsibilities can be delegated to ibm and to
origin-it
. This creates the domains ibm.com and origin-
it.com
.
The content of each domain must be maintained. That is
the responsibility of the hostmaster. There is, therefore, a
hostmaster for each of the root, com, and origin-it.com
domains.
Each hostmaster must manage the names, network
addresses, mail routing and DNS meta-information for
the domain (gure 3).
Name server
Local tables
cache
other name servers
query
response
Resolver 5 of 8
Naming convention
To make optimal use of DNS a naming convention is
vital. A naming convention denes the architecture of
the content. It describes the structure and rules for the
names that may be used within the company. A practical
naming convention ensures that names need to change
as little as possible, and that they have a logical struc-
ture. At the same time, the naming convention must also
have both a technical and a human dimension. The tech-
nical dimension gives the relationship between the
application and the infrastructure (see gure 1). The
human dimension is concerned with ensuring that the
end users and administrators can apply the convention
in practice.
Bearing in mind that organization