2011 12th International Conference on Parallel and Distributed Computing, Applications and Technologies
Prevent DNS Cache Poisoning Using Security Proxy
Lejun Fan
Institute of Computing Technology
Chinese Academy of Sciences
Beijing,China
fanlejun@software.ict.ac.cn
AbstractDNS has been suffering from cache poisoning attack
for a long time. The attacker sends camouflaged DNS response
to trick the domain name server, and inserts malicious
resource record into the cached database. Because the original
DNS protocol only depends on 16-bit transaction ID to verify
the response packet, it is prone to be guessed by the attacker.
Although many strategies such as transaction randomizing,
source port randomizing and the 0x20 technique have been
applied to improve the resistance of DNS, the attacker still has
chance to poison DNS server in an acceptable time. Other
more complicated strategy such as DNSSEC which provides
stricter prevention mechanism is not easy to deploy and is not
widely adopted yet. To address the problem, we present a novel
strategy called Security Proxy. The architecture can be easily
implemented and deployed on existing DNS server without
modification of DNS server itself. The embedded two schemes
Selective Re-Query and Security Label Communication can
cooperate and effectively prevent the cache poisoning attack.
We analyze our strategy from both the capability and
efficiency. Then we find that our Security Proxy has obvious
advantage over the original transaction ID, the source port
randomizing and 0x20 techniques.
DNS Cache Poisoning attack; Security Proxy; Selective Re-
Query; Security Label Communication
I. INTRODUCTION
Domain Name System(DNS) is important part of Internet
infrastructure. Most network applications rely on DNS for
translating domain name to IP address. If DNS is out of
service for even a few minutes, large part of Internet will be
influenced, thus it is necessary to prevent DNS from being
attack. DNS is not designed for security from origin and is
vulnerable to deliberate attack especially the one which is so-
called cache poisoning. DNS depends on UDP protocol for
communication and verifies the response packet by a 16-bit
transaction ID. If the attacker can guess the transaction ID
and forge a camouflaged DNS response as if it is from the
real authoritative server, when the recursive server receives
the packet, it would be deceived to accept the camouflaged
response and insert the wrong resource record which
contains modified domain name-IP mapping into it cache
space. When the malicious IP address is returned to the user
application, the user will encounter phishing web sites or
other traps hosted by the adversary.
DNS has been suffering from cache poisoning attack for
a long time. People tried to find ways to enhance the security
of DNS and get some improvement[1-12]. First widely used
strategy is transaction ID randomizing[10]. The original
978-0-7695-4564-6/11 $26.00 2011 IEEE
DOI 10.1109/PDCAT.2011.69
Yuanzhuo Wang, Xueqi Cheng, Jinming Li
Institute of Computing Technology
Chinese Academy of Sciences
Beijing,China
{wangyuanzhuo,cxq,lijinming}@ict.ac.cn
DNS used an incremental transaction ID which is prone to be
guessed by the attacker, people then turn to use randomizing
transaction ID and make it harder to be guessed. But there is
still only 216 = 65536 possible ID, thus source port
randomizing is introduced[11], instead of original fixed port
53, DNS servers communicate through a random port. This
method significantly increases the difficulty of the attacker
by the possible combination of ID and port. But a patient
attacker still has chance to poison the DNS server in
acceptable time. Then another strategy called 0x20 is
presented, it uses case sensitive domain name for further
verification[6]. The method once again decreases the
probability of success attack, but it has some limitation such
as that not all the DNS server is case sensitive and cant
either stop the attacker completely. Some other strategies
such as DNSSEC[5,9] and TSIG[12] can almost terminate
the cache poisoning attack by using complicated cryptology
and authorization mechanism, but modification of existing
DNS are needed and hard to deploy.
In order to enhance the security of existing DNS and
avoid unnecessary modification, we present a novel
prevention scheme called Security Proxy. As a security
component for DNS, our strategy can be implemented and
deployed on the DNS server easily with little modification to
existing DNS. The main function of Security Proxy is
improving the verification of DNS response and removing
the camouflaged packet. Security Proxy works like a normal
proxy and can intercept, filter, modify and forward the data
packet for DNS server. Furthermore, it has two different
schemes of identifying the camouflaged packet which is
called Selective Re-Query(SRQ) and Security Label
Communication(SLC). The two schemes have unique
advantages respectively and can be switched dynamically, in
order to keep the DNS safe and efficient at different threat
level. Our main contributions are as follows:
We present a novel strategy called Security Proxy. The
architecture can be easily implemented and deployed on
existing DNS server without modification of DNS server
itself. The two embedded schemes Selective Re-query and
Security Label Communication can cooperate and effectively
prevent the cache poisoning attack.
We analyze our strategy from both the capability and
effiency. We consider the attack success probability and the
cost of the attacker to perform cache poisoning, then we find
that our scheme can significantly decrease the chance to the
attacker and in the meanwhile, increase his cost. We also
compute the impact to DNS query effiency, we find that our
scheme only lead to little impact to the average query time.
387
 We evaluate and compare the existing strategies and
