simplified tcp based communication approach towards domain ... · pdf filesimplified tcp based...

Simplified TCP Based Communication Approach towards Domain Name

System for Improving Security

Alok Pandey1, Dr. Jatinderkumar R. Saini

2

1 Sr. Systems Manager, Department of Computer Science Engineering, Birla Institute of Technology Mesra,

Jaipur Campus, Rajasthan, INDIA . e-mail :[email protected]

2

Director (I/C) & Associate Professor, Narmada College of Computer Application, Bharuch,

Gujarat , INDIA. e-mail: [email protected]

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

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.

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.

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-

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

347

ISSN:2249-5789

mailto:[email protected]

http://www.mysite.com/

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.

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 machine-

oriented numbers. Any large-scale disruption of the

DNS would make the Internet unusable.

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-to-

address 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 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 name-

address tables hence some sort of hierarchical name-

space partitioning should be devised to deal with

recording and maintaining such details of every

internet host.

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.

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 tree-

structured 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 Zaw-

Sing 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 inter-

process 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

.

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 “ Formal-

Specification 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

proposed architecture, especially for critical DNS

zones, such as the .com zone.

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

influence on DNS performance and additional

traffic.

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.

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

The DNS database to procure the information

required.

3.1 DNS organization and infrastructure 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

http://www./

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

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

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.

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

http://www.abc/

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 Organization Sites

A Verisign 6

B University of Southern California,

Information Sciences Institute

1

C Cogent Communications 6

D University of Maryland, College Park 1

E U.S. NASA Ames Research Center 1

F Internet Systems Consortium, Inc. 49 49

G U.S. Department of Defense,

Network Information Center

6

H U.S. Department of Defense, Army

Research Lab

2

I Netnod 38

J Veisign 70

K RIPE NCC 18

L ICANN 39

M 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. Query the Internet root servers to get the

name servers for the .com TLD.

2. Query the .com TLD name servers to get

the authoritative name servers for

abc.com.

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

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

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

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.

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

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.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 DNS-dependent 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

2. Server infrastructure - servers and related

system that allow for DNS queries to be

sent and received

3. Management infrastructure - processes that

allows for the creation, modification, and

deletion of DNS content

4. 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:-

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.

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

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 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 The mitigations for all forms of DoS attacks

can be done by:


354

ISSN:2249-5789

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 well-

documented 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.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 server corruption

mitigation 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:

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

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.

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 three-

way 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

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:- 1. http://www.microsoft.com/presspass/press/2001/jan01/

01-24dnspr.mspx

2.http://www.pcworld.com/businesscenter/article/185458/dd

os_attack_on_dns_hits_amazon_and_others_briefly.html 3.http://www.iis.se/en/pressmeddelanden/felaktig-dns-

information-2

4. http://www.securityweek.com/content/reports-massive-

dns-outages-germany 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 Labs-

Research, 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

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., [email protected], 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 http://www.root- servers.org/ www.internetsociety.org

15 http://www.merriam-webster.Com/dictionary

/ossification

16 http://www.oe.energy.gov/DocumentsandMedia/

DNS_Exfiltration_2011-01-01_v1.1.pdf

17 http://www.kb.cert.org/vuls/ d/ 844360

18 http://www.ietf.org/rfc/rfc4786.txt 19 http://www.icann.org/en/committees/security/sac035.pdf

20 http://tools.ietf.org/html/rfc3833

21 http://www.secureworks.com/research/articles/dns-

cache- poisoning

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

ISSN:2249-5789

http://www.internetsociety.org/

http://www.ietf.org/rfc/rfc4786.txt/

http://www.icann.org/en/committees/security/sac035.pdf/

http://tools.ietf.org/html/rfc3833/