NETWORKS & SECURITY
Design and Implementation of an SDN-Enabled DNS
Security Framework
Zhenpeng Wang, Hongchao Hu*, Guozhen Cheng
National Digital Switching System Engineering and Technological Research Center, Zhengzhou 450002, China
* The corresponding author, email: 13633833568@139.com
Abstract: The Domain Name System (DNS)
is suffering from the vulnerabilities exploited
to launch the cache poisoning attack. Inspired
by biodiversity, we design and implement a
non-intrusive and tolerant secure architecture
Multi-DNS (MDNS) to deal with it. MDNS
consists of Scheduling Proxy and DNS server
pool with heterogeneous DNSs in it. And the
Scheduling Proxy dynamically schedules m
DNSs to provide service in parallel and adopts
the vote results from majority of DNSs to
decide valid replies. And benefit from the cen-
tralized control of software defined network-
ing (SDN), we implement a proof of concept
for it. Evaluation results prove the validity and
availability of MDNS and its intrusion/fault
tolerance, while the average delay can be con-
trolled in 0.3s.
Keywords: DNS cache poisoning attack;
software defined networking; moving target
defense; dynamic heterogeneous redundant
I. INTRODUCTION
As one of the most critical components of the
Internet, the Domain Name System (DNS)
provides not only resolution (or mapping)
between human-friendly domain names and
machine-friendly IP addresses, but also fun-
damental trust anchors for accessing Internet
China Communications • February 2019
services. Many internet applications, such as
http, email and ftp, indirectly or directly de-
pend on the security of the DNS infrastructure
to resolve a given domain name to its corre-
sponding IP address to establishing connec-
tions. Unfortunately, security was not one of
the design considerations for DNS, and it has
always been an attractive target to attackers
[1], [2], [3].
DNS cache poisoning is arguably one of the
most damaging attacks on DNS [4]. It refers
to cases where the cache of a DNS server is
injected with invalid or malicious mappings
between domain names and IP addresses.
There are numerous ways to poison the cache,
such as by compromising an authoritative
DNS or forging a reply to cheat the recursive
DNS. And Dan Kaminsky [3] discovered a
novel DNS cache poisoning attack in 2008,
while the contamination target in conventional
DNS cache poisoning is the answer resource
records, the Kaminsky attack’s target is the
authority resource records, which is more de-
structive.
Although a suite of complicated cryptology
and authorization mechanisms like DNSSEC
[6] has been deployed to secure DNS servers
and clients, there are still a few problems when
Received: Jun. 30, 2017
deploying DNSSEC on a large scale. First, Revised: Apr. 26, 2018
DNSSEC incurs a significant performance Editor: Jun Bi
233