ours. We find that our Security Proxy has obvious advantage
over the original transaction ID, the source port randomizing
and 0x20 techniques.
The rest of this paper is organized as follows: Section 2
reviews the background of DNS query and DNS cache
poisoning, Section 3 describes the detail of our Security
Proxy, Section 4 presents our threat model and analyze both
the capability and efficiency of our strategy, Section 5
compares our strategy with the other existing strategies.
Section 6 concludes this paper and discusses future work.
II. DNS CACHE POISONING
DNS is a hierarchical and distributed system for domain
name resolve service. As the critical part of Internet
infrastructure, the main function of DNS is keeping the
mapping between IP address and domain name. For each
DNS zone, there are name servers which maintain the
Resource Records (RR) for the zone. A name server can be
an authoritative name server (ANS) or a recursive and
caching name server (RNS). ANS is a name server that
stores original RRs. RNS is a cache server which stores
recent DNS query results for a period of time. The caching
mechanism of RNS significantly reduces the network traffic
and mitigates the pressure on the ANS, but leads to some
security issues. The most common and serious one is DNS
cache poisoning attack, which tricks a RNS server into
believing a camouflaged DNS response and adds it into
cached RRs. With a RNS being poisoned, user applications
will be directed to malicious IP addresses with phishing web
sites or other traps hosted by the adversary.Fig.1 shows more
details about DNS cache poisoning.
Figure 1. The process of how the attacker poison the RNS cache with a
camouflaged DNS response which contains the malicious IP a1.b1.c1.d1.
There are four classes of entities involved in DNS cache
poisoning, the ANS, the RNS, the user and the attacker. First,
in step (1) user application starts DNS query for a domain
name, the query is send by local stub resolver function which
is normally implemented in network function library of local
OS. When the query reaches a RNS, it is first checked in
RNSs local RR database and the cached RRs, if RNS still
cant find a RR which matches the queried domain name, it
then starts a recursive query from root ANS to TLD ANS
and then LLD ANS from step (2) to (4). After a LLD ANS
finally responses the query, the IP address of the queried
domain name is embedded in the answer section of DNS
data package in step (5a). At the very moment, the attacker
gets involved and sends a camouflaged data package which
388
contains a malicious IP address in step (5b). Because of DNS
protocol isnt designed for security reasons, RNS verifies the
received DNS response only with a 16-bit transaction ID. If
the attacker can guesses the ID and sends to RNS before the
real response returning from the ANS, the camouflaged data
package will be accepted and the real one will be discarded.
At last, the RNSs cached RRs are poisoned by the
malicious RR injected by the attacker.
III. SECURITY PROXY
A. Architecture
DNS was not originally designed with security in mind,
and thus has not strict verification mechanism for DNS
response data package. This is main reason which gives the
attacker chance to poison the DNS cache. Therefore, we
present a new countermeasure to prevent cache poisoning
attack called Security Proxy. Security Proxy can be deployed
on RNS and ANS as a component of existing DNS. It
intercepts and forwards the network traffic between RNS and
ANS like a normal proxy. But it implements several security
mechanisms for verifying the communication between RNS
and ANS in order to differentiate camouflaged DNS
response from the real ones.
Figure 2. The architecture of Security Proxy
Here is an overview of the architecture and work flow of
Security Proxy. As shown in Fig.2, Security Proxy is divided
into two parts, local proxy and remote proxy. The local part
is deployed on RNS, and remote part is on ANS. All the
communication between RNS and ANS will pass through the
Security Proxy. Except DNS request to RNS and RNS
response to the user(since there is no cache-poisoning related
data packet in the two classes of communication), all the
other request and response of potential attacker will also be
forwarded by local part of Security Proxy.
In consideration of the importance of DNS to Internet,
Security Proxy must keep the DNS query quick, and
meanwhile, prevent the attacker from poisoning the DNS
cache. As a tradeoff between capability and efficiency we
introduce two prevention schemes in Security Proxy:
Selective Re-Query(SRQ) scheme and Security Label
Communication scheme(SLC). The two schemes have
different scope of application and complement each other.
The SRQ scheme is a lightweight scheme. It keeps the DNS
query efficiency as much as possible while reduce the
success probability of cache poisoning attack. The SLC
scheme is a stricter scheme for prevent cache poisoning
attack as effectively as possible but lowers the DNS query
efficiency. We also adopt a special work mode to use the two
schemes corresponding to the dynamic threat level. In later
sections we will discuss more details about the two
prevention schemes and then the dynamic work mode.
B. Selective Re-query Scheme
In brief, SRQ scheme selects some suspicious DNS
responses that it has received and then sends an extra query
for the domain name in the responses. With comparison of IP
addresses in the two responses of the same domain name,
Security Proxy can decide whether an attack is being
performed. In this scheme, only local part of Security Proxy
needs to be activated.
The SRQ scheme employs the following notations:
Q: denotes the DNS request object which has two
properties tid and dname. tid denotes transaction ID and
dname denotes domain name string.
P: denotes the DNS response object which has three
properties tid, dname and ip. The ip denotes IP address
returned in DNS response.
QS: denotes the request set which contains DNS requests
received with unique tid.
PS: denotes the response set which contains DNS
responses received with unique tid, and if two responses
dname are equal, the ip should also be equal.
SS: denotes the suspicious response set which contains
DNS responses that may be camouflaged responses from the
attacker.
The work flow of DNS equipped with SRQ scheme now
consists of the following steps and is shown in Fig.3:
Figure 3. The work flow of SRQ
1) When RNS gets DNS resolve request from user
application, it initializes a new query with the queried
domain name and a random tid. Then the new query is send
to local part of Security Proxy instead of ANS.
2) local proxy inserts a new DNS request object Q with
the querys tid and dname into QS. Then local proxy sends
recursive query to remote ANS for RNS.
3) After the query result returns from ANS, local proxy
verifies it before forwards it to RNS. local proxy first checks
whether the tid of response is in QS. The legitimate DNS
response should have a request with the corresponding tid in
QS, if it does not, the attacker may appear in the moment, so
this response will be insert into SS for further verification in
step 4, else it will be treated as regular response in step 6.
4) For each suspicious response in SS, local proxy
checks them by send an extra DNS query. This query is
389
initialized with a new tid and when the result returns from
ANS, its response will be also inserted into SS. Because the
attacker would send lots of camouflaged responses with
different random domain name and tid to cover the real one
he wants to poison. If all the responses are insert into SS and
re-query, ANS will be flooded by our proxy. Thus SS has a
max capacity and will drop the excess response objects.
5) Then local proxy compares the multiple responses for
the same domain name, if the ip properties of them are
equal, there is no problem, if not, there must be some
camouflaged ones sends by the attacker. In order to
differentiate our re-query response from the attackers, we
introduce a time interval before sending the re-query, so the
latest response should be the real one.
6) When local proxy receives legitimate DNS response
from ANS, it simply remove the response objects in both
QS and PS.
7) After the above verification steps, local proxy then
returns RNS the legitimate response without change or the
re-query response instead of suspicious response.
The SRQ scheme is very sensitive to the guess attempt of
the attacker. Once the abnormal response appears, it can rise
alarm immediately and enter security routine. With the re-
query of the suspicious DNS response, this scheme can
reduce the chance of cache poisoning for the attacker. Since
only the suspicious responses will be re-query, most of
regular DNS query wont be influenced, the impact to the
DNS query efficiency is also limited. But the attacker can
still use more brute-force method to defeat this scheme and
we will discuss more about this in later sections. Therefore,
the SRQ scheme is suitable for preventing cache poisoning
attack at a lower threat level and keeps the DNS query
efficiency.
C. Security Label Communication
The SLC scheme is designed for preventing the cache
poisoning attack from root. The essential reason of this
attack is that the existing DNS protocol has weak verification
mechanism only by the 16-bit transaction ID. If we can
enhance the verification the attack wont exist. To this end,
we introduce security label communication scheme. This
scheme will activate both the local part and remote part of
the Security Proxy. Some extra verification field which is so-
called security label will be added to the DNS query and
response package. We use a random readable string as the
label. A label can have multiple characters for stricter
verification. A label is appended to the end of the standard
DNS packet as an extra additional field. The local proxy and
remote proxy can assemble or dissemble the package
embedded security label. With the intermediate of security
proxy, ANS and RNS can build more reliable
communication than existing mechanism.
The SLC scheme also employs some notations which is
similar to SRQ scheme:
Q: denotes the DNS request object which has three
properties: label, tid and dname. tid denotes transaction ID
and NAME denotes domain name string, the label is
introduced for the SLC scheme and denotes the security label
content.
P: denotes the DNS response object which has four
properties: label, tid, dname and ip. The ip also denotes IP
address returned in DNS response.
QS: denotes the request set which contains DNS requests
received with unique label and tid.
PS: denotes the response set which contains DNS
responses received with unique label and tid.
Again we will discuss the new work flow of DNS with
SLC scheme.
Figure 4. The work flow of SLC
As shown in Fig.4, it contains the following steps:
1) When RNS receives DNS resolve request, it starts a
new recursive query and sends to local part proxy.
2) Local proxy generates new security label with a
certain length and appends to the end of the DNS query
request, then sends the new DNS query request and inserts
corresponding object into QS for later use.
3) Remote proxy receives the DNS query request with
security label. It log the request object and insert into PS.
Then it cuts off the appended security label and sends
standard request to ANS.
4) Remote proxy receives the real response from ANS.
It look for original security label in PS and assigns the
answer field with the IP address in the real response, then it
return the response with security label to RNS.
5) The attacker must guess both the tid and the security
label to form the camouflaged DNS response packet.
6) Local Proxy receives the response of this query and
verifies both the tid and the security label. If any one of
them fails the verification, the response will be dropped.
7) If the verification is passed, the response will be
returned to RNS and then the user application.
The SLC scheme is stricter and more effective scheme
then the SRQ scheme for preventing the cache poisoning
attack. It significantly reduces the success probability of the
attack because the attacker must guess both the tid and the
security label at the same time. With a long security label,
the chance of the attacker will be very little. But in this
scheme the regular DNS packet and faked packet are equally
treated, this will increase the average query time and
influence the query efficiency of the entire system. So this
scheme should be used at a higher threat level.
390
D. Dynamic Switching Schemes
As mentioned above, the SRQ and SLC scheme suit for
different threat levels respectively. As a tradeoff for
capability and efficiency, we adopt a kind of work mode
which switches between the two schemes dynamically. The
work mode divides into two phases corresponding to the
threat level as follows:
Phase A: When threat level is quite low, the basic SRQ is
enough, each suspicious DNS response will be re-query only
once. When threat level get higher, advanced SRQ scheme
which means each suspicious DNS response will be re-query
more than once will be adopted.
Phase B: When threat level gets higher continuously, the
SRQ scheme cant cope with the situation and SLC scheme
should be switch to, security label will be appended to each
DNS packet. The characters of security label will increase
with the threat level.
The detail of switching scheme by threat level will be
discussed in next section. Under the dynamic work mode
that we adopt, the more effort attacker does, the stricter
prevention scheme will be used, and the lower the success
attack probability will be. Such negative feedback will
frustrate the attacker and protect the DNS elegantly.
IV. EFFECTIVITY ANALYSIS
As discussed above, we have understood the Security
Proxys architecture, core security scheme and dynamic
work mode. In this section, we will discuss the both the
security and performance of DNS when confronting cache
poisoning attack with the help of our Security Proxy. First
we will analyze the capability of preventing attack, and then
the impact to the efficiency of DNS query.
A. Security analysis
We analyze the security from two aspects: the probability
that the attacker performing successful cache poisoning
attack and the cost that the attacker will pay for the attack.
1) Preliminary
First, we give the definitions of threat level and attack
cost which will be used in later analysis.
a) Threat Level.
Let BW be total attack bandwidth, let Len be the
camouflaged packet length, the threat level which is defined
by the attack frequency can be denoted by TL, then TL = BW
/ Len.
b) Attack Cost.
Let BW and Ttotal be the attack bandwidth and total attack
time of the attacker, the attack cost denotes by C, then C =
BW + Ttotal .
2) Success Attack Probability
We denote the probability of success attack by psucc, psucc
changes with the threat level in different phases of the work
mode.
Phase A: when Security Proxy works under the SRQ
mode, the suspicious responses are selected and re-queried,
this means that the attacker must guess the Transaction ID of
the real response for multiple times which is denoted by R.
The number of possible TID for standard DNS response is
216 so that the number that the attacker should guess under
the SRQ mode is (216)R. But considering the SS has max
capacity, not all the suspicious response will be re-query. If
the attacker sends Nrandom random DNS response for covering
the real one and the capacity of the SS is Ncapa. The responses
in SS has probability that equals (216)-R for guess the real TID,
the other ones out of SS has probability that equals 2-16. Let
the probability of standard DNS be poisoned be constant K =
2-16, the total psucc can be computed as:
psucc = K(1+(KR-1)Ncapa / Nrandom)
Phase B: When Security Proxy switches to the SLC
mode, the psucc will be influenced by the random characters
in the security label. The attacker must not only guess the
TID but also guess the random characters. Let the length of
security label be L, the possible character contains all letters
and digits thus equals 36, the probability of guess the
security label equals 36-L. We also let constant K be 2-16, thus
the psucc can be computed as:
psucc =K36-L
Figure 5. The success attack probability of the SRQ and the SLC in
different threat level
According to formula (1) and (2), both the SRQ and
SLC mode will significantly reduce the success attack
probability when the parameter R in (1) and L in (2)
increases, and under the SRQ mode the psucc even reduce
faster because of the K in (1) is much greater than 36 in (2).
As shown in Fig.5, the curve of SRQ descends faster than the
SLC before the two curves intersect. But considering the
Definition 1 about the threat level we can find that the SLC
scheme is more suitable for the higher threat level than the
SRQ scheme. In Definition 1, threat level is computed by
BW/Len, this implies that under the SRQ mode the
increasing of threat level means the increasing of BW when
Len does not change. In formula (1), the increasing of BW
means the increasing of Nrandom. If Nrandom is large enough,
then the psucc will become greater than SLC and increase to
approximate K rapidly. But under the SLC mode, psucc is only
concerned with L in (2), when L increases, the security label
prolongs, then psucc reduces steadily. Thus the curve of the
SRQ descends slower and crosses over the curve of the SLC.
Therefore, switching the two schemes at the intersect point
of the curves is the best plan which can keep the psucc low in
different threat level.
3) Total Attack Cost
Next we will discuss the cost that the attacker pays for
the attack. Assume that the attacker guesses Nguess times
before he find the right answer, as we computed in (1) and
(2), the expectation of the number Nguess that the attacker
needs to send the packets equals to the reciprocal of the
success attack probability, which is 1/ psucc. So the total time
(1) expectation should be computed by the packet length, his
bandwidth and the Nguess, then:
Ttotal = LenNguess /BW (3)
The total time means how long will it take that the
attacker send all the 1/ psucc packets which length is Len to
match the real response with a bandwidth BW, then C can be
computed as:
C = BW + Len/(BWpsucc) (4)
(2)
Then according to the definition of threat level, then we
get another formula as follows:
C = TLLen + 1/(TLpsucc) (5)
With the increasing of TL, if the value of Len and psucc
does not change, the cost of the attacker in formula (6) will
first decrease to a minimum then increase monotonously.
The reason of the phenomenon is that if the attacker sends
less camouflaged packet and keep in a lower threat level he
needs longer time to accomplish the attack, but if he uses
more bandwidth to decrease the attack time, the cost of
network resource will increase. The total cost in our dynamic
switching work mode will increase even faster because Len
and 1/ psucc both increase together with the TL as mentioned
above. Therefore, under the Security Proxy if the attacker
wants to perform more threatening attack, he must pay much
more price than he gets.
B. Performance Analysis
Towards DNS performance, the main factors that we will
talk about are average query time of single DNS query. We
divide the DNS query time into three parts of our Security
Proxy, the basic query time Tbasic, the forward time Tforward
and the extra process time Tprocess. In both the SRQ mode and
SLC mode, the basic query time Tbasic consists of the time
that user send query to RNS, the time that the RNS send
recursive query to ANS, the time that the ANS returns the
query results. The forward time Tforward consists of the time
that the proxy receives the responses and the time that the
proxy sends the requests. The Tprocess has different meanings
in SRQ mode and SLC mode, the former mainly contains the
check, search, insert and remove operation time on the object
containers such as PS,QS and SS, the later mainly contains
the generate, compare, assemble and dissemble operation
391
time for the security labels. There is also another reason dynamic probability psucc in consecutive attack after sending
which influences the average query time, that the SRQ N camouflaged packet can be computed by:
contains the selective mechanism but the SLC treats all the
queries equally. psucc = 1-(1- psucc) N (8)
Next we will respectively compute the average query
time under SRQ the SLC mode, here we introduce Ntotal for We assume that the attacker has 1Mbps bandwidth in this
the total DNS query in a time interval includes both the scenario, and then the psucc of all the four schemes is as
regular packet and the camouflaged packet. Ncapa is same as follows:
mentioned in (1). Under SRQ mode, the regular DNS query
has normal query time Tbasic, but suspicious response has
extra re-query time, as mentioned in (1), the time of this part
of query will be Tprocess + R(Tbasic + Tforward), the proportion of
the two part is Ncapa / Ntotal denoted by N Then the average
query time Tavg can be computed by:

