Simplified tcp based communication approach towards domain name system for improving security

ISSN:2249-5789
Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357

Simplified TCP Based Communication Approach towards Domain Name
System for Improving Security
Alok Pandey1 , Dr. Jatinderkumar R. Saini2
1

Sr. Systems Manager, Department of Computer Science Engineering, Birla Institute of Technology Mesra,
Jaipur Campus, Rajasthan, INDIA . e-mail :
2

Director (I/C) & Associate Professor, Narmada College of Computer Application, Bharuch,
Gujarat , INDIA. e-mail:

Abstract
Using DNS, domain names can be assigned to
groups of Internet resources independent of their
physical location. Without DNS, the only way to
reach other computers on the Internet is to use the
numerical network address. The use of IP address
for locating and connecting to remote systems is
tedious and is not very user friendly. A preferable
and much relied upon service for retrieving an IP
address just by referencing a FQDN is DNS.
Several types of DNS based communications take
place on the internet which are exploited by the
cyber criminals for attacking systems. Although
different mechanisms have been suggested by the
research community to secure the DNS based
communications yet it is still not fully secure.

Since DNS does not necessarily require the
establishment of a TCP connection it allows the
attackers to redirect the response to the victims host
by spoofing the source IP address as the victims IP
address. By exploiting this vulnerability the attacker
can launch different types of attacks like Cache
Poisoning, DNS Spoofing, Protocol corruption,
Zone corruptions, Session Hijacking, etc. Although
the use of UDP makes the system faster, ye, it is
suggested that all DNS based communications
should be TCP based rather than UDP.
Keywords : DNS, DNS Spoofing, DNS Poisoning

1. Introduction
Computers communicate with each other on the
basis of IP Addresses. Each device on the network
needs a unique IP address to enable data packets to
reach their destinations. Initially there were only a
few hundred computers making up the ARPANET,
the military / educational precursor to the Internet
in the early days. It may be easy to remember a few
IP addresses on local network, but is difficult to
keep track of the addresses of remote systems that
Due to its ability to map system names into
numeric IP addresses hierarchically and its
distributed nature & robustness, DNS has evolved
into a globally distributed database and is a critical
component of the Internet.

might be often used. Thus came the concept of host

names. Host names provide a more “friendly” way
to name the systems and resources, making it easier
for humans to remember them. The hostnames of
the frequently visited web based resources can be
recorded with their respective IP addresses.
Initially when the number of nodes was small, then
a single text file could easily map host names to
their corresponding IP addresses. This text file is
called Hosts.txt and used to be managed by the
Stanford Research Institute (SRI). This Hosts.txt
file contained all of the name-to-address mappings
for all nodes on the ARPANET. Operating systems
use the Hosts.txt file to map host names to IP
addresses. System administrators copied the
Hosts.txt file from SRI to their local systems
periodically to update their address maps.
As the number of nodes on the network increased
and the use of this static text file for providing
mapping, became impractical. The networks were
growing and the new hosts were being added at a
very high rate. Soon neither SRI nor the system
administrators could keep pace with the necessary
frequent updating procedures. There was an urgent
need of an automatic translation mechanism that
could manage the mapping of IP Addresses to their
respective Host Names. Thus the Domain Name
System (DNS) was developed in the mid-1980s to
provide a dynamic means of updating and resolving
host names to their IP addresses. It is one of the
basic services on the Internet.

DNS was originally specified in 1983 by Paul.
Mockapetris in RFCs 882 and 883. It is described
as a distributed database with the purpose to
replace the HOSTS.TXT file that maps the
hostnames to IP addresses and vice versa. The
Domain Name System (DNS) provides translation
from human-friendly names to data in other formats.
DNS is commonly used of the translation from
names like “www.mysite.com” to the “dotted-quads”
of IPv4 addresses, such as 192.168.1.64, or “colon
separated hex” of IPv6 addresses like
fd63:fad8:482a:65d3::0:f0cc. The DNS also acts as a
form of assistance operator for both human-to-

347


ISSN:2249-5789
Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357

machine and machine-to-machine interactions. In
addition to IP addresses, the DNS is also used to look
up for mail servers, cryptographic keys and
retrieving information related to other DNS Name
Servers, Canonical Names, etc. Several internet
based services rely on DNS for their operation.
Hence if DNS fails or is slow, then the web sites
cannot be located.

In September 1981, D. L. Mills published RFC 799,

“Internet Name Domains” wherein he suggested that
in the long run, it will not be practicable for every
internet host to include all internet hosts in its nameaddress tables hence some sort of hierarchical namespace partitioning should be devised to deal with
recording and maintaining such details of every
internet host.

DNS works both as a set of protocols and as a
globally distributed database that is used heavily on
the Internet. The database is a network of several
million servers, which actively cooperate to provide
a globally distributed service that translates between
human-oriented alphanumeric labels and machineoriented numbers. Any large-scale disruption of the
DNS would make the Internet unusable.

Based upon the decision to move to a “Hierarchy of
Domains” in a meeting in February 1982 the RFC
805, “Computer Mail Meeting Notes,” was
published.