We propose MDNS,
a d y n a m i c h e t e ro -
geneous redundant
architecture based on
software defined net-
working to safeguard
the DNS.
234
penalty for the computationally intensive PKI
operations. Second, the signed DNS packets
could be much larger than original, which will
lead to other problems, such as the fragmenta-
tion attacks [7], R-DDoS and DR-DDoS [8].
Many non-cryptographic defenses have been
put forward to solve the problem of the easy-
to-guess transaction IDs (TxID) by increasing
the entropy of DNS query components such
as TxIDs, query labels and port numbers [12],
[13], [14]. However, these defenses have to
change the DNS protocol which makes them
difficult to deploy.
Inspired by biodiversity and Evolving
Defense Mechanism (EMD) [9], we present
Multi-DNS (MDNS) with heterogeneous
DNSs to enhance the security of DNS, which
doesn’t require any modification to the current
DNS system and protocol. EDM is also based
on a bio-inspired idea of network configura-
tion variations. EDM selects an efficient net-
work configuration variation strategy to pre-
vent corresponding security threats according
to the security requirements of the system, the
user, and the network security state. And we
add dynamic and redundant characteristics to
MDNS learning from Moving Target Defense
(MTD) [10]. Moving Target Defense technol-
ogy is proposed by Federal Networking and
Information technology Research and Devel-
opment (NITRD) in recent years, whose main
concept is to raise the complexity and costs
for attackers to deal with a great deal of uncer-
tainty by making systems dynamic and hard to
predict.
In order to realize the dynamic and redun-
dant characteristics of MDNS, we leverage the
emerging software defined networking tech-
niques [11]. SDN offers a greater control of
network through programming by decoupling
of control and data planes. In SDN, unification
of the control plane over all kinds of network
devices, renders it possible to manage network
traffic from a single point, automatically via
SouthBound Interface (i.e., OpenFlow).
The main contributions of this paper are as
follows:
• We propose MDNS, a dynamic heteroge-
neous redundant architecture to safeguard
the DNS without any modification to the
DNS protocol;
• We implement MDNS based on software
defined networking and propose the finger-
print masking method, handoff mechanism
and time saving strategy to enhance the
performance of MDNS further;
• We test the intrusion/fault tolerance and
performance of MDNS.
This paper is organized as follows. We
discuss the cache poisoning attack and relat-
ed work in Section 2. To solve the problem,
we present the design of MDNS with its core
components in Section 3. In Section 4, we
present the implementation of MDNS based
on SDN. And we evaluate the performance of
MDNS in Section 5. At last we conclude this
paper in Section 6.
II. RELATED WORK
2.1 DNS cache poisoning attack
The mapping between a domain name and IP
address is called DNS resolution (DNS look-
up). Figure 1 shows the workflow of DNS
lookup when client visits www.example.com
for the first time, which means the recursive
DNS (RNS) server hasn’t cached the answers
before. The stub resolver on the client sends
a recursive query to its RNS (1). In the event
of a cache miss, RNS will query recursively
to the root server, the .com Top Level Do-
main (TLD) server, and the authoritative DNS
(ANS) server of example.com (2~6). Finally,
the ANS will respond with the IP address of
www.example.com (7~8). When client gets the
IP address 93.184.216.34, it can visit the web
server (9~10).
The basic DNS protocol is UDP-based
and doesn’t authenticate replies. The only
checks are: (1) the query section and 16-bit
transaction ID (TxID), and (2) the source IP
and destination port of the reply must match,
respectively, the destination IP and source
port of the query. The first arriving packet that
satisfies these conditions is treated as a valid
China Communications • February 2019
reply from the ANS. Therefore, what the at-
tacker needs to do is to send a reply forgery
1.1.1.1 (7’ in red) satisfying these conditions
and arriving before the reply from the legit-
imate ANS (7 in black). What’s more, the
probability of guessing the right transaction
ID could be much higher due to weaknesses in
the random number generators, use of multiple
queries and the consequent birthday paradox.
And it will be much easier if the client and at-
tacker is the same person.
2.2 Defense strategies
Since security researcher Dan Kaminsky [3]
discovered the DNS vulnerability and pre-
sented the new extension of the DNS cache
poisoning attack, significant research efforts
have been devoted to studying the security of
DNS. The security policies fall into two types:
(1) increasing the entropy of DNS query, (2)
encryption and authentication technology.
Increasing the entropy of DNS query:
David Dagon [12] presented a practical tech-
nique to make DNS queries more resistant to
cache poisoning attack by mix the upper and
lower case spelling of the domain name in the
query, [13] used the similar idea. However,
the amount of additional entropy introduced
by the 0x20-bit encoding is a function of the
length of the queried domain name. For exam-
ple, it offers only 3 additional bits of entropy
for 163.com, 126.com, etc. Roberto Perdisci
[14] used wildcard domain name to increase
the entropy of DNS query. The key idea of this
method is to use wildcard domains and add
a random string instead of “*” to the queries’
domain name and still obtain a correct answer.
And some researches put forward new ways
to increase the overall entropy of the DNS
queries. Lihua Yuan [15] proposed a peer to
peer based scheme to detect and correct pol-
luted DNS records caused by cache poisoning
attacks. Its main idea is that it’s difficult for
attackers to compromise several DNS servers
with the same false records at the same time.
And Lejun Fan [17] proposed to use a proxy
between RNS and ANS to enhance the securi-
ty by sending an extra DNS query to check the
China Communications • February 2019
suspicious replies (Re-Query). And Jin C [5]
proposed to use multiple ANS to provide ser-
vice to increase the entropy of the DNS query.
Encryption and authentication technolo-
gy: In order to solve the availability problems
DNSSEC suffers from due to the packet frag-
mentation attack [7], R. van Rijswijk-Deij [19]
proposed to use elliptic curve cryptography
(ECC) as default signature algorithm rather
than the RSA, which is because the ECC sig-
natures are much smaller in size, leading to
smaller replies. And Ramzi Bassil [20] pro-
posed to use Identify-Based Encryption (IBE)
key management scheme to take over the
traditional complex Public-Key Infrastructure
(PKI). IBE is cryptosystem where the public
key can be any public string, such as a host
name, an IP address and email address etc., so
there is no need for a public key lookup phase
from a trusted-keys repository.
Although the two methods above can en-
hance the security, they all need to change the
DNS protocol and it’s not practical to verify
every record with the ANS using data encryp-
tion and authentication techniques, which will
render the caching mechanism ineffective.
III. DESIGN
In this paper, we propose Multi-DNS (MDNS),
a dynamic heterogeneous redundant archi-
tecture [25] to solve the problem. The main
point is that DNS replies are no longer from a
single DNS, for multiple DNSs will take part
in judging which DNS produces valid replies.
Web Hosting
93.184.216.34 1.1.1.1
Root
(9) (2)
RNS
(10) (3)
www.example.com
(1)
(8)
IP: 93.184.216.34
(4)
(5)
TLD(.com)
(8')
client IP: 1.1.1.1 (6)
(7') (7)
Spoofed Answer: with
IP 1.1.1.1
ns.example.com
attacker
Fig. 1. DNS cache poisoning attack.
235
 As the difficulty and cost are increased tre-
mendously when attackers try to compromise
numerous DNSs simultaneously. Hence, the
defense strategy offered by this mechanism
can improve the robustness and resilience of
the holistic network without any change to the
DNS protocol.
3.1 MDNS architecture
In addition to the client and DNS servers, a
Scheduling Proxy is introduced between them
to assist the deployment of virtual functions in
MDNS (figure 2). The constitution and func-
tions are described below:
DNS server pool: Instead of deploying
one DNS, it’s composed of N (N ≥ 3) DNSs,
each of which installed different kinds of DNS
software, such as BIND, NSD, and so on. Al-
though DNSs are achieved on heterogeneous
structures, they will generate the same replies
in case they receive the identical DNS query.
What’s more, to enhance the security further,
DNSs are deployed on diverse hosts with
different operation systems (Linux, Window,
etc.). There is no doubt that increasing the
number of different software systems can min-
imize the effectiveness of a single system-spe-
cific attack [24]. Through this, the attackers
have to mine the vulnerabilities of different
kinds of DNS server software simultaneously.
Scheduling Proxy: It’s the critical unit and
responsible for the scheduling, decision-mak-
ing and so on. And it is comprised of three
req rep
req rep
req
rep req rep
reps
Fig. 2. Overview of MDNS.
236
virtual functions modules: Scheduler, Decider
and Scrubber whose functions are depicted as
follows.
• Scheduler: Its main work is randomly se-
lecting m (m should be an odd number and
3 ≤ m ≤ N) DNSs to be active from server
pool and forwarding the DNS requests from
clients to them to provide service. There
are two cases in which the Scheduler would
switch the active DNSs. One is timing
switch mechanism that the Scheduler will
re-select new m DNSs at fixed intervals.
The other is event trigger mechanism that
the Scheduler will execute the scheduling
when it receives an alert message from De-
cider.
• Decider: The core function of the Decider
is judging whether DNSs are in benign
conditions by comparing their replies.
Then it sends the most trusted replies to
clients. The choice is made on the follow-
ing assumption: it is difficult for attackers
to compromise majority of DNS servers
simultaneously with the same false data
[15]. And the heterogeneous structures will
increase the difficulty further. Thus, the
identical replies can be considered correct,
secure and valid replies. Finally, an alert
message will be transmitted to notify the
Scheduler and Scrubber of the information
about the suspecting DNSs if it discovers
incongruous replies.
• Scrubber: Its chief duty is responsible for
manage the DNSs in the server pool. Once
receiving the alert message from the De-
cider, it will scrub the suspecting DNSs
according to the Decider’s orders: if it’s the
first time for a DNS to return an incongru-
ous reply, the Scrubber will clear its cache;
otherwise, restart it. After that, a notifica-
tion message will be transmitted to the De-
cider and Scheduler.
3.2 Workflow
First, the Scheduler picks m DNSs to provide
service and the Decider sends the valid replies
back to clients. Then, once any mechanism of
the Scheduler is triggered, new active DNSs
China Communications • February 2019
will be selected. As for the DNSs whose re-
plies are different from that of the most DNSs,
the Decider will notify the Scrubber to clear
their cache or restart them and the Scheduler
to pick from the rest DNSs next round. Finally,
above actions will be repeated to maintain the
DNSs in a secure, robust and resilient state.
3.3 Scheduling and decision-making
mechanism
In different time intervals, the Scheduler dy-
namically selects DNSs according to sched-
uling algorithm. Obviously, what Scheduler
needs to do is to increase the amount of unpre-
dictability of scheduling.
From information theory’s point of view,
uncertainty or randomness can be character-
ized by information entropy. Let pi denote
the probability of the DNSi being selected,
then the total uncertainty can be calculated
H = −∑ i =1 pi log( pi ). It is easy to prove that
N
H gets its maximum value H max = log N when
p=
1 p=
2 ,...,
= p=N 1 / N . So Scheduler first
randomly chooses a number m (m ≤ N) as the
expected value of the active DNSs’ number,
and then randomly selects each DNS to be ac-
tive with the same probability m / N.
Decider makes decision on the DNS replies
received from the active DNSs so as to detect
the cache poisoning attacks and send the final
decision outcomes to the clients. In the Byz-
antine fault systems, scholars have conducted
extensive researches on the decision fusion.
In this paper, we use a simple majority-based
decision fusion rule, for example, there are
three active DNSs, and Decider receives
that there are some reasons other than cache
poisoning attack that lead to inconsistence
among DNSs :
• Stale Cache: To improve efficiency, DNS
uses the cache mechanism which is TTL-
based mechanism that could store and re-
turn stale records. In this case, Decider just
equates this with a cache poisoning attack;
• Load Distribution: For some big compa-
nies, they may own several IP addresses
for their domain name, and to realize load
balancing, DNS commonly uses round rob-
in mechanism that rotates the order of the
records mapped to the same domain name.
In this case, we uses set comparison just
the same with [15], which means that for
a domain name that has three IP addresses
A1 , A2 , A3 , the answer A1 , A2 , A3 is equal to
A3 , A2 , A1.
IV. IMPLEMENTATION
4.1 MDNS based on SDN
To implement the dynamic and redundant
characteristics of MDNS, we propose to lever-
age the emerging software defined networking
techniques. The architecture is illustrated in
figure 3.
We use Ryu controller (APP) to realize the
three virtual functions of Scheduling Proxy:
(1) Scheduler, dynamically determines
where DNS queries should be forwarded. In
detail, Scheduler selects several DNSs to be
DNS server pool

three replies with the answer (IP addresses) Scheduler Scrubber Decider

93.184.216.34, 93.184.216.34, and 1.1.1.1 (6) replies DNS1

switch1
respectively, then the Decider will determine (1) select active
DNSs
(7) final answer DNS2
93.184.216.34 should be the right answer and switch2

send it to client. As for the third DNS respond- (2) request (3) multicast
(4) request
(5) replies
DNS3

ing 1.1.1.1, the Decider will originally suspect Client

(8) reply
switch0 switch3

that it has been attacked and let it reload the

...

...

record from ANS, and just let Scrubber clear

DNSN
the cache if its reply is different from the ma-
switchN
jority next time.
And we also need take into consideration
Fig. 3. Workflow of SDN-based MDNS

China Communications • February 2019 237

 active, and then sends instruction to switch0
(the blue switch in figure 3) for steering DNS
data flow. For example, if DNS1~3 are se-
lected, Scheduler will send the instruction
like Code1 shows to switch0, and after that,
switch0 will output DNS queries to DNS1~3
through switch1~3 respectively.
(2) Decider, receives the replies from
switch1~N (the yellow switches in figure 3)
which sent by active DNSs, and then decides
the final answer to send to the client (through
switch0).
(3) Scrubber, is responsible for clearing the
cache in DNS according to Decider’s orders
and we use the rndc tool to remote control
the DNS, for example, using the “rndc flush”
command to clear the cache in DNS.
Code1
match = in_port: from_client, nw_dst:
192.168.56.7
actions = output: switch1, switch2, switch3
From Code1 we can see that if switch0 gets
packets from clients and the destination IP ad-
dress is 192.168.56.7, it will forward them to
switch1, switch2 and switch3. And we can add
some match fields such as “udp”, “destination
port is 53” and so on.
4.2 Fingerprint masking method
Although we adopt dynamic redundant archi-
tecture, attackers may still locate DNS servers
(IP addresses) through network probing or
sniffing. So we design a fingerprint masking
method to clear the real information of DNSs.
We use a “dummy” DNS to conceal DNSs’
real location from clients (and potential attack-
ers) by stealthily modifying the packets. In our
implementation, SDN switches have a role of
either distributer or modifier. The distributer,
just like switch0, (blue switch in figure 3) is
used to forward DNS queries to certain yellow
switches, while the modifier, like switch1~N
(yellow switches), is responsible for modify-
ing the packets’ header, such as IP address and
MAC address, according to the DNS it con-
nects. For example, we set the dummy DNS’s
IP to be 192.168.56.7, which is exposed to
clients (and potential attackers), while the real
238
DNSs’ IP are 192.168.56.101, 192.168.56.102,
and so on. If DNS1 is one of the active DNSs,
the switch1 will modify the requests’ destina-
tion IP to 192.168.56.101 before outputting to
DNS1 and modify the replies’ source IP back
to 192.168.56.7 before outputting to Decider
(and to clients ultimately).
Through this way, the clients will mistak-
enly believe that it was the DNS with IP ad-
dress 192.168.56.7 that responded to the DNS
lookup, while the real DNSs’ IP addresses
were hidden. The logic of the flow entries in
switch1 is illustrated in Code2. And if switch-
es support OpenFlow 1.1 or later, we only
need one switch to realize the two roles above
at the same time by using the group tables.
Code2
#requests
match = in_port: from_switch0
actions = mod_nw_dst: 192.168.56.101,\
mod_dl_dst: 00:00:00:00:00:0a,\
output: DNS1
#replies
match = in_port: from_DNS1
actions = mod_nw_src: 192.168.56.7,\
mod_dl_src: 00:00:00:00:00:07,\
output: controller
4.3 Handoff mechanism
If the active DNSs’ number is different from
the one before the scheduling, the Decider
may get an “out-of-order” problem. For exam-
ple, at time t0, there were three active DNSs
(old DNSs), and at t1 the Scheduler started
to select five DNSs to be active and sent in-
struction to switch0 to output the queries to
the new DNSs, then the problem is that for
the replies received during the scheduling, the
Decider has no idea whether they are from the
old or new DNSs, so when the Decider has
already received three DNS replies, it doesn’t
know whether it should wait for three or five
replies, thus it may wait earnestly for the rest
two replies, while actually there should have
been only three.
We could wait for DNS queries at the old
DNSs to terminate and then set switch0 to
output to the new DNSs, however, it will take
China Communications • February 2019
a long time. To solve this problem, we design
the following handoff mechanism, as shown
in figure 4, the solid arrows indicate the DNS
queries or replies and the dashed arrows indi-
cate the instructions send to switch0:
(1) At time t1, when Scheduler decides to
change the active DNSs, it sends instruction to
switch0 to output DNS queries to controller;
(2) At time t3, Scheduler records the TxID
of the first DNS query received from switch0,
let’s call it New_TxID. Then the Scheduler
sends the first and subsequent queries to the
new DNSs;
(3) Let’s assume at time t4, Decider receives
the reply with New_TxID, which means it’s
the reply of the first query;
(4) At last, Scheduler sends instruction
that let the switch0 output queries to the new
DNSs to finish the scheduling at t5 (t5 ≈ t4). =
Through this way, Decider can tell the
number of the replies it should wait for based
on the time t4: the replies received before t4 are
from old DNSs and those after t4 are from new
DNSs.
4.4 Time saving strategy
And the time delay also needs to be taken into
consideration. It is obvious that MDNS will
increase the time delay: if the delay with just
one DNS server can be described as a random
variable T, then it will be max (T1 , T2 ,..., Tm )
for MDNS with m active DNSs. What’s more,
if there is one malfunctioning DNS, Decider
may keep waiting for too long and cause great
time delay.
In order to solve this problem, we propose
a pretreatment stage for time saving. Let’s call
it t1 when Decider received the first reply of a
query, and tthreshold donates the maximum time
mum security requirement”. As for the setting
of tthreshold, we use the similar method with the
three-sigma rule, which expresses a conven-
tional heuristic that “nearly all” values are
taken to lie within three standard deviations of
the mean. In our case, first we get the average
delay tave from previous statistics, and then we
set the tthreshold to meet that nearly all (we set it
99.99%) the delay less than or equal to tave+t-
threshold
. Thus, in the first case, the delay will be
the kth order statistic of T1 , T2 ,..., Tm. If the prob-
ability density function of T is f (t )(a ≤ t ≤ b),
then that of MDNS-m-s (MDNS with m active
DNSs using the time saving strategy) will be
Eq. (1). And in the second case, the delay can
be controlled in tave+tthreshold.
 m! k −1 m−k
 (k − 1)!(m − k )![ F (t )] [1 − F (t )]

f k (t )  f (t ) a ≤ t ≤ b
0 others


(1)
For example, as shown in figure 5, there
are five active DNSs that DNS4 and DNS5 (in
orange) are not working, and DNS3 (in red)
has been attacked. At t1, controller received
the first reply from DNS1, and at tave+tthresh-
old
, it got only three replies 93.184.216.34,
93.184.216.34, and 1.1.1.1 from DNS1~3
respectively. According to the strategy men-
tioned above, Decider will send the answer
93.184.216.34 to client and the DNS3 will be
suspected of having been attacked.
DNSs
Client (switch0) Controller
(switch1-5)
t0

interval Decider waits for. If the Decider has t1

old
t2 output queries DNSs
received more than or equal to = k (m + 1) / 2 to controller record the New_TxID

replies with the same answer before t1+tthreshold, t3

t4
then it sends the answer to the client at once receive the reply
new
t6 t5 of New_TxID
output queries
(rather than waiting for all the m replies), to new DNSs
DNSs

otherwise, it will choose the majority of the

replies back to client if received more than or
equal to kmin replies, and we call the kmin “mini-
Fig. 4. Workflow of scheduling.

China Communications • February 2019 239

 V. EVALUATION and its name server is 172.16.165.137 and
172.16.165.138 (NAT mode) respectively. The
In this section, we study the performance of Ryu controller runs on the host machine with
the MDNS. First, we conduct the Kaminsky IP 192.168.108.5. We set client’s default DNS
cache poisoning attack in a SDN network en- to be 192.168.56.7, which is not in existence
vironment to test the intrusion/fault tolerance (dummy DNS). And the reason why we use
provided by MDNS. Then, we measure the host-only mode is to add the virtual machines
delay (and handoff delay) of MDNS. Last, we to the SDN network. For example, we use
use the DNSBench [22] tool to test the perfor- openvswitch command “add-port switch0
mance of the MDNS. vmnet0” (vmnet0 is the host-only network
card used by the client) to link the client to
5.1 Experiment setup
switch0.
We setup the SDN network environment
5.2 Intrusion/fault tolerance test
using one server machine, which runs
eight virtual machines (VMware). And To prove the intrusion/fault tolerance, we use
the network topology is illustrated in fig- the Kaminsky DNS attack method provided
ure 6. The DNS server pool contains five in [23] and run the attack code on attacker to
DNSs (host-only and NAT mode) with IP flood the DNS1 with a stream of spoofed DNS
192.168.56.101~192.168.56.105 and NAT responses. The goal of the attack is to launch
address 172.16.165.131~172.16.165.135 the attack on the DNS1, such that when the
respectively. The client’s IP is 192.168.56.1 Client runs the “nslookup” command to get
(host-only mode) and the IP of attacker www.example.com’s IP address, the DNS1 will
end up going to the attacker’s name server
ns.dnslabattacker.net to get the IP address, so
Client Controller DNSs
the IP address returned is up to the attacker
www.example.com (we set it to 1.1.1.1, while the right answer is
DNS1 93.184.216.34).
t 93.184.216.34
1
DNS2 To compare the conventional DNS (just
93.184.216.34
1.1.1.1
DNS3 (attacked) DNS1 providing service) and proposed MDNS
DNS4 (error) (with DNS1~3), we set the forwarding rule
t1+tthreshold DNS5 (error)
93.184.216.34 in switch0 to output DNS queries to switch1
final answer
(DNS1) and later modify it to switch1~3
(DNS1~3).
Fig. 5. Time saving strategy. From figure 7(a), we can see that after
launching the attack, the client got the wrong
answer 1.1.1.1 (the red box), and later, after
Host switching to the MDNS, the client got the right
attacker answer 93.184.216.34 (the yellow box). And
ns.dnslabattacker.net
as shown in the figure 7(b), the Ryu controller
SDN controller
DNS1 attacker’s name server

switch1
got three replies, 1.1.1.1 from DNS1 (the red
switch2
DNS2
box), 93.184.216.34 from DNS2~3 (the blue
DNS3 Internet boxes), then Decider chose the majority an-
client switch0
switch3
swer 93.184.216.34 as the final answer sent to
switch4
DNS4 Root TLD(.com)ns.example.com the client (the yellow box).
DNS5
The results prove the intrusion/fault tol-
switch5
erance of MDNS, and it’s obvious that if we
use m active DNSs, we can tolerate up to
Fig. 6. Experiment topology. ( m +1) / 2 faulty DNSs.

240 China Communications • February 2019

 Although MDNS can improve the security
of DNS, the time delay increased also need to
be taken into account. In next section, we will
test the delay of MDNS.
5.3 Time delay test
We compare the time delay of the following
four modes: (1) Normal, which means the
switch1 outputs the replies to switch0 directly
(not through controller). We use it to simulate
the conventional DNS situation (only DNS1
providing service); (2) MDNS with one DNS
(MDNS-1), the only difference between mode
1 and mode 2 is whether switch1 outputs the
replies to controller or not. We compare it with
mode 1 to show the delay increased by send-
ing through controller; (3) MDNS with three
DNSs (MDNS-3); and (4) MDNS with five
DNSs (MDNS-5).
We send the DNS queries on the client and
collect the statistics delay of the four modes
respectively. And in order to avoid disturb-
ing from other network factors, we only use
the domain name www.example.com for test.
Before each test, we will clear the cache in
DNSs. The result is illustrated in figure 8.
From figure 8(a), we can see that the more
servers MDNS uses, the larger delay it has.
And as figure 8(b) shows, the delay of the first
query (the blue line) is much larger than that

(a) Query Results on Client

(b) Replies Received on Ryu Controller

Fig. 7. Query results.

15 1500 4
Normal delay of the first query
MDNS-1 average delay of 2~100 queries
average delay of 2~100 queries /ms

MDNS-3
MDNS-5
delay of the first query /ms

10 1000 3.5
time delay /ms

5
500 3

0
0 10 20 30 40 50 60 70 80 90 100 0 2.5
queries Normal MDNS-1 MDNS-3 MDNS-5

(a) Time Delay (b) Average delay

Fig. 8. Time delay test.

China Communications • February 2019 241

 of the subsequent queries (the red line) be-
cause of a cache miss at first. So we calculate
the average delay of the 2nd to 100th queries
(the red line). Comparing the result of Normal
and MDNS-1, we can see that sending the
replies to controller will increase the delay by
about 67.9% and 30% for the first query’s de-
lay and average delay of 2nd to 100th queries
respectively. And comparing the MDNS-1,
MDNS-3, and MDNS-5, we can find that the
delay of MDNS increases about linearly with
the number of DNSs we used.
Next, we test the handoff delay of MDNS.
Fig. 9. Log file of Ryu controller.
In our setting, at first, the Scheduler uses just
one DNS to provide service, and later switch-
3
es to three and five DNSs after the 50th and
10
MDNS-1 100th reply respectively.
MDNS-3
MDNS-5 The log file of controller is shown in figure
9. At t1, the controller sent the “add_flow” in-
struction to switch0 (the red box), after receiv-
2
ing it, switch0 outputted the DNS queries to
time delay /ms

10

controller. At t3, controller received the reply

of the first query (the green box). And we can
see that the replies received between t1 and t3
1
10 were from just one DNS (the black box), and
that was three after t3 (the yellow boxes).
The time delay result is illustrated in figure
10. We use three different colors to show the
0 20 40 60 80 100 120 140 160 180 200
queries number of servers MDNS used to provide ser-
vice. We mark three kind important moments
Fig. 10. Handoff delay. in figure 10: (1) the red triangles, denote t1, the
moment controller decides to schedule DNSs;
(2) the green squares, donate t3, the moment
600
controller receives the replies of the first DNS
query sent through controller; and (3) the black
500
circles, donate the time between t1 and t3.
We can intuitively find that the average
throughput responses/s

400
delay of the MDNS-1, MDNS-2, and MDNS-
3 increases just like figure 8(b) shows. And
300
we can see that the delay increased after t1,
like the black circles show, which is mainly
200
because the load of the controller increased
caused by the switch0 outputting the DNS
100
queries to it. And the delay increased sharply
at t3, like the green squares show, which is
0
Normal MDNS-1 MDNS-3 MDNS-3-s MDNS-5 MDNS-5-s mainly because the new DNSs didn’t have the
cache (cache miss) at first and the controller
Fig. 11. Throughput of MDNS. had to wait for all the replies. Thus, the delay

242 China Communications • February 2019

at t3 is just like the delay of the first query in Table I. Performance test.
figure 8(b). After t3, the delay recovered to the (a) Normal
normal level at once, which is mainly because Min Avg Max Std. Dev Reliab%
the scheduling was finished and the DNS que- Cached Named 0.000 0.000 0.001 0.000 100.0
ries were sent to switch1~5 directly again. Uncached Name 0.013 0.094 0.365 0.095 100.0
DotCom Lookup 0.032 0.096 0.268 0.075 100.0
5.4 Performance test
(b) MDNS-1
Next, we test the throughput of MDNS. While Min Avg Max Std. Dev Reliab%
test above is to send query one by one and Cached Named 0.000 0.001 0.002 0.000 100.0
record the delay (latency), we send queries all Uncached Name 0.014 0.124 0.822 0.149 100.0
the time to record the throughput of MDNS. DotCom Lookup 0.030 0.096 0.273 0.082 100.0
And the results are illustrated in figure 11. We
(c) MDNS-3
send 600 queries per second. We can see that
Min Avg Max Std. Dev Reliab%
the throughput of MDNS remains stable no
Cached Named 0.001 0.002 0.004 0.001 100.0
matter what the number of the active DNSs is
Uncached Name 0.015 0.294 1.004 0.315 100.0
and whether use our time saving strategy or
DotCom Lookup 0.038 0.207 0.888 0.251 100.0
not. That is mainly because the Decider can
(d) MDNS-3-s
perform parallel processing, which means the
Min Avg Max Std. Dev Reliab%
Decider will process the many queries at the
Cached Named 0.000 0.001 0.003 0.001 100.0
same time, rather than process on by one.
Uncached Name 0.013 0.097 0.268 0.091 100.0
We study the performance of MDNS by
using the DNS Benchmark tool [22]. DNS DotCom Lookup 0.031 0.069 0.256 0.035 100.0

Benchmark performs a detailed analysis the (e) MDNS-5

operational performance and reliability of the Min Avg Max Std. Dev Reliab%
DNS name servers (or resolvers) at once. The Cached Named 0.000 0.002 0.005 0.001 97.0
result is illustrated in Table I. Uncached Name 0.024 0.507 1.939 0.502 100.0
Table(a), Table(b), Table(c), and Table(e) DotCom Lookup 0.039 0.238 0.869 0.282 100.0
show the trend of increase in average delay (f) MDNS-5-s
is nearly same with figure 8. And contrasting Min Avg Max Std. Dev Reliab%
Table(c) with Table (d) and Table(e) with Cached Named 0.001 0.002 0.004 0.001 100.0
Table(f), we can see that the performance im- Uncached Name 0.015 0.245 1.003 0.298 100.0
provements benefiting from the time saving DotCom Lookup 0.034 0.062 0.258 0.035 100.0
strategy mentioned in Section 4.4 is signifi-
cant. The average delay is reduced by about
60%. And we can see that the delay of MDNS-
3-s is approximately equal to that of conven- VI. CONCLUSION
tional DNS, while that of MDNS-5-s can be
In this paper, we proposed MDNS, a dynamic
controlled in 0.3s. As for the delay brought
heterogeneous redundant architecture based
by MDNS, we can take one step further, let’s
on software defined networking. To enhance
take MDNS-5-s for example, we can set the
the robustness of DNS, we use Multi-DNS to
Decider to send the final answer back when
decide the valid answers and detect the cache
it receives two replies with the same answer,
poisoning attacks according to their replies.
rather than three. Obviously, it could be even
And to increase the amount of unpredictability,
shorter than the MDNS-3-s, however, this will
we adopt the idea of dynamicity in MTD and
lead to a corresponding decline in security.
realize it by dynamically controlling network
traffic with the help of SDN. And to further
increase the difficulty for attackers compro-

China Communications • February 2019 243

 mising all the Multi-DNS, we use heteroge-
neous DNS to avoid the same vulnerabilities.
At last, we implement MDNS and test the
performance of it, and the experimental results
prove the intrusion/fault tolerance of MDNS.
And the average delay can be controlled in
0.3s when we use MDNS-5-s.
ACKNOWLEDGEMENTS
This work is partly supported by the Na-
tional key Research and Development
Program of China (No.2016YFB0800100,
2016YFB0800101) and the National Natural
Science Fund for Creative Research Groups
Project (No.61521003) and the National Nat-
ural Science Fund for Youth Found Project
(No.61602509). We gratefully acknowledge
anonymous reviewers who read drafts and
made many helpful suggestions.
References
[1] S. M. Bellovin, “using the domain name system
for system break-ins,” Proc. USENIX Security
Symposium, Jun. 1995, pp. 199-208.
[2] J. Jiang, J. Liang, K. Li, et al, “ghost domain
names: revoked Yet Still Resolvable,” Proc. An-
nual Network & Distributed System Security
Symposium, Feb. 2012.
[3] D. Kaminskey, “It’s the end of the cache as we
know it,” Proc. In Blackhat Briefings, 2008.
[4] “an analysis report on security status and situa-
tion of Chinese domain name service,” 2017.
[5] C. Jin, Z. Hao, Z. Wu, “principles and defense
strategies of DNS cache poisoning,” China
Communications, vol.6, no.2, pp. 17-22, 2009.
[6] D. Eastlake, “domain name system security ex-
tensions,” RFC 2535 (Proposed Standard), 1999.
[7] Y. Gilad, A. Herberg, “fragmentation considered
vulnerable ,“ ACM Trans on Information and Sys-
tem Security, vol.15, no.4, pp. 16:1-16:31, 2013.
[8] “DNSSEC amplification DDoS,” Security Bulletin,
https://www.akamai.com/cn/zh/multimedia/
documents/state-of-the-internet/dnssec-ampli-
fication-ddos-security-bulletin.pdf, 2016.
[9] H. Zhou, C. Wu, M. Jiang, et al, “evolving de-
fense mechanism for future network security,”
IEEE Communications Magazine, vol.53, no.4,
pp. 45-51, 2015.
[10] R. Zhuang, S. A. Deloach, X. Ou, “towards a
Theory of Moving Target Defense,” Proc. ACM
Workshop on Moving Target Defense, Nov. 2014,
pp. 31-40.
[11] N. Mckeown, T. Anderson, “openFlow: enabling
innovation in campus networks,” ACM Sigcomm
244
Computer Communication Review, vol.38, no.2,
pp. 69-74, 2008.
[12] D. Dagon, M. Antonakakis, P. Vixie, et al, “in-
creased DNS forgery resistance through 0x20-
bit encoding: security via leet queries,” Proc.
ACM Conference on Computer and Communica-
tions Security, Oct. 2008, pp. 211-222.
[13] J. G. Høy, “anti DNS spoofing - extended query
id (XQID),“ http://www.jhsoft.com/dns-xqid.htm.
[14] R. Perdisci, M. Antonakakis, X. Luo, et al, “WSEC
DNS: protecting recursive DNS resolvers from
poisoning attacks,” Proc. IEEE/IFIP International
Conference on Dependable Systems & Networks,
2009, pp. 3-12.
[15] L. Yuan, K. Kant, P. Mohapatra, et al, “DoX: a
peer-to-peer antidote for DNS cache poisoning
attacks,” Proc. IEEE International Conference on
Communications, Jun. 2006, pp. 2345-2350.
[16] L. Yuan, C. Chen, P. Mohapatra, et al, “a proxy
view of quality of domain name service, poison-
ing attacks and survival Strategies,” ACM Trans
on Internet Technology, vol.12, no.3, pp. 321-
329, 2013.
[17] L. Fan, Y. Wang, X. Cheng, et al, “prevent DNS
cache poisoning using security proxy,” Proc.
International Conference on Parallel and Distrib-
uted Computing, Applications and Technologies,
2011, pp. 387-393.
[18] R. R. Van, A. Sperotto, A. Pras, “DNSSEC and its
potential for DDoS attacks: a comprehensive
measurement study,” ACM/USENIX, 2014, pp.
449-460.
[19] R. R. Van, K. Hageman, A. Sperotto, et al, “the
performance impact of elliptic curve cryptogra-
phy on DNSSEC validation,” IEEE/ACM Transac-
tions on Networking, 2017, pp. 738-750.
[20] R. Bassil, R. Hobeica, W. Itanni, et al, “security
analysis and solution for thwarting cache poi-
soning attacks in the Domain Name System,”
Proc. International Conference on Telecommuni-
cations, 2012, pp. 1-6.
[21] R. V. Hogg, J. W. Mckent, A. T. Craig, “introduc-
tion to mathematical statistics (7th ed),” China
Machine PRESS, 2012.
[22] “domain name speed benchmark,” https://
www.grc.com/ dns/benchmark.htm.
[23] “remote DNS attack lab,” http: //www.cis.syr.
edu/ ~wedu/seed/Labs_12.04/Networking/
DNS_Remote/.
[24] J. Voas, A. Ghosh, F. Charron, et al, “reducing
uncertainty about common-mode failures,”
Proc. IEEE Symposium Software Reliability Engi-
neering, 1997, pp. 308-319.
[25] J. Wu, “research on cyber mimic defense,” Jour-
nal of Cyber Security, vol.1, no.4, pp. 1-10, 2016.
[26] H. Hu, F. Chen, Z. Wang, “performance evalu-
ations on DHR for cyberspace mimic defense,”
Journal of Cyber Security, vol.1, no.4, pp. 40-51,
2016.
China Communications • February 2019
Biographies Guozhen Cheng, received
Ph.D. degree from National
Zhenpeng Wang, received B.S.
Digital System Engineering &
degree from Wuhan University,
Technological R&D Center,
Wuhan, China, in 2015. He is
Zhengzhou, China. He is now a
pursuing the M.S. degree in
Research Associate in National
National Digital System Engi-
Digital System Engineering &
neering & Technological R&D
Technological R&D Center. His
Center, Zhengzhou, China. His
current research is in software defined networking,
current research is in software
active defense, and network security. Email:
defined networking, active defense, and network se-
guozhencheng@hotmail.com.
curity. Email: whuwzp@whu.edu.cn.

Hongchao Hu, received Ph.D.

degree from National Digital
System Engineering & Techno-
logical R&D Center, Zheng-
zhou, China. He is now an As-
sociate Professor in National
Digital System Engineering &
Technological R&D Center. His
current research is in software defined networking,
network function virtualization, and network security.
(Corresponding author).

China Communications • February 2019 245