Tavg = N(Tprocess+R(Tbasic+Tforward))+(1-N)(Tbasic + Tforward)(6)

Under SLC mode, both the regular packet and the

suspicious packet will be has Tprocess, and the Tforward
increases for forwarding through both the local proxy and the
remote proxy for multiple times, we denote the count of
forwarding time by F, then the average query time can be
computed by: Figure 6. The variation of the success attack probability

Tavg = Tbasic + FTforward + Tprocess (7) As shown in Fig.6, assume that the attack accomplishes
the attack when the total attack probability reaches 0.9, the
In formula (7), when Ntotal is greater than Ncapa, the Tavg standard DNS TID mechanism can only prevent the attacker
will decrease to Tbasic + Tforward even the R increases. This for few seconds. With the help of 0x20 technique, the time
means that in SRQ mode, the Tavg can keep mostly the same will be in the order of hours. If source port randomizing
with standard DNS query. In formula (8) Tavg keeps constant, scheme is used, the attacker needs few months to accomplish
but since the Tforward and Tprocess are both generated by local the task. When our security proxy is equipped, the total time
computing in Security Proxy, the values of them are less than will prolong by many days or couple of weeks only in SRQ
Tbasic, so there would not be too much gap between the mode, if the stricter SLC mode is adopted, the time only for
standard time and the modified one. Therefore, in both the reaching 0.5 will be few years. Thus our scheme has
SRQ and SLC mode, our Security Proxy only impacts the advantage in lowering the success attack probability over the
average query time very little. existing prevention schemes.
Second, we evaluate the attack cost by formula (5).
V. COMPARATIVE ANALYSIS
In this section we will compare our Security Proxy with
other existing security strategies. We choose standard DNS
scheme which uses TID, the source port randomize
scheme(SPR), and the 0x20 scheme. First we compute the
basic success attack probability psucc of the three schemes.
The standard scheme with TID has a 16-bit integer, so the
psucc equals 2-16. The SPR scheme adds 216-1024 random
source port (excludes 1024 reserved port), so the psucc will be
1/(216-1024). The 0x20 scheme introduces case sensitive
domain name. Assume that the average domain name length
is 12, and then the psucc will be 2-162-12. Under our security
scheme, we let re-query only once in SRQ mode, then we let
the security label length also be 12 bytes in SLC mode. We Figure 7. The variation of total attack cost
also assume that the camouflaged packet length is average
100 byte, and the attacker has the network bandwidth that As shown in Fig.7, all the other strategies increase the
ranges from 1Mbps to 100Mbps. total attack cost significantly than standard DNS with only
transaction ID. Our SLC scheme is two orders of magnitude
A. Security Comparation
better than the SPR and three orders of magnitude than the
First, we consider the variation of the psucc in consecutive 0x20. The SRQ scheme is better than the 0x20 but worse
attack of the other three schemes and ours. Since the average than the SPR, since SRQ is designed for preventing the
success attack probability in single attack is psucc, the

