Identifying and blocking DNS tunnels

Abhishek Jalan, Ashwathi S Shiva

Introduction

Protocol tunneling implementations have been around for a long time. Tunneling is the encapsulation of one network protocol inside a different network protocol. There are various reasons
for doing so - to provide encryption, to grant local network access to remote users, to bypass
firewalls and application level filters and so on. While HTTP and SSH tunneling are the more
common approaches, there are also some lesser known methods of tunneling, such as ICMP and
DNS tunneling.
Our focus is on the security issues surrounding DNS tunneling, mainly the problem of identifying and blocking DNS tunneling. This topic is of interest for a number of reasons. DNS
is a ubiquitous protocol and a DNS server can be found on almost every network. DNS traffic
tends to not be as closely inspected as some other protocols. The combination of the two facts
results in many networks allowing DNS traffic to flow freely without any restrictions, which in
turn allows DNS tunneling to work even if there are other security mechanisms in place to prevent
unauthorized network access. The use of DNS tunneling has seen resurgence due to the increased
availability of wireless hotspots as well as the use of firewalls and application level filters to restrict
access to content.
DNS tunneling was first popularized by an article on Slashdot [4] which advertised using DNS
tunneling as a free way of getting Internet access through toll-free Microsoft PPP dial-in numbers.
Two German hackers wrote the first known implementation of DNS tunneling - Name Transfer
Protocol (NSTX) to specifically exploit this vulnerability [5].
One of the most popular uses for DNS tunneling is to bypass network restrictions to gain free
Internet access. It started with dial-in PPP access, but now days it is used to bypass captive
portals at wireless hotspots to gain Internet access without paying for it [2]. It can also be used to
evade application level proxies which restrict the use of certain applications and/or protocols [3].
Spyware can also use DNS as a covert channel for data exfiltration in networks where outbound
connections might be blocked [1].

Objective

As a network administrator or a security professional, there are good reasons why you might
want to be alerted when DNS tunneling is occurring on your network and you might even choose
to block it completely. Various countermeasures have been proposed to address this issue, such
as disallowing recursive DNS lookups, performing statistical analysis of the DNS traffic, using a
1

split DNS implementation and sending all external traffic through a proxy server. However, the
approaches all have their own drawbacks. Disallowing recursive DNS lookups is a very drastic
solution since it effectively makes regular communication over the Internet almost impossible. The
problem is alleviated a little by using a proxy server to resolve all DNS queries and handle all
external communication. This is suitable in certain scenarios, e.g. a private network at a company
where the applications that need Internet access are tightly controlled. But, in an open environment
like a University network or an ISPs network, requiring all traffic to pass through a proxy might
not be acceptable. There are many application categories that do not function properly through
a proxy. Additionally, there are privacy issues that come into play. Some of the solutions, which
we discuss in the related works section, are purely theoretical, or they require building advanced
analytical systems which are beyond the capabilities for a typical network administrator, making
them impractical for deployment outside of experimental environments. Our objective was to
design a practical solution for identifying and blocking DNS tunnels using freely available open
source software. We wanted to see if it would be possible to do, and if so, how one would go about
implementing such a system.

Related Work

There is prior research that has been done in this area. Most of the existing work is focused on a
statistical approach for identifying DNS tunnels, which places higher resource demands and may
not be practical from an implementation point of view. Additionally, in most cases there is no
code or tool available that can be implemented to test the effectiveness of the solutions.
DnsTrap uses artificial neural networks and anomaly detection to identify DNS tunnels [6].
The authors work in building a tool that uses artificial neural networks for tunnel detection is
commendable. However, a major limitation of the tool is that it only operates on packet captures
and cannot sniff traffic in real time. Additionally, the tool is not publically available.
Liu [9] proposes the use of a heuristic algorithm called Suffix Matching/Requested Frequency
Counting. The idea behind it is to examine and track all the recursive queries received by the DNS
server. Queries relating to a DNS tunnel tend to be ones which have long unique values for the
subdomain, with the same domain suffix. His algorithm keeps track of the number of queries seen
for each matching suffix and drops recursive queries for that suffix if the number of queries exceeds
a predetermined threshold. This approach has a few drawbacks. The amount of additional state
that the DNS server has to maintain is proportional to the number of unique queries it receives
and it can be fairly large for a busy server. Additionally, a whitelist of good domains has to be
maintained to prevent them from accidentally being blacklisted.
Karasaridis et al. developed a module called Tunneling Attack Detector [10], whose purpose
is to detect anomalies in the size of DNS packets. They analyze traffic flow data from a Tier-1
ISP and use statistical analysis to identify non-conforming packets. However, they only consider
2

