I've just seen a talk about tunnelling TCP/IP over DNS requests, because port 53 UDP is usually open and unfiltered. What techniques exist to detect and block such tunnels, and have you ever seen that tunnelling on a real network?

The technique uses base32-encoded requests for TXT records which result in base64-encoded responses in the answer. Banning TXT records outright seems a bit harsh, so perhaps anomalous traffic needs to be searched for. I don't know of any tool that specifically handles this case.

  • Please specify your question. On what type of network are you looking for this? What type of limitations have it already? Or is this only theoretical? Commented Apr 20, 2011 at 21:29
  • This is a question about what you have seen on your network. I'm interested to know whether this is done in the real world, whether it's perceived as a problem, and how you react.
    – user185
    Commented Apr 22, 2011 at 9:40
  • Ok so you are more interested in information leaking then the free wireless issue i brought up Commented Apr 22, 2011 at 9:58
  • @WZeberaFFS yeah, imagine that a company has a web content filter in place, but allows unfettered DNS access.
    – user185
    Commented Apr 22, 2011 at 10:38

5 Answers 5


The most systematic answer is to implement split horizon DNS in your infrastructure, such that only internal addresses resolve; clients then must use a proxy server to connect out to the internet, and the proxy server resolves external DNS for them. This is particularly effective if your core network doesn't have a default route, so that packets destined outside your network are dropped.

The downside, obviously, is that retrofitting those controls into a running environment is likely to be an expensive and complex proposition...


Can't recall the name, but I know there's been at least one commercial product which used port 53 to phone home (not a full TCP/IP tunnel though).

I would seriously question the (f)utility of trying to prevent this kind of thing by attempting to block specific outbound traffic though. Firewalls were never intended to filter outbound traffic, tunnels, covert channels etc in this way. As long as communication is allowed at all, people will find a way - HTTP(s) is the obvious means, but people have even built proof-of-concept full TCP/IP stacks using email as the transport.

Maybe you can detect this kind of thing by monitoring for anomalous traffic, but that seems like a secondary concern to me. It's probably a better use of resources to directly address the primary issue which triggers the concern - e.g. malware or data leakage.


I realize this is an old question, but I just ran across it and thought I'd post my perspective for sake of the next guy.

The best answer is caelyx's response: architect the network so only the proxy can resolve external DNS hostnames. As he points out, retrofitting this into a production environment is difficult.

A compromise is to block all udp/53 outbound unless it originates from your internal DNS server and/or allow only to your external DNS server. This mitigates applications that simply throw data over udp/53 to an arbitrary external server. It does not reduce the risk of DNS tunneling, since your internal and external DNS servers will happily forward any RFC-compliant traffic.

I research this in 2009 and posted my findings at armatum.com. The first post was to characterize "routine" DNS traffic and compare with typical DNS tunnel implementations. The second phase was to build an algorithm to detect the unusual behavior; it started as a clustering algorithm and ended up as a simple visualization of key characteristics:

Visualization of typical DNS traffic

(click through and check out the video, see the app working in real-time) Those key characteristics ended up focusing on length of hostname queried, type of request and count of unique characters in the hostname requested. Most RFC-compliant DNS tunnel implementations maximize these values to maximize upstream bandwidth, resulting in significantly increased values over typical DNS traffic.

As I noted in the update to the second post, if I were to re-do that work today I'd include the research that's been published since and also use count of subdomains per domain as a key characteristic. That's a clever technique.

I built this as a tool I wanted at my enterprise network perimeter, based on my years serving in that role. As far as I know there are no enterprise-class industry applications/hardware that provide this depth of insight. The most common are "application level firewalls" that ensure RFC compliance --- something you can (usually) enforce with the simpler split DNS network architecture described above.

Of note, I have seen TXT response records banned outright at a large (450k hosts) enterprise perimeter with no significant reduction in utility. Your mail gateways need TXT records for SPF, but the other common uses rarely have a place in the enterprise. I don't advocate this approach, because it "breaks the internet" -- but in dire circumstances I cannot argue with it's practicality.

And finally, yes -- I've seen this technique used live, though it is unusual. (referring to enterprises, not pay-per-use public access points)


I have seen this happen.

It is mainly used by cheap geeks to avoid having to pay for public wireless. What they do is that they set up a server at home ether a fake DNS or just a random VPN at home. And when they are out and about they might have to connect to the internet so they look for any open wireless and connect and if it wants you to pay then you try to connect to your fake DNS server and tada, free internet :). I have seen this done in the "real world".

This is also doable with ICMP or more known as PING that you create a ping tunnel between the client and home server and send the data that way.

But if you see this on a "open" network like an office LAN then there's probably some type of malware or similar that doesn't want you to mess with it. If this is the case then I suggest that you take a look at it.


Palo Alto Networks next generation firewall is used regularly to limit the use of a port to a specific application. DNS is a supported application. Two rules are needed in this specific order: (1) Application=DNS, Port=53, Allow (2) Application=any, Port=53, Deny

The only way you could be sure if your specific tunneling approach would be denied would be to test it.

New tunneling methods are developed all the time and there is surely no guarantee that a new method won't require some work on Palo Alto's part. This is evidenced by the recent TCP split handshake evasion method which Palo Alto addressed this week.

I am not aware of any other firewall that enables you to implement a positive enforcement model at the application level at this time as I have described above.

Full disclosure: I provide network security services including reselling Palo Alto Networks, Check Point, and Juniper firewalls.

  • 1
    That terminology always bugged me... they dont limit a port to an application, but they may limit it to a specific protocol. Might not be a huge difference for DNS (though there might be), but e.g. HTTP - is that really considered a single application?
    – AviD
    Commented Apr 21, 2011 at 0:39
  • 2
    @Bill - where you have a connection with a product or organisation, please state your affiliation, otherwise this looks a little like spam. See security.stackexchange.com/faq : May I promote products or websites I am affiliated with here?, near the bottom
    – Rory Alsop
    Commented Apr 21, 2011 at 11:37
  • @Rory - I amended my answer in two ways. I made it more specific and disclosed my relationship with Palo Alto Networks (as well as Check Point and Juniper).
    – Bill Frank
    Commented Apr 21, 2011 at 23:13
  • 1
    Note that DNS tunneling is actually using valid DNS requests - TXT records, most commonly (so it's not "non-DNS traffic, just on 53/udp"). Thus, the rules you specify would likely allow this. Commented Oct 26, 2011 at 7:51
  • 1
    IMO, speaking of applications at this layer only makes sense for "desktop firewalls", i.e., cases where you can actually associate a socket with an application. Everything else is educated guesswork.
    – pepe
    Commented Oct 26, 2011 at 9:25

You must log in to answer this question.