The Web and email traffic would grind to a halt
since the Internet users and systems would not be
able to use human-friendly names for
communication and would be forced to use IP
addresses for everything. Any accidental or
intentional DNS failures would take companies such
as Microsoft [1] and Amazon [2] and countries such
as Sweden [3] and Germany [4] partially or fully off
the Internet.
Ever since DNS came into existence three decades
ago, it has been continuously improved for making it

more reliable and secure. Even today DNS is subject
to a variety of threats and attacks. One of the goals of
this document is to help readers understand today‟s
threats to the DNS infrastructure and how to mitigate
these threats using the inherent capabilities of the
DNS or by implementing policies for operational
practices.

1.1 History of the DNS
In the earliest days of the Internet, names of systems
connected to the network were assigned locally and
there was no DNS. The Network Information Centre
(NIC) kept track of the names.
In December 1973 RFC 597, “Host Status,” was
published, which became the first official collection
of hostnames. The system manager was expected to
use RFC 597 and keep their local list of host-toaddress mappings up to date.
Soon an online file was maintained by the NIC for
containing the official name to address mappings and
subsequently the RFC 606, “Host Names On-Line,”
was proposed and published in December 1973 by L.
Peter Deutsch. Early names as defined in RFC 606
were simple labels. Like, the system at MIT‟s
Artificial Intelligence lab was called “MIT-AI.” This
simple label approach of naming hosts on the
network was used for almost a decade and could not
work forever.

In August 1982 with the publication of RFC 819, by
Zaw-Sing Su and Jon Postel, this new approach of

host naming, described as the “Domain Naming
Convention for Internet User Applications” was
codified and introduced. The new Domain Naming
Convention was intended to use hierarchy for
distributing administrative management of the
namespace that would eliminate duplicity of names.
RFC 819 provided the general outline of the DNS,
including the ideas of naming authorities, registrars
and iterative and recursive resolvers. It suggested
that the Internet names be used to form a treestructured administrative dependent hierarchy, rather
than topology dependent, hierarchy. It also defined
the first top-level domain, .ARPA, as “The Set Of
Organizations involved in the Internet system
through the authority of the U.S. Defence Advanced
Research Projects Agency.”
In October 1982, RFC 830 “A Distributed System
For Internet Name Service” was published by ZawSing Su. It described an architectural view of a name
resolution service provided through the cooperation
among a set of domain name servers (DNSs) and
discussed system components like database, caching of
names, application interfaces and protocols for interprocess communication necessary to implement a
distributing naming system.
By November 1983, Paul Mockapetris had
published RFCs 882 “Domain Names - Concepts
and Facilities” and RFC 883 “Domain Names Implementation and Specification,” giving the
initial specifications for the DNS as we know it
today. The structure of names in the DNS was also
defined very early in the history of the Internet.
In October 1984 Jon Postel and Joyce Reynolds
published RFC 920, “Domain Requirements,” which

defined the original top-level domains (ARPA,
GOV, EDU, COM, MIL, and ORG), the two letter
country domains and opened the possibility of other
top-level domains for “multi organizations,” large
international organizations-of-organizations, etc.

348


ISSN:2249-5789
Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357

proposed architecture, especially for critical DNS
zones, such as the .com zone.

.
In 1987 the original DNS RFCs 882 and 883 were
replaced by RFCs 1034 and 1035 respectively and
updated the DNS specifications based upon
implementations of RFCs 882 and 883. Both the
RFCs 1034 and 1035 are the core standards upon
which the DNS is based. DNS has been modified to
address new requirements time and again to
incorporate changes to the DNS operational
environment.

2. Literature Review

Steven Cheung et. al. in their paper “ FormalSpecification Based Approach for Protecting the
Domain Name System” [5] formally specify a DNS

wrapper that examines the incoming and the
outgoing DNS messages of a name server to detect
messages that could cause violations of the security
goal, cooperates with the corresponding
authoritative name servers to diagnose those
messages, and drops the messages that are
identified as threats. Based on the wrapper
specification, they implemented a wrapper
prototype and evaluated its performance.
Xunhua Wang, Yih Huang et. al. In their paper
“Enabling Secure On-line DNS Dynamic Update”
[6] point out two difficulties in the current
DNSSEC (DNS Security Extension) standards in
the handling of DNS dynamic updates:
a) On-line storage of a zone security key,
creating a single point of attack for both inside &
outside attackers,
b) Violation of the role separation principle,
which in the context of DNSSEC separates the
roles of zone security managers from DNS server
administrators.
To address these issues, they propose a secure DNS
architecture that is based on threshold
cryptography. They show that the architecture
adheres to the role separation principle without
presenting any single point of attack and also show
experimental results revealing that, in terms of
signature computation times, their architecture
incurs negligible performance penalty when using
RSA/MDS signatures but significant overhead

when using DSA signatures. They believe that the
high level of security can be achieved by their

Yih Huang Yih et.al. in their paper “Securing DNS
Services through System Self Cleansing and
Hardware Enhancements” [7] try to develop a
secure DNS architecture that contains the damage
of successful, undetected attacks. They achieve this
by constantly cleansing the servers and rotating the
role of individual servers. Moreover, the server
rotation process itself is protected against
corruption by hardware. They show the advantages
of our design in the areas of protection of the DNS
master file and cryptographic keys, incorruptible
intrusion tolerance, high availability, and
scalability, the support of using of high degrees of
hardware/server redundancy to improve both
system security and service dependability.
Suranjith Ariyapperuma et. al. in their paper
“Security vulnerabilities in DNS and DNSSEC “
[8] highlight some of the security vulnerabilities in
the Domain Name System (DNS) and the DNS
Security Extensions (DNSSEC). DNS data that is
provided by name servers lacks support for data
origin authentication and integrity by using digital
signatures. Although DNSSEC provides security
for DNS data, it suffers from serious security and
operational flaws. They point out with DNS and
DNSSEC architectures, and consider the associated
security vulnerabilities

