Protecting DNS from Cache Poisoning Attack

by Using Secure Proxy

Talha Naqash ,Faisal Bin Ubaid, Abubakar Ishfaq,Fazal-e-Hadi
Department of GS&AS
Bahria University
Islamabad, Pakistan
Talha.Naqash@yahoo.com; faisalubaid@gmail.com ; abubakar_2626@yahoo.com; fhadi76@gmail.com

Abstract The DNS is one of the most important part

of the Internet communication. DNS server runs a
robust mechanism which provides the IP address of the
internet host name. Even if the any component of this
internet communication is unavailable for short interval
then the whole internet communication will be
disturbed or some time stop responding. When a DNS
server sends a query to the specific server then an eves
dropper can launch cache poisoning attack easily. Many
solutions have been proposed which have their own
pros and cones. In this paper a proposed solution is
described by using security proxy with a hash function.
Cache Poisoning attack can be avoided by using this
technique. It creates a secure environment for the DNS
to communicate with other DNS. When the source DNS
receives any response from any DNS it will check the
authenticity of receiving packets and send the data to
the client. This technique provides secure environment
for DNS communication. This new technique is easy to
implement on the current DNS architecture without any
modification.
Key Word: DNS, SHA, Proxy, Poison attack.

INTRODUCTION
Domain name System is a layer wise computergenerated database that creates a link between the
user friendly domain name and IP address of the that
specific domain and vice versa. We depend upon the
DNS server to know the IP address, so we can look
through the required website, receive and send the
email, online shopping , checking bank account status
etc. On the other hand, if a little part of the DNS is
disrupted for few seconds then the whole
communication on the internet in that specific region
will be distressed. Stub-Resolver generate the DNS
queries for the targeted DNS[1]. UDP protocol is
used by the DNS and 16 bit ID is used for response
authentication. If the ID is compromised then
attacker can send a forged response, which can be

updated by the authoritative server. this is called

cache poison attack [2]. Cache Poison attack is a big
issue under discussion for a long time. People
working to sort out this problem . Most of algorithms
provide the solution to secure the ID. But it is easy to
spoof the ID by an attacker then researchers try to
encrypt the ID and tries to generate ID in various
fashions, so an eves dropper could not guess the ID.
But there are only 216=65536 ID combinations so a
new technique is introduced called Source port
randomization[3]. DNS normally used port number
53 for the communication. But in this method random
port are used to send and receive data. Different
combinations of ID and ports make it more difficult
for an attacker to guess the right combination, but a
professional attacker with high computational
systems can still launch the attack in a specified
time[3]. Another method called 0*20, in which case
sensitive domain name is used for authentication[4].
this method gain much fame to secure DNS because
it increase the complexity so much for an eves
dropper but all DNS are not case sensitive so DNS is
not fully safe. DNSSEC and TSIG methods avoid the
cache poison attack to some extend by using
authentication mechanism but there are still much
chance to compromise a DNS[5].
To improve the security of the DNS there is need
to avoid the useless adjustment. A novel technique is
proposed called secure proxy with hash function.
current DNS architecture just need a little
modification to deploy this new protocol. This
protocol secure the DNS from fake or rouge packets
as well as authentication of the packet. In this scheme
security proxy work like the normal proxy, receive
and send data for DNS server. Our novel technique
provide the more security and enhance efficiency.
The reset of the paper is organized as follows in
the section related work many the existing and

proposed schemes will be discussed, then next

section gives the brief introduction of the proxy
architecture. Then detail of the cache poisoning
attack is given then proposed solution then gives
comparative analysis and conclusion and Future
Work are described at the end of the paper.
RELATED WORK
Various techniques have been proposed to counter
measure the DNS poisoning attacks. The pioneer
technique which was introduced to mitigate the attack
was TID, transaction ID randomization [7]. In this
technique they have tried to minimize the brute
force or guessing attack by increasing the ID of
DNS query up to 63 alphanumeric characters.
However it was liable to be predicted by attacker
easily. Later another technique namely source port
randomization [8] was combine with TID for better
security. However it is only matter of time when
patient attacker still launchs DNS poisoning attack.
Afterwards another technique was introduced in [4].
They have laid more obstructions for attacker to
poison the DNS cache by using the combination of
lower and upper case letters for domain name in
query. Though it made hard for attacker yet it was not
an ideal solution because of several limitations like,
every DNS server is not case sensitive server.
Domain Name System Security Extension, DNSSEC
[9] and DNSSEC Look aside Validation, DLV [10]
are also some of the solutions provided to completely
mitigate the DNS cache poisoning. These solutions
have devised the mechanism of having integrity in
the DNS messages and authentication by using
complex cryptology. Unfortunately these solutions
need architectural changes in DNS making it difficult
to use. These changes include zone signing, making
policies for effective use of keys and their
management, having installations of those servers
and clients which are aware of DNSSEC protocols.