packets larger than 300 bytes to be anomalous, which means tunneling implementations like TUNS,
which uses a maximum packet size of 140 bytes [11], would not be identified.
Research done by Born and Gustafson[12], resulted in the creation of a tool called NgViz
which examines DNS traffic and shows anomalies in n-gram frequencies. They show that since the
character frequencies of normal DNS domain names follow the Zipfian distribution found in the
English language, they could detect anomalous traffic being tunneled through DNS, as it would
not conform to the expected distribution. Their work is promising; however the tool only operates
by analyzing static files against the fingerprint of legitimate traffic, so it cant be used to detect
and block DNS tunneling in real time.

Testing

We started off by building a virtual environment to test the existing DNS tunneling implementations, so we could gain a better understanding of how they function. Our initial network topology
consisted of 3 64-bit virtual machines, all running Ubuntu Linux 11.10. One virtual machine was
designated the tunnel client workstation and ran the client component of the various tunneling
tools. We configured another machine on the same network to be the local DNS server. We installed BIND 9.8.0 on the server and configured it to operate as a recursive name server. The third
machine was setup as the tunnel server. It was hosted on Amazons Elastic Compute Cloud (EC2)
service. We chose to host the DNS tunneling server on an EC2 virtual machine to more closely
simulate a real world implementation, which meant that the tunnel traffic should be routed outside
our network to a server located somewhere on the Internet, and the EC2 environment allowed us
to do this fairly easily.
Once our test environment was ready, we installed the different tunneling tools on the client
and server system and began testing them. We performed packet captures of the different phases
(initialization, idle, busy, etc.) of all the tunneling tools. The goal was to gain a better understanding of how IP and/or TCP data was being encapsulated in the DNS packets, what evasive
techniques each tool used, identify similarities and differences between the individual tools and
also note what unique traffic characteristics, if any, each one displayed, which could later aid us in
detecting the DNS tunnel being created.
First, we describe the basic mechanism by which the a DNS tunnel is created then we provide
details about the differences between each package. Each tool has a server and a client component. The server component runs on a server owned by the adversary. The server needs to
be publically accessible on UDP port 53. The adversary also needs to create a DNS entry for
a domain or subdomain, e.g. dnstunnel.mydomain.com, and point the name server (NS) record
for that domain to the IP address of the machine running the DNS server component. When
the adversary wishes to create a DNS tunnel, he starts up the client component of the tool and
provides it with the name of the DNS domain he registered. The client component will first try to
3