Christof Fetzer et.al in their paper “Enhancing
DNS Security using the SSL Trust Infrastructure”
[9] point out some of the shortcomings of the
current secure DNS (DNSSEC) standard like,
online updates and denial of service attacks etc
which are serious obstacles that might prevent
DNSSEC from replacing the traditional DNS. To
address these issues, they propose a simple
extension to the existing DNS. It is SSL based and
individual domains can decide independently of
each other if and when to adopt the extensions.
They show how to implement these extensions with
the help of a simple proxy DNS server.
Yong Wan Ju et. al .in their paper “Cache
Poisoning Detection Method for Improving
Security of Recursive DNS” [10] propose a new
detection method for cache poisoning attack on the
recursive DNS. The proposed method overcomes
the weak-points of the previous researches such as
DNSSEC and DoX system which are hierarchical
or vertical additional deployments of several DNS
servers, accordingly overall performance of the
system is decreased and additional traffic cost is
needed. That is to say, the proposed method sets
forth independent cache poisoning detection
method with the similar security level of DNSSEC,
notwithstanding the the improvement, there is little

349

ISSN:2249-5789
Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357

influence on DNS performance and additional
traffic.

The DNS database to procure the information
required.

Daniel Massey et. al. in their paper “ Public Key
Validation for the DNS Security Extensions “ [11]
say that t he deployment of DNS Security
(DNSSEC) can only succeed if there is an effective
mechanism for DNS public key validation. This
paper compares three potential approaches to DNS
key validation. A tree based approach utilizes the
existing structure of the DNS tree to form highly
structured key signing rules. This makes following
chains of trust simple, but it allows no flexibility
for individual zones and makes incremental
deployment impossible. A pure web of trust based
approach imposes no structure what so ever on the
key signing process. This lack of structure provides
a high degree of local control, but also makes it
difficult to find trusted chains or specify security
policies. The third approach is a new proposal
based on a the concept of a fault-tolerant mesh of
trust. The mesh approach utilizes some structured
elements from the tree-based approach while

maintaining the local flexibility found in the web of
trust. Our analysis shows the hybrid mesh approach
has the best chance of succeeding in the Internet.

3.1 DNS organization and infrastructure

David Conrad in his paper “Towards Improving
DNS Security, Stability and Resiliency” [12]
discusses in detail about some of the attacks how to
mitigate them.

3. The DNS in Operation
DNS is a distributed database system spread across
multiple DNS servers which allows the resolution of
domain names into their respective IP addresses.
The queries result in responses in the form of IP
addresses which are stored in the DNS databases in
the form of Resource Records abbreviated as RRs.
A domain name may consist of several strings
separated by dots which represent administrative
boundaries. For example, the dot between “gmail”
and “com” in the domain name “www.gmail.com”
represents the administrative boundary between the
“com” top-level domain and Gmail, the company
responsible for “gmail.com.” The Internet‟s DNS is
a single large tree, read right-to-left, with
progressively more specific administrative units to
the left.7
Within a DNS tree, each administrative unit is called
a „zone‟. For example, the “wikipedia.org” zone is

the piece of the DNS tree including all names ending
in “.wikipedia.org.” Further subdivisions are
possible like “wikipedia.org” might have multiple
zones, such as “en.wikipedia.org” The DNS lookup
occurs each time a user enters a URL in a web
browser. The application typically uses an
intermediate system called a resolver to navigate

Beneath the seemingly simple DNS look-up service
lies a complex logical and administrative
infrastructure. The DNS name resolution service
uses a data repository, organized as a globally
distributed database that‟s largely structured after
the hierarchical domain name space, or DNS tree.
At the top of the hierarchy is the root, a single
domain represented by a dot (“.”). Below the root
are top-level domains (TLDs), whether generic (for
example, .com, .gov, or .edu) or country-specific
(such ccTLDs include .de, .uk, and so on).
The next level consists of enterprise level domains
(ELDs) owned by commercial, government, or
academic organizations such as nist.gov or mit.edu.
A large enterprise generally has administrative
control over a given zone, classified as an ELD,
and a set of sub-domains. Thus, a zone refers to an
administrative entity in the DNS that provides DNS
services for a group of domains. The term “zone”
has percolated up to the top levels, and the terms
root zone, TLD zone, and ELD zones are often
used. The information flow in the DNS takes place

primarily among three distinct system entities:
authoritative name servers, stub resolvers, and
caching name servers, also called resolving /
recursive name servers or resolvers. Different type
of DNS Servers work together to provide the replies
to the DNS lookups performed by majority of the
applications.

