domain name system full report
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
computer science technology
Active In SP

Posts: 740
Joined: Jan 2010
24-01-2010, 06:02 PM

.doc   domain name system full report.doc (Size: 233 KB / Downloads: 88)


Although programs theoretically could refer to hosts, mailboxs and
other resources by their network (e.g., IP) addresses, these addresses
are hard for people to remember. Also, sending e-mail to
tana@ means that if Tanaâ„¢s ISP or organization moves the
mail server to a different machine with a different IP address, her e-
mail address has to change.Consequently, ASCII names were introduced to
decouple machine name from machine addresses. In this way, Tanaâ„¢s
address might be something like that,
the network itself understands only numerical address-es, so some
mechanism is required to convert the ASCII strings to network
addresses. In the following sections we will study how this mapping is
accomplished in the internet.
Way back in the ARPANET, there was simply a file, hosts.txt that listed
all the hosts & their IP addresses. Every night, all the hosts would
fetch it from the site at which it was maintained. For a network of a
few hundred large timesharing machines, this approach worked reasonably
However, when thousands of minicomputer & PCs were connected to the
net, everyone realized that this approach could not continue to work
forever. For one thing, the size of the file would become too large.
However, even more important, host name conflicts would occur
constantly unless names were centrally managed, something unthinkable
in a huge international network due to the load and latency. To solve
these problems, DNS (the Domain Name System) was invented.
The essence of DNS is the invention of a hierarchical, domain-based
naming scheme and a distributed database system for implementing this
naming scheme. It is primarily used for mapping host names and e-mail
destinations to IP addresses but can also be used for other purposes.
DNS is defined in RFCs 1034 and 1035.
Domain Name System
The Domain Name System (DNS) is a set of protocols and services on a
TCP/IP network that allows users of the network to utilize hierarchical
user-friendly names when looking for other hosts (that is, computers)
instead of having to remember and use their IP addresses. This system
is used extensively on the Internet and in many private enterprises
today. If you've used a Web browser, Telnet application, FTP utility,
or other similar TCP/IP utilities on the Internet, then you have
probably used a DNS server.
The DNS protocol's best-known function is mapping user-friendly names
to IP addresses. For example, suppose the FTP site at Microsoft had an
IP address of Most people would reach this computer by
specifying FTP:// and not the less "friendly" IP address.
Besides being easier to remember, the name is more reliable. The
numeric address could change for any number of reasons, but the name
can always be used.
Before the implementation of DNS, the use of user-friendly computer
names was done through the use of HOSTS files, which contained a list
of names and associated IP addresses. On the Internet, this file was
centrally administered and each location would periodically download a
new copy. As the number of machines on the Internet grew, this became
an unmanageable solution. The need for something better arose. This
better solution became DNS.
According to Dr. Paul Mockapetris, principle designer of DNS, the
original design goal for DNS was to replace the cumbersome singularly
administered HOSTS file with a lightweight distributed database that
would allow for a hierarchical name space, distribution of
administration, extensible data types, virtually unlimited database
size, and reasonable performance.
DNS maps to level 7 in the OSI model and can use either UDP or TCP as
the underlying protocol. Resolvers send UDP queries to servers first
for increased performance and only resort to TCP if truncation of the
returned data occurs.
The most popular implementation of the DNS protocol "BIND" was
originally developed at Berkeley for the 4.3 BSD UNIX operating system.
The name "BIND" stands for Berkeley Internet Name Domain. The primary
specifications for DNS are defined in Requests for Comments (RFCs) 974,
1034, and 1035.
Domain name space
A Domain Name System is composed of a distributed database of names.
The names in the DNS database establish a logical tree structure called
the domain name space. Each node or domain in the domain name space is
named and can contain sub domains. Domains and sub domains are grouped
into zones to allow for distributed administration of the name space
(zones will be discussed later in this section). The domain name
identifies the domain's position in the logical DNS hierarchy in
relation to its parent domain by separating each branch of the tree
with a period ".". The following figure shows a few of the top level
domains, where the Microsoft domain fits, and a host called "rhino"
within the "" domain. If someone wanted to contact that
host, they would use the Fully Qualified Domain Name (FQDN)