Figure 1: Architecture of Secure Proxy

Security proxy has two parts as shown in figure 1.

Local proxy and Remote proxy. Local proxy is
applied on the local DNS and the remote proxy is
deployed on the ANS. All the communication traffic
passed through RNS and ANS except the DNS query
to RNS then response of RNS to client.
DNS CACHE POISONING
In this section we going to discuss the cache
poisoning attack and how an attacker launch this
attack. When a client send a query to the DNS to
resolve, if the local DNS fails to answer that query
then it pass this query to the another server on the
behalf of the client if that targeted server responded
with wrong data then the wrong information will be
sent to the client as well as authoritative server will
copy this data to the many other servers. In another
scenario when a query send by the DNS to another
targeted DNS then attacker send a fake response to
the first DNS. First DNS save that response and
discard the response of the targeted DNS
automatically[6].
DNS is highly vulnerable to accept the cache
poisoning. Fake DNS server or fake query send the
hint or the information to the local DNS that do not
related to the send query. DNS believes that the extra
information is correct and trust worthy, so there is
need for a novel technique to check the received
information is from the authenticated DNS server.

SECURE PROXY ARCHITECTURE

DNS architecture is not designed with respect to
security as DNS cannot filter the rouge packet. Due
this flaw attacker can compromise the DNS cache.
we apply security proxy on the RNS and ANS.
Traffic normally route between RNS and ANS
generally like normal proxy. But it provide a secure
environment to communicate and also helped to
detect the rouge DNS server response.

Figure 2 The DNS cache poisoning process

In the figure 2 mechanism of the DNS poison

attack is discussed step by step.

Each step of the flow diagram is described below:

1.

1.

The attacker generate a query for the DNS

server to know the IP of a specific website
(www.xyz.com).
2. If the local DNS server do not have the
address the query then query is forwarded
to the authoritative name server to resolve
the query. The authoritative name server
is deployed by the attacker
3. The attacker resolve the query(mean
provide the IP address of the specific
website). but attacker also send some
additional fake information to the local
server as
IP of www.hbl.career.com is 205.2.2.2
IP of the www.suparco.org is 195.43.5.9
IP of www.pu.edu.pk is 143.63.8.9
4. Fake authoritative server send the original
query with the IP address of the
www.xyz.com and additional extra
information that remains in the cache of
the DNS for the time TTL.
5. Now if another client generate a query to
find
the
IP
address
of
the
www.suparco.org
6.
Now the compromised DNS responded
with the IP 195.43.5.9 this is the rouge
information instead of the real IP of that
specific website.

2.
3.

4.

PROPOSED SOLUTION
In this novel scheme a query is send by local DNS
and received the responses. The suspicious DNSs is
checked by the Security proxy . If two responses of
the same domain name are received then Security
proxy check their IP address and can spot the
attacker. The good aspect of this scheme is that only
local part of the security proxy is activated.

5.

6.
7.

Figure 3 Flow diagram Secure Proxy and hashing Flow diagram

When a DNS server entertain a query it

first check the required answer in locally
configured area server if the local server
fails to answer the query properly then
DNS resolver sends a query to the RNS
then RNS generate a new query with new
ID and new queried domain name then
calculate the SHA-1 of the ID and the
query and save it on RNS.
Request is send to the remote ANS to
resolve the recursive query.
When the ANS sends back the recursive
query result, the local proxy checks the
authenticity of the sender. SHA-1 of the
ID and the query is calculated then
compared with previous saved SHA-1 on
the RNS. If the both SHA-1 are equal
then this response is from legal DNS
otherwise the received response are not
from legitimate ANS.
The suspicious received query is
handled by the suspicious response set
part of the local proxy, as sometimes
received query may be camouflaged by
an attacker, so in step 4 further verify or
ANS treat this query as a normal query
and sends a regular response in step 6.
Again a unique ID assigned to the
suspicious query then SHA-1 again
calculated and send it to ANS. same as in
step 2.
Multiple responses for the domain
names are compared by the local proxy.
If the IP and the SHA-1 remain same
then there is no issue, query will be
forwarded to the RNS and if not, then
there must be some camouflaged
responses that are sent by the attacker.
In step six all the unique ID and the
calculate SHA-1are deleted.
Local Proxy sends legal response to the
RNS.