3.2.Authoritative servers
Every authoritative name server is associated with
a zone and, as its name denotes, is the authoritative
source for DNS data pertaining to that zone. To
provide fault tolerance, effective administration,
and
efficient
name
resolution,
several
geographically
and
logically
distributed
authoritative name servers exist for each zone.
These are further classified into primary name
servers, which maintain authoritative DNS data in
zone files, and secondary name servers, which
frequently refresh their contents from the primary
name servers. The Authoritative servers respond to
the query in one of the following ways: A positive response with an answer.
 A negative response indicating the answer

does not exist
 A referral response where to find further
information.
The authoritative servers are typically operated by or
on behalf of zone administrators. ISPs, DNS
registrars, and hosting providers often operate
authoritative servers on behalf of their customers.
The authoritative DNS infrastructure, particularly for

350


ISSN:2249-5789
Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357

“high value” zones such as top-level domains, are
generally outsourced to DNS-focused service
providers, such as Verisign, Afilias, and Neustar.

3.3. Stub resolvers
Stub resolvers are lightweight clients that formulate
DNS look-up queries on behalf of applications,
such as Web browsers or email servers and send
them to caching name servers. Stub resolvers don‟t
usually have any caching features. Caching name
servers each serve multiple stub resolvers.

domain to other name servers. The root servers
know the name servers for domain1.com and within
those name servers the west.domain1.com domain

is delegated to another set of name servers that
manage that portion of the overall domain1.com
domain. In most cases, domains and their records
are either managed directly by the organization
owning the domain or by the ISP that provides the
Internet connection for the organization.

Depending on the zone or domain requested, they
either query the appropriate authoritative name
servers or serve responses from their own caches
built from previous queries.

3.4. Resolver
The DNS clients use a resolver to request resolution
of a host name to an IP address. The resolver is an
application which acts as an intermediary between
name servers and various applications such as Web
browsers, e-mail applications, etc that need name
resolution. A DNS resolver acts on behalf of client
software to retrieve information about a particular
domain name. For example: Assuming that your
browser has to connect to www.abc.com. Then local
resolver creates a DNS query and sends it to the
name server(s) listed in the local computer‟s TCP/IP
settings. In the case of smaller enterprises and end
users, Internet service providers typically operate
resolvers. In the case of larger enterprises, the
resolvers are usually operated by the enterprises
themselves or by large-scale DNS hosting providers

4. How DNS works
DNS functions as a distributed database using a
client/server relationship between clients and the
servers that maintain DNS data. This distributed
database structure enables the DNS to be dynamic
and decentralized, allowing control over their own
portion of the DNS database by local domains and
also enabling clients to access the database.
At the topmost level there are the root servers (.)
which represent the period. They are 13 in numbers
(ROOT-SERVERS.NET) and are distributed across
the globe. The root servers maintain the database
for the top level domains (gTLDS-SERVERS.NET)
i.e .com, .net, .org, .mil, .edu, .gov, .int. etc. These
top level domain servers typically maintain data
only about the name servers which are authoritative
for a particular domain. The authoritative name
servers, contain data about primary name servers or
delegated name servers for that particular domain.
Finally these name servers maintain data for the
individual
domains.
These authoritative name servers maintain the
records for a domain or delegate some of or the

Image source: Verisign Domain Name Industry
Brief, June 2007 (PDF), last page.
There are two parts in the DNS Tree namely - a root
zone file and different name servers that act as the
“Root Servers”. The root zone file is small and lists

all top-level domains along with name servers for
respective domains. The root zone file is managed
by three different organizations: ICANN, the U.S.
Dept. of Commerce and Verisign. ICANN [13] is
responsible for accepting and validating changes
from various top-level domain authorities and then
suggesting the necessary changes in the root zone
file which are then authorized by the U.S. Dept. of
Commerce‟s National Telecommunications and
Information Administration (NTIA) and then
Verisign finally applies the updates, signs the zone
using DNSSEC and publishes the revised root zone
file on a “distribution master” server.

351


ISSN:2249-5789
Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357

The 13 root name servers are operated by the 12
independent organizations [14]. These root name
server operators fetch the root zone file from the
distribution master server which is maintained by
Verisign and then publish the information on the root
name severs which they operate independently.
Many of these root name servers are clusters of
machines which are distributed globally at multiple
locations/sites and share information using
“Anycast” routing technique. The summary of these

servers are as follows:Root
A
B
C
D
E
F
G
H
I
J
K
L
M

Organization
Sites
Verisign
6
University of Southern California,
1
Information Sciences Institute
Cogent Communications
6
University of Maryland, College Park
1
U.S. NASA Ames Research Center
1
Internet Systems Consortium, Inc.
49

U.S. Department of Defense,
6
Network Information Center
U.S. Department of Defense, Army
2
Research Lab
Netnod
38
Veisign
70
RIPE NCC
18
ICANN
39
WIDE Project
6

4.1. How DNS lookup works
The DNS clients use a resolver to request
resolution of a host name to an IP address. The
resolver is an application which acts as an
intermediary between name servers and various
applications such as Web browsers, e-mail
applications, etc that need name resolution. A DNS
resolver acts on behalf of client software to retrieve
information about a particular domain name. Let us
say that, a browser has to connect to
www.abc.com. then its local resolver creates a
DNS query and sends it to the name server(s) listed
in the local computer‟s TCP/IP settings.