Figure 1. Domains and sub domains
DNS Servers and the Internet
The root of the DNS database on the Internet is managed by the Internet
Network Information Center, located at internic. The top-level
domains were assigned organizationally and by country. These domain
names follow the International Standard 3166. Two-letter and three-
letter abbreviations are used for countries, and various abbreviations
are reserved for use by organizations, as shown in the following
DNS Domain Name Type of Organization
Com Commercial (for example, for Microsoft
Edu Educational (for example, for Massachusetts Institute
of Technology)
Gov Government (for example, for the White House in
Washington D.C.)
Int International organizations (for example, for NATO)
Mil Military operations (for example, for the Army)
Net Networking organizations (for example, for NSFNET)
Org Noncommercial organizations (for example, for
Each node in the tree of a DNS database, along with all the nodes below
it, is called a domain. Domains can contain both hosts (computers) and
other domains (sub domains). For example, the Microsoft domain could contain both computers such as FTP://
and sub domains such as, which could contain hosts
such as
Note In general, Domain names and Host names have restrictions in
their naming that only allow the use of characters "a-z," "A-Z," "0-9,"
and "-" (dash or minus sign). The use of characters such as the "/,"
".," and "_" (slash, period, and underscore) are not allowed.
A zone is some portion of the DNS namespace whose database records
exist and are managed in a particular zone file. A single DNS server
might be configured to manage one or multiple zone files. Each zone is
anchored at a specific domain node”referred to as the zone's "root
domain." Zone files do not necessarily contain the complete tree (that
is, all sub domains) under the zone's root domain. For a comparison of
domains and zones, look at the figure that follows. In this example, is a domain but the entire domain is not controlled by
one zone file. Part of the domain is actually broken off into a
separate zone file for Breaking up domains across
multiple zone files might be needed for distributing management of the
domain to different groups or possibly for efficiencies in data
replication (that is, zone transfers, which will be discussed later).
Note It is very important that you understand the difference between
a zone and a domain. A zone is a physical file, composed of resource
records, that defines a group of domains. A domain is a node in the DNS
namespace and all sub domains below it.

Figure 2. Domain with zones
Name Servers
DNS servers store information about the domain name space and are
referred to as name servers. Name servers generally have one or more
zones for which they are responsible. The name server is then said to
have authority for those zones.
When you configure a DNS name server (as we will soon see with the "NS"
record), you tell it which DNS name servers are in the same domain.
Primary, secondary, and master name servers
A primary name server is a name server that gets the data for its zones
from local files. Changes to a zone, such as adding domains or hosts,
are done at the Primary Name Server. A secondary name server gets the
data for its zones from another name server across the network which is
authoritative for that zone. The processes of obtaining this zone
information (that is the database file) across the network are referred
to as zone transfer.
There are three reasons to have secondary servers within an enterprise:
¢ Redundancy
You need at least two DNS name servers serving each zone, a primary
name server and at least one secondary name server for redundancy. Like
any fault-tolerant system, the machines should be as independent as
possible (that is, different networks and so forth).
¢ Remote locations
You should also have secondary servers (or other primary servers for
sub domains) in remote locations that have a large number of clients.
You would not want these clients to have to communicate across slow
links for name resolution.
¢ Reduce load on the primary
You also need secondary servers to reduce the load on the primary
Since information for each zone is stored in separate files, this
primary or secondary designation is defined at a zone level. In other
words, a particular name server may be a primary name server for
certain zones and a secondary name server for other zones.
When defining a zone on a name server as a secondary, you must
designate a name server from which to obtain the zone information. The
source of zone information for a secondary name server in a DNS
hierarchy is referred to as a master name server. A master name server
can be either a primary or secondary name server for the requested
zone. When a secondary name server starts up, it contacts its master
name server and initiates a zone transfer with that server.
Note Use secondary servers as master servers when the primary is
overloaded or when there is a more efficient network path between
"secondary to secondary" versus "secondary to primary."
Forwarders and slaves
When a DNS name server receives a DNS request, it attempts to locate
the requested information within its own zone files. If this fails
because the server is not authoritative for the domain requested, it
must communicate with other DNS name servers to resolve the request.
Since, on a globally connected network, a DNS resolution request
outside a local zone typically requires interaction with DNS name
servers outside of the company on the public Internet, you may want to
selectively enable specific DNS name servers in your company to do this
wide-area communication.
To address this issue, DNS allows for the concept of forwarders.
Specific DNS name servers are selected to be forwarders, and only
forwarders are allowed to carry out the wide-area communications across
the Internet. All other DNS name servers within the company are
configured to use forwarders and are configured with the IP addresses
of the DNS name servers designated as forwarders. This configuration is
done on a per-server basis, not a per-zone basis!

Figure 3. Forwarder and slaves
When a server configured to use forwarders receives a DNS request that
it is unable to resolve through its own zone files, it passes the
request to one of the designated forwarders. The forwarder then carries
out whatever communication is necessary to resolve the request and
returns the results to the requesting server, which, in turn, returns
the results to the original requester. If the forwarder is unable to
resolve the query, the DNS server attempts to resolve the query on its
own as normal.
Slaves are DNS servers that have been configured to use forwarders and
to return a failure message if the forwarder is unable to resolve the
request. Slaves make no attempt to contact other name servers if the
forwarder is unable to satisfy the request.
Name Resolution
There are three types of queries that a client can make to a DNS
server, recursive, iterative, and inverse. While discussing name
resolution, keep in mind that a DNS server can be a client to another
DNS server.
Recursive queries
In a recursive query, the queried name server is petitioned to respond
with the requested data or with an error stating that data of the
requested type or the domain name specified doesn't exist. The name
server cannot just refer the querier to a different name server.
This type of query is typically done by a DNS client (a resolver) to a
DNS server. Also, if a DNS server is configured to use a forwarder, the
request from this DNS server to its forwarder will be a recursive
Iterative queries
In an iterative query, the queried name server gives the best answer it
currently has back to the querier. This type of query is typically done
by a DNS server to other DNS servers after it has received a recursive
query from a resolver.
The following figure shows an example of both types of queries. Query
1/8 is a recursive query from a client resolver to its DNS server while
2/3, 4/5, and 6/7 are iterative queries from the DNS server to other
DNS servers.

Figure 4. Recursive and iterative queries
Getting the Host name given the IP address
What if a resolver has the IP address and would like to know the Host
name for a particular machine? Instead of supplying a name and asking
for an IP address, the client needs to provide the IP address and ask
for the name. Since there is no direct correlation in the DNS name
space between the domain names and the associated IP addresses they
contain, only a thorough search of all domains could guarantee a
correct answer.
To alleviate this problem, a special domain, "", was
created in the DNS name space. Nodes in the domain are
named after the numbers in the dotted-octet representation of IP
addresses. But since IP addresses get more specific from left to right
and domain names get less specific from left to right, the order of IP
address octets must be reversed when building the tree.
With this arrangement, administration of lower limbs of the DNS in- tree can be given to companies as they are assigned their
class A, B, or C subnet address.
Once the domain tree is built into the DNS database, a special pointer
record is added to associate the IP addresses to the corresponding host
names. In other words, to find a host name for the IP address, the resolver would query the DNS server for a pointer
record for If this IP address was outside
the local domain, the DNS server would start at the root and
sequentially resolve the domain nodes until it reached, which should contain the resource PTR record for 2 (that is,
The DNS Files
Most DNS systems must be configured by editing text files. With
Microsoft DNS, as with all Microsoft Windows®-based products, there is
a user-friendly interface. The new administration interface makes it
much easier to configure both local and remote Microsoft DNS servers.
The DNS administrative tool configures the RFC-compatible text files
for you.
Even though the graphical user interface gives you the ability to
modify the DNS files without an editor, you should know the makeup of
the DNS system configuration files. In RFC-compliant DNS systems, there
are several files which define the DNS system configuration and
database. These files include the database, cache, reverse lookup, and
127 reverse lookup files. These files also exist in the Windows NT 4.0
DNS and are RFC-compliant. These files are explained in detail in this
The Database File
A database file or "zone file" is the file that contains the resource
records for that part of the domain for which the zone is responsible.
Some of the common resource records are given below. Windows NT 4.0
supplies a file called "place.DNS as a template to work with. This
file should be edited and renamed before you use it on a production DNS
server. It is generally a good idea to name this file the same as the
zone it represents. This is the file that will be replicated between
masters and secondaries.
The Start of Authority
The first record in any database file is the SOA Record:
IN SOA <source host> <contact e-mail> <ser. no.> <refresh time> <retry
time> <expiration time> <TTL>
¢ source host”the host on which this file is maintained.
¢ contact e-mail”the Internet e-mail address for the person
responsible for this domain's database file.
Note Instead of writing the "@" symbol in the e-mail name, as would
normally be done, the "@" must be replaced with a "." when placed in
the zone files. In other words, the e-mail address would be represented as in
the zone file.
¢ serial number”the "version number" of this database file. This
number should increase each time the database file is changed.
¢ refresh time”the elapsed time (in seconds) that a secondary
server will wait between checks to its master server to see if the
database file has changed and a zone transfer should be requested.
¢ retry time”the elapsed time (in seconds) that a secondary
server will wait before retrying a failed zone transfer.
¢ expiration time”the elapsed time (in seconds) that a secondary
server will keep trying to download a zone. After this time limit
expires, the old zone information will be discarded.
In order for a resource record to span a line in a database file,
parentheses must enclose the line breaks.
Note In a zone file, the "@" symbol represents the root domain of the
zone ( in the following examples). The "IN" in the
following records is the class of data. It stands for Internet. Other
classes exist, but none of them are currently in widespread use.
Caution Any domain name in the database file which is not terminated
with a period "." will have the root domain appended to the end.
@ IN SOA (
1 ; serial number
10800 ; refresh [3 hours]
3600 ; retry [1hour]
604800 ; expire [7 days]
86400 ) ; time to live [1 day]
Setting the server's refresh interval is a balance between data
consistency (accuracy of your data) and your network's load.
The name server record
The name server record lists the name servers for this domain, allowing
other name servers to look up names in your domain.
<domain> IN NS <name server host >
The e-mail exchange record
This record tells us what host processes e-mail for this domain. If
multiple e-mail exchange records exist, the resolver will attempt to
contact the e-mail servers in order of preference from lowest value
(highest priority) to highest value (lowest priority). By using the
example records that follow, e-mail addressed to
is delivered to first, if possible,
then to if mailserver0 is
<domain> IN MX <preference> <mail server host >
@ IN MX 1 mailserver0
@ IN MX 2 mailserver1
The host record
A host record is used to statically associate host's names to IP
addresses within a zone. It should contain entries for all hosts which
require static mappings including workstations, name servers, e-mail
servers, and so on. These are the records which make up most of the
database file when static records are used.
<host name> IN A <ip address of host>
rhino IN A
nameserver2 IN A
mailserver1 IN A
The local host record
A local host record allows lookups for "" to
localhost IN A
The CNAME record
These records are sometimes called "aliases" but are technically
referred to as "Canonical Name" (CNAME) entries. These records allow
you to use more than one name to point to a single host.
Using canonical names makes it easy to do such things as host both an
FTP server and a Web server on the same machine.
<host alias name> IN CNAME <host name>
Assume that and FTP:// are on the same
machine. If this is the case, then you might have the following entries
in your zone file:
FileServer1 IN A
FTP CNAME FileServer1
www CNAME FileServer1
If you ever intend to move the FTP server service away from the Web
service, then all you have to do is change the CNAME in the DNS server
for FTP and add an address record for the new server. For example:
FTP CNAME FileServer2
FileServer2 IN A
The Reverse Lookup File
This is a database file that is used for reverse lookups, in particular
IP DNS zones of host names when supplied with the IP numbers. This
allows a resolver to provide an IP address and request a matching host
name. This file contains SOA and name server records similar to other
DNS database zone files. It also contains pointer records.
This DNS reverse lookup capability is important because some
applications provide the capabilities to implement security based on
the connecting host names. For instance, if a client tries to link to a
Network File System (NFS) volume with this security arrangement, the
NFS server would contact the DNS server and do a reverse-name lookup on
the client's IP address. If the host name returned by the DNS server is
not in the access list for the NFS volume or if the host name was not
found by DNS, then the NFS mount request would be denied. This reverse
lookup capability is also often used for troubleshooting reasons.
Here are two example zones for different IP class networks.
Example class C zone:
Example class B zone:
The pointer record
Pointer records provide a static mapping of IP addresses to host names
within a reverse lookup zone. IP numbers are written in backward order
and "" is appended to the end to create this pointer
record. As an example, looking up the name for "" requires
a PTR query for the name ""
<Ip reverse domain name> IN PTR <host name>
Example: IN PTR
The Arpa-127.rev File
This is a database file for the domain. This domain
is used for reverse-lookups of IP numbers in the 127 network, such as
"localhost." The only things in this file that change are the SOA and
NS records.
The BIND Boot File
Although the boot file is not actually defined in the RFCs and is not
needed in order to be RFC-compliant, it is described here for
completeness. This file is actually a part of the BIND-specific
implementation of DNS. Microsoft DNS can be configured to use a boot
file if you are going to administer DNS through changes to the text
files instead of using the DNS Administrator UI.
This file controls the startup behavior of the DNS server. Commands
must start at the beginning of a line and no spaces may precede
commands. Recognized commands are: "directory, cache, primary, and
secondary." The syntax for this file is as follows:
Directory command
Specifies a directory where other files referred to in the boot file
can be found.
directory <directory>
directory c:\winnts\system32\ DNS
Cache command
Specifies a file used to help the DNS service contact name servers for
the root domain. This command and the file it refers to must be
present. A cache file suitable for use on the Internet is provided with
Windows NT 4.0.
cache. <filename>
cache . cache
Primary command
Specifies a domain for which this name server is authoritative and a
database file that contains the resource records for that domain (that
is, zone file). Multiple primary command records could exist in the
boot file.
primary <domain> <filename>
primary microsoft.DNS
primary dev.DNS
Secondary command
Specifies a domain for which this name server is authoritative and a
list of master server IP addresses from which to attempt downloading
the zone information, rather than reading it from a file. It also
defines the name of the local file for caching this zone. Multiple
secondary command records could exist in the boot file.
secondary <domain> <hostlist> <local filename>
secondary test.DNS
Forwarders command
Specifies another server that is willing to try resolving recursive
queries on behalf of the system.
forwarders <hostlist>
Slave command
Specifies that the use of forwarders is the only possible way to
resolve queries. Can only follow a forwarders command.
Introduction to Microsoft DNS
Some people might ask "what is the Microsoft DNS and why should I use
it?" Well, let's start out by telling you what DNS is not. First, the
Microsoft DNS server is not a port of the Berkley BIND code (which is
currently at revision 10.4 as of the writing of this paper). We made a
conscious decision to not port the BIND code, but rather to write our
own code that was fully RFC-compliant and compatible with BIND. We made
this decision because we wanted to be able to easily add performance
enhancements to the product. The Microsoft DNS server is also not the
code that was shipped in the Windows NT Resource Kit. If you used that
utility, you probably noticed that it had problems with zone transfers.
The DNS server service in Windows NT 4.0 is a complete rewrite and is
not just a bug-fixed version. Rest assured that in the DNS included
with Windows NT 4.0, RFC compliance has been thoroughly tested and it
all works as defined, including zone transfers.
Now let's talk about what the Microsoft DNS server is. First and
foremost, the DNS server in Windows NT 4.0 is an RFC-compliant
implementation of DNS. If there is a required feature in an RFC that is
not found in the Microsoft DNS product, this would be considered a bug.
Because Microsoft DNS is an RFC-compliant DNS server, it creates and
uses standard DNS zone files and supports all standard resource record
types. It is interoperable with other DNS servers and includes the de
facto standard DNS diagnostic utility”NSLOOKUP. Microsoft DNS also has
many features above and beyond those specified in the RFCs, such as
dynamic update through tight integration with WINS and easy
administration through the graphical administration utility called DNS
Note Microsoft DNS supports RFCs 1033, 1034, 1035, 1101, 1123, 1183,
and 1536.
With the Microsoft implementation of DNS, network administers can turn
off the legacy DNS systems in favor of a Microsoft Windows NT
implementation. They can remove any static entries for Microsoft-based
clients in legacy DNS server zone files in favor of the dynamic WINS/
DNS integration. For example, if a non“Microsoft-based client wants to
get to a Web page on an HTTP server that is DHCP/WINS-enabled, the
client can query the DNS server, the DNS server can query WINS, and the
name can be resolved and returned to the client. Previous to the WINS
integration, there was no way to reliably resolve the name because of
the dynamic IP addressing.
The following figure shows how a non“Microsoft-based client might find
a machine named "," running Microsoft Internet
Information Server (IIS), which has a dynamically allocated address
from DHCP and has registered with WINS.

Figure 7. Name resolution for non“Microsoft-based client
Also, as mentioned previously, the server running Microsoft DNS has a
graphical user interface DNS Manager that allows for easy
administration of any other Microsoft DNS server on the network through
RPC (similar to the way other Windows NT administrative utilities, such
as Server Manager and Event Viewer, work). The administrative UI also
contains a zone wizard that enables someone less familiar to DNS to be
successful in creating zones and zone database files. Keep in mind that
you cannot administer non“Microsoft DNS servers with this
administrative tool.
It's important to note that the Microsoft DNS server can easily use the
database, boot, cache, rev, and other files from any other DNS server
implementation (that is, UNIX or other Windows NT DNS implementation)
as long as that DNS server is RFC compliant. All that needs to be done
to port the files over to Microsoft DNS is change the file names and
locations in the boot file.
Note Although Microsoft DNS will support a boot file on initial
installation, the Boot file is a BIND-specific implementation and not a
requirement of the RFCs. This feature is provided for easy migration
from BIND-based DNS Servers. If the Microsoft DNS Manager UI tool is
used to create and administer zone files, this "Boot From BootFile"
option will be set to "Boot From Registry" and Microsoft DNS will store
and use data in the Windows NT registry for locating and loading the
zone file databases. A message will be written to the BOOT file stating
that the information is now in the registry. To go back to booting from
the boot file, the value of the "EnableRegistryBoot" key in the Windows
NT registry must be modified manually.
The Microsoft DNS server can also be a primary or secondary name server
to any other operating system (or other vendors' Windows NT
implementations). This makes it easy to begin to migrate away from a
UNIX DNS -based solution to the Microsoft-based solution.
The next section will walk you through the setup of a Microsoft DNS
server and explain the parameters required for a client resolver to
The Server
Installing the DNS Service
Verify DNS information in Windows NT
Before installing the actual Microsoft DNS service, it is important
that the Windows NT Server 4.0 server's TCP/IP stack is configured
correctly. In particular, the DNS section needs to be verified, because
the DNS service gets many of its default settings from this section
during setup.
To verify this information, run Control Panel and go into Network.
Click the Protocols tab. Pull up the properties dialog box for the
TCP/IP Protocol and click the DNS tab. Verify that you have a correct
Host Name and Domain filled in on this screen.
Note If the domain name and host name are supplied in the network
control panel setup when you create a zone, DNS will add SOA, A, and NS
records to the database. If the information is not configured, only the
SOA record is created.
Installing the Microsoft DNS Service
To install the Microsoft DNS Service on a Windows NT 4.0-based system,
run the Control Panel and go into Network. Click the Services tab, then
click the Add button. Highlight Microsoft DNS Server and click OK.

Figure 9. Installing Microsoft DNS Server service
At this point, a default installation of Microsoft DNS server service
will be installed on the Windows NT-based server. This installation
will install files in your \<SystemRoot>\system32\ DNS directory as
shown. At this point, you will be prompted to restart your server.

Figure 10. Location of default DNS Server service installation
Configuring DNS Domains and Zones
To configure the DNS server, run the DNS Manager under the
Administrative Tools. Initially, the DNS Manager will not have any
servers in its list. To add the local server, pull down the DNS menu
and click New Server. Fill in the name of your local server and click
OK. The server will then show up in the Server List. Double-click the
server to see the server statistics and zones that have been defined.

Figure 11. Configuring DNS Server
Since the DNS server initially has no information about your specific
network, the DNS server service installs as a caching-only name server
for the Internet. This means that DNS only contains information on the
Internet root servers. For most DNS configurations, additional
information must be supplied to obtain the desired operation.
The first step in configuring the DNS server is to determine the
hierarchy for your DNS domains and zones. Design considerations for a
DNS hierarchy are discussed in the next section of this paper. Once the
domain and zone information have been determined, the information must
be entered into the DNS configuration using the DNS Manager.
Since DNS information is grouped and controlled by zones, a zone must
first be created. To do this, click the server name with the alternate
mouse button and then click New Zone.
Note If you double-click the CACHE zone, you can see all of the hosts
that the DNS server has statically defined and dynamically cached due
to a previous query. The CACHE will also show all of the WINS entries
that have been resolved and have not elapsed their WINS-specific Cache
Time-out Value.

Figure 12. Creating a zone
At this point, a dialog is presented that asks if the zone you are
creating is a primary zone (information stored locally) or a secondary
zone (information obtained from a master server by a zone transfer). If
it is a primary zone, no additional information is needed at this step.
If it is a secondary zone, you must also enter the zone and master
server names in this screen.
The next step is to fill in the zone name and zone file information for
the local server. This will determine how the zone shows up in the DNS
Manager and what file name it is stored under. If this is a secondary
zone, this zone name should match the master server zone name. If this
zone file already exists in the DNS directory, DNS will import these
records automatically when this zone is created.
If this is a secondary zone, you would then be asked to enter the IP
address of the master name servers (the name servers with which you
will do zone transfers for this zone).
Once all this information is entered, the zone will be added to the DNS
hierarchy. If you have additional zones that need to be added, follow
the same procedure for each zone. Once all zones have been added to the
server, you should then add any DNS subdomains under the zones that
your hierarchy might contain. To do this, click the appropriate zone
with the alternate mouse button and click New Domain.
Enter the name of the new sub domain in the dialog box and click OK. If
multiple levels of sub domains are needed, create each successive sub
domain by clicking the immediate parent with the alternate mouse
button, clicking New Domain, and entering the name of the new sub
This process can also be used for adding new host or resource records
at any domain location within the DNS hierarchy.
Integration with WINS Lookup
The WINS record
Although DNS may seem similar to Windows Internet Naming Service
(WINS), there are a couple of major differences. DNS is a static
database of IP addresses for name-to-address mapping, which must be
manually updated by an administrator. Also, DNS has the concept of
hierarchy which allows the administration and replication of the
database to be broken up into "zones." WINS, on the other hand, allows
machines to dynamically register their name-to-address mappings and
therefore requires far less administration. WINS is also a flat name
space, without the concept of hierarchy, and requires each WINS server
to maintain a complete database of entries through replication.
The Microsoft DNS server works hand in hand with the Microsoft WINS
server and provides a great deal of interoperability. To provide this
interoperability, a new record was defined as part of the zone database
file. The WINS record is specific to Windows NT and may be attached
only to the zone root domain. The presence of a WINS record instructs
the name server to use WINS to look up any requests for hosts in the
zone root that do not have static addresses in the IP database. This
functionality is particularly useful for UNIX-based clients that need
to contact DHCP/WINS enabled clients through IP.
<domain> IN WINS <IP address of WINS server>
Enabling WINS lookup
WINS Lookup can be enabled for a zone through the DNS Manager instead
of requiring manual entry of the WINS record. This is accomplished by
clicking the zone with the alternate mouse button and clicking
properties. Then click the WINS Lookup tab. Check the Use WINS
Resolution checkbox and fill in the IP address of the WINS Server that
you wish to use and click Add. Multiple WINS server addresses can be
You probably only need to use WINS lookup if you have non“Microsoft-
based TCP/IP clients that need to resolve Host Name to IP addresses,
for example, if your organization needs to be able to use FTP or HTTP
on servers running Windows NT from non“Microsoft-based (that is, UNIX)
Caution If you have a zone configured to do WINS lookup, then all DNS
servers that are authoritative for that zone need to be able to do WINS
lookup or you will have intermittent behavior.
In order to easily add the Microsoft WINS/ DNS lookup to a legacy DNS
architecture, simply create a new DNS subdomain in your enterprise and
have the Windows NT-based primary and secondary servers enabled to do
WINS lookup in this domain. For example, in the following figure there
are an domain and an domain. All of the
Microsoft-based clients register with the WINS server in the domain.

Figure 18. WINS/ DNS lookup with legacy architecture
WINS lookup is done on a DNS -zone basis. A query to a DNS server for would go to the WINS server if the DNS that had
the WINS lookup record was authoritative for zone, but a
query for would not go to that same WINS
server. This is shown in the following figure.
Figure 19. WINS lookup and DNS zones
If you are using a WINS record, the Time to Live (TTL) in the SOA
record is not the default for WINS as well. The WINS TTL is configured
through the "Advanced Zone Properties" dialog box (under the WINS
lookup tab) when you're configuring the zone. When an IP address/Host
name is resolved through WINS, the address is cached for the WINS Cache
Time-out Value. If this address is ever forwarded to another DNS, the
WINS Cache Time-out Value TTL is what is sent.
If your data doesn't change much, you will want to set your TTL high.
Keep in mind that you can set the TTL on individual records as well.
Note If the TTL on an individual RR's address is lower or higher than
the TTL in the SOA record, the individual's TTL takes precedence.
WINS and Reverse Lookup
The WINS reverse lookup record
Although WINS was not constructed to provide reverse lookup
capabilities, this functionality can still be accomplished for
DHCP/WINS enabled clients when using Microsoft's DNS server. The
presence of a WINS-R record at the zone root instructs the name server
to use a NetBIOS node adapter status lookup for any reverse lookup
requests for IP addresses in the zone root which are not statically
defined with PTR records.
<domain> IN WINS-R <domain to append to returned NetBIOS names>
Enabling WINS reverse lookup
WINS reverse lookup can be enabled for a zone through the DNS Manager
instead of requiring manual entry of the WINS-R record. This is
accomplished by clicking on the appropriate zone with the
alternate mouse button and clicking on properties. Then click on the
WINS Reverse Lookup tab. Check the Use WINS Reverse Lookup checkbox and
fill in the DNS Host Domain to be appended to the NetBIOS name before
returning the response to the resolver.
Note The Microsoft DNS server can be configured to not send WINS
records to secondary servers. This is necessary if you have a mixture
of Microsoft- and UNIX-based DNS servers, because UNIX-based DNS
servers do not have the capability to do WINS lookup.
Other Things to Know
The Microsoft DNS server supports "Notify"
The DNS NOTIFY transaction allows master servers to inform secondary
servers when the zone has changed (notify is set on the master server
on a per-zone basis)”an interrupt as opposed to poll model. This should
reduce propagation delay while not unduly increasing the master
server's load.
The use of this feature depends on how often the master server's data
will change and how slow the link is between the secondary and the
primary. If the master server's data changes a great deal, it is
important that the data on the secondary is very accurate, and the link
between the site that houses the primary and the secondary is not
negatively impacted by the zone transfer, then it may be a good idea to
use this feature.
It's also a good idea to use this feature if the master server's data
does not change very often. If this is the case, you can make the
refresh time on the master very long and a notification will be sent to
the secondary when they need to update their zone database.
Microsoft DNS supports "round robin"
Round robin is a technique used as a form of load balancing between
servers. You can read more about load balancing in RFC 1794. Here's an
example that shows how this works:
On the DNS server you could have 2 address entries for the same host,
such as the following: A A
If you make a query by some mechanism such as "PING," the DNS server will send both IP
addresses back, but typically the client will always use the first one.
The next time the DNS server receives a query for this host, the order
of the list is changed in a round robin fashion (the address that was
first in the previous list will be last in the new list), hence when
the client resolver chooses the first IP address in the list, it
chooses a different server. This is typically used for load balancing.
Here is a trace of a query that shows how the feature works. In frame
1, a query is sent to get the IP address for host
"". Because there were 2 entries in the
database, both were returned. The client resolver, in most
implementations (including the Microsoft resolver), uses the first
entry and discards the second.
1 SCOTTSU-7 Xircom40417A DNS 0x1:Std Qry for
DNS: 0x1:Std Qry for of type Host Addr
on class INET addr.
2 Xircom40417A SCOTTSU-7 DNS 0x1:Std Qry Resp. for
DNS: 0x1:Std Qry Resp. for of type Host
Addr on class INET addr.
DNS: Answer section: of type Host
Addr on class INET addr.(2 records present)
DNS: Resource Record: of type Host
Addr on class INET addr.
DNS: Resource Name:
DNS: Resource Type = Host Address
DNS: Resource Class = Internet address class
DNS: Time To Live = 0 (0x0)
DNS: Resource Data Length = 4 (0x4)
DNS: IP address =
DNS: Resource Record: of type Host
Addr on class INET addr.
DNS: Resource Name:
DNS: Resource Type = Host Address
DNS: Resource Class = Internet address class
DNS: Time To Live = 3600 (0xE10)
DNS: Resource Data Length = 4 (0x4)
DNS: IP address =
The next time someone makes a query for the host, the first IP address in the list will
be different:
DNS: Answer section: of type Host Addr
on class INET addr.(2 records present)
DNS: Resource Record: of type Host
Addr on class INET addr.
DNS: Resource Name:
DNS: Resource Type = Host Address
DNS: Resource Class = Internet address class
DNS: Time To Live = 3600 (0xE10)
DNS: Resource Data Length = 4 (0x4)
DNS: IP address =
DNS: Resource Record: of type Host
Addr on class INET addr.
DNS: Resource Name:
DNS: Resource Type = Host Address
DNS: Resource Class = Internet address class
DNS: Time To Live = 0 (0x0)
DNS: Resource Data Length = 4 (0x4)
DNS: IP address =
NetBIOS scope
The main thing to remember about DNS support for NetBIOS scope is DON'T
USE IT unless your network already uses NetBIOS scope. In a scope
configuration, all hosts are assigned a scope ID, and they register
this scope ID”along with their NetBIOS name”with WINS. If DNS is
configured to use scope, when it queries WINS, in addition to passing
the DNS host name as the single-part NetBIOS name, it also passes the
DNS domain as the NetBIOS scope ID.
A very important point to remember about scope is that when scope is
used, NetBIOS applications cannot see hosts that are in another scope!
One such NetBIOS application happens to be the Windows NT Net logon
service, which is responsible for trust relationships between Windows
NT domains. This means, for example, that if scope is used, a user
cannot log on in a domain where domain controllers have a different
scope than that of the user's station. It also means that a user cannot
access resources on a network server in a domain whose scope is
different than that of the user's station.
When does Microsoft DNS read and write to the zone files?
On startup of the DNS service, the zone files are read from disk. As
changes are made through the DNS Manager, the service periodically
flushes these changes to disk. In general, you should always use the
DNS Manager utility to add, delete, or modify resource records in the
database. However, if you feel a need to modify the files with an
editor, you should only make changes to these files if the DNS server
service is stopped. By default, the files are located in \%SystemRoot%
\system32\ DNS.
If you use the DNS administrative utility, and choose the DNS | "Update
Server Data Files" menu item, the files will also be flushed from
memory to disk.
The Eventlog
The DNS server will report events into the Eventlog. This allows an
administrator to determine when a zone transfer has been completed, or
when the DNS service has started, stopped, or an error has occurred.
The Resolver
The exact procedure needed to setup individual client machines will
vary depending on the operating system and TCP/IP software being used.
The specific procedures for the clients will not be covered in this
paper. However, the general setup parameters required and their use
will be discussed.
The Host Name
The host name for the client can be any combination of the letters A
through Z, the numerals 0 through 9, and the hyphen (-). By default, in
Microsoft networking environments, this value is the NetBIOS computer
name, but you can assign a different host name without affecting the
NetBIOS computer operation, if desired. If WINS Lookup is used with
Microsoft DNS, this value should match your NetBIOS computer name for
Note Some characters that can be used in NetBIOS names, especially
the underscore and period, cannot be used in DNS host names.
The Domain Name
The domain name is used with the host name to create a fully qualified
domain name (FQDN) for the computer. The FQDN is the host name followed
by a period (.), followed by the domain name. For example, this could
be, where wkstn1 is the host name and is the domain name. During DNS queries, the fully
qualified domain name is used.
The DNS Servers
Many operating systems allow you to specify several DNS servers in
their configurations. When this capability is provided, a priority
order is also provided so that a preferred server can be identified.
For a given DNS query, the system attempts to get DNS information from
the first IP address in the list. If no response is received, it goes
to the next server in the list, and so on.
Note In most systems, if you have two DNS servers listed, the system
only checks the second server if no response is received from the first
server. If the system attempts to check a host name with the first
server and receives a message that the host name is not recognized, the
system does not try the second DNS server.
The Domain Suffix Search Order
In some systems, a Domain Suffix Search Order capability is provided.
The Domain Suffix Search Order specifies the DNS domain suffixes to be
appended to the host names during name resolution. When attempting to
resolve a fully qualified domain name (FQDN) from a host-only name, the
system will first append the local domain name. If this is not
successful, the system will use the Domain Suffix list to create
additional FQDNS in the order listed and query DNS servers for each.
An example client configuration from a machine running Windows NT 4.0
is illustrated below.
Name Resolution
Windows NT TCP/IP 3.5x systems may use several methods for locating
NetBIOS resources:
¢ NetBIOS name cache
¢ NetBIOS name server
¢ IP subnet broadcasts
¢ Static LMHOSTS files
¢ Static HOSTS files
¢ DNS servers
Earlier implementations used only cache, broadcasts, and LMHOSTS files;
however, in version 3.5, a NetBIOS name server (WINS) was added and
modifications were made to allow NetBIOS applications to query the DNS
name space by appending configurable domain suffixes to a NetBIOS name.
However, the DNS name resolution was always done last, after the
NetBIOS cache, LMHOSTS file (if enabled), WINS (if enabled), and
broadcast were tried. With Windows NT 4.0, the DNS name resolution will
be tried first if the name is greater than 15 characters (maximum
length of a NetBIOS computer name on Windows NT). The Host name can now
be used in any of the Windows NT utilities (such as Microsoft Explorer,
seen below) that previously supported NetBIOS computer names. This
functionality will also be made available in the Windows 95 operating
system in the future.
Note Remember that the \%SystemRoot%\system32\drivers\etc\HOSTS file
can still be used for Host name resolution. However, DNS will be
queried before the HOSTS file is parsed.
If the DNS Host name (larger than 16 characters) is passed to a utility
and there are 2 transports loaded on a workstation (TCP and NetBEUI),
only the TCP transport will try to set up the session. If the Host name
is not used and the NetBIOS name is used, then all transports will be
In this example I could have also used:
\\\public instead of \\\public.
For more information on NetBIOS name resolution, you can refer to the
white paper "Windows NT Server: Dynamic Host Configuration Protocol and
Windows Internet Naming Service."
Note On a Windows NT-based workstation, if a Host name is not found
through DNS resolution, the name will be passed to NetBT (NetBIOS over
TCP/IP) for resolution through WINS, LMHOSTS file, or broadcast. This
might be seen as a feature for intranets that have many Web or FTP
servers and want to get resolution through WINS for host queries.
Prakash Narasimhamurthy of Microsoft Consulting Services provided the
flow charts shown in the following figures to illustrate name
resolution for the various node types:

Figure 24.
DNS Server to Connect to the Internet
Security Considerations
Many corporations today want to connect their internal networks to the
Internet toprovide access to external resources to employees who need
them to accomplish their assigned tasks. Although this is a very
important capability, it is one that must be well planned to avoid
possible data security risk from exposing the internal network to users
outside the corporation. One common way to provide this protection is
the use of a firewall. In Internet terms, a firewall is a system or
device which provides network security by allowing only certain
authorized activities to be accomplished between internal networks and
the Internet.
A firewall system can be very simple or extremely complex depending on
the particular requirements of the individual company. This paper is
not designed to provide an exhaustive description of firewall design,
but we will briefly discuss how the Microsoft DNS server can be used in
a firewall environment.
Here is a typical Internet connectivity setup for a company using a
dual-homed firewall (that is, proxy).
The firewall protects access from the outside while allowing clients on
the internal network access to Internet resources. This design also
allows for external WWW and FTP servers. These external servers must be
closely monitored and secured as much as possible since they are
directly on the Internet network with no "firewall"-type access
control. The router can provide some security by providing packet
filtering, if desired, to limit the type of traffic allowed. Access to
the internal network is controlled by the firewall.
The internal Web server can be set up exactly like the external server
except that security concerns are limited to the access controls
necessary for company employees. Typically, only those responsible for
Web development will actually log on to the internal servers to change
the files located there, although everyone would typically be given the
right to view the Web pages using a browser.
The Domain Name System for the external and internal networks are
usually entirely isolated from one another. This prevents external
clients from obtaining the names and addresses for internal resources
located inside the firewall. The only thing an outside user will see is
the IP addresses of the servers which are providing external services
(that is FTP, www, e-mail, and so on).
Typical Internet Connectivity Design
With these security concerns now established, let's look at a typical
Internet connectivity design and specifically at the way the DNS
servers would be configured. Below is a diagram of a typical large
company which has several internal and external resources which require
DNS services.

Figure 28. Large company Internet connectivity design
There are several items which should be noted about this example
network before we begin discussing the DNS configurations. These items
¢ Acme maintains primary and secondary DNS servers for their
external services (that is, DNS and DNS - There is also a secondary DNS server for their zone, which is maintained by their Internet Service Provider
for redundancy (that is, These name servers are
authoritative for domains and
¢ Some external services are being maintained on multiple
mirrored servers.
¢ Multiple e-mail servers are used to supply SMTP e-mail
connectivity to
¢ This network design uses packet filtering at the router as well
as using multihomed proxy servers to implement security.
¢ The internal network is using WINS for registration/lookup of
Microsoft-based clients and servers.
¢ Some intranet services (that is, Web Services) are being
provided on internal servers running Windows NT Server.
¢ DNS services on the internal network are isolated from the
Internet DNS services.
¢ The internal network is displayed as a simple no routed
environment for clarity.
With these details in mind, let's look at how this would affect the DNS
architecture. We will go through the thought process of configuring the
external DNS server first, then we will discuss the internal DNS
External DNS Server Configuration
After installing the DNS service on the Windows NT Server-based
machines (that is, DNS -server1 and DNS -server2), we use the Microsoft
DNS Manager tool to create a primary zone for domain and a
reverse lookup primary zone for on DNS -
server1. This will create an SOA record which contains the primary name
server "DNS" and the e-mail address for the
administrator of the DNS server "" as well as a
separate NS record for DNS -server1. Since the remaining default
parameters for this zone are sufficient, we will not modify them and
the defaults will be placed in the SOA record.
The following additional records must be created in the domain
and should be done with the "Create Associated PTR Record" enabled
where applicable.
Name server records (NS) should be created for DNS -server2 and E-mail exchange records (MX) should be created for
mail-server1 and mail-server2. We will set the preference for both of
these to 10 for equal load balancing. Address records (A) should be
created for each of the computers which connect directly to the
"Exposed Internet Network."
The actual name of the gopher server in our example is "gopher-". The de facto standard for supplying services on the
Internet is to serve them on computers with host names that correspond
with the service being supplied. To allow users to easily locate our
gopher service by connecting to the standard "", we will
use a canonical name (that is alias) for this server. To do this, we
create a canonical name record (CNAME) for "gopher" and associate it
with "gopher-server1".
Because there are multiple mirrored web servers and FTP servers
providing services to external users, there needs to be a way of
grouping these so that load balancing across the servers can occur.
There are several ways to do this with round robin techniques. The
method we will use here is to associate each of the mirrored servers
with the same alias name. We will use the popular names of the services
as the alias (that is www, FTP, and so on), which will allow easier
location of the services by users. To do this, we create a canonical
name record (CNAME) for each of the mirrored servers with the service
name as the alias and the server name for the host. With this
arrangement, each query to a particular DNS server for a particular
server name using its alias (that is, will return the
list of servers in a round robin fashion with a different server being
listed first in the list each time. Since most resolvers try the first
returned entry first, as described previously in this paper, this will
provide load balancing between servers.
Once this zone has been set up on the primary DNS server, the
and zones should be created on the secondary
DNS servers. These secondary zones should be pointing back to the
primary DNS server as the master for the zone transfers.
Here is the resulting zone file for the external DNS servers:
; Database file acme. DNS for zone. (External DNS Server)
; Zone version: 10
@ IN SOA (
10 ; serial number
3600 ; refresh
600 ; retry
86400 ; expire
3600 ); minimum TTL
; Zone NS records
@ IN NS DNS-server1
@ IN NS DNS-server2
; Zone records
@ IN MX 10 mail-server1
@ IN MX 10 mail-server2
DNS-server1 IN A
DNS-server2 IN A
FTP-server1 IN A
FTP-server2 IN A
gopher-server1 IN A
mail-server1 IN A
mail-server2 IN A
proxy-server1 IN A
proxy-server2 IN A
proxy-server3 IN A
www-server1 IN A
www-server2 IN A
www-server3 IN A
www-server4 IN A
gopher IN CNAME gopher-server1
www IN CNAME www-server1
www IN CNAME www-server2
www IN CNAME www-server3
www IN CNAME www-server4
Internal DNS Server Configuration
After installing the DNS service on the Windows NT Server-based
machines (that is, DNS -internal1 and DNS-internal2), we use the
Microsoft DNS Manager tool to create a primary zone for the internal
domain and a reverse lookup primary zone for on DNS -internal1. This will create an SOA record which
contains the primary name server "DNS" and the e-
mail address for the administrator of the DNS server "web-", as well as a separate NS record for DNS -internal1.
Since the remaining default parameters for this zone are sufficient, we
will not modify them and the defaults will be placed in the SOA record.
After creating these zones, we will enable WINS Lookup on the
zone and enter the IP addresses of the two internal WINS servers. This
will create a WINS record (WINS) in this zone file. We will also enable
WINS Reverse Lookup on the zone and enter the
DNS host domain as "". This will create a WINS reverse lookup
record (WINS-R) in this zone file.
The following additional records must be created in the internal domain and should be done with the "Create Associated PTR
Record" enabled where applicable.
A name server record (NS) should be created for DNS -internal2. Address
records (A) should be created for each of the computers which connect
directly to the "Isolated Corporate Network" which are not WINS
clients. It may be that all of the servers within the corporate network
are WINS-aware and therefore no static entries would be needed, but
just to show how you can mix static entries with WINS, we will
statically define the proxy servers and the DNS servers in the DNS zone
file. We will also create a "localhost" address record for the local
Since there are multiple mirrored Web servers providing services to
internal users, we will use the round robin technique using canonical
names as we did on the external network and associate these mirrored
servers with "". The difference here is that there are
no associated address records (A) for the internal Web servers (that is
www-internal1, www-internal2, www-internal3), because these are WINS
clients and the DNS server will query the WINS server for these
addresses when needed.
Once this zone has been set up on the primary DNS server, the
and zones should be created on the secondary
DNS server. These secondary zones should be pointing back to the
primary DNS server as the master for the zone transfers.
Here is the resulting zone file for the internal DNS servers:
Use Search at wisely To Get Information About Project Topic and Seminar ideas with report/source code along pdf and ppt presenaion
seminar class
Active In SP

Posts: 5,361
Joined: Feb 2011
21-04-2011, 12:05 PM

.doc   Domain Name System.doc (Size: 308.5 KB / Downloads: 54)

This era of technology is mainly focused on communication. The Internet is a communication system that has brought a wealth of information to our fingertips and organized it for our use. The Internet uses the IP address, which uniquely identifies the connection of a host to the Internet. People prefer to use names instead of numeric addresses. In past, when the Internet was small, mapping was done using a host file. It had only two columns; one for name and one for the address. But today, it is impossible to have single host file relate every address to names and it would be impossible to update all the host files in the world every time there is a change. Therefore, we need a system that can map a name to an address or an address to a name. This seminar and presentation report provides information about such a system called Domain Name System. It has been a tried to explain the concepts and ideas behind DNS. The information about its origin as well as about the DNS protocol itself, the principles on which it works and also its uses have been tried to cover in this report. The main focus is behind the working of DNS and how this working is made possible in the Internet.
Domain Name System (DNS) is a distributed database used by TCP/IP applications to map between hostnames and IP addresses, and to provide electronic mail routing information. Each site maintains its own database of information and runs a server program that other systems across the Internet can query. The DNS provides the protocol which allows clients and servers to communicate with each other.
The Internet Protocol address is a 32- bit integer. If somebody wants to send a message it is necessary to include the destination address, but people prefer to assign machines pronounceable, easily remembered names (host names). For this reason the Domain Name System is used. These logical names also allow independence from knowing the physical location of a host. A host may be moved to a different network, while the users continue to use the same logical name. When Internet was small, mapping was done using a host file. Today, it is impossible to have one single host file relate every address to a name. The host file would be too large to store in every host. Also, it would be impossible to update all the host files in the world every time there is a change.
One solution would be to store the entire host file in a single computer and allow access to this centralized information to every computer that needs a mapping. But this would create a huge amount of traffic on the Internet.
Another solution, the one used today, is to divide this huge amount of information into smaller parts and store each part on a different computer. In this method, the host that needs mapping can contact the closest computer holding he needed information. This method is used by the Domain Name System.
To be unambiguous, the names assigned to machines must be carefully selected from a name space with complete control over the binding between the names and IP address. The names must be unique because the addresses are unique. A name space that maps each address to a unique name can be organized in two ways: flat or hierarchical.
In a flat name space, a name is assigned to an address. A name in this space is a sequence of characters without structure. The main disadvantage of a flat name space is that it cannot be used in a large system such as Internet because it must be centrally controlled to avoid ambiguity and duplication.
In a hierarchical name space, each name is made of several parts. The first part can define the organization, the second part can define the name, the third part can define departments, and so on. In this case, the authority to assign and control the name spaces can be decentralized. A central authority can assign the part of the name that defines the nature of the organization and the name. The responsibility for the rest of the name can be given to the organization itself. Suffixes can be added to the name to define host or resources. The management of the organization need not worry that the prefix chosen for a host is taken by another organization because even if part of an address is the same, the whole address is different. The names are unique without the need to be assigned by a central authority. The central authority controls only part of the name, not the whole name.
To have a hierarchical name space, a domain name space was designed. In this design, the names are defined in an inverted-tree structure with the root at the top. Each node in the tree has a label, which is a string with a maximum of 63 characters. The root label is a null string (empty string). DNS requires that children of a node(nodes that branch from the same node)have different labels, which guarantees the uniqueness of the domain names.
Each node in the tree has a domain name. A fully domain name is a sequence of labels separated by dots (.). The domain names are always read from the node up to the root. The last label is the label of the root (null). This means that a full domain name always ends in a null label, which means the last character is a dot because the null string is nothing.
If a label is terminated by a null string, it is called a fully qualified domain name. An FQDN is a domain name that contains the full name of a host.
If a label is not terminated by a null string, it is called partially qualified domain name. A PQDN starts from a node, but it does not reach the root.
A domain is a sub-tree of the domain name space. The name of the domain is the domain name of the node at the top of the sub-tree.
The information contained in the domain name space must be stored. But it is very inefficient and also not reliable to have just one computer store such a huge amount of information. It is inefficient because responding to requests from all over the world places a heavy load on the system. It is not reliable because any failure makes the data inaccessible.
The solution to these problems is to distribute the information among many computers called DNS servers.
The way to distribute information among DNS servers is to divide the whole space into many domains based on the first level. Let the root stand-alone and create as many domains as there are first level nodes. Because a domain created this way could be very large, DNS allows domains to be divided further into smaller domains. Thus we have a hierarchy of servers in the same way that we have a hierarchy of names.
What a server is responsible for, or has authority over, is called a zone. The server makes a database called a zone file and keeps all the information for every node under that domain. If a server accepts responsibility for a domain and does not divide the domains into smaller domains, the domain and zone refer to the same thing. But if a server divides its domain into sub domains and delegates parts of its authority to other servers, domain and zone refer to different things. The information about the nodes in the sub domains is stored in the servers at the lower levels, with the original server keeping some sort of references to these lower level servers. Of course the original server does not free itself from responsibility totally: It still has a zone, but the detailed information is kept by the lower level servers.
A root sever is a server whose zone consists of the whole tree. A root server usually does not store any information about domains but delegates its authority to other servers, keeping references to those servers. Currently there are more than 13 root servers, each covering the whole domain name space. The servers are distributed all around the world.
DNS defines two types of servers: primary and secondary. A Primary Server is a server that stores a file about the zone for which it is an authority. It is responsible for creating, maintaining, and updating the zone file. It stores the zone file on a local disc.
A secondary server is a server that transfers the complete information about a zone from another server (Primary or Secondary) and stores the file on its local disc. If updating is required, it must be done by the primary server, which sends the updated version to the secondary.
DNS is a protocol that can be used in different platforms. In the Internet, the domain name space (tree) is divided into three different sections: Generic domains, Country domains, and Inverse domain.
The generic domains define registered hosts according to their generic behavior. Each node in the tree defines a domain, which is an index to the domain name space database.
The first level in the generic domains section allows seven possible three character levels. These levels describe the organization types as listed in following table.
seminar paper
Active In SP

Posts: 6,455
Joined: Feb 2012
23-03-2012, 12:11 PM

Domain Name Service

.docx   Domain Name Service.docx (Size: 122.17 KB / Downloads: 22)

Overview to DNS in Microsoft Windows 2000
To facilitate communications between computers, computers can be given names within a name space. The specific name space defines the rules for naming a computer, and for how names are resolved into IP addresses. When one computer communicates with other computers, it must resolve, or convert, a computer name into an IP address based on the rules of the name space being used. This resolution will be done by a name-resolution service.
There are two main name spaces, and name-resolution methods, used within Windows 2000: NetBIOS, implemented by Windows Internet Naming Service (WINS) (described in Chapter 17), and the DNS, described in this chapter. Windows 2000 also provides support for other name spaces, such as Novell Netware and Banyan Vines, although discussion of these is outside the scope of this book.

What Is DNS?
The DNS is an IETF-standard name service. The DNS service enables client computers on your network to register and resolve DNS domain names. These names are used to find and access resources offered by other computers on your network or other networks, such as the Internet. The following are the three main components of DNS:
• Domain name space and associated resource records (RRs) A distributed database of name-related information.
• DNS Name Servers Servers that hold the domain name space and RRs, and that answer queries from DNS clients.
• DNS Resolvers The facility within a DNS client that contacts DNS name servers and issues name queries to obtain resource record information.

Key DNS Terms
This section describes the key components of the DNS and defines key DNS terms.

Domain Name Space
The domain name space is a hierarchical, tree-structured name space, starting at an unnamed root used for all DNS operations. In the DNS name space, each node and leaf in the domain name space tree represents a named domain. Each domain can have additional child domains. Figure 16-1 illustrates the structure of Internet domain name space.

Resource Records (RR)
A resource record is a record containing information relating to a domain that the DNS database can hold and that a DNS client can retrieve and use. For example, the host RR for a specific domain holds the IP address of that domain (host); a DNS client will use this RR to obtain the IP address for the domain.
Each DNS server contains the RRs relating to those portions of the DNS namespace for which it's authoritative (or for which it can answer queries sent by a host). When a DNS server is authoritative for a portion of the DNS name space, those systems' administrators are responsible for ensuring that the information about that DNS name space portion is correct. To increase efficiency, a given DNS server can cache the RRs relating to a domain in any part of the domain tree.
There are numerous RR types defined in RFCs 1035 and 1036, and in later RFCs. Most of the RR types are no longer needed or used, although all are fully supported by Windows 2000. Table 16-2 lists the key RRs that might be used in a Windows 2000 network. (For more detail on the contents of specific RRs, see the "DNS Resource Records" section later in this chapter.)


Important Note..!

If you are not satisfied with above reply ,..Please


So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page

Quick Reply
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
  web spoofing full report computer science technology 13 9,024 20-05-2016, 11:59 AM
Last Post: Dhanabhagya
  android full report computer science technology 57 73,255 24-09-2014, 05:05 PM
Last Post: Michaelnof
  steganography full report project report tiger 23 25,818 01-09-2014, 11:05 AM
Last Post: computer science crazy
  3D PASSWORD FOR MORE SECURE AUTHENTICATION full report computer science topics 144 92,700 13-05-2014, 10:16 AM
Last Post: seminar project topic
Video Random Access Memory ( Download Full Seminar Report ) computer science crazy 2 2,423 10-05-2014, 09:44 AM
Last Post: seminar project topic
Brick Virtual keyboard (Download Full Report And Abstract) computer science crazy 37 31,049 08-04-2014, 07:07 AM
Last Post: Guest
  Towards Secure and Dependable Storage Services in Cloud Computing FULL REPORT seminar ideas 5 4,153 24-03-2014, 02:51 PM
Last Post: seminar project topic
  eyeOS cloud operating system full report seminar topics 8 11,479 24-03-2014, 02:49 PM
Last Post: seminar project topic
  XML encryption full report computer science technology 7 6,679 24-03-2014, 02:31 PM
Last Post: seminar project topic
  Intelligent Navigation Systems (Download Full Seminar Report) Computer Science Clay 10 6,649 24-03-2014, 02:24 PM
Last Post: seminar project topic