This scheme is very sensitive for the response

mechanism. If any illegal response is received then
security mechanism of this proposed algorithm is
alert, also revivifying step enhance it security and
make it difficult for an attacker to crack this scheme.

COMPARATIVE ANALYSIS
The purpose of the research is to develop a
scheme which is more resistant to the cache
poisoning attack and light weight to implement.
Normally a security protocol has several properties
[4] like
1.
2.
3.

No Radical Change
Protocol stability
Backward Compatible

No Radical change means to not change the

existing DNS infrastructure so much. Protocol
Stability means whenever there is need to change the
any protocol of the DNS then improved or new
protocol should not disturb the existing DNS
protocols. Backward compatibility mean new or
improved protocol should be according to the DNS
standards [4].
In this section we compare the 0*20 Bit encoding
technique [4] with secure proxy technique under the
light of bench marks that are defined above. In the
0*20 encoding scheme not require to change the
infrastructure of the DNS. But in some cases
approximately 0.3% of the authoritative servers in the
world already preserve the encoding scheme.
Similarly the in secure proxy technique there is no
need to change the infrastructure of the DNS but
there is need a small data base on RNS to store the
SHA-1. DNS 0*20 is not a light weight solution as
compare to the secure proxy technique. If we talk
about the backward compatibility of the techniques
then in 0*20 bit encoding technique upper and lower
case spellings are mixed together to increase the
complexity of the protocol but this scheme is hard to
implement because there are 16.5 million DNS
servers have implemented and all servers cannot
support this case sensitive technique. Secure proxy
technique is easy to implement because only a minor
change in the existing software program can generate
the SHA-1 and check the suspected response of the
ANS.
CONCLUSION
The current DNS is not secure from cache poison
attack. A lot of methods are proposed to enhance the
security of the DNS. In this paper we proposed a
novel scheme called Security proxy with SHA-1.

This method is easy to implement and invulnerable.

RNS query is sent to the ANS after giving a unique
ID and calculating SHA-1, on receiving response
from ANS ID ,SHA-1 and IP address are checked to
locate an attacker.
FUTURE WORK
In the future we will study the various attack on
DNS like amplification attack, rebinding attack and
try to avoid these attacks by using Security proxy
technique with SHA-1.
REFRENCES
[1] D. Atkins, et al, Threat Analysis of the Domain
Name System (DNS), RFC 3833.
[2] E. Naone. The flaw at the heart of the internet.
Technology Re-view, November/December
2008(https://www.technologyreview.com/web/2
1537/).
[3] D. J. Bernstein. djb-dns http://cr.yp.to/djbdns.html
[4] D. Dagon., et al. Increased DNS forgery
resistance through 0x20-bit encoding: security
via leet queries. In: Proceedings of the 15th
ACM
conference
on
Computer
and
Communications
Security.
Alexandria,
Virginia, USA: ACM, 2008
[5] S. Krishnaswamy, , W. Hardaker and R. Mundy:
DNSSEC in Practice: Using DNSSEC-Tools to
Deploy DNSSEC. In: Conference For
Homeland Security, 2009. CATCH '09.
Cybersecurity Applications & Technology,
2009, pp. 3-15.
[6] M. Wong and W. Schlitt. Sender policy
framework (SPF) for authorizing use of
domains in e-mail, version 1, April 2006.
http://www.ietf.org/rfc/rfc4408.txt .
[7]

J. G. Hy. Anti DNS spoofing extended query

ID (XQID) http://www.jhsoft.com/dns-qid.htm

[8]

D. J. Bernstein. djb-dns,
http://cr.yp.to/djbdns.html

[9] M. Andrews. The dnssec lookaside validation

(dlv) dns resource record, rfc 4431.
http://tools.ietf.org/html/rfc4431, 2006

[10] S. Weiler. Dnssec lookaside validation (dlv),

rfc 5074. http://tools.ietf.org/html/rfc5074,
November 2007