The sequence of events to get the IP address for
www.abc.com are - First the computer queries the
name server (DNS server) it is set up to use. This is
the recursive name server shown above. If the
name server doesn‟t know the IP address for
www.abc.com, so it will start the following chain
of queries before it can report back the IP address
to the calling computer.
1.
2.

Query the Internet root servers to get the
name servers for the .com TLD.
Query the .com TLD name servers to get
the authoritative name servers for
abc.com.

3.

4.

Ask the authoritative name servers for
abc.com to finally get the IP address for
the host www.abc.com, then return that IP
address to your computer.
Finally the computer has the IP address
for www.abc.com, it can access that host.

If there is a connection to the ISP then the ISP‟s
name servers resolves the query. The resolver

sends the DNS resolution request to the first of the
name servers as specified in the local TCP/IP
settings. The server checks its cache of previously
resolved names, for abc.com so, that name server
sends a DNS query to the root server for the .com
domain. The root server responds with the
addresses of the name servers that are authoritative
for the abc.com domain.
The ISP‟s name server then builds another request
for www.abc.com and submits it to the abc.com‟s
49
name server, which responds with the IP address of
www.abc.com. This information is passed back to
the resolver, which gives it to the calling
application. As a result abc.com‟s Web site appears
in the browser. Resolving a host name to an IP
address is called forward lookup.
Caching is an important part of the operation of the
DNS. At each stage along the way, from application
to resolver to name server, information may be
cached. In normal DNS operation, to improve
performance, the resolver will store the responses
and referrals it has received so that future lookups
for the same information can be answered
immediately. Caching is used to avoid sending
queries across the network to DNS servers, speeding
response time. Because caching is an expected part
of DNS operation, each domain name response
(resource record) includes a “time to live” (TTL)
value indicating how long information may be

cached.

4.2. DNS Security Extensions (DNSSEC)
DNSSEC (DNS Security Extensions) is an important
tool in increasing the security of the Internet‟s
Domain Name System.
It is a set of extensions to the DNS for providing
authentication and performing integrity checking of
DNS data. Authentication ensures that zone
administrator can provide authoritative information
for any particular DNS domain and integrity
checking ensures that information cannot be
modified accidentally or maliciously while in transit
or in storage in the DNS. DNSSEC provides a strong
cryptographic signature of DNS data that the
DNSSEC compliant resolvers can verify to ensure
that the data received over the network hasn‟t been
modified since it was originally DNSSEC-signed.

352


ISSN:2249-5789
Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357

In DNSSEC, the server and the resolver both have to
be security aware as the DNS server is required to
support some additional types of DNS records.
Likewise the resolver should be able to detect the
new DNSSEC extensions and must check DNS data

for authentication and data integrity. Any
modification of the DNS data from what was
originally signed at the authoritative source can be
detected, thereby allowing a security-aware DNS
resolver to discard corrupt or unauthorized data.
Although DNSSEC was standardized in 2005, it is
not commonly used. However, adoption of DNSSEC
is expected to accelerate as the root DNS zone was
signed in July 2010.

can misdirect name resolution mapping, opening
network data to capture inspection and potential
corruption.
Many other types of threats have also been seen in
which DNS system is used to carry out attacks on the
other assets. These different types of threats to the
DNS, can be broadly categorized as below:
• Denial of Service – In this type of attack the
Internet users are kept away from using the DNS
• Data Corruption - In this case there will be
unauthorized change of information in the DNS)
• Information Exposure – Here the information is
disclosed about Internet users after examining their
DNS traffic.

5. DNS Threats
Since DNS is critical to the operation of the Internet,
it must be secure from different types of threats and
risks. This portion provides information on some of
the existing threats which lead to DNS failure and

their counter measures for mitigating such risks. A
variety of threats have been seen to the DNS system
including threats to the DNS infrastructure itself. The
most common types are :-

5.1. DNS Spoofing
DNS spoofing means that a computer on the
Internet has been able to advertise a false IP
address for itself. This is due to the easy setting up
of one s DNS resolver and feeding it with false
information. It can also be done by the following:1.

A malicious DNS advertises false IP
address to a victim. Subsequent DNS
queries are sent bogus IP address, traffic is
sent to wrong host.
2. Java applets could be created to spoof IP
address in order to penetrate into insecure
server. This unprotected server in a
network thinks that it being contacted by a
trusted host but in fact, the machine on the
end of the connection is operated by some
malicious users.
DNS Spoofing is a serious attack based on the
strong trust relations between client machine and
their DNS server. The DNS server can be attacked
in many different ways but all rely on the
translation between Domain Name and IP address.

5.2. Cache Poisoning

Another security concern regarding to DNS is the
process of Cache Poisoning. It is a process where
attacks are launched on cache data of DNS in order
to misdirect and intercept packets on domain name
servers. One simple type of attack is where bogus
data from a remote name server is offered to a
genuine name server, which in turn stores the
misleading data in its cache. By providing false
host name and mapping information, the attacker

5.3. Denial of Service
It is the most significant threat to the DNS and
also the hardest to defend against. In DOS, The
attacker purposefully tries to disrupt service by
creating failure / mistakes, in the DNS
infrastructure itself by performing some malicious
activities. This results in DNS becoming slow or
inaccessible and is often called a Denial of
Service (DoS) attack. In many a cases, both
human as well as automated systems users of the
DNS face increased delays, timeouts, and other
performance related issues. The worst-case may a
complete disruption of all DNS-related and DNSdependent services. Denial of Service threatens
the DNS security, integrity and stability of its
internal sub-component.
Within this category two different types of DOS
have been seen:(1). Resource Starvation – Insufficient resources
here the attacker tries to misuse the system
resources like server CPU, memory, internet
bandwidth etc because of which the DNS service