make a direct connection with the machine running the server component on port 53. While this
is not common, some networks do allow clients to make outbound connections on port 53, even
while blocking or outgoing requests on port 80, 444, etc. If the connection on port 53 is possible,
the client can then exchange packets directly with the server. In most cases however, this will be
blocked. So the client then sends a data packet encoded as a DNS request to the local DNS server,
intended for the NS for the adversarys domain. The leftmost label of the domain name in the
query (hereupon referred to as Lowest Level Domain (LLD)) contains the data the client wises to
transmit to the server, encoded in Base32 format. A typical request would look something like this:
dIUAQIJEM7VABAAEASC.MRTGQ2TMNY0.dnstunnel.mydomain.com. The local DNS server
will locate the NS that is authoritative for the domain and forward the query to it. The authoritative NS is the machine running the server component of the tunneling tool. When the tunneling
server receives the DNS query, it extracts the LLD, decodes it and processes it as necessary. If the
packet is intended for a different host, the server will route it out to the Internet, and wait for a
response. The response is then encoded using Base64 and sent back to the querying DNS server
in the form of a TXT, NULL or CNAME record. This is essentially how data is transmitted back
and forth using the DNS tunnel.
We examined 5 different tunneling tools, which basically operate in the manner described
above. NSTX was the first publically available tool for creating DNS tunnels [4]. It uses Base64
for encoding data and the responses are sent as TXT records. NSTX creates a tunneling network
interface on the machine, which can be used to transmit and receive data.
OzymanDNS uses a set of Perl scripts to create a DNS tunnel; however it doesnt create a
virtual tunneling interface on the client. Instead it just transmits data sent and received on a
specified TCP port. It can be used to create an SSH tunnel over the DNS channel and then route
application traffic through the tunnel. Another slight difference with OzymanDNS is that it makes
use of the EDNS0 extensions and TXT records when sending data back to the client. The EDNS0
extensions, which were proposed in 1999 [15], allow the tunneling tools to get past the 512 byte
DNS packet size limit, significantly increasing the throughput of the tunnel. OzymanDNS has not
been updated since 2005 and it proved to be very unstable during our tests, crashing often.
Dns2tcp essentially operates in the same fashion as OzymanDNS. The program is written in C
and didnt suffer from any of the stability issues that we faced with OzymanDNS.
Iodine builds on the work done by the previous DNS tunneling tools and adds some more
features like authentication and compression. It uses NULL records and EDNS0 extensions for
sending responses back to the client. NULL records are defined in RFC 1035 [7] as an experimental
record type that can contain any data up to 65,535 bytes. Since NULL records do not have a defined
format, by using them, Iodine is able to avoid the overhead of encoding the data in Base64 and it
also allows for the use of compression, increasing the efficiency of the tunnel.
TUNS is a newer implementation that was born out of a research project at a French University
[11]. It was designed specifically to evade detection. It does this by trying to match its traffic
4

profile to that of a legitimate DNS client and avoids the use of any enhancements like using NULL
records or EDNS0 extensions. The server component encodes data packets using Base32 encoding
and transmits them as CNAME records.

5
5.1

Implementation
Blocking NULL Records

As we discovered during the testing phase, many tunneling tools make use of NULL records for
transmitting data. A NULL record is defined as an experimental record type in the DNS RFC and
though most DNS implementations understand and allow NULL records, we were not able to find
any legitimate use for them. Thus, we decided to investigate the possibility of disallowing NULL
records as a way of blocking DNS tunnels. We mistakenly assumed that blocking a specific record
type would be a fairly easy configuration change in BIND. However, most DNS implementations
offer very few DNS security features outside of source port randomization and DNSSEC. Due to
there rarely being a need to block specific DNS record types in practice, that capability has not
been implemented in BIND and most other DNS servers. After investigating other mechanisms
for achieving the desired effect, we came across a new feature in BIND called Response Policy
Zones (RPZ). RPZs are a controversial new addition to BIND that allows for DNS rewriting and
DNS blocking. We upgraded our BIND instance to version 9.9.0 to make use some of the latest
RPZ changes. We were than able to configure our BIND server to reject or redirect NULL record
queries. Even though we werent technically using RPZs for their intended purpose we were able
to achieve the desired results.

5.2

Detecting Tunnel Traffic

Detection and classifying of traffic of any type is not an easy task for a machine. A firewall or
intrusion detection system (IDS) cannot accurately classify traffic as legitimate or malicious very
easily. Instead, the general approach is find traffic that is known to be malicious, look for unique
identifying patterns in the traffic and then use that as a template for classifying similar traffic
as malicious. The challenge here is to do it in a matter that minimizes false positives while still
identifying the malicious traffic. This is essentially the basis on which IDSs operate. We decided
to use the same technique for identifying DNS tunneling traffic. We began by examining the
packet captures of the various tunneling tools that we had obtained earlier, looking for identifying
characteristics. It turned out that some of the more sophisticated tools did have patterns in the
DNS requests and responses that could be treated like a unique signature. Iodine for instance,
always sets certain bits in the header and body of its DNS requests and responses. We were able to
exploit that to create a rule sets for Snort. Snort was the open source intrusion detection system

