DOMAIN NAME SYSTEM

SEMINAR REPORT

SUBMITTED IN PARTIAL FULFILMENT

FOR AWARD OF DEGREE OF BACHELOR OF TECHNOLOGY
IN
COMPUTER SCIENCE AND ENGINEERING
By

Prashant
(Roll No. 2021021053)

Submitted in
Department of Computer Science and Engineering

MADAN MOHAN MALAVIYA UNIVERSITY OF TECHNOLOGY

GORAKHPUR-273010
CONTENTS

1. Introduction
 History of DNS
2. Domain Name System
 Definition of DNS
3. Domain Name Space
 Definition of domain name space
 Name Resolution
 DNS Server and the Internet
(i) Domain
(ii) Zones
(iii) Name Server
4. Resolver
 Setup
 HostName
 DNS Sever
5. Importance of DNS
6. Future of DNS
7. Conclusion
8. References
Introduction
History of DNS

The development of the DNS can be traced back to the early days of the
internet, when it was a relatively small and tightly connected network called
ARPANET. In the early 1980s, ARPANET introduced a centrally managed
file called the “hosts.txt” file that mapped hostnames to IP addresses. As
the internet grew rapidly, this approach became unmanageable.

In 1983, Paul Mockapetris and Jon Postel introduced the DNS as we know
it today through RFC 882 and RFC 883, providing a distributed and
hierarchical system for domain name resolution. This innovation paved the
way for the scalable and efficient DNS architecture that underpins the
modern internet.

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 [email protected] 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 [email protected], 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.
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 157.55.100.1. Most people would reach this computer by
specifying FTP.microsoft.com 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 "microsoft.com"
domain. If someone wanted to contact that host, they would use the Fully
Qualified Domain Name (FQDN) rhino.microsoft.com.

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 www.internic.net/. 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 examples.

DNS Type of Organization

Domain
Name

Com Commercial (for example, microsoft.com for Microsoft Corporation)

Edu Educational (for example, mit.edu for Massachusetts Institute of

Technology)

Gov Government (for example, whitehouse.gov for the White House in

Washington D.C.)

Int International organizations (for example, nato.int for NATO)

Mil Military operations (for example, army.mil for the Army)

Net Networking organizations (for example, nsf.net for NSFNET)

Org Noncommercial organizations (for example, fidonet.org for FidoNet)

Domains

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 microsoft.com
could contain both computers such as FTP.microsoft.com and sub domains
such as dev.microsoft.com, which could contain hosts such as
ntserver.dev.microsoft.com.

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.

Zones

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, microsoft.com 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 dev.microsoft.com. 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
server.

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 query.

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, "in-addr.arpa.", was created in

the DNS name space. Nodes in the in-addr.arpa 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 in-addr.arpa tree. With this arrangement, administration
of lower limbs of the DNS in-addr.arpa 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 157.55.200.2,
the resolver would query the DNS server for a pointer record for
2.200.55.157.in-addr.arpa. 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 200.55.157.in-addr.arpa, which should contain the
resource PTR record for 2 (that is, 157.55.200.2).

The Resolver
Setup

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
consistency.

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 wkstn1.microsoft.com, where wkstn1 is the host name and
microsoft.com 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 tried.

In this example I could have also used:

\\157.55.100.204\public instead of \\scottsu-

7.scottsu.com\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.

Importance of DNS
 Human-Readable Addresses: DNS allows users to access websites
and services using easy-to-remember domain names instead of
having to remember numerical IP addresses. This enhances user-
friendliness and accessibility.

 Scalability: DNS is designed to handle the immense growth of the

internet. Its hierarchical structure and distributed nature ensure
efficient and scalable domain name resolution.

 Load Balancing: DNS can be used to distribute traffic across

multiple servers by associating a domain name with multiple IP
addresses. This load balancing enhances the reliability and
performance of websites and services.

 Redundancy and Failover: DNS can be configured to provide

redundancy and failover capabilities. If one server or data center
becomes unavailable, DNS can direct traffic to alternative resources.
  Global Reach: DNS is a global system, enabling users from anywhere
in the world to access websites and services by their domain names.
It plays a crucial role in making the internet truly global.

The Future of DNS

The DNS landscape is continuously evolving to address emerging
challenges and improve its performance. Some notable developments
include:

 DNS over HTTPS (DoH) and DNS over TLS (DoT): These protocols
encrypt DNS traffic, enhancing user privacy and security.

 DNSSEC Adoption: Wider adoption of DNSSEC helps prevent DNS

cache poisoning and enhances the trustworthiness of DNS responses.

 IPv6 Transition: As IPv6 adoption grows, DNS plays a critical role

in mapping IPv6 addresses to domain names.

 Edge Computing: DNS is integral to the emerging field of edge

computing, where low-latency access to resources is crucial.

 Blockchain and Decentralization: Some initiatives explore

blockchain-based DNS systems to increase resilience and reduce
centralization.

Conclusion
The Domain Name System (DNS) is the unsung hero of the internet, silently
working behind the scenes to make the web accessible and user-friendly. It
has a rich history, a complex yet elegant structure, and immense
importance in today’s digital age. Despite its challenges and
vulnerabilities, DNS continues to evolve to meet the changing needs and
demands of the internet, ensuring that users can access the vast array of
online resources with ease and confidence. As the internet continues to
grow and evolve, so too will the Domain Name System, adapting to new
technologies and security threats while remaining a cornerstone of online
communication and connectivity.Rules to Architect a Good DNS Solution
for the Future.
 References
 DNS & BIND 3rd edition. Paul Albitz, Cricket Liu.

 O’Reilly & Associates, 1998. , TCP/IP Protocol Suite. Behiouz, A.

Forouzan

 Windows NT DNS. Michael P. Masterson, H. Knief, S. Vinick; New

Riders Publishing, 1998. .,

 www.geeksforgeeks.com,www.wikipedia.com