becomes slow. The attacker tries to flood the
network, switches, routers etc. with bogus traffic
or tries to block the legitimate DNS requests and
replies and disrupt the normal working of the
DNS infrastructure.
(2). Resource Disruption – The attacker tries to
disrupt the normal working by creating events
which make the resources unavailable until some
external event restores the resource - typically
creates intentional electrical power failure which
will bring down the servers till the power is
restored.
The threat of DoS covers all components of the DNS
including:
1. Physical & network infrastructure buildings, power supplies, network
connections

353


ISSN:2249-5789
Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357

2.

3.

4.

Server infrastructure - servers and related

system that allow for DNS queries to be
sent and received
Management infrastructure - processes that
allows for the creation, modification, and
deletion of DNS content
Administrative infrastructure - support
agreements and procedures, staffing,
invoicing, and similar arrangements

5.4 Data Corruption
Data Corruption in DNS can happen because of
different reasons. Some of the reasons are:1. When DNS responses don‟t match the
intended, published data.
2. When someone has intentionally or
accidentally changed the data in DNS
servers in un-authorized ways.
3. As DNS queries and responses pass over
the Internet, over an intermediate DNS
server (resolver) which might have corrupt
or incorrect data inserted into their cache
because of attacks called as cache
poisoning.
4. When an attacker sends answers to queries
faster than the legitimate servers can,
providing erroneous data to the application.

5.5.Information Exposure
The DNS protocol was originally designed as a
mechanism to associate named resources to
addresses without any concern for Privacy

protection.
DNS queries and responses are
transmitted without any form of encryption, and
hence can be observed at multiple points. DNS
operators may also be capable of correlating requests
and using them for other purposes. At the same time
there is a requirement that individuals should be able
to use the DNS and the related WHOIS protocol in
an anonymously as it would let the individuals
perform DNS queries without having their requests
observed and correlated with their identity.
Besides the above mentioned threats some more
types which are not immediate operational type have
been observed as follows:-

minimum security restrictions are imposed by the
routers and firewalls on its traffic. As a result, DNS
traffic has been used for several forms of attack.
5.7.1. Fast Flux DNS
As defined by ICANN‟s Security and Stability
Committee “Fast flux” is an evasion technique used
by the cyber-criminals and Internet miscreants to
evade their identification, location and shutting
down such web sites that are used for illegal
purposes.28. In Fast Flux DNS, networks of typically
compromised servers by malware are used as name
servers. This allows for rapid changes to DNS-related
data, and helps attackers to delay or evade detection
and mitigation of their activities.
5.7.2. DNS as a Hidden Channel

DNS requests and responses can be used as a hidden
channel for communications [16]. Several cases have
been documented in which DNS has been used as the
mechanism for communications between botnet
command and control servers of the systems that
make up the botnet.. Some tunnelling protocol like IP
over DNS and TCP over DNS have been developed
by the cyber criminals that allow arbitrary data to be
passed over the DNS protocol. Thus using such
techniques DNS can be used by attacker to bypass
network security mechanisms and compromise other
internal systems.
5.7.3. Application Corruption Attacks
Similarly maliciously created DNS responses can be
used to corrupt some applications. In some cases,
DNS responses can cause unexpected application
behaviours. They may be used to compromise
systems. As has already seen in web application,
huge amounts of SQL injection and cross-site
scripting attacks can lead to different types of attacks
on the network resources. It may be assumed that
any data obtained over a network channel could be
intentionally malicious or accidentally malformed.
In cases where application or library source code is
unavailable [17], some caching resolvers have
configuration options that allow filters to be applied
to responses to reduce the risk of malicious data
being supplied to applications.

6. Mitigating DNS Threats

5.6. Ossification
Issues related to maintaining backward compatibility
and implementing future upgrades resulting due to
technological improvements is a critical problem.
Such a situation has been broadly termed as
ossification [15] . Due to ossification DNS has lesser
ability to adjust to future changes in the Internet.
Ossification has also delayed the deployment of
upgrading of technologies which are needed for
security, stability of the DNS.

The DNS has a number of features as part of the
original design or incorporated later on that make it
resilient to many forms of disruption and attack.
Some such recent additions to the DNS system are
“DNS Security Extension” also known as the
DNSSEC and operational practices such as the
deployment of “Anycast” [18] which provide
increased protection against many of the common
threats to the DNS.

6.1. Denial of Service Threats
5.7. Threats from the DNS
Since DNS is a core component of internet hence

The mitigations for all forms of DoS attacks
can be done by:

354

ISSN:2249-5789
Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357

a)

By way of over-provision the infrastructure
to withstand attacks
b) Spreading out the infrastructure to different
geographic locations, using independent
facilities, systems and other technologies to
remove the choke points
c) Utilizing operational best practices that
apply to other core IT systems, with welldocumented and mature processes and
procedures that are reviewed and updated
regularly.