we deployed for implementing DNS tunnel detection. We setup a new virtual machine running
Ubuntu and installed Snort on there. We also configured our virtual switch to mirror all traffic
intended for the router to on another port that was connected to the monitoring interface on the
Snort server. After some tweaking, we were able to refine our rules to accurately detect DNS
tunneling traffic, while generating no false positives. Of course, this is not a guarantee that the
rule sets will never generate a false positive, but given the unusual nature of the specific bits that
are set in the DNS tunnel packets, the probability of a legitimate DNS packet also having the same
combination of bits set is very low.

5.3

Securing Captive Portals

One of the most popular uses for DNS tunnels is to bypass a captive portal to get free Internet
access. Unsecured wireless hotspots can often be found at high traffic locations like airports,
malls, University campuses, libraries etc. Even though the wireless network is not using a security
protocol like WEP or WPA for securing the network, network access is typically restricted by the
use of a captive portal. After joining the network, the users are redirected to a registration or
authentication page where they are required to login with existing credentials or pay a fee to gain
Internet access. The redirection is typically done in one of three ways. When IP redirection is
used, the firewall redirects all external HTTP/HTTPS traffic to the registration server. If DNS
redirection is employed, the DNS server uses a technique similar to DNS cache poisoning to return
the IP address of the registration server for any DNS request. In other cases, all traffic is sent
through a proxy server, which forwards all web traffic to the registration server by rewriting the
URL. If a recursive DNS server is present on the network, then in all cases except DNS redirection,
an unauthenticated user will be able to create a DNS tunnel and use it to get Internet access.
While it is possible to stop a tunnel from being created by not resolving external DNS queries for
unauthenticated users, many networks do not implement this.
For our implementation, we setup a new virtual server and installed PacketFence on it. PacketFence is an open source network access control server. We isolated the workstation running
the tunneling clients by placing it on a separate network behind the PacketFence server. In the
default PacketFence configuration, the tunneling client was still able to create a DNS tunnel and
get external network access through it. To prevent this, we enabled a feature of PacketFence called
DNS Blackhole. This is similar to the DNS redirection technique discussed previously, where the
PacketFence server resolves all DNS requests internally by returning its own IP address. Only after
a client is authenticated, are its DNS requests forwarded to the local DNS server. This prevented
any unauthorized clients from using DNS tunneling to bypass the captive portal and gain Internet
access.

5.4

Traffic Shaping

The three approaches discussed previously were fairly successful at identifying and blocking most of
the DNS tunneling tools, but not all of them. We decided to slow down the tunnels that we couldnt
block, to greatly reduce their usefulness. We did this by implementing the traffic shaping features
of PFSense. PFSense is an open source firewall distribution based on FreeBSD. We deployed
another virtual machine running PFSense, on the edge of our network. Using PFSense we setup
traffic limiters for upstream and downstream DNS traffic. The bandwidth in either direction was
limited to 100 kilobits per client. The number was picked rather arbitrarily. Ideally, a network
administrator would run a bandwidth monitor for DNS traffic for an extended period of time
and pick a bandwidth limit based on the average amount of traffic consumed by legitimate DNS
requests. The objective would be to pick a value that is high enough that legitimate DNS traffic
is not impacted too much, while at the same time, any unauthorized high bandwidth use of DNS
would be slowed down significantly, to the point of making it impractical to use DNS tunnels.
We realize that this is not an all-encompassing solution. There are still specific cases in which
even a very low bandwidth DNS tunnel might provide to be useful, like establishing an SSH
session over DNS, or by spyware, for covert data exfiltration. To address such cases, some of the
more restrictive solutions discussed previously can be employed, such as disallowing recursive DNS
lookups or requiring the use of a proxy server for all communication. However, for more generalized
situations, using traffic shaping might be an effective deterrent against DNS tunneling use.

DNS Tunneling Server

Internet

Firewall

Malicious User

DNS Tunneling Client

NAC Server

DNS Server

Figure 1: Network Topology

Router

Intrusion Detection System

Evaluation

For evaluating the effectiveness of our solution, we combined all our techniques together and a
created a unified network design, against which the different DNS tunneling tools were tested.
The final network topology can be seen in Figure 1. The table below shows the results of our
evaluation.
Tool

Successfully Identified

Successfully Blocked

NSTX

Yes

Yes

DNS2tcp

Yes

Yes

Iodine

Yes

Yes

TUNS

No

No