392
attack while keeping the efficiency high, the result is
acceptable. The cost curve of standard DNS first decreases to
a minimum and then increases as we discussed in Section 4.1,
the other four curves are similar to the STD when the threat
level is great enough, but we cant see that in Fig.7 since we
assume the attack has a bandwidth ranged from 1Mbps to
100Mbps. In fact, if the attacker uses more bandwidth to
sending packet to DNS server, it would become DOS attack
rather DNS attack.
B. Performance Comparation
As we mentioned in Section 4.2, the average query time
can be split to three parts, the basic query time Tbasic, the
forward time Tforward and the extra process time Tprocess. The
main overhead of our Security Proxy is the Tforward and Tprocess
and towards the SPR and 0x20, the main overhead is Tprocess.
We develop the proof-of-concept implement of the core
algorithm of the SPR, 0x20 and our SRQ and SLC scheme
with C language then test the value of the three time
variables and then compute the average query time by
formula(7) and formula(8). We assume that 10% of the total
packets needs re-query under SRQ mode and a single DNS
query needs forwarding three times under both SRQ mode
and SLC mode.
Figure 8. The query time of SPR,0x20 and our SRQ, SLC
As shown in Fig.8, the impact to average query time of
SPR is about 20ms, the 0x20 is about 30ms, and our scheme
introduces approximate 40ms overhead under SRQ mode
and 70ms under SLC mode. Although our security
mechanism introduce multiple forwarding and extra
processing, but the forwarding time and processing time are
much shorter than the basic query time and lead to little
overhead. And in most instance, the threat level is low and
our Security Proxy will be under SRQ mode, which leads to
only 10% overhead of the selected suspicious domain names.
Even under the SLC mode, the overhead would be less than
20%. But considering the attack cost in higher threat level, it
is worthy to trade the security with the little performance
cost.
VI. CONCLUSION
The existing DNS has been suffering from cache
poisoning attack for a long time. Many strategies have been
applied to improve the security of DNS. In this paper we
393
present Security Proxy which can be easily implemented and
deployed on existing DNS server and prevent the cache
poisoning attack by the two embedded schemes Selective
Re-query and Security Label Communication. We analyze
our strategy from both the capability and effciency and find
that our Security Proxy has obvious advantage over the
original transaction ID, the source port randomizing and
0x20 techniques. In the future work, we will study the
countermeasure of other DNS attack categories such as
amplification attack and rebinding attack using our Security
Proxy.
ACKNOWLEDGMENT
This work is supported by National Natural Science
Foundation of China (No.60803123, 60873245, 60933005)
and the Projects of Development Plan of the State High
Technology Research (No.2010AA012502).
REFERENCES
[1] Alexiou, N., et al.: Formal Analysis of the Kaminsky DNS Cache-
Poisoning Attack Using Probabilistic Model Checking. In: High-
Assurance Systems Engineering (HASE), 2010 IEEE 12th
International Symposium on, IEEE Press, 2010, pp. 94-103.
[2] Trostle, J., B. Van Besien and A. Pujari: Protecting against DNS
cache poisoning attacks. In: Secure Network Protocols (NPSec), 2010
6th IEEE Workshop on, IEEE Press, 2010 , pp. 25-30.
[3] Perdisci, R., et al.: WSEC DNS: Protecting recursive DNS resolvers
from poisoning attacks. In: Dependable Systems & Networks, DSN
'09. IEEE/IFIP International Conference on. IEEE Press, 2009, pp. 3-
12
[4] Jackson, C., et al., Protecting browsers from DNS rebinding attacks.
ACM Trans, 2009, Web. 3(1): pp. 1-26
[5] Krishnaswamy, S., 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] Dagon, D., 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
[7] Changhua, S., L. Bin and S. Lei: Efficient and Low-Cost Hardware
Defense Against DNS Amplification Attacks. In: Global
Telecommunications Conference, 2008. IEEE GLOBECOM 2008,
IEEE Press, 2008, pp. 1-5.
[8] Fanglu, G., C. Jiawu and C. Tzi-cker: Spoof Detection for Preventing
DoS Attacks against DNS Servers. In: Distributed Computing
Systems, 2006. ICDCS 2006. 26th IEEE International Conference on,
IEEE Press, 2006, pp. 37- 37.
[9] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. DNS
security introduction and requirements,
http://www.ietf.org/rfc/rfc4033.txt.
[10] J. G. Hy. Anti DNS spoofing - extended query ID (XQID),
http://www.jhsoft.com/dns-xqid.htm
[11] D. J. Bernstein. djb-dns, http://cr.yp.to/djbdns.html
[12] P. Vixie, O. Gudmondsson, D. Eastlake 3rd, and B. Wellington.Secret
Key Transaction Authentication for DNS (TSIG)
.http://tools.ietf.org/html/rfc2845