6.2. Stub Corruption
Trusted stub resolver and its network path should be
used. It should be verified that the IP Address for
DNS resolution services that are mentioned at
/etc/resolv.conf on Unix-related systems and in the
registry in Windows systems are the correct
expected values. Using DNSSEC will mitigate some
of corrupted resolution paths.

6.3. Caching resolver corruption
Timely application of security packs and systems
updates ensure that they are guarded against the
known threats. Although implementation of name

server allows a server to act as caching resolver and
also as an authoritative server, they should not be
hosted on the same box. As a best practice,
separation of authoritative name service from
caching resolution service should be done as it will
mitigate various forms of data corruption such as
cache poisoning and inappropriate responses to the
authoritative queries.

6.7 Query Prediction

As discussed in “DNS Threat Analysis” [20], every
message in the DNS has a 16-bit query identifier that
is used to match responses to queries. In
combination with the 16-bit source port, this gives a
total of 32 bits to uniquely identify a DNS
transaction between any given source and
destination. As early as 1986, it was recognized that
this provided only a weak defence against injection
of bogus responses by a malicious third party. In
particular, it is possible to take advantage of “the
Birthday Paradox”, to predict a query identifier and
then inject a response [21].

6.8. Man-in-the-Middle
DNS traffic is not encrypted. An attacker with
control over the intermediate network can implement
a variety of man-in-the-middle attacks.

6.9. Cache Poisoning

Predicting queries and man-in-the-middle attacks
allow for an attacker to insert bogus data into a
cache, an attack known as cache poisoning,
discussed in detail above. The key mitigation for all
of these protocol corruption attacks is DNSSEC,
which allows a security-aware resolver to verify that
the DNS data have not been modified in transit.
With this capability, it no longer matters that an
attacker can predict query identifiers, can sit in the
middle of a DNS transaction, or can attempt to
poison the cache since any attempt to modify the
DNS data will be detectable.

6.10. Data Corruption
6.4. Intermediate systems
Intermediate systems are critical as they play an
important role in DNS resolutions and hence should
be updated timely. By using DNSSEC any
modifications of data in transit can be detected by
the validating resolver. Unfortunately, the use of
DNSSEC is hampered by middle-boxes that inhibit
used of DNSSEC by incorrectly handling requests
that ask for DNSSEC-signed responses or the
responses themselves [19].

6.5.
Authoritative
mitigation

server

corruption

In addition to mitigations previously discussed, it is
important to ensure the DNSSEC keying material is
managed to minimize the chance that an attacker can
steal keying material and impersonate an
authoritative server. Best practices for DNSSEC
deployment use “offline signing keys” minimizing
the possibility of key theft.

6.6. Protocol Corruption
Protocol Corruption takes advantage of limitations
or vulnerabilities in the DNS protocol itself to
corrupt DNS data. There are three broad categories
of Protocol Corruption:

DNSSEC can be used to guard against data
corruptions as it was primarily designed for this
reason. Other techniques like constant vigilance of
the system resolvers and application of necessary
security patches should be done.

6.11. Information Exposure
Information Exposures are unauthorized releases of
personal and other data associated with the DNS and
DNS queries. These exposures can occur at both the
administrative level as well as at the network and
system level with attacks known as “Cache
Snooping” and “Zone Walking”. Protecting against

Cache Snooping related to authoritative servers.
General protection of data including secure data
paths and methods to protect against system
compromise are the countermeasures.

6.12. Mitigating DNS as a hidden Channel
Mitigation of hidden channel use of DNS requires
detection. Constant monitoring may help to detect
unusual use patterns, such as a large number of TXT
responses being sent to a particular server. Analysis
of DNS traffic within an enterprise can provide a
baseline to detect the hidden channel DNS problems.

355


ISSN:2249-5789
Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357

7. Our Approach
Internet supports both TCP based (port no 53) and
UDP based (port no 53) transport mechanism for
DNS. However majority of the communication is
UDP based. Since DNS does not necessarily require
the establishment of a TCP connection it allows the
attacker to redirect the response away from its
network to the victims host by spoofing the source IP
address as the victims IP address. By exploiting this
vulnerability the attacker sends a small request to the
DNS server to which the server may respond with a

very large reply. This large reply can be redirected
by the attacker to the victim machine and thus
consume most of the victim‟s resources. Daniel
Bernstein has reported that a 36-byte DNS query can
result in a 3995-byte DNS response.

a proper handshake actually takes place. The sender
sends the FIN packet which is acknowledged by the
receiver by an ACK packet and if the receiver also
wants to terminate the connection at the same time
it also sends a FIN packet to the sender. This FIN
packet is once again acknowledged by the sender
by sending ACK packet.
By using the above concept it can be ascertained
that the communications to the DNS servers are
being send by legitimate DNS Resolvers and
servers. Hence it is suggested that all DNS based
communication TCP should be used as the transport
mechanism rather than UDP as it will greatly
improve the security aspects of DNS.
References:-

Such attacks are classified as DNS amplification
attacks as it amplifies the attacker‟s ability to
consume resources on the victims system. Since
DNS queries are small, the attackers queries can go
undetected which might lead to a distributed denial
of services attack on the victim‟s system. Since a
spoofed IP address is used by the attacker it becomes
very difficult to trace such attacks.DNS has been