We were successful in blocking most of the popular tunneling tools, except TUNS. As mentioned
previously, TUNS was designed as part of an academic exercise to see if it was possible to create a
tool that could evade detection. It achieves this using only CNAME records for data transmission,
greatly limiting its overall throughput. While it is successful in hiding its identity, by sacrificing
on performance it reduces its usefulness. We were unable to block it, but we were successful in
slowing it down, making it even less useful.

Future Work

In our environment, Snort was deployed in passive mode, where a copy of the traffic is sent to the
Snort server and alerts are generated if the traffic matches the defined rule sets. Using Snort in
inline mode would be preferable as Snort could then be configured to drop traffic related to DNS
tunneling instead of just alerting on it.
We would like to investigate the possibility of using open source tools that could perform
network traffic analysis to establish a baseline pattern for the network and then use anomaly
detection to discover when DNS tunneling is being used. We were unable to locate a single
package that could do this, but we believe that by combining multiple different components we
should be able to build such a system.
Lastly, it might be beneficial to spend some more time analyzing the behavior of TUNS to see
if we can come up with ways of identifying and/or blocking it.

Conclusion

We have shown that DNS tunneling is a serious security threat that is often overlooked or ignored
because the existing approaches for blocking it are either impractical or too complex. We have
developed a mechanism for identifying and blocking DNS tunnels using only freely available open
8

source tools. We outline four different techniques - Blocking NULL records, Detecting Tunnel
Traffic, Securing Captive Portals and Traffic Shaping, which when used together, prove to be
fairly effective, stopping all but one of the four popular tunneling tools we examined.

References
[1] J. Aycock, Spyware and Adware, Springer Publishing Company, Incorporated, 2009. ISBN
0387777407, 9780387777405
[2] S. Psomadakis, (2011, April). Tunnel IP traffic through DNS, to bypass captive portals(or
firewalls). Lecture conducted from National Technical University of Athens.
[3] D. Kaminsky, Black Ops of DNS, Black Hat Briefings, 2004.
[4] F. Heinz, J. Oster, IP Tunneling Through Nameservers, Slashdot, September 10, 2000
http://slashdot.org/articles/00/09/10/2230242.shtml
[5] T. Gil, NSTX HOWTO, Created:
http://thomer.com/howtos/nstx.html

2005-11-04,

Last

modified:

2006-02-27

[6] J. Hind, Catching DNS Tunnels with A.I., Proceedings of DefCon 17, July 2009. Las Vegas,
Nevada.
[7] P. Mockapetris. RFC 1035 - Domain Names - Implementation and Specification, November
1987. http://www.faqs.org/rfcs/rfc1035.html.
[8] A. Merlo, G. Papaleo, S. Veneziano, and M. Aiello, A Comparative Performance Evaluation of
DNS Tunneling Tools, CISIS, . Herrero and E. Corchado, Berlin, Heidelberg: Springer Berlin
Heidelberg, 2011, pp. 84-91.
[9] Z. Liu, What an IP-over-DNS Tunnel-A Case Study on Large Operational Network, Proceedings of DNS EASY 2011 Workshop, October 2011. Rome, Italy.
[10] A. Karasaridis, K. Meier-Hellstern, and D. Hoeflin. Detection of DNS anomalies using flow
data analysis. In Global Telecommunications Conference (GLOBECOM), Nov. 2006.
[11] P. Neyron, O. Richard, and L. Nussbaum, On Robust Covert Channels Inside DNS, 24th IFIP
International Security Conference, Pafos, Cyprus: 2009, pp. 51-62.
[12] K. Born, D. Gustafson. 2010. NgViz: detecting DNS tunnels through n-gram visualization
and quantitative analysis.CSIIRW, 2010.
[13] T. van Leijenhorst, K.-W. Chin, and D. Lowe, On the Viability and Performance of DNS
Tunneling, in ICITA 08, 2008
9

[14] M. Dusi, M. Crotti, F. Gringoli, and L. Salgarelli, (2009). Tunnel hunter: Detecting
application-layer tunnels with statistical fingerprinting. Computer Networks, 53(1):81-97.
[15] P. Vixie, 1999. Extension mechanisms for DNS (EDNS0). RFC 2671. Internet Engineering
Task Force (IETF).

10