This is an overview of how Tunneling data over DNS works, for a tutorial see How to tunnel data over DNS.

Tunneling data over DNS isn't a new idea but it's one that surprisingly few people even in the security industry are aware of. Software to do dns tunneling has been around since at least 2006 and possibly before that. When I first heard about DNS Tunneling I completely misunderstood it and though it was like running something like an SSH Server on port 53 my responce was along the lines of "Sure but you just lock outbound connections on port 53 down, only alow connections from your DNS servers and only to your upstream DNS servers that will stop people tunneling traffic over port 53".

But it's much more subtle than that. Consider the following network¹

I've split each of the services up into individual servers to make it easier to follow although in reality it's more likely the whole thing is just an all in one Firewall/Router/Proxy/Access point/DNS/whatever device.

Now at first glance it looks like the only way go get on the net is through the Horrible Web Proxy. All out bound connection on port 53 must come from 10.1.1.5 and go to 8.8.8.8 and we don't control either of those. All connections on 80 and 443 must go through Horrible Web Proxy which is probably asking for credit card details and spying on our data at the same time. But we are not out of options!

The DNS server will happily talk to us without a credit card, because "hey, it's just DNS." and you need DNS to be working to resolve websites so you can start using the Horrible Web Proxy. So if we do an lookup for a txt record for a sub-domain where you control the Authoritative DNS Server. The request goes to 10.1.1.5 which doesn't have the result cached (becasue the record is unique and not cached) so it asks the upstream server 8.8.8.8. That's allowed out through the fire wall and then 8.8.8.8 in turn asks the authoritative server which replies with a txt record that is returned to you at 10.1.1.73.

So for example you look up {data_to_send.base32}.dns-tunnel.xo.tc and it replies with "{data_as_reply.base64}" as the txt record.

This technique is not only useful for browsing the web when stuck behind a captive portal, it can also be useful for people wanting to quietly exfiltrate data from a network where there is a Data Loss Prevention or other systems in place to prevent or detect outgoing data. I heard a story once² where person was doing some security training and heard about DNS Tunneling. He went pale and he said something like "We just saw a huge amount of DNS traffic leaving our network a couple of months ago and couldn't work out what it was. We just though it was a server malfunctioning." I'm guessing they had all the joys of rolling out incident response to look forward to after that.