used for amplification attacks for some time, DNS
Amplification attacks make use of either
authoritative servers or resolvers to reflect data
towards a target.
As per the frame format defined for DNS in RFC
1035 there is a 16 bit field called identifier which
can be assigned value by the program that generates
any kind of query. This identifier is copied in the
corresponding reply and can be used by the
requester to match up replies to outstanding queries.
However there is no provision for any kind of
sequence numbers.
As most of the communications are UDP based
hence there is no mechanism to check whether the
packets coming in or going out are legitimate nor
not. This forms the basis for generating different
types of attacks like DNS Spoofing, Cache
Poisoning, Zone corruptions, Session Hijacking,
Data corruption, Protocol corruption etc. Although
the use of UDP makes the system faster yet it is
suggested that all DNS based communications
should be TCP based rather than UDP.
When TCP is used for communication then a threeway handshake will take place for graceful
communication to happen. The sender will send a
SYN packet which will be acknowledged by the
receiver by sending back the SYN ACK packet
which is again acknowledged by the sender by
sending an ACK packet after which the data
transfer phase begins.
When a TCP connection closes gracefully then also

1. />01-24dnspr.mspx
2. />dd
os_attack_on_dns_hits_amazon_and_others_briefly.html
3. />4. />5.“Formal-Specification Based Approach for Protecting
the Domain Name System By Steven Cheung,
Department of Computer Science, University of
California, Davis, CA 95616, and Karl N. Levitt,
Department of Computer Science, University of
California, Davis, CA 95616
6 “Enabling Secure On-line DNS Dynamic Update” by
Xunhua Wang, Yih Huang, Department of Computer
Science, George Mason University, Fairfax, VA
22030
USA , Yvo Desmedt, Department of Computer
Science, Norida State University, Tallahassee,
FL 32306 USA and David Rine, Department of
Computer Science, George Mason University,
Fairfax,
VA 22030 USA
7 “Securing DNS Services through System Self
Cleansing
and Hardware Enhancements” by Yih Huang, David
Arsenault, and Arun Sood , Department of
Computer Science and Center for Image Analysis,
George Mason University, Fairfax, VA 22030
8 “Security vulnerabilities in DNS and DNSSEC” by
Suranjith Ariyapperuma and Chris J. Mitchell,
Information Security Group, Royal Holloway,
University of London, Egham, Surrey TW20 0EX,

UK
9 “Enhancing DNS Security using the SSL Trust
Infrastructure”by Christof Fetzer and Gert Pfeifer,
Dresden University of Technology, Department of
Computer Science, Institute for System Architecture,
01062 Dresden, Germany and Trevor Jim, AT&T
LabsResearch, 180 Park Ave., Florham Park, NJ, 07932,
USA
10 “Cache Poisoning Detection Method for Improving
Security of Recursive DNS” by Yong Wan Ju, Kwan
Ho

356


ISSN:2249-5789
Alok Pandey et al , International Journal of Computer Science & Communication Networks,Vol 3(6),347-357

Song, Eung Jae Lee, National Internet Development
Agency of KOREA and Yong Tae Shin, Internet
Communication and Network Lab., Soongsil Univ.
11 “Public Key Validation for the DNS Security
Extensions” by Daniel Massey, USC / ISI , Ed Lewis,
Network Associates, Inc., , Olafur
Gudmundsson, Ogud.com, Russ Mundy, Network
Associates, Inc., Allison Mankin, USC/ISI
12 “Towards Improving DNS Security, Stability and
Resiliency” by David Conrad, Internet Society.,
www.internetsociety.org
13 In this case, ICANN is acting in the role of the Internet

Assigned Numbers Authority. This role could be moved
to another organization, but the function would be same.
14 t- servers.org/ www.internetsociety.org
15
/>/ossification
16
/>DNS_Exfiltration_2011-01-01_v1.1.pdf
17 d/ 844360
18 />19 />20 />21
/>
Biographical notes
Alok Pandey is Senior Systems manager and
faculty member at B.I.T. (MESRA), Jaipur
Campus. His qualifications include B.E.(EEE),
MBA. He has also done MCSE, RHCE, CCNA,
IBM Certified E-Commerce and diploma in Cyber
law. He has a rich industrial working experience of
more than 17 years and also a teaching experience
of about 9 years in the areas of Data
Communication
and
Computer
Networks,
Information Security, E-Commerce, Systems
Management , ERP etc. He is also a member of
CSI, IAENG and ISOC. His research interests
include Computer Networks and Network Security.
Dr. Jatinderkumar R. Saini is Ph.D. from Veer
Narmad South Gujarat University, Surat, Gujarat,
India. He secured first rank in all three years of

MCA in college and has been awarded gold medals
for this. He is also a recipient of silver medal for
B.Sc. (Computer Science). He is an IBM Certified
Database Associate-DB2 as well as IBM Certified
Associate Developer-RAD. He has presented 14
papers in international and national conferences
supported by agencies like IEEE, AICTE, IETE,
ISTE, INNS etc. One of his papers has also won
the „Best Paper Award‟. 11 of his papers have been
accepted for publication at international level and
13 papers have been accepted for national level
publication. He is a chairman of many academic
committees. He is also a member of numerous
national and international professional bodies and
scientific research academies and organizations.

357